Bug#978594: O: pylint-plugin-utils -- Utilities and helpers for writing Pylint plugins (Python 3)
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)
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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'
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
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 python3
Bug#944987: pylint: please upgrade to >= 2.3.0
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?
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
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
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
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
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
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
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
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
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
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%
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!
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
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
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
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
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
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()
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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???
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???
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
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
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
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
Control: tags -1 + patch Proposed patch: https://salsa.debian.org/postgresql/apgdiff/merge_requests/2
Bug#894698: apgdiff: wrong home page
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
Control: tags -1 + patch Proposed patch: https://salsa.debian.org/postgresql/apgdiff/merge_requests/1
Bug#894697: apgdiff: move out of asciidoc
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
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
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#894192: altos: move out of asciidoc
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#894194: anet: move out of asciidoc
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#894188: ansible: Move out of asciidoc
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