Bug#1067782: Uses deprecated tooling to build package

[Michael Hanke]

It is unclear why tqdm (and tqdm specifically) is downloaded. The build
log confirms that python3-tqdm (4.66.2-2) was installed as a
build-dependency.

That being said, the step that triggers the download is preceded with
the message


PYTHONPATH="bin:" python3 setup.py develop --install-dir bin
running develop
/usr/lib/python3/dist-packages/setuptools/command/develop.py:40: 
EasyInstallDeprecationWarning: easy_install command is deprecated.
!!



Please avoid running ``setup.py`` and ``easy_install``.
Instead, use pypa/build, pypa/installer or other
standards-based tools.

See https://github.com/pypa/setuptools/issues/917 for details.



!!
  easy_install.initialize_options(self)
/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py:66: 
SetuptoolsDeprecationWarning: setup.py install is deprecated.
!!



Please avoid running ``setup.py`` directly.
Instead, use pypa/build, pypa/installer or other
standards-based tools.

See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
for details.



!!

Possibly the problem is caused by a toolchain that should no longer be
used to begin with.

-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://psychoinformatics.de

Bug#1070186: New upstream fixed problem

[Michael Hanke]

The current 1.0.3 release no longer depends on boto and has moved to
boto3.

-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://psychoinformatics.de

Bug#968730: SO version specification changed upstream

[Michael Hanke]

It seems that upstream has changed the way they set the SO version
information:

https://salsa.debian.org/med-team/nifticlib/-/commit/eabee0938978a7f5e8e28522be3d856dee3975cf#48dc04d58c3c3f29ad0415ca64d38e3231bffd87_0_17

and the previous explicit set in the top-level CMakeLists.txt is gone.

-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://psychoinformatics.de

Bug#937490: pynifti: Python2 removal in sid/bullseye

[Michael Hanke]

Hi,

On Sun, Aug 2, 2020, 23:47 Moritz Mühlenhoff  wrote:

> On Fri, Jul 10, 2020 at 01:08:44PM +0200, Andreas Tille wrote:
> > On Mon, Jun 29, 2020 at 08:37:58PM +0200, Moritz Mühlenhoff wrote:
> > > On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote:
> > >
> > > The upstream homepage states
> > >
> > > | PyNIfTI is no longer actively developed. At has been
> > > | superseded by NiBabel -- a pure-Python package that
> > > | provides everything that PyNIfTI could do, and a lot more.
> > >
> > > Given that nibabel is packaged, let's simply remove pynifti?
> >
> > Same answer from my side as for mrtrix - from my point of
> > view it can go.
>
> Michael/Yaroslav, ping. Ack to remove pynifti from your end?


Yes, it can go. Thx.


Michael

>
>

Bug#937090: mrtrix: Python2 removal in sid/bullseye

[Michael Hanke]

Hi,

On Sun, Jul 26, 2020, 13:20 Moritz Mühlenhoff  wrote:

> On Fri, Jul 10, 2020 at 01:07:27PM +0200, Andreas Tille wrote:
> > Hi Moritz,
> >
> > On Tue, Jun 30, 2020 at 08:14:15PM +0200, Moritz Mühlenhoff wrote:
> > >
> > > Given that there's a separate mrtrix3 source package which is ported to
> > > Python 3, should src:mrtrix simply be removed now?
> >
> > I wished Michael or Yaroslav would answer this question.  I'm just
> > helping to maintain this package and do not have the slightest interest
> > in it - may be the interest to see it go to have less work ...
>
> Michael, Yaroslow, what do you think?


Thanks Andreas and Moritz for all your work! I agree that removing this
source package is the the best way forward.

Best,

Michael

Bug#937490: pynifti: Python2 removal in sid/bullseye

[Michael Hanke]

Hi,

yes, that sounds like to best course of action to me.

Best,

Michael

On Mon, Jun 29, 2020, 20:38 Moritz Mühlenhoff  wrote:

> On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote:
> > Package: src:pynifti
> > Version: 0.20100607.1-4.1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> >
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> The upstream homepage states
>
> | PyNIfTI is no longer actively developed. At has been
> | superseded by NiBabel -- a pure-Python package that
> | provides everything that PyNIfTI could do, and a lot more.
>
> Given that nibabel is packaged, let's simply remove pynifti?
>
> Cheers,
> Moritz
>

Bug#963593: Package ready

[Michael Hanke]

The package is done, and in local production use for a few days now. It
is hosted on github at https://github.com/mih/debian-annexremote.git
until DPMT approves my request to join the team.

Lintian 2.80 reports no issues with it.

-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://psychoinformatics.de

Bug#963593: ITP: annexremote -- abstraction for git-annex special remote implementations

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: annexremote
  Version : 1.4.3
  Upstream Author : Silvio Ankermann 
* URL : https://github.com/Lykos153/AnnexRemote
* License : GPL3
  Programming Lang: Python
  Description : abstraction for git-annex special remote implementations


This package is needed for packaging the 0.13 release of the datalad package.
Moreover, it is also used for other special remote implementations, such
as

- https://github.com/Lykos153/git-annex-remote-googledrive
- https://github.com/CONP-PCNO/git-annex-remote-globus

It is a simple package with no dependencies other than Python. I am not
aware of an alternative.

I am using it regularly. I plan to produce a package that is compliant
with the Debian Python Modules Team and have it be team maintained on
salsa.

Bug#937500: No PY3

[Michael Hanke]

Control: retitle -1 "ROM: pyoptical is outdated and not ported to Python3"
Control: reassign -1 ftp.debian.org


-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://psychoinformatics.de

Bug#918843: you have my blessing Re: Bug#918843: ITS: matlab-support

[Michael Hanke]

Hey,



On Wed, Sep 25, 2019, 17:47 Sébastien Villemot  wrote:

> Thanks Yaroslav and Michael for your reply.
>
> I’m going to perform the move to another team. Do you want to remain
> listed as uploaders?
>

I am OK to be removed.

Thanks,

Michael

Bug#918843: you have my blessing Re: Bug#918843: ITS: matlab-support

[Michael Hanke]

Hi,

On Mon, Sep 23, 2019 at 2:45 PM Yaroslav Halchenko  wrote:
> On Sun, 22 Sep 2019, Boyuan Yang wrote:
>
> > Sorry but there hasn't been much progress yet -- recent MATLAB releases have
> > several changes that requires much tweak on matlab-support package and I
> > haven't have enough time into it.
>
> > Given the lack of original maintainers' response in the previous months, I
> > believe it should be reasonable to "salvage" this package and have it team-
> > maintained under either Debian Science Team or the Debian Octave Group. If 
> > you
> > are going to upload any new version of matlab-support, please also consider
> > adding me into the uploaders list.
>
> I am one of the original maintainers (as part of the NeuroDebian Team).
> FWIW, you have my blessing (I will tripple check with Michael in
> person when I have a chance but I think he wouldn't object) to have it
> moved under Debian Science or Octave team maintainership.

Seconded and thanks!

Michael

Bug#889130: O: cctools

[Michael Hanke]

Package: wnpp
Severity: normal

Haven't used this package in a long time and the version in Debian is
two major releases behind upstream. Upstream does not use a standard
build system (but a custom configure script) that can make updates rather
time consuming.

The package has an overall low user count (popcon 43), and could be a
candidate for removal from the archive if nobody is interested in
maintaining it.

Bug#887598: ITP: jasp -- Offers standard analysis procedures in both their classical and Bayesian form

[Michael Hanke]

Hi,

just FYI there is/was a PR on JASP's GitHub with a semi complete packaging.
It had quite a few TODOs, but they should be detailed in the PR. Maybe that
is a useful starting point.

Cheers,

Michael



On Jan 21, 2018 21:35, "Andreas Tille"  wrote:

> Hi Joris,
>
> thanks for this ITP.  Please consider maintaining the package in Debian
> Science team.
>
> Kind regards
>
>   Andreas.
>
> On Thu, Jan 18, 2018 at 11:02:34AM +0100, jo...@jorisgoosen.nl wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Joris Goosen 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> >
> > * Package name: jasp
> >   Version : 0.8.5
> >   Upstream Author : JASP-team 
> > * URL : http://www.jasp-stats.org/
> > * License : GPL
> >   Programming Lang: C++, R
> >   Description : Offers standard analysis procedures in both their
> > classical and Bayesian form
> >
> >  JASP is a cross platform statistical software program with a
> > state-of-the-art
> >  graphical user interface. It offers standard analysis procedures in both
> >  their classical and Bayesian form.
> >  .
> >  It was designed with the user in mind: APA-formatted tables can be
> >  copy-pasted in your word processor, output can be extensively annotated,
> >  adjustment of input options dynamically changes the output, and
> selecting
> >  old output revives the associated input choices for inspection and
> > adjustment.
> >  .
> >  JASP is also statistically inclusive,
> >  as it offers both frequentist and Bayesian analysis methods.
> >  Indeed, the primary motivation for JASP is to make it easier for
> > statistical
> >  practitioners to conduct Bayesian analyses.
> >  .
> >  For more information and tutorials see: https://jasp-stats.org/
> >
> > 
> > This package is useful as it allows scientist, especially in the social
> > sciences, a friendly interface to state-of-the-art statistics techniques
> > and is under active development.
> > I plan to maintain as part of my work as one of the upstream-developers
> and
> > aim to make it fully debian compatible from the get-go.
> >
> > As far as i've understood the information on the debian-wiki we will
> need a
> > sponsor to be able to upload to the debian repositories.
>
> --
> http://fam-tille.de
>
>

Bug#886951: O: arno-iptables-firewall -- single- and multi-homed firewall script with DSL/ADSL support

[Michael Hanke]

Package: wnpp
Severity: normal

I intend to orphan the arno-iptables-firewall package. Popcon is at 468.
Upstream is very pleasant and releases are infrequent. However, I still
lack the resources to take proper care of this package.

The package description is:
 Unlike other lean iptables frontends in Debian, arno-iptables-firewall
 will setup and load a secure, restrictive firewall by just asking a few
 question. This includes configuring internal networks for internet access
 via NAT and potential network services (e.g. http or ssh).
 .
 However, it is in no way restricted to this simple setup. Some catch words
 of additional features, that can be enabled in the well documented
 configuration file are: DSL/ADSL, Port forwarding, DMZ's,
 portscan detection, MAC address filtering.

Bug#879624: Similar issue, also X1 carbon

[Michael Hanke]

Looking into possible known issues for at-spi or gnome-terminal-server
did not bring up anything useful for me.

FTR: Installing xfce4 or kde both gives me a working desktop. So this
might actually be a GNOME issue rather than an X issue, or an
interaction of the two.

On Sat, Nov 4, 2017 at 10:14 AM, Michael Hanke  wrote:
> Update:
>
> I stopped the gdm3 service and started a freshly installed slim login
> manager. I comes right up, no issues.
>
> Starting the GNOME session from slim, however, results in immediate
> failure. This is syslog from the last message of slim to the X server
> shutdown:
>
> Nov  4 09:49:56 meiner slim[8940]: /usr/bin/X11/xauth:  file
> /home/mih/.Xauthority does not exist
> Nov  4 09:49:56 meiner org.a11y.Bus[9347]: Activating service
> name='org.a11y.atspi.Registry'
> Nov  4 09:49:56 meiner org.a11y.Bus[9347]: Successfully activated
> service 'org.a11y.atspi.Registry'
> Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]: SpiRegistry
> daemon is running with well-known name - org.a11y.atspi.Registry
> Nov  4 09:49:56 meiner gnome-terminal-[9379]: gnome-terminal-server:
> Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
> Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]: XIO:  fatal IO
> error 11 (Resource temporarily unavailable) on X server ":0.0"
> Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]:   after 21
> requests (19 known processed) with 0 events remaining.
> Nov  4 09:49:56 meiner org.gtk.vfs.Daemon[9347]: A connection to the
> bus can't be made
> Nov  4 09:49:58 meiner kernel: [  249.268908] [drm] Reducing the
> compressed framebuffer size. This may lead to less power savings than
> a non-reduced-size. Try to increase stolen memory size if available in
> BIOS.
> Nov  4 09:49:58 meiner slim[8940]: (II) Server terminated successfully
> (0). Closing log file.
>
> On Fri, Nov 3, 2017 at 5:02 PM, Michael Hanke  wrote:
>> Hi,
>>
>> same here, after upgrade to buster no X anymore. Normal start works, but
>> ends at terminal login. Manual startx makes the screen flicker briefly, then
>> back to terminal. X log contain no errors (EE).
>>
>> Downgrade to stretch didn't change the situation in any way. Going back from
>> linux 4.13 to 4.8 had no effect either.
>>
>> During downgrade gconf2 choked (triggers hung and never completed). During
>> upgrade I think I saw some gconf error message too, but I cannot find a
>> trace of them anywhere.
>>
>> Any advice would be highly appreciated.
>>
>> Thanks in advance
>>
>> Michael
>>
>
>
>
> --
> Michael Hanke
> http://psychoinformatics.de



-- 
Michael Hanke
http://psychoinformatics.de

Bug#879624: Similar issue, also X1 carbon

[Michael Hanke]

Update:

I stopped the gdm3 service and started a freshly installed slim login
manager. I comes right up, no issues.

Starting the GNOME session from slim, however, results in immediate
failure. This is syslog from the last message of slim to the X server
shutdown:

Nov  4 09:49:56 meiner slim[8940]: /usr/bin/X11/xauth:  file
/home/mih/.Xauthority does not exist
Nov  4 09:49:56 meiner org.a11y.Bus[9347]: Activating service
name='org.a11y.atspi.Registry'
Nov  4 09:49:56 meiner org.a11y.Bus[9347]: Successfully activated
service 'org.a11y.atspi.Registry'
Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]: SpiRegistry
daemon is running with well-known name - org.a11y.atspi.Registry
Nov  4 09:49:56 meiner gnome-terminal-[9379]: gnome-terminal-server:
Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]: XIO:  fatal IO
error 11 (Resource temporarily unavailable) on X server ":0.0"
Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]:   after 21
requests (19 known processed) with 0 events remaining.
Nov  4 09:49:56 meiner org.gtk.vfs.Daemon[9347]: A connection to the
bus can't be made
Nov  4 09:49:58 meiner kernel: [  249.268908] [drm] Reducing the
compressed framebuffer size. This may lead to less power savings than
a non-reduced-size. Try to increase stolen memory size if available in
BIOS.
Nov  4 09:49:58 meiner slim[8940]: (II) Server terminated successfully
(0). Closing log file.

On Fri, Nov 3, 2017 at 5:02 PM, Michael Hanke  wrote:
> Hi,
>
> same here, after upgrade to buster no X anymore. Normal start works, but
> ends at terminal login. Manual startx makes the screen flicker briefly, then
> back to terminal. X log contain no errors (EE).
>
> Downgrade to stretch didn't change the situation in any way. Going back from
> linux 4.13 to 4.8 had no effect either.
>
> During downgrade gconf2 choked (triggers hung and never completed). During
> upgrade I think I saw some gconf error message too, but I cannot find a
> trace of them anywhere.
>
> Any advice would be highly appreciated.
>
> Thanks in advance
>
> Michael
>



-- 
Michael Hanke
http://psychoinformatics.de

Bug#879624: Similar issue, also X1 carbon

[Michael Hanke]

Hi,

same here, after upgrade to buster no X anymore. Normal start works, but
ends at terminal login. Manual startx makes the screen flicker briefly,
then back to terminal. X log contain no errors (EE).

Downgrade to stretch didn't change the situation in any way. Going back
from linux 4.13 to 4.8 had no effect either.

During downgrade gconf2 choked (triggers hung and never completed). During
upgrade I think I saw some gconf error message too, but I cannot find a
trace of them anywhere.

Any advice would be highly appreciated.

Thanks in advance

Michael

Bug#861330: RM: fslview -- ROM; no longer maintained upstream, FTBFS (obsolete dependencies), replacement available

[Michael Hanke]

Package: ftp.debian.org
Severity: normal

The package can no longer be built in unstable.
I just issues an ITP for the replacement #861327

Bug#861327: ITP: fsleyes -- feature-rich viewer for volumetric images

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: fsleyes
  Version : 0.10.1
  Upstream Author : Paul McCarthy 
* URL : https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/
* License : Apache-2
  Programming Lang: Python
  Description : feature-rich viewer for volumetric images

This is the successor of 'fslview' (currently in Debian, but stuck with
Qt4, and needs to be removed). This new viewer is a full replacement,
written in pure Python, using wx.

It requires a number of dependencies to become available in Debian
first. Namely, Python packages: fslpy, props (to be renamed to fsleyes-props),
and indexed_gzip. The latter is presently in NEW. The rest will follow
suit.

Bug#860084: ITP: libxdf -- static C++ library for loading XDF (multi-channel stream format) files

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: libxdf
  Version : 0.93
  Upstream Author : Yida Lin (?)
* URL : https://github.com/Yida-Lin/libxdf
* License : GPL3
  Programming Lang: C++
  Description : static C++ library for loading XDF (multi-channel stream 
format) files


Libxdf is a cross-platform C++ library for loading multimodal,
multi-rate signals stored in XDF files. Libxdf is a core component of
bio-signal viewing application SigViewer. It can also be integrated into
other C++ applications.

The last release is just a few days old.

This is a new dependency of the sigviewer package that needs an update
to version 0.6 (#860083)

This package will be maintained by the NeuroDebian team.

At the moment upstream does not support building a shared library.

Bug#860083: sigviewer: New upstream version (0.6), with no dependency (libxdf, unpackaged)

[Michael Hanke]

Package: sigviewer
Version: 0.5.1+svn556-5
Severity: wishlist

FTR: sigviewer switched to Qt5 and wants libxdf
(https://github.com/Yida-Lin/libxdf) now. libxdf has no upstream supoprt
for building shared libraries.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages sigviewer depends on:
ii  libbiosig1   1.3.0-2.2
ii  libc62.24-9
ii  libcholmod3  1:4.5.4-1
ii  libgcc1  1:6.3.0-6
ii  libqt4-xml   4:4.8.7+dfsg-11
ii  libqtcore4   4:4.8.7+dfsg-11
ii  libqtgui44:4.8.7+dfsg-11
ii  libstdc++6   6.3.0-6

sigviewer recommends no packages.

sigviewer suggests no packages.

-- no debconf information

Bug#860081: biosig4c++: Version 1.8.4b required for sigviewer 0.6 (also not updated in Debian)

[Michael Hanke]

Source: biosig4c++
Severity: wishlist

FYI: Looking into updating sigviewer to 0.6. Noticed that an update of biosig
is a precondition.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#849119: Known for a long time, workaround available

[Michael Hanke]

For the benefit of people reading this:

The problem has been reported upstream repeatedly:

https://www.playonlinux.com/de/issue-5043.html
https://www.playonlinux.com/en/issue-4940.html

The latter of those is over two years old. Doesn't look as if anyone
cares enough.

I have a 2560x1440 laptop screen and playonlinux is unusable as shipped
by Debian. The first report linked above points to a workaround:

--- /usr/share/playonlinux/python/lib/Variables.py  2016-04-09 
16:03:37.0 +0200
+++ /tmp/Variables.py   2017-03-11 09:04:02.795008276 +0100
@@ -49,7 +49,7 @@
 windows_add_size = 0
 windows_add_playonmac = 0
 else:
-windows_add_size = 25
+windows_add_size = 100
 windows_add_playonmac = 0
 
 widget_borders = wx.RAISED_BORDER

I can confirm that this resolves the issue with my screen size, at least
to the degree that the buttons become visible again and any
functionality is available at all.

Sure thing that this isn't a general solution, but better than nothing.


-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://psychoinformatics.de

Bug#851739: python-docutils: Upgrade to 0.13.1 breaks list-table directive

[Michael Hanke]

Package: python-docutils
Version: 0.12+dfsg-1
Severity: normal

Upgrading from 0.12 to 0.13.1 causes this error when processing a
list-table directive within a pelican run.

ERROR: Could not process pages/publications.rst
  | TypeError: unsupported operand type(s) for +=: 'int' and 'str'
  |___
  | Traceback (most recent call last):
  |   File "/usr/lib/python2.7/dist-packages/pelican/generators.py", line 616, 
in generate_context
  | context_sender=self)
  |   File "/usr/lib/python2.7/dist-packages/pelican/readers.py", line 508, in 
read_file
  | content, reader_metadata = reader.read(path)
  |   File "/usr/lib/python2.7/dist-packages/pelican/readers.py", line 230, in 
read
  | pub = self._get_publisher(source_path)
  |   File "/pelican-plugins/bootstrap-rst/bootstrap.py", line 302, in 
_get_publisher
  | pub.publish()
  |   File "/usr/lib/python2.7/dist-packages/docutils/core.py", line 219, in 
publish
  | output = self.writer.write(self.document, self.destination)
  |   File "/usr/lib/python2.7/dist-packages/docutils/writers/__init__.py", 
line 80, in write
  | self.translate()
  |   File "/usr/lib/python2.7/dist-packages/docutils/writers/_html_base.py", 
line 71, in translate
  | self.document.walkabout(visitor)
  |   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
  | if child.walkabout(visitor):
  |   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
  | if child.walkabout(visitor):
  |   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
  | if child.walkabout(visitor):
  |   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 166, in 
walkabout
  | visitor.dispatch_visit(self)
  |   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 1882, in 
dispatch_visit
  | return method(node)
  |   File 
"/usr/lib/python2.7/dist-packages/docutils/writers/html4css1/__init__.py", line 
778, in visit_thead
  | self.write_colspecs()
  |   File 
"/usr/lib/python2.7/dist-packages/docutils/writers/html4css1/__init__.py", line 
289, in write_colspecs
  | width += node['colwidth']
  | TypeError: unsupported operand type(s) for +=: 'int' and 'str'


Downgrade to 0.12 resolves it again (no other changes to package
versions). Version info below is after downgrade.

Failed to produce a minimal RST snippet to show the problem with rst2*
tools directly. Could be interaction with pelican, or the respective plugin.


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

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

Versions of packages python-docutils depends on:
ii  docutils-common  0.12+dfsg-1
ii  python-roman 2.0.0-2
pn  python:any   

Versions of packages python-docutils recommends:
ii  docutils-doc 0.13.1+dfsg-1
ii  libpaper-utils   1.1.24+nmu5
ii  python-pil   3.4.2-1
ii  python-pygments  2.1.3+dfsg-1

Versions of packages python-docutils suggests:
ii  fonts-linuxlibertine [ttf-linux-libertine]  5.3.0-2
pn  texlive-lang-french 
ii  texlive-latex-base  2016.20161130-1
ii  texlive-latex-recommended   2016.20161130-1

-- no debconf information

Bug#835746: fixed in odin-2.0.3: FTBFS: seqgradspiral.cpp:30:71: error: no matching function for call to 'max(double, float)'

[Michael Hanke]

Hi Thies,

I had a quick look at upgrading the package to 2.0.3. I am trying to
build against Qt5 (all the bdeps seem to be there), but the AC setup
does not acknowledge the presence of Qt5 in my test system.

Should this be working?

Thanks,

Michael


-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://psychoinformatics.de

Bug#828269: Info from upstream

[Michael Hanke]

Hi Tim,

thanks for the patch. I did a test build and can confirm that it works.
I am now preparing an upload to Debian proper. Should come within the
next few hours.

Thanks for taking care of this issue!

Michael

On Sat, Nov 26, 2016 at 04:50:21PM -0600, Tim Theisen wrote:
> I have been working on getting HTCondor working with OpenSSL 1.1.
> 
> Although we would prefer to compile with VOMS support, it is preferable
> to turn this off, rather than miss getting into stretch. I have a patch
> to turn off compilation with VOMS. (rules.patch) We should revert this
> patch when the VOMS folks fix up their OpenSSL issues.
> 
> Once the VOMS dependency was eliminated, I found a few minor changes
> that needed to be addressed within HTCondor itself. I have included a
> patch to 8.4.9 (OpenSSL1.1.patch). This update will be released as part
> of the HTCondor 8.4.10 release, expected on December 1st.
> 
> Let me know if you need anything more, ...Tim
> 
> On 11/04/2016 06:31 AM, Michael Hanke wrote:
> > Relaying information from upstream's triaging:
> >
> >
> > 
> > I concluded that the problem was not with HTCondor. It had to do with the
> > following packages: libglobus-gsi-proxy-core, libglobus-gsi-proxy-ssl and
> > voms. The Globus folks addressed the first two issues. However, the VOMS 
> > issue
> > (#828595) is a blocker for us.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828595
> > https://github.com/italiangrid/voms/issues/50
> > 
> > ___
> > htcondor-debian mailing list
> > htcondor-deb...@cs.wisc.edu
> > https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian
> 
> -- 
> Tim Theisen
> Release Manager
> HTCondor & Open Science Grid
> Center for High Throughput Computing
> Department of Computer Sciences
> University of Wisconsin - Madison
> 4261 Computer Sciences and Statistics
> 1210 W Dayton St
> Madison, WI 53706-1685
> +1 608 265 5736
> 

> diff --git a/src/condor_includes/condor_crypt_3des.h 
> b/src/condor_includes/condor_crypt_3des.h
> index e2967d8..dc29b6a 100644
> --- a/src/condor_includes/condor_crypt_3des.h
> +++ b/src/condor_includes/condor_crypt_3des.h
> @@ -61,7 +61,7 @@ class Condor_Crypt_3des : public Condor_Crypt_Base {
>  //--
>  // Private constructor
>  //--
> -des_key_schedule  keySchedule1_, keySchedule2_, keySchedule3_;
> +DES_key_schedule  keySchedule1_, keySchedule2_, keySchedule3_;
>  unsigned char ivec_[8];
>  int   num_;
>  };
> diff --git a/src/condor_io/condor_auth_ssl.cpp 
> b/src/condor_io/condor_auth_ssl.cpp
> index b8bb6cf..3c366b3 100644
> --- a/src/condor_io/condor_auth_ssl.cpp
> +++ b/src/condor_io/condor_auth_ssl.cpp
> @@ -36,7 +36,9 @@
>  #endif
>  
>  // Symbols from libssl
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
>  static long (*SSL_CTX_ctrl_ptr)(SSL_CTX *, int, long, void *) = NULL;
> +#endif
>  static void (*SSL_CTX_free_ptr)(SSL_CTX *) = NULL;
>  static int (*SSL_CTX_load_verify_locations_ptr)(SSL_CTX *, const char *, 
> const char *) = NULL;
>  #if OPENSSL_VERSION_NUMBER < 0x1000L
> @@ -55,8 +57,12 @@ static void (*SSL_free_ptr)(SSL *) = NULL;
>  static int (*SSL_get_error_ptr)(const SSL *, int) = NULL;
>  static X509 *(*SSL_get_peer_certificate_ptr)(const SSL *) = NULL;
>  static long (*SSL_get_verify_result_ptr)(const SSL *) = NULL;
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
>  static int (*SSL_library_init_ptr)() = NULL;
>  static void (*SSL_load_error_strings_ptr)() = NULL;
> +#else
> +static int (*OPENSSL_init_ssl_ptr)(uint64_t, const OPENSSL_INIT_SETTINGS *) 
> = NULL;
> +#endif
>  static SSL *(*SSL_new_ptr)(SSL_CTX *) = NULL;
>  static int (*SSL_read_ptr)(SSL *, void *, int) = NULL;
>  static void (*SSL_set_bio_ptr)(SSL *, BIO *, BIO *) = NULL;
> @@ -79,7 +85,11 @@ Condor_Auth_SSL :: Condor_Auth_SSL(ReliSock * sock, int /* 
> remote */)
>  
>  Condor_Auth_SSL :: ~Condor_Auth_SSL()
>  {
> +#if OPENSSL_VERSION_NUMBER < 0x1000L
>  ERR_remove_state( 0 );
> +#elif OPENSSL_VERSION_NUMBER < 0x1010L
> +ERR_remove_thread_state( 0 );
> +#endif
>   if(m_crypto) delete(m_crypto);
>  }
>  
> @@ -96,7 +106,9 @@ bool Condor_Auth_SSL::Initialize()
>  
>   if ( Condor_Auth_Kerberos::Initialize() == false ||
>(dl_hdl = dlopen(LIBSSL_SO, RTLD_LAZY)) == NULL ||
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
>!(SSL_CTX_ctrl_ptr = (long (*)(SSL_CTX *, int, long, void 
> *))dlsym(dl_hdl, "SSL_CTX_ctrl")) ||

Bug#843397: python-rdflib-jsonld: Requires python-rdflib 4.2.1 to work properly with schema.org contexts

[Michael Hanke]

Package: python-rdflib-jsonld
Version: 0.4.0-1
Severity: important


The full protocol of the issue and resolution is here:

https://github.com/RDFLib/rdflib-jsonld/issues/42

In short: python-rdflib needs to be upgraded in order get correct http
requests required to obtain jsonld context from schema.org

Given the prominent role of schema.org in the context of JSON-LD, I am
setting the severity to important.


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

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

Versions of packages python-rdflib-jsonld depends on:
ii  python-rdflib  4.1.2-3
pn  python:any 

python-rdflib-jsonld recommends no packages.

python-rdflib-jsonld suggests no packages.

-- no debconf information

Bug#837402: Thanks

[Michael Hanke]

Thanks Adrian!

Will upload when #828269 has been dealt with.

Michael

-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://psychoinformatics.de

Bug#828269: Info from upstream

[Michael Hanke]

Relaying information from upstream's triaging:



I concluded that the problem was not with HTCondor. It had to do with the
following packages: libglobus-gsi-proxy-core, libglobus-gsi-proxy-ssl and
voms. The Globus folks addressed the first two issues. However, the VOMS issue
(#828595) is a blocker for us.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828595
https://github.com/italiangrid/voms/issues/50

Bug#833880: patool: Please provide python(3)-patoolib package

[Michael Hanke]

Hey,

thanks a lot for implementing this!

It sure works for me. However, I am uncertain whether Debian Python policy
would mandate dedicated python{3}-patoolib packages. You might want to
double-check that.

I didn't do a full review, but I noticed one tiny thing:

Vcs-Git URL wrong in debian/control

Any of these should do it:
https://anonscm.debian.org/git/collab-maint/patool.git
git://anonscm.debian.org/collab-maint/patool.git

You can verify with `debcheckout patool` that the current URL is wrong.

Thanks!

Michael


On Sun, Sep 11, 2016 at 1:02 PM, Abhijith PA 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello
>
> I pushed the changes to alioth. Can you check whether it fixes the
> currrent problem . If it is okay I can upload .
> https://anonscm.debian.org/cgit/collab-maint/patool.git
>
>
> Sorry for taking too much time .
>
>
> - --
> Abhijith PA (bhe)
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJX1TnZAAoJEIY9TfLtnCjvP1MP/2lT5E2sJBTDCmXX0di7TcmX
> 1GW73BOHhbpp6L6GVKuCrkgSGU7YbcwdhLoUMABqtcPGP8cYwz6kWeKfpPFOt6FX
> Ce6XAVXc47A8+fTWJDuYjf/VaFEEuPzRSPTEZnhuA71ZUxHv3nxqZ/13N6UqY2IX
> jUdxsOR5ds8cvnvm3oqfsjIz30xRU2AdZlOFse1Ht0QdmLIQ9aaAsPLtoqF7VKpP
> z/Ea7oNPCrGRpdtc7/pBBcgX0aJhcuARabLBWqnn+8mVU8HPqx4DGlYr0jb1/5BD
> cxP7FVKGD2KnfkqJu2Ej8ALHHueJvDJOsDjlEegPMmUPD/IvoKhgGRcMnQbxp4m0
> N9bMA5eR3qk0HMD5PU0Hm+Ys3sN6SkCQutDR4pEo2M8lyb6ypvCGtAyDPVaQBisZ
> /OvSFRfgTFA1LafD/9IuuV584iNirmHwO5kpqXIX6Lp5b96yXFr73v4HVCWWLxGJ
> 8ajX/gt+tgVttM7GlkczarFs8MMStbtqz1lTM1eY49TGXqLE37DqJ3HaZK1A+OK3
> JyWcfluWX8ghZnAt7Fg7V3iL/FcRUbW4Axz/p74iIlDnUMcoGa8z4VgbdznCLU5j
> t8C4NrNOIdgos9Ga1ZgYWz9hkRISArsIys9b1ACDX95sebzk+s8JaL10hQ6w6Pa+
> Cg6yQf4cue6Ioop+bvYd
> =TiVW
> -END PGP SIGNATURE-
>

Bug#835493: ITP: indexed-gzip -- fast random access of gzip files in Python

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: indexed-gzip
  Version : 0.1
  Upstream Author : Paul D McCarthy
* URL : https://github.com/pauldmccarthy/indexed_gzip
* License : BSDish https://opensource.org/licenses/zlib-license.php
  Programming Lang: Python
  Description : fast random access of gzip files in Python

[from the README]

The indexed_gzip project is a Python extension which aims to provide a
drop-in replacement for the built-in Python gzip.GzipFile class, the
IndexedGzipFile.

The standard gzip.GzipFile class exposes a random access-like interface
(via its seek and read methods), but every time you seek to a new point
in the uncompressed data stream, the GzipFile instance has to start
decompressing from the beginning of the file, until it reaches the
requested location.

An IndexedGzipFile instance gets around this performance limitation by
building an index, which contains seek points, mappings between
corresponding locations in the compressed and uncompressed data streams.
Each seek point is accompanied by a chunk (32KB) of uncompressed data
which is used to initialise the decompression algorithm, allowing us to
start reading from any seek point. If the index is built with a seek
point spacing of 1MB, we only have to decompress (on average) 512KB of
data to read from any location in the file.

Performance comparison:
https://github.com/pauldmccarthy/indexed_gzip#performance

This needs to be packaged as a dependency of a replacement of the
`fslview` (https://packages.debian.org/sid/fslview) package, which will
not make it into the next release due to its dependencies on obsolete
code (Qt4, ...).

This will be maintained by the NeuroDebian team.

Bug#814635: htcondor: unowned directory after purge: /var/lib/systemd/coredump/

[Michael Hanke]

Hi,

On Sat, Feb 13, 2016 at 04:47:21PM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package left unowned
> directories on the system after purge, which is a violation of
> policy 6.8:
> 
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails



> If the package would ship this as an empty directory, dpkg would take
> care of the creation and removal (if it's empty).
> 
> >From the attached log (scroll to the bottom...):
> 
> 1m30.4s ERROR: FAIL: Package purging left files on system:
>   /var/lib/systemd/coredump/   not owned

This is the directory where systemd places its coredumps. Its creation
might be triggered by condor configuring how to perform coredumps in
this test, but I cannot see any code that would manually create it. I
think it is systemd that creates it.

The path of this specific directory depends on systemd. So if I ship
this in the package and systemd changes its behavior, this issue would
resurface.

Michael

-- 
Michael Hanke
GPG: 4096R/C073D2287FFB9E9B
http://mih.voxindeserto.de

Bug#833880: patool: Please provide python(3)-patoolib package

[Michael Hanke]

Source: patool
Severity: wishlist

Currently it is impossible to use patool's Python API from Python 3
applications. It would be nice to have support for Python 3. Looking at
upstream they seem to support Python 3 alright.

Thanks!

Bug#829424: psychopy: ioHub uses inappropriate PID file location

[Michael Hanke]

Package: psychopy
Version: 1.83.04.dfsg-2
Severity: normal

When using PsychoPy in an IPython session the following happens:



In [1]: import psychopy.iohub as iohub
In [2]: io = iohub.launchHubServer()
---
IOError   Traceback (most recent call last)
 in ()
> 1 io = iohub.launchHubServer()

/usr/lib/python2.7/dist-packages/psychopy/iohub/client/__init__.pyc in 
launchHubServer(**kwargs)
   1502 #print "IOHUB CONFIG: ",ioConfig
   1503 # Start the ioHub Server
-> 1504 return ioHubConnection(ioConfig)
   1505 
   1506 ### ioHubExperimentRuntime 

/usr/lib/python2.7/dist-packages/psychopy/iohub/client/__init__.pyc in 
__init__(self, ioHubConfig, ioHubConfigAbsPath)
283 
284 self._shutdown_attempted=False
--> 285 self.iohub_status = self._startServer(ioHubConfig, 
ioHubConfigAbsPath)
286 if self.iohub_status != "OK":
287 raise RuntimeError("Error starting ioHub server: 
%s"%(self.iohub_status))

/usr/lib/python2.7/dist-packages/psychopy/iohub/client/__init__.pyc in 
_startServer(self, ioHubConfig, ioHubConfigAbsPath)
988 self.registerPygletWindowHandles(*whs)
989 
--> 990 iopFile= open(iopFileName,'w')
991 iopFile.write("ioHub PID: "+str(Computer.iohub_process_id))
992 iopFile.flush()

IOError: [Errno 13] Permission denied: '/usr/bin/.iohpid'


The reason is that in psychopy/iohub/client/__init__.py line 904 the
path of sys.argv[0] is used as the location to place a PID file.
Obviously, this fails for a system install of IPython.

It seems that this isn't the only time this paradigm is used:

% grep -R "rootScript"  .
./iohub/client/__init__.py:rootScriptPath = os.path.dirname(sys.argv[0])
./iohub/util/targetpositionsequence.py:rootScriptPath = 
os.path.dirname(sys.argv[0])
./iohub/launchHubProcess.py:rootScriptPathDir=sys.argv[2]

A solution for Debian could be to replace this with /var/run/user/.../psychopy,
but upstream may want to adopt a more general solution. appdirs doesn't
seem to support such, though.




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

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

Versions of packages psychopy depends on:
ii  python 2.7.11-1
ii  python-configobj   5.0.6-2
ii  python-lxml3.6.0-1
ii  python-matplotlib  1.5.1-1+b1
ii  python-numpy   1:1.10.4-2
ii  python-opengl  3.0.2-1
ii  python-pygame  1.9.1release+dfsg-10+b1
ii  python-pyglet  1.1.4.dfsg-3
ii  python-scipy   0.17.0-1+b1

Versions of packages psychopy recommends:
ii  ipython  2.4.1-1
ii  libxxf86vm1  1:1.1.4-1
ii  python-gevent1.1.1-1
ii  python-imaging   3.1.1-1
ii  python-msgpack   0.4.6-1+b2
pn  python-opencv
ii  python-openpyxl  2.3.0-1
ii  python-pandas0.17.1-3
ii  python-psutil3.4.2-1+b1
ii  python-pygame1.9.1release+dfsg-10+b1
ii  python-pyglet1.1.4.dfsg-3
ii  python-pyo   0.7.9-1
ii  python-serial3.0.1-1
ii  python-wxgtk2.8  2.8.12.1+dfsg2-2
ii  python-wxgtk3.0  3.0.2.0+dfsg-1+b1
ii  python-xlib  0.14+20091101-5
ii  python-yaml  3.11-3+b1

Versions of packages psychopy suggests:
pn  libavbin0  
pn  python-iolabs  
pn  python-pyxid   

-- no debconf information

Bug#755181: Upstream Merge

[Michael Hanke]

Dear Barak,

On Tue, Mar 29, 2016 at 12:42:51PM +0100, Barak A. Pearlmutter wrote:
> I did a quick merge to the latest upstream.
> 
> git://anonscm.debian.org/~bap/cctools.git
> 
> If someone who uses this package a lot would test it, that would be fantastic.

Thanks a lot for updating the package. I gave it a pass. It seems the
dh_auto_clean logic is no longer valid. There is no Makefile.config
generated anymore and cleaning isn't done because of that.

After manual clean the package built without error, using the tarball of
5.4.6 that you commited. I noticed the following warning:

W: dh_python2:479: Please add dh-python package to Build-Depends
W: dh_python2:331: Python 3.x location detected, please use dh_python3:
debian/python-workqueue/usr/lib/python3.5

likely leading to lintian:

W: python-workqueue: python-module-in-wrong-location 
usr/lib/python3.5/site-packages/_work_queue.so 
usr/lib/python3/dist-packages/_work_queue.so
W: python-workqueue: python-module-in-wrong-location 
usr/lib/python3.5/site-packages/work_queue.py 
usr/lib/python3/dist-packages/work_queue.py

and there is also this:

E: coop-computing-tools: embedded-library usr/bin/chirp_server: sqlite

I guess those need fixing.


Upon install I saw this:

dpkg: error processing archive ../coop-computing-tools_5.4.6-1_amd64.deb 
(--install):
 trying to overwrite '/usr/bin/prune', which is also in package graphviz 
2.38.0-12+b2

An unfortunate name choice -- probably easiest to resolve in the scope
of this package with a rename.

If you have time to keep working on the package, please do not hesitate to add
yourself as an uploader. I'll do my best to review updates, if you are
interested.

Thanks again,

Michael


-- 
Michael Hanke
http://mih.voxindeserto.de

Bug#817195: Same observation

[Michael Hanke]

Hi,

On Sat, Mar 19, 2016 at 01:38:51PM +0100, Julien Cristau wrote:
> On Tue, Mar 15, 2016 at 15:34:18 +0100, Michael Hanke wrote:
> > If this package is responsible, the most recent upgrade in my system
> > happened on 2016-03-11, upgrading from 2.99.917-2 to
> > 2.99.917+git20160218-1.
> > 
> Your best bet is probably to actually check if reverting to an older
> version of the intel driver fixes the issue, and if it does, to file
> this upstream per
> https://01.org/linuxgraphics/documentation/development/how-report-bugs

A similar bugs has already been reported:

https://bugs.freedesktop.org/show_bug.cgi?id=94578

Michael

Bug#818384: Duplicate

[Michael Hanke]

This is likely a duplicate of https://bugs.debian.org/817195

Bug#817195: Duplicate

[Michael Hanke]

Likely duplicate: https://bugs.debian.org/818384

Bug#817195: Same observation

[Michael Hanke]

Hi,

I seem to observe the exact same behavior on a machine with a different
chipset

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
Graphics Controller (rev 09)

and using a Display Port connection. Gnome shell in use also. It doesn't
depend on the particular DP device connected, and the behavior was
introduced by (or co-occurred with) a recent package upgrade.

If this package is responsible, the most recent upgrade in my system
happened on 2016-03-11, upgrading from 2.99.917-2 to
2.99.917+git20160218-1.

Thanks,

Michael

Bug#810945: New dependency set

[Michael Hanke]

Forgot one thing. Here is the new set of dependency for the experimental
upload of ODIN 2.0

libdcmtk-dev | libdcmtk2-dev | libdcmtk1-dev,
libdcmtk2v5,
dcmtk

I was able to get a successful build with it. Any advice on how to
optimze that (apart from ignoring the past) is appreciated.

Thanks,

Michael

Bug#810945: Useless dependencies

[Michael Hanke]

This dependency setting is motivated by the need for 'dicom.dic' which
has moved a lot in the past. Currently

% apt-file search dicom.dic
libdcmtk2: /usr/share/libdcmtk2/dicom.dic
libdcmtk2v5: /usr/share/libdcmtk2/dicom.dic
libdcmtk4v5: /usr/share/libdcmtk4/dicom.dic
libdcmtk5: /usr/share/libdcmtk5/dicom.dic

This is required for the tests to run. This package is often backported
and it would be a hassle to have to modify it for each an every target.

If you have a suggestion on how to do this better, I'd be happy to
implement it. At the moment I don't see how this bug is severity
important.

Thanks,

Michael

Bug#810165: closed by Yaroslav Halchenko (Bug#810165: fixed in ants 2.1.0-3)

[Michael Hanke]

Hi,

out of curiosity: where is the harm in a "useless" alternative dependency
that enables people to easily build backports without tinkering with the
package?

Michael

On Sun, Jan 10, 2016 at 10:54 AM, Tobias Frost  wrote:

> Am Samstag, den 09.01.2016, 22:55 -0500 schrieb Yaroslav Halchenko:
> >
> >
> > but ok -- will list libpng-dev as the first and alternative libpng12
> > and will see how it goes
> >
>
> *sigh* ok, even if the libpng12-dev is superficious. (It creates more
> work, as I will file a bug to remove it once the transistion have
> started and you'll need another sourceful upload.)
>



-- 
Michael Hanke
http://mih.voxindeserto.de

Bug#798170: Almost done

[Michael Hanke]

FTR: I was able to build the latest upstream release (2.0.0) against the
QWT package (6.1) in experimental. However, a linking problem (get's
linked against Qt4 and Qt5) causes the main GUI to segfault. I contacted
upstream to get this solved. Will upload to experimental once this is
done.

Bug#798058: Info

[Michael Hanke]

FTR: The test fails, because the dtype of the metadata array in the test
file changes during the read/write cycle in the test. The actual content
is unchanges though.

After initial write:

array([['dt', '0.1'],
   ['first_id', '0'],
   ['first_index', '0'],
   ['label', 'population0'],
   ['last_id', '4'],
   ['last_index', '5'],
   ['n', '505'],
   ['size', '5'],
   ['units', 'mV'],
   ['variable', 'v']], 
  dtype='|S11')

and after the re-write:

array([['dt', '0.1'],
   ['first_id', '0'],
   ['first_index', '0'],
   ['label', 'population0'],
   ['last_id', '4'],
   ['last_index', '5'],
   ['n', '505'],
   ['size', '5'],
   ['units', 'mV'],
   ['variable', 'v']], 
  dtype='|S32')

Not yet clear on how this happens.

ttfn

Bug#805819: libqwt-qt5-dev now in experimental

[Michael Hanke]

FTR: libqwt-qt5-dev is now available in experimental -- a 2.0.0 puload
to experimental seems possible.

Bug#805819: No update to Odin 2.0.0 possible

[Michael Hanke]

Hi,

thanks for the patch. I tried to prepare a new upstream version (2.0.0) for
upload, but it is deadlocked (like other packages) in the impossible
transition to VTK6+Qt5 without a version of QWT for Qt5 being available.

So instead of an upstream update, the next upload will be a patched
1.8.8.

Thanks,

Michael

Bug#798040: ITP: dcmstack -- DICOM to Nifti conversion

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: dcmstack
  Version : 0.6.2
  Upstream Author : Brendan Moloney 
* URL : https://github.com/moloney/dcmstack
* License : MIT
  Programming Lang: Python
  Description : DICOM to Nifti conversion

 DICOM to Nifti conversion with the added ability to extract and summarize
 meta data from the source DICOMs. The meta data can be injected into a
 Nifti header extension or written out as a JSON formatted text file.
 .
 This package provides the Python package, command line tools (dcmstack,
 and nitool), as well as the documentation in HTML format.


This package is necessary for creating datsasets that are fully
compliant with and utilize all features of the BRAIN IMAGING DATA
STRUCTURE standard:

http://bids.neuroimaging.io

This is a new community norm for open-data in neuroimaging research.

This package will be maintained by the NeuroDebian team.

Bug#749531: Still not compiling with vtk6

[Michael Hanke]

Hi,

I looked into converting fslview to Qt5, but that doesn't seem to be an
option. QWT is a build-dependency, but the latest version 6 is not yet
available for Qt5. That seems to be a blocker right now.

Michael

Bug#749531: Still not compiling with vtk6

[Michael Hanke]

Just for the record. I still fail to compile this package with vtk6.
VTK6.1 shows the previous Qt5 linker resolution issue. VTK6.1 fails due
to some MOC incompatibility, ala:

/home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview/moc_application.cxx:15:2:
 error: #error "This file was generated using the moc from 5.4.2. It"
 #error "This file was generated using the moc from 5.4.2. It"
  ^
/home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview/moc_application.cxx:16:2:
 error: #error "cannot be used with the include files from this version of Qt."
 #error "cannot be used with the include files from this version of Qt."
  ^
/home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview/moc_application.cxx:17:2:
 error: #error "(The moc has changed too much.)"
 #error "(The moc has changed too much.)"
  ^
/home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview/moc_application.cxx:22:5:
 error: ‘QByteArrayData’ does not name a type
 QByteArrayData data[37];

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de

Bug#792758: bwidget vs. fsl incompatibility

[Michael Hanke]

Hi,

thanks for the report and sorry for the delay. I can reproduce it,
as soon as I install bwidget -- which is not a dependency of FSL.

I'll look into it.

Michael

Bug#795672: [neurodebian-desktop] Add dependency on reportbug-ng

[Michael Hanke]

Package: neurodebian-desktop
Version: 0.37.2
Severity: normal

--- Please enter the report below this line. ---

I would like to recommend people to report bugs with a convenient tool.
Hence, I'd prefer to have reportbug-ng be available and refer to it in
the documentation.

This bug is actually filed with reportbug-ng. While it is not extremely
more convenient, it is more convenient.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16-2-amd64

Debian Release: stretch/sid
  650 testing security.debian.org 
  650 testing http.debian.net 
  500 stretch neuro.debian.net 
  500 stable  dl.google.com 
  500 dataneuro.debian.net 

--- Package information. ---
Depends (Version) | Installed
=-+-===
ssh-askpass-gnome | 
 OR ssh-askpass   | 1:1.2.4.1-9
desktop-base  | 8.0.2
gnome-icon-theme  | 3.12.0-1
neurodebian-popularity-contest| 0.37.2


Package's Recommends field is empty.

Package's Suggests field is empty.




-- 
Michael Hanke
http://mih.voxindeserto.de

Bug#792279: ITP: nilearn -- fast and easy statistical learning on neuroimaging data

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: nilearn
  Version : 0.1.3
  Upstream Author : Gael Varoquaux 
* URL : https://github.com/nilearn/nilearn
* License : BSD
  Programming Lang: Python
  Description : fast and easy statistical learning on neuroimaging data

 This Python module leverages the scikit-learn toolbox for multivariate
 statistics with applications such as predictive modelling, classification,
 decoding, or connectivity analysis.

As such, it extends the reach of sklearn (python-sklearn) into the
neuroimaging domain.

The package will be maintained by the NeuroDebian team.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772232: htcondor: bashism in /bin/sh script

[Michael Hanke]

Hi,

thanks for the report.

On Sat, Dec 06, 2014 at 01:17:17PM +0100, Raphael Geissert wrote:
> > possible bashism in ./etc/init.d/condor line 167 (unsafe echo with
> > backslash):
> > echo "$@""\c"

This is located in a code block that is only executed when "echo -n"
doesn't work. This should no be the case in Debian, as Debian policy
suggest the use of this construct for init script.

I have fixed all other issues.

Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671467: condor: Build system setup cannot handle kFreeBSD

[Michael Hanke]

The kfreebsd failure is not the only issue with the suboptimal detection
of environments based on OS names in Condor's cmake setup. #780517 is
another example.

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#780517: condor FTBFS on raspbian and probablly other derivatives due to fragile OS detection code.

[Michael Hanke]

Hi,

On Sun, Mar 15, 2015 at 01:14:14PM +, peter green wrote:
> Package: condor
> 
> Condor started failing to build on raspbian after we started identifying as
> ourselves rather than as Debian. An example of such a failure can be seen
> at.
> 
> http://buildd.raspbian.org/status/fetch.php?pkg=condor&arch=armhf&ver=8.2.1~dfsg.1-1&stamp=1406013132
> >CMake Error at externals/bundles/cream/1.14.0/CMakeLists.txt:263 (if):
> >   if given arguments:
> >
> > "MATCHES" "rhel6" "OR" "MATCHES" "centos6" "OR" "MATCHES" "sl6"
> >
> >   Unknown arguments specified
> >
> >
> >-- Configuring incomplete, errors occurred!
> I strongly suspect that other derivatives are affected as well.
> 
> To get things building for us I added raspbian to the list of recognised
> distros but I don't consider that a good long term soloution. Really code
> that needs to identify distros should make use of /etc/os-release and if it
> can't find an exact distro match should use the id_like parameter in that
> file to identify what family the distro comes from. I have no clue how to
> implement that in cmake though.
> 
> http://debdiffs.raspbian.org/main/c/condor/condor_8.2.3~dfsg.1-5%2brpi1.debdiff

Thanks for the patch. I will include your fix in the upload of HTCondor
8.2.8, but I agree that this should be dealt with in a more general way.
I am CC'ing the Condor devs.

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784778: FTBFS: no matching function for call to 'condor_sockaddr::condor_sockaddr(const soap::*)'

[Michael Hanke]

Hi,

On May 14, 2015 00:45, "peter green"  wrote:
>
> Tags 784778 +patch
> thanks
>
>> During a binNMU of condor for the gsoap transition, the following error
was
>> encountered on all architectures:
>>
>> /«PKGBUILDDIR»/src/condor_schedd.V6/soap_scheddStub.cpp: In function
'bool stub_prefix(const char*, const soap*, int, int, DCpermission, bool,
soap_schedd::condor__Transaction*&, soap_schedd::condor__Status&,
ScheddTransaction*&)':
>> /«PKGBUILDDIR»/src/condor_schedd.V6/soap_scheddStub.cpp:289:36: error:
no matching function for call to 'condor_sockaddr::condor_sockaddr(const
soap::*)'
>>  condor_sockaddr addr(&soap->peer);
>
> The attatched debdiff made the package build in my sid amd64 chroot. It
has not been tested beyond that. It will be uploaded to raspbian soon after
merging it with existing raspbian changes. I have no intent to NMU in
Debian.

Thanks a lot. I'll take a look and upload ASAP.

Michael

Bug#775521: unblock: condor/8.2.3~dfsg.1-6

[Michael Hanke]

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

Please unblock package condor

After you positive feedback I want to upload a package update that
fixes:

https://bugs.debian.org/775276

I am attaching the debdiffs for source and binary packages.

Thanks!

unblock condor/8.2.3~dfsg.1-6

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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru condor-8.2.3~dfsg.1/debian/changelog condor-8.2.3~dfsg.1/debian/changelog
--- condor-8.2.3~dfsg.1/debian/changelog	2014-12-05 21:10:33.0 +0100
+++ condor-8.2.3~dfsg.1/debian/changelog	2015-01-16 18:59:28.0 +0100
@@ -1,3 +1,12 @@
+condor (8.2.3~dfsg.1-6) unstable; urgency=medium
+
+  [Alex Waite]
+  * Upstream security fix: Authenticated users could execute arbitrary code as
+the condor user due to a bug in the way the condor daemon sent email
+notifications (CVE-2014-8126). (Closes: #775276)
+
+ -- Michael Hanke   Fri, 16 Jan 2015 18:59:12 +0100
+
 condor (8.2.3~dfsg.1-5) unstable; urgency=medium
 
   * Fix wrong default SPOOL location introduced with 8.2.3~dfsg.1-4. Whenever
diff -Nru condor-8.2.3~dfsg.1/debian/patches/CVE-2014-8126.patch condor-8.2.3~dfsg.1/debian/patches/CVE-2014-8126.patch
--- condor-8.2.3~dfsg.1/debian/patches/CVE-2014-8126.patch	1970-01-01 01:00:00.0 +0100
+++ condor-8.2.3~dfsg.1/debian/patches/CVE-2014-8126.patch	2015-01-16 18:53:02.0 +0100
@@ -0,0 +1,224 @@
+From e891cea9970496aac74caf72604475a2b7e6a0ca Mon Sep 17 00:00:00 2001
+From: Florian Weimer 
+Date: Tue, 9 Dec 2014 16:09:03 -0600
+Subject: [PATCH] Update command line flags for modern /bin/mail and add option
+ to use sendmail. #4764
+
+---
+ src/condor_utils/email.cpp | 137 -
+ 1 file changed, 110 insertions(+), 27 deletions(-)
+
+diff --git a/src/condor_utils/email.cpp b/src/condor_utils/email.cpp
+index 574d0bb..396d287 100644
+--- a/src/condor_utils/email.cpp
 b/src/condor_utils/email.cpp
+@@ -45,12 +45,21 @@ static FILE *email_open_implementation(char *Mailer,
+ static FILE *email_open_implementation(const char * final_args[]);
+ #endif
+ 
++static void email_write_headers(FILE *stream,
++const char *FromAddress,
++const char *FinalSubject,
++const char *Addresses,
++int NumAddresses);
++static void email_write_header_string(FILE *stream, const char *data);
++
++
+ extern DLL_IMPORT_MAGIC char **environ;
+ 
+ FILE *
+ email_open( const char *email_addr, const char *subject )
+ {
+-	char *Mailer;
++	char *Sendmail = NULL;
++	char *Mailer = NULL;
+ 	char *SmtpServer = NULL;
+ 	char *FromAddress = NULL;
+ 	char *FinalSubject;
+@@ -61,12 +70,6 @@ email_open( const char *email_addr, const char *subject )
+ 	int arg_index;
+ 	FILE *mailerstream;
+ 
+-	if ( (Mailer = param("MAIL")) == NULL ) {
+-		dprintf(D_FULLDEBUG,
+-			"Trying to email, but MAIL not specified in config file\n");
+-		return NULL;
+-	}
+-
+ 	/* Take care of the subject. */
+ 	if ( subject ) {
+ 		size_t prolog_length = strlen(EMAIL_SUBJECT_PROLOG);
+@@ -92,7 +95,6 @@ email_open( const char *email_addr, const char *subject )
+ 	if ( (SmtpServer=param("SMTP_SERVER")) == NULL ) {
+ 		dprintf(D_FULLDEBUG,
+ 			"Trying to email, but SMTP_SERVER not specified in config file\n");
+-		free(Mailer);
+ 		free(FinalSubject);
+ 		if (FromAddress) free(FromAddress);
+ 		return NULL;
+@@ -110,7 +112,6 @@ email_open( const char *email_addr, const char *subject )
+ 		if ( (FinalAddr = param("CONDOR_ADMIN")) == NULL ) {
+ 			dprintf(D_FULLDEBUG,
+ "Trying to email, but CONDOR_ADMIN not specified in config file\n");
+-			free(Mailer);
+ 			free(FinalSubject);
+ 			if (FromAddress) free(FromAddress);
+ 			if (SmtpServer) free(SmtpServer);
+@@ -136,7 +137,6 @@ email_open( const char *email_addr, const char *subject )
+ 	}
+ 	if (num_addresses == 0) {
+ 		dprintf(D_FULLDEBUG, "Trying to email, but address list is empty\n");
+-		free(Mailer);
+ 		free(FinalSubject);
+ 		if (FromAddress) free(FromAddress);
+ 		if (SmtpServer) free(SmtpServer);
+@@ -144,6 +144,19 @@ email_open( const char *email_addr, const char *subject )
+ 		return NULL;
+ 	}
+ 
++	Sendmail = param("SENDMAIL");
++	Mailer = param("MAIL");
++
++	if ( Mailer == NULL && Sendmail == NULL ) {
++		dprintf(D_FULLDEBUG,
++			"Trying to email, but MAIL and SENDMAIL not specified in config file\n");
++		free(FinalSubject);
++		free(FromAddress);
++		free(SmtpServer);
++		free(FinalAddr);
++		return NULL;
++	}
++
+ 	/* construct the argument vector for the mailer */
+ 	//char const * 

Bug#698386: Is there a future for ITKSNAP?

[Michael Hanke]

Hi Gert,

On Fri, Jan 16, 2015 at 10:39 AM, Michael Hanke 
wrote:

> I am currently building the package, and if that shows no problems, I will
> upload after a bit of testing. Few more things:
>
> - I'd target "experimental" not unstable (solely for not causing problems
> with the stable release) -- I hope you agree
>
> - I'd be glad if you could see yourself as a maintainer of this package!
> If you are OK with that, please add yourself as an uploader, so I can
> simply sponsor the upload.
>
>
Two more things: Both bugs that are open against itksnap can be closed with
this upload.

Thanks,

Michael


-- 
Michael Hanke
http://mih.voxindeserto.de

Bug#698386: Is there a future for ITKSNAP?

[Michael Hanke]

Hi Gert,

On Thu, Jan 15, 2015 at 5:12 PM, Gert Wollny  wrote:

> Hello,
>
> I've now upload the latest changes, with that the package should be okay
> for upload.
>
> Additional changes:
>
>  * eliminated lintian warning: menu-icon-uses-relative-path
>  * added watch file
>  * corrected dependencies
>  * builds in sid pbuilder amd64
>

Great!

There are still some lintian info messages left:
>
> spelling-error-in-binary
>usr/lib/snap-3.2.0/ITK-SNAP baloon balloon
>
> desktop-entry-contains-encoding-key
>usr/share/applications/itksnap.desktop:2 Encoding
>
> itksnap: desktop-entry-lacks-keywords-entry
> usr/share/applications/itksnap.desktop
>

They look like they need to be forwarded upstream, but should not hold up
an upload.

I am currently building the package, and if that shows no problems, I will
upload after a bit of testing. Few more things:

- I'd target "experimental" not unstable (solely for not causing problems
with the stable release) -- I hope you agree

- I'd be glad if you could see yourself as a maintainer of this package! If
you are OK with that, please add yourself as an uploader, so I can simply
sponsor the upload.


Thanks again for all your effort!

Michael


-- 
Michael Hanke
http://mih.voxindeserto.de

Bug#698386: Is there a future for ITKSNAP?

[Michael Hanke]

Hi Gert,
On Jan 14, 2015 5:08 PM, "Gert Wollny"  wrote:
>
> Hello all,
>
> now that Paul provided an official upstream tarball I took the liberty
> to update the itksnap package to version 3.2.0 in the packaging git on
> alioth.  There is still a lintian warning about
>
> menu-icon-uses-relative-path
>
> and some warnings about NMU, because currently my name is in the
> changelog entry and I'm not an uploader. Since I'm only DM and this
> package is not in my allowed list, I can't upload anyway.
>
> Note that the tests are currently disabled since they require to connect
> to a display and I don't know how to do this properly (xvbf seems to be
> the solution).
>
> So far I only test compiled it on my up-to-date jessie installation, and
> didn't test whether all build requirements are listed.
>
> I installed the package and tested loading an image, segmenting it
> manually, and this works.
>
> Later this week I will add a watch file and check whether the
> dependencies are sufficient (pbuilder, sid ... yada yada).

Thanks a lot for your effort. Unless somebody picks this up earlier (please
let us know), I'll look into an upload on the weekend.

Cheers,

Michael

Bug#749531: Patch

[Michael Hanke]

Hi Anton,

first of all: thanks for the patch and sorry for the ridiculously long
time it took me to respond.

On Tue, May 27, 2014 at 09:22:56PM +0200, Anton Gladky wrote:
> new VTK version 6.1 is already in archive. We are planning to
> switch all dependent on VTK 5 packages to this new version
> to escape dependencies on older unsupported VTK.

I tried to build the package with your patch, but it fails. VTK6 seems
to pull in Qt5 dependencies that it does not seem to resolve properly.
Linking the main binary fails like this:

Linking CXX executable ../../bin/fslview
cd /home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/fslview.dir/link.txt --verbose=1

/usr/bin/ld: cannot find -lQt5::Widgets
collect2: error: ld returned 1 exit status

As FSLView itself relies on Qt4, I think that Qt5 dependency should be
resolved by VTK6. I hope that mixing Qt versions is a more fundamental
problem, as switching to Qt5 seems infeasible at this point. Qwt
(another dependencies) also depends on Qt4 in its latest version in
Debian.

Michael


-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#773589: additional information (baobab does not show mounted devices)

[Michael Hanke]

I just noticed that if I start baobab with sudo, I can see those 
partitions which are mounted in /media or have mountoption user in fstab.


Further investigation showed up that this even works if I start baobab 
with sudo -u  where  is the same as logged in, so it is 
obvious that it has to do something with the environment:


If I unset DBUS_SESSION_BUS_ADDRESS before starting baobab it works with 
all partitions with option 'user' or 'users' in fstab (not works if they 
are mounted with 'default')


Hope that helps.
Regards
Michael


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#773589: baobab does not show mounted devices

[Michael Hanke]

Package: baobab
Version: 3.14.1-1
Severity: important

Starting baobab without parameters shows up only root-filesystem, unmounted
drives and my personal folder.

If I walk to the mountpoints (/home and some are subfolders of /mnt) within
baobab there seems to be nothing mounted, what maybe wanted, but since I cannot
see mounted drives in the main screen it is not possible to analyze them.

If I start "baobab " with  one of the subfolders within
/mnt everything works fine.



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

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

Versions of packages baobab depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-13
ii  libcairo-gobject21.14.0-2.1
ii  libcairo21.14.0-2.1
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.1-1
ii  libgtk-3-0   3.14.5-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3

Versions of packages baobab recommends:
ii  yelp  3.14.1-1

baobab suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#773584: nautilus: no "open with" menu for directory

[Michael Hanke]

Package: nautilus
Version: 3.14.1-2
Severity: normal

There is no "open with" menu entry if right-clicking on directories.



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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.22-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  gvfs   1.22.2-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-13
ii  libcairo-gobject2  1.14.0-2.1
ii  libcairo2  1.14.0-2.1
ii  libexempi3 2.2.1-2
ii  libexif12  0.6.21-2
ii  libgail-3-03.14.5-1
ii  libgdk-pixbuf2.0-0 2.31.1-2+b1
ii  libglib2.0-0   2.42.1-1
ii  libglib2.0-data2.42.1-1
ii  libgnome-desktop-3-10  3.14.1-1
ii  libgtk-3-0 3.14.5-1
ii  libnautilus-extension1a3.14.1-2
ii  libnotify4 0.7.6-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libselinux12.3-2
ii  libtracker-sparql-1.0-01.2.4-1
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-4
ii  nautilus-data  3.14.1-2
ii  shared-mime-info   1.3-1

Versions of packages nautilus recommends:
ii  eject  2.1.5+deb1+cvs20081104-13.1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gnome-sushi3.12.0-2+b1
ii  gvfs-backends  1.22.2-1
ii  librsvg2-common2.40.5-1

Versions of packages nautilus suggests:
ii  brasero  3.11.4-1
ii  eog  3.14.1-1
ii  evince [pdf-viewer]  3.14.1-1
ii  totem3.14.0-2
ii  tracker  1.2.4-1
ii  xdg-user-dirs0.15-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772176: unblock: condor/8.2.3~dfsg.1-5

[Michael Hanke]

On Fri, Dec 5, 2014 at 11:12 PM, Adam D. Barratt 
wrote:

> On Fri, 2014-12-05 at 22:56 +0100, Michael Hanke wrote:
> > The mixture of in-place modification at runtime and patches has proven
> > to be unreliable. Hence to move towards putting as much
> > as possible into patches.
>
> Right, but the section I mentioned, which is removed in the patch, was
> only added in the -4 package I previously unblocked. So removing it
> again with no explanation seems slightly odd.
>

Even in -4 it wasn't really added. If you inspect the long sed expression
that was removed
in -4 (which, in combination with a changed configuration file, was the
cause for
#769100), you'll see that all configuration variable are set to identical
values. The section was
"added" as the actual configuration file had no corresponding variables to
modify anymore.


> (Looking at it, yes the items it contains are indeed in the other patch,
> but that just makes things even more confusing. Why was it added in the
> first place, and why isn't the removal documented?)
>

I hope I answered why it was "added". As for why it was "removed" or turned
into a patch:
Only for having the entire configuration setup in a patch (as in-place
modification is apparently
fragile). As the freeze policy states that only the diff between the
version in testing and the one
to be unblocked is relevant, I went for this modification in order to have
the end result less
complicated. Granted that the way towards it was a bit convoluted. I am
sorry that you had to
witness it that closely.

In any case, this may be academic, as condor appears to have picked up a
> dependency on the new version of globus-io, which is still blocked.
>

That is unfortunate. I hope for the best.

thanks in any case,

Michael

Bug#772176: unblock: condor/8.2.3~dfsg.1-5

[Michael Hanke]

Hi Adam,

thanks for taking processing my request:

On Fri, Dec 5, 2014 at 10:42 PM, Adam D. Barratt 
wrote:

> Control: tags -1 + moreinfo
>
> On Fri, 2014-12-05 at 21:57 +0100, Michael Hanke wrote:
> > The previously unblocked (#771419) version 8.2.3~dfsg.1-4 that was
> > intended to fix #769100 inadvertently introduced another (grave) bug
> > in the default configuration (#772170).
> [...]
> > Except for the changelog and the reported patch the debdiff is identical
> > to the one reported in (#771419).
>
> That doesn't appear to be the case:
>
> diff -Nru condor-8.2.3~dfsg.1/debian/rules condor-8.2.3~dfsg.1/debian/rules
> --- condor-8.2.3~dfsg.1/debian/rules2014-11-29 08:52:02.0 +
> +++ condor-8.2.3~dfsg.1/debian/rules2014-12-05 19:23:32.0 +
> @@ -106,13 +106,6 @@
> chrpath -d debian/libclassad*/usr/lib/libclassad.so.*.*
> # kill the default local config -- debconf will handle that
> rm debian/htcondor/etc/condor/condor_config.local
> -   # modify condor config file with default Debian config
> -   # no default chatter to upstream
> -   echo "CONDOR_DEVELOPERS = NONE" >>
> debian/htcondor/etc/condor/condor_config
> -   echo "CONDOR_DEVELOPERS_COLLECTOR = NONE" >>
> debian/htcondor/etc/condor/condor_config
> -   # SSH template is a config file
> -   echo "SSH_TO_JOB_SSHD_CONFIG_TEMPLATE =
> /etc/condor/condor_ssh_to_job_sshd_config_template" \
> -   >> debian/htcondor/etc/condor/condor_config
>

I am not sure I understand. I think this change is accounted for in


https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=spool_fix.patch;att=1;bug=772170

Functionally equivalent lines are now included in a patch for

  src/condor_examples/condor_config.generic.debian.patch

The mixture of in-place modification at runtime and patches has proven to
be unreliable. Hence to move towards putting as much
as possible into patches.

I am missing something?

Thanks,

Michael

Bug#772176: unblock: condor/8.2.3~dfsg.1-5

[Michael Hanke]

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

Please unblock package condor

The previously unblocked (#771419) version 8.2.3~dfsg.1-4 that was
intended to fix #769100 inadvertently introduced another (grave) bug
in the default configuration (#772170).

The new upload 8.2.3~dfsg.1-5 fixes this bug with the patch that is
available from #772170. The full changlog entry is:

diff --git a/debian/changelog b/debian/changelog
index 8bff6c1..6cb318b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+condor (8.2.3~dfsg.1-5) unstable; urgency=medium
+
+  * Fix wrong default SPOOL location introduced with 8.2.3~dfsg.1-4. Whenever
+not overwritten by an explicit SPOOL setting, this version relocated
+SPOOL to /var/lib/condor/lib. Consequently, existing job and usage logs
+where inaccessible by HTcondor. This update reverts this unintentional
+change and sets SPOOL explicitly to /var/spool/condor again.
+(Closes: #772170)
+
+ -- Michael Hanke   Fri, 05 Dec 2014 20:32:17 +0100
+
 condor (8.2.3~dfsg.1-4) unstable; urgency=medium
 
   * Adjust mechanism to apply the default Debian configuration to cope with

Except for the changelog and the reported patch the debdiff is identical
to the one reported in (#771419). Please let me know if you need a full
debdiff nevertheless.

Thanks and sorry for the hassle!

unblock condor/8.2.3~dfsg.1-5

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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772170: Patch

[Michael Hanke]

Here is a tentative patch.
diff --git a/debian/patches/default_debian_config b/debian/patches/default_debian_config
index 77ba593..9415fd3 100644
--- a/debian/patches/default_debian_config
+++ b/debian/patches/default_debian_config
@@ -90,3 +90,32 @@ Author: Michael Hanke 
  type=path
  review=?
  [CREDD_ARGS]
+--- a/src/condor_examples/condor_config.generic.debian.patch
 b/src/condor_examples/condor_config.generic.debian.patch
+@@ -29,7 +29,7 @@
+  #LOCAL_CONFIG_DIR_EXCLUDE_REGEXP = ^((\..*)|(.*~)|(#.*)|(.*\.rpmsave)|(.*\.rpmnew))$
+  
+  ##  Use a host-based security policy. By default CONDOR_HOST and the local machine will be allowed
+-@@ -50,5 +48,24 @@
++@@ -50,5 +48,29 @@
+  #FLOCK_TO = condor.cs.wisc.edu, cm.example.edu
+  
+  ##
+@@ -45,7 +45,7 @@
+ +RUN = $(LOCAL_DIR)/run/condor
+ +LOG = $(LOCAL_DIR)/log/condor
+ +LOCK= $(LOCAL_DIR)/lock/condor
+-+SPOOL   = $(LOCAL_DIR)/lib/condor/spool
+++SPOOL   = $(LOCAL_DIR)/spool/condor
+ +EXECUTE = $(LOCAL_DIR)/lib/condor/execute
+ +BIN = $(RELEASE_DIR)/bin
+ +LIB = $(RELEASE_DIR)/lib/condor
+@@ -55,3 +55,8 @@
+ +SHARE   = $(RELEASE_DIR)/share/condor
+ +
+ +PROCD_ADDRESS = $(RUN)/procd_pipe
+++
+++CONDOR_DEVELOPERS = NONE
+++CONDOR_DEVELOPERS_COLLECTOR = NONE
+++
+++SSH_TO_JOB_SSHD_CONFIG_TEMPLATE = /etc/condor/condor_ssh_to_job_sshd_config_template
diff --git a/debian/rules b/debian/rules
index df092db..74b2bb9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -106,13 +106,6 @@ override_dh_install:
 	chrpath -d debian/libclassad*/usr/lib/libclassad.so.*.*
 	# kill the default local config -- debconf will handle that
 	rm debian/htcondor/etc/condor/condor_config.local
-	# modify condor config file with default Debian config
-	# no default chatter to upstream
-	echo "CONDOR_DEVELOPERS = NONE" >> debian/htcondor/etc/condor/condor_config
-	echo "CONDOR_DEVELOPERS_COLLECTOR = NONE" >> debian/htcondor/etc/condor/condor_config
-	# SSH template is a config file
-	echo "SSH_TO_JOB_SSHD_CONFIG_TEMPLATE = /etc/condor/condor_ssh_to_job_sshd_config_template" \
-		>> debian/htcondor/etc/condor/condor_config
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#772170: htcondor: New default configuration relocates spool dir -> history lost

[Michael Hanke]

Package: htcondor
Version: 8.2.3~dfsg.1-4
Severity: grave
Justification: causes non-serious data loss

With the update to 8.2.3~dfsg.1-4 the default condor config file included
a modified location for the SPOOL directory.
As a result the spool directory is now by default located at
/var/lib/condor/spool instead of /var/spool/condor. This resets condors
user priority and job logs (condor_history...).

The hot fix is to configure SPOOL by modifying the relevant line in
/etc/condor/condor_config to 

SPOOL = /var/spool/condor

An update that fixes this in the installed default config file is pending.

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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages htcondor depends on:
ii  adduser   3.113+nmu3
ii  debconf [debconf-2.0] 1.5.54
ii  libc6 2.19-13
ii  libcgroup10.41-6
pn  libclassad7   
ii  libcomerr21.42.12-1
ii  libcurl3  7.38.0-3
ii  libdate-manip-perl6.47-1
ii  libexpat1 2.1.0-6+b3
ii  libgcc1   1:4.9.1-19
ii  libglobus-callout03.13-3
ii  libglobus-common0 15.26-3
ii  libglobus-ftp-client2 8.13-6
ii  libglobus-gass-transfer2  8.8-3
ii  libglobus-gram-client313.10-3
ii  libglobus-gram-protocol3  12.12-3
ii  libglobus-gsi-callback0   5.6-3
ii  libglobus-gsi-cert-utils0 9.10-3
ii  libglobus-gsi-credential1 7.7-3
ii  libglobus-gsi-openssl-error0  3.5-3
ii  libglobus-gsi-proxy-core0 7.7-3
ii  libglobus-gsi-proxy-ssl1  5.7-3
ii  libglobus-gsi-sysconfig1  6.8-3
ii  libglobus-gss-assist3 10.12-3
ii  libglobus-gssapi-error2   5.4-3
ii  libglobus-gssapi-gsi4 11.13-3
ii  libglobus-io3 10.11-1
ii  libglobus-openssl-module0 4.6-3
ii  libglobus-rsl210.9-3
ii  libglobus-xio04.15-3
pn  libgsoap4 
iu  libgssapi-krb5-2  1.12.1+dfsg-15
iu  libk5crypto3  1.12.1+dfsg-15
iu  libkrb5-3 1.12.1+dfsg-15
iu  libkrb5support0   1.12.1+dfsg-15
iu  libldap-2.4-2 2.4.40-3
ii  libltdl7  2.4.2-1.11
ii  libpcre3  1:8.35-3.1
ii  libssl1.0.0   1.0.1j-1
ii  libstdc++64.9.1-19
ii  libuuid1  2.25.2-3
iu  libvirt0  1.2.9-6
ii  libx11-6  2:1.6.2-3
iu  perl  5.20.1-3
ii  python2.7.8-2
iu  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages htcondor recommends:
ii  dmtcp  2.3.1-5

Versions of packages htcondor suggests:
pn  coop-computing-tools  


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#771419: unblock: condor/8.2.3~dfsg.1-4

[Michael Hanke]

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

Please unblock package condor

This update fixes RC bug #769100, which is a synonym for a whole family
of unreported bugs caused by a (now) inappropriate procedure to apply
the default configuration. The default config is now applied as a
dedicated patch, instead of assuming the existance of all relevant
config variable in a monolithic file -- like it used to be.

This update also include the Dutch Debconf translation #766067.

This update does not include all available fixes from the upstream
bugfix release 8.2.4 -- the diff is relatively large, although most
changed lines affect literal strings in the code. In the interest of a
quick RC bug fix, these bugs are left as is for now.

unblock condor/8.2.3~dfsg.1-4

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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru condor-8.2.3~dfsg.1/debian/changelog condor-8.2.3~dfsg.1/debian/changelog
--- condor-8.2.3~dfsg.1/debian/changelog	2014-10-17 20:47:37.0 +0200
+++ condor-8.2.3~dfsg.1/debian/changelog	2014-11-29 10:53:23.0 +0100
@@ -1,3 +1,19 @@
+condor (8.2.3~dfsg.1-4) unstable; urgency=medium
+
+  * Adjust mechanism to apply the default Debian configuration to cope with
+the removal of the monolithic configuration file in the 8.2.x series.
+The default configuration is now applied as a patch to the table of
+parameters in the HTCondor sources (Closes: #769100).
+The report of leaving behind an unowned directory is merely a symptom of
+this bug.
+  * Adjust default configuration to make HTCondor work with Debian's
+ganglia (also see Ticket #4709). Thanks to Alex Waite for the fix.
+  * Add Debconf template translation:
+- Dutch -- courtesy of Frans Spiesschaert .
+  (Closes: #766067)
+
+ -- Michael Hanke   Sat, 29 Nov 2014 09:57:27 +0100
+
 condor (8.2.3~dfsg.1-3) unstable; urgency=medium
 
   * Modify the DMTCP shim script to work with the 2.x series of DMTCP.
@@ -98,7 +114,7 @@
 script.
   * Bumped Standards-version to 3.9.4; no changes necessary.
   * Add new dependency on libboost-test-dev.
-  * Disable installation of obsolete Pearl modules.
+  * Disable installation of obsolete Perl modules.
   * Fix DEP5 syntax error in debian/copyright.
 
  -- Michael Hanke   Tue, 31 Dec 2013 10:22:08 +0100
diff -Nru condor-8.2.3~dfsg.1/debian/patches/default_debian_config condor-8.2.3~dfsg.1/debian/patches/default_debian_config
--- condor-8.2.3~dfsg.1/debian/patches/default_debian_config	1970-01-01 01:00:00.0 +0100
+++ condor-8.2.3~dfsg.1/debian/patches/default_debian_config	2014-11-29 10:32:03.0 +0100
@@ -0,0 +1,92 @@
+Description: Specify default config in the table of parameters
+  Previously, this configuration was shipped as a big config file.
+  This changed in the 8.2.x series and now needs to go into the table of
+  parameters -- which is not (yet) comprehensive. Hence, a few variables
+  still need to be present in the default config file too.
+Forwarded: not-needed
+Bug-Debian: http://bugs.debian.org/769100
+Author: Michael Hanke 
+
+--- a/src/condor_utils/param_info.in
 b/src/condor_utils/param_info.in
+@@ -1175,7 +1175,7 @@
+ tags=accountant,Accountant
+ 
+ [SPOOL]
+-default=$(LOCAL_DIR)/spool
++default=$(LOCAL_DIR)/spool/condor
+ type=path
+ reconfig=true
+ customization=seldom
+@@ -2169,7 +2169,7 @@
+ tags=daemon_core,daemon_core_main
+ 
+ [COLLECTOR_NAME]
+-default=My Pool - $(CONDOR_HOST)
++default=Debian Condor Pool - $(CONDOR_HOST)
+ type=string
+ reconfig=true
+ customization=seldom
+@@ -2773,7 +2773,7 @@
+ 
+ [MAIL]
+ # default location for mail on RHEL is /bin/mail, default on debian is /usr/bin/mail
+-default=/bin/mail
++default=/usr/bin/mail
+ win32_default=$(BIN)\condor_mail.exe
+ type=path
+ reconfig=true
+@@ -3572,7 +3572,7 @@
+ tags=c++_util,condor_config
+ 
+ [REQUIRE_LOCAL_CONFIG_FILE]
+-default=true
++default=false
+ win32_default=false
+ type=bool
+ reconfig=true
+@@ -4102,7 +4102,7 @@
+ tags=starter,StarterHookMgr
+ 
+ [JAVA_BENCHMARK_TIME]
+-default=2
++default=0
+ type=int
+ reconfig=true
+ customization=seldom
+@@ -6607,7 +6607,7 @@
+ tags=c++_util,condor_config
+ 
+ [GANGLIA_LIB64_PATH]
+-default=/lib64,/usr/lib64,/usr/local/lib64
++default=/lib,/usr/lib,/usr/local/lib
+ type=string
+ reconfig=true
+ customization=seldom
+@@ -6634,7 +6634,7 @@
+ tags=c++_util,condor_config
+ 
+ [GANGLIAD_METRICS_CONFIG_DIR]
+-default=$(RELEASE_DIR)/etc/condor/ganglia.d
++default=/etc/condor/ganglia.d
+ type=path
+ reconfig=true
+ customization=seldom
+@@ -6834,7 +6834,7 @@
+ review=?
+ 
+ [CONDOR_ADMIN]
+-default=root@$(FULL_HOSTNAME)
++default=root@localho

Bug#769100: Minimal vs. proper fix of #769100 (htcondor is marked for auto-removal from testing)

[Michael Hanke]

Thanks for the report. I am CC'ing the Debian release team to get
feedback regarding an acceptable fix Debian testing.

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

This bug is caused by the (now invalid) assumption of the Debian packaging to
find all relevant config variables in the main condor_config file (see
the various sed expressions in debian/rules).

However, as explained in

  https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=4325

the mechanism for specifying the default configuration changed leading up to
the 8.2.x series.

The proper way to fix this is to move all default configuration settings from
debian/rules into a patch of src/condor_utils/param_info.in.

Alternatively, a CRED_STORE_DIR variable could be reintroduced into the
default config file shipped with the package, which would override this
particular (broken) default. The changes to the source package would be
minimal, but the general invalid approach to specifying a default
configuration would be kept.

While I have the attention of the release time, I'd like to ask for
feedback on pushing an upstream update into jessie. HTCondor uses the
odd/even version setup for stable and development releases. The 8.2.x
series is the stable branch that only sees fixes and no feature
additions. After the freeze of jessie, htcondor 8.2.4 has been released which
contains numerous bug fixes. An exhaustive list to the respective
tickets can be found here.

  http://research.cs.wisc.edu/htcondor/manual/v8.2.4/10_3Stable_Release.html

If approved, I'd like to update the package to 8.2.4, change the default
configuration handling to a generally valid approach, and include the new
translation available from the bug tracker.

Thanks in advance for your feedback.

Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#698386: Is there a future for ITKSNAP?

[Michael Hanke]

Hi,

On Thu, Oct 23, 2014 at 11:57:19AM -0400, Paul Yushkevich wrote:
> Hi Michael,
> 
> I am confused :)
> 
> You previously mentioned that the file
> /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
> exists on the system
> 
> I was suggesting to set the prefix path to /usr/lib/x86_64-linux-gnu/cmake
> - so that directory should exist

Sorry, I was sloppy. The directory exists, but it doesn't have cmake
files:

% cmake .. -D CMAKE_PREFIX_PATH:STRING=/usr/lib/x86_64-linux-gnu/cmake
CMake Error: The source directory "/usr/lib/x86_64-linux-gnu/cmake" does not 
appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.

% ll /usr/lib/x86_64-linux-gnu/cmake
total 72K
drwxr-xr-x 2 root root 4,0K Okt 12 10:06 PulseAudio/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Concurrent/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Core/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5DBus/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Gui/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Network/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGL/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGLExtensions/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5PrintSupport/
drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Qml/
drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Quick/
drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickTest/
drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickWidgets/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Sql/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Test/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Widgets/
drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Xml/

> I am happy to add a CMake flag that will disable the search for the
> plugins. We need the plugins when packaging ITK-SNAP binaries using make
> package. Otherwise if a system does not already have Qt installed, the user
> is hosed.

That would be good. For the Debian package we can specify any runtime
dependencies in the binary package (if they aren't already explicit from
the linker output). It sounds like that would fulfil all requirements of
itksnap.


Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#698386: Is there a future for ITKSNAP?

[Michael Hanke]

On Thu, Oct 23, 2014 at 11:26:50AM -0400, Paul Yushkevich wrote:
> Please try cmake ... -D CMAKE_PREFIX_PATH:STRING=/usr/lib/
> x86_64-linux-gnu/cmake
> 
> And let me know if that works any better.

No, it doesn't -- such a directory doesn't exist.

I believe the CMake setup assumes a rigidity of a Qt5 installation that
does not match the actual installation of the Debian (Ubuntu, Mint,...) system
Qt5.

Michael



-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#698386: Is there a future for ITKSNAP?

[Michael Hanke]

On Thu, Oct 23, 2014 at 10:43:56AM -0400, Paul Yushkevich wrote:
> I am not quite sure where on the Debian system Qt cmake files are, but I
> think you should be able to find them using
> 
> locate Qt5Config.cmake

The file is here:

/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake

> On Thu, Oct 23, 2014 at 10:43 AM, Paul Yushkevich  > Please try setting the CMAKE_PREFIX_PATH to
> > [PATH_TO_QT_INSTALLATION]/lib/cmake
> >
> > In my case that's /opt/Qt/5.3/gcc_64/lib/cmake

I tried

  cmake .. -DCMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5

and a bunch of other variants, but the problem persists.

Michael


-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#698386: Is there a future for ITKSNAP?

[Michael Hanke]

Hi,

On Tue, Oct 21, 2014 at 08:42:50AM -0400, Paul Yushkevich wrote:
> That's great to hear! As far as the CMAKE_PREFIX_PATH, I set it to
> /opt/Qt/5.3/gcc_64/lib/cmake. In my case, Qt is installed to /opt/Qt. I am
> not quite sure why the VTK and GDCM are becoming an issue in the debian
> build, perhaps ITK and VTK are configured slightly differently from the way
> I have them configured.

I tried building today's dev32 branch, but the QT plugin issue remains.

CMake Error at CMakeLists.txt:1135 (get_property):
  get_property could not find TARGET Qt5::QXcbIntegrationPlugin.  Perhaps it
  has not yet been created.
CMake Error at CMakeLists.txt:1136 (get_property):
  get_property could not find TARGET Qt5::QGifPlugin.  Perhaps it has not yet
  been created.

I do have the relevant package installed and the plugins are present:

/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqgif.so

Any idea what needs to be done to help cmake find them?

Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765743: dmtcp: Please install docs in standard location

[Michael Hanke]

Package: dmtcp
Version: 2.3.1-5
Severity: normal

The package installs some of its docs in a versioned directory. The rest
of the package doesn't support co-installation of multiple versions,
hence it would make sense to drop the versioned path and install into
the standard directory exclusively.

mih@meiner /tmp % dpkg -L dmtcp |grep share/doc
/usr/share/doc
/usr/share/doc/dmtcp-2.3.1
/usr/share/doc/dmtcp-2.3.1/AUTHORS
/usr/share/doc/dmtcp-2.3.1/QUICK-START.gz
/usr/share/doc/dmtcp-2.3.1/NEWS.gz
/usr/share/doc/dmtcp
/usr/share/doc/dmtcp/copyright
/usr/share/doc/dmtcp/changelog.Debian.gz
/usr/share/doc/dmtcp/NEWS.Debian.gz



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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dmtcp depends on:
ii  libc6   2.19-11
ii  libgcc1 1:4.9.1-16
ii  libstdc++6  4.9.1-16

dmtcp recommends no packages.

dmtcp suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765741: dmtcp_checkpoint --join option broken

[Michael Hanke]

Package: dmtcp
Version: 2.3.1-5
Severity: normal
Tags: upstream

According to the docs the --join option of dmtcp_checkpoint offers a way
to join an existing coordinator session and properly fail if that is not
possible. However that option seems broken:

m@meiner /tmp % dmtcp_coordinator --port 0 --daemon
dmtcp_coordinator (DMTCP) 2.3.1
License LGPLv3+: GNU LGPL version 3 or later
.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see COPYING file for details.
(Use flag "-q" to hide this message.)

dmtcp_coordinator starting...
Host: meiner (127.0.1.1)
Port: 45497
Checkpoint Interval: disabled (checkpoint manually instead)
Exit on last client: 0
Backgrounding...
m@meiner /tmp % dmtcp_checkpoint --port 45497 --join sleep 120
[9065] ERROR at coordinatorapi.cpp:76 in getHostAndPort; REASON='JASSERT(mode & 
CoordinatorAPI::COORD_NEW || mode & CoordinatorAPI::COORD_ANY) failed'
dmtcp_launch (9065): Terminating...
99 m@meiner /tmp % dmtcp_checkpoint --port 45497 sleep 120
m@meiner /tmp % 
   95%


As you can see, dmtcp_checkpoint crashes with --join, but works as
intended when used without. This bugs leaves, for example, the Condor
DMTCP shim script without a way to reliably verify that a particular
coordinator is used.

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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dmtcp depends on:
ii  libc6   2.19-11
ii  libgcc1 1:4.9.1-16
ii  libstdc++6  4.9.1-16

dmtcp recommends no packages.

dmtcp suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#698386: Is there a future for ITKSNAP?

[Michael Hanke]

Hi,

I am reviving this old thread in order to bring it to an end. Everyone
who has expressed interest and/or frustration in the past is in CC
(incl. the relevant bug).

Over the past month (or rather year) I have repeatedly tried to update
the itksnap package, and today I am giving up. ITK-SNAP has extremely
tight versioned dependencies on ITK and VTK. Making it work with any
current ITK version in Debian seems to require a lucky roll of the dice
(that would not come for me). As of today, neither the current stable
3.2, nor the master branch head compiles in sid. At least for the first
I am pretty sure a version mismatch is the case (see e.g. [1]).
The actual reasons for FTBFS change over time, but the failure rate is
close to 100% for my attempts.

My personal conclusion is that it makes no sense to maintain an itksnap
package independently of ITK.

The package has a popcon score of 241 -- rather solid for a special
interest package of this kind (about half of what ITK3 had in its
prime). It would be a shame to see it go away. On the other hand
dragging an outdated version along forever is not an option.

And to make it very clear: ITK-SNAP is a solid piece of software that I
have enjoyed using (and still do). The problem is solely a ridiculously
complex software interdependency problem, that makes long-term package
maintenance a nightmare.

I have tagged the bug with "help". I see no reason to remove itksnap
from jessie, because this old version does what it was intended to do.
But for the next round we either need to find a better home, or we
should let it go.

Cheers,

Michael

[1] https://groups.google.com/forum/#!topic/itksnap-users/2byPxMTS3Wo



-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#623649: nmu for matlab-support

[Michael Hanke]

Hi,

On Sun, Sep 28, 2014 at 09:11:42PM -0400, Michael Gilbert wrote:
> On Sun, Sep 28, 2014 at 9:05 PM, Yaroslav Halchenko wrote:
> > On Sun, 28 Sep 2014, Michael Gilbert wrote:
> >> Hi, I've uploaded an nmu to delayed/10 remove the libxp dependency.
> >> matlab versions have not required this for 4 years now, and this is
> >> one of two packages remaining with the dependency.
> >
> > I am not the main maintainer of this package but having experience with
> > it,  Would you mind just moving it into Recommends so we would not need
> > backport-specific patches:  we are providing this package across wide
> > range of Debian/Ubuntu releases (so libxp6 would be present) and
> > some people might still use elderly Matlabs.  So with it in Recommends
> > we would please Debian gods and make users of older Matlabs happy.
> 
> Unfortunately that won't really work since the recommends will become
> a policy violation once libxp is removed.  I would recommend adding
> some info to the docs or providing a fetching script to help users
> that are insistent on using old versions.

Thanks for the NMU. I see no problem removing the dependency, if libxp
is being removed.

Cheers,

Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751522: Not wishlist

[Michael Hanke]

Hi,

I don't think this is a wishlist bug. The current version does not work
with the standard compiler. I am trying to update the fsl source package
but I can't do it, because I cannot build against sid anymore due to
this issue.

Given the approaching freeze, please let me know if there are plans to
fix this soon, or whether I should rip out the CUDA bits.

Thanks,

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#754559: fsl: Update to current major version 5

[Michael Hanke]

Source: fsl
Severity: normal

This current version in Debian is ancient. An update to the 5.0 series
is necessary. The first upload attempt ended in NEW due to some
documentation bits with unclear origin. Next one is coming...

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

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749777: typo

[Michael Hanke]

On Thu, May 29, 2014 at 07:56:07PM +0100, Barak A. Pearlmutter wrote:
> $ apt-cache show coop-computing-tools/sid | egrep asbtraction
>   * Wavefront: A computational asbtraction for running very large dynamic
> 
> $ dict asbtraction
> No definitions found for "asbtraction", perhaps you mean:
> ...:  abstraction

Thanks! This will be fixed with the next upload.

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747794: condor: FTBFS: error: krb5.h: No such file or directory

[Michael Hanke]

Hi,

thanks for the patch. I am working on an update to 8.0.6 and will include
you patch in the new upload.

Cheers,

Michael


On Sun, May 25, 2014 at 3:26 PM, Hideki Yamane  wrote:

> control: tags -1 +patch
>
> Hi,
>
>  Attached patch would fix this FTBFS. Could you check and apply it,
>  please?
>
> --
> Regards,
>
>  Hideki Yamane henrich @ debian.or.jp/org
>  http://wiki.debian.org/HidekiYamane
>



-- 
Michael Hanke
http://mih.voxindeserto.de

Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons

[Michael Hanke]

Hi,

On Thu, Apr 10, 2014 at 03:10:54PM +0200, Petter Reinholdtsen wrote:
> Are you still able to reproduce this?  I'm trying to write a test case
> to trigger this bug, but am unable to do so.  This is the test code I
> use, and it always report SigIgn:  for both test
> scripts.  What am I doing wrong?  Note that you need startpar version
> 0.59 just uploaded to unstable to have support for the -e and -d options
> to use startpar without running scripts in /etc/init.d/. :)

Thanks for keeping track of this one!

Unfortunately, the issue is still present -- on an up-to-date Debian
wheezy. I still have no clue who to trigger this behavior other than
a reboot of those machines. I can still reliably fix it by a restart
of the condor daemons once the machines are fully up.

If there is anything I can try on those machines that would help you
determine the problem please let me know.

Thanks,

Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#662542: Bug#720821: voxbo: diff for NMU version 1.8.5~svn1246-1.1

[Michael Hanke]

Thanks for your work. I am currently traveling. Please go ahead with your
upload. I'll try to do it myself around the end of the week if you did not
manage it by then.

cheers,

michael

 On Feb 9, 2014 10:45 PM, "Andreas Moog"  wrote:

> tags 662542 patch
> tags 720821 patch
> thanks
>
> Dear maintainer,
>
> I've prepared an NMU for voxbo (versioned as 1.8.5~svn1246-1.1) and
> will try to find a sponsor in the next week. Please feel free to tell
> me if I should wait longer or you want to upload yourself.
>
> Regards.
>

Bug#737187: fsl: depends on deprecaed Tcl/Tk 8.4

[Michael Hanke]

Please go ahead and NMU the package. An upload of FSL5 is overdue --
will hopefully happen over the next few weeks.

Thanks,

Michael


On Fri, Jan 31, 2014 at 11:18:20AM +0400, Sergei Golovan wrote:
> Package: fsl
> Version: 4.1.9-7
> Severity: serious
> Tags: patch
> 
> Dear Maintainer,
> 
> We are about to drop Tcl/Tk 8.4 from Debian, but your fsl package still
> depends on tcl8.4 and tk8.4. The attached patch just replaces these
> dependencies by tcl and tk, which are metapackages installing the default
> Tcl/Tk version.
> 
> If you don't mind, I'll perform NMU with this patch.
> 
> -- System Information:
> Debian Release: 7.3
>   APT prefers proposed-updates
>   APT policy: (500, 'proposed-updates'), (500, 'stable'), (100, 'unstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash

> diff -Nru fsl-4.1.9/debian/changelog fsl-4.1.9/debian/changelog
> --- fsl-4.1.9/debian/changelog2012-10-22 13:00:27.0 +0400
> +++ fsl-4.1.9/debian/changelog2014-01-31 10:47:47.0 +0400
> @@ -1,3 +1,10 @@
> +fsl (4.1.9-7.1) unstable; urgency=low
> +
> +  * Non-maintainer upload.
> +  * Replaced tcl8.4 and tk8.4 by tcl and tk in the package dependencies.
> +
> + -- Sergei Golovan   Fri, 31 Jan 2014 10:47:41 +0400
> +
>  fsl (4.1.9-7) unstable; urgency=low
>  
>* Stop regenerating tclIndex during postinst. This is no longer necessary
> diff -Nru fsl-4.1.9/debian/control fsl-4.1.9/debian/control
> --- fsl-4.1.9/debian/control  2012-10-22 13:04:59.0 +0400
> +++ fsl-4.1.9/debian/control  2014-01-31 10:46:39.0 +0400
> @@ -7,7 +7,7 @@
>   libboost-dev (>= 1.32.0), libpng12-dev (>= 1.2.8rel),
>   libgd2-noxpm-dev (>= 2.0.33) | libgd2-xpm-dev (>= 2.0.33), libnewmat10-dev,
>   libgdchart-gd2-noxpm-dev | libgdchart-gd2-xpm-dev,
> - liboctave-dev | octave3.2-headers | octave3.0-headers, tcl8.4 (>=8.4.7),
> + liboctave-dev | octave3.2-headers | octave3.0-headers, tcl,
>   imagemagick, libnifti-dev (>> 1.1.0-1)
>  Standards-Version: 3.9.3
>  Homepage: http://www.fmrib.ox.ac.uk/fsl/
> @@ -29,7 +29,7 @@
>  
>  Package: fsl-4.1
>  Architecture: any
> -Depends: ${shlibs:Depends}, ${misc:Depends}, mozilla-firefox | www-browser, 
> tcsh | c-shell, tk8.4 (>=8.4.7), tcl8.4 (>=8.4.7), bc, dc
> +Depends: ${shlibs:Depends}, ${misc:Depends}, mozilla-firefox | www-browser, 
> tcsh | c-shell, tk, tcl, bc, dc
>  Recommends: fsl-doc-4.1 (= ${source:Version}), fsl-atlases, fslview
>  Suggests: fsl-feeds, octave | ${octave:Depends}, dicomnifti, 
> fsl-possum-data, fsl-first-data, gridengine-client
>  Conflicts: fsl-fslview, fsl-doc-4.1 (<< 4.1.9-5~)


-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#736185: python-scipy: filtfilt() not working in wheezy

[Michael Hanke]

Package: python-scipy
Version: 0.10.1+dfsg2-1
Severity: normal
Tags: upstream patch

The filtfilt() function in the signal module is not working in wheezy due to a
missing axis keyword argument.

Here is the upstream bug:

https://github.com/scipy/scipy/issues/2145

Here is the fix:

https://github.com/scipy/scipy/pull/181/files

The problem was fixed upstream in 0.11 and is, consequently, not present
in jessie and beyond.

It would be great to get this updated in stable. filtfilt() is often used
in tutorials and having it fail probably turns a lot of hair gray.

Thanks!

-- System Information:
Debian Release: 7.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-scipy depends on:
ii  libamd2.2.0   1:3.4.0-3
ii  libatlas3-base [liblapack.so.3]   3.8.4-9+deb7u1
ii  libblas3 [libblas.so.3]   1.2.20110419-5
ii  libc6 2.13-38
ii  libgcc1   1:4.7.2-5
ii  libgfortran3  4.7.2-5
ii  liblapack3 [liblapack.so.3]   3.4.1+dfsg-1+deb70u1
ii  libquadmath0  4.7.2-5
ii  libstdc++64.7.2-5
ii  libumfpack5.4.0   1:3.4.0-3
ii  python2.7.3-4+deb7u1
ii  python-numpy [python-numpy-abi9]  1:1.6.2-1.2

Versions of packages python-scipy recommends:
ii  g++ [c++-compiler]  4:4.7.2-1
ii  g++-4.7 [c++-compiler]  4.7.2-5
ii  python-dev  2.7.3-4+deb7u1
ii  python-imaging  1.1.7-4

Versions of packages python-scipy suggests:
ii  python [python-profiler]  2.7.3-4+deb7u1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734591: python-nipype: DataFinder Interface broken

[Michael Hanke]

Package: python-nipype
Version: 0.9-1
Severity: normal
Tags: upstream patch

Hey,

the DataFinder interface is broken in this version.

See https://github.com/nipy/nipype/pull/761 for a demo and the patch.

Do you want me to upload a patched package, or do you prefer to wait for
an upstream merge and upload a new git snapshot?

Thanks,

Michael

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

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-nipype depends on:
ii  python 2.7.5-5
ii  python-cfflib  2.0.5-1
ii  python-networkx1.7~rc1-3
ii  python-nibabel 1.3.0-1~nd70+1
ii  python-scipy   0.12.0-2+b1
ii  python-simplejson  2.6.2-1
ii  python-support 1.0.15
ii  python-traits  4.1.0-1

Versions of packages python-nipype recommends:
ii  graphviz 2.26.3-15+b1
ii  ipython  0.13.2-2
ii  python-nose  1.3.0-2

Versions of packages python-nipype suggests:
ii  afni0.20130912~dfsg.1-2~nd80+1
ii  fsl-5.0-core [fsl]  5.0.6-1
pn  matlab-spm8 
pn  python-nipy 
pn  python-pyxnat   
pn  slicer  

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#714364: 8.0.5 almost done

[Michael Hanke]

Quick update:

After a long time the 8.x packaging is almost done. The only thing left
to do is to figure out the reason for a schedd segfault. Once this is
fixed I will upload.

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#731246: condor: Needs to adapt to Globus Toolkit multi-arch support

[Michael Hanke]

Hi Mattias,

On Mon, Dec 16, 2013 at 07:17:24PM +0100, Mattias Ellert wrote:
> Is there an estimate from the maintainers when this might be fixed? I
> know that there is some ongoing work to update condor to version 8, and
> that this issue might get fixed in the process. Will that happen soon?

Personally, it is likely that I won't be able to focus on this before
the holidays. Maybe the condor devs can be quicker.

> If such an update is still some time away, are there plans to provide a
> minor update to the current version to fix this issue? If you so desire,
> I can offer to make an nmu that only adds the patch proposed to the
> current version so that this issue can be fixed. The condor package is
> currently blocking the libgsoap4 transition and a successful build is
> needed to complete it. Let me know if you think an nmu is a good idea or
> if this will disrupt your planned work.

A quick NMU would be appreciated -- no need for a delayed-queue upload.
If I can do it myself within the next few days, I'll let you know
upfront so we do not duplicate work.

Thanks,

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#724021: e-mail validation for Debian via package

[Michael Hanke]

Hi Paul,

thanks for bringing this to my intention. The maintainership was not
transferred by accident, instead the goal had been to have one of the
upstream developers take over the Debian packaging. However, that
process has stalled.

At this time, there is no point in keeping the package in Debian. Hence I
filled
a bug (#732129) asking ftp-masters to remove the package. This should be
a practical alternative to a proper fix for now.

If something requires via as a dependency in the future, we can bring it
back.

Sorry for the hassle,

Michael



On Sat, Dec 14, 2013 at 1:38 PM, Paul Gevers  wrote:

> Hi
>
> Currently the via package in Debian is one of the last package to block
> the removal of lesstif2 [0]. This is due to a serious bug [1] in the
> package which prevents if from migrating to testing.
>
> This e-mail aims to recheck the use of the lip...@cbs.mpg.de address,
> which caused bug [1] to be reported. The bug is about violation of
> policy section 3.3, which says that the maintainer must be specified
> with a working e-mail address.
>
> @ Michael, do I understand the changelog correctly if I say that you
> often copy the upstream packaging? The debian packaging svn is not
> up-to-date, so I can't check if you intentionally moved the
> maintainer-ship to the Lipsia group. If so, could you fix bug 724021 by
> uploading a via package with your name and e-mail address as Maintainer
> again?
>
> Paul
>
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708462
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724021
> [2] http://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
>
>

Bug#732129: RM: via -- ROM; Outdated, no reverse dependencies, potential replacement

[Michael Hanke]

Package: ftp.debian.org
Severity: normal

Please remove this package. It is holding up the lesstif transition. It
was originally introduced as a dependency of lipsia, which has been
removed from Debian in the past.

A very similar library is provided by the mia package that is been
worked on by the Debian Med team.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#731246: condor: Needs to adapt to Globus Toolkit multi-arch support

[Michael Hanke]

Hi,

On Tue, Dec 03, 2013 at 04:07:20PM +0100, Mattias Ellert wrote:
> With the recent update of Globus Toolkit to version 5.2.5, the debian
> packages implements Multi-Arch support. For this reason the install
> location for the architecture dependent header files had to be changed.

Thanks for your report and the patch!

> PS. At the moment the condor build also fails due to a broken latex2html
> that goes into an endless loop during generation of the documentation
> files. (See BTS #723913)

Ah, thanks for the pointer! This is the issue that is currently holding
up an upload of condor 8.x.

Cheers,

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730810: psychopy: Movie support suboptimal

[Michael Hanke]

On Sun, Dec 01, 2013 at 07:27:33PM +0100, Michael Hanke wrote:
> On Fri, Nov 29, 2013 at 08:38:26PM -0500, Yaroslav Halchenko wrote:
> > have you asked PsychoPy guys themselves?
> 
> Not yet.

My post is here:

https://groups.google.com/d/topic/psychopy-users/geU_mvLJ1ms/discussion


-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730810: psychopy: Movie support suboptimal

[Michael Hanke]

On Sun, Dec 01, 2013 at 06:59:39PM +0100, Mario Kleiner wrote:
> You could check if the problem goes away/is reduced if you use
> movies with very small frame sizes, so inefficient conversion into
> OpenGL textures doesn't matter. And/Or try on graphics cards from
> different vendors/different drivers etc.

This doesn't seem to be the case. I have redone my test using the movie
clip that is shipped with psychopy in order to minimize the chance that
my movie encoding is the source of the problem

/usr/share/pyshared/psychopy/demos/coder/stimuli/jwpIntro.mov

Even with a frame size of 40x30 it reports dropped frames (although at
this size I cannot confirm their presence visually anymore). I tried h264, mp4,
mpeg2 and mpeg1, which should be increasingly easier to decompress, and
I tried different bitrates -- nothing makes the clip play smooth.

At the same time I see no significant CPU usage on an i7-3667U CPU @ 2.00GHz.

Most of the tests happened on machines with INTEL hardware, but on
NVIDIA hardware I see the same issue.

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730810: psychopy: Movie support suboptimal

[Michael Hanke]

On Fri, Nov 29, 2013 at 08:38:26PM -0500, Yaroslav Halchenko wrote:
> I guess this is hardware independent? (i.e. you have tried on few
> boxes/laptops with the same success)

I tried 4 machines from three vendors so far. They had intel or nvidia
hardware, debian wheezy, jessie or ubuntu 13.04 -- all with the same
performance pattern.

> have you asked PsychoPy guys themselves?

Not yet.

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730810: psychopy: Movie support suboptimal

[Michael Hanke]

Package: psychopy
Version: 1.77.02.dfsg-1
Severity: normal

Hi,

using movie stimuli in Psychopy doesn't really work smoothly. Whenever a
movie with sound is played I experience dropped frames. I am attaching a
little benchmark that can be used to show this (done in the builder,
just select a movie file and run it). This issue is only present when
sound is actually played. When it is not played, even when a sound
stream is present in the file and avbin just 'ignores' it, the stimulus
is smooth.

All files and codec combinations I tested play smooth in avplay, vlc,
mplayer and others. I see this issue on amd64 and i386 -- independent of
whether Psychopys own system check reports 'dropped frames' on a
particular system or not. I tested Debian Jessie and Ubuntu 13.04, both
show the problem.

Psychopy upstream recommends avbin 5 for movie stimuli, but Debian never
had it (according to snapshots.d.o). Psychopy upstream also recommend
uncompressed PCM audio -- that makes no difference in comparison to,
e.g. FLAC.

Interestingly, I see a similar jerky playback in openshot. However, when
using the MELT player (from the framework that openshot is based on)
everything is smooth.

This is also not an obvious IO issue. Even if I cache the entire movie
file in memory, the frame drops are still present. System load at
playback is negligible.

Any advise would be very much appreciated.

Thanks,

Michael


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

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages psychopy depends on:
ii  python 2.7.5-5
ii  python-configobj   4.7.2+ds-5
ii  python-lxml3.2.0-1+b1
ii  python-matplotlib  1.1.1~rc2-1
ii  python-numpy   1:1.7.1-3
ii  python-opengl  3.0.1-1
ii  python-pygame  1.9.1release+dfsg-8
ii  python-pyglet  1.1.4.dfsg-2
ii  python-scipy   0.12.0-2+b1
ii  python-support 1.0.15

Versions of packages psychopy recommends:
ii  ipython  0.13.2-2
ii  libavbin07-1.4
ii  libxxf86vm1  1:1.1.3-1
ii  python-imaging   1.1.7-4
ii  python-openpyxl  1.5.8-1
ii  python-pygame1.9.1release+dfsg-8
ii  python-pyglet1.1.4.dfsg-2
ii  python-pyo   0.6.8-1
ii  python-serial2.6-1
ii  python-wxgtk2.8  2.8.12.1+dfsg-1

Versions of packages psychopy suggests:
pn  python-iolabs  
pn  python-pyxid   

-- debconf-show failed

  



















  
  

  














  
  






  

  
  

  

Bug#728861: Upstream version seems to have general problems

[Michael Hanke]

Looking at

https://code.google.com/p/ardesia/issues/detail?id=60

or

https://code.google.com/p/ardesia/issues/detail?id=57

or even

https://code.google.com/p/ardesia/issues/detail?id=44

I can replicate all of them on jessie (amd64) with the standard GNOME3
setup (intel HD4000).

I'd say ardesia in its current upstream shape is not fit for a release.
I tried both the upstream .debs for 1.1 and 1.0, as well as the official
Debian package -- same behavior.

Michael



-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728861: ardesia: Does not display UI elements and crashes

[Michael Hanke]

Package: ardesia
Version: 1.1-1
Severity: important

Hi,

Running ardesia yields a uniform gray screen with the mouse pointer
changes to the "edit pen". Other than that I can perform any action.
Stopping ardesia in this state only works by Ctrl-C in a terminal, upon
which ardesia segfaults.

This is on Debian jessie + GNOME3.

Please let me know if I can contribute more information.


Thanks!


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

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ardesia depends on:
ii  libatk1.0-0 2.10.0-2
ii  libc6   2.17-93
ii  libcairo-gobject2   1.12.16-2
ii  libcairo2   1.12.16-2
ii  libgdk-pixbuf2.0-0  2.28.2-1
ii  libglib2.0-02.36.4-1
ii  libgsf-1-1141.14.28-1
ii  libgsl0ldbl 1.16+dfsg-1
ii  libgtk-3-0  3.8.4-1
ii  libpango1.0-0   1.32.5-5+b1
ii  libxml2 2.9.1+dfsg1-3
ii  vlc 2.0.8-1+b2
ii  xdg-utils   1.1.0~rc1+git20111210-7

ardesia recommends no packages.

ardesia suggests no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#713514: Need help with lazarus-related bug

[Michael Hanke]

Hi Paul,

On Sun, Sep 22, 2013 at 10:47 AM, Paul Gevers  wrote:

> On 22-09-13 09:36, Michael Hanke wrote:
> > thanks for the pointer! Unfortunately that did not solve the original
> issue:
>
> So far, you didn't explain the original issue :).
>

thanks again for your time! I was indeed sloppy explaining the problem. I
am quite sure now it is a depedency issue. Once I install 'lazarus' in the
chroot it works.

Also thanks for the bug report regarding pristine-tar -- I have never
pushed that indeed -- will do.

I am now going to the list of packages that could have changed after
wheezy. I'll update this bug once I have the solution, or come back aksing
for more help.

Thanks,

Michael