Bug#1023389: RM: simpleitk -- ROM; Has RC bugs but no active maintainer

[Ghislain Vaillant]

Le jeu. 3 nov. 2022, 11:33, Andreas Tille  a écrit :

> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-Cc: debian-...@lists.debian.org, Ghislain Antony Vaillant <
> ghisv...@gmail.com>
>
> Hi,
>
> it seems we have to face reality:  Due to RC bugs this package has not
> migrated to testing for 1373 days and the only current uploader of the
> package inside the Debian Med team does not respond to any ping.  We
> simply have no capacity to care for this package.
>
> So please remove the package from Debian.
>
> Kind regards and thanks for your work as ftpmaster
>
>   Andreas.
>

I second Andreas' assessment. This package should be removed given my lack
of time to maintain it anymore.

Best regards,
Ghis

>

Bug#951805: Help with glbinding

[Ghislain VAILLANT]

If you need sponsorship and access to the repo, feel free to request 
them to the Debian Science mailing list.


Cheers,
Ghis

Le dim., oct. 2 2022 at 22:04:07 +0200, Andrea Pappacoda 
 a écrit :
Il giorno dom 2 ott 2022 alle 20:54:01 +02:00:00, Ghislain Vaillant 
mailto:ghisv...@gmail.com>> ha scritto:
Feel free to assist with maintenance of any of my packages under the 
Debian science team umbrella.


You don't need to ask for permission 


Thanks for the fast reply, Ghislain! I'll start working on this in a 
few days. Would you be able to sponsor my first upload and/or grant 
me DM rights to the package? If you prefer, I can publish my changes 
in a Salsa fork so that you can take a look at them before trusting 
me too much :)


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#951805: Help with glbinding

[Ghislain Vaillant]

Hi Andrea,

Feel free to assist with maintenance of any of my packages under the Debian
science team umbrella.

You don't need to ask for permission 

Ghis

Le dim. 2 oct. 2022, 18:22, Andrea Pappacoda  a écrit :

> Hi Ghislain, glbinding hasn't been updated in four years. Would you
> like some help with the package? I've used glbinding in the past, and
> I'd be happy to help with maintenance under the Science team.
>
> --
> OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49
>
>
>

Bug#995829: ITP: itk5 -- extensive suite of software tools for image analysis

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: itk5
  Version : 5.2.1
  Upstream Author : NumFOCUS
* URL : https://itk.org
* License : Apache-2.0
  Programming Lang: C++, Python
  Description : extensive suite of software tools for image analysis

This package is a core dependency for a large array of medical packages.

This package will be maintained by the Debian Med Packaging Team.

Bug#976622: ITP: python3-oscrypto -- cryptography library for Python

[Ghislain Vaillant]

Use python-oscrypto (as in Python the language) or just oscrypto for the
source package name.

Use python3-oscrypto for the name of the binary package installing the
module for Python 3.

Le dim. 6 déc. 2020 à 01:18, Joseph Nahmias  a écrit :

> Package: wnpp
> Severity: wishlist
>
> * Package name: python3-oscrypto
>   Version : 1.2.1
>   Upstream Author : Will Bond 
> * URL : https://github.com/wbond/oscrypto
> * License : MIT
>   Programming Lang: Python
>   Description : cryptography library for Python
>
> TLS (SSL) sockets, key generation, encryption, decryption, signing,
> verification and KDFs using the OS crypto libraries. Does not require a
> compiler, and relies on the OS for patching. Works on Windows, OS X and
> Linux/BSD.
>
> I plan to maintain this under the Debian Python Team.
>
> Used by a number of cross-platform projects including for verifying
> LineageOS
> builds.
>
>

Bug#940680: Provide backports for Buster

[Ghislain Vaillant]

On Mon, 30 Sep 2019 19:42:39 +0200 Ghislain Vaillant <
ghisv...@gmail.com> wrote:
> On Mon, 23 Sep 2019 10:44:08 +0100 Simon McVittie 
> wrote:
> > On Thu, 19 Sep 2019 at 00:17:00 +0200, ghisv...@gmail.com wrote:
> > > Since the release of freedesktop runtime version 19.08, flatpak
> attempts
> > > to install org.freedesktop.Platform.openh264 but fails with the
> > > following warning message:
> > > 
> > > Warning: org.freedesktop.Platform.openh264 needs a later flatpak
> version
> > 
> > This will be addressed by flatpak 1.2.5 in the next buster
> > point release (see #940818). It should become available soon via
> > buster-proposed-updates, if you want to test it early.
> 
> I'd be happy to. I have enabled buster-pu and await said update.

The update landed today on my machine. The issue with upgrading
org.freedesktop.Platform.openh264 is indeed resolved.

Cheers,
Ghis

Bug#940680: Provide backports for Buster

[Ghislain Vaillant]

On Mon, 23 Sep 2019 10:44:08 +0100 Simon McVittie 
wrote:
> On Thu, 19 Sep 2019 at 00:17:00 +0200, ghisv...@gmail.com wrote:
> > Since the release of freedesktop runtime version 19.08, flatpak
attempts
> > to install org.freedesktop.Platform.openh264 but fails with the
> > following warning message:
> > 
> > Warning: org.freedesktop.Platform.openh264 needs a later flatpak
version
> 
> This will be addressed by flatpak 1.2.5 in the next buster
> point release (see #940818). It should become available soon via
> buster-proposed-updates, if you want to test it early.

I'd be happy to. I have enabled buster-pu and await said update.

> > Would you consider providing backports of newer releases of flatpak
to
> > Buster to bypass future issues with new runtimes?
> 
> I'll probably do a backport eventually, but ideally using backports
> shouldn't be necessary in order to use Flathub, so fixing stable is a
> higher priority for me right now than maintaining backports.

Agreed. As a flatpak maintainer myself, I have not felt the need to
upgrade to a newer release even for development purposes.

Cheers,
Ghis

Bug#926935: arpack: FTBFS (does not honor parallel=n in DEB_BUILD_OPTIONS)

[Ghislain Vaillant]

Le mer. 24 avr. 2019 à 17:02, Santiago Vila  a écrit :

> On Wed, Apr 24, 2019 at 04:47:16PM +0200, Sylvestre Ledru wrote:
> > Le 24/04/2019 à 16:45, Santiago Vila a écrit :
> > > On Wed, Apr 24, 2019 at 04:24:59PM +0200, ghisv...@gmail.com wrote:
> > > > Anyone objecting on applying Santiago's patch to src:arpack to fix
> the
> > > > occasionnal FTBFS on single-core builders?
> > > >
> > > > If not, then I am happy to prepare a release.
> > >
> > > Thanks a lot.
> > >
> > > One minor clarification: The failure happens always on single-cpu
> systems,
> > > not just occassionally.
> > >
> > Don't hesitate to forward that upstream if you find a fix
> > https://github.com/opencollab/arpack-ng
>
> A general fix (i.e. one that upstream accept) would probably involve
> using "nproc" command inside the Makefiles, but then we would have to
> override that anyway to avoid using so many simultaneous jobs if the
> user explicitly ask for less jobs via DEB_BUILD_OPTIONS.
>
> The safe/conservative thing to do would be to use 1 job for the test suite.
>
> I can put an issue in github if you confirm there is not one yet.
>
> Thanks.
>

I did not find one, but glanced very quickly through the issue tracker.

>

Bug#921460: dead upstream - keep out of testing

[Ghislain Vaillant]

Le mar. 5 févr. 2019 à 20:21, Rebecca N. Palmer  a
écrit :

> Package: clsparse
> Severity: serious
> X-Debbugs-Cc: debian-scie...@lists.debian.org, ghisv...@gmail.com
> (plus an identical one for freefem3d)
>
> This package is dead upstream, and it has been suggested [0] that
> because of this, it should not be fixed for buster.
>
> I don't know enough about it to have an opinion on this: I am opening
> this bug as a "don't waste your time fixing it" notice.
>
> If this remains the consensus, please consider removing it from unstable
> as well.
>
> [0] https://lists.debian.org/debian-science/2019/02/msg00015.html


Agreed. It should be removed.

Ghislain

>
>

Bug#916859: closed by Andrey Rahmatullin (Re: Bug#916859: RFS: PDF Studio Viewer/2018 [ITP] -- pdf viewer)

[Ghislain Vaillant]

Le jeu. 20 déc. 2018 à 12:33, Sven Hoexter  a écrit :

> On Wed, Dec 19, 2018 at 05:12:39PM -0500, Studio Support wrote:
> > Hello Andrey,
> >
> > Regarding the solution on Bug#916859 about our package "pdfstudioviewer"
> >
> > It's free in the real sense of the term, meaning that users don't pay
> for it. But it is not open source. Our end-user license is displayed to
> users upon running our application the first time.
> >
> > We don't care if our application is listed under the Free or the
> Commercial products.
> >
> > We have a Debian installer so I hope you can use that.
>
> Hi,
> I, and propably many more Debian developers, appreciate that you try to
> engange
> with the Debian project, but really we're focused on open source software.
> You might
> want to read https://www.debian.org/social_contract.html
>
> So yes it's true that we have this sad part called "non-free" on our
> mirrors but formally
> it's not really part of the distribution, and still everything shipped in
> non-free requires
> to have a source package as well.
> https://wiki.debian.org/Packaging/SourcePackage
>
> In the end I can only encourage you to open source your software,
> otherwise you've to move
> on and distribute it via your own self hosted repository.
>
> Sven
>

Another solution would be to distribute your software via Flatpak or Snap
which most distributions, including Debian, support very well.

Ghis

>

Bug#887747: ITP: gnome-shell-extension-easyscreencast -- video recording extension for the GNOME shell

[Ghislain Vaillant]

Le lun. 1 oct. 2018 à 05:42, Samuel Henrique  a
écrit :

> Hello everyone,
>
> I see that the last email here is from January 21th, so I decided to
> myself package gnome-shell-extension-easyscreencast,
>

You did well.

>
> It is almost ready at salsa[0], it just need a final review of d/copyright
> to check if there were new copyright holders added on the new release. I
> did not committed under gnome's team organization, but I can do so if asked
> (I didn't because I don't know if this is what the team wants).
>

If you want the package to be under team maintenance, you should.

>
> Please let me know if you've made any progress on your package, if you
> want to do any changes on top of mine or if you want to co-maintain it.
>
> If there's no opinions against, I will do the upload soon.
>

Please go ahead. Thank you for taking care of it.

>
> Thanks,
>
> [0]https://salsa.debian.org/debian/gnome-shell-extension-easyscreencast
>
> --
> Samuel Henrique 
>

Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

[Ghislain Vaillant]

Le sam. 8 sept. 2018 à 15:05, Mo Zhou  a écrit :

> control: owner -1 !
>
> Hi Ghislain,
>
> I can sponsor this now. Should wait for you to update the package
> to the latest upstream verison, or check and upload it from git
> repo as is?
>
> I think the packaging repo is this one:
> https://salsa.debian.org/python-team/modules/python-jsonrpc


I'll have a look soon.

>
> BTW, why don't you submit a DD application at nm.d.o?
>

Lack of time, mostly. Congrats for yours btw.

Ghis

>

Bug#904478: Enable support for JPEG 2000

[Ghislain Vaillant]

Package: src:pillow
Severity: wishlist

Dear maintainer,

According to the upstream documentation [1], Pillow should have read
support for JPEG 2000 via OpenJPEG v2. This format is used quite heavily
in medical software (via the DICOM format), so it would be really nice
to provide a JPEG2000 enabled version of Pillow for this community.

[1] 
https://pillow.readthedocs.io/en/5.2.x/handbook/image-file-formats.html#jpeg-2000

```
To enable JPEG 2000 support, you need to build and install the OpenJPEG
library, version 2.0.0 or higher, before building the Python Imaging
Library.
```

I suppose it should be as straightforward as adding `libopenjp2-7-dev`
in Build-depends, and verifying that `setup.py` detects it properly?

Best regards,
Ghis

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

Kernel: Linux 4.16.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#903136: RFP: spyder-kernels -- Jupyter kernels for the Spyder console

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist

* Package name: spyder-kernels
  Version : 1.0.1
  Upstream Author : Spyder Development Team
* URL : https://github.com/spyder-ide/spyder-kernels
* License : Expat
  Programming Lang: Python
  Description : Jupyter kernels for the Spyder console

Long-Description:
 Package that provides the kernels used by Spyder on its IPython
 console.
 .
 Spyder is the Scientific Python Development Environment.

Spyder-kernels is a required dependency for spyder>=3.3. I would suggest
to co-maintain this package wit the Debian Science Team wherein spyder
and its plugins are currently located.

Bug#902553: New version does not build

[Ghislain Vaillant]

I am away right now and can't investigate before two weeks.

Looks Cython related from a first look.

Ghis

Le ven. 29 juin 2018 à 11:17, Andreas Tille  a écrit :

> Hi Ghislain,
>
> since one of the Debian Med packages seems to be affected I tried to
> upgrade h5py (see Git repository).  Unfortunately it does not build:
>
> ...
> running build_ext
> Traceback (most recent call last):
>   File "setup.py", line 168, in 
> cmdclass = CMDCLASS,
>   File "/usr/lib/python2.7/dist-packages/setuptools/__init__.py", line
> 129, in setup
> return distutils.core.setup(**attrs)
>   File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
> dist.run_commands()
>   File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
> self.run_command(cmd)
>   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
>   File "/usr/lib/python2.7/distutils/command/build.py", line 128, in run
> self.run_command(cmd_name)
>   File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
> self.distribution.run_command(command)
>   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
>   File "/build/h5py-2.8.0/setup_build.py", line 156, in run
> from Cython.Build import cythonize
>   File "/usr/lib/python2.7/dist-packages/Cython/Build/__init__.py", line
> 1, in 
> from .Dependencies import cythonize
>   File "/usr/lib/python2.7/dist-packages/Cython/Build/Dependencies.py",
> line 36, in 
> from ..Compiler.Main import Context, CompilationOptions,
> default_options
>   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py", line
> 30, in 
> from .Symtab import ModuleScope
>   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Symtab.py", line
> 19, in 
> from . import PyrexTypes
>   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/PyrexTypes.py",
> line 17, in 
> from .Code import UtilityCode, LazyUtilityCode, TempitaUtilityCode
>   File "Cython/Compiler/Code.py", line 38, in init Cython.Compiler.Code
> ImportError: /usr/lib/python2.7/dist-packages/Cython/
> StringIOTree.x86_64-linux-gnu.so: undefined symbol: Py_InitModule4_64
> E: pybuild pybuild:336: build: plugin distutils failed with: exit code=1:
> /usr/bin/python-dbg setup.py build
> dh_auto_build: pybuild --build -i python{version}-dbg -p 2.7 returned exit
> code 13
> make[1]: *** [debian/rules:22: override_dh_auto_build] Error 25
> make[1]: Leaving directory '/build/h5py-2.8.0'
> make: *** [debian/rules:10: build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
>
> Can you please have a look?
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
>

Bug#897603: New upstream release

[Ghislain Vaillant]

Package: thefuck
Version: 3.11-2
Severity: wishlist

Dear maintainer,

Please consider upgrading src:thefuck to the latest upstream version
(3.26 at the time of writing).

You might also want to take this opportunity to switch the dependencies
to Python 3, thereby dropping the need for pathlib2.

On a side note, it might be good to transition the package from
collab-maint to the new salsa hosting service. Since the application is
written in Python, you might be interested to join the Python
Application Team to facilitate potential co-maintenance.

Thank you for your work on src:thefuck.

Ghis

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

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

Versions of packages thefuck depends on:
ii  python2.7.15~rc1-1
ii  python-colorama   0.3.7-1
ii  python-decorator  4.1.2-1
ii  python-pathlib2   2.3.2-1
ii  python-psutil 5.4.2-1
ii  python-six1.11.0-2
ii  python2.7 2.7.15~rc1-1

thefuck recommends no packages.

thefuck suggests no packages.

-- no debconf information

Bug#894811: New upstream release

[Ghislain Vaillant]

Package: src:python-pbr
Severity: wishlist

Dear maintainer,

Please consider upgrading the packaging to the latest version (4.0.1 at
this time).

Cheers,
Ghis

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

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

Bug#894810: New upstream release

[Ghislain Vaillant]

Package: src:python-doc8
Severity: wishlist

Dear maintainers,

Please consider upgrading the packaging to the latest version (0.8 at
this time).

Cheers,
Ghis

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

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

Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

[Ghislain Vaillant]

Hi Gianfranco, could you upload this please?

Cheers,
Ghis

Le jeu. 15 févr. 2018 à 15:59, Ghislain Vaillant <ghisv...@gmail.com> a
écrit :

> Le jeudi 15 février 2018 à 15:51 +, Lumin a écrit :
> > Hi,
> >
> > On 15 February 2018 at 13:52, Ghislain Vaillant <ghisv...@gmail.com>
> > wrote:
> >
> > > > 1. please fix the following copyright issue:
> > > I will update d/copyright accordingly.
> > > > 2. This package failed to build when python2 version of sphinx
> > > > exists:
> > >
> > > I don't care to be honest.
> > >
> > > It builds fine on a clean chroot with the Python 3 version of
> > > Sphinx:
> >
> > OK. Let's omit the failure in an unclean build environment.
> >
> > @Gianfranco: Would you mind sponsoring this package after
> > Ghislain uploaded updated package to mentors?
> > I've checked several lists [1][2][3] and the package LGTM,
> > expect for the license issue mentioned above.
> >
> > ✔ control and rules in good shape
> > ✔ debomatic build and tests successful
> >
> > [1] devref section 7.5.1 Sponsoring packages
> > [2] https://wiki.debian.org/SponsorChecklist
> > [3] https://wiki.debian.org/LucaFalavigna/NEWChecklist
>
> I have just pushed the change requested by Lumin in the packaging
> repository, retagged and submitted an updated tarball to mentors.
>
> Also, hi Gianfranco, been a while...
>
> ...yes I know my DD application :-)
>
> Ghis
>

Bug#893729: sympy FTBFS: python3-distutils is now a separate package

[Ghislain Vaillant]

Another option could be to patch the build system to use setuptools instead
of distutils as recommended by the PyPA?

Le mer. 21 mars 2018 à 20:45, Rebecca N. Palmer  a
écrit :

> Source: sympy
> Severity: serious
> Control: tags -1 patch
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>
> python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
> so if you need it, please build-depend on it.  (Or python3-setuptools,
> given that this looks like it might prefer that.)
>
> (Has anyone checked whether there are more of these?)
>
> dpkg-buildpackage: info: source package sympy
> dpkg-buildpackage: info: source version 1.1.1-4
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Yaroslav Halchenko
> 
> dpkg-buildpackage: info: host architecture amd64
>   dpkg-source --before-build sympy-1.1.1
>   fakeroot debian/rules clean
> dh  clean --with python2,python3 --buildsystem=pybuild
> debian/rules override_dh_auto_clean
> make[1]: Entering directory
> '/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'
> dh_auto_clean
> I: pybuild base:217: python2.7 setup.py clean
> /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
> distribution option: 'install_requires'
>warnings.warn(msg)
> running clean
> I: pybuild base:217: python3.6 setup.py clean
> Traceback (most recent call last):
>File "setup.py", line 46, in 
>  from setuptools import setup, Command
> ModuleNotFoundError: No module named 'setuptools'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "setup.py", line 49, in 
>  from distutils.core import setup, Command
> ModuleNotFoundError: No module named 'distutils'
> E: pybuild pybuild:330: clean: plugin distutils failed with: exit
> code=1: python3.6 setup.py clean
> dh_auto_clean: pybuild --clean -i python{version} -p 3.6 returned exit
> code 13
> make[1]: *** [debian/rules:29: override_dh_auto_clean] Error 25
> make[1]: Leaving directory
> '/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'
> make: *** [debian/rules:10: clean] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules clean subprocess
> returned exit status 2
>
>

Bug#892758: ITP: python-bsdf -- Python implementation of the Binary Structured Data Format

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant <ghisv...@gmail.com>

* Package name: python-bsdf
  Version : 2.1.1
  Upstream Author : Almar Klein
* URL : http://bsdf.io/
* License : BSD
  Programming Lang: Python
  Description : Python implementation of the Binary Structured Data Format

Long-Description:
 The Binary Structured Data Format (BSDF) is an open specification for
 serializing (scientific) data, for the purpose of storage and (inter
 process) communication.
 .
 It's designed to be a simple format, making it easy to implement in
 many programming languages. However, the format allows implementations
 to support powerful mechanics such as lazy loading of binary data, and
 streamed reading/writing.
 .
 BSDF is a binary format; by giving up on human readability, BSDF can be
 simple, compact and fast. See the full specification, or how it
 compares to other formats.

This library is a new dependency for src:python-imageio. It will be
maintained by the Debian Science Team.

Bug#888935: node-xterm FTBFS: error TS2339: Property 'parentElement' does not exist on type 'never'

[Ghislain Vaillant]

> Source: node-xterm
> Version: 2.7.0+ds1-1
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/no
> de-xterm.html
> 
> ...
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/build/1st/node-xterm-2.7.0+ds1'
> tsc --project .
> src/utils/Mouse.ts(30,80): error TS2339: Property 'parentElement'
> does not exist on type 'never'.
> debian/rules:19: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2

No idea how to fix this. The package used to build fine.

Without further context, I am clueless about what to do about it.

Please help,
Ghis

Bug#891613: steam: Steam update suddenly depends on full nvidia graphic support regardless of equipment

[Ghislain Vaillant]

On Tue, 27 Feb 2018 11:34:06 +0300 Boris Pek 
wrote:
> Hi,
> 
> (I am not a maintainer of this package.)
> 
> > My system uses AMD graphics and while X installs a variety of other
drivers, it
> > is not that demanding of storage. Steam only adds nvidia support,
but with the
> > new edition it *requires* nvidia support whether needed or not.
> 
> It is not true. nvidia packages are only in recommendations of
package steam.
> 
> > apt install steam
> > [...]
> 
> Try something like this:
> sudo apt install -V steam --no-install-recommends
> 
> Best wishes,
> Boris

IMO, they should be demoted to Suggests instead of Recommends.

Steam on Windows does not come bundled with Nvidia drivers, nor does it
explictly recommends to use Nvidia-powered hardware. I don't see how
their inclusion in Recommends is justified by the definition in the
Debian packaging policy.

Besides, having the Nvidia libs listed in Recommends is inconvenient
for users with only AMD or Intel graphics, which is my case personally.
Being involved in Debian packaging, I do know about the presence of the
--no-install-recommends option, but most Debian or Ubuntu users don't. 

Please reconsider.

Best regards,
Ghis

Bug#890200: PyQt5 package should provide an egg-info

[Ghislain Vaillant]

On Mon, 12 Feb 2018 23:35:14 -0500 Scott Kitterman  wrote:
> On Sunday, February 11, 2018 09:19:59 PM VA wrote:
> > Package: python-pyqt5
> > Version: 5.9.2+dfsg-1
> > 
> > Many Debian python packages include an egg-info folder, but python-
pyqt5
> > does not.
> 
> The PyQt5 upstream does not use standard Python tools for building
the 
> package.  As shipped by upstream, a source build of PyQt5:
> 
> python3 configure.py
> make
> sudo make install
> 
> does not install any egg information.  Only the upstream wheels
provide 
> anything.  They provide a PyQt5-5.10.dist-info directory which
appears to 
> perform a similar function.
> 
> This is probably not feasible in Debian as we split PyQt5 into a
number of 
> sub-packages to minimize the dependencies that get pulled in for
various 
> applications.  I'm not sure how to manage the egg-info for such a
case.
> 
> Scott K

The problem is that anything that explicitly depends on pyqt5 (as in
'pyqt5' being listed in install_requires) yields a DistributionNotFound
error. I am having this very issue with the recent release of spyder.

A solution is to remove the explicit dependency in order to trick the
setuptools metadata, but it is pretty ugly. Is there really no other
way?

Ghis

Bug#891132: RFS: python-meshio/1.11.7-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-meshio"

* Package name: python-meshio
  Version : 1.11.7-1
  Upstream Author : Nico Schlömer
* URL : https://github.com/nschloe/meshio
* License : Expat
  Section : python

It builds those binary packages:

  meshio-tools - command-line tools for meshio
  python3-meshio - library for reading and writing mesh data (Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/python-meshio

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-meshio/python-meshio_1.11.7-1.dsc

Changes since the last upload:

  * New upstream version 1.11.7
  * Refresh the patch queue
  * Update the copyright years
  * Remove obsolete dependency on lxml
  * Drop the get-orig-source target
  * Point the VCS URIs to salsa.debian.org
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3

Regards,
Ghislain Vaillant

Bug#891131: RFS: pytest-qt/2.3.1-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pytest-qt"

* Package name: pytest-qt
  Version : 2.3.1-1
  Upstream Author : Bruno Oliveira
* URL : https://github.com/pytest-dev/pytest-qt
* License : Expat
  Section : python

It builds those binary packages:

  python-pytestqt-doc - documentation for pytest-qt
  python3-pytestqt - pytest plugin for Qt application testing (Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/pytest-qt

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pytest-qt/pytest-qt_2.3.1-1.dsc

Changes since the last upload:

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org

  [ Ghislain Antony Vaillant ]
  * New upstream version 2.3.1
  * Refresh the patch queue
  * Update the copyright years
  * Normalize the package descriptions
  * Drop the get-orig-source target
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3
  * Set PYTEST_QT_API before running the tests
  * Increase verbosity of autopkgtests

Regards,
Ghislain Vaillant

Bug#891130: RFS: python-mechanicalsoup/0.10.0-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-mechanicalsoup"

* Package name: python-mechanicalsoup
  Version : 0.10.0-1
  Upstream Author : Mirth Hickford <mirth.hickf...@gmail.com>
* URL : https://github.com/hickford/MechanicalSoup
* License : Expat
  Section : python

It builds those binary packages:

  python-mechanicalsoup - library for automating interaction with websites 
(Python 2)
  python3-mechanicalsoup - library for automating interaction with websites 
(Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/python-mechanicalsoup

Alternatively, one can download the package with dget using this
command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-mechanicalsoup/python-mechanicalsoup_0.10.0-1.dsc

Changes since the last upload:

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org

  [ Ghislain Antony Vaillant ]
  * New upstream version 0.10.0 (Closes: #883366)
  * Refresh the patch queue
  * Update the copyright years
  * Drop the get-orig-source target
  * Normalize the package descriptions
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3
  * Explicitly disable testing at build time.
Reason: Tests require network access
  * Add pytest-mock to the autopkgtest Depends

 Regards,
 Ghislain Vaillant

Bug#891117: RFS: python-schema/0.6.7-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-schema"

* Package name: python-schema
  Version : 0.6.7-1
  Upstream Author : Vladimir Keleshev <vladi...@keleshev.com>
* URL : https://github.com/keleshev/schema
* License : Expat
  Section : python

It builds those binary packages:

  pypy-schema - simple data validation library (PyPy)
  python-schema - simple data validation library (Python 2)
  python3-schema - simple data validation library (Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/python-schema

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-schema/python-schema_0.6.7-1.dsc

Changes since the last upload:

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org

  [ Ghislain Antony Vaillant ]
  * Update the gbp configuration
  * New upstream version 0.6.7
  * Fixup whitespacing in rules file
  * Support the nocheck build profile
  * Filter egg-info with extend-diff-ignore
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3
  * Update the copyright years

Regards,
Ghislain Vaillant

Bug#891116: RFS: python-sparse/0.2.0-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-sparse"

* Package name: python-sparse
  Version : 0.2.0-1
  Upstream Author : Matthew Rocklin <mrock...@gmail.com>
* URL : https://github.com/mrocklin/sparse
* License : BSD
  Section : python

It builds those binary packages:

  python3-sparse - multidimensional sparse arrays for Python

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/python-sparse

Alternatively, one can download the package with dget using this
command:

  dget -x https://mentors.debian.net/debian/pool/main/p/python-sparse/p
ython-sparse_0.2.0-1.dsc

Changes since the last upload:

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org

  [ Ghislain Antony Vaillant ]
  * New upstream version 0.2.0
  * Drop superfluous nocheck guards
  * Fixup whitespacing in rules file
  * Add versioned dependency to scipy
  * Add new install dependency on six
  * Add new test dependency on packaging
  * Move extend-diff-ignore to d/s/options
  * Add patch disabling the upstream pytest config
- New patch: No-pytest-config.patch
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3
  * Update the copyright years

Regards,
Ghislain Vaillant

Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

[Ghislain Vaillant]

Le jeudi 15 février 2018 à 15:51 +, Lumin a écrit :
> Hi,
> 
> On 15 February 2018 at 13:52, Ghislain Vaillant <ghisv...@gmail.com>
> wrote:
> 
> > > 1. please fix the following copyright issue:
> > I will update d/copyright accordingly.
> > > 2. This package failed to build when python2 version of sphinx
> > > exists:
> > 
> > I don't care to be honest.
> > 
> > It builds fine on a clean chroot with the Python 3 version of
> > Sphinx:
> 
> OK. Let's omit the failure in an unclean build environment.
> 
> @Gianfranco: Would you mind sponsoring this package after
> Ghislain uploaded updated package to mentors?
> I've checked several lists [1][2][3] and the package LGTM,
> expect for the license issue mentioned above.
> 
> ✔ control and rules in good shape
> ✔ debomatic build and tests successful
> 
> [1] devref section 7.5.1 Sponsoring packages
> [2] https://wiki.debian.org/SponsorChecklist
> [3] https://wiki.debian.org/LucaFalavigna/NEWChecklist

I have just pushed the change requested by Lumin in the packaging
repository, retagged and submitted an updated tarball to mentors.

Also, hi Gianfranco, been a while...

...yes I know my DD application :-)

Ghis

Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

[Ghislain Vaillant]

2018-02-15 8:33 GMT+00:00 Lumin :
> control: merge -1 880442
> control: owner -1 !
> control: tag -1 +moreinfo
>
> Hi Ghislain,
>
> Some comments on this package:
>
> 1. please fix the following copyright issue:
>(reproduce with $ licensecheck -r .)
>
> ./jsonrpc/six.py: MIT/X11 (BSD like)
>Copyright (c) 2010-2013 Benjamin Peterson
>
> There is six.py. What's the relationship between it and python3-six?
> My preliminary guess is that upstream just copied that file to their
> project.

Correct. Don't think it is worth repacking though.

I will update d/copyright accordingly.

> 2. This package failed to build when python2 version of sphinx exists:
>
> make[2]: Entering directory
> '/home/lumin/packages/sponsor/python-jsonrpc-1.10.8/docs'
> sphinx-build -b html -d _build/doctrees   source _build/html
> Running Sphinx v1.6.7
> making output directory...
>
> Configuration error:
> There is a programable error in your configuration file:
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/sphinx/config.py", line 157,
> in __init__
> execfile_(filename, config)
>   File "/usr/lib/python2.7/dist-packages/sphinx/util/pycompat.py",
> line 150, in execfile_
> exec_(code, _globals)
>   File "/usr/lib/python2.7/dist-packages/six.py", line 709, in exec_
> exec("""exec _code_ in _globs_, _locs_""")
>   File "", line 1, in 
>   File "conf.py", line 109, in 
> import sphinx_rtd_theme
> ImportError: No module named sphinx_rtd_theme
>
> make[2]: *** [Makefile:45: html] Error 1
> make[2]: Leaving directory
> '/home/lumin/packages/sponsor/python-jsonrpc-1.10.8/docs'
> make[1]: *** [debian/rules:21: override_dh_auto_build] Error 2
> make[1]: Leaving directory 
> '/home/lumin/packages/sponsor/python-jsonrpc-1.10.8'
> make: *** [debian/rules:9: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> debuild: fatal error at line 1152:
> dpkg-buildpackage -rfakeroot -us -uc -ui -i failed

I don't care to be honest.

It builds fine on a clean chroot with the Python 3 version of Sphinx:

http://debomatic-amd64.debian.net/distribution#unstable/python-jsonrpc/1.10.8-1/buildlog

That's all that matters.

Ghis

Bug#890364: pybind11-dev: Request migration to unstable

[Ghislain Vaillant]

Hi Shane, thanks for reaching out,

On Wed, 14 Feb 2018 00:48:14 + Shane Loretz  wrote:
> Would the maintainer be willing to migrate 2.2.1 from experimental to
unstable? I'm a user of a distribution based on debian unstable. I have
been using pybind11 from pip previously. The package in experimental
appears to be working flawlessly for my usecase and has some nice new
features not in the version currently in unstable.

There are a few rdpends I have got to test first to guarantee a smooth
upgrade. But yes, I intend to migrate the new version to unstable soon.

Cheers,
Ghis

Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-jsonrpc"

* Package name: python-jsonrpc
  Version : 1.10.8-1
  Upstream Author : Kirill Pavlov <k...@p99.io>
* URL : https://github.com/pavlov99/json-rpc
* License : Expat
  Section : python

It builds those binary packages:

  python-jsonrpc-doc - documentation for json-rpc
  python3-jsonrpc - Python implementation of JSON-RPC 1.0 and 2.0 (Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/python-jsonrpc

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-jsonrpc/python-jsonrpc_1.10.8-1.dsc

Packaging repository:

  https://salsa.debian.org/python-team/modules/python-jsonrpc

Debomatic build:

  
http://debomatic-amd64.debian.net/distribution#unstable/python-jsonrpc/1.10.8-1

Changes since the last upload:

  * Initial release. (Closes: #879050)

Regards,
Ghislain Vaillant

Bug#890306: RFS: sphinxcontrib-doxylink/1.5-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sphinxcontrib-doxylink"

* Package name: sphinxcontrib-doxylink
  Version : 1.5-1
  Upstream Author : Matt Williams
* URL : https://github.com/sphinx-contrib/doxylink
* License : BSD
  Section : python

It builds those binary packages:

  python3-sphinxcontrib.doxylink - Sphinx extension for linking to Doxygen 
documentation (Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/sphinxcontrib-doxylink

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sphinxcontrib-doxylink/sphinxcontrib-doxylink_1.5-1.dsc

Packaging repository:

  https://salsa.debian.org/python-team/modules/sphinxcontrib-doxylink

Debomatic build:

  
http://debomatic-amd64.debian.net/distribution#unstable/sphinxcontrib-doxylink/1.5-1

Changes since the last upload:

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org

  [ Ghislain Antony Vaillant ]
  * d/gbp.conf: Sign all tags
  * d/gbp.conf: Drop pq section
  * Source future releases from GitHub
  * New upstream version 1.5
  * Drop the patch queue, fixed upstream
  * Drop the packaging for Python 2, dropped upstream
  * Add new build dependency on doxygen and pytest
  * Add pybuild setup for running the tests
  * Run autopkgtests for all supported Python versions
  * Point the Homepage URI to the GitHub repository
  * Update the copyright years
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3
  * Normalize the package descriptions

Regards,
Ghislain Vaillant

Bug#889891: python-csvkit: Executable for csvgrep.py, csvcut.py etc. are needed

[Ghislain Vaillant]

Control: tags -1 wontfix

On Thu, 08 Feb 2018 14:13:53 +0300 Aleksey Cheusov  wrote:
> Hello. Could you please provide executables for .py files under
> /usr/lib/python2.7/dist-packages/csvkit/utilities directory?
> That is, csvgrep (without .py or .pyc extension), csvcut, csvsort
etc.
> It would be nice to see these executable under bin directory.

python3-csvkit already provides said scripts under /usr/bin.

> Also, please specify python2 in shebang explicitely instead of
'/usr/bin/env python'.
> A reason for this is that default python may change to, for example,
python v.3.

No need for that. Again, if you need these scripts, please install the
python3-csvkit package.

Bug#890225: RFS: flake8-polyfill/1.0.2-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "flake8-polyfill"

* Package name: flake8-polyfill
  Version : 1.0.2-1
  Upstream Author : Ian Cordasco <graffatcolmin...@gmail.com>
* URL : https://gitlab.com/pycqa/flake8-polyfill
* License : MIT
  Section : python

It builds those binary packages:

  python3-flake8-polyfill - polyfill package for Flake8 plugins

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/flake8-polyfill

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/flake8-polyfill/flake8-polyfill_1.0.2-1.dsc

Packaging repository:

  https://salsa.debian.org/python-team/modules/flake8-polyfill

Debomatic:

  
http://debomatic-amd64.debian.net/distribution#unstable/flake8-polyfill/1.0.2-1

Changes since the last upload:

  * New upstream version 1.0.2
  * Update copyright years
  * Drop superfluous nocheck guards
  * Fixup whitespacing in rules file
  * Point VCS URIs to salsa.debian.org
  * Bump the debhelper version to 11
  * Bump the standards version to 4.1.3
  * Add missing Enhances relationship

Regards,
Ghislain Vaillant

Bug#880402: Blocked by #888458

[Ghislain Vaillant]

Control: block -1 by 888458

Bug#888458: python-networkx: packages out of date, haven't been updated for 18 months

[Ghislain Vaillant]

CC'd Sandro explictly in case he is not subscribed to the bugs.

Several packages now require an update for networkx.

Please confirm whether you are still actively involved with its
packaging, or whether assistance is required and in what form.

Thanks,
Ghis

On Thu, 25 Jan 2018 14:25:49 -0800 Jameson Graef Rollins  wrote:
> Package: python-networkx
> Version: 1.11-2
> Severity: normal
> 
> The python-networkx packages were last updated in August 2016, which
> was 18 months ago.  There has been a major upstream releases since
> then (current stable upstream is 2.1).  The missing major release
> update is causing compatibility problems with other platforms.
> 
> Has this package been orphaned?  Please advise.
> 
> Thanks for the help.
> 
> jamie.
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (600, 'testing'), (500, 'stable'), (200, 'unstable'),
(101, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages python-networkx depends on:
> ii  python2.7.14-4
> ii  python-decorator  4.1.2-1
> 
> Versions of packages python-networkx recommends:
> ii  python-matplotlib 2.0.0+dfsg1-2+b1
> ii  python-numpy  1:1.13.3-2
> ii  python-pkg-resources  38.2.4-2
> ii  python-pydot  1.2.3-1
> ii  python-pygraphviz 1.4~rc1-1+b1
> ii  python-scipy  0.19.1-2
> ii  python-yaml   3.12-1+b1
> 
> Versions of packages python-networkx suggests:
> ii  python-networkx-doc  1.11-2
> 
> -- no debconf information
> 
> 

Bug#887933: src:nose2: Provide a binary package for PyPy

[Ghislain Vaillant]

Can you build a pypy-nose2 package for pypy, in addition to the current
binary packages for Python 2 (python-nose2) and Python 3 (python3-nose2).

Thanks,
Ghis

2018-02-05 16:05 GMT+00:00 Pierre-Elliott Bécue :
> Dear Ghislain,
>
> I might be unaware of something, but I'm not able to understand what you
are
> currently asking.
>
> Could you please give me some hints? :)
>
> Cheers,
>
> --
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2

Bug#888075: Switch to ITA

[Ghislain Vaillant]

Control: owner -1 !
Control: retitle -1 ITA: csvkit

I intend to adopt csvkit and transfer its maintenance to the Debian
Science Team together with the agate stack it depends on.

Cheers,
Ghis

Bug#874498: protobuf: Please package latest upstream version

[Ghislain Vaillant]

On Fri, 17 Nov 2017 15:47:57 -0500 Sandro Tosi 
wrote:
> adding explicitly all the protobug uploaders + the latest 2 DDs who
> uploaded the package
> 
> > Please package the latest version from upstream (3.4.0 at this
time).
> >
> > Severity important because currect protoc produces broken
JavaScript
> > code for gogo.proto.
> 
> Is there any chance we could get a newer version of protobuf uploaded
> to sid? we're currently running a rather old version for a project
> moving relatively fast as protobuf. 3.5.0 was released few days ago
> and it would be extremely helpful if we can get it available for
> debian unstable

Just to complement what Sandro said, the latest release of grpcio (used
by Tensorflow) requires protobuf >= 3.5.

Bug#787519: git-buildpackage: Read config from XDG_CONFIG_HOME/debian/gbp.conf

[Ghislain Vaillant]

On Sat, 16 Dec 2017 08:36:03 +0100 Guido =?iso-8859-1?Q?G=FCnther?=  wrote:
> 
> Another issue is that once we do this writing config files (which
will
will
> need to happen too) has to decide what to do if both ~/.gbp.conf and
> ~/.git-buildpackage/gbp.conf are there. With the current order we'd
need
> to still favour ~/.gbp.conf so IMHO the XDG_CONFIG_HOME version needs
> to have higher priority than ~/.gbp.conf.

I second that $XDG_CONFIG_HOME/git-buildpackage/gbp.conf should be
given priority over $HOME/.gbp.conf, which should facilitate the
transition whilst keeping old configurations working.

Ghis

Bug#887583: libjs-fetch FTBFS with mocha 4.0.1-3

[Ghislain Vaillant]

cc'd to Pirate Praveen who reported a similar issue for a version on
experimental?

Do you have an idea what's going on? Why is Adrian's log different to
yours?

On Thu, 18 Jan 2018 09:23:11 +0200 Adrian Bunk  wrote:
> Source: libjs-fetch
> Version: 2.0.3-1
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/li
bjs-fetch.html
> 
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/build/1st/libjs-fetch-2.0.3'
> xvfb-run -a -s "-screen 0 640x480x16" ./script/test
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-
pbuilder1'
> Error loading resource http://localhost:3901/node_modules/mocha/mocha
.css (203). Details: Error transferring http://localhost:3901/node_modu
les/mocha/mocha.css - server replied: Not Found
> Error loading resource http://localhost:3901/node_modules/url-search-
params/build/url-search-params.js (203). Details: Error transferring ht
tp://localhost:3901/node_modules/url-search-params/build/url-search-
params.js - server replied: Not Found
> Error loading resource http://localhost:3901/node_modules/mocha/mocha
.js (203). Details: Error transferring http://localhost:3901/node_modul
es/mocha/mocha.js - server replied: Not Found
> ReferenceError: Can't find variable: Mocha
> ReferenceError: Can't find variable: suite
> TypeError: mocha.run is not a function. (In 'mocha.run()',
'mocha.run' is undefined)
> Likely due to external resource loading and timing, your tests
require calling `window.initMochaPhantomJS()` before calling any mocha
setup functions. See https://github.com/nathanboktae/mocha-phantomjs-co
re/issues/12
> TypeError: Attempting to change the setter of an unconfigurable
property.
> TypeError: Attempting to change the setter of an unconfigurable
property.
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-
pbuilder1'
> Error loading resource http://localhost:3901/node_modules/mocha/mocha
.css (203). Details: Error transferring http://localhost:3901/node_modu
les/mocha/mocha.css - server replied: Not Found
> Error loading resource http://localhost:3901/node_modules/url-search-
params/build/url-search-params.js (203). Details: Error transferring ht
tp://localhost:3901/node_modules/url-search-params/build/url-search-
params.js - server replied: Not Found
> Error loading resource http://localhost:3901/node_modules/mocha/mocha
.js (203). Details: Error transferring http://localhost:3901/node_modul
es/mocha/mocha.js - server replied: Not Found
> ReferenceError: Can't find variable: Mocha
> Likely due to external resource loading and timing, your tests
require calling `window.initMochaPhantomJS()` before calling any mocha
setup functions. See https://github.com/nathanboktae/mocha-phantomjs-co
re/issues/12
> TypeError: Attempting to change the setter of an unconfigurable
property.
> TypeError: Attempting to change the setter of an unconfigurable
property.
> debian/rules:28: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 1
> 
> 

Bug#887747: RFP: gnome-shell-extension-easyscreencast -- video recording extension for the GNOME shell

[Ghislain Vaillant]

Control: owner -1 !
Control: retitle -1 ITP: gnome-shell-extension-easyscreencast -- video 
recording extension for the GNOME shell 

I have successfully built a local version of the package using the
initial work done by the Kali team [1]. I intend to base the initial
packaging on that and improve it to the Debian packaging standards.

I'd like it to be maintained under the umbrella of the Debian GNOME
team (cc'd). Anyone from the team, could you please accept my request
to join the group on salsa, so I can push and start a formal review.

[1] 
http://git.kali.org/gitweb/?p=packages/gnome-shell-extension-easyscreencast.git;a=summary

Cheers,
Ghis

On Fri, 19 Jan 2018 16:10:47 + Ghislain Vaillant <ghisv...@gmail.co
m> wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: gnome-shell-extension-easyscreencast
>   Version : 0.10
>   Upstream Author : Tobias Schönberg
> * URL : https://github.com/EasyScreenCast/EasyScreenCast
> * License : GPL-3
>   Programming Lang: JavaScript
>   Description : video recording extension for the GNOME shell
> 
> Long-Description:
>  This extension simplifies the use of the video recording function
>  integrated in gnome shell, allows quickly to change the various
>  settings of the desktop recording.

Bug#887747: RFP: gnome-shell-extension-easyscreencast -- video recording extension for the GNOME shell

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist

* Package name: gnome-shell-extension-easyscreencast
  Version : 0.10
  Upstream Author : Tobias Schönberg
* URL : https://github.com/EasyScreenCast/EasyScreenCast
* License : GPL-3
  Programming Lang: JavaScript
  Description : video recording extension for the GNOME shell

Long-Description:
 This extension simplifies the use of the video recording function
 integrated in gnome shell, allows quickly to change the various
 settings of the desktop recording.

Bug#881205: Assistance for maintaining src:backintime

[Ghislain Vaillant]

Dear Jonathan,

I was suprised to discover that backintime had been removed from
testing despite RC bug #881205 being fixed upstream [1].

For testing/unstable an update of the package to version 1.1.24 should
do the trick, whilst stretch/wheezy will require a backport of this
particular commit.

I was wondering whether you need any help with the maintenance of the
package, which I'd be happy to offer. It might also be useful to move
the package to team-maintenance long term, under collab-maint or one of
the Python packaging teams.

[1] https://github.com/bit-team/backintime/commit/cef81d0da93ff60125260
7df3db1a48f7f6f01

Cheers,
Ghis

Bug#863168: ismrmrd FTBFS on armhf

[Ghislain Vaillant]

Le 17/12/17 à 15:40, Adrian Bunk a écrit :

On Sun, Dec 17, 2017 at 02:33:03PM +, Ghislain Vaillant wrote:

ISMRMRD uses a non-portable instruction (#pragma pack) which modifies the
memory alignment of its data structures. It seems neither armhf nor sparc64
supports it, hence the failure of the test suite for both architectures.


#pragma pack is supported everywhere,
and this pragma is the cause of the FTBFS.


Ack.


I am not sure what the best course of action is. Either leaving things as is
assuming a future rebuild with a newer compiler could improve it, disabling
the tests or even dropping the packages for the failing architectures.

Opinions welcome.


With #pragma pack you are forcing the compiler to do the wrong thing,
the only thing a newer compiler could possibly improve would be to
error on such code.


Ack.


Unaligned floating point access on armhf is expected to fail,
and that's exactly what happens here:
unknown location(0): fatal error: in 
"AcquisitionsTest/test_acquisition_header": memory access violation at address: 
0xbecd3b6a: invalid address alignment

Running the test in gdb confirms that this is floating point code.

sparc is generally unhappy with unaligned access:
unknown location(0): fatal error: in 
"AcquisitionsTest/test_acquisition_header": memory access violation at address: 
0x7feffb7c936: invalid address alignment

Note that even on architectures where unaligned access is permitted
it can be slower than aligned access.


So, what would be the right course of action moving forward? Removing 
the package for both armhf and sparc64?


Ghis

Bug#863168: ismrmrd FTBFS on armhf

[Ghislain Vaillant]

ISMRMRD uses a non-portable instruction (#pragma pack) which modifies 
the memory alignment of its data structures. It seems neither armhf nor 
sparc64 supports it, hence the failure of the test suite for both 
architectures.


I am not sure what the best course of action is. Either leaving things 
as is assuming a future rebuild with a newer compiler could improve it, 
disabling the tests or even dropping the packages for the failing 
architectures.


Opinions welcome.

Ghis

Bug#884154: Forwarded upstream

[Ghislain Vaillant]

Control: forwarded -1 https://github.com/github/fetch/issues/594

Bug#884154: [Pkg-javascript-devel] Bug#884154: FTBFS with chai 4.1.2 in experimental

[Ghislain Vaillant]

Le 16/12/17 à 17:31, Pirate Praveen a écrit :

On ശനി 16 ഡിസംബര്‍ 2017 10:44 വൈകു, Ghislain Vaillant wrote:

I don't know anything about chai. Besides, since you are its maintainer,
I would expect the investigation to be done by yourself rather than myself.


No, that is not how a transition is supposed to work. Do you expect
maintainer of nodejs package to fix all issues of all packages using
nodejs by themselves when updating nodejs versions?


You are deliberately taking an extreme case to fulfill your narrative. I 
would not fit nodejs and chai in the same basket.



I did not even get heads up with webmock transition in ruby team. It was
right away FTBFS and autoremoval from testing for packages failing to
build with webmock 3.


And?


I can try and help, but as maintainer of libjs-fetch, it is your
responsibility to fix issues of your package when dependencies change.


We are talking about a *test* dependencies which now makes the build 
fail after a major version bump. It makes sense to expect more 
information from the corresponding maintainer.


Should we expect every single maintainer affected by an FTBFS to go read 
the release notes of chai in order to figure what broke between version 
3 and 4. I am very skeptical about this.



I meant context about why the package now FTBFS. I understand this is a
transition and I don't think uploading to unstable is wise before FTBFS
issues such as this one are fixed. Is there an urgency in having chai
4.x in testing/unstable?


Indeed, that is why it is uploaded first to experimental and giving
heads up to packages affected by this transition. We can definitely wait
for a reasonable time before uploading to unstable.


Which is appreciated.


1. chai itself is FTBFS with nodejs 6


That's unfortunate indeed.


2. we generally want to ship the latest versions


But not systematically.


3. Some packages are already starting to require newer versions of chai,
for example node-yargs (whose tests are disabled currently).


It makes sense to disable them if they specifically require chai >= 4.


You could ask upstream to move to chai 4 and take their help. Or you
could also disable tests.


Disabling the tests would be a serious downgrade considering testing is 
currently working, unlike node-yargs. I am seriously uncomfortable with 
this proposal.


I can ask upstream, though chai is officially pinned at version 2.x there.

Bug#884154: [Pkg-javascript-devel] Bug#884154: FTBFS with chai 4.1.2 in experimental

[Ghislain Vaillant]

Le 16/12/17 à 17:07, Pirate Praveen a écrit :

On ശനി 16 ഡിസംബര്‍ 2017 08:41 വൈകു, Ghislain Vaillant wrote:

Why is this happening with chai 4.x and not 3.5?


That is what we need to find out. Possibly some deprecated methods are
removed from new version.


I don't know anything about chai. Besides, since you are its maintainer, 
I would expect the investigation to be done by yourself rather than myself.



Sorry, but I am gonna need more context to fix this.


We are trying to update chai from 3.5 to 4.x but noticed this package
fails with chai 4.x. Once we upload chai 4.x to unstable, it will cause
FTBFS (and severity will be changed to serious) and we wanted to give a
heads up before that. This is the normal procedure of a transition.


I meant context about why the package now FTBFS. I understand this is a 
transition and I don't think uploading to unstable is wise before FTBFS 
issues such as this one are fixed. Is there an urgency in having chai 
4.x in testing/unstable?

Bug#884154: FTBFS with chai 4.1.2 in experimental

[Ghislain Vaillant]

Why is this happening with chai 4.x and not 3.5?

Sorry, but I am gonna need more context to fix this.

Ghis

On Tue, 12 Dec 2017 14:00:12 +0530 Pirate Praveen  
wrote:

package: libjs-fetch
version: 2.0.3-1
severity: important

I'd like to upload chai 4.1.2 to unstable soon, please fix these failures.

xvfb-run -a -s "-screen 0 640x480x16" ./script/test
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pravi'
Error loading resource
http://localhost:3901/node_modules/url-search-params/build/url-search-params.js
(203). Details: Error transferring
http://localhost:3901/node_modules/url-search-params/build/url-search-params.js
- server replied: Not Found


․ArrayBuffer
is deprecated in XMLHttpRequest.send(). Use ArrayBufferView instead.
․

  94 passing (578ms)
  11 pending
  21 failing

  1) polyfill Headers returns null on no header found:
 isNull@http://localhost:3901/node_modules/chai/chai.js:4757:58
http://localhost:3901/test/test.js:208:18
callFn@http://localhost:3901/node_modules/mocha/mocha.js:4613:25
run@http://localhost:3901/node_modules/mocha/mocha.js:4
  06:13
  runTest@http://localhost:3901/node_modules/mocha/mocha.js:5002:13
  http://localhost:3901/node_modules/mocha/mocha.js:5080:19
  next@http://localhost:3901/node_modules/mocha/mocha.js:4927:16
  http://localhost:3901/node_modules/mocha/mocha.js:4937:11
  next@http://localhost:3901/node_modules/mocha/mocha.js:4875:25
  http://localhost:3901/node_modules/mocha/mocha.js:4904:9
  timeslice@http://localhost:3901/node_modules/mocha/mocha.js:6042:27

  2) polyfill Headers deletes headers:
 isNull@http://localhost:3901/node_modules/chai/chai.js:4757:58
http://localhost:3901/test/test.js:221:18
callFn@http://localhost:3901/node_modules/mocha/mocha.js:4613:25
run@http://localhost:3901/node_modules/mocha/mocha.js:4
  06:13
  runTest@http://localhost:3901/node_modules/mocha/mocha.js:5002:13
  http://localhost:3901/node_modules/mocha/mocha.js:5080:19
  next@http://localhost:3901/node_modules/mocha/mocha.js:4927:16
  http://localhost:3901/node_modules/mocha/mocha.js:4937:11
  next@http://localhost:3901/node_modules/mocha/mocha.js:4875:25
  http://localhost:3901/node_modules/mocha/mocha.js:4904:9
  timeslice@http://localhost:3901/node_modules/mocha/mocha.js:6042:27

  3) polyfill Headers throws TypeError on invalid character in field name:
 throws@http://localhost:3901/node_modules/chai/chai.js:6320:16
http://localhost:3901/test/test.js:237:18
callFn@http://localhost:3901/node_modules/mocha/mocha.js:4613:25
run@http://localhost:3901/node_modules/mocha/mocha.js:4606:13
runTest@http://localhost:3901/n
  de_modules/mocha/mocha.js:5002:13
  http://localhost:3901/node_modules/mocha/mocha.js:5080:19
  next@http://localhost:3901/node_modules/mocha/mocha.js:4927:16

Bug#883366: python-mechanicalsoup: new upstream version 0.9.0

[Ghislain Vaillant]

Dear Paul,

On Sun, 03 Dec 2017 12:13:27 +0800 Paul Wise  wrote:

Source: python-mechanicalsoup
Severity: wishlist

Please package the new upstream version 0.9.0 of MechanicalSoup:

https://github.com/MechanicalSoup/MechanicalSoup/releases


I'd be happy to update the packaging of MechanicalSoup to the latest 
upstream release. However, version 0.8.0 has been under RFS for more 
than a month, and has yet to be answered [1].


This is not an isolated case unfortunately, and my personal motivation 
is suffering as a result.



Please also adjust the Homepage to point at the new github org.


Sure.

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

Cheers,
Ghis

Bug#882303: RFS: sphinxcontrib-bibtex/0.3.6-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: sphinxcontrib-bibtex
  Version : 0.3.6-2
  Upstream Author : Matthias C. M. Troffaes
* URL : https://github.com/mcmtroffaes/sphinxcontrib-bibtex
* License : BSD
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/git/debian-science/packages/sphinxcontrib-bibtex.git

Changes since last upload:

  * Enable testing during build
  * Ignore tests requiring Tinkerer
  * Add missing B-D on sphinx-common
  * Bump the standards version to 4.1.1

Regards,
Ghis

Bug#882302: RFS: python-meshio/1.9.3-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-meshio
  Version : 1.9.3-1
  Upstream Author : Nico Schlömer
* URL : https://github.com/nschloe/meshio
* License : Expat
  Section : python

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/python-meshio.git

Changes since last upload:

  * New upstream version 1.9.3
  * Refresh the patch queue
  * Add new dependency on netCDF4
  * Add support for nocheck builds

Regards,
Ghis

Bug#877316: Forwarded upstream

[Ghislain Vaillant]

Control: forwarded -1 https://github.com/clMathLibraries/clBLAS/issues/321

Bug#881837: Updating the h5py Uploaders list

[Ghislain Vaillant]

Control: tags -1 + fixed pending

On Wed, 15 Nov 2017 18:16:51 +0100 Tobias Frost  wrote:

Source: h5py
Version: 2.6.0-2 2.7.1-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Soeren Sonnenburg  wishes no longer to be uploader of h5py.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.


Done. Soeren Sonnenburg has been removed from the Uploaders list of this 
package.



(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)


I already took over maintenance a while back.

Thanks for your work within the MIA team.

Regards,
Ghis

Bug#879196: patch attached

[Ghislain Vaillant]

On Tue, 14 Nov 2017 22:35:47 + "Ana C. Custura"  
wrote:

Hi Ghis,

Thank you for the patches. I have merged this one (I thought the way you
rewrote the rules file was very elegant), and the ones you sent
separately with regards to enabling tests. 


Thanks, did you push your latest changes to the Alioth repository?

FYI, #881765 should also be fixed. @anbe, once yapf 0.19.0-1 is cleared 
from new, you might want to use this version for the backports if that's 
possible.


Cheers,
Ghis

Bug#880958: yapf3 explicitly depends on python3.5

[Ghislain Vaillant]

What about the patches fixing the other two bugs affecting yapf? Please
consider checking the BTS.

Ghis


Le 14 nov. 2017 22:25, "Ana C. Custura" <a...@netstat.org.uk> a écrit :

Hi Ghis,

Thank you for the reply. There is a package on mentors that addresses
both this bug (88958) and the split (879196) bug you raised. I am
waiting for my mentor to review it before uploading.

Ana

On Tue, Nov 14, 2017, at 08:59 AM, Ghislain Vaillant wrote:
> Thank you Matthias for raising this issue. CC'ing the maintainer in case
> she's not subscribed.
>
> On Mon, 6 Nov 2017 11:52:00 +0100 Matthias Klose <d...@debian.org> wrote:
> > Package: yapf3
> > Version: 0.17.0-1
> > Severity: serious
> > Tags: sid buster
> >
> > yapf3 explicitly depends on python3.5. One mistake certainly is the b-d
on
> > python3-all, which is wrong for an application-only package.
>
> The application is not compliant with the Python packaging guidelines.
> The public modules should be split from the application package. See
> #879196 for a discussion about it.
>
> I have proposed a patch offline but it has yet to be applied. Fixing
> #879196 will transitively fix the issue you just reported.
>
> > And if this package is application-only, why ship both Python2 and
Python3 vesions?
>
> It is nether application-only, nor Python 3 specific.
>
> Cheers,
> Ghis

Bug#879196: patch attached

[Ghislain Vaillant]

Here is a patch implementing the proposed split.
>From 37a9eaf8b03aebd4eb6839280aee68cbd48d68b4 Mon Sep 17 00:00:00 2001
From: Ghislain Antony Vaillant 
Date: Tue, 14 Nov 2017 09:24:42 +
Subject: [PATCH] Ship the modules in separate binary packages

Gbp-Dch: Short
Thanks: Matthias Klose for reporting
Closes: #879196, #880958
---
 debian/control | 50 +++---
 debian/rules   | 18 +-
 2 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/debian/control b/debian/control
index 21120f5..facb68c 100644
--- a/debian/control
+++ b/debian/control
@@ -1,5 +1,5 @@
 Source: yapf
-Section: python
+Section: utils
 Priority: optional
 Maintainer: Ana Custura 
 Build-Depends: debhelper (>=9),dh-python,python-all,python-setuptools,python3-all,python3-setuptools
@@ -12,20 +12,56 @@ Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/yapf.git
 
 Package: yapf
 Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${misc:Depends},
+ ${python:Depends},
+ python-yapf
 Description: Python code formatter for different styles (Python 2)
  Yapf is a tool that reformats code to the best formatting that conforms to the
  style guide. It is not only concerned with lint errors, but also with the
  styilistic appearance of Python code. The idea is also similar to the 'gofmt'
- tool for the Go programming language. This package installs the tool for Python
- 2.
+ tool for the Go programming language.
+ .
+ This package provides the command-line interface for Python 2.
+
+Package: python-yapf
+Architecture: all
+Section: python
+Depends: ${misc:Depends},
+ ${python:Depends}
+Breaks: yapf (<< 0.17.0-2)
+Replaces: yapf (<< 0.17.0-2)
+Description: public modules for yapf (Python 2)
+ Yapf is a tool that reformats code to the best formatting that conforms to the
+ style guide. It is not only concerned with lint errors, but also with the
+ styilistic appearance of Python code. The idea is also similar to the 'gofmt'
+ tool for the Go programming language.
+ .
+ This package provides the modules for Python 2.
 
 Package: yapf3
 Architecture: all
-Depends: ${python3:Depends}, ${misc:Depends}
+Depends: ${misc:Depends},
+ ${python3:Depends},
+ python3-yapf
 Description: Python code formatter for different styles (Python 3)
  Yapf is a tool that reformats code to the best formatting that conforms to the
  style guide. It is not only concerned with lint errors, but also with the
  styilistic appearance of Python code. The idea is also similar to the 'gofmt'
- tool for the Go programming language. This package installs the tool for Python
- 3.
+ tool for the Go programming language.
+ .
+ This package provides the command-line interface for Python 3.
+
+Package: python3-yapf
+Architecture: all
+Section: python
+Depends: ${misc:Depends},
+ ${python3:Depends}
+Breaks: yapf3 (<< 0.17.0-2)
+Replaces: yapf3 (<< 0.17.0-2)
+Description: public modules for yapf (Python 3)
+ Yapf is a tool that reformats code to the best formatting that conforms to the
+ style guide. It is not only concerned with lint errors, but also with the
+ styilistic appearance of Python code. The idea is also similar to the 'gofmt'
+ tool for the Go programming language.
+ .
+ This package provides the modules for Python 3.
diff --git a/debian/rules b/debian/rules
index 420e98a..675be8c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,22 +5,14 @@
 PYVERS=$(shell pyversions -sv)
 PY3VERS=$(shell py3versions -sv)
 export PYBUILD_NAME=yapf
+export PYBUILD_DESTDIR_python2=debian/python-${PYBUILD_NAME}
+export PYBUILD_DESTDIR_python3=debian/python3-${PYBUILD_NAME}
 
 %:
 	dh $@  --with python2,python3 --buildsystem=pybuild
 
 override_dh_auto_install:
 	dh_auto_install
-
-	set -e && for pyvers in $(PYVERS); do \
-python$$pyvers setup.py install --install-layout=deb \
---root $(CURDIR)/debian/yapf; \
-done
-
-	set -e && for pyvers in $(PY3VERS); do \
-python$$pyvers setup.py install --install-layout=deb \
---root $(CURDIR)/debian/yapf3; \
-done
-
-	mv $(CURDIR)/debian/yapf3/usr/bin/yapf $(CURDIR)/debian/yapf3/usr/bin/yapf3
-
+	dh_movefiles --package=yapf --sourcedir=$(PYBUILD_DESTDIR_python2) usr/bin
+	dh_movefiles --package=yapf3 --sourcedir=$(PYBUILD_DESTDIR_python3) usr/bin
+	(cd $(CURDIR)/debian/yapf3 && mv ./usr/bin/yapf ./usr/bin/yapf3)
-- 
2.14.1

Bug#877701: patch attached

[Ghislain Vaillant]

Here is a patch removing the confusing section from the manpage.
>From cf7d5826bb9a17c68403f81ba9c9b346497c9c70 Mon Sep 17 00:00:00 2001
From: Ghislain Antony Vaillant 
Date: Tue, 14 Nov 2017 09:17:09 +
Subject: [PATCH] Remove confusing SEE ALSO section in manpages

Gbp-Dch: Short
Thanks: Matthias Urlichs for reporting
Closes: #877701
---
 debian/yapf.1  | 2 --
 debian/yapf3.1 | 2 --
 2 files changed, 4 deletions(-)

diff --git a/debian/yapf.1 b/debian/yapf.1
index dccfae6..66c774d 100644
--- a/debian/yapf.1
+++ b/debian/yapf.1
@@ -48,5 +48,3 @@ don't search for local style definition (.style.yapf)
 .IP
 [\-\-style STYLE] [\-\-style\-help] [\-\-no\-local\-style]
 [files [files ...]]
-.SH "SEE ALSO"
-More detailed information can be found in the html files in /usr/local/share/doc/yapf
diff --git a/debian/yapf3.1 b/debian/yapf3.1
index 68f9dd7..e68dc72 100644
--- a/debian/yapf3.1
+++ b/debian/yapf3.1
@@ -48,5 +48,3 @@ don't search for local style definition (.style.yapf3)
 .IP
 [\-\-style STYLE] [\-\-style\-help] [\-\-no\-local\-style]
 [files [files ...]]
-.SH "SEE ALSO"
-More detailed information can be found in the html files in /usr/local/share/doc/yapf3
-- 
2.14.1

Bug#880958: yapf3 explicitly depends on python3.5

[Ghislain Vaillant]

Thank you Matthias for raising this issue. CC'ing the maintainer in case 
she's not subscribed.


On Mon, 6 Nov 2017 11:52:00 +0100 Matthias Klose  wrote:

Package: yapf3
Version: 0.17.0-1
Severity: serious
Tags: sid buster

yapf3 explicitly depends on python3.5. One mistake certainly is the b-d on
python3-all, which is wrong for an application-only package.


The application is not compliant with the Python packaging guidelines. 
The public modules should be split from the application package. See 
#879196 for a discussion about it.


I have proposed a patch offline but it has yet to be applied. Fixing 
#879196 will transitively fix the issue you just reported.



And if this package is application-only, why ship both Python2 and Python3 
vesions?


It is nether application-only, nor Python 3 specific.

Cheers,
Ghis

Bug#881199: RFS: python-coloredlogs/7.3-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: coloredlogs
  Version : 7.3-1
  Upstream Author : Peter Odding 
* URL : https://coloredlogs.readthedocs.io
* License : Expat
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/cgit/python-modules/packages/python-coloredlogs.git

Changes since the last upload:

  * New upstream version 7.3
  * Bump the standards version to 4.1.1
  * Add recommended get-orig-source target

Best regards,
Ghis

Bug#881054: libarrayfire-opencl3: "INTERNAL KERNEL BUILD ERROR" from af::matmulTN

[Ghislain Vaillant]

Hi Ralf,

Based on the content of your report, you are suggesting that the latest 
version (3.5.1 at this very time) would solve the issue you are 
experiencing, am I correct?


Cheers,
Ghis

Bug#880729: RFS: python-parameterized/0.6.1-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-parameterized
  Version : 0.6.1-2
  Upstream Author : David Wolever
* URL : https://github.com/wolever/parameterized
* License : BSD
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/cgit/python-modules/packages/python-parameterized.git

Changes since the last upload:

  * Fix debci failures due to a buggy test
- New patch Remove-unicode-docstring-test.patch
  * Fixup the Vcs-Browser URI
  * Remove superfluous nocheck guards
  * Add recommended get-orig-source target
  * Bump the standards version to 4.1.1

Best regards,
Ghis

Bug#880577: RFS: shark/3.1.4+ds1-1 [RC]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: shark
  Version : 3.1.4+ds1-1
  Upstream Author : Christian Igel 
* URL : http://image.diku.dk/shark/
* License : LGPL-3
  Section : science

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/cgit/debian-science/packages/shark.git

Changes since the last upload:

  * New upstream version 3.1.4+ds1 (Closes: #853658)
  * Add missing Built-Using metadata for the docs
  * Add support for the nodoc build profile
  * Build the docs with Python 3
  * Bump the standards version to 4.1.1

Regards,
Ghis

Bug#880443: RFS: spyder-reports/0.1.1-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: spyder-reports
  Version : 0.1.1-1
  Upstream Author : Spyder Project Contributors
* URL : https://github.com/spyder-ide/spyder-reports
* License : Expat
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/cgit/debian-science/packages/spyder-reports.git

Changes since the last upload:

  * Initial release. (Closes: #872534)

Regards,
Ghis

Bug#880442: RFS: python-jsonrpc/1.10.3-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-jsonrpc
  Version : 1.10.3-1
  Upstream Author : Kirill Pavlov 
* URL : https://github.com/pavlov99/json-rpc
* License : Expat
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/cgit/python-modules/packages/python-jsonrpc.git

Changes since the last upload:

  * Initial release. (Closes: #879050)

Regards,
Ghis

Bug#880412: RFS: python-h5netcdf/0.5.0-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-h5netcdf
  Version : 0.5.0-1
  Upstream Author : Stephan Hoyer 
* URL : https://github.com/shoyer/h5netcdf
* License : BSD
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/git/debian-science/packages/python-h5netcdf.git

Changes since the last upload:

  * New upstream version 0.5.0
  * Add recommended get-orig-source target

Regards,
Ghis

Bug#880408: RFS: python-pymeasure/0.5-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-pymeasure
  Version : 0.5-1
  Upstream Author : PyMeasure Developers
* URL : https://github.com/ralph-group/pymeasure
* License : Expat
  Section : python

Please check out the package by visiting the following URL:


https://anonscm.debian.org/git/debian-science/packages/python-pymeasure.git

Changes since last upload:

  * New upstream version 0.5
  * Refresh the patch queue
  * Bump the standards version to 4.1.1
  * Add recommended get-orig-source target

Regards,
Ghis

Bug#880406: RFS: python-bayespy/0.5.12-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-bayespy
  Version : 0.5.12-1
  Upstream Author : Jaakko Luttinen 
* URL : https://www.bayespy.org
* License : Expat
  Section : python

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/python-bayespy.git

Changes since the last upload:

  * New upstream version 0.5.12
  * Bump the standards version to 4.1.1
  * Add recommended get-orig-source target

Regards,
Ghis

Bug#880405: RFS: python-meshio/1.8.17-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-meshio
  Version : 1.8.17-1
  Upstream Author : Nico Schlömer
* URL : https://github.com/nschloe/meshio
* License : Expat
  Section : python

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/python-meshio.git

Changes since last upload:

  * New upstream version 1.8.17
  * Bump the standards version to 4.1.1

Regards,
Ghis

Bug#879196: src:yapf: Split public modules from yapf / yapf3

[Ghislain Vaillant]

On 22/10/17 21:55, Ana C. Custura wrote:

Hi Ghis,


The Debian Python policy stipulates that public modules be provided in a
separate binary package [1]. Please consider packaging the public
modules for yapf / yapf3 in separate python-yapf / python3-yapf binary
packages and have yapf /yapf3 depend on them.


Many thanks for this, I had a read through the policy and am happy to do
it,  I'm looking at the next week or so.


Great, thanks.


I would have offered to do it myself, but it looks like your package is
not under team-maintenance. You might want to consider joining a team
(for instance the DPMT) to ease future maintenance efforts.


Joining  a team sounds like a good idea,  thanks for the advice!


I'd be happy to handle the transition to the DPMT for you. I am a member 
of the team, and have done such transitions multiple times in the past.


Cheers,
Ghis

Bug#878804: RFS: shotwell/0.26.3-1

[Ghislain Vaillant]

On 22/10/17 21:12, Jeremy Bicha wrote:

Jörg, I can sponsor this for you since I have been maintaining
shotwell in Ubuntu this year.

1. Please add a Breaks to shotwell instead of just a Replaces. It
wouldn't hurt to bump the version too like this:

Breaks: shotwell-common (<< 0.26.3-1)
Replaces: shotwell-common (<< 0.26.3-1)

I think you can remove this line though
Breaks: shotwell (<< 0.26.2-1)

2. Please remove all the obsolete patches from your debian/patches/
instead of just disabling them.

3. I'm attaching a patch to fix the install of appstream metadata.
You'll also need to modify debian/shotwell.install to install the
metadata.

--- debian/shotwell.install2017-09-22 17:26:18.0 -0400
+++ ../debian/shotwell.install2017-10-22 15:59:36.667571371 -0400
@@ -1,3 +1,4 @@
  usr/bin
  usr/lib
  usr/share/applications
+usr/share/appdata


From the AppStream guidelines [1], the metadata are to be installed 
under /usr/share/metainfo not /usr/share/appdata. Otherwise, Lintian 
will trigger a warning [2].


[1] https://wiki.debian.org/AppStream/Guidelines
[2] 
https://lintian.debian.org/tags/appstream-metadata-in-legacy-location.html


Ghis

Bug#860768: Switch from ITP to RFP

[Ghislain Vaillant]

Control: retitle -1 RFP: python-ordered-set
Control: noowner -1

On Wed, 19 Apr 2017 21:47:25 +0100 Ghislain Antony Vaillant 
 wrote:

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-ordered-set
  Version : 2.0.2
  Upstream Author : Luminoso Technologies, Inc.
* URL : https://github.com/LuminosoInsight/ordered-set/
* License : Expat
  Programming Lang: Python
  Description : ordered set implementation for Python

This package is a dependency for sphinxcontrib-bibtex. It will be
co-maintained by the DPMT.


sphinxcontrib-bibtex no longer needs this ITP to be fulfilled, as the 
dependency on ordered-set can be substituted with sortedcollections, 
which is already packaged.


Ghis

Bug#879050: Reopened

[Ghislain Vaillant]

Control: reopen -1 !

Please have a closer look at #700960. This is not the same piece of 
software as this ITP.


If anything, #700960 should have been merged with #542166 and closed as 
a result.


Ghis

Bug#861649: Newer version uploaded

[Ghislain Vaillant]

On 16/10/17 15:39, Gard Spreemann wrote:

On Monday 16 October 2017 11:53:08 CEST Ghislain Vaillant wrote:

On 16/10/17 11:22, Gard Spreemann wrote:

Not relevant since the upload would be to sid anyway, right?


FYI, current version is 4.1.1.


Checked and bumped. Thanks.


   E: python3-gudhi: binary-or-shlib-defines-rpath
   usr/lib/python3/dist-packages/gudhi.cpython-35m-x86_64-linux-gnu.so
   /usr/lib/x86_64-linux-gnu>
I admit I'm on thin ice here, but from
https://wiki.debian.org/RpathIssue I had the impression that the use
of RPATH is OK here since only the python3 executable would be loading
the shared object. Am I correct?


It will import is as a module, no? You should not need rpath for public
extension modules. Look for usage of `runtime_library_dirs` in the
definition of the extension module within setup.py.


I've added a patch to give an empty argument to
runtime_library_dirs. The lintian warning went away, and the Python
extension still works.

Thank you.


These are very simple example programs only used together with the
documentation and their own source code. As such it feels a bit
strange for them to have manpages. I could also remove that binary
package, if you think that is better.


Ask yourself whether these are worth shipping. I suspect the examples
are more useful in source code form than binary.


I've changed the -examples package to just ship sources.


I believe that's wise.


By the way: I'm currently letting dh have its way with whether or not
it compresses the sources, which gives an inconsistent result. Should
I do something about this?


Yes, I'd advise to override dh_compress to exclude the examples from 
compression.



This was actually done on purpose. The examples are really meant to be
used together with the documentation, and as such I don't think the
warning applies here. Please let me know if I'm wrong.


Did you declare libgudhi-examples as a library package instead of misc
or doc by any chance (see Section field in d/control)? Then, the warning
would be accurate. Instead, ship the examples in source code form and
make the package Section: misc.


No problem. Glad to see your packaging work is progressing.

Ghis

Bug#861649: Newer version uploaded

[Ghislain Vaillant]

On 16/10/17 11:22, Gard Spreemann wrote:

On Saturday 14 October 2017 00:56:11 CEST Adam Borowski wrote:

Before a human review, it'd be good to fix issues found by automated
tools.  In particular, lintian throws a lot.  Please run it on both
source and built packages (lintian gudhi*changes).

"lintian -i" gives a helpful explanation how to fix these problems.


Hello, and thanks a lot for getting back to me.

I *think* I have evaluated all of the lintian errors, but any
suggestions or comments are very welcome:


  W: gudhi source: newer-standards-version 4.0.0 (current is 3.9.8)

Not relevant since the upload would be to sid anyway, right?


FYI, current version is 4.1.1.


  E: python3-gudhi: binary-or-shlib-defines-rpath 
usr/lib/python3/dist-packages/gudhi.cpython-35m-x86_64-linux-gnu.so 
/usr/lib/x86_64-linux-gnu

I admit I'm on thin ice here, but from
https://wiki.debian.org/RpathIssue I had the impression that the use
of RPATH is OK here since only the python3 executable would be loading
the shared object. Am I correct?


It will import is as a module, no? You should not need rpath for public 
extension modules. Look for usage of `runtime_library_dirs` in the 
definition of the extension module within setup.py.

  W: gudhui: binary-without-manpage usr/bin/gudhui

I will work on creating a man page for this.


  W: libgudhi-examples: binary-without-manpage usr/bin/libgudhi-example-*

These are very simple example programs only used together with the
documentation and their own source code. As such it feels a bit
strange for them to have manpages. I could also remove that binary
package, if you think that is better.


Ask yourself whether these are worth shipping. I suspect the examples 
are more useful in source code form than binary.



  W: libgudhi-examples: lib-recommends-documentation recommends: libgudhi-doc

This was actually done on purpose. The examples are really meant to be
used together with the documentation, and as such I don't think the
warning applies here. Please let me know if I'm wrong.


Did you declare libgudhi-examples as a library package instead of misc 
or doc by any chance (see Section field in d/control)? Then, the warning 
would be accurate. Instead, ship the examples in source code form and 
make the package Section: misc.



  W: libgudhi-doc: embedded-javascript-library 
usr/share/doc/libgudhi/html/jquery.js please use libjs-jquery


From #736360 and #736432 I had the impression that this is a

long-standing problem where there is not yet any consensus about how
to proceed. Am I overlooking something?


Indeed, that's a doxygen specific issue. You may leave it like that or 
override for it. It's up to what your future sponsor prefers.


Cheers,
Ghis

Bug#877700: [Help] Exclusion did not worked (Was: Bug#877419: Bug#877700: RM: pandas [arm64 armel armhf mips mips64el mipsel s390x] ...)

[Ghislain Vaillant]

On 14/10/17 07:54, Andreas Tille wrote:

On Fri, Oct 13, 2017 at 08:00:36PM +0200, Andreas Tille wrote:


I might try to pick some of the failed tests from the logs.  I did so
once with kind of iterative uploads for python-cogent package by
checking the logs of the failing architectures.  If you think the proper
way would be to login to each single architecture and build there this
would not fit into my time frame I'm willing to spent on this task.


I treid to approach this by re-using the exclusion mechanism that was
used before (but not activated) in the rules file of pandas[1]:

  
diff --git a/debian/rules b/debian/rules

index 286e36561..186ae36f1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,17 +24,8 @@ UVER_PYSHORT := $(shell echo $(UVER_PY) | sed -e 
's,+git.*,,g')
  
  MIN_CYTHONVER = 0.23
  
-ifneq ($(DEB_HOST_ARCH),amd64)

-   # obtained by   grep -e 'ERROR:' -e 'FAIL:' pandas-sid.log |awk '{print 
$2;}' | sed -e 's,^test,,g' | tr '\n' '|'
-   # on log of failed tests on mips build box on pandas 0.19.2-1
-   # Majority of them is probably due to a bug in NumPy 
https://github.com/numpy/numpy/issues/8325
-   # of incorrectly treating NaT on non-amd64 platforms
-   # So for stretch release for now disabling those tests on non-amd64
-# plot ones are excluded due to seems to be a bug in matplotlib which 
shows up
-# on s390
-   # EXCLUDE_TESTS_ARCH := --exclude 
'test(_frame_from_json_to_json|_misc_example|ArrayNumpyLabelled|DataFrameNumpyLabelled|_resample_timedelta_values|_timestamp_compare|_where_timedelta|ArrayNumpyExcept|_resample_datetime_values|_NaT_cast|_where_datetime|_where_datetime|_datetimelikes_nan|_value_counts_normalized|_agg_dict_parameter_cast_result_dtypes|_boxplot|_boxplot_vertical|_errorbar_plot|_hist_df|_line_area_stacked|_plot|_round_trip_valid_encodings)'
-# Try without excludes now that we are so much in the future ;)
-   EXCLUDE_TESTS_ARCH :=
+ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH), arm64 armel armhf mips 
mips64el mipsel s390x alpha hppa powerpc ppc64))
+   EXCLUDE_TESTS_ARCH := --exclude 
'test(test_value_counts_normalized|test_resample_timedelta_values|test_resample_datetime_values|test_datetimelikes_nan|test_where_datetime|test_timestamp_compare|test_agg_dict_parameter_cast_result_dtypes|test_NaT_cast|test_where_datetime|test_where_timedelta)'
  else
 EXCLUDE_TESTS_ARCH :=
  endif


Unfortunately this ends up in:

...
pandas_datareader: None
usage: pytest.py [options] [file_or_dir] [file_or_dir] [...]
pytest.py: error: unrecognized arguments: --exclude
   inifile: /<>/setup.cfg
   rootdir: /<>
debian/rules:109: recipe for target 'python-test2.7' failed
...

I confirm that I have not found the --exclude option for pytest.

I'm not that experienced with pytest.  From some short research I had
the idea to quilt patch some "slow" markers for the failing tests and
for the affected architectures ignore those "slow" tests.

Any better technical idea?


Indeed you could use a custom "slow" marker for it. The corresponding 
patch should be upstreamable too if appropriately motivated.


Ghis

Bug#810788: Preparing a package of openshot-qt

[Ghislain Vaillant]

On 11/10/17 12:20, Dr. Tobias Quathamer wrote:

Am 20.09.2017 um 11:05 schrieb Dr. Tobias Quathamer:

Hi Ghis,

any news on the git push?


Hi Ghis,

the git repository on Alioth is still empty -- it would be great if you
could find the time to push your work there. :-)


I recently re-installed my system and must have deleted the repository 
by mistake. I cannot find it in my backups.


I am afraid you'd have to start from scratch on that one.

Ghis

Bug#878175: RFS: python-mechanicalsoup/0.8.0-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-mechanicalsoup
  Version : 0.8.0-1
  Upstream Author : Mirth Hickford 
* URL : https://github.com/hickford/MechanicalSoup
* License : Expat
  Section : python

One can check out the package by visiting the following URL:


https://anonscm.debian.org/cgit/python-modules/packages/python-mechanicalsoup.git

Changes since last upload:

  * Add recommended get-orig-source target
  * New upstream version 0.8.0
  * Bump the minimum Python versions to 2.7 and 3.4
  * Fixup the Vcs-Browser URI
  * Bump the standards version to 4.1.1
  * Avoid dependency on pytest-runner
- New patch No-pytest-runner.patch
  * Move extend-diff-ignore to d/s/options

Best regards,
Ghis

Bug#878174: RFS: pytest-qt/2.2.1-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: pytest-qt
  Version : 2.2.1-1
  Upstream Author : Bruno Oliveira
* URL : https://github.com/pytest-dev/pytest-qt
* License : Expat
  Section : python

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/cgit/python-modules/packages/pytest-qt.git

Changes since the last upload:

  * New upstream version 2.2.1
  * Add choice of PyQt APIs to Recommends
  * Bump the standards version to 4.1.1

Regards,
Ghis

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

On 10/10/17 11:58, Adrian Bunk wrote:

On Tue, Oct 10, 2017 at 12:08:29AM +0100, Ghislain Vaillant wrote:

On 09/10/17 23:06, Adrian Bunk wrote:

On Mon, Oct 09, 2017 at 12:28:22PM +0100, Ghislain Vaillant wrote:

...
I was complaining about the insufficiencies behind this RC, more than the
situation with Sphinx. No offense to Adrian, but getting an RC bug reported
without much context to work with is just plain frustrating. Without your
intervention, this RC could have dragged for a long time.


Ghis, I do consider our repeated attempts to blame me for not fixing a bug in
your package VERY offensive.


I don't recall saying anywhere in this thread that I expected *you* to
provide a patch for this. I complained about the lack of context of the
initial bug report, albeit too bluntly to your taste.
...


Your repeated "without much context to work with" are just fancy words
for blaming me for not having debugged a FTBFS in your package.


This interpretation is yours. I acknowledged earlier that nothing was 
implied on my end. Whether you believe or not is a different matter and 
beyond the point of this thread.



I did tell you everything I knew (including providing the email address
of the person causing the FTBFS in the initial bug report), and it is
not my job to debug a FTBFS in your package.



You were even lucky that I was able to point you at what broke it,
there are more than 200 open RC bugs for FTBFS I reported [1] and
in many cases the error message is all I can provide.


Since you failed to quote the second half of my previous reply, I'll 
paste it again:


"Please accept my sincere apologies"

Should you decide to reply to this email, I would appreciate you quoting 
it in full instead of selective pieces of it to fulfill your narrative.


I have come clean and apologized for my wrongs, now is the time to shake 
hands and move on.


Regards,
Ghis

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

On 09/10/17 23:06, Adrian Bunk wrote:

On Mon, Oct 09, 2017 at 12:28:22PM +0100, Ghislain Vaillant wrote:

...
I was complaining about the insufficiencies behind this RC, more than the
situation with Sphinx. No offense to Adrian, but getting an RC bug reported
without much context to work with is just plain frustrating. Without your
intervention, this RC could have dragged for a long time.


Ghis, I do consider our repeated attempts to blame me for not fixing a bug in
your package VERY offensive.


I don't recall saying anywhere in this thread that I expected *you* to 
provide a patch for this. I complained about the lack of context of the 
initial bug report, albeit too bluntly to your taste.



I did not break it, I am not the maintainer of the package that broke,
and I have zero knowledge about either package.


Neither did I explicitly or implicitly held you responsible for the 
issue leading up to this RC bug. Please read again.



And the fact that I even did the extra work of finding the exact change
that broke your package makes it even more insulting - for a large part
of the FTBFS I report I do not even have a clue what broke it.



The only thing I regret is that I tried to be helpful after your initial
email, and I am seriously considering giving you a permanent entry in my
killfile so that I won't have to read another email from you for the rest
of my life.


Let's not reach such extremes yet. We are all working towards the same 
goal, i.e. making Debian a quality Linux distribution. Please accept my 
sincere apologies if I did hurt your feelings in any way.


Now, let's just move on shall we.

Ghis

Bug#877196: Please fix lintian warnings

[Ghislain Vaillant]

On 09/10/17 19:14, Andreas Tille wrote:

Hi Ghislain

Please fix the following issues:

W: nfft source: unnecessary-testsuite-autopkgtest-header
W: libnfft3-2: transitional-package-should-be-oldlibs-optional oldlibs/extra


Both of these are already addressed. Are you building from the right 
tag? Otherwise, these could be false positives I guess?



W: libnfft3-doc: embedded-javascript-library 
usr/share/doc/libnfft3-doc/html/jquery.js please use libjs-jquery


That's the classic issue with the copy of jquery generated by doxygen. 
The Debian maintainer for src:doxygen recommends to not act on it, and I 
was told before to leave the warning as is instead of using an override.


Ghis

Bug#878086: Please fix "appstream-metadata-in-legacy-location usr/share/appdata/pyzo.appdata.xml"

[Ghislain Vaillant]

Hi Andreas,

On 09/10/17 19:09, Andreas Tille wrote:

Hi Ghislain,

please fix

W: pyzo: appstream-metadata-in-legacy-location 
usr/share/appdata/pyzo.appdata.xml
N:
N:AppStream metadata file was found in /usr/share/appdata/. The AppStream
N:XML files should be placed in /usr/share/metainfo/.
N:
N:Refer to https://wiki.debian.org/AppStream/Guidelines for details.
N:
N:Severity: minor, Certainty: certain
N:
N:Check: appstream-metadata, Type: binary


Done and retagged.


and may be also these

I: pyzo: font-in-non-font-package 
usr/share/pyzo/pyzo/resources/fonts/SourceCodePro-Bold.otf
N:
N:This package contains a *.ttf, *.otf, or *.pfb file, file extensions
N:used by TrueType, OpenType, or Type 1 fonts, but the package does not
N:appear to be a dedicated font package. Dedicated font package names
N:should begin with fonts-. (Type 1 fonts are also allowed in packages
N:starting with xfonts-.) If the font is already packaged, you should
N:depend on that package instead. Otherwise, normally the font should be
N:packaged separately, since fonts are usually useful outside of the
N:package that embeds them.
N:
N:Severity: wishlist, Certainty: possible
N:
N:Check: files, Type: binary, udeb
N:
I: pyzo: font-in-non-font-package 
usr/share/pyzo/pyzo/resources/fonts/SourceCodePro-Regular.otf


I remembered looking at packaging the SourceCodePro fonts for Debian. 
The build process was utterly horrible and I eventually gave up.



Kind regards and thanks for your work on these packages

  Andreas.

PS: Here comes my regular question about your DM application. :-P


I know I know XD

Cheers,
Ghis

Bug#878089: RFS: dcm2niix/1.0.20170923-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name    : dcm2niix
  Version : 1.0.20170923-1
  Upstream Author : Chris Rorden
* URL : https://github.com/rordenlab/dcm2niix
* License : BSD
  Section : science

One can check out the package by visiting the following URL:

https://anonscm.debian.org/cgit/debian-med/dcm2niix.git

Changes since the last upload:

  * New upstream version 1.0.20170923
  * Bump the standards version to 4.1.1

Regards,
Ghis

Bug#878086: RFS: pyzo/4.4.3-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: pyzo
  Version : 4.4.3-1
  Upstream Author : Almar Klein
* URL :http://www.pyzo.org/
* License : BSD
  Section : science

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/cgit/debian-science/packages/pyzo.git

Changes since the last upload:

  * Add recommended get-orig-source target
  * New upstream version 4.4.3
  * Move iep package to oldlibs/optional
  * Bump the standards version to 4.1.1

Best regards,
Ghis

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

On 03/10/17 12:28, Dmitry Shachnev wrote:

Control: forwarded -1 https://bitbucket.org/pybtex-devs/pybtex/pull-requests/9/

Hi Ghislain,

On Sat, Sep 30, 2017 at 10:40:52AM +0100, Ghislain Vaillant wrote:

And what the hell am I supposed to do with this?!

Nice of you to report the issue but, without further context, I can't take
further actions.

Isn't it the Dmitry's responsibility to at least communicate on the change
and suggest solutions for it to people impacted by RCs? If he did, please
point me to the announcement in case I missed it.

Sorry for that. I was aware of 5 or 6 packages that my change could affect,
but I did not expect that there would be more of them. Also I do not have
the resources to rebuild all reverse dependencies for every change in Sphinx.

Anyway, better late than never, so let me explain what happened there:

* Sphinx has a JavaScript library (doctools.js) that it uses to perform
   search on built HTML documents. This library is loaded from search.html
   page, and that page should contain a DOCUMENTATION_OPTIONS JavaScript
   object which acts like configuration for that library.

* Right now, if you open /usr/share/doc/python-pybtex-doc/html/search.html
   from your package, you will notice that search does not work. The browser
   console will have an error like this:

   searchtools.js:543:96: TypeError: suffix is undefined

   It is not something that I broke; it is caused by a change in Sphinx 1.5,
   that added one more required option (SOURCELINK_SUFFIX) which should be in
   DOCUMENTATION_OPTIONS.


Many thanks for providing these details.


* Good news is that you should not notice such issues yourself; dh_sphinxdoc
   performs the sanity check for you. It had a warning about this since sphinx
   1.5.2-2. In the latest upload I turned this warning into error, which is
   why you get this FTBFS bug.

I see.

* The only packages affected by this are ones that have custom templates,
   that do not inherit from sphinx/themes/basic/layout.html. Yours has one in
   docs/theme/layout.html.

* I have just created an upstream pull request which fixes this issue. You
   can grab the patch from there.

Thanks for working on a fix, very much appreciated.

In future, please CC me if you want to complain about Sphinx.

I was complaining about the insufficiencies behind this RC, more than 
the situation with Sphinx. No offense to Adrian, but getting an RC bug 
reported without much context to work with is just plain frustrating. 
Without your intervention, this RC could have dragged for a long time.


Ghis

Bug#877150: Forwarded upstream

[Ghislain Vaillant]

Control: forwarded -1 https://github.com/shoyer/h5netcdf/issues/32

Bug#852138: theano 0.9 ready for upload

[Ghislain Vaillant]

On 08/10/17 12:53, Rebecca N. Palmer wrote:

On 30/09/17 15:38, Rebecca N. Palmer wrote:
In Alioth (e49f225, not tagged as my other package's sponsor prefers 
not doing that until upload).


Note that my hardware can't run the GPU tests due to #877316, so it 
might be a good idea for someone else to do so before upload.


Has anyone tried this, and if not, should I try asking elsewhere (e.g. 
the d-science list)?


On Nvidia systems, building theano includes the GPU tests if the GPU 
is accessible (it may not be in chroots) and the required dependencies 
are installed: python-pygpu python3-pygpu nvidia-cuda-dev libcuda1 
nvidia-driver


(The -dev version is required because libgpuarray dlopen()s libraries 
by their un-numbered names)




IMO, we should just focus on the CPU tests and hope for the best for the 
GPU ones. GPU testing could be done within debci, but I am not even sure 
how we could ensure a test machine is provisioned with the necessary 
hardware for it (nvidia).


If you want something that doesn't take 5 hours, it's also possible to 
run just the libgpuarray tests with nosetests3 -v root>/theano/gpuarray/tests/ , but this will miss some GPU tests 
elsewhere in the source tree.


Theano can also use OpenCL, but this is still in development and must 
be explicitly enabled with THEANO_FLAGS='init_gpu_device=opencl0:0' 
(dependencies: python-pygpu python3-pygpu libclblas-dev 
ocl-icd-opencl-dev mesa-opencl-icd).


Considering upstream confirmed active development will stop next year, I 
would not hold on the prospect of full OpenCL support.


Cheers,
Ghis

Bug#877316: clblas: Crashes on single-precision-only hardware, due to double-precision literals

[Ghislain Vaillant]

Hi Rebecca,

On Sat, 30 Sep 2017 14:47:03 +0100 "Rebecca N. Palmer" 
 wrote:

Package: libclblas2
Version: 2.12-1
Control: tags -1 upstream
Control: affects -1 beignet-opencl-icd

Some clblas operations use '0.0' (a double-precision literal) not '0.0f' 
(a single-precision literal) even when processing single-precision arrays.


This causes it to crash on GPUs that don't support double precision:

ASSERTION FAILED: sel.hasDoubleType()
   at file 
/build/beignet-1.3.1/backend/src/backend/gen_insn_selection.cpp, 
function void 
gbe::ConvertInstructionPattern::convertBetweenFloatDouble(gbe::Selection::Opaque&, 
const gbe::ir::ConvertInstruction&, bool&) const, line 6148


This particular 0.0 appears to have come from 
http://sources.debian.net/src/clblas/2.12-1/src/library/blas/AutoGemm/KernelOpenCL.py/#L368, 
but there may well be more.


This issue also exists in upstream git.


Are you aware of an existing bug filed upstream for this? If so, could 
you link it to this bug report with an appropriate forward comand ?


Otherwise, would you please consider filing the bug upstream, since you 
already triaged it as non Debian specific.


Thanks for investigating this.

Ghis

Bug#852138: theano 0.9 ready for upload

[Ghislain Vaillant]

H Rebecca,

On 30/09/17 15:38, Rebecca N. Palmer wrote:
In Alioth (e49f225, not tagged as my other package's sponsor prefers not 
doing that until upload).


Note that my hardware can't run the GPU tests due to #877316, so it 
might be a good idea for someone else to do so before upload.


Thanks for the heads-up,

I thought Theano v0.9.x would require libgpuarray 0.7.x? Or is that for 
the future (and probably last) 1.0 version? Please let me know if you 
have further pieces of information.


Ghis

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300


And what the hell am I supposed to do with this?!

Nice of you to report the issue but, without further context, I can't 
take further actions.


Isn't it the Dmitry's responsibility to at least communicate on the 
change and suggest solutions for it to people impacted by RCs? If he 
did, please point me to the announcement in case I missed it.


This is really frustrating.

Ghis

Bug#877196: RFS: nfft/3.4.0~rc2-1 [experimental]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: nfft
  Version : 3.4.0~rc2-1
  Upstream Author : Prof. Dr. Daniel Potts 


* URL : http://www-user.tu-chemnitz.de/~potts/nfft/
* License : GPL-2+
  Section : science

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/nfft.git

Changes since the last upload:

  * New upstream version 3.4.0~rc2
  * Mark transitional packages oldlibs/optional
  * Remove test restrictions for ppc architectures
  * Add support for the nocheck build option
  * Bump the standards version to 4.1.1

Regards,
Ghis

Bug#877057: RFS: python-bayespy/0.5.11-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: python-bayespy
  Version : 0.5.11-1
  Upstream Author : Jaakko Luttinen 
* URL : https://www.bayespy.org
* License : Expat
  Section : python

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/python-bayespy.git

Changes since the last upload:

  * New upstream version 0.5.11
  * Update copyright dates
  * Revert exclusion of plot tests
  * Use DEB_BUILD_OPTIONS for nocheck
  * Replace occurrences of findstring with filter
  * Fixup whitespacing in rules file
  * Move extend-diff-ignore to d/s/options
  * Add an autopkgtest suite
  * Fixup the Vcs-Browser URI
  * Drop install dependency on python3-tk
  * Bump the standards version to 4.1.0

Regards,
Ghis

Bug#872652: Problems building package

[Ghislain Vaillant]

On 24/09/17 11:19, Andreas Tille wrote:

On Sun, Sep 24, 2017 at 08:39:02AM +0100, Ghislain Vaillant wrote:


Are you sure your cowbuilder setup is ok? This is usually not a good sign:


BTW, the issue happens inside the clean target which is run *before*
chrooting into cowbuilder chroot.


I have pushed a new version which gets rid of this side effect. Could 
you try again with the latest tip of the master branch?


Ghis

Bug#872652: Problems building package

[Ghislain Vaillant]

On 23/09/17 18:15, Andreas Tille wrote:

On Sat, Sep 23, 2017 at 10:39:35AM +0100, Ghislain Vaillant wrote:

Frederic gave a hint to bug #873921.


Now that the situation with pandas / statsmodels is resolved, the package
builds fine [1].

[1] 
http://debomatic-amd64.debian.net/distribution#unstable/python-pymeasure/0.4.6-1/buildlog

Could you push it to the archive please?


$ gbp-build
gbp:info: Tarballs 'python-pymeasure_0.4.6.orig.tar.gz' not found at 
'../tarballs/'
gbp:info: Exporting 'WC' to 
'/home/andreas/debian-maintain/alioth/debian-science/git/packages/build-area/python-pymeasure-tmp'
gbp:info: Moving 
'/home/andreas/debian-maintain/alioth/debian-science/git/packages/build-area/python-pymeasure-tmp'
 to 
'/home/andreas/debian-maintain/alioth/debian-science/git/packages/build-area/python-pymeasure-0.4.6'
I: using cowbuilder as pbuilder
dpkg-checkbuilddeps: error: Unmet build dependencies: python3-all python3-pandas 
python3-pyqtgraph (>= 0.9.10) python3-pytest-runner python3-pyvisa python3-serial 
(>= 2.7) python3-sphinx python3-sphinx-rtd-theme
W: Unmet build-dependency in source
dpkg-source: info: using options from 
python-pymeasure-0.4.6/debian/source/options: 
--extend-diff-ignore=^[^/]+\.egg-info/
dpkg-source: info: applying No-privacy-breach.patch
dh clean --with python3,sphinxdoc --buildsystem=pybuild
debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/home/andreas/debian-maintain/alioth/debian-science/git/packages/build-area/python-pymeasure-0.4.6'
dh_auto_clean
I: pybuild base:184: python3.6 setup.py clean

Note: Bypassing https://pypi.python.org/simple/pytest-runner/ (disallowed host; 
see http://bit.ly/1dg9ijs for details).

Couldn't find index page for 'pytest-runner' (maybe misspelled?)

Note: Bypassing https://pypi.python.org/simple/ (disallowed host; see 
http://bit.ly/1dg9ijs for details).

No local packages or working download links found for pytest-runner
Traceback (most recent call last):
   File "setup.py", line 70, in 
 keywords="measure instrument experiment control automate graph plot"
   File "/usr/lib/python3.6/distutils/core.py", line 108, in setup
 _setup_distribution = dist = klass(attrs)
   File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 325, in 
__init__
 self.fetch_build_eggs(attrs['setup_requires'])
   File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 446, in 
fetch_build_eggs
 replace_conflicting=True,
   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 855, 
in resolve
 dist = best[req.key] = env.best_match(req, ws, installer)
   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1127, 
in best_match
 return self.obtain(req, installer)
   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1139, 
in obtain
 return installer(requirement)
   File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 518, in 
fetch_build_egg
 return cmd.easy_install(req)
   File "/usr/lib/python3/dist-packages/setuptools/command/easy_install.py", 
line 691, in easy_install
 raise DistutilsError(msg)
distutils.errors.DistutilsError: Could not find suitable distribution for 
Requirement.parse('pytest-runner')
E: pybuild pybuild:283: clean: plugin distutils failed with: exit code=1: 
python3.6 setup.py clean
dh_auto_clean: pybuild --clean --test-pytest -i python{version} -p "3.6 3.5" 
returned exit code 13
debian/rules:12: recipe for target 'override_dh_auto_clean' failed
make[1]: *** [override_dh_auto_clean] Error 25
make[1]: Leaving directory 
'/home/andreas/debian-maintain/alioth/debian-science/git/packages/build-area/python-pymeasure-0.4.6'
debian/rules:9: recipe for target 'clean' failed
make: *** [clean] Error 2
gbp:error: '~/bin/git-pbuilder ''' failed: it exited with 2


:-(


Not sure what to tell you. Both debomatic and my local sbuild do not 
report such issues.


Are you sure your cowbuilder setup is ok? This is usually not a good sign:

dpkg-checkbuilddeps: error: Unmet build dependencies [...]

And would explain why you are getting:

Could not find suitable distribution for Requirement.parse('pytest-runner')

Ghis

Bug#872652: Problems building package

[Ghislain Vaillant]

On Mon, 4 Sep 2017 13:16:46 +0200 Andreas Tille <andr...@an3as.eu> wrote:

Hi Ghislain,

On Mon, Sep 04, 2017 at 11:47:09AM +0200, Ghislain Vaillant wrote:
> Hi Andreas, how are you doing?

Fine thank you.
 
> On 04/09/17 11:27, Andreas Tille wrote:
> 
> I just ran a test build on debomatic, and it is now riddled with "undefined

> symbol: PyFPE_jbuf" errors which were not there before.
> 
> I believe this is symptomatic of a larger issue within the archive, since

> other Python packages I maintain have had a similar error raised by their
> respective autopkgtests recently. *sigh*

Frederic gave a hint to bug #873921.


Now that the situation with pandas / statsmodels is resolved, the 
package builds fine [1].


[1] 
http://debomatic-amd64.debian.net/distribution#unstable/python-pymeasure/0.4.6-1/buildlog


Could you push it to the archive please?

Cheers,
Ghis

Bug#876483: RFS: xtensor/0.11.2-1 [experimental]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: xtensor
  Version : 0.11.2-1
  Upstream Author : Johan Mabille, Sylvain Corlay and Wolf Vollprecht
* URL : http://quantstack.net/xtensor
* License : BSD
  Section : libs

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/xtensor.git

Changes since the last upload:

  * New upstream version 0.11.2
  * Refresh the patch queue
  * Fixup whitespacing in rules file
  * Replace occurrences of findstring with filter
  * Use DEB_BUILD_OPTIONS for the nocheck and nodoc guards

Regards,
Ghis