Bug#978594: O: pylint-plugin-utils -- Utilities and helpers for writing Pylint plugins (Python 3)

[Joseph Herlant]

Package: wnpp
Severity: normal
X-Debbugs-Cc: aerosti...@debian.org

I intend to orphan the pylint-plugin-utils package. I haven't taken any time
for my packages this year and don't see this changing anytime soon so retiring.

The package description is:
 This is not a direct Pylint plugin, but rather a set of tools

Bug#978593: O: pylint-django -- Pylint plugin for analysing code using Django (Python 3)

[Joseph Herlant]

Package: wnpp
Severity: normal
X-Debbugs-Cc: aerosti...@debian.org

I intend to orphan the pylint-django package. I didn't take any time for my
packages this year and don't see this changing anytime soon, so retiring.

The package description is:
 Features
   * Prevents warnings about Django-generated attributes such as
 Model.objects or Views.request.
   * Prevents warnings when using ForeignKey attributes
 ("Instance of ForeignKey has no member").
   * Fixes pylint's knowledge of the types of Model and Form field attributes
   * Validates Model.__unicode__ methods.
   * Meta informational classes on forms and models do not generate errors.
 It is also used by the Prospector tool.

Bug#978592: O: asciidoc -- Highly configurable text format for writing documentation

[Joseph Herlant]

Package: wnpp
Severity: normal

I intend to orphan the asciidoc package. I haven't had taken the time to take
care of my packages over the last few months and don't see this changing
anytime soon so I'm retiring.

The package description is:
 AsciiDoc is a text document format for writing articles, books, manuals and
 UNIX man pages. AsciiDoc files can be translated to HTML (with or without
 stylesheets), DocBook (articles, books and refentry documents) and LinuxDoc
 using the asciidoc command. AsciiDoc can also be used to build and maintain
 websites.
 .
 You write an AsciiDoc document the same way you would write a
 normal text document, there are no markup tags or weird format notations.
 AsciiDoc files are designed to be viewed, edited and printed directly or
 translated to other presentation formats
 .

Bug#971704: gnome-shell-pomodoro: diff for NMU version 0.18.0-0.1

[Joseph Herlant]

Thanks for doing that. I unfortunately haven't taken any time for
opensource since the beginning of this COVID madness.

Feel free to push it now. It's totally fine with me.

Thanks
Joseph

Bug#960400: gnome-shell-pomodoro: gnome-shell 3.36 compatibility

[Joseph Herlant]

Thanks for the report Antonio and sorry for the late reply, things
have been kind of crazy on my side lately.

I'll try to take care of the upgrade over the weekend.

Thanks,
Joseph

Bug#954780: Duplicate: almost identical content already shipped with vim-runtime

[Joseph Herlant]

Control: forwarded -1 https://github.com/asciidoc/asciidoc-py3/pull/100

Hi Pavel,

Thanks for pointing it out. I had no idea Stuart got it in vim too.
I pushed a PR upstream to get rid of it in the asciidoc repo. I'll
delete vim-asciidoc once upstream signed off on its removal.

Thanks,
Joseph

Bug#949780: maptool: Maptool segfaults

[Joseph Herlant]

Thanks for your answers.

On Sun, Jan 26, 2020 at 4:39 AM ael  wrote:
> I used the simplest defaults I think.
>
> In my history I just have
> cmake ../navit/
> make maptool
>
> Does that tell you what you need to know?

It does, thanks.

Joseph

Bug#949780: maptool: Maptool segfaults

[Joseph Herlant]

Hi,

Taking the england-latest.osm.pbf from
https://download.geofabrik.de/europe/great-britain.html it does fail
with 0.5.4 after several minutes of processing with (not a segfault
per say but still failing):

PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 62282 relations 0
tiles 7:17 181 MB
PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 62282 relations 0
tiles 7:47 181 MB
PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 62282 relations 0
tiles 8:17 181 MB
worker 3 exit
PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 62282 relations 0
tiles 8:18 181 MB
PROGRESS9: Processed 47104 nodes (8208 out) 0 ways 0 relations 0 tiles
8:18 181 MB
process_multipolygons:process (thread 0)
process_multipolygons:finish (thread 0)
maptool: /build/navit-vwCTlu/navit-0.5.4+dfsg.1/navit/maptool/itembin.c:93:
item_bin_copy_attr: Assertion `attr == attr_osm_wayid' failed.

You mention in the bug there that you were able to run your pbf by
compiling maptool from the git repo. What compilation flags did you
use?

Thanks for  your help,
Joseph

Bug#949780: maptool: Maptool segfaults

[Joseph Herlant]

Hi,

On Fri, Jan 24, 2020 at 2:00 PM ael  wrote:
> Package: maptool
> Version: 0.5.3+dfsg.1-2+b1

Please try with the 0.5.4 version currently in unstable as here have
been a lot of changes to maptool since 0.5.3.

> This was encountered while looking at the issues with navit on wince:
> see https://github.com/navit-gps/navit/issues/953#issuecomment-578313710

Are you using the debian binaries on wince?

> Search down that page to see the problem with the Debian testing
> maptool:
>
> maptool --protobuf -i
> /ssdback1/ael/mapping/mkgmap/great-britain-latest.osm.pbf test.bin
>
> but that SEGFAULTED almost immediately after writing some empty *.tmp


Could you provide the link to the .pbf or the proto and the way you
build it so we can reproduce it please? It's hard to debug without
more information.

> I see that there is a new version in unstable but I have not tried that
> version as yet.

Please try with the new version. There's been a lot of changes in
maptool between 0.5.3 and 0.5.4.

Thanks
Joseph

Bug#949484: navit FTBFS on ppc64el, rsvg crashes.

[Joseph Herlant]

Hi Peter,

Thank for your report.

On Tue, Jan 21, 2020 at 6:09 AM peter green  wrote:
> Unfortunately the new version failed to build on ppc64el,
> it seems rsvg is crashing.

I noticed this issue but it seems to me like it's really an issue with
librsvg2 more than an issue with Navit itself.

> Potential solutions include.
>
> 1. Fix the build system to only build arch all data during
>the arch all build (the result of the rsvg run in question
>seems to be packaged in an arch all package).
> 2. Find and fix the underlying rsvg issue.

I'll just switch the svg2png processor to another tool, that should do
the trick for now.
Feel free to send a MR if you have a better patch! ;)

Thanks,
Joseph

Bug#949214: Bug#948388: navit: fails to connect to gpsd

[Joseph Herlant]

Control: merge 948388 949214

Hi Mattia, thanks for the official FTBS report. It appears this issue
has already been reported in #948388 so I'm merging the 2 bugs. if you
don't mind.

Hi guys, thanks for the report, investigation and patching.

On Fri, Jan 17, 2020 at 5:18 PM Peter Green  wrote:
> I just took what has been discussed into this
> bugreport so-far and put it all together into a
> debdiff. If I get confirmation from users that the
> resulting package works and noone objects to me
> doing so I will likely NMU this later.

No need for an NMU. I'll coordinate the change with upstream to make
sure we're not missing anything with this patch and do an upload over
the weekend.

Thanks for your help!
Joseph

Bug#946810: python3-commonmark-py: update the source url in watch to match the currently supported repo

[Joseph Herlant]

Package: python3-commonmark-bkrs
Version: 0.5.4+ds-4
Severity: wishlist

Dear Maintainer,

The watch file of the package points to the old repository
(rolandshoemaker/CommonMark-py):
https://salsa.debian.org/python-team/modules/commonmark-
bkrs/blob/master/debian/watch

But that repository clearly states that using that repo as source is deprecated
and we should be using the supported one here instead:
https://github.com/readthedocs/commonmark.py

Do you think it would be doable to migrate that over as it seems it's the way
to a maintained upstream?

I'm not sure how much work would actually be involved in that.

Thanks for your help,
Joseph



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

Kernel: Linux 5.3.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-commonmark-bkrs depends on:
ii  python3  3.7.5-1

python3-commonmark-bkrs recommends no packages.

Versions of packages python3-commonmark-bkrs suggests:
pn  python-commonmark-bkrs-doc  

-- no debconf information

Bug#946805: ruby-hamlit: Please upgrade to latest upstream

[Joseph Herlant]

Package: ruby-hamlit
Version: 2.9.2-2
Severity: wishlist

Dear Maintainer,

Since the upgrade of ruby-tilt to 2.0.10 yesterday the tests for ruby-hamlit
fail.
See: https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-
hamlit/3668609/log.gz

It seems that this has been fixed in the latest upstream version.
To see more explanation about a potential fix of the problem, see
https://github.com/rtomayko/tilt/issues/347

But again, I can see upstream running their tests against tilt 2.0.10 without
any issue, so I guess it's fixed in the latest version.

Utkarsh created a MR to gitlab (which depends on ruby-hamlit) to make sure they
accept to support the latest version but given that the only tests failing were
already failing before I don't see any reason why that would be an issue. See:
https://gitlab.com/gitlab-org/gitlab/merge_requests/21793

Thanks for your time,
Joseph



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

Kernel: Linux 5.3.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-hamlit depends on:
ii  libc62.29-3
ii  libgmp10 2:6.1.2+dfsg-4
ii  libruby2.5   2.5.7-1
ii  ruby 1:2.5.2
pn  ruby-temple  
ii  ruby-thor0.19.4-1
ii  ruby-tilt2.0.9-1

ruby-hamlit recommends no packages.

ruby-hamlit suggests no packages.

Bug#946619: python3-pylint-django: Re-enable the tests after pylint 2.5 has been released.

[Joseph Herlant]

Package: python3-pylint-django
Version: 2.0.11-1
Severity: wishlist

As explained in #945426, pylint 2.4 has removed the unit tests from the package
installation and the test functional classes have only been re-introduced in
the package in pylint 2.5 so for now I'll disable the unit tests and re-enable
them when pylint 2.5 is back.
This report is a reminder to do it.



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

Kernel: Linux 5.3.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pylint-django depends on:
ii  pylint   2.2.2-4
ii  python3  3.7.5-1
ii  python3-pylint-plugin-utils  0.6-1

python3-pylint-django recommends no packages.

python3-pylint-django suggests no packages.

-- no debconf information

Bug#895462: Please keep asciidoc in Debian

[Joseph Herlant]

Hi Simon,

I'd be interested in your use case. Do you have some examples of what
you call "proper localization with support for multiple languages and
flexibility through additional config files"?
I also work with asciidoctor so I'd be happy to see with them if
upstream has that on their backlog.

To be honest, asciidoc hasn't been really active over the last few
years (since its creator left the project) and even the current
maintainers have advise several times to switch to asciidoctor (which
has become the official reference for the asciidoc language), so the
package does now support python3, yes, but I would still advise to
look at alternatives long term.

The reason I keep this one open for now is to make sure people realize
that it's not because the language name is asciidoc that they should
use the asciidoc binary.

Joseph

Bug#945426: pylint doesn't ship the test libraries anymore

[Joseph Herlant]

Hi,

FYI what I'm looking for is the test_functional-related classes
and those have been moved to pylint/testutils.py in the upcoming
version 2.5 so we can also wait until that new version is released and
leave the tests in the source package only tooif you want.

Thanks,
Joseph

Bug#945391: asciidocapi: fails with AttributeError: 'NoneType' object has no attribute 'loader'

[Joseph Herlant]

Control: forwarded -1 https://github.com/asciidoc/asciidoc-py3/pull/86

Hi Simon,

Thanks a lot for the report!
I was able to reproduce the bug you described and I can confirm that
your patch works as expected.
Thanks a lot for that! :)

I forwarded your patch to the upstream repo:
https://github.com/asciidoc/asciidoc-py3/pull/86
I'll give them a few days for comments and style changes if they have
any and will release the new version after that.

Thanks again,
Joseph

Bug#945426: pylint doesn't ship the test libraries anymore

[Joseph Herlant]

Package: pylint
Version: 2.4.4-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Thanks a lot for the prompt upgrade of pylint the other day.
Unfortunately since the upgrade, it seems we lost the testing libraries that
other packages like pylint-django rely on.

This has been introduced by this upstream PR:
https://github.com/PyCQA/pylint/pull/2958 and this specific commit:
https://github.com/PyCQA/pylint/commit/33b8185a455c1686d038258697bb93005f2441c2
This change has been released in 2.4.0.

As they are in the Debian source package, do you think it would be possible to
either have them in a separate package or
add them back to where they were before please?


In the version currently in testing we have:
$ pylint --version
pylint 2.2.2
astroid 2.1.0
Python 3.7.5 (default, Oct 27 2019, 15:43:29)
[GCC 9.2.1 20191022]
$ ls -l /usr/lib/python3/dist-packages/pylint/test
total 376K
drwxr-xr-x  2 root root 4.0K Nov 24 08:51 acceptance
- -rw-r--r--  1 root root 1.1K Oct 11  2018 conftest.py
drwxr-xr-x  2 root root 4.0K Nov 24 08:51 data
drwxr-xr-x  3 root root 4.0K Nov 24 08:51 extensions
drwxr-xr-x  2 root root  56K Nov 24 08:51 functional
drwxr-xr-x  3 root root 4.0K Nov 24 08:51 input
drwxr-xr-x  2 root root 4.0K Nov 24 08:51 messages
drwxr-xr-x 10 root root 4.0K Nov 24 08:51 regrtest_data
- -rw-r--r--  1 root root 4.7K Oct 11  2018 test_func.py
- -rw-r--r--  1 root root  13K Nov 27  2018 test_functional.py
- -rw-r--r--  1 root root 2.3K Oct 11  2018 test_import_graph.py
- -rw-r--r--  1 root root 4.1K Oct 11  2018 test_regr.py
- -rw-r--r--  1 root root  20K Oct 11  2018 test_self.py
- -rw-r--r--  1 root root  18K Oct 11  2018 unittest_checker_base.py
- -rw-r--r--  1 root root 3.8K Oct 11  2018 unittest_checker_classes.py
- -rw-r--r--  1 root root 1.8K Oct 11  2018 unittest_checker_exceptions.py
- -rw-r--r--  1 root root  18K Oct 11  2018 unittest_checker_format.py
- -rw-r--r--  1 root root 4.3K Oct 11  2018 unittest_checker_imports.py
- -rw-r--r--  1 root root 2.6K Nov 28  2018 unittest_checker_logging.py
- -rw-r--r--  1 root root 3.1K Oct 11  2018 unittest_checker_misc.py
- -rw-r--r--  1 root root  39K Oct 11  2018 unittest_checker_python3.py
- -rw-r--r--  1 root root 4.7K Oct 11  2018 unittest_checker_similar.py
- -rw-r--r--  1 root root  11K Oct 11  2018 unittest_checker_spelling.py
- -rw-r--r--  1 root root 3.7K Oct 11  2018 unittest_checker_stdlib.py
- -rw-r--r--  1 root root 2.5K Oct 11  2018 unittest_checker_strings.py
- -rw-r--r--  1 root root 4.6K Oct 11  2018 unittest_checkers_utils.py
- -rw-r--r--  1 root root 9.5K Oct 11  2018 unittest_checker_typecheck.py
- -rw-r--r--  1 root root 8.6K Oct 11  2018 unittest_checker_variables.py
- -rw-r--r--  1 root root 2.0K Oct 11  2018 unittest_config.py
- -rw-r--r--  1 root root  27K Oct 11  2018 unittest_lint.py
- -rw-r--r--  1 root root 6.2K Oct 11  2018 unittest_pyreverse_diadefs.py
- -rw-r--r--  1 root root 3.8K Oct 11  2018 unittest_pyreverse_inspector.py
- -rw-r--r--  1 root root 3.9K Oct 11  2018 unittest_pyreverse_writer.py
- -rw-r--r--  1 root root 1.7K Oct 11  2018 unittest_reporters_json.py
- -rw-r--r--  1 root root 2.5K Oct 11  2018 unittest_reporting.py
- -rw-r--r--  1 root root  14K Oct 11  2018 unittest_utils.py


$ pylint --version
pylint 2.4.4
astroid 2.3.3
Python 3.7.5 (default, Oct 27 2019, 15:43:29)
[GCC 9.2.1 20191022]
$ ls -l /usr/lib/python3/dist-packages/pylint/test
ls: cannot access '/usr/lib/python3/dist-packages/pylint/test': No such file or
directory

Thanks a ton! :)

Joseph
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE6CPaER4i14V+HYZYY/eACiPXslIFAl3au34ACgkQY/eACiPX
slLHrA//bastkKdNJPQe/bVV3edXyX5T+YwmUOZ0OynQQWk589rnIqQeptMkoY7/
IzR5vav3QfVae6yQMm6wjErB7sPaVFUAvXfi+HIygdPITWt9o78laWcHteOLE4J1
Ee0tRPxIESX+6YpZbm8Twrppdg1klU9q0kKF61xpRbC2Ujk5LDqRktpHphhPxcjb
SsIsK8WMVyf/+x/BX9RRGxVQfmQL9w310zsXlGaMIUpWH2bpy5v7KSpSCXSjLXwd
l5t0kbcvCMie0tVSrFAWOpiKjIAiZDJbOistPzJ9RF7X3TWwf4qPuhHMDBWNEV2Y
UzetkI4jBFyl5CPhH3c3D7np41AjaWt8+z/+Mc+MVFWUDTGI7AmW4z3HqH82N8z7
tiVYVwFUAbYB/usy8PJs9HMFqDbgAb5jX1hYZeRlcakK+d+fGmDv6qrmQfTwpU4X
UO0ek9qwjNKkKvlUXpHTl5zKxdjijI6U1L5d6CwXd/XUtH7nLAaCrkWgLODZm45g
JjdmyZS9pklTyZPyCf/taZbqcdew3BF65KuRbn/bYwt0AwtpyNEQ3bl6K6EEOisa
98bB6cyL/iorvuZS9+2Gpw8o9U5atFyD7frLsuewp2dBvNnV6L55DrHjShRKka+V
fI5a+MbXf/+3PUi/NhQLIuMwFQ93AGFY2Yc5n+bpFiXcHPFEklw=
=r7+y
-END PGP SIGNATURE-



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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 pylint depends on:
ii  python3 3.7.5-1
ii  python3-astroid 2.3.3-1
ii  

Bug#944987: pylint: please upgrade to >= 2.3.0

[Joseph Herlant]

Source: pylint
Version: 2.2.2-4
Severity: wishlist

Hi Sandro,

Would it be possible to upgrade pylint to latest please?
I'm currently in the need of pylint 2.3.0 minimum to be able to upgrade pylint-
django.
If you want me to take care of it, please let me know I can try.

Thanks,
Joseph



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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#943456: m2r: maintain in python group?

[Joseph Herlant]

Hi Jonas,

I noticed that your ITP mentioned that you plan to maintain m2r in the
Debian group.
Any chance you could put it in the Python module group instead?
https://salsa.debian.org/python-team/modules

Thanks,
Joseph

Bug#942751: RM: gnome-shell-pomodoro/unstable [s390x] -- ANAIS; dependency not building on s390x

[Joseph Herlant]

Package: ftp.debian.org
Severity: normal

Hi guys,

As gnome-shell isn't in s390x anymore and is required for the installation (but
not the build) of gnome-shell-pomodoro, Jeremy suggested in
https://salsa.debian.org/debian/gnome-shell-pomodoro/merge_requests/2 that I
release a new version that build-depend on gnome-shell (which I did yesterday)
and ask you guys if you could remove gnome-shell-pomodoro from unstable for the
s390x architecture.

Do you mind removing the package gnome-shell-pomodoro from unstable for the
s390x architecture please?

Thanks for your help,
Joseph

Bug#940718: xml-core: please remove versioned depends on sed

[Joseph Herlant]

Hi Andrej,

> xml-core depends on sed (>= 4.1.2-8). However, looking at sed, I don’t
> see the reason why this particular version, and it’s not even in
> oldoldstable anymore anyway. Please consider dropping the versioned
> requirement and replacing it with a plain one.

Just FYI this specific version was fixing #248910.
I agree this can be removed as this condition is supported by all the
debian versions we have,
However I need to do a bit of digging on whether we need to have sed
as a dependency at all. It looks like this dependency wouldn't be
needed anymore after #687109 but I'll need to do some testing to
confirm.

Thanks,
Joseph

Bug#940718: xml-core: please remove versioned depends on sed

[Joseph Herlant]

Control: owner -1 !

Hi Andrej,

Thanks for the report.
It indeed doesn't makes sense anymore and I don't have the entire
history of it so I'm not sure why it was setup this way.
I'll clean that up.

Thanks,
Joseph

Bug#936151: New asciidoc version uploaded with python3 support

[Joseph Herlant]

Control: tags -1 + pending

Hi,

Thanks for the report and sorry for the late reply.
I've just uploaded to the ftp queue a new git snapshot of the python3
implementation of asciidoc.
Hopefully everything works as expected with that unreleased implementation.

Thanks for your patience,
Joseph

Bug#936422: django-tables: Python2 removal in sid/bullseye

[Joseph Herlant]

Hi Matthias,

I was surprised to receive this mail as I thought that migration had
already been done but it turns out that the doc package was still
depending on python-doc instead of python3-doc.

I'll upload the new version shortly.

Thanks,
Joseph

Bug#935196: asciidoctor: Source highlighting does not work any more

[Joseph Herlant]

Control: forwarded -1 https://github.com/asciidoctor/asciidoctor/issues/3394
Control: owner -1 !

Hi Sebastien,

Thanks for your report.
I'm working on a patch with upstream.

Thanks,
Joseph

Bug#934998: asciidoctor: new upstream version

[Joseph Herlant]

Control: owner -1 !

Hi Brian,

Thanks for your report.
I was working on that upgrade a few wweeks ago but hit some roadblock
as you can see in
https://lists.debian.org/debian-ruby/2019/06/msg3.html

I'll try to see if I can package the new version today.

Joseph
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE6CPaER4i14V+HYZYY/eACiPXslIFAl1ZcdYACgkQY/eACiPX
slKFYxAAjFmQaivR9NzGm/L5NEtYt64z0qT12i+9flP6oEBLgZDM9+Fr60WT+pN8
sfMTa6yf3zGMYjZt2zOou4TgkF/GkAvB5NCVBMRWKVuLWxeezAJQX9OPsj0hTqK2
uG79uGir3+26zlqHe2MC3C6pYqPrvnf1dOvlRumJoMvuMPKv2n9bWx7ILoYdv9GD
wvCw/BmFCdtWK7gh+nq8WxlYyC/Gl5A7Bs5V6VwMT18IKaowNy4WRyDMKCG53/IO
Pnikq0z3Iv2FDqjh5x/GYApUpHWGGns+LO+/01f6dR00t5Rr5DOsV0trS0dRmLqg
tofSzyQooRpZ4gN9dSUgh9iHQTYwhO9e0pfTcSd6EJpbzcGvfN4J0aqNEgJN8AD7
QfD7nj7c4YHk6dFMA+d0xVn+Xus8/8ob2t7wsMmEjPW5Ez6uT9dkFaS5UxDKS3cx
fJjKaRXVw5VLHPVb2OCCmr/JblX0EVMEuQllhvpbWyLZu0xF99JXNOXOYXQyrtjB
0N6rvhGuBIOt+HboaYqdEYC9cfHEZRxuwmfZYMiOkLbONop4Znr0W93Pbh0NV1lc
65kTzEjIRAGM4rt7pGvG/GJHCRM1CshUSIcd3hDmTBYpnXORHRmMBL/7NL3R9USN
Jp6sV1bZ3cZDrtQ4v3hMJi6yOIPMNIuao49ofNGfsl9f+ts7sOw=
=2UeX
-END PGP SIGNATURE-

Bug#919479: gnome-shell-pomodoro: multimonitor setup: pomodoro break 'breaks' gnome shell, restart needed

[Joseph Herlant]

Package: gnome-shell-pomodoro
Followup-For: Bug #919479

Hi Wim,

Can you reproduce it in newer versions of the package?
What windows manager do you use when you have the problem?
Is it only happening with 3 screens?
I've been running that app for a long time on dual screen using i3 and haven't
faced the problem you're describing but I'm using testing.

Thanks for your help,
Joseph



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 gnome-shell-pomodoro depends on:
ii  gnome-shell 3.30.2-10
ii  gnome-shell-pomodoro-data   0.14.0-1
ii  libatk1.0-0 2.32.0-2
ii  libayatana-appindicator3-1  0.5.3-4
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libcanberra00.30-7
ii  libdbusmenu-glib4   18.10.20180917~bzr490+repack1-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgirepository-1.0-1   1.58.3-2
ii  libglib2.0-02.60.6-1
ii  libgom-1.0-00.3.3-5
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.10-1
ii  libpango-1.0-0  1.42.4-7
ii  libpangocairo-1.0-0 1.42.4-7
ii  libpeas-1.0-0   1.22.0-4

gnome-shell-pomodoro recommends no packages.

gnome-shell-pomodoro suggests no packages.

-- no debconf information

Bug#934530: ruby-sequel-pg - new version available

[Joseph Herlant]

Package: ruby-sequel-pg
Version: 1.6.16-1+b2
Severity: wishlist

Dear Maintainer,

I can see that ruby-sequel-pg has a new version available and has a RC bug
(#899307 which is not happening anymore, I checked).
Do you mind if I prepare the new version and upload it as a team upload?

Thanks for your help,
Joseph



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 ruby-sequel-pg depends on:
ii  libc62.28-10
ii  libgmp10 2:6.1.2+dfsg-4
ii  libpq5   11.4-1
ii  libruby2.5   2.5.5-4
ii  ruby 1:2.5.1
ii  ruby-pg  1.1.3-3+b1
ii  ruby-sequel  5.15.0-1

ruby-sequel-pg recommends no packages.

ruby-sequel-pg suggests no packages.

-- no debconf information

Bug#926711: gnome-shell-pomodoro: workaround for notification volume going to 100%

[Joseph Herlant]

Hi,

Sorry for the late reply.
I thought I already answered that report but it seems it's just that I
replied to another one that was saying the exact same thing,
I'm not sure there's a fix for it. Just a workaround (I know it's not
ideal but I don't have enough knowledge of Vala to propose a fix).
See: https://github.com/codito/gnome-pomodoro/issues/244

Joseph

Bug#934271: #934271: patch integrated!

[Joseph Herlant]

Control: tags ! + pending
Control: forwarded ! https://github.com/vinayak-mehta/tablib/pull/374

Hi Mathieu,

Thanks for the report and sorry for the late reply.
I've uploaded the latest version of python-tablib and included your patch.
I also forwarded your patch to upstream to hopefully get it merged for
next release: https://github.com/vinayak-mehta/tablib/pull/374

I just uploaded the new package in the ftp-master queue.

Thanks
Joseph

Bug#934020: O: libnxml -- C library for parsing, writing and creating xml 1.0/1.1 files or streams

[Joseph Herlant]

Package: wnpp
Severity: normal

I intend to orphan the libnxml package.

The package description is:
 libnxml is a C library for parsing, writing, and creating XML 1.0 and
 1.1 files or streams. It supports UTF-8, UTF-16be and UTF-16le, UCS-4
 (1234, 4321, 2143, 2312).

Bug#934019: O: cmph -- C Minimal Perfect Hashing Library development files

[Joseph Herlant]

Package: wnpp
Severity: normal

I intend to orphan the cmph package.

The package description is:
 Minimal perfect hash functions are widely used for memory efficient storage
 and fast retrieval of items from static sets, such as words in natural
 languages, reserved words in programming languages or interactive systems,
 universal resource locations (URLs) in Web search engines, or item sets in
 data mining techniques.

Bug#934018: O: libmrss -- C library for parsing, writing and creating RSS files or streams

[Joseph Herlant]

Package: wnpp
Severity: normal

 libmrss is a C library for parsing, writing and creating RSS
 (0.91, 0.92, 1.0, 2.0) files or streams.
 .
 This package contains the shared libraries.

It is not really maintained upstream anymore but should be relatively clean.

Bug#934017: O: gnome-shell-pomodoro -- GNOME Shell time-management app

[Joseph Herlant]

Package: wnpp
Severity: normal

I intend to orphan the gnome-shell-pomodoro package.

The package description is:
 This GNOME Shell app helps you to manage time according to the
 pomodoro technique.
 .
 Features:
  * puts a countdown timer in the GNOME Shell top panel;
  * nags you with reminders about taking a break;
  * uses full screen notifications that can be easily dismissed;
  * hides other notifications until the start of the break;
  * sets your IM (Empathy) status to "busy".
 .
 The pomodoro technique is a time and focus management method which improves
 productivity and quality of work. The name comes from a kitchen timer, which
 can be used to keep track of time. In short, you are supposed to focus on work
 for around 25 minutes and then have a well deserved break in which you should

Bug#934015: O: asciidoc -- Highly configurable text format for writing documentation

[Joseph Herlant]

Package: wnpp
Severity: normal

I intend to orphan the asciidoc package.

The package description is:
 AsciiDoc is a text document format for writing articles, books, manuals and
 UNIX man pages. AsciiDoc files can be translated to HTML (with or without
 stylesheets), DocBook (articles, books and refentry documents) and LinuxDoc
 using the asciidoc command. AsciiDoc can also be used to build and maintain
 websites.
 .
 You write an AsciiDoc document the same way you would write a
 normal text document, there are no markup tags or weird format notations.
 AsciiDoc files are designed to be viewed, edited and printed directly or
 translated to other presentation formats
 .
 This metapackage provides a fully functionnal asciidoc environment working
 with dblatex for historical purposes.
 AsciiDoc is a text document format for writing articles, books, manuals and
 UNIX man pages. AsciiDoc files can be translated to HTML (with or without
 stylesheets), DocBook (articles, books and refentry documents) and LinuxDoc
 using the asciidoc command. AsciiDoc can also be used to build and maintain
 websites.
 .
 You write an AsciiDoc document the same way you would write a
 normal text document, there are no markup tags or weird format notations.
 AsciiDoc files are designed to be viewed, edited and printed directly or
 translated to other presentation formats


Currently there's a work to move it to python3 but it's not been released yet:
https://github.com/asciidoc/asciidoc-py3

Bug#933921: src:python-tablib: Unsafe use of yaml.load()

[Joseph Herlant]

Hi,

Thanks Scott for the report.
Tomas: the repository in Openstack was archived long ago because it
was ported to https://salsa.debian.org/python-team/modules/python-tablib
The module is used by other packages than openstack (like
django-tables if I remember correctly), so could you please hold off
the removal request please?
If the repo in the openstack group bother you, you can drop it but
please don't drop tablib (at least not the python3 version).

Thanks,
Joseph

Bug#899307: ruby-sequel-pg: All SELECT ::Dataset methods fails with FrozenError

[Joseph Herlant]

Control: tags -1 + moreinfo

Hi Andrey,

I'm trying to reproduce your issue but I can't seem to be able to.

I get an error the 1st time I try to establish the connection but I
believe that's linked to something else.

Here's what I see (I use docker run --rm --name pg-docker -e
POSTGRES_PASSWORD=docker -d -p5432:5432 postgres so don't really care
that there's a password here, it's going to be gone in a min):

$ irb
irb(main):001:0> require 'pg'
=> true
irb(main):002:0> require 'sequel'
=> true
irb(main):003:0> DB =
Sequel.connect('postgres://postgres:docker@localhost:5432/postgres')
Traceback (most recent call last):
   12: from /usr/bin/irb:11:in `'
   11: from (irb):3
   10: from /usr/lib/ruby/vendor_ruby/sequel/core.rb:121:in `connect'
9: from
/usr/lib/ruby/vendor_ruby/sequel/database/connecting.rb:36:in
`connect'
8: from
/usr/lib/ruby/vendor_ruby/sequel/database/connecting.rb:17:in
`adapter_class'
7: from
/usr/lib/ruby/vendor_ruby/sequel/database/connecting.rb:88:in
`load_adapter'
6: from
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
5: from
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
4: from
/usr/lib/ruby/vendor_ruby/sequel/adapters/postgres.rb:803:in `'
3: from
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
2: from
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`require'
1: from
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
`const_get'
NameError (uninitialized constant PGError)
Did you mean?  TypeError
irb(main):004:0> DB =
Sequel.connect('postgres://postgres:docker@localhost:5432/postgres')
=> #
irb(main):005:0> DB.run("create table events (a text, b text)")
=> nil
irb(main):006:0> DB[:events].insert('foo', 'bar')
=> nil
irb(main):007:0> DB[:events].insert('foo1', '1bar')
=> nil
irb(main):008:0> DB[:events].insert('foo2', '2bar')
=> nil
irb(main):009:0> DB[:events].insert('foo3', '3bar')
=> nil
irb(main):010:0> DB[:events].insert('foo4', '4bar')
=> nil
irb(main):011:0> DB[:events].insert('foo5', '5bar')
=> nil
irb(main):012:0> DB[:events].insert('foo6', '6bar')
=> nil
irb(main):013:0> DB[:events].first
=> {:a=>"foo", :b=>"bar"}
irb(main):014:0> DB[:events].delete
=> 7
irb(main):015:0> DB.run("drop table events")
=> nil
irb(main):016:0>

So I wonder if that's really related to ruby-sequel-pg.
The other packages I got are:
$ dpkg -l | grep 'ruby-sequel\|ruby-pg\|ruby  '
ii  ruby1:2.5.1
  amd64Interpreter of object-oriented scripting
language Ruby (default version)
ii  ruby-pg 1.1.3-3
  amd64PostgreSQL interface for Ruby
ii  ruby-sequel 5.15.0-1
  all  Simple, flexible, and powerful SQL database
access toolkit for Ruby
ii  ruby-sequel-pg  1.6.16-1+b2
  amd64Faster SELECTs when using Sequel with pg


Can you try to reproduce it with your current version of packages and
let us know if you still see the issue please?

Thanks for your help,
Joseph
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE6CPaER4i14V+HYZYY/eACiPXslIFAl0Bf88ACgkQY/eACiPX
slJHLw//YLPbLaDuxa+BkwmJrX5HULj1D1EKBkcuFZLD0sECKbMMDxgggNz90Fxu
/Ns3Rrv06Y+aedS56MPDlwaLdlW29w2ea81ZDly8ycA6v7mLKvmDfog5K5XGAGmD
X4PN+cPsItI5KFF8yWjyhcNoY+AJjVZQSAi0euzNtQYRA3dtfkgMWYdxMBj8l2ZT
ISmv8ETgZTpv0phhOlSSrXxgWLa1KuN3Bttt0qUdc+/6IQ9Zxi6QfuDTzdec0yZU
k2fhGaOEVcva5twM7T86r+PE5ucxtTWs3HGo/anCdVU4ZPM3jxUeJILLDUIyQ62M
BJqJgNnJHGVv8YYHfh9aFB0U2u4eqVSr54hiIeixCsDs/n63QuoxSu8mpSu3KfwB
cQvqZm7hb7LSKT8Tqvhndcnsa3Q6ScceX5DZebS620iElmxOVH+5vL+ONcbCWf7C
OWN6bsO9XAOvUfsiDU+i4Fdpi3PNPpH3nPHvHPigzA8ZRW7892vhjB/2qFt9k9T5
iNnzeJM/4uRfPg8qkeqjR8Tw7opBqTiFOpW6wnPRY6/7AuGAbAr0JufY9MTf9O5T
e4yysbJmNHWgRn4pc+Ht0Mv6p1a+UKKg4xxGxs6uaCmermRrM4dPb4aFDElahsUA
+7D9ITtpV8MhMswKbDeoEsCX7GJSWR+AAl5lyFOKHJcaa8eaqJk=
=i0V2
-END PGP SIGNATURE-

Bug#660687: Update on ITA: xml-core

[Joseph Herlant]

Hi guys,

I haven't had much time to work on this over the last few weeks.
Other priorities have showed up.
I'll get back to this when I get more time. In the meantime if someone else 
wants to get on, take care of the bug
reports and adopt the package, go ahead. If not, I'll finish that later.

Thanks,
Joseph


signature.asc
Description: PGP signature

Bug#918340: pylint-django build depends on python3-factory-boy that is currently not in buster

[Joseph Herlant]

FYI, the new version of factory-boy is on the ftp-master queue. This
will solve itself in the next few days.
I'll close it once the package reaches testing.

Cheers,
Joseph

Bug#918340: pylint-django build depends on python3-factory-boy that is currently not in buster

[Joseph Herlant]

Hi Adrian,

Thanks for the report.
I was hoping to get a quick answer from
https://github.com/FactoryBoy/factory_boy/issues/552 to push the new
version of factory-boy without patching but I'll probably try to
update the package and add the patch for python 3.7 that has been
already merged so that the FTBS is fixed.
I'll probably do that tomorrow if Brian is ok with it.

Thanks,
Joseph

Bug#910318: factory-boy: do you mind if I upload the new version and fix the FTBS?

[Joseph Herlant]

Hi Brian,

One of my packages needs factory-boy to be able to run properly (see #918340).

Do you mind if I upload the latest version of factory-boy and add the
subset of the relevant patch that fixes the compatibility with python
3.7? (the part about factory/utils.py in
https://github.com/FactoryBoy/factory_boy/commit/97f48597d241aca598783f7bcaed34bf7b133343)

I can work on it asap if you don't mind me taking care of it.

Thanks for your help,
Joseph

Bug#917717: pylint-django: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Joseph Herlant]

Note that I'm having trouble with the latest release right now (see
https://github.com/PyCQA/pylint-django/issues/215) so I won't upload
it today.
But I should be able to get that fixed shortly.

Bug#917717: pylint-django: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Joseph Herlant]

Control: tags -1 + fixed-upstream

Reading through the changes of 2.0.1 to 2.0.5 of pylint-django, it
seems that this change has already been dealt with in the latest
version.
See: 
https://github.com/PyCQA/pylint-django/commit/c0408d7b844f46cf675986576ea2acaf4fd234cc#diff-caeb1acca0adc7ada7d03b9e07452774
So please don't get mad if I drop your patch. ;)

Thanks
Joseph

Bug#917717: pylint-django: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Joseph Herlant]

Control: tags -1 - fixed
Control: tags -1 + patch
Hi guys,

Thanks Lucas for the report. Sorry for the late reply, I was out of
the country with very limited internet access.

Thanks Emmanuel for the quick patch.
Notes for next time:
 * Please use meaningful commit messages, especially when committing
to the master branch of a package you don't maintain. Using commit
messages like "fix issue 917717" makes the commit history harder to
read and the use of tools like gbp dch impossible as well as rendering
the gitlab hooks in place for tagging the bugs as pending unusable.
(If you're not sure about your patches, please just create a MR and
the maintainer can help getting the patch to a better standard)
 * Please conform to the DEP-3 headers when you are writing a quilt
patch header. See https://dep-team.pages.debian.net/deps/dep3/
 * If you have a patch that you thing is good enough for Debian, it's
generally a good practice to propose it upstream as upstream is
generally aware of the potential negative impacts and this would avoid
having to maintain diverging patch hell, especially on packages you
don't maintain.
 * Please don't tag bugs as "fixed" as long as there's no NMU uploaded
(as long as the package is not in the archive). In your case the tag
"patch" seems more appropriate.

There is an upstream upgrade I need to do so I'll clean the previous
points and do the upload today or tomorrow.

Thanks,
Joseph

Bug#907105: Bug#909105: consider switching asciidoctor to Architecture: all

[Joseph Herlant]

Hi Jeremy,

On Thu, Nov 22, 2018 at 6:11 AM Jeremy Bicha  wrote:
> Could you go ahead and do this upload now?

Sorry but I've been waiting for 2 months for the debian-keyring to be
uploaded to be able to upload my packages.
As long as it's not been released with my key I believe I can't upload
my packages.

Good catch on the new upstream release, I'll package it and see if
someone in the ruby team is available to upload the package.

Thanks,
Joseph

Bug#911650: [developers-reference] usage of dh_strip conflicts with debhelper documentation

[Joseph Herlant]

Hi Tobias! :)

On Mon, Oct 22, 2018 at 10:43 PM Tobias Frost  wrote:
> I think that would be great; my (related) merge request
> https://salsa.debian.org/debian/developers-reference/merge_requests/7
> misses the information what to do when you mirgrate from manual to
> automatic debug packages.
> If you could extend this MR, that would be great ;-) TIA!

Sorry I didn't see the MR and related bug report before filing this
one and got sidetracked after.
Sure, I'll extend your MR tomorrow.

Thanks! :)
Joseph

Bug#911650: [developers-reference] usage of dh_strip conflicts with debhelper documentation

[Joseph Herlant]

Package: developers-reference
Version: 3.4.21
Severity: normal

Hi,

Based on the man page of dh_strip[1], "the `--dbg-package` option is a
now special purpose option that you normally do not need" which
contradicts with the paragraph 6.7.9. )Best practices for debug
packages) of the developers reference.

If I understand correctly we should say smoething like the wiki [3] says:
If you use debhelper/9.20151219 or newer in Debian, it will generate
debug symbol packages (as -dbgsym) for you with no additional
changes to your source package.
If you want to transition from a former -dbg package to a -dbgsym
package you might want to look into the dh_strip's switch
--dbgsym-migration=pkgname-dbg (<< currentversion~)' switch.

Am I correct assuming that it's the right thing to recommend?

If yes, I'll go ahead and do a merge request for that.

Thanks
Joseph

1. https://manpages.debian.org/unstable/debhelper/dh_strip.1.en.html
2. https://www.debian.org/doc/manuals/developers-reference/ch06.html
3. https://wiki.debian.org/DebugPackage

Bug#910841: xml-core: more elts

[Joseph Herlant]

Another element to keep in mind when working on that one is what is
explained in https://lists.debian.org/debian-qa/2015/08/msg00015.html

Bug#910841: xml-core: review how the catalogs updates are handled

[Joseph Herlant]

Package: xml-core
Version: 0.18
Severity: wishlist

This is a follow-up on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660687#15 as it
makes more sense in its own bug report rather than on the ITA bug
report.

The following content was from Daniel Leidert, previous maintainer of
the package:

It is more or less a similar bug to #477751. Every package update
re-installs all entries to /etc/xml/catalog and /etc/xml/$package.xml.
But this is a policy violation. Changes done to the above files are not
preserved. Further we create and manipulate the system catalog by a
self-written tool. IMO the rewrite must finish in

- shipping the /etc/xml/$package.xml file instead of creating it (so
dh_installxmlcatalogs will simply put a file into etc/xml/)

- and registering it with the system catalog by the nextCatalog entry
instead of putting delegate* entries in the system catalog directly
(this should be done in a way, that is compatible with using the
xmlcatalog tool from libxml)

- if a user decides he wants to unregister a catalog, he can simply
remove the relevant nextCatalog [1] entry in /etc/xml/catalog - and this
change must be preserved during package updates.

[1] 
https://www.oasis-open.org/committees/entity/spec-2001-08-06.html#s.nextcatalog

Bug#910838: xml-core: add unit tests

[Joseph Herlant]

Package: xml-core
Version: 0.18
Severity: whishlist

It would be nice to have some unit tests on this package.
It's pretty widely used and unit tests would prevent from some
unexpected bugs after a given change.

Bug#660687: ITA: xml-core -- XML infrastructure and XML catalog file support

[Joseph Herlant]

Control: retitle 660687 ITA: xml-core -- XML infrastructure and XML
catalog file support

Hi,

Based on the lack of answer I'm guessing you didn't have the time to
look at it so I'm going to go ahead and work on the package in the
next few weeks.
Let me know if you still want to adopt it, I can help or let you do
it, whatever you think is best.
In the meantime I'll file some bugs and prepare a new version.

Thanks
Joseph

Bug#910702: gnome-shell-pomdoro: Please Build-Depends on gjs

[Joseph Herlant]

On Thu, Oct 11, 2018 at 3:02 PM Jeremy Bicha  wrote:
> Would it be ok if I uploaded to Debian from your git repo if we do need it?

I have absolutely no problems with that. :)
I'm done with my changes for now. Feel free to cut the release
whenever you need it.

Joseph

Bug#910057: Proposed patch

[Joseph Herlant]

Control: tags -1 + patch

Proposed patch:
https://salsa.debian.org/aerostitch/userdir-ldap/merge_requests/1

I contacted the DSA team via #debian-admin, waiting for feedback.
Not sure if there's any package this ticket should be reassigned to or
if it should be just closed manually when the MR is merged.

We'll see.

Joseph

Bug#909105: consider switching asciidoctor to Architecture: all

[Joseph Herlant]

> I reported that bug.

Indeed, that's why I was confused! :D

> After reading my report three times, I see how you
> might have interpreted it that way. I wrote that there is a problem,
> "because asciidoctor is Architecture: all and implicitly Multi-Arch:
> no". The problem results from the combination of those fields, not from
> either single field. The satisfiability problem is fully solved by the
> Multi-Arch: foreign field alone regardless of the Architecture value.

After reviewing the change, I don't exactly remember why I did the
change only on the ruby-asciidoctor package but I'm guessing I simply
forgot to update asciidoctor arch part when doing the split.

I'll have a look at it asap.

Joseph

Bug#909105: consider switching asciidoctor to Architecture: all

[Joseph Herlant]

Hi Helmut,

Thanks for your report.

I think you can find the explanations to those questions in #893467
which is the origin of th split of the asciidoc package.
Let me know if there are still more questions about it after reading #893467.

Regarding the dependency version, that's a good point that I'll push a
fix for that in the repo which will ship in next release.

Thanks
Joseph

Bug#906504: pulseaudio: FTBFS in buster/sid (failing tests) => patch available

[Joseph Herlant]

Hi Sven and Felipe,

Thanks for the report on those architectures and the intermediate upload.
I think I found a better way to handle that test that I proposed in
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/7
The idea is rather than allowing a random number of rounding issues
that grows over time, potentially hiding other errors, we allow the
values returned to have a difference of + or - 1, which allows the
rounding issues without allowing bigger deviation.
Tested on amd64, it works as expected, so I updated the patch proposed
earlier via the salsa MR:
https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/2

Let me know if you'd like to change something in it.

Thanks
Joseph

Bug#908291: developers-reference, section 5.11.4: Add a note on versioning scheme when reverting an NMU

[Joseph Herlant]

Hi Ian,

On Sun, Sep 9, 2018 at 7:39 AM Ian Jackson
 wrote:
> Maybe adding a link or xref to policy 5.6.12.1 would be helpful.

Good point, thanks! I updated the MR to include the reference to the policy.

Joseph

Bug#908291: developers-reference, section 5.11.4: Add a note on versioning scheme when reverting an NMU

[Joseph Herlant]

Source: developers-reference
Severity: wishlist
Tags: patch

Dear Maintainer,

The Developer's reference explains a lot about NMUs and corresponding version
scheme but it does not explain the naming convention to use when you have to
revert an NMU that brings a new upstream version.
Lintian has a check about it (https://lintian.debian.org/tags/epoch-changed-
but-upstream-version-did-not-go-backwards.html), so it seems the format is
wildly accepted.
So maybe a not about it here would be a good thing.

I took the liberty to provide a patch via a MR:
https://salsa.debian.org/debian/developers-reference/merge_requests/4

Let me know if adding that paragraph would be ok and if the wording is correct.
I'm not sure on how to handle the po files. Let me know if I can help on that
too.

Thanks
Joseph

Bug#907936: nuntius-linux FTBFS with vala 0.42.0-1

[Joseph Herlant]

Hi Barak,

On Thu, Sep 6, 2018 at 2:35 AM Barak A. Pearlmutter
 wrote:
>
> Thanks. But even with that patch I'm still getting a build error with
> valac 0.42.0-1
>
> src/notification.vala:37.17-37.29: error: Equality operation: `null'
> and `bool' are incompatible
> if (_read != null) {
> ^

I'm sorry I went too quickly yesterday and didn't test enough
apparently and something passed when it shouldn't have.
I made another one today:
https://github.com/holylobster/nuntius-linux/pull/81 This one should
work.
Could you test with it please? I'm having troubles with my computer
today and having trouble to compile quilt patches in the git repo (it
keeps telling me the patch has fuzz, I can't understand why as I
created it with quilt).

Thanks for your help,
Joseph

Bug#906504: pulseaudio: FTBFS in buster/sid (failing tests) => patch available

[Joseph Herlant]

Control: forwarded -1
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/4
Control: tags -1 + patch
Control: tags -1 + upstream

Hi,

The issue is due to a optiomizations impacting precision with GCC8.
There is an existing bug report on this issue upstream:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/559
and an existing merge request there too:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/4

I've created the MR on salsa to add the upstream patch with quilt in
the current version:
https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/1

Let me know if I can do anything more to help on this specific issue.

Thanks
Joseph

Bug#907936: nuntius-linux FTBFS with vala 0.42.0-1

[Joseph Herlant]

Control: forwarded -1 https://github.com/holylobster/nuntius-linux/pull/79
Control: tags -1 + upstream

Hi,

FYI I pushed a patch upstream to fix that specific issue. See
https://github.com/holylobster/nuntius-linux/pull/79

Best,
Joseph

Bug#907897: gnome-shell-pomodoro: FTBFS

[Joseph Herlant]

Control tag -1 + pending

Hi,

The issue is related to the Vala upgrade to 0.42.0 which was released
on 09/02 in Debian and brings this commit in:
https://github.com/GNOME/vala/commit/0d396f7daaf34596b159380b8ee2a57799ac9336
which forces the absence of "default" to custom get accessors.

Anyway, after creating the issue I ended up pushing a PR upstream
(https://github.com/codito/gnome-pomodoro/pull/370) and creating a
quilt patch for
https://salsa.debian.org/debian/gnome-shell-pomodoro/commit/fa3c929bc201716fb5fa1f4805c5c8da69f8f689
Tested locally it works fine.

This will be included in the coming release.

Thanks
Joseph

Bug#907897: gnome-shell-pomodoro: FTBFS

[Joseph Herlant]

Control: forwarded -1 https://github.com/codito/gnome-pomodoro/issues/369
Control: owner -1 !

Hi Paul,

Thanks for the report. Perfect timing, I was preparing a release for
another FTBS! :)

Working on a fix right now. It should be available soon.

Thanks
Joseph

Bug#905107: gnome-shell-pomodoro: patch in the repo

[Joseph Herlant]

Control: tags -1 + pending

Patched version available in the repo. I'm in the process of becoming
a DD. If my usual sponsor don't have the time to review and upload it
before I finish the process, I'll take care of it (hopefully in about
2 weeks).

Thanks,
Joseph

Bug#905107: gnome-shell-pomodoro: global.screen is not available in GNOME Shell 3.29

[Joseph Herlant]

Hi Simon,

Sorry for the late, I just saw this bug.
Thanks for forwarding it upstream. I'll work on a PR for that this weekend.

Joseph

Bug#869194: awscli failing to upload empty files on => due to python-s3transfer

[Joseph Herlant]

Control: reassign -1 python-s3transfer
Control: forwarded -1 https://github.com/boto/s3transfer/pull/102

Reassigning this bug to python-s3transfer as it is the one that will
be patch to support the missing argument.

Upstream issues:
https://github.com/aws/aws-cli/issues/2403#issuecomment-389325158

Bug report in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/python-s3transfer/+bug/1696800

There are actually 2 upstream patches, the 2nd one superseeding the
1st: https://github.com/boto/s3transfer/pull/88 and
https://github.com/boto/s3transfer/pull/102

Joseph

Bug#898592: lintian: add tag debian-pyversions-is-obsolete

[Joseph Herlant]

Hi Chris,

On Mon, May 14, 2018 at 2:31 PM, Chris Lamb  wrote:
> (FYI I think your MR missed the debian/changelog entry as well as not
> shipping the two "pyversions" test fixtures, presumably because they
> were files "new" to Git?)

Oops, I indeed forgot the git add on the 2 test files and forgot to
update the changelog, sorry :\
Thanks a lot for taking care of that! :)

> Anyway, I've applied it in Git, pending upload:

Awesome, thanks a lot! :)

Joseph

Bug#898592: lintian: add debian-pyversions-is-obsolete => patch

[Joseph Herlant]

Control: tags -1 + patch

Patch proposed: https://salsa.debian.org/lintian/lintian/merge_requests/3

Thanks
Joseph

Bug#898592: lintian: add tag debian-pyversions-is-obsolete

[Joseph Herlant]

Package: lintian
Version: 2.5.86
Severity: wishlist

Dear Maintainer,

Since the transition to dh_python2 [1], it is recommended by the python policy
[2] to use X-Python-Version and X-Python3-Version tag in debian/control (if
necessary) instead of the debian/pyversions file.

I think it would be a good thing to start showing an info-level message like we
did for pycompat to remind people to move to clean this file from the repo.

Joseph

[1] https://wiki.debian.org/Python/TransitionToDHPython2
[2] 
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions

Bug#895166: ben: move out of asciidoc

[Joseph Herlant]

On Sun, May 13, 2018 at 4:27 AM, Mehdi Dogguy  wrote:
> I've done the necessary changes to use asciidoctor instead of asciidoc and
> pushed my changes to Ben's Git repository. This bug will be closed with
> the next upload.

Awesome, thanks a lot Mehdi! :)

Bug#896396: python*-django-tables2: django_tables2 fails to import => usage problem???

[Joseph Herlant]

I just saw that that there was a discussin on #896429 (I was looking
at #896396).

> I wonder whether we can draw anything useful from these bugs before
> closing them.
>
> For one thing, you cannot use autopkgtest-pkg-python on these modules as is.
> So yeah, for django this may make sense, but this behaviour is still 
> unfortunate from a qa pov.
>
> I'd like to hear your opinion on this matter.

Well the one thing we could draw for that is that the django-related
packages need to have their own test suite like I'm doing for
django-tables (see
https://salsa.debian.org/python-team/modules/django-tables/tree/debian/master/debian/tests).

Joseph

Bug#896396: python*-django-tables2: django_tables2 fails to import => usage problem???

[Joseph Herlant]

Control: severity -1 minor
Control: tag -1 + moreinfo
Hi

The error message you posted seems pretty explicit: it seems you're
missing some configuration apparently:

django.core.exceptions.ImproperlyConfigured: Requested setting
DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must
either define the environment variable DJANGO_SETTINGS_MODULE or call
settings.configure() before accessing settings.


If you want to understand how to use django-tables2, I encourage you to read:
https://github.com/jieter/django-tables2/blob/master/README.rst
and the tutorial:
https://django-tables2.readthedocs.io/en/latest/pages/tutorial.html
The mentioned tutorial is used in our autopkgtests too for the
upcoming version:
https://salsa.debian.org/python-team/modules/django-tables/blob/debian/master/debian/tests/test-run-py3

You must understand that this is is a django module, it's not
something to use outside of a properly configured django application.

Please let me know if you need more information.
If not, please close this bug.

Thanks
Joseph

Bug#865855: New version of tablib ready for review/upload

[Joseph Herlant]

Hi guys,

I updated the package to use standard branches, pybuild, autopkgtest,
make it run with python3 and get the latest version in.
I pushed it to the following repository:
https://salsa.debian.org/python-team/modules/python-tablib
Let me know if it's acceptable.

If so https://salsa.debian.org/openstack-team/python/python-tablib can
be dropped.

Let me know what you think.

Thanks for your help,
Joseph

Bug#896263: django-haystack: 2 RC bugs => 1 MR

[Joseph Herlant]

Dear maintainer,

I believe those 2 bugs would be fixed by
https://salsa.debian.org/python-team/modules/django-haystack/merge_requests/1
Could you have a look please?

I see in  https://github.com/django-haystack/django-haystack/pull/1603
that other people outside of Debian seem to have the problem too so
the fix might change later on.

#896263 and #896296 generate several dependent packages to be on
autoremoval from testing soon, so it would be great if we could have
this one fixed.

Thanks for your help,
Joseph

Bug#895186: asciidoctor: url-related issues are fixed upstream

[Joseph Herlant]

Control: tag -1 + fixed-upstream

Hi,

The issue has been fixed upstream and will be released as part of
1.5.7 whose timeline is being discussed in
https://github.com/asciidoctor/asciidoctor/issues/2663

Thanks,
Joseph

Bug#895187: asciidoctor: url-related issues are fixed upstream

[Joseph Herlant]

Control: tag -1 + fixed-upstream

Hi,

The issue has been fixed upstream and will be released as part of
1.5.7 whose timeline is being discussed in
https://github.com/asciidoctor/asciidoctor/issues/2663

Thanks,
Joseph

Bug#895613: asciidoctor FTBFS: test failures

[Joseph Herlant]

Thanks a lot for the quick answer! :)

> I can reproduce in a chroot with "dpkg-buildpackage -B"
> (there's likely some way to do the same in sbuild).

I'm now able to reproduce it with the following flags: `--arch-any
--no-arch-all`
I'll try to fix it this morning.

Thanks for the help!
Joseph

Bug#895613: asciidoctor FTBFS: test failures

[Joseph Herlant]

Hi Adrien,

Thanks for reporting. I was looking into it already.
My only problem is that I can't reproduce it when using sbuild in my
gbp buildpackage locally. I tried with different parameters but can't
understand why.
The missing files should have been installed by dh_install as they are
defined in ruby-asciidoc.install.
The only diff I see is that it runs dh binary-arch instead of dh binary.
Do you have the documentation of all the options you use on the buildd
environments please? I can't seem to find it.

Thanks for your help,
Joseph

Bug#895501: btrfs-progs: move out of asciidoc

[Joseph Herlant]

Package: btrfs-progs
Version: 4.15.1-1
Control: block 895462 by -1

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

btrfs-progs already supports asciidoctor to build its documentation
natively starting in 4.16. See:
https://github.com/kdave/btrfs-progs/blob/master/configure.ac#L107
and
https://github.com/kdave/btrfs-progs/blob/master/Documentation/Makefile.in#L56

All you have to do is change asciidoc to asciidoctor in debian/control
and you can remove the dependency on xmlto that is not needed anymore
also.

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks for your help,
Joseph

Bug#895485: booth: move out of asciidoc

[Joseph Herlant]

Package: booth
Version: 1.0-6
Severity: wishlist
Control: block 895462 by -1
Control: forwarded -1 https://github.com/ClusterLabs/booth/pull/67

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

I pushed a PR to upstream (see forwarded field), so when it's in and
released you can migrate more easily.
Note that I'm not sure you'll need docbook-* and xsltproc as
dependencies anymore once you're done.

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks

Bug#895462: asciidoc: deprecate in Debian

[Joseph Herlant]

Package: asciidoc
Version: 8.6.10-2
​Control: b​
lock -1 by 884213 893467 895186 895187 894192 894194 894188 894697 894700
894710 895165 895166 895167 895168

As announced by upstream in their last release[1], this is probably the
last release of asciidoc and encourage people to move to alternate tools
such as asciidoctor.

Asciidoc currently supports python2 only and the port to python3 [2] don't
seem to receive enough effort to go through [3], [4].

As we are pushing EOL of python2 in Debian, we need to properly manage the
EOL of asciidoc.

Concerning the move to asciidoctor, the following bugs need to be solved
before being able to really push forward: #884213, #893467, #895186, #895187

Command I used to get the list of packages that depends on asciidoc:
grep-dctrl -FBuild-Depends,Build-Depends-Indep,Recommends,Suggests -e
asciidoc[^t] -sPackage /var/lib/apt/lists/*Sources | cut -f2 -d ' '

I'll open debian bugs as I go and sometimes push upstream fixes. Here's
what I got so far:

​​
altos --> #894192
anet  --> #894194
ansible --> fixed upstream, debian: #894188
apgdiff --> used in the debain side only. #894697
autorevision --> #894700
awesome --> fixed upstream, debian: #894710
awesome-extra --> #895165
ben --> #895166
bgpdump --> #895167
boot-info-script --> #895168
booth
btrbk
btrfs-progs
butteraugli
cclive
ccontrol
cconv
cgit
clfswm
cluster-glue
codequery
compton
crmsh
cross-toolchain-base
cross-toolchain-base-ports
ctop
cvs-fast-export
cxxtest
cyclograph
czmq
dahdi-linux
dahdi-tools
dbusada
debian-security-support
debmake-doc
deutex
disorderfs
dpmb
dput-ng
dracut
drbd-doc
elasticsearch-curator
ent
erlang-ranch
evemu
evtest
fai
flactag
flashproxy
fldigi
frame
freedoom
fwknop-gui
genometools
git
git-cola
git-phab
git-reintegrate
git-remote-bzr
gitinspector
gitmagic
graphite2
grml-debootstrap
grml2usb
guetzli
guilt
gyp
herbstluftwm
httpfs2
i3-wm
i3status
jack-tools
jid
k3d
kakoune
kanboard-cli
katarakt
kicad
libalog
libam7xxx
libaqbanking
libchipcard
libcoap
libgwenhywfar
libmodbus
libpam-abl
libquvi
libquvi-scripts
libvmime
libxi
linux
lizardfs
lsyncd
madwimax
megatools
mlton
mp3fs
mpris-remote
mylvmbackup
nanomsg
newsbeuter
newsboat
ninja-build
nss-wrapper
ntpsec
nut
obfsproxy
ocl-icd
offlineimap
open-adventure
open-infrastructure-apache-icons
open-infrastructure-container-tools
open-infrastructure-package-tracker
open-infrastructure-storage-tools
pacemaker
pajeng
passenger
pavucontrol
pavumeter
pcscada
pegasus-wms
pepper
phodav
piuparts
poedit
postgresql-plproxy
psensor
pylama
python-ethtool
qutebrowser
quvi
rear
resolv-wrapper
rurple-ng
sen
shadowsocks-libev
shellex
shove
shunit2
simple-obfs
socket-wrapper
spring
springlobby
ssh-audit
stgit
tesseract
tig
tinyproxy
tor
trace-cmd
tweeper
udiskie
ufo-core
vmfs-tools
voltron
w1retap
warzone2100
wireshark
xnbd
yash
zeal
zynaddsubfx --> fixed upstream and fixed in the debian repo: #892969


[1] https://github.com/asciidoc/asciidoc/releases/tag/8.6.10
[2] https://github.com/asciidoc/asciidoc3/
[3] https://github.com/asciidoc/asciidoc3/pull/1
[4] https://github.com/asciidoc/asciidoc/issues/83

Bug#895188: asciidoctor: E-mail addresses are rendered twice [manpage backend]

[Joseph Herlant]

Hi,

I think this is due to the way the links are rendered in general.

To achieve your goal you would need to use the following:
mailto:debian.a...@manchmal.in-ulm.de[Christoph Biedl]

instead of:
Christoph Biedl 

See: https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#links

Is that acceptable?

Thanks
Joseph

Bug#895167: bgpdump: move out of asciidoc

[Joseph Herlant]

Hi  Christoph,


> Switching to asciidoctor was the obvious thing to do although it's not a
> simple drop-in replacment for a2x. Probably "asciidoctor --attribute
> reproducible --backend=manpage" does the trick.

Yes, that's the command to generate manpages in asciidoctor.

> But I'm stuck with several regressions, see above. Also, given the fact
> #884213 hasn't been addressed in months raises concerns whether using
> asciidoctor was a wise decision.

Fair point, thanks for pointing that out. I'll try to help the current
asciidoctor maintainers fix those.

I'll let you know when that's done.

Thanks
Joseph

Bug#895168: boot-info-script: remove unused dependency on asciidoc

[Joseph Herlant]

Package: boot-info-script
Version: 1.5.0-2
Severity: wishlist

Dear Maintainer,

It seems that asciidoc has been forgotten to be removed in
https://salsa.debian.org/debian/boot-info-script/commit/c079e0276ef46516399f211613b1240522a742b8

Patch available here:
https://salsa.debian.org/debian/boot-info-script/merge_requests/1

Note: if you choose to re-add a man page later, please do not use
asciidoc as it is deprecated and only supports python 2. You can use
asciidoctor instead for example.

Thanks
Joseph

Bug#895167: bgpdump: move out of asciidoc

[Joseph Herlant]

Package: bgpdump
Version: 1.5.0-2
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks
Joseph

Bug#895166: ben: move out of asciidoc

[Joseph Herlant]

Package: ben
Version: 0.7.7
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks

Bug#895165: awesome-extra: move out of asciidoc

[Joseph Herlant]

Package: awesome-extra
Version: 2017110501
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks
Joseph

Bug#894710: awesome: move out of asciidoc

[Joseph Herlant]

Hi Reiner,


> What is your planned timeline for getting rid of asciidoc?
> Is it sufficient to wait for the next awesome release, or do you want to
> have it already applied to the currently released version?

Asciidoc will be removed on next Debian major release when python2
will be removed so if upstream releases before that, then it's
perfect.

Thanks
Joseph

Bug#894710: awesome: move out of asciidoc

[Joseph Herlant]

Package: awesome
Version: 4.2-5
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?

Note: I already pushed an upstream PR
https://github.com/awesomeWM/awesome/pull/2234 in case it can help for
follow-up.

Thanks for your help,
Joseph

Bug#894700: autorevision: move out of asciidoc

[Joseph Herlant]

Package: autorevision
Version: 1.21-1
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?

Thanks for your help,
Joseph

Bug#894698: apgdiff: wrong home page - proposed patch

[Joseph Herlant]

Control: tags -1 + patch

Proposed patch: https://salsa.debian.org/postgresql/apgdiff/merge_requests/2

Bug#894698: apgdiff: wrong home page

[Joseph Herlant]

Package: apgdiff
Version: 2.5.0~alpha.2-75-gcaaaed9-1
Severity: wishlist

Dear Maintainer,

The current home page of apgdiff defined in the package
(http://apgdiff.startnet.biz/) does not exist anymore. This one has
been migrated to https://www.apgdiff.com/.

Regards,
Joseph

Bug#894697: apgdiff: move out of asciidoc - patch

[Joseph Herlant]

Control: tags -1 + patch

Proposed patch: https://salsa.debian.org/postgresql/apgdiff/merge_requests/1

Bug#894697: apgdiff: move out of asciidoc

[Joseph Herlant]

Package: apgdiff
Version: 2.5.0~alpha.2-75-gcaaaed9-1
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).
In your case you would just have to change the asciidoc command and
package dependency to asciidoctor.

Thanks for your help,
Joseph

Bug#894224: pylint: dpkg-source complains about missing .eggs folder when building from source

[Joseph Herlant]

Control: tags -1 +patch

Hi,

The proposed patch is:
https://salsa.debian.org/python-team/applications/pylint/merge_requests/1

Best,
Joseph

Bug#894224: pylint: dpkg-source complains about missing .eggs folder when building from source

[Joseph Herlant]

Package: pylint
Version: 1.8.1-1
Severity: wishlist

Hi,

When I try to build the package from the git repo it fails with the
following error (even if I can't find it in the orig tarball or in the
one built from the pristine-tar tarball:

dpkg-source: warning: file
pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/metadata.json
has no final newline (either original or modified version)
dpkg-source: info: local changes detected, the modified files are:
 pylint-1.8.1/.eggs/README.txt
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/DESCRIPTION.rst
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/LICENSE.txt
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/PKG-INFO
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/RECORD
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/WHEEL
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/entry_points.txt
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/metadata.json
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/namespace_packages.txt
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/requires.txt
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/EGG-INFO/top_level.txt
 pylint-1.8.1/.eggs/pytest_runner-4.2-py2.7.egg/ptr.py
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/pylint_1.8.1-2.diff.Gt1Wnv


One way to ignore this would be to add the following line in
debian/source/options:
extend-diff-ignore = \.eggs(?:$|/.*)

I'll propose a PR as patch for this in a minute.
Let me know if there's another way to fix it.

Thanks
Joseph

Bug#894194: anet: move out of asciidoc

[Joseph Herlant]

Package: anet
Version: 0.3.4-1
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).
In your case you would just have to change the asciidoc command and
package dependency to asciidoctor.

Thanks for your help,
Joseph

Bug#894192: altos: move out of asciidoc

[Joseph Herlant]

Package: altos
Version: 1.8.5-1
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).
You will have to use asciidoctor-pdf to generate the pdf version of
your documentation but the rest should be doable with asciidoctor.

Thanks for your help,
Joseph

Bug#894188: ansible: Move out of asciidoc

[Joseph Herlant]

Package: ansible
Version: 2.5.0+dfsg-1
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages packages that depend on it and their upstream to get its EOL go
smooth.

A patch has been merged by upstream to get rid of it. It would be nice if it
could be cherry-picked inside the current version:
https://github.com/ansible/ansible/pull/37861

Do you think it's acceptable on your side?
I can push a PR with the quilt patch on Salsa if you are ok with that process.

Thanks for your reply,
Joseph