Bug#831077: Preparing for upload

[Ole Streicher]

Hi,

to make some progress here, I would like to upload a new version of
casacore based on the current git repository by the end of the week.
This would close this bug. I would also add myself into the "Uploaders"
list (and mark it as a regular upload).

Are there any objections? Gijs? Benda?

Cheers

Ole

Bug#798818: Reopen bug for updating kernel for mipsel buildds

[Ole Streicher]

Hi Aurelien,

On 27.09.2016 13:31, Aurelien Jarno wrote:
> We have identified an hardware FPU bug on the Loongson 3 build daemons,
> a dozen of packages are known to be affected so far, it seems your
> package is an additional one.
> [...]
> As explained above, this won't fix your issue. That said I have
> configured those build daemons to not build casacore anymore, and I have
> given back casacore. This should fix your issue.

Thanks a lot for the explanation and adding casacore to the blacklist.
This helps a lot to get through the portability issues of casacore :-)

Cheers, and greetings to Lyon

Ole

Bug#831175: Bug is not reproducible anymore

[Ole Streicher]

Control: tags -1 + unreproducible

I cannot reproduce this anymore; also the just-uploaded new version
(with minor changes not affecting the build) builds fine. The cause of
the FTBFS is probably not in the package itself, but in the "casacore"
dependency, which was not built with gcc-6 at the time of the bug
report. I fixed this (and also some other problems) in the casacore package.

If there are no more build problems on x86_64, I would close this bug in
the next days.

Cheers

Ole

Bug#798818: Reopen bug for updating kernel for mipsel buildds

[Ole Streicher]

unarchive 798818
reopen 798818
thanks

Sorry for disturbing you again: When building on
mipsel-aql-02.debian.org, the kernel is still

Kernel: Linux 3.16.0-4-loongson-3 mipsel (mips64)

which is far outdated, and causes an FTBFS:

https://buildd.debian.org/status/fetch.php?pkg=casacore=mipsel=2.1.0-3=1474903782

For comparison, the previous one succeeds:

https://buildd.debian.org/status/fetch.php?pkg=casacore=mipsel=2.1.0-2=1474385578

Similarly, I get a failure on mipsel-aql-02.debian.org (this time for
mips64).

Could you please update *all* mips buildds to a 4.7 kernel? Otherwise
there is always trouble with the FPU.

Bug#830254: Failures due to kernel bugs in MIPS

[Ole Streicher]

The three tests

* tClassicalStatistics
* tHingesFencesStatistics
* tLCEllipsoid

FTBFS on MIPS platforms (mips, mipsel, mips64) when they are build on
linux kernel version 3.16.0, but succeed on kernel version 4.7.

Since I previously had floating point problems on MIPS with older
kernels -- see f.e.

https://bugs.debian.org/811368
https://bugs.debian.org/781892

They *should* be all updated; see https://bugs.debian.org/798818
However, mipsel-aql-* machines are still on kernel 3.16...

Bug#839348: astroml: FTBFS: dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 returned exit code 13

[Ole Streicher]

Control: reassign -1 python-sklearn 0.18-1
Control: retitle -1 python-sklearn: wrong import of "parallel"
Control: affects -1 src:astroml

This is a bug in scikit-learn, not in astroml:

$ python
Python 2.7.12+ (default, Sep  1 2016, 20:27:38) 
[GCC 6.2.0 20160822] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sklearn.mixture
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/sklearn/mixture/__init__.py", line 5, 
in 
from .gmm import sample_gaussian, log_multivariate_normal_density
  File "/usr/lib/python2.7/dist-packages/sklearn/mixture/gmm.py", line 27, in 

from .. import cluster
  File "/usr/lib/python2.7/dist-packages/sklearn/cluster/__init__.py", line 6, 
in 
from .spectral import spectral_clustering, SpectralClustering
  File "/usr/lib/python2.7/dist-packages/sklearn/cluster/spectral.py", line 16, 
in 
from ..metrics.pairwise import pairwise_kernels
  File "/usr/lib/python2.7/dist-packages/sklearn/metrics/__init__.py", line 33, 
in 
from . import cluster
  File "/usr/lib/python2.7/dist-packages/sklearn/metrics/cluster/__init__.py", 
line 20, in 
from .unsupervised import silhouette_samples
  File 
"/usr/lib/python2.7/dist-packages/sklearn/metrics/cluster/unsupervised.py", 
line 13, in 
from ..pairwise import pairwise_distances
  File "/usr/lib/python2.7/dist-packages/sklearn/metrics/pairwise.py", line 27, 
in 
from ..externals.joblib import parallel
ImportError: cannot import name parallel

It is a regression; 0.17.1-2 (in testing) works fine.

Best regards

Ole

Bug#843668: ITP: drizzle -- Dithered image combination for Python

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-Cc: debian-as...@lists.debian.org, debian-de...@lists.debian.org

* Package name: drizzle
  Version : 1.1
  Upstream Author : Bernie Simon <bsi...@stsci.edu>
* URL : http://spacetelescope.github.io/drizzle/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Dithered image combination for Python

 The drizzle library is a Python package for combining dithered images
 into a single image. This library is derived from code used in
 drizzlepac. Like drizzlepac, most of the code is implemented in the C
 language. The biggest change from drizzlepac is that this code passes
 an array that maps the input to output image into the C code, while
 the drizzlepac code computes the mapping by using a Python
 callback. Switching to using an array allowed the code to be greatly
 simplified.

The package is an upcoming astropy affiliated package and will be
maintained by the Debian Astro Team. A git repository is created at

https://anonscm.debian.org/git/debian-astro/packages/drizzle.git

Best regards

Ole

Bug#843667: ITP: drizzle -- Dithered image combination for Python

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>

* Package name: drizzle
  Version : 1.1
  Upstream Author : Bernie Simon <bsi...@stsci.edu>
* URL : http://spacetelescope.github.io/drizzle/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Dithered image combination for Python

 The drizzle library is a Python package for combining dithered images
 into a single image. This library is derived from code used in
 drizzlepac. Like drizzlepac, most of the code is implemented in the C
 language. The biggest change from drizzlepac is that this code passes
 an array that maps the input to output image into the C code, while
 the drizzlepac code computes the mapping by using a Python
 callback. Switching to using an array allowed the code to be greatly
 simplified.

The package is an upcoming astropy affiliated package and will be
maintained by the Debian Astro Team. A git repository is created at

https://anonscm.debian.org/git/debian-astro/packages/drizzle.git

Best regards

Ole

Bug#843709: Purify missed the cfitsio5 transition

[Ole Streicher]

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

Hi,

The "purify" package was in NEW while the cfitsio transition was going on,
so it missed it. Please do an binNMU for the package now.

 nmu purify_2.0.0-1 . amd64 . -m 'Rebuild against libcfitsio5'

Thanks

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas,


On 09.11.2016 12:47, Andreas Tille wrote:
> In other words: Once it was defined as syntax for these control files
> that newlines need to be escaped.  I do not like it and as I said this
> is fixed in the long-term pending rewrite.  However, the bug is not
> serious but at best wishlist.  Would you follow this arguing?
>

Not really. My point here is that this happens really unexpected, and
since blend-gen-control doesn't complain about the then wrong format,
one silently gets wrong dependencies. At least I did in the first
versions of debian-astro (<0.5).

We have a clear definition of how these files should look like, namely
RFC822, and this also defines continuation lines. Look at
https://blends.debian.org/blends/ch08.html#edittasksfiles - it is
blends-gen-control that isn't conform to that.

I would think that there is also a quick fix for it -- the tool already
handles continuation lines for the tasks description, so one could
probably just take that. I have no glue of all the Perl $@^!~ special
chars, but wouldn't do it something like the attached patch (after
removing the obvious errors from it)?

Or something else just adopted from lines 556-562 of blends-gen-control?

Best regards

Ole

diff --git a/devtools/blend-gen-control b/devtools/blend-gen-control
index 1aba552..cde3237 100755
--- a/devtools/blend-gen-control
+++ b/devtools/blend-gen-control
@@ -566,9 +566,14 @@ sub load_task {
 my $header;
 for $header (qw(Depends Recommends Suggests)) {
 if (m/^$header:\s+(.+)$/ && $1 !~ /^\s*$/) {
+		my $pkgs = $1;
+		while () {
+		last if (m/^\S+/ || m/^\s*$/);
+		$pkgs .= $_;
+		}
 $taskinfo{$curpkg}{$header} = ()
 if (! exists $taskinfo{$curpkg}{$header});
-my ($pkglist, $missinglist) = process_pkglist($1);
+my ($pkglist, $missinglist) = process_pkglist($pkgs);
 push(@{$taskinfo{$curpkg}{$header}}, @{$pkglist});
 
 		$haspackages += $#{$taskinfo{$curpkg}{$header}} + 1;

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas, Petter and all,

On 10.11.2016 21:07, Andreas Tille wrote:
> So I confirm that the first problem we detected is solved but there is
> another one breaking Debian Edu.  I have again no suspicion why the '\'
> sign is not elimiunated from the list only in those few cases.

I can also just "poke in the fog" here. I thought that the multilines
were already eaten up by lines 537-544, and should not appear again
here. However, they do, as my "print" debugger shows. Perlists, please
help!!!

The pragmatic solution here is to just remove the backslashes from the
end of line. I can commit a patch that does this.

However, debian-edu keeps to be broken. Reason is that the tasks contain
lines like (development)

Depends: fp-compiler, [...multiline... ], fp-units-fv
Depends: lazarus

so, with two "Depends" in one section. Or (electronics):

Depends: qucs, gpsim, oregano
Recommends: education-menus, xoscope
Suggests: kicad, kicad-doc-en, kicad-doc-de, kicad-doc-es, kicad-doc-fr
Suggests: electric, pcb, xcircuit, freehdl, gtkwave
Responsible: ?
NeedConfig:  no

two "Suggests". This does not work anymore (no idea why), but is also
IMO forbidden by RFC834.

I have no idea why this works without RFC834 continuation, but not with
them.

On the other hand, we *win* one more dependency: in "common", the
"firmware-ralink" dependency line was *not* preceded one with a
backslash. This shows that the backslash is just a bad idea for
continuation lines.

--> debian-edu tasks are just broken. They don't follow any rule, and
depending from the parser one will get always different results. Maybe
we should fix that? remove all backslash continuation lines and
duplicated keywords from the tasks files?

Best regards

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi all,

On 11.11.2016 08:07, Andreas Tille wrote:
> On Thu, Nov 10, 2016 at 10:38:32PM +0100, Ole Streicher wrote:
>> --> debian-edu tasks are just broken. They don't follow any rule, and
>> depending from the parser one will get always different results. Maybe
>> we should fix that? remove all backslash continuation lines and
>> duplicated keywords from the tasks files?
> 
> I think it should be sufficient to add line breaks where needed.

If we touch them anyway, we could make them fully RFC compliant at this
time as well. Since I am currently stuck in the S-Bahn (Polizeieinsatz),
I will do that for debian-edu and push. Cellphone internet is a nice
thing sometimes... :-)

@Petter, please review and change/revert if you disagree.

Cheers

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas,

On 10.11.2016 13:48, Andreas Tille wrote:
> Hi Petter,
>
> On Thu, Nov 10, 2016 at 12:39:07PM +0100, Petter Reinholdtsen wrote:
>> Control: tags -1 + pending
>>
>> [Andreas Tille]
 Should I commit it?
>>> Yes please.  Ole, you reported problems with your patch.  Could you
>>> please be more verbose about this problem - at best based on Petter's
>>> commit to make sure we are all working on the same code?
>> It is now commited.  Please give it some more testing before uploading.
>> Preferably also with the debian-edu git repo, where both tasks and
>> control file is kept in git, allowing any changes to be easily
>> discovered.
> I need to admit two things: Even in Debian Med we went into the trap
> criticised by Ole.  In bio-cloud which is not maintained by me we were
> also loosing entries.  The second thing I need to admit that there are
> in fact syntax errors resulting from the patch.  When using the new
> blends-dev package a
>
> gbp clone ssh://git.debian.org/git/blends/projects/med.git
> cd med
> make dist
> grep ^, debian/control
>
> shows the problem.  It leads to something like
>
> Suggests: bagpipe,
>  cufflinks,
>  embassy-phylip,
>  gmap,
>  r-cran-vegan
> ,
>  r-other-mott-happy.hbrem
> ,
>  r-other-valdar-bagphenotype.library,
>  soapdenovo2
> ,
>  sra-toolkit
> ,
>  staden-io-lib-utils
> ,

This is what I meant, and it is fixed by my last commit. Please try
again ;-)

Cheers

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas & all,

On 09.11.2016 15:35, Andreas Tille wrote:
>> We have a clear definition of how these files should look like, namely
>> RFC822, and this also defines continuation lines.
> 
> Unfortunately in this specific feature tasks files are not RFC822
> compliant, which sucks, yes.  Its even not documented (I just checked
> since I intended to document it at some point in time but can't find it
> :-( )

If one of our main tools is not compliant with our documented
specifications, and this may cause incomplete metapackages (which are
one central part of the blend), then I would still rate this as an RC
bug, independently of whether it is easy to fix or not.

>> I would think that there is also a quick fix for it -- the tool already
>> handles continuation lines for the tasks description, so one could
>> probably just take that. I have no glue of all the Perl $@^!~ special
>> chars, but wouldn't do it something like the attached patch (after
>> removing the obvious errors from it)?
>>
>> Or something else just adopted from lines 556-562 of blends-gen-control?
> 
> While I fully agree that we should fix this I'm not fully convinced how
> to sensibly proceed here.  The problematic thing is that we are quite
> short before a release and if we might break metapackage creation in
> some way we might get in trouble.  I'm no Perl programmer myself (even
> if I think your patch looks sensible) and so IMHO staying conservative
> and add some line ending escapes could be the less invasive change.

I checked my patch, and it does *not* work correctly, it will produce
syntax errors in the debian/control file, if RFC822 continuation lines
are used. For tasks that have all in one line, or that have
metapackages, everything seems to be OK, however.

> If you (and Bas and other readers here) think we should fix the issue
> right now I'm fine if you apply the patch below and we should seriously
> test the metapackage creation of each Blend *before* 2016-12-05.
> 
> What do you think?

I am ready to test and also to fix; however my know-how ends here. I
don't know what is wrong with the fix.

Just wondering, and starting to really get worried: None of the
debian-blends maintainers has enough Perl knowledge to fix this? If we
all do not know Perl, why do we use that language in one of our central
tools? That sounds to me even more RC than the bug itself...

Cheers

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas and Bas,

On 10.11.2016 08:45, Andreas Tille wrote:
> On Wed, Nov 09, 2016 at 06:27:13PM +0100, Sebastiaan Couwenberg wrote:
>> On 11/09/2016 03:35 PM, Andreas Tille wrote:
>>> If you (and Bas and other readers here) think we should fix the issue
>>> right now I'm fine if you apply the patch below and we should seriously
>>> test the metapackage creation of each Blend *before* 2016-12-05.
>>>
>>> What do you think?
>>
>> I think supporting the deb822 format should be a Blends release goal for
>> buster,
> 
> I fully agree.  I admit I did way less for blends-dev than I intended to
> do but other tasks that felt more urgent occupied all my Debian time.
> 
>> it's indeed to late in the stretch dev cycle in my opinion.
> 
> That would mean to lower the severity of #840094.  Ole, are you OK with
> this?

No, I am not. The tool gives wrong results, and it does so silently. If
I would not have discovered this by chance, the Debian Astro tasks
packages were still wrong and would have stayed so in Stretch. I don't
know about other blends, whether they ever checked the metapackages --
others still may have missing tasks as well, just because their
maintainers read the docs and trust the debian-blends package. And you
can't just change the specs in the last minute.

And, if the package is in Stretch, people will start their new blend
with exactly this package, again running into this trouble.

I would really propose to fix that before Stretch. It just can't be that
difficult. Nobody knows a Perl specialist who can have a look?

(Oh, and can we have Python for the Next Generation blends-dev? This is
at least what I understand, and there is already a parser for rfc822)

Best regards

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas and Bas,

On 10.11.2016 08:45, Andreas Tille wrote:
> On Wed, Nov 09, 2016 at 06:27:13PM +0100, Sebastiaan Couwenberg wrote:
>> On 11/09/2016 03:35 PM, Andreas Tille wrote:
>>> If you (and Bas and other readers here) think we should fix the issue
>>> right now I'm fine if you apply the patch below and we should seriously
>>> test the metapackage creation of each Blend *before* 2016-12-05.
>>>
>>> What do you think?
>>
>> I think supporting the deb822 format should be a Blends release goal for
>> buster,
> 
> I fully agree.  I admit I did way less for blends-dev than I intended to
> do but other tasks that felt more urgent occupied all my Debian time.
> 
>> it's indeed to late in the stretch dev cycle in my opinion.
> 
> That would mean to lower the severity of #840094.  Ole, are you OK with
> this?

No, I am not. The tool gives wrong results, and it does so silently. If
I would not have discovered this by chance, the Debian Astro tasks
packages were still wrong and would have stayed so in Stretch. I don't
know about other blends, whether they ever checked the metapackages --
others still may have missing tasks as well, just because their
maintainers read the docs and trust the debian-blends package. And you
can't just change the specs in the last minute.

And, if the package is in Stretch, people will start their new blend
with exactly this package, again running into this trouble.

I would really propose to fix that before Stretch. It just can't be that
difficult. Nobody has a Perl specialist who can have a look?

(Oh, and can we have Python for the Next Generation blends-dev? This is
at least what I understand, and there is already a parser for rfc822)

Best regards

Ole

Bug#845427: python-pywcs: ROM; dead upstream; superceded by python-astropy

[Ole Streicher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-as...@lists.debian.org

Dear ftpmasters,

please remove python-pywcs. It is not maintained upstream anymore since
years and completely superceded by python-astropy. Without major
efforts, it is unusable because of incompatibilities to its
dependencies. CI tests fail.

People should just move to astropy and replace

import pywcs

with

import astropy.wcs as pywcs

There are no reverse dependencies.

Best regards

Ole

Bug#844087: Please consider removing pyfits

[Ole Streicher]

Hi Aurelien,


On 22.11.2016 22:12, Aurelien Jarno wrote:
> On 2016-11-12 11:40, Ole Streicher wrote:
>> is however valid for pyfits, which also will not see any upstream love
>> anymore.
> Note that pyfits has seen an upload in 2016, so it got upstream love
> recently, and there is a newer version than the one from Jessie in the
> archive. That said it was clearly the last version.


Sure, however the major reason for my proposal is that upstream itself
expressed that one should switch. And he thinks about releasing a
really-last version that just imports astropy.io.fits.

>> IMO the release of Stretch is a good opportunity to force the users into
>> the use of astropy, especially as it is as easy as replacing
>>
>> import pyfits
>>
>> by
>>
>> import astropy.io.fits as pyfits
> That's not fully correct. That's true for simple programs, that said
> astropy.io.fits has removed or deprecated some functions, so it doesn't
> work in the most complex cases.

Do you have an example here? From my experience, already the recent
versions have some incompatibilities. These incompatibilites lead to a
non-working pywcs, and this is the occasion for me to think about the
pywcs removal. For old code, you just can't use pyfits anymore;

 header.update(key, value=v,  comment=c)

will not work.

> My plan has always been to remove pyfits from the archive after the
> release of Stretch. I don't see the point of doing that earlier.

I am afraid that the user will migrate to the last pyfits release
instead of astropy, even if the effort is the same. And stay in the dead
end.

Best regards

Ole

Bug#845332: ITP: casacore-data-sources -- Table of ICRF reference source coordinates for casacore

[Ole Streicher]

Hi Jonathan,

On 22.11.2016 20:12, Jonathan Quick wrote:
> On Tue, November 22, 2016 5:22 pm, Ole Streicher wrote:
>> It is still undecided if we take ICRF1 (1998; 608 sources) or
>> ICRF2 (2007; 3414 sources).
> 
> ICRF-2 supersedes ICRF-1 with more accurate positions.  Currently the next
> realisation (ICRF-3) is under preparation for release in 2017.

I know; however casacore in the moment provides a table with ICRF1; see
f.e. ftp://ftp.astron.nl/outgoing/Measures/WSRT_Measures.ztar

If there is no reason to stay with ICRS1, I would use ICRF2; I will
however see if some arguments pop up upstream:

https://github.com/casacore/casacore/issues/539

Cheers

Ole

Bug#845332: ITP: casacore-data-sources -- Table of ICRF reference source coordinates for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-sources
  Version : 1 or 2
* URL : https://www.iers.org/IERS/EN/DataProducts/ICRF/icrf.html
* License : Public domain
  Description : Table of ICRF reference source coordinates for casacore

 This package contains a table with the sources that realize the
 and the International Celestial Reference Frame (ICRF), as a table for
 the use with casacore. The ICRF is now the standard reference frame
 used to define the positions of the planets (including the Earth) and
 other astronomical objects.

The package is a part of the effort taken by Benda Xu and me within the
Debian Astro team to split up the original "casacore-data" package (RFP
#761146) by data source into smaller packages which can be maintained
independently.

It is still undecided if we take ICRF1 (1998; 608 sources) or
ICRF2 (2007; 3414 sources).

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-sources.git

Best regards

Ole

Bug#846142: ITP: casacore-data-lines -- Table of spectral lines for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-lines
  Version : 1.0
* URL : https://github.com/casacore/lines-table
* License : CC0
  Description : Table of spectral lines for casacore

 This package contains a table with the spectral line frequencies for the use
 with casacore.

The package is a part of the effort taken by Benda Xu and me within the
Debian Astro team to split up the original "casacore-data" package (RFP
#761146) by data source into smaller packages which can be maintained
independently.

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-lines.git

Best regards

Ole

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

[Ole Streicher]

Control: reassign -1 blends-tasks
Control: tags -1 moreinfo

Hi Holger,

thank you for your bug report to the "blends" package. I would, however
question a few things here and also ask for a little bit more information:

The "blends-tasks" package was created as a result of working on bug
#758116, titled "tasksel: Allow to select Blends selection during
installation - just 'DE', 'Web server', 'Mail server' is NOT enough".
This bug was created more than two years ago, and nowhere in the bug it
was questioned that the blends should be selectable during the
installation process. This, however, *requires* to have the information
about the blends available during installation, and this makes the
package that provides this information "important". Therefore, it is not
a policy violation, which in turn removes your argument to make this bug
"serious". It also does not "completely break the UI of the installer"
-- the selection is in no mean different from the desktop environment
selection. I would therefore propose to lower the severity of the bug.

Also, I would ask you to do an NMU until the discussion has settled
down. This would be an abuse of the NMU. NMUs are meant to deal with
unresponsive maintainers, and you did not show any evidence that the
blends maintainers are not responsive with respect to this problem.
Doing NMUs during a discussion is quite offending. I also don't see a
reason to hurry with implementing an unsettled decision: the blends
selection is there since almost 8 months now without any significant
change or discussion for ~6months. What makes the issue now so urgent
that you try to push this within four days? Why didn't you do this half
a year ago? We implemented the current solution at that time (and you
*knew* that we did) exactly to have some buffer for discussion about
critics. Why didn't you use that, but start now when it is quite late?

The next point is that you base your critics not on some experience with
the current installer but on an outdated, half-a-year-old screenshot.
Since then, several improvements were done, both in the appearance in
the installer, and in the selection of which blends are there. For the
first, see the discussion here:

https://lists.debian.org/debian-blends/2016/07/msg00027.html

We would also not include all blends there, but select them on an opt-in
base. So, if debian-edu is not useful to be installed that we, it shall
be removed. At the end, this will reduce the number of selectable blends
quite much.

I would therefore ask you to rebase your arguments on your experience
with the current implementation and not on something that is six months
old and not actual anymore.

Another point, concerning the argument of "confusing" users: As I said,
the blends-tasks package is in place now since eight months, with the
current implementation there since ~6 months. Since then there was no
single report that someone did not understand the options here -- no bug
report, nothing on the installer, blends, or devel mailing lists. I also
did an extensive search on the net, and the only thing I found is
mentioned in the discussion above and addressed by the changes made
after that. Since then, no single problem was reported, with more than
5000 installations according to popcon. This gives a good sign that the
addition of the blends to that menu does not confuse people, and I would
ask you to show a better empirical evidence that it does.

I will not discuss the arguments during the discussion in #758116 here
again -- there was a lengthy discussion about this, and the linked
postings were covered there as well. It makes no sense to repeat that
here again six months later.

Concerning your idea of having different install images, I am not
convinced that it is a good solution: First, it multiplies the whole
image creation process by the number of blends. If we have 10 official
architectures and (let's say) 5 blends to be included there, they would
then have to manage 60 images instead of 10, with all the requirements
that come out of this (installer manual, web page, updates, web space etc.).

But it also gives a wrong sign: Debian Pure Blends are by definition
integral part of Debian itself. But even now, this is hard to understand
for many people -- questions like "what is the difference between Debian
Astro and Debian" are quite common, even in front of a poster describing
exactly that. With having separate official images for all blends,
people would even be more confused. As an example, I would take the
Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
installation options -- people usually think that they have to
re-install the system if they want to switch from one flavour to the
other. Having similar experience with Debian would be bad for the
reputation of the Blends, and for Debian in general.

Best regards

Ole

Bug#844984: python-astropy: FTBFS: tests failures

[Ole Streicher]

Control: forwarded -1 https://github.com/astropy/astropy/issues/5460


I already opened a bug report upstream about this. However, I am not
sure whether this may an openssl-1.1 problem with Python; I don't see an
obvious bug in the astropy code here.

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas, Petter and all,


On 15.11.2016 07:09, Andreas Tille wrote:
> Hi,
>
> I just want to announce that I'll be de-facto offline today and
> tomorrow.  So I can not do further testing of the "Use of uninitialized
> value" testing.
>
> Kind regards
>
>   Andreas.
>
> On Fri, Nov 11, 2016 at 12:52:46PM +0100, Andreas Tille wrote:
>> Use of uninitialized value $_ in pattern match (m//) at
>> /usr/share/blends-dev/blend-gen-control line 568,  line 28.
>> [...]

I fixed this in the git. HOWEVER, again: I have no glue what I do here.
I just assume that "next unless defined $_" does more or less what it
means, and I hope it will do so as well in the line where I put it. Same
for "last if !defined $_". I used these two phrases just because they
are already somewhere else in the script. Anyone with Perl knowledge:
CHECK IT!

Cheers

Ole

Bug#845145: Please provide CI tests

[Ole Streicher]

Package: jsamp

Severity: wishlist

X-Debbugs-Cc: Paul Sladen 


Hi Paul,


since jsamp provides some unit tests, it would be useful to run them via
the Debian Continious Integration platform,

http://ci.debian.net

This would ensure that the package keeps in shape when the environment
(f.e. the Java version) changes.


Best regards


Ole

Bug#841610: statsmodels: FTBFS: TypeError: cannot sort an Index object in-place, use sort_values instead

[Ole Streicher]

Control: tags -1 patch

Upstream there is already a simple patch available for the TypeError:

https://github.com/statsmodels/statsmodels/pull/3239

For convenience, it is attached.

The IOErrors are gone with the newest Pandas version.

However, the ValueError do not disappear when adding tzdata to the
build-depends.
>From 22cc39f77059297a3ec22d68f1684efd65c433a5 Mon Sep 17 00:00:00 2001
From: thequackdaddy 
Date: Wed, 16 Nov 2016 14:25:19 -0600
Subject: [PATCH] Simplified commit

---
 statsmodels/tools/grouputils.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/statsmodels/tools/grouputils.py b/statsmodels/tools/grouputils.py
index 8e91bba..481ee99 100644
--- a/statsmodels/tools/grouputils.py
+++ b/statsmodels/tools/grouputils.py
@@ -403,6 +403,7 @@ def get_slices(self, level=0):
 """
 # TODO: refactor this
 groups = self.index.get_level_values(level).unique()
+groups = np.array(groups)
 groups.sort()
 if isinstance(self.index, MultiIndex):
 self.slices = [self.index.get_loc_level(x, level=level)[0]

Bug#844085: Please replace pyfits by astropy.io.fits

[Ole Streicher]

Source: pyscanfcs
Version: 0.2.3-2
Severity: wishlist
Tags: patch

Dear maintainer,

the package depends on the "python-pyfits" package which is obsolete
today and will not see any further development upstream. I am going to
create a bug against pyfits asking to remove it from Debian.

The "python-astropy" package is the designated successor and provides a
drop-in replacement for pyfits. The attached patch does the necessary
replacement.

Best regards

Ole

>From 3f4d5181a4ccfe42f50624ab801011991fa001d5 Mon Sep 17 00:00:00 2001
From: Ole Streicher <oleb...@debian.org>
Date: Sat, 12 Nov 2016 11:16:12 +0100
Subject: [PATCH] Use Astropy in place of Pyfits

---
 debian/control |  2 +-
 .../patches/Use-Astropy-in-place-of-Pyfits.patch   | 74 ++
 debian/patches/series  |  1 +
 3 files changed, 76 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/Use-Astropy-in-place-of-Pyfits.patch
 create mode 100644 debian/patches/series

diff --git a/debian/control b/debian/control
index feb5349..8c53ad6 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Build-Depends: python-setuptools,
python-matplotlib,
python-multipletau,
python-numpy,
-   python-pyfits,
+   python-astropy,
python-scipy,
python-wxgtk3.0,
imagemagick,
diff --git a/debian/patches/Use-Astropy-in-place-of-Pyfits.patch b/debian/patches/Use-Astropy-in-place-of-Pyfits.patch
new file mode 100644
index 000..86306b5
--- /dev/null
+++ b/debian/patches/Use-Astropy-in-place-of-Pyfits.patch
@@ -0,0 +1,74 @@
+From: Ole Streicher <oleb...@debian.org>
+Date: Sat, 12 Nov 2016 11:14:23 +0100
+Subject: Use Astropy in place of Pyfits
+
+Pyfits is obsolete and will not get any upstream updates anymore. It is
+replaced by Astropy which provides a drop-in-replacement as astropy.io.fits.
+---
+ freeze_pyinstaller/debian_ubuntu_bundle_script.sh | 2 +-
+ pyscanfcs/doc.py  | 4 ++--
+ pyscanfcs/main.py | 2 +-
+ setup.py  | 2 +-
+ 4 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/freeze_pyinstaller/debian_ubuntu_bundle_script.sh b/freeze_pyinstaller/debian_ubuntu_bundle_script.sh
+index eaf835c..135b063 100755
+--- a/freeze_pyinstaller/debian_ubuntu_bundle_script.sh
 b/freeze_pyinstaller/debian_ubuntu_bundle_script.sh
+@@ -41,7 +41,7 @@ if ! [ -e $Env ]; then
+ # Pyinstaller
+ pip install git+git://github.com/pyinstaller/pyinstaller.git@779d07b236a943a4bf9d2b1a0ae3e0ebcc914798
+ # PyFITS
+-pip install pyfits
++pip install astropy
+ fi
+ source $Env"/bin/activate"
+ 
+diff --git a/pyscanfcs/doc.py b/pyscanfcs/doc.py
+index 86131b5..ce05cc3 100755
+--- a/pyscanfcs/doc.py
 b/pyscanfcs/doc.py
+@@ -25,7 +25,7 @@ import multipletau
+ import numpy
+ import os
+ import platform
+-import pyfits
++import astropy
+ import scipy
+ import sys
+ 
+@@ -143,7 +143,7 @@ def SoftwareUsed():
+"\n - matplotlib "+matplotlib.__version__+\
+"\n - multipletau "+multipletau.__version__+\
+"\n - NumPy "+numpy.__version__+\
+-   "\n - PyFITS "+pyfits.__version__+\
++   "\n - Astropy "+astropy.__version__+\
+"\n - SciPy "+scipy.__version__+\
+"\n - uilayer "+uilayer.__version__+\
+"\n - wxPython "+wx.__version__
+diff --git a/pyscanfcs/main.py b/pyscanfcs/main.py
+index 78c4f80..31e9da1 100755
+--- a/pyscanfcs/main.py
 b/pyscanfcs/main.py
+@@ -57,7 +57,7 @@ import matplotlib.pyplot as plt
+ import multipletau
+ 
+ import numpy as np# NumPy
+-import pyfits
++import astropy.io.fits as pyfits
+ from scipy.fftpack import fft
+ from scipy.fftpack import fftfreq
+ # SFCSnumeric needs scipy.optimize
+diff --git a/setup.py b/setup.py
+index 46a8709..baa6337 100644
+--- a/setup.py
 b/setup.py
+@@ -65,7 +65,7 @@ setup(
+ "matplotlib >= 1.1.0",
+ "multipletau >= 0.1.4",
+ "NumPy >= 1.5.1",
+-"pyfits",
++"astropy",
+ "SciPy >= 0.8.0",
+ "wxPython >= 2.8.10.1"
+ ],
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..7b7c503
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+Use-Astropy-in-place-of-Pyfits.patch
-- 
2.10.2

Bug#844087: Please consider removing pyfits

[Ole Streicher]

Source: pyfits
Severity: wishlist
Control: block -1 by 844085

Dear Aurelien,

as I wrote on the debian-astro mailing list, I am planning to remove
pywcs because it is completely obsoleted by astropy. The same argument
is however valid for pyfits, which also will not see any upstream love
anymore.

IMO the release of Stretch is a good opportunity to force the users into
the use of astropy, especially as it is as easy as replacing

import pyfits

by

import astropy.io.fits as pyfits

Pyfits has three reverse dependencies (astlib, python-cpl, and
pyscanfcs), with the first to being optional (first option there is
astropy already). For pyscanfs, I files a bug #844085 asking to switch
to astropy.

Once they did the warp, would you also consider to remove? IMO that
would help to keep Debian clean from obsolete packages.

Best regards

Ole

Bug#842931: ITP: casacore-data-jplde -- Jet Propulsion Laboratory Development Ephemeris for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-jplde
* URL : ftp://ssd.jpl.nasa.gov/pub/eph/planets/ascii/
* License : Public domain
  Description : Jet Propulsion Laboratory Development Ephemeris for
casacore

The name Jet Propulsion Laboratory Development Ephemeris are a series of
models of the Solar System produced at the Jet Propulsion Laboratory in
Pasadena, California, primarily for purposes of spacecraft navigation
and astronomy. The package will include the
`DE200` and `DE405` tables for casacore.

The package is a part of the effort taken by Benda Xu and me within the
Debian Astro team to split up the original "casacore-data" package (RFP
#761146) by data source into smaller packages which can be maintained
independently.

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-jplde.git

Best regards

Ole

Bug#842925: ITP: casacore-data-igrf -- International Geomagnetic Reference Field data for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-igrf
  Version : 10 or 12
* URL : http://www.ngdc.noaa.gov/IAGA/vmod/igrf.html
* License : Public domain
  Description : International Geomagnetic Reference Field data for
casacore

This package contains the coefficients for the standard mathematical
description of the Earth's main magnetic field that is used widely in
studies
of the Earth's deep interior, its crust and its ionosphere and
magnetosphere.

The package is a part of the effort taken by Benda Xu and me within
the Debian Astro team to split up the original "casacore-data" package
(RFP #761146) by data source into smaller packages which can be
maintained independently.

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-igrf.git

Best regards

Ole

Bug#842935: ITP: casacore-data-tai-utc -- Difference table between TAI and UTC for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-tai-utc
* License : BSD-2-Clause
  Description : Difference table between TAI and UTC for casacore

This native package contains the leap second difference between TAI and
UTC, created from /usr/share/zoneinfo/leap-seconds.list. The data are in
a format specific to casacore. The table is kept in sync with the tzdata
package.

The package is a part of the effort taken by Benda Xu and me within the
Debian Astro team to split up the original "casacore-data" package (RFP
#761146) by data source into smaller packages which can be maintained
independently.

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-tai-utc.git

Best regards

Ole

Bug#842934: ITP: casacore-data-predict -- Earth orientation parameter prediction tables for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-predict
* URL : http://maia.usno.navy.mil/
* License : Public domain
  Description : Earth orientation parameter prediction tables for
casacore

The IERS Prediction tables provide predictions for the time-varying
orientation of the terrestrial reference frame within the quasi-inertial
celestial reference frame for casacore.

The package will contain the `IERSpredict` and `IERSpredict2000` tables
for casacore.

The package is a part of the effort taken by Benda Xu and me within the
Debian Astro team to split up the original "casacore-data" package (RFP
#761146) by data source into smaller packages which can be maintained
independently.

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-predict.git

Best regards

Ole

Bug#842933: ITP: casacore-data-eop -- Earth Orientation Parameters database for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-eop
* URL : https://hpiers.obspm.fr/iers/eop/eopc04/
* License : Public domain
  Description : Earth Orientation Parameters database for casacore

The Earth Orientation Parameters (EOP) describe the irregularities of
the Earth rotation with respect to a non-rotating reference frame.

The package will contain the `IERSeop97` and `IERSeop2000` tables for
casacore.

The package is a part of the effort taken by Benda Xu and me within
the Debian Astro team to split up the original "casacore-data" package
(RFP #761146) by data source into smaller packages which can be
maintained independently.

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-eop.git

Best regards

Ole

Bug#842936: ITP: casacore-data-observatories -- Table of radio observatory coordinates for casacore

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: casacore-data-observatories
  Version : 1.0
* URL : https://github.com/casacore/observatory-table
* License : Public domain
  Description : Table of radio observatory coordinates for casacore

This package contains a table with radio observatories and their
coordinates for the use with casacore. The data is initially taken from
Wikipedia, but will be incrementally replaced with verified coordinates.

The package is a part of the effort taken by Benda Xu and me within the
Debian Astro team to split up the original "casacore-data" package (RFP
#761146) by data source into smaller packages which can be maintained
independently.

The package will be maintained on our git repository under

https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-igrf.git

Best regards

Ole

Bug#842936: ITP: casacore-data-observatories -- Table of radio observatory coordinates for casacore

[Ole Streicher]

Hi Jonathan,

this package is just one of the standard tables that are available in
casacore. Unfortunately, the original table is maintained in a somehow
intransparent way at NRAO and ASTRON (looks both institutes maintain it
separately), with no "source" available, and without a clear license
attached. Also this original list seems to be old (2007?), buggy (f.e.
https://github.com/casacore/casacore/issues/304), and incomplete (often
some coordinates are missing).


To have an open start here, I compiled a list of telescopes and their
coordinates from Wikipedia. The list is obviously not very accurate yet,
but I hope that we can improve that from public references as time goes.
If you can point me to reference geolocations of the VLBI network
observatories, that would be really helpful. However, for the effects
you describe I am bound to what casacore can take (which is just a plain
coordinates in WGS-84 and x/y/z).


Best regards


Ole



On 02.11.2016 13:24, Jonathan Quick wrote:
> Hi Ole
>
> On Wed, November 2, 2016 2:09 pm, Ole Streicher wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Ole Streicher <oleb...@debian.org>
>> X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org
>>
>> * Package name: casacore-data-observatories
>>   Version : 1.0
>> * URL : https://github.com/casacore/observatory-table
>> * License : Public domain
>>   Description : Table of radio observatory coordinates for casacore
>>
>> This package contains a table with radio observatories and their
>> coordinates for the use with casacore. The data is initially taken from
>> Wikipedia, but will be incrementally replaced with verified coordinates.
> At the highest accuracy, these antenna coordinates are functions of time due
> to plate techtonics, with global solutions published at semi-regular intervals
> as the ITRF (International Terrestrial Reference Frame).  Depending on their
> usage within casacore, you may/may not need such accuracies.
>
> Regards
> Dr. Jonathan Quick
> VLBI Operations Manager, HartRAO
>

Bug#842935: ITP: casacore-data-tai-utc -- Difference table between TAI and UTC for casacore

[Ole Streicher]

Hi Jonathan,


the original casacore package takes these data from usno; however after
some discussion in debian-science I was convinced that tzdata is
reliably enough for our use:

https://lists.debian.org/debian-mentors/2016/10/msg00494.html

Best regards

Ole


On 02.11.2016 13:37, Jonathan Quick wrote:
> Hi Ole
>
> On Wed, November 2, 2016 2:08 pm, Ole Streicher wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Ole Streicher <oleb...@debian.org>
>> X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org
>>
>> * Package name: casacore-data-tai-utc
>> * License : BSD-2-Clause
>>   Description : Difference table between TAI and UTC for casacore
>>
>> This native package contains the leap second difference between TAI and
>> UTC, created from /usr/share/zoneinfo/leap-seconds.list. The data are in
>> a format specific to casacore. The table is kept in sync with the tzdata
>> package.
> Technically the canonical source for this information is the Bulletin C issued
> by the IERS at roughly six monthly intervals.  I hope the leap-seconds.list is
> maintained in reference to those.
>
> Regards
>   Jon
>

Bug#842934: ITP: casacore-data-predict -- Earth orientation parameter prediction tables for casacore

[Ole Streicher]

Hi Jonathan,


the package will for sure only contain the prediction for one moment and
will be probably outdated when the package reaches the user. However, it
will come with a script that can fetch and convert the current data,
with the possibility to run this via cron or such. Therefore, the
package will have the current data, if the user needs it.


Best regards


Ole


On 02.11.2016 13:34, Jonathan Quick wrote:
> Hi Ole
>
> On Wed, November 2, 2016 2:07 pm, Ole Streicher wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Ole Streicher <oleb...@debian.org>
>> X-Debbugs-CC: debian-de...@lists.debian.org, debian-as...@lists.debian.org
>>
>> * Package name: casacore-data-predict
>> * URL : http://maia.usno.navy.mil/
>> * License : Public domain
>>   Description : Earth orientation parameter prediction tables for
>> casacore
>>
>> The IERS Prediction tables provide predictions for the time-varying
>> orientation of the terrestrial reference frame within the quasi-inertial
>> celestial reference frame for casacore.
>>
>> The package will contain the `IERSpredict` and `IERSpredict2000` tables
>> for casacore.
> These tend to be moving goal posts.  Post-analysis of VLBI sessions (and
> related space geodetic techniques) gives measurements of EOPs (which are
> unknown functions of time due to myriad torques applied to the earth by wind,
> ocean, other bodies, human activities etc.)  The predictions are just that, an
> estimate at a point in time of the future evolution of these parameters which
> is subsequently obsoleted by the actual measurements.  Hence packaging these
> predictions would be of little value, and by their nature, the further into
> the future one predicts, the less accurate they become.
>
> Regards
>   Jon
>> The package is a part of the effort taken by Benda Xu and me within the
>> Debian Astro team to split up the original "casacore-data" package (RFP
>> #761146) by data source into smaller packages which can be maintained
>> independently.
>>
>> The package will be maintained on our git repository under
>>
>> https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-predict.git
>>
>> Best regards
>>
>> Ole
>>
>>
>>
>

Bug#840473: cfitsio: new upstream version

[Ole Streicher]

Aurelien Jarno:
> Florian Schlichting:
>> a new upstream version of cfitsio was released in April 2016. Would you
>> consider packaging it?
> 
> Yes, I am aware of that. Unfortunately it introduces yet another soname
> changes, which make things a bit more complicated.

Since there is a transition freeze effective from 2016-11-05 [1], this
should IMO be addressed ASAP. For the packages under Debian Astro
maintenance, I could offer help here.

Could you specify where you expect the complications?

BTW, I would recommend to put cfitsio under Debian Astro team
maintenance, due to the importance of the package. Would you be willing
to do that?

Best regards

Ole

[1] https://wiki.debian.org/DebianStretch

Bug#837232: statsmodels: FTBFS: Tests failures

[Ole Streicher]

DearYaroslav,

could you ensure that the "statmodels" package migrate to testing, so
that the dependent packages will not be removed?

The package is uninstallable of a number of platforms in the new
release, so they should probably removed from testing.

Best regards

Ole

Bug#840589: Questioning severity of the bug

[Ole Streicher]

Hi Peter,

could you explain why you think this is of severity "serious"? In my
opinion, FTBFS should be "important" as long as there is at least one
useful architecture.

The definition for important is:

"a bug which has a major effect on the usability of a package, without
rendering it completely unusable to everyone."

which fits to the situation: there *are* still people to which the
package is usable (namely the ones which use the architectures where it
works).

IMO it is up to the maintainer's decision to fix the FTBFS here, or to
remove the failing archs from Debian to let the package pass to testing.

So, if you not oppose to, I would lower the severity and make it non-RC.

Best regards

Ole

Bug#840986: Please update to 0.9.0

[Ole Streicher]

Package: src:glueviz/0.8.2-1
Severity: wishlist

Hi,

I am just following the tutorial for glue on the ADASS, and upstream
(Tom Robitaille) showed some great new features for  0.9 (mainly 3d).

It would be worth upgrading to 0.9, definitely ;-)

Cheers

Ole

Bug#840589: Questioning severity of the bug

[Ole Streicher]

Hi Julien,

On 16.10.2016 18:30, Julien Cristau wrote:
>   Packages must autobuild without failure on all architectures on
>   which they are supported. Packages must be supported on as many
>   architectures as is reasonably possible. Packages are assumed to
>   be supported on all architectures for which they have previously
>   built successfully. Prior builds for unsupported architectures
>   must be removed from the archive (contact -release or ftpmaster
>   if this is the case).
> 
> As skimage no longer builds on architectures where it used to build (and
> where it thus is assumed to supported), the "serious" severity for this
> bug is correct.

Yea, but it is on the decision of upstream and maintainer which
platforms are supported by the package. If the maintainer is not able
(or willing) to support the platforms that FTBFS, why shouldn't he
remove them?

Best

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

On 08.12.2016 09:33, Wouter Verhelst wrote:
> On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
>> But it also gives a wrong sign: Debian Pure Blends are by definition
>> integral part of Debian itself. But even now, this is hard to understand
>> for many people -- questions like "what is the difference between Debian
>> Astro and Debian" are quite common, even in front of a poster describing
>> exactly that. With having separate official images for all blends,
>> people would even be more confused. As an example, I would take the
>> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
>> installation options -- people usually think that they have to
>> re-install the system if they want to switch from one flavour to the
>> other. Having similar experience with Debian would be bad for the
>> reputation of the Blends, and for Debian in general.
> 
> I don't agree with this argument.
> 
> Yes, indeed, in Ubuntu people often don't know that they don't really
> need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
> that really a problem?

Yes. In the whole 12 years of Ubuntu, they didn't succeed to make clear
that [KXG]Ubuntu is not different from Ubuntu except for the package
selection. I don't know how important it is for them to keep the unity
-- maybe they don't care here much.

But for Debian Pure Blends, it is important to have it clear that the
Pure Blends are just plain ("Pure") Debian. We don't just use the Debian
infrastructure to do something else -- we are an integrated part.
DebianMed and Debian Astro are in no way different from Debian, and if
you have Debian, then you have the Debian Pure Blends as well: it is
just a matter of package selection (and, ofcourse, mainly having the
special packages for our fields available).

And I still think that it would be horrible, if someone wanting to
switch to or from a Pure Blend would feel the need of re-installing.

The argument of wanting more than one blend installed at the same time
(not so rare within interdisciplinary teams) comes on top of that.

> It's certainly *easier* for users to understand that if they want X, Y,
> or Z, they just need to install from the X, Y, or Z image.

So, if they want KDE, they should just need to install a KDE Debian image?

The idea of the Debian Pure Blends is much similar to the idea of the
Desktop environments: There is no "KDE Debian", there is "just" a K
Desktop Environemnt in Debian. Similarly, the is no "Astro-Debian".
There is just a useful environment for astronomers in Debian.

And, having extra images per blend would multiply the number of images
we have to maintain. Instead of 10 official architectures, we would have
10 + 10 * number_of_blends. Possibly again multiplied by the number of
desktop environments, if we apply the same argument to them.
I am not sure that the cdimage team would be happy about this.

> I don't buy that presenting users with a choice of image to download
> "confuses" them, when it in fact *takes away* a very confusing menu from
> the installer. 

I would again ask to present some empirical data that adding the Blends
menu is "very confusing". The menu is there since quite a while, and it
was presented to many people, and we usually *do* get a response if
nobody understands the installation process. So, where are the complaints?

After eight months of testing, we can compare the fears here with the
collected experience. And this just doesn't support the fears.

> I think it's going to be obvious to people that if you
> download, say, a Debian Med image, you're going to have a different
> experience than if you download a "plain vanilla" Debian image; and
> that's *certainly* going to make things easier for Debian Med users,
> too.

The experience when installing Debian Astro is just Debian. It only adds
a useful selection of software on top of that, so that you immediately
can start your research, but aside from that everything is as everywhere.

So, the difference here is even less than the difference in experiencing
different desktop environments.

And my experience is that it is easier if people ask about how to
install Debian Astro, I can tell "Just select it in the last step of the
normal installer", instead of "Go to our home page, download a separate
image from there, and install this". It actually makes much difference
if the users can "feel" that they are just inside Debian, and not in a
special distribution.

Best regards

Ole

Bug#846197: cpl-plugin-xshoo: FTBFS randomly (tests 126 and 230 fail)

[Ole Streicher]

Hi Santiago,

OK, I have run it ~15 times without problems last time. I however just
disabled the wrong of the two errors (one causes the other), so I switch
this now.

However, after digging into the code, the failure looks mystic, since
the number there is just created from a substring "0.9x11" by taking
everything left of the x, and then divided by 3600. The string is fixed
in the test. It looks like that there sometimes an additional digit
slips in, but in one case (20161207T200220Z) the extraction results in
25000 instead of 0.00025. Really strange. But I don't feel that I can do
much here (it is already forwarded). Upstream is informed, however.

So, I disabled the (now hopefully right) test, and the package could be
built now 40 times in a row without failure.

Thumbs crossed :-)

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

On 08.12.2016 18:27, Raphael Hertzog wrote:
> - trying to keep blends-tasks now because we have no better option on the
>   table right now is not a good move either. Had you not circumvented the
>   d-i review at the time you introduced blends-tasks, then maybe you could
>   have advertised the limitation of tasksel and we could have found sooner
>   someone willing to fix this even if nobody in the blends team had the
>   required skills...

The current solution was announced in bug #758116, which at that time
was assigned to tasksel, so you will find it in your mail archive. In
this bug, there is also a discussion about the limitations of tasksel
(starting in 2014, which is probably soon enough!), and also some
statements from the d-i team that they will probably not have time to
implement something here.

There is (and was) no circumvention of a d-i review. The menu is
available, and you can always review it and file a bug if it has a
problem -- like for any other aspect in Debian. This didn't happen for
the blends-tasks package so far. This shows that either the problems
were not big enough, or that d-i just had no time to do so. In the
latter case, I don't see why d-i would have more time if the tasks menu
would be in tasksel-data.

In my opinion it *is* a good idea to spread responsibilites; especially
when one team is overloaded and the topic fits so well into the field of
another team. And I see no advantage to move the responsibility of the
blends submenu back from the blends team to d-i.

> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
> 
> Install packages for a:
> 
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options
> 
> You only see "tasksel" if you check the "Show me more options" which
> should be unchecked by default. There's code that translates each option
> into default selections at the tasksel level.

If this could be implemented in Stretch, it would be a good compromise.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Phil,

On 10.12.2016 01:03, Philip Hands wrote:
> Just to test things out, if one adds:
> 
>   url=hands.com/d-i/bug/846002/preseed.cfg
> 
> to the kernel command line (so, hitting TAB as the installer's boot menu)
> it will tweaks d-i to have such a menu.

To me, this looks like a very nice solution! In the tasksel screen, the
"back" button was enabled for the first time, but produced an error and
brought me back to the list of installation steps.

Going through the sofware selection a second time made the back button
disappear. I have absolutely no experience with preseeding, so I can't
test it more than the interactive use case.

The advantage of your solution is that one doesn't need to touch tasksel
itself, which may address Cyrils doubts. And since Holger also seems to
be happy with this solution: maybe we could focus on this in the further
discussion?

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important

[Ole Streicher]

Hi Michael,

On 10.12.2016 14:48, Michael Biebl wrote:
> Am 10.12.2016 um 14:15 schrieb Ole Streicher:
>> Hi Michael,
>>
>> On 10.12.2016 13:18, Michael Biebl wrote:
>>> While I have no opninion on whether blend-tasks is important enough to
>>> have installed by default,  I would urge to revisit the idea to (mis)use
>>> the package priority to achieve that.
>>
>> That is the standard way how tasksel gets its menu: tasksel-data is
>> marked as "important" and that way it finds its way onto the installer
>> image. So, all arguments you have here are also valid for the default
>> tasks. If we think this is wrong, we should get a completely different
>> solution here -- which is IMO outside of the scope of this bug.
> 
> Well, two wrongs don't make one right.

If we would remove one of them, the other would still stay there, and
the problem remains.

> An obvious solution seemed to me, to make tasksel(-*) depend on
> blends-tasks. This why, the package would be marked as auto-installed,
> and should you later decide to implement that differently, say directly
> in tasksel, then tasksel can simply drop that dependency.

The disadvantage is that people can't uninstall the blends task. And at
least Holger clearly indicated that he wants to have this option.

> I assume though you have considered this obvious solution and decided
> against it for some reason?

The major reason is that during the discussion of the blends into
tasksel became clear that the tasksel maintainers are already
overloaded. Having to manage the blends tasks here would put another
work on top of that. Additionally, they have no competence in deciding
neither which blends should go in, nor about how to describe them. This
all done by the Blends team. So, it seems to be natural for me to have
the blends tasks maintained by this team, and not by the tasksel developers.

In principle, the same would be applicable for the desktop selection,
however there seems to be no dedicated team for the desktop.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Phil,

On 10.12.2016 12:06, Philip Hands wrote:
> Anyway, having done it, my first impression (which I'm surprised by) is
> that the list is too short -- I think that it is perhaps because it is
> much easier to select one option from a list than it is to decide what
> combination of options one wants.

My feeling is exactly the opposite: the having the two most prominent
options there is (if they have good names), with the "90% standard"
preselected seems simple enough; in the discussion of this bug there was
even the proposal (as I remember) to have just *one* option, which also
would not be too bad: Most people probably don't care here anyway to
select something, and just having *one* checkbox here would give room
for a detailed explanation what is going to be installed then.

Then, even the "server" would move to the "extended" selection --
servers are usually installed by more experienced users which can deal
with more options.

In any case, I would like to hear the opinion of Cyril or other d-i
people here.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important

[Ole Streicher]

Hi Michael,

On 10.12.2016 13:18, Michael Biebl wrote:
> While I have no opninion on whether blend-tasks is important enough to
> have installed by default,  I would urge to revisit the idea to (mis)use
> the package priority to achieve that.

That is the standard way how tasksel gets its menu: tasksel-data is
marked as "important" and that way it finds its way onto the installer
image. So, all arguments you have here are also valid for the default
tasks. If we think this is wrong, we should get a completely different
solution here -- which is IMO outside of the scope of this bug.

> If a package was pulled in by debootstrap because of its priority, it's
> marked as manually installed.
> This is usually bad, because say later on you decide that you want to
> change the name of the package or implement this differently, the
> manually installed package sticks around.

But this problem is true for all manually installed package, right? So,
a manually installed iceweasel would have a renaming problem as well.
Couldn't it be solved by a transitional package?  I would also consider
this as not being release critical.

The current solution would also have the advantage that people who
actually hate the blends task list (like Holger Levsen: "I will get used
to type 'apt remove blends-tasks' as well.") have the possibility to
remove that from the tasks selection list. So, this would probably have
more acceptance than a solution where the blends tasks are glued into
the main task selection.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

On 09.12.2016 08:37, Philip Hands wrote:
>> On Wed, 07 Dec 2016, Philip Hands wrote:
>>> It could be much improved by making it more obvious that the heading is
>>> a heading.  Even if we're unable to stop headings having a checkbox, we
>>> could change the text and the hierarchy slightly to be something like
>>> this:
>>>
>>> [ ]  === Debian Desktop Environments:
>>> [x]  ... Gnome
>> [...]
>>> Would that cheer people up without needing a major rewrite of tasksel?

This improves the situation, and could probably done quite simple at the
same place where the ellipsis (...) is introduced:

https://sources.debian.net/src/tasksel/3.38/tasksel.pl/#L360-L366

One just needs to find out here that it is actually a heading.

> I think that should be a select, rather than a multi-select:
> 
>  -->  standard desktop (will install $DESKTOP)  <--
>   standard server  (includes ssh)
>   other use cases
> 
> (or however the UI presents it)
> 
> The reason for the extra bits in brackets is that I've always thought
> the tasksel menu was hiding just a little too much of what was meant by
> the options.

I would vote for that, however we would need

1. someone willing *and* competent (the latter excludes myself) to
implement this in tasksel,

2. someone convincing Cyril that this is ready to go into Stretch:

On 08.12.2016 23:20, Cyril Brulebois wrote:
> While it's clear to me we need to fix the blends situation at some point
> before the release (couldn't find time to do so yet; last resort option
> is masking all of them entirely), I'm rather dubious about changing the
> package selection/tasksel screen at this point of the release cycle.

Volunteers for any of those tasks?

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important

[Ole Streicher]

Hi again,

sorry: missed one point:

On 10.12.2016 15:07, Ole Streicher wrote:
> On 10.12.2016 14:48, Michael Biebl wrote:
>> An obvious solution seemed to me, to make tasksel(-*) depend on
>> blends-tasks. This why, the package would be marked as auto-installed,
>> and should you later decide to implement that differently, say directly
>> in tasksel, then tasksel can simply drop that dependency.
>> I assume though you have considered this obvious solution and decided
>> against it for some reason?

If you mean here why we just didn't put blends-tasks as dependency into
tasksel-data: this wouldn't help, since the Policy says (§2.5):

"Packages must not depend on packages with lower priority values"

Since tasksel-data is Priority: important, blends-tasks would need to
have this priority as well.

Ole

Bug#848112: Python-skimage depends on unavailable package python-dask

[Ole Streicher]

package: python-skimage
version: 0.12.3-2
severity: serious

The Python 2 version of skimage depends on a package "python-dask" that
is not available in Debian.

There is a patch that make the dependency optional; however the
dependency was not removed afterwards. For Python 3, this seems to work.

Since skimage is one of the central packages, I would again ask to put
it under science|python team maintenance. Especially when under some
time pressure (upcoming freeze, combined with autoremovals of packages)
it would help a lot if the problems could be debugged within a standard
Debian developer workflow, without the need to switch to github or so.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Philip,

On 06.12.2016 20:43, Philip Hands wrote:
> Could we serve their needs with an extra debian-installer/blend 
> preseed to deal with this, probably aliased as just 'blend' so that 
> one could type something like:
> 
> blend=med
> 
> when booting the default media to get the desired result?

I think this is really unergonomic, since people need to understand or
remember installer boot time options. Boot prompt options are magic for
many users, and they need to read the documentation to get this.

And it is not recoverable: imagine that someone forgets to put it there
or made a typo, he cannot go back and change this -- he has to go
through the full installation process again.

And it does not really *present* the blends to the user; he already
needs to know what is there.

> If we then made the ISOs easy to tweak, so that the default option
> on the Debian-Med ISOs included blend=med on the command line by 
> default, would that actually be better than what we have, and also 
> allow us to drop the problematic tasksel items?

Since I already answered this, I hope it is OK to just copy my old
argument here:

I am not convinced that it is a good solution: First, it multiplies the
whole image creation process by the number of blends. If we have 10
official architectures and (let's say) 5 blends to be included there,
they would then have to manage 60 images instead of 10, with all the
requirements that come out of this (installer manual, web page, updates,
web space etc.).

But it also gives a wrong sign: Debian Pure Blends are by definition
integral part of Debian itself. But even now, this is hard to understand
for many people -- questions like "what is the difference between Debian
Astro and Debian" are quite common, even in front of a poster describing
exactly that. With having separate official images for all blends,
people would even be more confused. As an example, I would take the
Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
installation options -- people usually think that they have to
re-install the system if they want to switch from one flavour to the
other. Having similar experience with Debian would be bad for the
reputation of the Blends, and for Debian in general.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Tollef,

On 06.12.2016 17:04, Tollef Fog Heen wrote:
> ]] Ole Streicher 
> 
>> On 06.12.2016 10:37, Holger Levsen wrote:
>>> And this *is* still pretty confusing, though admitly better than it was
>>> half a year ago. 
>>
>> The current implementation has a popcon of >5000, without a single
>> complaint or confusion documented in the web within the last six months.
>> This is at least *some* empirical evidence that it is not "pretty
>> confusing", and again I would ask you to show any better empirical data
>> here to support your own point.
> 
> It's confusing enough that when I've had engineers from a provider
> install Debian for me, I have ended up with a desktop rather than server
> installation.  Should I have filed a bug about it?  Maybe.

I think you should, since this is the preferred way to let the
maintainer know about problems. This is even more true for prereleases
like alpha6 ff., since they depend on bugreports to get finished properly.

But this is not (completely) what I mean: I didn't only check for bug
reports, but also for help requests or comments. And the status is:
nobody had so much difficulties with the additional choices, that he
asked what to do. So, although the current way has been used by many
people, no difficulty was documented (with the exception I already
mentioned).

> I think it would be better if we moved most of tasksel out of the
> installer entirely and had an app store of some sort where applications
> and blends could all be better presented with screenshots and
> all. 

I disagree here: the installer is a kind-of assistent which leads you
through the installation process. It is much easier, even for me, to
follow these steps than to need to remember to start the app store
afterwards.

BTW, tasksel is able to do both: it is called from the installer, but
also max be called afterwards to change the selection if needed. IMO
this is the optimal way to interact with the user. It is just the
implementation that is hopelessly outdated.

> Again, I don't know how feasible it is to end up with a better design
> for stretch, but I don't think the current design is particularly
> scalable and should be replaced for buster.

Fully Ack. I see the current solution to integrate the Blends in Stretch
as a compromise for Stretch only; afterwards we should look to rewrite
tasksel for a better scalability.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

On 06.12.2016 20:13, Tollef Fog Heen wrote:
> Debconf has support for pluggable UI widgets, so somebody could do this
> without _too_ much work in the graphical version if they wanted, with
> fallback code for the curses and text versions.

In principle, you are true. One of the reasons that I pushed the
debian-blends-tasks.desc in spring already was that we can see whether
this solution is a good compromise, of if we need to do further changes.

For the moment, I don't see pluggable UI widgets as an option anymore:
this would either mean to rewrite much of tasksel, or to add another
step (--> a new program/package) to the installer. With the ongoing
freeze, this doesn't sound realistic. For Buster, we should think about
a significant tasksel change, however.

Best regards

Ole

Bug#846197: cpl-plugin-xshoo: FTBFS randomly (tests 126 and 230 fail)

[Ole Streicher]

Control: forwarded -1 PIPE-6911
Control: tags -1 unreproducible

Hi,

I forwarded the problem to ESO, for reference it gets there the issue
number PIPE-6911. Their ticket system is however internal only, so that
I can't give an URL here.

I also tried to reproduce the problem, but was not successful: More than
10 builds (cowbuilder, x86_64, stretch) in a rowwere OK, without a
single failure.The same for sid. Therefore, I also do not expect that
upstream can do much here.

I will disable the test in the moment, but re-enable it when there is a
new upstream version. Please re-open if you then still encounter the
problem.

Best regards

Ole

Bug#847970: sunpy FTBFS in stretch due to missing skimage

[Ole Streicher]

Hi Adrian,

I do not completely understand what the goal of this bug is: The missing
build dependency is already noted in the package, and an autoremoval is
filed (and sent out to me as the maintainer). So, I am already noted by
the problem, and I don't see what the additional bug gives here except
the need to close one RC bug more.

Wouldn't it be simpler just to mark #840589 as "affects: src:sunpy"?

Best regards

Ole

On 12.12.2016 17:59, Adrian Bunk wrote:
> Source: sunpy
> Version: 0.7.4-1
> Severity: serious
> Tags: stretch sid
> Control: block -1 by 840589
> 
> node-yargs build-depends on python{,3}-skimage,
> which is not in stretch due to #840589
> 

Bug#850966: Please support ftp search with version number only in the directory name

[Ole Streicher]

Package: devscripts
Severity: wishlist
User: devscri...@packages.debian.org
Usertags: uscan


I have the following sample download URL

ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v3.0-9/stilts_src.zip

Corresponding Debian version number should be 3.0.9.

There is currently no way to get this downloaded via uscan. I tried

version=3
options="uversionmangle=s/\-/./,filenamemangle=s/\/$/.zip/" \
ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v([\d\.\-]+)/ stilts_src.zip

but it doesn't work; basically it adjusts upstream version to be 1:

uscan info: Newest upstream tarball version selected for download 
(uversionmangled): 1

Bug#850966: Please support ftp search with version number only in the directory name

[Ole Streicher]

Hi Ben,

Am 12.01.2017 um 09:22 schrieb Ben Finney:
> Ole Streicher <oleb...@debian.org> writes:
> How would you expect this to work?

one way could be: uscan could check the dir

ftp://andromeda.star.bris.ac.uk/pub/star/stilts/

for all dirs matching v([\d\.\-]+),

compare with d/changelog (by using uversionmangle),
search for the most recent version between the newer ones,
then download from that dir the file specified in the second
part (stilts_src.zip), and rename it using fileversionmangle 
(so to v3.0-9.zip in the example).

> You're right. The only information UScan can use, is what information is
> in the response document. It needs a *single* document with *all* the
> relevant versions, as links in the document.

if the second component (the file name) does not contain a
grouped regexp, it could just be added to the directory link
in the first document.

Another way would be to use only one URL:

ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v([\d\.\-]+)/stilts_src.zip

If there is a directory component *after* the grouped regexp, split it into 
three parts:

* Base URL for directory, ftp://.../star/stilts/
* Regexp for the directory search and version extraction, v([\d\.\-]+)/
* suffix path to add for download, stilts_src.zip

> How would you propose UScan should detect all the relevant versions?
> What URL will respond with a document containing the complete list of
> versioned links?

See above.

Does this make sense?

Best regards

Ole

Bug#846002: Debian Installer Stretch RC 1 release

[Ole Streicher]

On 15.01.2017 05:21, Cyril Brulebois wrote:
> The Debian Installer team[1] is pleased to announce the first release
> candidate of the installer for Debian 9 "Stretch".
> 
> 
> Important changes in this release of the installer
> ==
> 
>  * [...]
>  * As noted in the Stretch Alpha 6 release announcement, Debian Pure
>Blends appeared in the Software selection screen. Unfortunately,
>concerns voiced back then weren't worked on until after the freeze
>started, and a freeze isn't the time where critical screens should
>be revamped. Support was disabled accordingly.

Since this is still an open discussion in #846002, I would have
preferred if you would not try to force your own preference here before
the CTTE made its decision. IMO your solution is not in any way
cooperative and tries to make the CTTE decision useless.

I therefore would ask the CTTE to make a final decision about the
inclusion of the blends selection in the Stretch installer. In principle
these are *two* decisions:

1. Appearance of the blends in the installer:

Please decide, whether

 * the blends shall be shown in their current (alpha-8) form

 * The installer is extended to show the desktop and the blends only
   optionally (as propagated by Phil, and opposed by Cyril)

 * the blends should not appear in the Stretch installer at all.

2. Maintenance of the blends tasks appearing in the installer:

 * in a separate package maintained by the blends team

 * integrated into tasksel and maintained by d-i

 * be removed completely from the installation process

Best regards

Ole

Bug#851437: astroplan: FTBFS (requires Internet to build)

[Ole Streicher]

The problem here is that with astropy-1.3, doctests are buggy:

https://github.com/astropy/astropy/issues/5670

A workaround currently is to disable doctests during the build:

python$* setup.py test --skip-docs -vv --args -v

Cheers

Ole

Bug#846363: Please let casacore-data-tai-utc migrate

[Ole Streicher]

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

The package casacore-data-tai-utc is currently stuck in unstable because
of an unsatisfiable Depends:

excuses:
 * 12 days old (needed 10 days)
 * casacore-data-tai-utc/i386 unsatisfiable Depends: python3-casacore
 * Valid candidate

The package is useful on (some) other archs, however, and will become
useful on i386 as soon as the FTBFSs are fixed. Therefore I would ask to
force the package migration.

Thanks

Ole

Bug#846539: ITP: gwcs -- Tools for managing the World Coordinate System of astronomical data

[Ole Streicher]

Dear Miguel,

would you mind to put the packaging under Debian Astro team maintenance?
This would make contributions of others easier, and we would also help
you with questions and finally sponsor the package when it is ready.

On 01.12.2016 23:56, Miguel de Val-Borro wrote:
> * Package name: gwcs
>   Version : 0.5.1
>   Upstream Author : Nadia Dencheva 
> * URL : https://github.com/spacetelescope/gwcs
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : Tools for managing the World Coordinate System of 
> astronomical data
> 
> GWCS supports a data model which includes the entire transformation pipeline
> from input coordinates to world coordinates.  The goal of the package is to
> provide a flexible toolkit which is easily extendible by adding new transforms
> and frames.
> 
> The package will be maintained using a git repository on alioth.

The Debian Astro web page is https://blends.debian.org/astro

I am forwarding this to our mailing list as well:

https://lists.debian.org/debian-astro

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi all,

On 06.12.2016 00:29, Don Armstrong wrote:
> [The screen shot Holger linked to is a screen shot of the installer at
> the tasksel screen showing an entry for "Debian Blends" followed by a
> series of entries which start with leading periods followed by entries
> like "HamRadio" and "DebiChem".]

This screenshot is outdated since several months. Currently, the wording
is different, and the number of included blends has shrunken a lot.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important

[Ole Streicher]

On 06.12.2016 10:18, Philip Hands wrote:
> it also buries the 'standard system utilities' item in the middle of
> the list, where it makes even less sense than it did at the end.

The positions of the items can be changed by assigning a "Relevance"
(one digit) to them. So, if the "Standard" task should be on top (what I
would prefer), it should get a high relevance; if it should be at the
end, it should get a low relevance. Currently, there is no relevance
specified for the "Standard" task, therefore it defaults to 5.

The blends tasks have "Relevance: 8", since I intended to have the
blends at the end (which is the right place for special tasks, IMO).
There is room for one relevance below, and if this is not enough, we
could rise the blends relevance: I just thought that there is probably
more need to sort things before than after the "Special tasks".

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

On 06.12.2016 10:37, Holger Levsen wrote:
> And this *is* still pretty confusing, though admitly better than it was
> half a year ago. 

The current implementation has a popcon of >5000, without a single
complaint or confusion documented in the web within the last six months.
This is at least *some* empirical evidence that it is not "pretty
confusing", and again I would ask you to show any better empirical data
here to support your own point.

> and it will only get worse, if we would keep it this way… We have *many* more
> blends in Debian… Debian Parl, Debian Junor, Debian Edu come to my mind
> immediatly.
> why list some and not some others? 


The "single checkbox" is not usable for all blends, since it requires a
"one size fits all" solution. For Debian Edu, you already stated
yourself that it is useless. Debian Junior and Debian Parl didn't opt
in. I therefore don't see a danger that the list will grow endlessly
before Stretch.

> and that this bug should not be about this tasksel menu but *about this
> was implemented*, which is by forcing an unneeded package on each and
> every Debian system under the sun. (priority: important…)

I already answered to this: there is no technical reason to have the
blends task in an individual package; technically it could also be put
into tasksel-data itself.

However, this would require action from the tasksel team every time
something changes in the blends task. d-i is already overloaded, and it
will not help if we put another responsibility on top of that. So, it is
a good solution to separate the responsibility of the "Special tasks"
item to the blends team.

Compared to an integrated (into tasksel-data) solution, the size impact
is minimal: mainly the overhead of having an additional package there.
If we care about this overhead, the problem would apply to tasksel-data
as well.

Best regards

Ole

Bug#846002: Lowering severity

[Ole Streicher]

Control: Severity -1 normal


Since no objections against my proposal were expressed for a week, I am
lowering the severity.

Since there is no update of the bug report with more recent experiences,
I will to close it as of version 0.6.94 within a few days.


Best regards


Ole

Bug#846002: Lowering severity

[Ole Streicher]

Hi Holger,

On 05.12.2016 13:46, Holger Levsen wrote:
> I'm sorry that I failed to respond yet. 

I am quite angry about this: You basically opened this bug by stating
that you will do an NMU within 4-5 days, but you already knew that you
would not have time to discuss the bug before you planned this to happen.

This puts quite some pressure to us to respond within a reasonable time
-- and then you (who clearly expressed how important you think this is)
hide yourself and fail to respond.

This all happens after half a year of silence from you, where we could
have discussed this and find alternatives without too much pressure.

And you even didn't check the current status before filing the bug.

Sorry, but this doesn't sound like a sensible behavior to get a good
solution.

> Still, this doesnt make a policy violation a non-policy violation.
> (Priority: important is *wrong* for this package.)

It is as wrong as for tasksel-data: if we want to have blends selection
in the installer, then this information needs to be available there.

Lowering the bug severity was done since I proposed so and did not get a
veto reply (covering my arguments) from you within a week.

> You are forcing the installation of blends-tasks on every Debian
> system. This is *not ok*.

In principle, the whole package could be integrated into tasksel-data.
However, this makes the work more complicated for the (already
overloaded) tasksel maintainers, since they also would have to deal with
the integration of the individual blends. The current solution keeps the
maintenance of the blends tasks in the installer in the responsibility
of the blends team.

I don't see why this solution is worse than to have it combined in a
single package (or file) -- it is even better since it moves
responsibilities away from an already overloaded team.

> I will try to reply ASAP, but… I might fail and just reassign to
> tech-ctte. (I also find it very hard to find time for this as you failed
> to understand the problem with the current implementation from the
> beginning, so I'm doubtful whether trying again (for like the 4th or 5th
> time will change anything.)

I brought some arguments. It would be nice if you could respond to them.

Since you even didn't check the current state, it is hard to discuss
here. As I explained, your arguments are already handled with version
0.6.95.

I would prefer to have the arguments discussed first instead of just
re-assigning to tech-ctte (which you did while I writing this reply, and
before you even started to handle Andreas' and my arguments).

Best regards

Ole

Bug#761146: Re-ITPing

[Ole Streicher]

Control: retitle -1 ITP: casacore-data -- Data for Common Astronomy Software 
Applications core library
Control: owner -1 Ole Streicher <oleb...@debian.org>

To keep the casacore data packages together, I plan 
to use the original package as a metapackage that
depends on the individual ones, currently:

* casacore-data-tai-utc
* casacore-data-irgf
* casacore-data-lines
* casacore-data-observatories
* casacore-data-sources

Once the remaining packages are there, they will
be added as dependencies as well:

* casacore-data-eop (ITP #842933)
* casacore-data-jplde (ITP #842931)
* casacore-data-predict (ITP #842934)

but this will not happen for stretch: They are not
buildable with the current version of casacore due to
https://github.com/casacore/casacore/issues/537

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

On 06.12.2016 12:02, Philip Hands wrote:
> Ole Streicher <oleb...@debian.org> writes:
> 
>> On 06.12.2016 10:37, Holger Levsen wrote:
>>> And this *is* still pretty confusing, though admitly better than it was
>>> half a year ago. 
>>
>> The current implementation has a popcon of >5000, without a single
>> complaint or confusion documented in the web within the last six months.
>> This is at least *some* empirical evidence that it is not "pretty
>> confusing", and again I would ask you to show any better empirical data
>> here to support your own point.
> 
> You seem to be mixing up two things here.
> 
> Holger was saying that the menu is confusing (as am I).
> 
> You're saying that because 5000 people seem to have ended up with this
> package on their systems, they were not confused.

I am saying that from these 5000 people nobody asked for help or
complained in the web, except for the initial wording. This initial
documented confusion shows that we actually *get* a response here (and
the search is not just useless).

> Looking at the graph for debian-astro, is seems to follow a similar
> curve, so perhaps these are the people that are installing the
> blends-tasks (BTW is there an easy way to check which packages are
> installed together via popcon?)

The relevant package from debian-astro (which is going to be installed
with by tasksel) is "astro-all". It has a popcon of 148, so most of the
people installing blends-tasks (5400) then do not install debian-astro.

The curve for both is similar, since both were introduced together:
astro-all was specifically created to do the actual installation of
Debian-Astro via the installer tasksel.

> There is no need for them to tick the 'Special tasks' menu item in order
> to install any of the the blends, so to some tiny extent they were
> confused when they did that, were they not?

I also find the structure here not optimal; this is however given by the
limitation that tasksel uses debconf, which has only limited
possibilities. The checkbox in "Special tasks" is confusing for sure.

However, this does not add confusion: the same problem is already there
(and was so in Jessie) with the "Desktop environment", so people need to
get used to it anyway -- we don't solve this by deciding the current issue.

What the empirical search however shows that the blends-tasks didn't add
additional confusion here.

Best regards

Ole

Bug#849502: Use of embedded external libraries

[Ole Streicher]

I removed the usage of six, configobj, ply, jquery and jquery.dataTables
in the git repository. However, I still cannot remove the use of the
local pytest, since astropy doesn't test successfully with the current
version in Debian (3.0.5). See also

https://github.com/astropy/astropy/issues/5277
https://github.com/astropy/astropy/issues/5670

Once this is fixed, I will remove that as well. It will be switched off
in astropy/tests/helper.py then.

Bug#849196: Sometimes, supress_warnings misses one of its attributes

[Ole Streicher]

Hi Sandro,

On 30.12.2016 15:01, Sandro Tosi wrote:
> On Fri, Dec 23, 2016 at 9:47 AM, Ole Streicher <ole.streic...@gmx.de> wrote:
>> This is a regression; it did not happen with 1.11. Please fix this
>> regression ASAP so that skimage can migrate safely before the freeze.
> 
> as asked on the github issue, is disabling parallel tests execution in
> skimage a viable temporary solution?

For the moment, I disabled the build time tests in skimage completely
because of #849196, to ensure it migrates before the freeze (I took the
really latest chance to do so). Therefore, I would not touch the package
before Jan 5. Once it is in testing, It would be however very important
to re-enable the tests, since this is more a crude hack than a clean
solution.

Unfortunately, I am not familar with the skimage code (I just did the
firefighter job here); specifically I don't know where to switch off
parallel tests, and what other implications that has. Maybe, you discuss
this with Yaroslav (in Cc), who is the skimage package maintainer? Also
the parallel bug I opened on the "scikit-image" github (referenced on
the numpy issue) may help there. Finally, Yaroslav should decide here.

I personally however would much more prefer to go back to the latest
numpy 1.11 in testing, and update only after 1.12 is released. I very
dislike having workarounds because a beta or a release candidate
uploaded to testing is buggy. And I would also prefer not to have a beta
or RC shipped with Stretch.

Best regards

Ole

Bug#848859: FTBFS randomly (failing tests)

[Ole Streicher]

Hi all,

On 04.01.2017 20:57, Santiago Vila wrote:
> I still want to build all packages and have 0 or 1 failures,
> so in this case the probability should be 1/50/2, i.e. 1%.
> 
> I think this is still feasible.

My experience is that the buildds that are currently in use provide more
build problems than the packages themself. BTW, why don't you count this
as RC?

[statistical]
>> The "fix" for such cases is the increasing of the threshold or disabling
>> the test completely. Because you can do nothing with it due to the
>> nature of numerical simulations.

Just disabling would be bad, since the test still can point to some
problem in the implementation, like optimization problems or such.

IMO the correct solution here would be to remove the randomness and to
seed with a fixed value (which is known to give a result within the
expectations).

> But as far as there are people in this project who consider that a
> package which FTBFS on single-CPU machines more than 50% of the time
> is ok "because it does not usually fail in buildd.debian.org",
> we are doomed.

We have 10 archs, and with a 50% chance of failure you will not get any
version built. Even when the buildds try it two or three times.

> The problem I see with this threshold thing is that every maintainer
> seems to have his own threshold, different from the others.
> 
> In case we decide about RC-ness depending on probability of failure:
> What threshold do you think we should use for a single package and why?
> 
> [ I say that 1% of failure is the maximum we should allow, and I've
>   explained why, but I would love to hear your opinion on this ].

I would not put any direct number here, but be pragmatic: We need to
build the package from source, and this has to be done on all supported
architectures, and on the buildds. As long as this is done, I see no
reason for an RC bug. If a package fails on a supported arch on the
buildds, this is RC, independent of whether this came from an
architectural difference or from a random build failure. Your tests with
repeated builds help the maintainer to find the cause in that case, and
for this they are helpful. But not release critical by themself.

Cheers

Ole

Bug#848859: FTBFS randomly (failing tests)

[Ole Streicher]

Hi Santiago,

On 04.01.2017 01:41, Santiago Vila wrote:
> On Tue, 27 Dec 2016, Ole Streicher wrote:
> Hello Ole. Thanks for your reply. Please don't forget to Cc: me if you
> expect your message to be read.

OK, however I usually assume that a bug submitter actually reads the
messages for his submitted bugs.

>>> In particular, if something happens 1 every 20 times on average, the
>>> fact that it did not happen when you try 10 times does not mean in any
>>> way that it may not happen.
>>
>>
>> I must however say that I don't see why a package that fails to build
>> once in 20 builds would have a release critical problem:
> 
> It's in Release Policy: Packages *must* autobuild *without* failure.
> 
> If a package fails to build from time to time, that's a failure.

Packages actually *do* fail from time to time, when I look into my
autobuilder. Not due to the package, but due to glitches within the
buildd infrastructure. Would you consider this a failure?

>> I totally agree that catching random failures
>> is a good quality measure, but this is IMO severity "important" at maximum.
> 
> Well, would you say it's RC if it fails 99% of the time?
> I guess you would.

I would consider a bug RC if it actually doesn't build on our buildds.

>> And it would be nice to have this QA test not just before the release,
>> but already early in the release cycle. This would help a lot to avoid
>> stressful bugfixes just before the freeze.
> 
> Well, if you see my list of FTBFS-randomly bug here:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org
> 
> you will see that I started to report FTBFS-randomly bugs several
> months ago, not last week, and not last month.
> 
> What would really help is to have somebody else reporting these bugs,
> because apparently very few people want to report them.
> 
> Also, you can't seriously "complain" that a bug reporter didn't not
> report something earlier! Of course that it would be nice to do this
> kind of QA stuff at every point in the release cycle, but as the same
> software that we maintain, my bug reports come with no warranty, not
> even the warranty that the bug is reported "as soon as it exists"! :-)

What I do complain about is that doing this just before the release adds
additional pressure to the package maintainers: The problem for us
ordinary people is that most of the time my packages look fine, without
serious problems, and just before the release all those RC bugs pop up
in bunches, with quite some time pressure to solve them. If the RC bugs
were randomly distributed over time, it would be more time to solve
them, and the quality of the fixes would be better: for example, in the
moment, I would just disable build time tests that randomly fail, while
usually I would try to see why they fail and fix that. In the moment,
there is no time for this.

Doing release QA just before the release leads to quick hacks to keep
things there, while a continious QA really solves them.

Best regards

Ole

Bug#848859: FTBFS randomly (failing tests)

[Ole Streicher]

On 05.01.2017 11:36, Santiago Vila wrote:
> On Thu, Jan 05, 2017 at 11:06:50AM +0100, Ole Streicher wrote:
>> Hi all,
>>
>> On 04.01.2017 20:57, Santiago Vila wrote:
>>> I still want to build all packages and have 0 or 1 failures,
>>> so in this case the probability should be 1/50/2, i.e. 1%.
>>>
>>> I think this is still feasible.
>>
>> My experience is that the buildds that are currently in use provide more
>> build problems than the packages themself. BTW, why don't you count this
>> as RC?
> 
> Can you clarify the question? I don't understand what you refer exactly.

It does not make sense to have 100% reliability on the package itself to
build but only 95% on the buildds. If we want to have reliability, then
every chain member counts -- and the weakest one in the moment for me
does not seem to be the packages themselves, but the buildd setups we
currently have. So, if you consider unreliable package builds as an RC
problem, you should also consider the unreliable buildd setup as an RC
problem.

>>> But as far as there are people in this project who consider that a
>>> package which FTBFS on single-CPU machines more than 50% of the time
>>> is ok "because it does not usually fail in buildd.debian.org",
>>> we are doomed.
>>
>> We have 10 archs, and with a 50% chance of failure you will not get any
>> version built. Even when the buildds try it two or three times.
> 
> It's actually more subtle than that.
> 
> The package may be ready to be built on multi-core machines, but not on
> single-core machines. So, the probability that I measure (greater than 50%),
> might not be the same as the probability on official autobuilders.

Ususally it is the other way around: packages build fine
single-threaded, but don't do so on many threads (or CPUs). At the end
it it also depends on how many CPUs you actually get for the build -- if
there are some packages built in parallel, the result may be as for a
single CPU.

> Then there is the other subtle thing: The package may be Arch:all, in
> which case a 50% of probability (this time independent on the number
> of CPUs) may go unnoticed very easily, either because the maintainer
> uploaded the .deb him/herself, or, if the maintainer uploaded
> in source-only form, we can just be lucky for that time.

I would favour much to ignore any prebuilt binaries and to re-build
everything anyway.

> We provide software which is free to be modified. If people is going
> to modify it and then it fails because the package only builds ok in
> buildd.debian.org, then we are removing one of the essential freedoms,
> the freedom to modify it, and the package becomes de-facto non-free,
> even if we still distribute it in main.

First, the multi-CPU buildd setup is free (as in speech), isn't it? So,
depending on this does not make anything non-free. I don't see why the
dependency on a specific build environment would change the DFSG
freeness at all (as long as the build environment itself is DFSG free).

Then, we are speaking about random failures. If you use a single-core
and see a build failure, you can just pragmatically repeat it.

Sorry, I don't see why this would restrict DFSG freedom here.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Cyril,

On 20.12.2016 10:59, Cyril Brulebois wrote:
> dropping blends entirely is still my default option in case proposed
> changes have too far reaching consequences.

As I already wrote several times: before you do so, please show some
evidence that in the half year that the current version of the installer
containing a blends selection has added an unacceptable amount of
confusion and that we can't solve that by changing the wording or such.

We already have more that 5700 popcon-counted installations with the
blends selection in the installer. This should give some base for that.

And at least by searching the net, I could not find anything.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Sam,

On 21.12.2016 16:10, Sam Hartman wrote:
>>>>>> "Ole" == Ole Streicher <oleb...@debian.org> writes:
> I don't find quoting popcon stats useful.  You've used them to support
> the claim both that this is important and that users don't find it
> confusing.

I am quoting popcon here since they give a lower estimate of the number
of users who actually did the test. Nothing more. Nothing about importance.

> I think your reasoning rests of the false assumptions that users are
> likely to report bugs when they find something confusing.
> In my experience that's not the case.  Instead, they are likely to get
> grumpy and decrease their overall confidence in some software.
> Users cannot be counted on to proactively report confusing aspects of
> software.

I don't speak about bug reports only. I have searched the net for any
appearance of problems with the blends; also discussion forums and such.

And as I wrote in one of my early statements: there *was* such a case:
in a german forum, someone asked "what does this blends stuff mean?".
This shows that one *gets* a response here. After that response, we
changed the wording; no further complaints were found after that.

And I would also not just count "end user reports". If for example
someone would have done an install party (or such), he would know what
the usual questions of users were. Also if someone recommended to
install Stretch to his friend and had to help somewhere. He could (and
should!) then do a bug report. Didn't happen yet.

"Confusion" is not just something mythical that we can't see empirical.
We will see it in help requests, blog posts, also bug reports, and other
complaints. If the raise of confusion is "inacceptable" as stated here,
I would really ask for some empirical evidence for this. At least, I did
some homework by checking that no complaints popped up somewhere in the
net (except the one I already mentioned).

Best regards

Ole

Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)

[Ole Streicher]

On 21.12.2016 16:17, Adrian Bunk wrote:
> I can clearly understand why Andreas is unhappy to see when such a 
> change is uploaded without prior warning 1.5 months after the start
> of the freeze, and 1 week before an important deadline for his package.

Sure; what I also don't understand is why numpy pushes its RC and betas
into unstable instead of experimental (and then maybe check or asks for
checking for the reverse deps). This makes it harder to revert if there
are problems.

Sandro, maybe you could explain that a bit?

Cheers

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Holger

On 20.12.2016 15:27, Holger Levsen wrote:
> On Tue, Dec 20, 2016 at 03:16:50PM +0100, Ole Streicher wrote:
>> Again: the installer is there to test for 6 months now, but if it is
>> inacceptably bad: why are there no complaints?
> 
> the complaints have been there for months, you just choose to consider
> them invalid. some people dont like to repeat themselves.

After six months of testing, I would expect that the fears that were
expressed at that times were supported by some real solid experiences.
This is a big difference and in no way a repetition.

Ole

Bug#848758: Re: Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)

[Ole Streicher]

Hi all,

On 21.12.2016 11:59, Andreas Tille wrote:
> On Wed, Dec 21, 2016 at 11:40:16AM +0200, Adrian Bunk wrote:
>> For python-skbio it is *really* time to panic *right now*.
> Thanks for confirming that I was not actually panicing. ;-)

While I agree in principle, I would like to remind the following as well:

The current FTBFS mainly (as far as I can see) come from a change that
was announced already two numpy versions ago: that numpy will refuse to
accept floats as indices.

The according functions are since then marked as "deprecated" and issue
a warning. Numpy introduced this change with 1.11rc already, which was
uploaded to Debian about 6 months ago. After it appears that many
packages (als in Debian) have problems with this, they postponed it for
another release -- which happens just now.

I am a bin angry here about unresponsive upstreams, which just ignore
these changes as long as possible, and I am not sure whether we should
ship Stretch with an outdated numpy release just because there are a
number of upstreams that are too lazy to keep their packages up to date.
I would really ask to push upstream hardly to do the required changes;
maybe we can decide if it is needed to revert that later. The changes
are required anyway; doing them sooner than later is no mistake in any case.

(I am too lazy in the moment to support my statement with links; if you
need, I will do so ofcourse)

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Steve,

On 20.12.2016 15:16, Steve McIntyre wrote:
> I *have* also seen users confused by the addition of the blends

Can you be more specific here? Old wording (with many blends) or current
solution? What was the specific problem?

> into the tasksel list. A better split of the tasks (like Phil is
> suggesting) would help a lot here.

This is for sure. Cyril just states that he rather would love to remove
the blends completely, and this is something I am arguing against.

That Phils solution is a great compromise, is out of question. IMO it
would help much if d-i would help here a bit instead of just trying to
play a veto game.

Best regards

Ole

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ole Streicher]

Hi Cyril,

On 20.12.2016 15:01, Cyril Brulebois wrote:
> Ole Streicher <oleb...@debian.org> (2016-12-20):
>> As I already wrote several times: before you do so, please show some
>> evidence that in the half year that the current version of the installer
>> containing a blends selection has added an unacceptable amount of
>> confusion and that we can't solve that by changing the wording or such.
> 
> Having more choices means more confusion. Look at any UX studies, or
> install parties.
> 
> Also, choices aren't consistent depending on installation media, which
> doesn't help.
> 
> You might call it me being weird, but this is how we've tried to balance
> choices in D-I for a few years (10+ AFAICT), as already confirmed by
> Christian earlier. The addition of various blends in the path of all
> users shifts this balance, in the wrong direction.

And by how much? If it is just a very little bit, this could be acceptable.

It seems clear by the whole discussion that tasksel is *already* quite
confusing to the users in an unacceptable way, and that we should change
it in buster. So, whatever we do now is just the last step in a dead end.

BTW, adding LXQT to the desktops also goes into the wrong direction,
since it adds another choice. This shows, that you don't take the "wrong
direction" argument serious yourself (resp. Christian, who did the patch
in the tasksel git).

>> We already have more that 5700 popcon-counted installations with the
>> blends selection in the installer. This should give some base for
>> that.
> 
> Surely, people asking for blends are using blends selection. That's nice
> and I'm pretty sure nobody is going to dispute that. But that shouldn't
> make d-i more confusing for others.

So, please *show* that the current solution does add confusion in an
unacceptable way. Show for example installation reports. Or something
else which shows clearly that the current concrete solution in not
acceptable. Based on the concrete experience of the current installer.

And, I didn't just search through the astronomy related pages for
issues, but tried to catch any report for the new installer -- and
didn't find anything.

Again: the installer is there to test for 6 months now, but if it is
inacceptably bad: why are there no complaints?

Best regards

Ole

Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)

[Ole Streicher]

On 21.12.2016 19:16, Sandro Tosi wrote:
>> They are still, what the name suggests: candidates, with no confirmation
>> to be useful in a production environment. I don't see why they should
>> ever migrate to testing (as they did in 1.11.1rc.1). Last time, we had
>> an numpy RC in testing for more than four months (2016-05-06 to
>> 2016-10-16)! This doesn't confirm a sigh quality tendency. And imagine
> 
> this is the diff between 1.11.2rc1 and 1.11.2 (not the same versions
> you mentioned, but the most recent one we can make such comparison):
> 
> https://anonscm.debian.org/cgit/python-modules/packages/python-numpy.git/diff/?h=upstream/11.11.2

... and the difference to the one before is larger, and more critical,
and longer in testing.

> the version is just a name, there will be bugs even in the most shiny
> new release of every software

An "RC" instead of a release is there for a reason. The last (1.11)
numpy release process has shown that. It would be nice if the Debian
packaging would reflect this difference.

Best regards

Ole

Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)

[Ole Streicher]

Hi Sandro,

On 21.12.2016 16:43, Sandro Tosi wrote:
> On Wed, Dec 21, 2016 at 10:27 AM, Ole Streicher <oleb...@debian.org> wrote:
>> Sure; what I also don't understand is why numpy pushes its RC and betas
>> into unstable instead of experimental (and then maybe check or asks for
>> checking for the reverse deps). This makes it harder to revert if there
>> are problems.
>>
>> Sandro, maybe you could explain that a bit?
> 
> early/wider exposure, and they tend to be of high quality.

They are still, what the name suggests: candidates, with no confirmation
to be useful in a production environment. I don't see why they should
ever migrate to testing (as they did in 1.11.1rc.1). Last time, we had
an numpy RC in testing for more than four months (2016-05-06 to
2016-10-16)! This doesn't confirm a sigh quality tendency. And imagine
that happens now; chances are high that we release Stretch with a numpy
release candidate.

IMO the way numpy changes are to be tested in Debian needs some adjustment.

Best regards

Ole

Bug#848112: Python-skimage depends on unavailable package python-dask

[Ole Streicher]

Control: tags 848112 pending

Hi all,

On 23.12.2016 10:08, Andreas Tille wrote:
> Ole, if you would please commit the patch you named in #848112 and
> upload the package to make sure it can migrate right in time and will
> enable other packages to migrate as well?
> 
> HOWEVER, we have another problem:  If I build the current state in Git
> I'm running into:
> TypeError: 'numpy.float64' object cannot be interpreted as an index

I have a fix for both, and after a final test build, I will upload.

The package still seems to be in bad shape; during the docs generation
exceptions are thrown like

ValueError: 3-dimensional arrays must be of dtype unsigned byte,
unsigned short, float32 or float64
TypeError: 'numpy.float64' object cannot be interpreted as an index

They are ignored, however, but show that some work is still needed.

Cheers

Ole

Bug#849196: Sometimes, supress_warnings misses one of its attributes

[Ole Streicher]

Package: src:python-numpy
Severity: serious
Version: 1:1.12.0~b1-1
X-Debbugs-Cc: debian-scie...@lists.debian.org
Forwarded: https://github.com/numpy/numpy/issues/8413
Affects: src:skimage

When trying to compile skimage, I sometimes get the following error:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/transform/tests/test_integral.py",
line 46, in test_vectorized_integrate
assert_equal(expected, integrate(s, r0, c0, r1, c1))  # test deprecated
  File
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/transform/integral.py",
line 86, in integrate
warn("The syntax 'integrate(ii, r0, c0, r1, c1)' is "
  File
"/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/_shared/_warnings.py",
line 16, in warn
warnings.warn(message, stacklevel=stacklevel)
  File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line
2199, in _showwarning
self._orig_show(message, category, filename, lineno,
AttributeError: 'suppress_warnings' object has no attribute '_orig_show'

or

ERROR: test suite for 
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 229, in run
self.tearDown()
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 352, in tearDown
self.teardownContext(ancestor)
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 368, in
teardownContext
try_run(context, names)
  File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run
inspect.getargspec(func)
  File "/usr/lib/python3.5/inspect.py", line 1040, in getargspec
stacklevel=2)
  File "/usr/lib/python3/dist-packages/numpy/testing/utils.py", line
2199, in _showwarning
self._orig_show(message, category, filename, lineno,
AttributeError: 'suppress_warnings' object has no attribute '_orig_show'

Bug#849177: Python-numpy transition breaks at least two packages

[Ole Streicher]

Hi all,

On 23.12.2016 11:19, Andreas Tille wrote:
> I'm also not sure and people who know better than me should feel free to
> close bug #849177.  I'd be really happy if there are better solutions to
> fix python-skimage in the next 36 hours.  My reading of the arguments in
> #849177 is that there are other reasons to revert the upgrade even
> without the additional problem - thus I was opening the bug report
> independently from other packages like python-skimage and python-skbio.

While the original FTBFS for skimage is solved now, I found another
problem with numpy 1.12 RC (and skimage) which I reported upstream:

https://github.com/numpy/numpy/issues/8413

Currently, this keeps up to get a version of skimage into Debian that
has a chance to migrate.

This is really very disappointing to run into those problems just a few
hours before the window for the stretch migration closes.

Sandro, could you please *immediately* rollback the numpy RC or at least
upload a version that otherwise solves all the regressions that are
still open? Please put a stable, working version of numpy that we all
can rely on. Time matters here.

Best regards

Ole (quite angry in the moment, sorry.)

Bug#849196: Sometimes, supress_warnings misses one of its attributes

[Ole Streicher]

Just to show an extremal case:

https://buildd.debian.org/status/fetch.php?pkg=skimage=all=0.12.3-3=1482501775

has this 15 times.

This is a regression; it did not happen with 1.11. Please fix this
regression ASAP so that skimage can migrate safely before the freeze.

Best

Ole

Bug#848782: statsmodels: FTBFS: TypeError: 'float' object cannot be interpreted as an index

[Ole Streicher]

OK, I will re-upload directly to ftp-master.

Andreas, since you already moved and cleaned up skimage: would you do
the same for pandas and statsmodels? For statsmodels, I will already put
the new VCS into d/control and do a team upload (pushing the changes as
soon as the git is there).

Cheers

Ole

On 25.12.2016 14:42, Yaroslav Halchenko wrote:
> On December 25, 2016 7:29:09 AM EST, Ole Streicher <oleb...@debian.org> wrote:
>> Hi Yaroslav, Michael,Andreas,
>>
>> I uploaded the NMU as release 1.1 to DELAYED/2 now. I preferred NMU
>> since I am not a NeuroDebian team member.
>>
>> And I would (again) propose to move the package to debian-science. It
>> would also be useful to have it with the default structure (with
>> upstream and pristine-tar branches).
>>
>> Best regards
>>
>> Ole
>>
>> On 25.12.2016 10:43, Ole Streicher wrote:
>>> I'll upload to DELAYED ASAP (need to learn how to do this anyway);
>>> however the unresolved problem is still the pandas FTBFS. Without
>> that,
>>> statsmodels will not migrate.
>>>
>>> Cheers
>>>
>>> Ole
>>>
>>> On 25.12.2016 08:34, Andreas Tille wrote:
>>>> Hi Ole,
>>>>
>>>>> the attached patch fixes the FTBFS. What is the schedule to fix the
>>>>> other problems with statsimage -- especially pandas?
>>>>
>>>> I learned that NeuroDebian is happy about team uploads / NMUs - so
>>>> I think its fine if you upload your patch.
>>>>
>>>> Kind regards
>>>>
>>>> Andreas.
>>>>
>>>> PS: If you are not convinced and there is no response from Yaroslav
>> or
>>>> Michael in the next 24 hours - well, people are occupied by real
>> life
>>>> these days, yust tell me and I'd upload.
>>>>
> 
> You can go ahead and upload without delays. 
> If you see somehow that moving under another bigger team would make package 
> better, you have my blessing for pandas and statsmodels
> 
> Cheers
> 

Bug#848782: statsmodels: FTBFS: TypeError: 'float' object cannot be interpreted as an index

[Ole Streicher]

Hi Yaroslav, Michael,Andreas,

I uploaded the NMU as release 1.1 to DELAYED/2 now. I preferred NMU
since I am not a NeuroDebian team member.

And I would (again) propose to move the package to debian-science. It
would also be useful to have it with the default structure (with
upstream and pristine-tar branches).

Best regards

Ole

On 25.12.2016 10:43, Ole Streicher wrote:
> I'll upload to DELAYED ASAP (need to learn how to do this anyway);
> however the unresolved problem is still the pandas FTBFS. Without that,
> statsmodels will not migrate.
> 
> Cheers
> 
> Ole
> 
> On 25.12.2016 08:34, Andreas Tille wrote:
>> Hi Ole,
>>
>>> the attached patch fixes the FTBFS. What is the schedule to fix the
>>> other problems with statsimage -- especially pandas?
>>
>> I learned that NeuroDebian is happy about team uploads / NMUs - so
>> I think its fine if you upload your patch.
>>
>> Kind regards
>>
>> Andreas.
>>
>> PS: If you are not convinced and there is no response from Yaroslav or
>> Michael in the next 24 hours - well, people are occupied by real life
>> these days, yust tell me and I'd upload.
>>

Bug#848782: statsmodels: FTBFS: TypeError: 'float' object cannot be interpreted as an index

[Ole Streicher]

I'll upload to DELAYED ASAP (need to learn how to do this anyway);
however the unresolved problem is still the pandas FTBFS. Without that,
statsmodels will not migrate.

Cheers

Ole

On 25.12.2016 08:34, Andreas Tille wrote:
> Hi Ole,
> 
>> the attached patch fixes the FTBFS. What is the schedule to fix the
>> other problems with statsimage -- especially pandas?
> 
> I learned that NeuroDebian is happy about team uploads / NMUs - so
> I think its fine if you upload your patch.
> 
> Kind regards
> 
> Andreas.
> 
> PS: If you are not convinced and there is no response from Yaroslav or
> Michael in the next 24 hours - well, people are occupied by real life
> these days, yust tell me and I'd upload.
> 

Bug#848859: FTBFS randomly (failing tests)

[Ole Streicher]

Hi Santiago,

> In particular, if something happens 1 every 20 times on average, the
> fact that it did not happen when you try 10 times does not mean in any
> way that it may not happen.


I must however say that I don't see why a package that fails to build
once in 20 builds would have a release critical problem:

There is nothing in our policy that requires a reproducible or even a
always successful build. I totally agree that catching random failures
is a good quality measure, but this is IMO severity "important" at maximum.

And it would be nice to have this QA test not just before the release,
but already early in the release cycle. This would help a lot to avoid
stressful bugfixes just before the freeze.

Best regards

Ole

Bug#848505: tycho2: FTBFS (segfault during build)

[Ole Streicher]

Control: reassign -1 astrometry.net
Control: affects -1 src:tycho2
Control: tags -1 pending

It is confirmed that the crash is a problem in astrometry.net. A patch
is available; we just clarify whether a new astrometry.net upstream
version is issued or the patch is applied to the current version.

Bug#848782: statsmodels: FTBFS: TypeError: 'float' object cannot be interpreted as an index

[Ole Streicher]

Control: tags -1 patch

Hi,

the attached patch fixes the FTBFS. What is the schedule to fix the
other problems with statsimage -- especially pandas?

best regards

Ole
>From 5c6f9ffecf8e53c32edc14326042bb4d5ca6a641 Mon Sep 17 00:00:00 2001
From: Ole Streicher <oleb...@debian.org>
Date: Sat, 24 Dec 2016 14:56:07 +0100
Subject: [PATCH] Fix index type in `reshape` to be integer

---
 debian/changelog  |  6 ++
 debian/patches/fix_wrong_index_type.patch | 15 +++
 debian/patches/series |  1 +
 3 files changed, 22 insertions(+)
 create mode 100644 debian/patches/fix_wrong_index_type.patch

diff --git a/debian/changelog b/debian/changelog
index febebbe..bbd71aa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+statsmodels (0.8.0~rc1+git59-gef47cd9-2) UNRELEASED; urgency=medium
+
+  * Fix index type in `reshape` to be integer. Closes: #848782
+
+ -- Ole Streicher <oleb...@debian.org>  Sat, 24 Dec 2016 14:56:22 +0100
+
 statsmodels (0.8.0~rc1+git59-gef47cd9-1) unstable; urgency=medium
 
   * Fresh upstream rc snapshot which hopefully addresses some
diff --git a/debian/patches/fix_wrong_index_type.patch b/debian/patches/fix_wrong_index_type.patch
new file mode 100644
index 000..ca284b9
--- /dev/null
+++ b/debian/patches/fix_wrong_index_type.patch
@@ -0,0 +1,15 @@
+Author: Ole Streicher <oleb...@debian.org>
+Descrption: Fix index type in `reshape` to be integer.
+
+This will avoid FTBFS with numpy >= 1.12 beta
+--- a/statsmodels/genmod/generalized_estimating_equations.py
 b/statsmodels/genmod/generalized_estimating_equations.py
+@@ -2392,7 +2392,7 @@
+ exog_names = [x.split("[")[0] for x in exog_names]
+ 
+ params = np.reshape(self.params,
+-(ncut, len(self.params) / ncut))
++(ncut, len(self.params) // ncut))
+ 
+ for ev in exog_values:
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 0f4a162..649de9c 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@ up_reduce_test_precision
 deb_skip_test_ons390
 deb_no_nbformat_for_now
 up_3239.patch
+fix_wrong_index_type.patch
-- 
2.10.2

Bug#849271: version comparison fails with numpy 1.12.0b1

[Ole Streicher]

package: astropy
version: 1.3-1
severity: serious
forwarded: https://github.com/astropy/astropy/issues/5643

With astropy 1.3 and numpy 1.12.0b1, many affiliated packages now fail
in the tests when the numpy version number is compared. For example aplpy:

Traceback (most recent call last):
  File "debian/tests/python3-aplpy", line 7, in 
import aplpy
  File "/usr/lib/python3/dist-packages/aplpy/__init__.py", line 9, in

from ._astropy_init import *
  File "/usr/lib/python3/dist-packages/aplpy/_astropy_init.py", line
116, in 
from astropy import config
  File "/usr/lib/python3/dist-packages/astropy/__init__.py", line 116,
in 
_check_numpy()
  File "/usr/lib/python3/dist-packages/astropy/__init__.py", line 104,
in _check_numpy
from .utils import minversion
  File "/usr/lib/python3/dist-packages/astropy/utils/__init__.py", line
20, in 
from .compat.odict import OrderedDict
  File
"/usr/lib/python3/dist-packages/astropy/utils/compat/__init__.py", line
14, in 
from .numpycompat import *
  File
"/usr/lib/python3/dist-packages/astropy/utils/compat/numpycompat.py",
line 24, in 
NUMPY_LT_1_12 = not minversion('numpy', '1.12dev')
  File "/usr/lib/python3/dist-packages/astropy/utils/introspection.py",
line 159, in minversion
return parse_version(have_version) >= parse_version(version)
  File "/usr/lib/python3.5/distutils/version.py", line 70, in __ge__
c = self._cmp(other)
  File "/usr/lib/python3.5/distutils/version.py", line 337, in _cmp
if self.version < other.version:
TypeError: unorderable types: int() < str()

Bug#846002: blends-tasks must not be priority:important - ballot proposal

[Ole Streicher]

Hi Margarita,

On 26.12.2016 14:43, Margarita Manterola wrote:
> While it's great that there is a possibly better solution in the works for the
> tasksel screen, there's still the issue at hand that blends-tasks has used the
> severity of the package as a way of circumventing collaboration with tasksel
> maintainers.

I already several times pointed that out: We did not "circumvent" the
collaboration with the tasksel maintainers.

The relevant bug #758116 was assigned to tasksel for quite a long time,
and the proposed solution to create a package blends-tasks was announced
exactly there -- so the proposal was on the desk of the tasksel
maintainers, explicitly asking if they would veto.

The first response from a tasksel maintainer came only five weeks later,
without a veto, but with a discussion that finally lead to the current
wording and selection. This is not what I would usually call "circumvent
collaboration".

For any other critics, the usual way to collaborate is to open a bug
report. This did not happen then before of this bug (#846002). #846002
was again based on the first version of blends-tasks (see Holgers
initial message), and he failed to rebase it within an reasonable time
(and the original critics were already handled by the update to
blends-tasks 0.6.94 as described above).

And, again, IMO the d-i team several times expressed their heavy
overload. It seems natural that working on the blends selection in
tasksel or the correct wording should be done by the people who actually
deal with the blends, avoiding to put additional load on them.

Could you support your accusation a bit? I have the feeling that you are
ignoring my arguments (since I have put them here already).

Best regards

Ole

Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)

[Ole Streicher]

Hi Adrian,

On 21.12.2016 15:29, Adrian Bunk wrote:
> On Wed, Dec 21, 2016 at 02:05:57PM +0100, Ole Streicher wrote:
>> ...
>> The according functions are since then marked as "deprecated" and issue
>> a warning. Numpy introduced this change with 1.11rc already, which was
>> uploaded to Debian about 6 months ago. After it appears that many
>> packages (als in Debian) have problems with this, they postponed it for
>> another release -- which happens just now.
>> ...
> 
> You are saying you knew for 6 months that many packages in Debian
> have problems with the changes that have just been uploaded.
> 
> Why were no bugs filed a few months before the upload?

Most of my own programs have CI tests which immediately gave a signal. I
forwarded this upstream (mainly as github issues) and took part in the
diskussion between upstream (f.e. astropy) and numpy, so that finally
the decision was made to postpone.

Since I looked only on my own packages, there was no need to file bugs;
especially since the problem was postponed. The upstream maintainers
that were informed took measures in between; therefore I have only one
package (astroml) currently failing.

I had no information about any other package; therefore I couldn't file
bug reports. I can just recommend: If a Python package comes with tests,
use the Debian CI infrastructure for it. This helps a lot as an early
indicator of problems. And since the problems appear on packages with
build time test, I would like to ask back: why don't you use CI?

Best regards

Ole

Bug#846094: cpl_mask.c: Unaligned access

[Ole Streicher]

Control: tags -1 pending

Hi,

I applied the patch from Ubuntu in the git repository. However, since
the bug is severity "normal" and we are in freeze, I do not upload a new
revision.

Ubuntu patch: https://patches.ubuntu.com/c/cpl/cpl_7.0-3ubuntu1.patch
Relevant commit:
https://anonscm.debian.org/cgit/debian-astro/packages/cpl.git/commit/?id=1654c4f5d72d768f40a9f1415697049e7704282f

Best regards

Ole

Bug#858260: pandas: FTBFS (pandas.tests.test_multilevel.TestMultiLevel fails)

[Ole Streicher]

Looking into ci.debian.net, the new failure appears for the first time
on 2017-03-14:

https://ci.debian.net/data/packages/unstable/amd64/p/pandas/20170314_082050.autopkgtest.log.gz

The debci log also shows an update of tzdata for this time:

https://ci.debian.net/data/packages/unstable/amd64/p/pandas/20170314_082050.log

so I would suspect this as the cause as well.

Bug#857067: Excluding arch s390x for dsdp?

[Ole Streicher]

Control: tags -1 patch

Hi Andreas and all,

it seems that this bug is fixed in Ubuntu; at least there is a quite
careful analysis:

https://bugs.launchpad.net/ubuntu/+source/dsdp/+bug/1543982

I attach the complete patch; it needs some minor clean-up, but is a good
candidate to solve this.

Cheers

Ole
diff -pruN 5.8-9.1/debian/changelog 5.8-9.1ubuntu2/debian/changelog
--- 5.8-9.1/debian/changelog	2012-05-27 20:01:57.0 +
+++ 5.8-9.1ubuntu2/debian/changelog	2016-04-14 11:52:55.0 +
@@ -1,3 +1,21 @@
+dsdp (5.8-9.1ubuntu2) xenial; urgency=medium
+
+  * Cast INFO to int before storing it in the flag. LP: #1543982.
+
+ -- Dimitri John Ledkov   Thu, 14 Apr 2016 12:52:28 +0100
+
+dsdp (5.8-9.1ubuntu1) xenial; urgency=medium
+
+  * Build using -O2 on s390x. LP: #1543982.
+
+ -- Matthias Klose   Wed, 10 Feb 2016 11:28:13 +0100
+
+dsdp (5.8-9.1build1) xenial; urgency=medium
+
+  * No-change rebuild for libblas3gf->libblas3 transition.
+
+ -- Matthias Klose   Sat, 16 Jan 2016 16:13:00 +0100
+
 dsdp (5.8-9.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -pruN 5.8-9.1/debian/control 5.8-9.1ubuntu2/debian/control
--- 5.8-9.1/debian/control	2011-07-22 07:29:20.0 +
+++ 5.8-9.1ubuntu2/debian/control	2016-04-14 11:53:55.0 +
@@ -1,7 +1,8 @@
 Source: dsdp
 Section: science
 Priority: extra
-Maintainer: Soeren Sonnenburg 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Soeren Sonnenburg 
 Build-Depends: cdbs, debhelper (>= 5), gfortran, libblas-dev, liblapack-dev,
  doxygen, doxygen-latex
 Standards-Version: 3.9.2
diff -pruN 5.8-9.1/debian/patches/series 5.8-9.1ubuntu2/debian/patches/series
--- 5.8-9.1/debian/patches/series	1970-01-01 00:00:00.0 +
+++ 5.8-9.1ubuntu2/debian/patches/series	2016-04-14 11:53:35.0 +
@@ -0,0 +1 @@
+type-mismatch.patch
diff -pruN 5.8-9.1/debian/patches/type-mismatch.patch 5.8-9.1ubuntu2/debian/patches/type-mismatch.patch
--- 5.8-9.1/debian/patches/type-mismatch.patch	1970-01-01 00:00:00.0 +
+++ 5.8-9.1ubuntu2/debian/patches/type-mismatch.patch	2016-04-14 11:53:49.0 +
@@ -0,0 +1,15 @@
+Description: Cast INFO to int before storing it in the flag
+Author: Dimitri John Ledkov 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1543982
+
+--- dsdp-5.8.orig/src/vecmat/dlpack.c
 dsdp-5.8/src/vecmat/dlpack.c
+@@ -123,7 +123,7 @@ static int DTPUMatCholeskyFactor(void* A
+ dtpuscalemat(AP,ss,N);
+   }
+   dpptrf(, , AP,  );
+-  *flag=INFO;
++  *flag=(int) INFO;
+   return 0;
+ }
+ 
diff -pruN 5.8-9.1/debian/rules 5.8-9.1ubuntu2/debian/rules
--- 5.8-9.1/debian/rules	2012-05-27 19:07:13.0 +
+++ 5.8-9.1ubuntu2/debian/rules	2016-04-14 11:53:19.0 +
@@ -5,15 +5,18 @@ DEB_SHLIBDEPS_INCLUDE := /usr/lib/atlas
 ver:= $(DEB_UPSTREAM_VERSION)
 soname := libdsdp-$(ver)gf.so
 
+DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
+OPT = -O3
+
 common-build-arch:: debian/build-arch-stamp
 debian/build-arch-stamp:
-	$(MAKE) DSDPROOT=`pwd` OPTFLAGS="-fPIC -O3" dsdpapi LAPACKBLAS="-llapack \
+	$(MAKE) DSDPROOT=`pwd` OPTFLAGS="-fPIC $(OPT)" dsdpapi LAPACKBLAS="-llapack \
 		-lblas -lm"
 	cd lib && ar x libdsdp.a && \
 		$(CC) -shared -Wl,--no-add-needed,-soname=$(soname) -o $(soname) *.o \
 		-llapack -lblas -lm && ln -s $(soname) libdsdp.so && rm *.o
 	$(MAKE) DSDPROOT=`pwd` -C examples clean
-	$(MAKE) DSDPROOT=`pwd` OPTFLAGS="-O3" DSDPLIB="-L$(CURDIR)/lib -ldsdp -lm" \
+	$(MAKE) DSDPROOT=`pwd` OPTFLAGS="$(OPT)" DSDPLIB="-L$(CURDIR)/lib -ldsdp -lm" \
 		example LAPACKBLAS=""
 	touch $@
 
diff -pruN 5.8-9.1/.pc/applied-patches 5.8-9.1ubuntu2/.pc/applied-patches
--- 5.8-9.1/.pc/applied-patches	1970-01-01 00:00:00.0 +
+++ 5.8-9.1ubuntu2/.pc/applied-patches	2016-04-15 01:37:08.336449243 +
@@ -0,0 +1 @@
+type-mismatch.patch
diff -pruN 5.8-9.1/.pc/type-mismatch.patch/src/vecmat/dlpack.c 5.8-9.1ubuntu2/.pc/type-mismatch.patch/src/vecmat/dlpack.c
--- 5.8-9.1/.pc/type-mismatch.patch/src/vecmat/dlpack.c	1970-01-01 00:00:00.0 +
+++ 5.8-9.1ubuntu2/.pc/type-mismatch.patch/src/vecmat/dlpack.c	2005-10-21 19:31:15.0 +
@@ -0,0 +1,1015 @@
+#include "dsdpsys.h"
+#include "dsdpvec.h"
+#include "dsdplapack.h"
+
+/*! \file dlpack.c
+\brief DSDPDataMat, DSDPDualMat, DSDPDSMat, DSDPSchurMat, DSDPXMat,
+objects implemented in dense upper packed symmetric format.
+*/
+
+typedef struct{
+  char UPLO;
+  double *val;
+  double *v2;
+  double *sscale;
+  int  scaleit;
+  int n;
+  int owndata;
+} dtpumat;
+
+static const char* lapackname="DENSE,SYMMETRIC,PACKED STORAGE";
+
+int DTPUMatEigs(void*AA,double W[],double IIWORK[], int nn1, double *mineig){
+  dtpumat* AAA=(dtpumat*) AA;
+  ffinteger info,INFO=0,M,N=AAA->n;
+  ffinteger IL=1,IU=1,LDZ=1,IFAIL;
+  ffinteger *IWORK=(ffinteger*)IIWORK;
+  double