Bug#1077470: python3-lsprotocol: Request for backport / Intend to backport
Niels Thykier writes: > Please give me a heads up when you uploaded it to backports NEW. Then I will > upload `python3-pygls` to backports well, which is the last piece that > I need. I just uploaded the package and received the confirmation that it's in NEW. -- Arto Jantunen
Bug#1077470: python3-lsprotocol: Request for backport / Intend to backport
Niels Thykier writes: > I would like to see python3-lsprotocol backported to stable-backports. I use > it in my work on `debputy` and the lack of `python3-lsprotocol` in the current > stable reduces the functionality of `debputy` when used in stable-backports. > > To this end, I would like to coordinate: > > 1. Do you see any blockers for backporting this package other than > packaging? To my knowledge has a strong focus on backwards > compatibility in the specification, so I am not expecting a new > release will end up being problematic. But you might know more > than I do. :) Nope. In fact the current package in unstable/testing installs and works just fine on bookworm (I have been using it there since the beginning). As far as the upstream side is concerned I have no special knowledge, I only packaged it since it's a reverse-dep of the pylsp ruff plugin which I'm an active user of. > 2. Do you have preferences for how the backport is maintained? As in, > do you want to do it? If not, should I use the python3-lsprocotol > git repo (I would need access to it in that case). Or would you > prefer not to have anything to do with it and the maintenance > happens elsewhere? It requires very little work (add a changelog entry and upload), so I can just as well do it myself and save the coordination overhead. I just updated the package in unstable, I'll wait for it to migrate and then upload a backport. Thanks a lot for your work with debputy, I'm using it in my Debian work and it's been great. -- Arto Jantunen
Bug#1071987: python3-sqlalchemy: Missing version constraint in python3-typing-extensions dependency
Package: python3-sqlalchemy Version: 2.0.30+ds1-1 Severity: serious X-Debbugs-Cc: Arto Jantunen Attempting to import sqlalchemy on a partially upgraded bookworm installation results in the following traceback: Traceback (most recent call last): File "/usr/bin/sqlacodegen", line 5, in from sqlacodegen.cli import main File "/usr/lib/python3/dist-packages/sqlacodegen/cli.py", line 8, in from sqlalchemy.engine import create_engine File "/usr/lib/python3/dist-packages/sqlalchemy/__init__.py", line 12, in from . import util as _util File "/usr/lib/python3/dist-packages/sqlalchemy/util/__init__.py", line 15, in from ._collections import coerce_generator_arg as coerce_generator_arg File "/usr/lib/python3/dist-packages/sqlalchemy/util/_collections.py", line 38, in from .typing import is_non_string_iterable File "/usr/lib/python3/dist-packages/sqlalchemy/util/typing.py", line 56, in from typing_extensions import TypeAliasType as TypeAliasType # 3.12 ImportError: cannot import name 'TypeAliasType' from 'typing_extensions' (/usr/lib/python3/dist-packages/typing_extensions.py) Apparently a version later than 4.4.0 which is included in bookworm is needed. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (150, 'unstable'), (150, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-sqlalchemy depends on: ii python3 [python3-supported-min] 3.11.2-1+b1 ii python3-greenlet 2.0.2-1 ii python3-importlib-metadata 4.12.0-1 ii python3-typing-extensions4.4.0-1 Versions of packages python3-sqlalchemy recommends: pn python3-sqlalchemy-ext Versions of packages python3-sqlalchemy suggests: pn python-sqlalchemy-doc pn python3-aiosqlite pn python3-asyncpg pn python3-fdb ii python3-mysqldb1.4.6-2+b1 pn python3-pg8000 ii python3-psycopg2 2.9.5-1+b1 pn python3-pymssql -- no debconf information -- Arto Jantunen
Bug#1061421: Fails to start after an upgrade
"Marc Dequènes (duck)" writes: > Quack, > > On 2024-05-08 09:40, Marc Dequènes wrote: > >> Not sure this is the same problem but I would say it's worth a try. >> I'll prepare the package and let you know how it goes. > > I packaged and uploaded 0.5.0 and this bug is fixed for me now, but I'd like > to hear from you all before closing this bug. This version works for me. -- Arto Jantunen
Bug#1061421: Fails to start after an upgrade
Jeremy Bícha writes: > Please verify whether wlgreet is working for you now. Was something changed somewhere? What, where? On trixie the issue reproduces exactly the same (even with sway upgraded to the binNMU'd version from sid). -- Arto Jantunen
Bug#1068900: elpa-magit-forge: Missing versioned dependency on elpa-transient
Package: elpa-magit-forge Version: 0.3.2+git20231227.1.299bbaa-1 Severity: serious Justification: Policy 3.5 Upgrading to the new snapshot of magit-forge on testing results in the following: install/magit-forge-0.3.2.50snapshot: Handling install of emacsen flavor emacs install/magit-forge-0.3.2.50snapshot: byte-compiling for emacs ../../elpa-src/treepy-0.1.1/treepy.el: Warning: Case 'node will match ‘quote’. If that’s intended, write (node quote) instead. Otherwise, don’t quote ‘node’. ../../elpa-src/treepy-0.1.1/treepy.el: Warning: Case 'context will match ‘quote’. If that’s intended, write (context quote) instead. Otherwise, don’t quote ‘context’. ../../elpa-src/treepy-0.1.1/treepy.el: Warning: Case ':preorder will match ‘quote’. If that’s intended, write (:preorder quote) instead. Otherwise, don’t quote ‘:preorder’. ../../elpa-src/treepy-0.1.1/treepy.el: Warning: Case ':postorder will match ‘quote’. If that’s intended, write (:postorder quote) instead. Otherwise, don’t quote ‘:postorder’. ../../elpa-src/treepy-0.1.1/treepy.el: Warning: Case ':preorder will match ‘quote’. If that’s intended, write (:preorder quote) instead. Otherwise, don’t quote ‘:preorder’. ../../elpa-src/treepy-0.1.1/treepy.el: Warning: Case ':postorder will match ‘quote’. If that’s intended, write (:postorder quote) instead. Otherwise, don’t quote ‘:postorder’. Emergency (magit): Magit requires ‘transient’ >= 0.5.0, but due to bad defaults, Emacs’ package manager, refuses to upgrade this and other built-in packages to higher releases from GNU Elpa. To fix this, you have to add this to your init file: (setq package-install-upgrade-built-in t) Then evaluate that expression by placing the cursor after it and typing C-x C-e. Once you have done that, you have to explicitly upgrade ‘transient’: M-x package-upgrade transient RET Then you also must make sure the updated version is loaded, by evaluating this form: (progn (unload-feature ’transient t) (require ’transient)) If you don’t use the ‘package’ package manager but still get this warning, then your chosen package manager likely has a similar defect. In toplevel form: forge-bitbucket.el:26:2: Error: Invalid slot name: "#", :inapt-face In toplevel form: forge-commands.el:25:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-gitea.el:26:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-github.el:27:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-gitlab.el:27:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-gogs.el:26:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-issue.el:25:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-list.el:28:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-notify.el:25:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-pkg.el:1:2: Warning: ‘define-package’ is an obsolete function (as of 29.1). In toplevel form: forge-post.el:27:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-pullreq.el:25:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-repo.el:25:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-revnote.el:25:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-semi.el:25:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge-topic.el:30:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: forge.el:44:2: Error: forge-topic-mark-read is already defined as something else than a generic function In toplevel form: magit-forge-pkg.el:1:2: Warning: ‘define-package’ is an obsolete function (as of 29.1). ERROR: install script from elpa-magit-forge package failed dpkg: error processing package elpa-magit-forge (--configure): installed elpa-magit-forge package post-installation script subprocess returned error exit status 1 Processing triggers for install-info (7.1-3) ... Errors were encountered while processing: elpa-magit-forge Config is in use. E: Sub-process /usr/bin/dpkg returned an error code (1) Please add a versioned dependency on elpa-transient to prevent this from getting out of sync in testing, and to keep partial upgrades working. -- System Information: Debian Release: t
Bug#1063424: nmu: wlgreet_0.4.1-3
"Marc Dequènes (duck)" writes: > Quack, > > On 2024-02-08 15:50, Arto Jantunen wrote: > >> This is needed to fix #1061421 (crash with recent sway versions). This is >> caused by the same underlying issue as #1061563 in alacritty, it was already >> fixed via binNMU there. > > Thanks a lot. > I'm in the middle of moving to a new Pond and lacked time to debug more, so > this is really helpful. Sadly as far as I can tell that did not in fact fix the issue for wlgreet (while it definitely did for alacritty). I don't know why, though. More debugging is needed. -- Arto Jantunen
Bug#1063424: nmu: wlgreet_0.4.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: wlgr...@packages.debian.org, 1061...@bugs.debian.org Control: affects -1 + src:wlgreet nmu wlgreet_0.4.1-3 . ANY . unstable . -m "Rebuild against rust-smithay-client-toolkit 0.16.1" This is needed to fix #1061421 (crash with recent sway versions). This is caused by the same underlying issue as #1061563 in alacritty, it was already fixed via binNMU there.
Bug#1061421: Fails to start after an upgrade
"Marc Dequènes (duck)" writes:
> Thanks for the report.
> I stumbled onto the same problem but so far was not able to identify what's
> going on. Rebuilding the package does not help.
> I guess it's related to libraries that are loaded dynamically, possibly mesa,
> but it does not seem like an ABI breakage.
> I'll try to dig deeper but l’m open to suggestion.
#1061563 is a similar bug (started at the same time, also talks about
wl_surface) against alacritty. It has more information, and claims to
have a solution as well ("The update of smithay-client-toolkit from
0.16.0 to 0.16.1 is the relevant change and we already have 0.16.1 sctk
packaged."). wlgreet also has a build-dep on
librust-smithay-client-toolkit-dev so this might very well be the same
issue, and fixable in the same way.
--
Arto Jantunen
Bug#1061421: Fails to start after an upgrade
Package: wlgreet Version: 0.4.1-3 Severity: grave After a semi-recent upgrade (I'm not sure which one, as I don't reboot or restart my session after each one) of testing wlgreet no longer starts. Here is what I get when trying to start it under a manually launched sway session: RUST_BACKTRACE=full wlgreet thread 'main' panicked at 'internal error: entered unreachable code', src/app.rs:473:48 stack backtrace: 0: 0x562fb820dd27 - 1: 0x562fb81db7ef - 2: 0x562fb821a5d4 - 3: 0x562fb820d9cf - 4: 0x562fb8217dee - 5: 0x562fb8218960 - 6: 0x562fb820e194 - 7: 0x562fb820e126 - 8: 0x562fb82181f1 - 9: 0x562fb81c1822 - 10: 0x562fb81c187c - 11: 0x562fb829de53 - 12: 0x562fb8269b29 - 13: 0x7fb720bb9a4e - 14: 0x7fb720bb5bb1 - 15: 0x7fb720bb75ac - wl_display_dispatch_queue_pending 16: 0x7fb720bb7b5f - wl_display_roundtrip_queue 17: 0x562fb8298d69 - 18: 0x562fb81cfa3a - 19: 0x562fb82a01a3 - 20: 0x562fb81d225c - 21: 0x7fb7208eb6ca - 22: 0x7fb7208eb785 - __libc_start_main 23: 0x562fb81c7de1 - 24:0x0 - [wayland-client error] A handler for wl_surface panicked. The issue is reproducible under debvm as follows: debvm-create -o /tmp/debvm -r trixie -- --include=linux-image-amd64,wlgreet,greetd --hook-dir /usr/share/mmdebstrap/hooks/useradd && debvm-run -i /tmp/debvm -g Modify greetd config to start sway (comment out agreety, uncomment sway) and restart it, wlgreet fails with what looks like the same error message. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages wlgreet depends on: ii libc6 2.37-13 ii libgcc-s1 13.2.0-10 ii sway 1.9~debian.2bba8a86-2 wlgreet recommends no packages. wlgreet suggests no packages. -- Configuration Files: /etc/greetd/sway-config changed: exec "/usr/sbin/wlgreet; swaymsg exit" bindsym Mod4+shift+e exec swaynag \ -t warning \ -m 'What do you want to do?' \ -b 'Poweroff' 'systemctl poweroff -i' \ -b 'Reboot' 'systemctl reboot -i' include /etc/sway/config.d/* include /etc/greetd/sway-config.d/* -- no debconf information
Bug#1055559: python3-ruff: Missing dependency on ruff
Package: python3-ruff Severity: serious Version: 0.0.291+dfsg1-1 Control: block 1054205 by -1 The Python library is entirely useless without the binary, thus there needs to be a strong dependency between them. -- Arto Jantunen
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Xiyue Deng writes:
> Arto Jantunen writes:
>
>> Xiyue Deng writes:
>>
>>> Hi Arto,
>>>
>>> Arto Jantunen writes:
>>>
>>>> Xiyue Deng writes:
>>>>> Package: sponsorship-requests
>>>>> Severity: important
>>>>> X-Debbugs-CC: debian-emac...@lists.debian.org
>>>>>
>>>>> Dear mentors,
>>>>>
>>>>> I am looking for a sponsor for my package "lsp-mode":
>>>>>
>>>>> * Package name : lsp-mode
>>>>>Version : 8.0.0-6
>>>>>Upstream contact : Vibhav Pant
>>>>> * URL : https://github.com/emacs-lsp/lsp-mode
>>>>> * License : GPL-3+
>>>>> * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode
>>>>>Section : lisp
>>>>>
>>>>> The source builds the following binary packages:
>>>>>
>>>>> elpa-lsp-mode - Emacs client/library for the Language Server Protocol
>>>>>
>>>>> To access further information about this package, please visit the
>>>>> following URL:
>>>>>
>>>>> https://mentors.debian.net/package/lsp-mode/
>>>>>
>>>>> Alternatively, you can download the package with 'dget' using this
>>>>> command:
>>>>>
>>>>> dget -x
>>>>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>>>>
>>>>> Changes since the last upload:
>>>>>
>>>>> lsp-mode (8.0.0-6) unstable; urgency=medium
>>>>> .
>>>>>* Add patch to fix test failures (Closes: #1052939).
>>>>>* Update Standards-Version to 4.6.2. No change needed.
>>>>>* Add myself as uploader (Closes: #1042568).
>>>>>* Add signing key verification to d/watch.
>>>>>* Add d/upstream/metadata.
>>>>>* Add Upstream-Contact and update year in d/copyright.
>>>>>* Add patch to fix non-UTF-8 encoding.
>>>>>* Drop unused lintian overrides.
>>>>
>>>> Thanks for taking over this package.
>>>>
>>>> When I try to build this (under sbuild) I get the following build
>>>> failure:
>>>>
>>>> Test ‘lsp-text-document-hover-request’ redefined
>>>>
>>>> Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>>>> mapbacktrace(#f(compiled-function (evald func args flags) #>>> -0x187de6214517952>))
>>>> debug-early-backtrace()
>>>> debug-early(error (error "Test ‘lsp-text-document-hover-request’
>>>> redefined"))
>>>> error("Test `%s' redefined" lsp-text-document-hover-request)
>>>> ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>>>> lsp-text-document-hover-request :documentation nil :body (closure (t) nil
>>>> (lsp-workspace-folders-add (f-join lsp-test-location "fixtures"))
>>>> (find-file
>>>> (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) (deferred:sync!
>>>> (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq
>>>> 'initialized
>>>> (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_)
>>>> (goto-char
>>>> (point-min)) (search-forward "fn1") (lsp-def-request-async
>>>> "textDocument/hover"
>>>> (lsp--text-document-position-params #'(lambda (contents) (let* ((fn-566
>>>> #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
>>>> #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
>>>> #'signal) (list (car err) (cdr err))) (let ((value-568
>>>> 'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
>>>> (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
>>>> form-description-570 (nconc (list '(should (lsp-hover? contents))) (list
>>>> :form
>>>> (cons fn-566 args-567)) (if (eql value-568
>>>> 'ert-form-evaluation-aborted-569) nil
>>>> (list :value value-568)) (if (eql value-568
>>>> 'ert-form-evaluation-aborted-569)
>>>> nil (let* ((-explainer- (and t (ert--get-explainer 'lsp-hover? (if
>>>>
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Xiyue Deng writes:
> Hi Arto,
>
> Arto Jantunen writes:
>
>> Xiyue Deng writes:
>>> Package: sponsorship-requests
>>> Severity: important
>>> X-Debbugs-CC: debian-emac...@lists.debian.org
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for my package "lsp-mode":
>>>
>>> * Package name : lsp-mode
>>>Version : 8.0.0-6
>>>Upstream contact : Vibhav Pant
>>> * URL : https://github.com/emacs-lsp/lsp-mode
>>> * License : GPL-3+
>>> * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode
>>>Section : lisp
>>>
>>> The source builds the following binary packages:
>>>
>>> elpa-lsp-mode - Emacs client/library for the Language Server Protocol
>>>
>>> To access further information about this package, please visit the
>>> following URL:
>>>
>>> https://mentors.debian.net/package/lsp-mode/
>>>
>>> Alternatively, you can download the package with 'dget' using this command:
>>>
>>> dget -x
>>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>>
>>> Changes since the last upload:
>>>
>>> lsp-mode (8.0.0-6) unstable; urgency=medium
>>> .
>>>* Add patch to fix test failures (Closes: #1052939).
>>>* Update Standards-Version to 4.6.2. No change needed.
>>>* Add myself as uploader (Closes: #1042568).
>>>* Add signing key verification to d/watch.
>>>* Add d/upstream/metadata.
>>>* Add Upstream-Contact and update year in d/copyright.
>>>* Add patch to fix non-UTF-8 encoding.
>>>* Drop unused lintian overrides.
>>
>> Thanks for taking over this package.
>>
>> When I try to build this (under sbuild) I get the following build
>> failure:
>>
>> Test ‘lsp-text-document-hover-request’ redefined
>>
>> Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>> mapbacktrace(#f(compiled-function (evald func args flags) #> -0x187de6214517952>))
>> debug-early-backtrace()
>> debug-early(error (error "Test ‘lsp-text-document-hover-request’
>> redefined"))
>> error("Test `%s' redefined" lsp-text-document-hover-request)
>> ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>> lsp-text-document-hover-request :documentation nil :body (closure (t) nil
>> (lsp-workspace-folders-add (f-join lsp-test-location "fixtures")) (find-file
>> (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) (deferred:sync!
>> (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq 'initialized
>> (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_)
>> (goto-char
>> (point-min)) (search-forward "fn1") (lsp-def-request-async
>> "textDocument/hover"
>> (lsp--text-document-position-params #'(lambda (contents) (let* ((fn-566
>> #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
>> #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
>> #'signal) (list (car err) (cdr err))) (let ((value-568
>> 'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
>> (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
>> form-description-570 (nconc (list '(should (lsp-hover? contents))) (list
>> :form
>> (cons fn-566 args-567)) (if (eql value-568 'ert-form-evaluation-aborted-569)
>> nil
>> (list :value value-568)) (if (eql value-568 'ert-form-evaluation-aborted-569)
>> nil (let* ((-explainer- (and t (ert--get-explainer 'lsp-hover? (if
>> -explainer- (list :explanation (apply -explainer- args-567)) nil)
>> (ert--signal-should-execution form-description-570)) nil (ert-fail
>> form-description-570))) value-568) (kill-buffer)
>> (lsp-workspace-folders-remove (f-join lsp-test-location "fixtures")))
>> :most-recent-result nil :expected-result-type :passed :tags nil :file-name
>> "/<>/test/lsp-integration-test.el"))
>> load-with-code-conversion("/<>/test/lsp-integration-test.el"
>> "/<>/test/lsp-integration-test.el" nil t)
>> command-line-1(("-l" "package" "--eval" "(add-to-list
>> 'package-directory-list
>> \"/usr/share/emacs/site-lisp/elpa\")" "--eval&qu
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
command-line() normal-top-level() dh_elpa_test: error: emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L clients/ -L . -L test -l test/lsp-clangd-test.el -l test/lsp-completion-test.el -l test/lsp-file-watch-test.el -l test/lsp-integration-test.el -l test/lsp-io-test.el -l test/lsp-javascript-test.el -l test/lsp-methods-test.el -l test/lsp-mode-test.el -l test/lsp-protocol-test.el -l test/lsp-common-test.el -l debian/ert-helper.el returned exit code 255 make: *** [debian/rules:4: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Is this something specific to my environment? I can't see two actual definitions of a test with that name... -- Arto Jantunen
Bug#1054206: ITP: lsprotocol -- Python implementation of the Language Server Protocol types
Jonas Smedegaard writes: > Quoting Arto Jantunen (2023-10-19 07:48:40) >> * Package name: lsprotocol > > Do the project really need to occupy the global namespace "lsprotocol" > within Debian? > > If The project does not provide an executable /usr/bin/lsprotocol (which > is generally usable, not just a narrow tool more appropriately provided > in Debian as an example file), or in other ways make use the name > "lsprotocol" in a system-wide namespace, then please rename the project > as packaged in Debian - i.e. not only binary packages but also source > package, to include a suitable prefix or suffix. > > Concretely, please consider renaming this packaging project as > python-lsprotocol. The source package contains the source for these data definitions, a generator (written in Python) and the definitions in Python, Rust and Dotnet. At this time I wasn't planning on creating binaries for the other two languages, but would definitely be open to that later on (at which time it may make sense to move out of the Python team). -- Arto Jantunen
Bug#1054206: ITP: lsprotocol -- Python implementation of the Language Server Protocol types
Package: wnpp Severity: wishlist Owner: Arto Jantunen X-Debbugs-Cc: debian-de...@lists.debian.org Control: block 1054205 by -1 * Package name: lsprotocol Version : 2023.0.0b1 Upstream Contact: Microsoft Corporation * URL : https://github.com/microsoft/lsprotocol * License : MIT Programming Lang: Python Description : Python implementation of the Language Server Protocol types lsprotocol is a Python implementation of object types used in the Language Server Protocol (LSP). This is needed as a dependency of python-lsp-ruff. I will maintain it under the Python team.
Bug#1054205: ITP: python-lsp-ruff -- Ruff linting plugin for pylsp
Package: wnpp Severity: wishlist Owner: Arto Jantunen X-Debbugs-Cc: debian-de...@lists.debian.org Control: block -1 by 1030835 * Package name: python-lsp-ruff Version : 1.5.3 Upstream Contact: Julian Hossbach * URL : https://github.com/python-lsp/python-lsp-ruff/ * License : MIT Programming Lang: Python Description : Ruff linting plugin for pylsp python-lsp-ruff is a plugin for python-lsp-server that adds linting, code action and formatting capabilities that are provided by ruff, an extremely fast Python linter written in Rust. I will maintain it under the Python team.
Bug#1049950: dh-python: Pybuild runs tests with tox but fails to clean up
Stefano Rivera writes: > Control: tag -1 + moreinfo > > Hi Arto (2023.08.17_11:33:51_+0200) >> Pybuild uses tox to run the upstream test suite of the package, but >> fails to clean up the created .tox directory during debian/rules clean. > > It has code to do this, can you point to an example of it not happening? > > https://salsa.debian.org/python-team/tools/dh-python/-/blob/a5068b6de912dee00415e3ed8af13b75ef29994c/dhpython/build/base.py#L164-172 Bug #1045322 was filed against pytrainer, and I read the log there as "tox directory not cleaned up". The bug is marked blocked by this bug. Pytrainer has an essentially empty debian/rules so my immediate thought was that the tools used (dh_python3 + pybuild) are the source of the problem. -- Arto Jantunen
Bug#1043060: emacs-pgtk: wayland backend unusable with emacsclient
Sean Whitton writes: > 2. install pgtk's emacsclient, because that seems to cover everyone. >More testing is required. Attached is a patch implementing this solution. The end result works for the pgtk/Wayland side, but the other variants on X side should get more testing. >From cf5d2cd81bd9e39cfd6312a85351ca40dea88f85 Mon Sep 17 00:00:00 2001 From: Arto Jantunen Date: Wed, 2 Aug 2023 11:37:00 +0300 Subject: [PATCH 2/2] Take emacs-bin-common contents from pgtk --- debian/rules | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/debian/rules b/debian/rules index b42d2634a42d..1d76f18c9ece 100755 --- a/debian/rules +++ b/debian/rules @@ -399,7 +399,7 @@ endef override_dh_auto_install: $(autogen_install_files) rm -rf \ - $(install_dir_gtk) $(install_dir_nox) $(install_dir_lucid) \ + $(install_dir_pgtk) $(install_dir_nox) $(install_dir_lucid) \ $(pkgdir_common)/* \ $(pkgdir_bin_common)/* \ $(pkgdir_gtk)/* \ @@ -408,13 +408,13 @@ override_dh_auto_install: $(autogen_install_files) $(pkgdir_lucid)/* \ $(pkgdir_el)/* - $(call emacs_inst,build-gtk,$(install_dir_gtk)) + $(call emacs_inst,build-pgtk,$(install_dir_pgtk)) ## # emacs-common ifneq (,$(findstring emacs-common, $(shell dh_listpackages))) install -d $(pkgdir_common) - cp -a $(install_dir_gtk)/* $(pkgdir_common) + cp -a $(install_dir_pgtk)/* $(pkgdir_common) rm -r $(pkgdir_common)/usr/bin rm \ @@ -488,8 +488,8 @@ override_dh_auto_install: $(autogen_install_files) ifneq (,$(findstring emacs-bin-common, $(shell dh_listpackages))) # Move common binaries to emacs-bin-common. install -d $(pkgdir_bin_common)/usr - cp -a $(install_dir_gtk)/usr/bin $(pkgdir_bin_common)/usr - cp -a $(install_dir_gtk)/usr/libexec $(pkgdir_bin_common)/usr + cp -a $(install_dir_pgtk)/usr/bin $(pkgdir_bin_common)/usr + cp -a $(install_dir_pgtk)/usr/libexec $(pkgdir_bin_common)/usr # Make sure there's just one. test -f $(pkgdir_bin_common)/usr/bin/emacs-* @@ -517,6 +517,7 @@ override_dh_auto_install: $(autogen_install_files) ## # emacs-gtk ifneq (,$(findstring emacs, $(shell dh_listpackages))) + $(call emacs_inst,build-gtk,$(install_dir_gtk)) $(call install_common_binpkg_bits,\ $(install_dir_gtk),$(pkgdir_gtk),emacs-gtk,gtk) @@ -530,8 +531,7 @@ override_dh_auto_install: $(autogen_install_files) ## # emacs-pgtk -ifneq (,$(findstring emacs-pgtk, $(shell dh_listpackages))) - $(call emacs_inst,build-pgtk,$(install_dir_pgtk)) +ifneq (,$(findstring emacs, $(shell dh_listpackages))) $(call install_common_binpkg_bits,\ $(install_dir_pgtk),$(pkgdir_pgtk),emacs-pgtk,pgtk) -- 2.40.1 -- Arto Jantunen
Bug#1049950: dh-python: Pybuild runs tests with tox but fails to clean up
Package: dh-python Version: 6.20230813 Severity: normal Control: block 1045322 by -1 Pybuild uses tox to run the upstream test suite of the package, but fails to clean up the created .tox directory during debian/rules clean. -- Arto Jantunen
Bug#1042568: O: lsp-mode -- Emacs client/library for the Language Server Protocol
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 + src:lsp-mode Since I no longer use it (eglot is now included in Emacs and I have converted my workflow to use it instead) I intend to orphan the lsp-mode package. The change removing my name from Uploaders has already been applied in git. This is a team-maintained package, so the adoptor should either replace me in Uploaders, or alternatively take the package out of the team's hands. The package description is: A Emacs Lisp library for implementing clients for servers using Microsoft's Language Server Protocol (v3.0)[1]. . The library is designed to integrate with existing Emacs IDE frameworks (completion-at-point, xref (beginning with Emacs 25.1), flycheck, etc). . [1]: https://github.com/Microsoft/language-server-protocol
Bug#1034609: Fails to start under Python 3.11
Michael Prokop writes: > * Arto Jantunen [Wed Apr 19, 2023 at 07:49:33PM +0300]: > >> The package fails to import under Python 3.11 with the following traceback: >> Traceback (most recent call last): > [...] >> File "/usr/lib/python3/dist-packages/sqlacodegen/main.py", line 10, in >> >> from sqlacodegen.codegen import CodeGenerator >> File "/usr/lib/python3/dist-packages/sqlacodegen/codegen.py", line 4, in >> >> from inspect import ArgSpec >> ImportError: cannot import name 'ArgSpec' from 'inspect' >> (/usr/lib/python3.11/inspect.py) >> >> The issue seems to have been fixed in the latest release candidate, but that >> isn't really suitable for bookworm during the freeze, so the intent of this >> bug is to cause the package to be dropped from the release. > > If you don't want to maintain this package or its 1.1.6 version > within bookworm then nevermind my comment :) - but looking at > https://github.com/agronholm/sqlacodegen/issues/239#issuecomment-1457728533 > the fix for this *might* be as simple as replacing: > > from inspect import ArgSpec > > with: > > from inspect import FullArgSpec > > Also see https://docs.python.org/3/whatsnew/changelog.html + > https://docs.python.org/3/library/inspect.html#inspect.getfullargspec > > But given that v1.1.6 was released on 2015-05-15 and not updated > within Debian since then, while upstream relased multiple stable > versions like e.g. v2.3.0 on 2020-07-13, I'd understand your > reasoning to drop this package at least for bookworm. :) Even after patching those and a few smaller issues the upstream testsuite still doesn't pass (seems like a difference in how it expects sqlalchemy to behave, so probably related to the version bookworm has of that). I could skip the test or patch it to pass, but.. I think it's simply too late now, and would just let the package get autoremoved. I plan to upload the latest upstream RC (which I think should work with Python 3.11) to unstable after that has happened. -- Arto Jantunen
Bug#1034609: Fails to start under Python 3.11
Package: sqlacodegen
Version: 1.1.6-4
Severity: grave
Tags: upstream fixed-upstream
The package fails to import under Python 3.11 with the following traceback:
Traceback (most recent call last):
File "/usr/bin/sqlacodegen", line 33, in
sys.exit(load_entry_point('sqlacodegen==1.1.6', 'console_scripts',
'sqlacodegen')())
File "/usr/bin/sqlacodegen", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/sqlacodegen/main.py", line 10, in
from sqlacodegen.codegen import CodeGenerator
File "/usr/lib/python3/dist-packages/sqlacodegen/codegen.py", line 4, in
from inspect import ArgSpec
ImportError: cannot import name 'ArgSpec' from 'inspect'
(/usr/lib/python3.11/inspect.py)
The issue seems to have been fixed in the latest release candidate, but that
isn't really suitable for bookworm during the freeze, so the intent of this
bug is to cause the package to be dropped from the release.
-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (990, 'testing-security'), (990, 'testing'), (500, 'unstable'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sqlacodegen depends on:
ii python3 3.11.2-1+b1
ii python3-inflect 2.1.0-4
ii python3-sqlalchemy 1.4.46+ds1-1
sqlacodegen recommends no packages.
sqlacodegen suggests no packages.
-- no debconf information
Bug#1031333: golang-docker-credential-helpers: Please demote gnome-keyring to Recommends
Package: golang-docker-credential-helpers Version: 0.6.4+ds1-1+b4 Severity: wishlist Tags: patch Dear Maintainer, The golang-docker-credential-helpers binary package contains two entirely separate credential helpers. docker-credential-pass requires the pass tool to work, and docker-credential-secretservice requires gnome-keyring (or perhaps it could work with any other package providing the same dbus interface such as kwalletd, but I haven't checked that). Users of docker-credential-pass thus have no need to install gnome-keyring (which fights with the mentioned kwalletd that is required and running by default for KDE users). See here for an MR implementing the change: https://salsa.debian.org/go-team/packages/golang-github-docker-docker-credential-helpers/-/merge_requests/3 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages golang-docker-credential-helpers depends on: ii gnome-keyring 42.1-1+b1 ii libc6 2.36-8 ii libglib2.0-0 2.74.5-1 ii libsecret-1-0 0.20.5-3 golang-docker-credential-helpers recommends no packages. Versions of packages golang-docker-credential-helpers suggests: ii pass 1.7.4-6
Bug#1029946: ITP: radicale-dovecot-auth -- Dovecot authentication plugin for Radicale
Package: wnpp Severity: wishlist Owner: Arto Jantunen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: radicale-dovecot-auth Version : 0.4.1 Upstream Contact: Arvedui * URL : https://github.com/Arvedui/radicale-dovecot-auth * License : GPL-3 Programming Lang: Python Description : Dovecot authentication plugin for Radicale Plugin to connect Radicale (a CalDAV (calendar) and CardDAV (contact) server) to the Dovecot authentication system. The package will be maintained under the Debian Python Team.
Bug#1027916: ITP: aiohttp-oauthlib -- oauthlib for aiohttp clients
Package: wnpp Severity: wishlist Owner: Arto Jantunen X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aiohttp-oauthlib Version : 0.1.0 Upstream Contact: Hugo Osvaldo Barrera * URL : https://git.sr.ht/~whynothugo/aiohttp-oauthlib * License : ISC Programming Lang: Python Description : oauthlib for aiohttp clients This library is a port of requests-oauthlib for aiohttp. vdirsyncer needs this library to be able to access calendar systems that use OAuth. The package will be maintained under the Debian Python Team.
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > Nearly five months later, I'm just pinging in to say that I'm still A: > interested in this, and B: waiting on any possible response as regards > what qualifies as sufficient testing for the drop-the-problematic-file > WIP branch. > > Once we're sufficiently certain that the result is OK as far as what > would go into a package, I plan (as I have for some time now) to make a > release with it, which should also include the new feature which has > been sitting in Limbo for some time now. Moosic is currently very low on my very long TODO list, I can't guarantee any timeframe for getting to it. To remove my timetable as blocker for this work, you could for example join the Python team yourself, do the packaging and look for a sponsor to upload the result. -- Arto Jantunen signature.asc Description: PGP signature
Bug#1003103: Clients are missing from the package
Package: elpa-lsp-mode Version: 8.0.0-2 Severity: grave Tags: patch X-Debbugs-Cc: tho...@koch.ro A large part of the program isn't included in the package, see a debdiff between version 8.0.0-2 and a correctly built package: Files in first .deb but not in second - -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-actionscript.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-ada.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-angular.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-bash.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-beancount.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-clangd.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-clojure.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-cmake.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-crystal.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-csharp.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-css.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-d.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-dhall.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-dockerfile.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-elixir.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-elm.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-erlang.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-eslint.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-fortran.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-fsharp.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-gdscript.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-go.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-groovy.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-hack.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-haxe.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-html.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-javascript.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-json.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-kotlin.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-lua.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-markdown.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-nim.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-nix.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-ocaml.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-perl.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-php.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-prolog.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-purescript.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-pwsh.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-pyls.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-pylsp.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-r.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-racket.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-rf.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-rust.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-solargraph.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-sorbet.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-sqls.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-steep.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-svelte.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-terraform.el -rw-r--r-- root/root /usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-tex.el -rw-r--r-- root/root /usr/share/emacs/site-
Bug#998214: lsp-mode: Please update to version 8.0.0
Package: lsp-mode Version: 7.0.1-3 Severity: wishlist Please update to the current upstream version 8.0.0. It adds support for the current python-lsp-server (instead of only supporting the deprecated pyls variant). -- Arto Jantunen
Bug#996813: openzwave: Please add support for cross building
Package: src:openzwave Version: 1.6.1545+ds-2 Severity: wishlist Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs Please add support for cross building. The changes required to allow cross building are available as an MR on salsa: https://salsa.debian.org/debian-iot-team/openzwave/-/merge_requests/4 -- Arto Jantunen signature.asc Description: PGP signature
Bug#994533: python3-matplotlib: Fails to import under Wayland
Package: python3-matplotlib Version: 3.3.4-1 Severity: important Tags: upstream, fixed-upstream Forwarded: https://github.com/matplotlib/matplotlib/issues/19405 Dear Maintainer, When running under Wayland matplotlib before version 3.4.0 fails at import time with the following traceback: Gdk-Message: 14:13:31.165: Unable to load tcross from the cursor theme Traceback (most recent call last): File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_gtk3.py", line 43, in cursors.SELECT_REGION: Gdk.Cursor.new(Gdk.CursorType.TCROSS), TypeError: constructor returned NULL Please update to a later upstream version to fix the issue. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-matplotlib depends on: ii libc6 2.31-13 ii libfreetype62.10.4+dfsg-1 ii libgcc-s1 10.2.1-6 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-ui 1.12.1+dfsg-8 ii libstdc++6 10.2.1-6 ii python-matplotlib-data 3.3.4-1 ii python3 3.9.2-3 ii python3-cycler 0.10.0-3 ii python3-dateutil2.8.1-6 ii python3-kiwisolver 1.3.1-1+b1 ii python3-numpy [python3-numpy-abi9] 1:1.19.5-1 ii python3-pil 8.1.2+dfsg-0.3 ii python3-pyparsing 2.4.7-1 ii python3-six 1.16.0-2 Versions of packages python3-matplotlib recommends: ii python3-tk 3.9.2-1 Versions of packages python3-matplotlib suggests: pn dvipng pn ffmpeg ii ghostscript9.53.3~dfsg-7+deb11u1 ii gir1.2-gtk-3.0 3.24.24-4 pn inkscape ii ipython3 7.20.0-1 ii librsvg2-common2.50.3+dfsg-1 pn python-matplotlib-doc pn python3-cairocffi ii python3-gi 3.38.0-2 ii python3-gi-cairo 3.38.0-2 pn python3-gobject pn python3-nose ii python3-pyqt5 5.15.2+dfsg-3 pn python3-scipy ii python3-sip4.19.25+dfsg-1 ii python3-tornado6.1.0-1+b1 pn texlive-extra-utils pn texlive-latex-extra pn ttf-staypuft -- no debconf information
Bug#992686: pipewire-pulse: Please have pipewire-pulse Provide pulseaudio
Package: pipewire-pulse Version: 0.3.33-1 Severity: wishlist Dear Maintainer, Please add Provides: pulseaudio to the pipewire-pulse package so that the pulseaudio daemon which this replaces can be removed (a lot of tools have dependencies on pulseaudio, but work just as well or better with pipewire-pulse). I don't think Conflicts, Replaces or Breaks are needed here as there are no file conflicts and there is no real harm that comes from having both installed (except perhaps difficulties in making sure that the right daemon is started and the wrong one isn't). -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (500, 'oldstable'), (90, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pipewire-pulse depends on: ii init-system-helpers 1.60 ii libc62.31-13 ii libpipewire-0.3-00.3.33-1 ii pipewire 0.3.33-1 pipewire-pulse recommends no packages. pipewire-pulse suggests no packages. -- no debconf information
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > On 2021-03-12 at 05:32, Arto Jantunen wrote: >> We might as well just remove it for now, we can easily bring it back >> if we can come up with a plausible story about the licensing >> situation. > > If you think that's OK for the package (and its users, who may or may > not care about completion), then I'm fine with it for the moment. I don't think we have a massive number of users anyway, and they can still manually install the completion if they need it. In any case, having the package without completion is probably preferable to not having the package at all. > Would this call for an upstream release dropping the file, or are you OK > with excluding it from what gets installed as part of the package? I'd prefer an upstream release if you don't feel strongly about it, I think otherwise I need to filter the upstream tarball and I'd rather not. -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > On 2021-03-10 at 01:30, Arto Jantunen wrote: > >> Indeed the package was rejected after two months in the queue, due to >> things missing from the copyright file: >> >>> +--+ >>> | REJECT reasoning | >>> +--+ >>> >>> examples/completion seems to be copyright Etienne PIERRE and there does not >>> seem to be reason that they too have relinquished copyright. >>> >>> moosic/server/xmlrpc_registry.py has a different license. >>> >>> +--+ >>> | N.B. | >>> +--+ >>> >>> This review may not be exhaustive. Please check your source package >>> against your d/copyright and the ftpmaster REJECT-FAQ, throughly, >>> before uploading to NEW again. > > Neither of these things is new; they were true of the last version prior > to the removal, and possibly of some versions prior to that as well. > That makes this a bit aggravating. > > Still, I suppose that just means they slipped through the cracks of the > less-stringent copyright review that's applied to packages already in > the archive, rather than that they shouldn't need to be addressed... There is no systematic copyright review happening for packages that are already in the archive (unless they add new binary packages and end up in the NEW queue that way). I'm personally not a fan of how this currently works in Debian, but "so there has ever been and ever will be". >> I'll try to find the time to go through the source and update this, >> unless you beat me to it of course. :) > > For moosic/server/xmlrpc_registry.py, I think we just need to document > the license in debian/copyright. I don't have a local copy of the > debian/ directory for this, and have no experience with updating such, > so although I'd kind of like to *get* that experience I think it'd > probably be best if you cover that part. Sure, I'll handle that. > For examples/completion, it's not clear whether or not documenting the > copyright statement would be enough. No specific license is stated for > that file, so it's not clear what license Etienne PIERRE (whom I infer > to be its original author, prior to later changes introduced by Daniel > Pearson) would have intended for it. The completion script was actually provided through Debian initially and then later included upstream: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184633 This initial submission includes a copyright statement, but no license. Not asking for one was clearly my mistake. We might as well just remove it for now, we can easily bring it back if we can come up with a plausible story about the licensing situation. -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > (Apologies for breaking threading; I don't seem to have received the > original mail, and my Web browser appears to be treating the mailto: > links as something like file://mailto: links, and reports that it can't > find any file by the given name.) > > On 2021-01-02 at 13:34, Arto Jantunen wrote: > >> The package has been uploaded and is in NEW awaiting processing by >> the FTP team. > > Last night (as far as I can judge), this package disappeared from > https://ftp-master.debian.org/new.html (which I take to be the NEW > queue). > > As of a few minutes ago, it did not seem to be in the archive. A > packages.debian.org search didn't find it in anything newer than stable > (with the old version, of course), and the tracker.debian.org page for > this package showed the last change being the removal this past April. > > I'm not sure whether this is normal (package approved, processing to get > it actually into unstable doesn't happen right away, no visible sign of > package's status in the meantime), or whether it may mean that the > package has been rejected. > > If the former, then all is well. If the latter, I'd be interested to > know the status, both so I know what to expect and in case there's > anything I can do to help the package get in on a subsequent try. > Indeed the package was rejected after two months in the queue, due to things missing from the copyright file: > +--+ > | REJECT reasoning | > +--+ > > examples/completion seems to be copyright Etienne PIERRE and there does not > seem to be reason that they too have relinquished copyright. > > moosic/server/xmlrpc_registry.py has a different license. > > +--+ > | N.B. | > +--+ > > This review may not be exhaustive. Please check your source package > against your d/copyright and the ftpmaster REJECT-FAQ, throughly, > before uploading to NEW again. I'll try to find the time to go through the source and update this, unless you beat me to it of course. :) In any case we have missed the freeze by a mile, so we have a couple of years to get this done before the next round. -- Arto Jantunen
Bug#981635: Device database is not installed
Package: src:openzwave Version: 1.6.1545+ds-1 Severity: normal Tags: patch Under version 1.6 the device database isn't being installed since the packaging wasn't updated to do that when upgrading from version 1.5. I have created an MR on Salsa with the fix: https://salsa.debian.org/debian-iot-team/openzwave/-/merge_requests/1 -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
Control: tags -1 +pending The Wanderer writes: > On 2020-12-23 at 02:08, Arto Jantunen wrote: > >> The Wanderer writes: > >>> I've decided it's worth the effort to become the new upstream for >>> this, and confirmed with the original author that he has no >>> objections, as he is no longer spending any time maintaining it. >>> >>> Version 1.5.7, based on Python 3 rather than Python 2, is now >>> available from: >>> >>> https://github.com/inverseparadox/moosic >>> >>> Please consider packaging this version, if possible in time to meet >>> the release freeze. > >>> Please let me know if there's anything I can do to help move this >>> forward. >> >> You've done the big part of the work already. I'll try to take care >> of updating the package as soon as I can, but due to commitments >> related to the holiday season that will probably take a week or so. >> That should still give us barely enough time before the freeze. > > I am *very* glad to hear that. After sending the above, I discovered > that the package had in fact already been removed from both testing and > unstable; I was starting to be concerned that it might need a full RFP / > ITP / RFS / trip-through-NEW / etc. cycle, which could be more of a > problem and more time-consuming than I'd prefer to engage with at this > stage. > > While obviously making the release freeze would be preferable, don't > worry too much if you can't make that time-frame on your end; I'd still > be happier with the package available in sid (or even experimental) than > with it dropped entirely, even if it doesn't get shipped with the next > release. > >> Thanks a lot for the work you did here. > > Thank *you* for picking this package back up, even with the upstream > side already handled! > > My "if there's anything I can do to help" on this still stands, so long > as I continue to have the time and other capacity to spare. The package has been uploaded and is in NEW awaiting processing by the FTP team. -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > On 2020-12-23 at 02:08, Arto Jantunen wrote: > >> The Wanderer writes: > >>> I've decided it's worth the effort to become the new upstream for >>> this, and confirmed with the original author that he has no >>> objections, as he is no longer spending any time maintaining it. >>> >>> Version 1.5.7, based on Python 3 rather than Python 2, is now >>> available from: >>> >>> https://github.com/inverseparadox/moosic >>> >>> Please consider packaging this version, if possible in time to meet >>> the release freeze. > >>> Please let me know if there's anything I can do to help move this >>> forward. >> >> You've done the big part of the work already. I'll try to take care >> of updating the package as soon as I can, but due to commitments >> related to the holiday season that will probably take a week or so. >> That should still give us barely enough time before the freeze. > > I am *very* glad to hear that. After sending the above, I discovered > that the package had in fact already been removed from both testing and > unstable; I was starting to be concerned that it might need a full RFP / > ITP / RFS / trip-through-NEW / etc. cycle, which could be more of a > problem and more time-consuming than I'd prefer to engage with at this > stage. Yeah, apparently so. I thought it had only been removed from testing, but since it has been removed from unstable (removed completely) we do need a trip through NEW. As I can't affect the time that takes we'll see what we can do. -- Arto Jantunen
Bug#970635: moosic: not Python-3-compatible, so due for removal
The Wanderer writes: > retitle -1 moosic: new upstream version works with Python 3 > thanks > > > I've decided it's worth the effort to become the new upstream for this, > and confirmed with the original author that he has no objections, as he > is no longer spending any time maintaining it. > > Version 1.5.7, based on Python 3 rather than Python 2, is now available > from: > > https://github.com/inverseparadox/moosic > > Please consider packaging this version, if possible in time to meet the > release freeze. > > I have a private branch which includes a debian/ directory, and I have > successfully built a Debian package from that branch which depends on > Python 3 and appears to work. However, my ability to test such a thing > in my available environments is limited, and I don't at all trust that > I've gotten the packaging updates correct; all else being equal, I would > prefer to rely on the existing Debian maintainer for that work. > > Please let me know if there's anything I can do to help move this > forward. You've done the big part of the work already. I'll try to take care of updating the package as soon as I can, but due to commitments related to the holiday season that will probably take a week or so. That should still give us barely enough time before the freeze. Thanks a lot for the work you did here. -- Arto Jantunen
Bug#970282: O: python-inflect -- Generate plurals, singular nouns, ordinals, indefinite articles
"Iain R. Learmonth" writes: > Package: wnpp > Severity: normal > X-Debbugs-Cc: debian-pyt...@lists.debian.org > > I intend to orphan the python-inflect package. This would be a good > candidate for the Python team. It has reverse dependencies in Debian: > python3-jaraco.itertools and sqlacodegen. > > The package description is: > The inflect Python module correctly generates plurals, singular nouns, > ordinals and indefinite articles. It can also convert numbers to words. Agreed, this should be transferred to the Python team. I can be an uploader for it (I already maintain sqlacodegen, even though it appears to have been abandoned upstream). -- Arto Jantunen
Bug#960744: ITP: python-aioinflux -- Asynchronous Python client for InfluxDB
Package: wnpp Severity: wishlist Owner: Arto Jantunen * Package name: python-aioinflux Version : 0.9.0 Upstream Author : Gustavo Bezerra * URL : https://github.com/gusutabopb/aioinflux * License : MIT Programming Lang: Python Description : Asynchronous Python client for InfluxDB Asynchronous Python client for InfluxDB. Built on top of aiohttp and asyncio. Aioinflux is an alternative to the official InfluxDB Python client. . Aioinflux supports interacting with InfluxDB in a non-blocking way by using aiohttp. It also supports writing and querying of Pandas dataframes, among other handy functionality. I will maintain this under the DPMT.
Bug#945204: Incorrect unversioned dependency on libxmlb1
Package: fwupd Version: 1.3.3-3 Severity: serious The unversioned dependency on libxmlb1 is incorrect. On a partially upgraded system it reports this at startup (all dependencies are satisfied): fwupdmgr: /lib/x86_64-linux-gnu/libxmlb.so.1: version `LIBXMLB_0.1.7' not found (required by fwupdmgr) fwupdmgr: /lib/x86_64-linux-gnu/libxmlb.so.1: version `LIBXMLB_0.1.13' not found (required by fwupdmgr) This may also be a bug in libxmlb, depending on how the dependency is being generated. I did not check, please reassign if needed. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwupd depends on: ii libarchive13 3.3.3-4+deb10u1 ii libc6 2.29-2 ii libefiboot137-2 ii libefivar1 37-2 ii libelf10.176-1.1 ii libfwupd2 1.3.3-3 ii libgcab-1.0-0 1.2-3~deb10u1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgnutls303.6.7-4 ii libgpg-error0 1.35-1 ii libgpgme11 1.12.0-6 ii libgudev-1.0-0 232-2 ii libgusb2 0.3.0-1 ii libjson-glib-1.0-0 1.4.4-2 ii libpolkit-gobject-1-0 0.105-25 ii libsmbios-c2 2.4.1-1 ii libsoup2.4-1 2.64.2-2 ii libsqlite3-0 3.29.0-2 ii libtss2-esys0 2.1.0-4 ii libxmlb1 0.1.6-2 ii shared-mime-info 1.10-1 Versions of packages fwupd recommends: pn bolt pn fwupd-signed ii python3 3.7.3-1 fwupd suggests no packages. -- no debconf information
Bug#940813: firmware-iwlwifi: iwlwifi-9000-pu-b0-jf-b0-46.ucode is broken
] ieee80211_do_open+0x17b/0x8c0 [mac80211] __dev_open+0xcd/0x160 __dev_change_flags+0x1ad/0x220 dev_change_flags+0x21/0x60 do_setlink+0x322/0xe90 ? generic_make_request_checks+0x221/0x630 ? cpumask_next+0x16/0x20 ? __snmp6_fill_stats64.isra.57+0x6b/0x110 ? __nla_validate_parse+0x51/0x850 __rtnl_newlink+0x53d/0x8a0 ? __nla_reserve+0x38/0x50 ? __nla_put+0xc/0x20 ? pskb_expand_head+0x74/0x2d0 ? __update_load_avg_se+0x1f6/0x2a0 ? update_load_avg+0x7e/0x550 ? account_entity_enqueue+0xc5/0xf0 ? __wake_up_common+0x130/0x190 ? _cond_resched+0x15/0x30 ? kmem_cache_alloc_trace+0x147/0x1c0 rtnl_newlink+0x43/0x60 rtnetlink_rcv_msg+0x2b1/0x360 ? __wake_up_common+0x7a/0x190 ? _cond_resched+0x15/0x30 ? rtnl_calcit.isra.31+0x110/0x110 netlink_rcv_skb+0x49/0x110 netlink_unicast+0x17e/0x200 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 ___sys_sendmsg+0x29f/0x300 ? try_to_wake_up+0x54/0x5d0 ? touch_atime+0x33/0xe0 ? wake_up_q+0x80/0x80 ? __wake_up_common+0x7a/0x190 __sys_sendmsg+0x57/0xa0 do_syscall_64+0x53/0x130 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f03bf207467 Code: 44 00 00 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 3b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 4 RSP: 002b:7ffd7818a930 EFLAGS: 0293 ORIG_RAX: 002e RAX: ffda RBX: 0008 RCX: 7f03bf207467 RDX: RSI: 7ffd7818a980 RDI: 0008 RBP: 7ffd7818a980 R08: R09: R10: 5623f57a4010 R11: 0293 R12: R13: R14: 7ffd7818ab38 R15: 7ffd7818ab2c iwlwifi :00:14.3: Firmware not running - cannot dump error -- Arto Jantunen
Bug#914253: ITP: python-sqlalchemy-migrate -- Database schema migration for SQLAlchemy
Per Andersson writes: > Package: wnpp > Severity: wishlist > Owner: Per Andersson > > * Package name: python-sqlalchemy-migrate > Version : 0.11.0 > Upstream Author : OpenStack > * URL : https://pypi.org/project/sqlalchemy-migrate/ > * License : MIT/Expat > Programming Lang: Python > Description : Database schema migration for SQLAlchemy > > Inspired by Ruby on Rails’ migrations, Migrate provides a way to deal > with database schema changes in SQLAlchemy projects. > > Migrate extends SQLAlchemy to have database changeset handling. It > provides a database change repository mechanism which can be used from > the command line as well as from inside python code. > > This is required for new versions of pytrainer. > > I plan to maintain this in the Python Modules Team. > This is already packaged as python-migrate by the Openstack team. It might be a different upstream fork, though. -- Arto Jantunen
Bug#912841: RM: memcachedb -- ROM; Unmaintained upstream
Package: ftp.debian.org Severity: normal Please remove the memcachedb package from the archive before the buster release. It has been unmaintained upstream for many years, and as a network daemon it has security implications that I cannot fully address on my own. -- Arto Jantunen
Bug#894773: Storing non-ascii values in memcache fails on Python 2
Package: python-memcache Version: 1.57-2 Severity: important Forwarded: https://github.com/linsomniac/python-memcached/issues/79 Tags: upstream, fixed-upstream Stored Unicode objects are returned as encoded strings from the cache. Please update to version 1.59 to fix this and make the package usable on Python 2 again. The bug was introduced in upstream version 1.56. -- Arto Jantunen
Bug#885635: QScintilla2 Transition Started
Scott Kitterman writes: > In the interests of moving the transition along, not having heard back, I'm > preparing an NMU and plan to upload shortly. Thanks for the NMU, I've had a busy week.. -- Arto Jantunen
Bug#880882: RFA: bcfg2 -- Configuration management system
Package: wnpp Severity: normal I request an adopter for the bcfg2 package. Upstream development has slowed down, and keeping up with django and it's endless deprecations and changes is proving to be difficult. I'm also no longer a user of bcfg2, and have limited time available to work on it.
Bug#868644: python-inflect: NMU to fix 867438
"Iain R. Learmonth" writes: > On 07/17/2017 07:00 AM, Arto Jantunen wrote: >> I have uploaded an NMU to fix #867438 to delayed/5, hopefully to keep >> both this package and sqlacodegen from being removed from >> testing. Trivial NMU diff attached. > > Thanks for this. It was on my todo list for today but I hadn't quite got to > it, if you wish you may upload this directly to unstable. No problem, in that case I rescheduled it to go in today. -- Arto Jantunen
Bug#868644: python-inflect: NMU to fix 867438
Source: python-inflect
Version: 0.2.5-1
Severity: normal
I have uploaded an NMU to fix #867438 to delayed/5, hopefully to keep
both this package and sqlacodegen from being removed from
testing. Trivial NMU diff attached.
diff --git a/debian/changelog b/debian/changelog
index fe54ae1bca06..c44f6c608e49 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+python-inflect (0.2.5-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Apply patch from Adrian Bunk to correctly generate dependencies for
+the python 3 package (Closes: #867438)
+
+ -- Arto Jantunen Mon, 17 Jul 2017 08:47:48 +0300
+
python-inflect (0.2.5-1) unstable; urgency=medium
* Initial release. (Closes: #806450)
diff --git a/debian/control b/debian/control
index 87a10c3fb877..90e85decdef9 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Description: Generate plurals, singular nouns, ordinals, indefinite articles
Package: python3-inflect
Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${python3:Depends}, ${misc:Depends}
Description: Generate plurals, singular nouns, ordinals, indefinite articles (Python 3)
The inflect Python module correctly generates plurals, singular nouns,
ordinals and indefinite articles. It can also convert numbers to words.
--
Arto Jantunen
Bug#867249: systemd: Boot hangs if /home is an automounted NFS share
Package: systemd Version: 232-25 Severity: important If /home is configured to automount a network fs boot hangs while waiting for systemd-tmpfiles-setup. There appears to be a missing dependency and/or dependency loop here, the automount is enabled before the network and the NFS client are up and systemd-tmpfiles-setup tries to access /home and waits forever for it to be mounted. The workaround is to disable /usr/lib/tmpfiles.d/home.conf. Please see https://bugzilla.redhat.com/show_bug.cgi?id=1414804 for a Redhat bug report about the same issue. -- Arto Jantunen
Bug#866814: RFA: memcachedb -- Persistent storage engine using the memcache protocol
Package: wnpp Severity: normal I request an adopter for the memcachedb package. It hasn't been maintained upstream for a long time now, so could use a lot of work. Unless someone wants to continue maintaining this the package should probably be removed. The package description is: Memcachedb is a distributed key-value storage system designed for persistent data. It is NOT a cache solution, but a persistent storage engine for fast and reliable key-value based object storage and retrieval. . It conforms to the memcache protocol, so any memcached client can have connectivity with it. Memcachedb uses Berkeley DB as a storing backend, so lots of features including transactions and replication are available.
Bug#853016: even stops apt
Control: severity -1 important 積丹尼 Dan Jacobson writes: > severity 853016 grave > thanks > In fact, you terminate the window the aptitude upgrade was running. > The next time the user runs apt/aptitude, he will be met with > E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to > correct the problem. > W: Could not lock the cache file; this usually means that dpkg or another apt > tool is already installing packages. Opening in read-only mode; any changes > you make to the states of packages will NOT be preserved! > E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to > correct the problem. This is documented behaviour and thus not RC, please see the release notes: "You should not upgrade using telnet, rlogin, rsh, or from an X session managed by xdm, gdm or kdm etc. on the machine you are upgrading. That is because each of those services may well be terminated during the upgrade, which can result in an inaccessible system that is only half-upgraded." The package has logic to not restart nodm if the user is logged in (I think this was copied from gdm3): if [ "$1" = "remove" ]; then if [ -x /etc/init.d/nodm ]; then nostop= for hostname in "" "localhost" "$(hostname)" "$(hostname -f)"; do if echo $DISPLAY | grep -q "^$hostname:0.*"; then nostop=yes fi done if [ -z $nostop ]; then invoke-rc.d nodm stop fi fi fi It seems that this didn't work for you for one reason or the other. I'll look into this. -- Arto Jantunen
Bug#796203: NMU
Control: tags -1 + pending Dear maintainer, I've prepared an NMU for nodm (versioned as 0.12-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- Arto Jantunen diff -Nru nodm-0.12/debian/changelog nodm-0.12/debian/changelog --- nodm-0.12/debian/changelog 2016-03-23 17:13:51.0 +0200 +++ nodm-0.12/debian/changelog 2017-01-18 17:29:22.0 +0200 @@ -1,3 +1,11 @@ +nodm (0.12-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Apply patches from Simon McVittie to add a native systemd service +file (Closes: #796203). + + -- Arto Jantunen Wed, 18 Jan 2017 17:29:22 +0200 + nodm (0.12-1) unstable; urgency=low [ Enrico Zini ] diff -Nru nodm-0.12/debian/copyright nodm-0.12/debian/copyright --- nodm-0.12/debian/copyright 2016-03-23 16:54:40.0 +0200 +++ nodm-0.12/debian/copyright 2017-01-18 17:29:22.0 +0200 @@ -63,6 +63,17 @@ 2016, Mike Gabriel License: GPL-2+ +Files: + debian/nodm.config + debian/nodm.postinst + debian/nodm.prerm +Copyright: + 2000-2001, Branden Robinson + 2008, Joachim Breitner + 2009-2011, Enrico Zini + 2016, Mike Gabriel +License: GPL-2 + License: GPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -81,3 +92,7 @@ On Debian systems, the full text of the GNU General Public License version 2 can be found in the file `/usr/share/common-licenses/GPL-2'. + +License: GPL-2 + Licensed under the GNU General Public License, version 2. See the file + /usr/share/common-licenses/GPL-2 or <http://www.gnu.org/copyleft/gpl.txt>. diff -Nru nodm-0.12/debian/nodm.config nodm-0.12/debian/nodm.config --- nodm-0.12/debian/nodm.config 2016-03-23 16:54:40.0 +0200 +++ nodm-0.12/debian/nodm.config 2017-01-18 17:29:22.0 +0200 @@ -1,9 +1,45 @@ #!/bin/sh +# Partially based on gdm3.config, © 2000-2001 Branden Robinson. +# Licensed under the GNU General Public License, version 2. See the file +# /usr/share/common-licenses/GPL-2 or <http://www.gnu.org/copyleft/gpl.txt>. + + set -e . /usr/share/debconf/confmodule +THIS_PACKAGE=nodm +DEFAULT_DISPLAY_MANAGER_FILE=/etc/X11/default-display-manager + +# set default display manager + +db_get shared/default-x-display-manager +OLD_DEFAULT="$RET" + +db_metaget shared/default-x-display-manager owners +OWNERS="$RET" +db_metaget shared/default-x-display-manager choices +CHOICES="$RET" + +if [ "$OWNERS" != "$CHOICES" ]; then + db_subst shared/default-x-display-manager choices $OWNERS + db_fset shared/default-x-display-manager seen false +fi + +db_input high shared/default-x-display-manager || true +db_go + +# using this display manager? +db_get shared/default-x-display-manager +CURRENT_DEFAULT="$RET" +# set a flag to indicate to postinst that we need to update from debconf +if [ "$OLD_DEFAULT" != "$CURRENT_DEFAULT" ]; then + DEFAULT_DISPLAY_MANAGER_DIR=$(dirname $DEFAULT_DISPLAY_MANAGER_FILE) + test -e $DEFAULT_DISPLAY_MANAGER_DIR || mkdir -p $DEFAULT_DISPLAY_MANAGER_DIR + touch $DEFAULT_DISPLAY_MANAGER_FILE.debconf-update +fi + if [ -s /etc/default/nodm ] ; then . /etc/default/nodm diff -Nru nodm-0.12/debian/nodm.init nodm-0.12/debian/nodm.init --- nodm-0.12/debian/nodm.init 2016-03-23 16:54:40.0 +0200 +++ nodm-0.12/debian/nodm.init 2017-01-18 17:29:22.0 +0200 @@ -1,7 +1,7 @@ #!/bin/sh ### BEGIN INIT INFO # Provides: nodm -# Should-Start: console-screen kbd hal bluetooth +# Should-Start: bluetooth # Required-Start: $remote_fs # Required-Stop: # Default-Start: 2 3 4 5 diff -Nru nodm-0.12/debian/nodm.postinst nodm-0.12/debian/nodm.postinst --- nodm-0.12/debian/nodm.postinst 2016-03-23 16:54:40.0 +0200 +++ nodm-0.12/debian/nodm.postinst 2017-01-18 17:29:22.0 +0200 @@ -1,10 +1,49 @@ #! /bin/sh -# postinst script for nodm +# postinst script for nodm, partially based on gdm3.postinst set -e +THIS_PACKAGE=nodm +DEFAULT_DISPLAY_MANAGER_FILE=/etc/X11/default-display-manager + . /usr/share/debconf/confmodule +# debconf is not a registry, so we only fiddle with the default file if +# the configure script requested an update +if [ -e $DEFAULT_DISPLAY_MANAGER_FILE.debconf-update ]; then + rm -f $DEFAULT_DISPLAY_MANAGER_FILE.debconf-update + if db_get shared/default-x-display-manager; then +# workaround debconf passthru bug (#379198) +if [ -z "$RET" ]; then + RET="$THIS_PACKAGE" +fi +if [ "$THIS_PACKAGE" != "$RET" ]; then + echo "Please be sure to run \"dpkg --configure $RET\"." +fi +if db_get "$RET"/daemon_name; then + echo "$RET" > $DEFAULT_DISPLAY_MANAGER_FILE +fi + fi +fi + +DEFAULT_SERVICE=/etc/systemd/system/display-manager.service +#
Bug#851511: Fails to install with emacs24
Package: elpa-magit Version: 2.10.0-1 Severity: important I have both emacs25 and emacs24 installed, elpa-magit fails to compile for emacs24 (version 24.5+1-7.1+b1): Setting up elpa-magit (2.10.0-1) ... tsort: -: input contains a loop: tsort: dash-el tsort: emacsen-common tsort: -: input contains a loop: tsort: elpa-git-commit tsort: emacsen-common tsort: elpa-with-editor tsort: -: input contains a loop: tsort: elpa-git-commit tsort: emacsen-common tsort: -: input contains a loop: tsort: emacsen-common tsort: elpa-magit-popup tsort: -: input contains a loop: tsort: elpa-with-editor tsort: emacsen-common Install dash-el for emacs24 install/dash-el: Handling install for emacsen flavor emacs24 Loading 00debian-vars... Loading /etc/emacs/site-start.d/20apel.el (source)... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50dash-el.el (source)... Loading /etc/emacs/site-start.d/50devscripts-el.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Info: Skip debian-el loading if run under dpkg control. Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)... Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)... Loading /etc/emacs/site-start.d/50pylint.el (source)... Loading /etc/emacs/site-start.d/50python-docutils.el (source)... Loading /etc/emacs/site-start.d/50w3m-el.el (source)... Loading /etc/emacs/site-start.d/50yaml-mode.el (source)... Loading /etc/emacs/site-start.d/51debian-el.el (source)... Wrote /usr/share/emacs24/site-lisp/dash-el/dash-functional.elc Wrote /usr/share/emacs24/site-lisp/dash-el/dash.elc Install dash-el for emacs25 install/dash-el: Handling install for emacsen flavor emacs25 Loading 00debian-vars... Loading /etc/emacs/site-start.d/20apel.el (source)... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50dash-el.el (source)... Loading /etc/emacs/site-start.d/50devscripts-el.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Info: Skip debian-el loading if run under dpkg control. Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)... Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)... Loading /etc/emacs/site-start.d/50pylint.el (source)... Loading /etc/emacs/site-start.d/50python-docutils.el (source)... Loading /etc/emacs/site-start.d/50w3m-el.el (source)... Loading /etc/emacs/site-start.d/50yaml-mode.el (source)... Loading /etc/emacs/site-start.d/51debian-el.el (source)... Install elpa-git-commit for emacs24 install/git-commit-2.10.0: Handling install of emacsen flavor emacs24 install/git-commit-2.10.0: byte-compiling for emacs24 Install elpa-git-commit for emacs25 install/git-commit-2.10.0: Handling install of emacsen flavor emacs25 install/git-commit-2.10.0: byte-compiling for emacs25 Install elpa-with-editor for emacs24 install/with-editor-2.5.1: Handling install of emacsen flavor emacs24 install/with-editor-2.5.1: byte-compiling for emacs24 Install elpa-with-editor for emacs25 install/with-editor-2.5.1: Handling install of emacsen flavor emacs25 install/with-editor-2.5.1: byte-compiling for emacs25 Install emacsen-common for emacs24 emacsen-common: Handling install of emacsen flavor emacs24 Wrote /etc/emacs24/site-start.d/00debian-vars.elc Wrote /usr/share/emacs24/site-lisp/debian-startup.elc Install emacsen-common for emacs25 emacsen-common: Handling install of emacsen flavor emacs25 Install elpa-magit-popup for emacs24 install/magit-popup-2.10.0: Handling install of emacsen flavor emacs24 install/magit-popup-2.10.0: byte-compiling for emacs24 Install elpa-magit-popup for emacs25 install/magit-popup-2.10.0: Handling install of emacsen flavor emacs25 install/magit-popup-2.10.0: byte-compiling for emacs25 Install elpa-magit for emacs24 install/magit-2.10.0: Handling install of emacsen flavor emacs24 install/magit-2.10.0: byte-compiling for emacs24 Loading 00debian-vars... Loading /etc/emacs/site-start.d/20apel.el (source)... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50dash-el.el (source)... Loading /etc/emacs/site-start.d/50devscripts-el.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Info: Skip debian-el loading if run under dpkg control. Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)... Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)... Loading /etc/emacs/site-start.d/50pylint.el (source)... Loading /etc/emacs/site-start.d/50python-docutils.el (source)... Loading /etc/emacs/site-start.d/50w3m-el.el (source)... Loading /etc/emacs/site-start.d/50yaml-mode.el (source)... Loading /etc/emacs/site-start.d/51debian-el.el (source)... In toplevel form: git-rebase.el:72:1:Error: Cannot open load file: no such file or directory, magit-repos Wrote /usr/share/emacs24/site-lisp/elpa/magit-2.10.0/magit-apply.elc Wrote /usr/share/emacs24/site-lisp/elpa/magit-2.10.0/magit-autorevert.elc In toplevel form: magit-b
Bug#811986: qwtplot3d: diff for NMU version 0.2.7+svn191-10.1
Graham Inggs writes: > Hi Arto > > On 23 December 2016 at 14:59, Arto Jantunen wrote: >> I've prepared an NMU for qwtplot3d (versioned as 0.2.7+svn191-10.1) and >> uploaded it to DELAYED/5. Please feel free to tell me if I >> should delay it longer. > > Thanks for the upload. I'm not the maintainer, but I suggest you > remove the delay otherwise qwtplot3d won't migrate to testing before > the freeze. > > BTW, the bug was RC and there had been no maintainer activity for more > than 7 days, so I think a DELAYED/0 would have been appropriate. Indeed you are right, I misjudged my timing. I have rescheduled this upload to go through now. The point of course was to get this package (and goldencheetah) into stretch. Thanks for the heads up. -- Arto Jantunen
Bug#811986: qwtplot3d: diff for NMU version 0.2.7+svn191-10.1
Control: tags 811986 + pending Dear maintainer, I've prepared an NMU for qwtplot3d (versioned as 0.2.7+svn191-10.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- Arto Jantunen diff --git a/debian/changelog b/debian/changelog index 2307d95a8148..78897e5515e0 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +qwtplot3d (0.2.7+svn191-10.1) unstable; urgency=low + + * Non-maintainer upload. + * Apply patch from Graham Inggs to update symbols +for gcc 6 (Closes: #811986) + + -- Arto Jantunen Fri, 23 Dec 2016 14:26:35 +0200 + qwtplot3d (0.2.7+svn191-10) unstable; urgency=medium * Disable qt5 library on architectures armel and armhf. diff --git a/debian/libqwtplot3d-qt4-0v5.symbols b/debian/libqwtplot3d-qt4-0v5.symbols index c45435b68e59..bc8ac0b53ff2 100644 --- a/debian/libqwtplot3d-qt4-0v5.symbols +++ b/debian/libqwtplot3d-qt4-0v5.symbols @@ -243,10 +243,10 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER# _ZN5Qwt3D4Axis9setMajorsEi@Base 0.2.7 _ZN5Qwt3D4Axis9setMinorsEi@Base 0.2.7 _ZN5Qwt3D4AxisC1ENS_6TripleES1_@Base 0.2.7 - _ZN5Qwt3D4AxisC1ERKS0_@Base 0.2.7 + (optional=templinst)_ZN5Qwt3D4AxisC1ERKS0_@Base 0.2.7 _ZN5Qwt3D4AxisC1Ev@Base 0.2.7 _ZN5Qwt3D4AxisC2ENS_6TripleES1_@Base 0.2.7 - _ZN5Qwt3D4AxisC2ERKS0_@Base 0.2.7 + (optional=templinst)_ZN5Qwt3D4AxisC2ERKS0_@Base 0.2.7 _ZN5Qwt3D4AxisC2Ev@Base 0.2.7 _ZN5Qwt3D4AxisD0Ev@Base 0.2.7 _ZN5Qwt3D4AxisD1Ev@Base 0.2.7 @@ -268,7 +268,7 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER# _ZN5Qwt3D5ArrowD0Ev@Base 0.2.7 _ZN5Qwt3D5ArrowD1Ev@Base 0.2.7 _ZN5Qwt3D5ArrowD2Ev@Base 0.2.7 - _ZN5Qwt3D5Color12createVectorERSt6vectorINS_4RGBAESaIS2_EE@Base 0.2.7 + (optional=templinst)_ZN5Qwt3D5Color12createVectorERSt6vectorINS_4RGBAESaIS2_EE@Base 0.2.7 _ZN5Qwt3D5GL2QtEddd@Base 0.2.7 _ZN5Qwt3D5Label11setPositionENS_6TripleENS_6ANCHORE@Base 0.2.7 _ZN5Qwt3D5Label12devicefonts_E@Base 0.2.7 @@ -380,9 +380,9 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER# _ZN5Qwt3D6Plot3DD0Ev@Base 0.2.7 _ZN5Qwt3D6Plot3DD1Ev@Base 0.2.7 _ZN5Qwt3D6Plot3DD2Ev@Base 0.2.7 - _ZN5Qwt3D7MappingD0Ev@Base 0.2.7 - _ZN5Qwt3D7MappingD1Ev@Base 0.2.7 - _ZN5Qwt3D7MappingD2Ev@Base 0.2.7 + (optional=templinst)_ZN5Qwt3D7MappingD0Ev@Base 0.2.7 + (optional=templinst)_ZN5Qwt3D7MappingD1Ev@Base 0.2.7 + (optional=templinst)_ZN5Qwt3D7MappingD2Ev@Base 0.2.7 _ZN5Qwt3D8CellData5clearEv@Base 0.2.7 _ZN5Qwt3D8CellDataD0Ev@Base 0.2.7 _ZN5Qwt3D8CellDataD1Ev@Base 0.2.7 @@ -475,6 +475,7 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER# _ZNK5Qwt3D8LogScale8ticLabelEj@Base 0.2.7 _ZNK5Qwt3D9CrossHair5cloneEv@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS2_S4_EERKS2_@Base 0.2.7 + (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EE19_M_emplace_back_auxIJRKS2_EEEvDpOT_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EED1Ev@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D2IO5EntryESaIS2_EED2Ev@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D4AxisESaIS1_EED1Ev@Base 0.2.7 @@ -482,11 +483,14 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER# (optional=templinst)_ZNSt6vectorIN5Qwt3D4AxisESaIS1_EEaSERKS3_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D4RGBAESaIS1_EEaSERKS3_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPS1_S3_EEmRKS1_@Base 0.2.7 + (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EE17_M_default_appendEm@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EED1Ev@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EED2Ev@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D5LabelESaIS1_EEaSERKS3_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D6Plot3D5LightESaIS2_EEaSERKS4_@Base 0.2.7 + (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE12emplace_backIJS1_EEEvDpOT_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base 0.2.7 + (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EE19_M_emplace_back_auxIJS1_EEEvDpOT_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIN5Qwt3D6TripleESaIS1_EEaSERKS3_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIPdSaIS0_EEaSERKS2_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIS_IPdSaIS0_EESaIS2_EED1Ev@Base 0.2.7 @@ -496,9 +500,12 @@ libqwtplot3d-qt4.so.0 libqwtplot3d-qt4-0v5 #MINVER# (optional=templinst)_ZNSt6vectorIS_IjSaIjEESaIS1_EED2Ev@Base 0.2.7 (optional=templinst)_ZNSt6vectorIS_IjSaIjEESaIS1_EEaSERKS3_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIdSaIdEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPdS1_EERKd@Base 0.2.7 + (optional=templinst)_ZNSt6vectorIdSaIdEE19_M_emplace_back_auxIJRKdEEEvDpOT_@Base 0.2.7 (optional=templinst)_ZNSt6vectorIdSaIdEEaSERKS1_@Base 0.2.7 (optional=temp
Bug#833477: Remove forwarding and upstream relevant tags
Control: notforwarded -1 Control: tags -1 - upstream - wontfix Since this issue will not be fixed upstream it would seem that the next step is to fix it for the Debian package by disabling the built in media router as shown in the patch. -- Arto Jantunen
Bug#837071: vmdebootstrap: Customize option does not follow documentation
Package: vmdebootstrap Version: 0.5-2 Severity: normal The man-page documents the customize option as follows: --customize=SCRIPT run SCRIPT after setting up system. If the script does not exist in the current working directory, /usr/share/vmdeboot‐ strap/examples/ will be checked as a fallback. The script needs to be executable and is passed the root directory of the debootstrap as the only argument. Use chroot if you need to execute binaries within the debootstrap. Actually the script must always be provided with a fully qualified path for the tool to pick it up, neither the current working directory nor /usr/share/vmdebootstrap/examples is used. The same issue applies for version 1.4 which is in backporst. I did not test 1.6 from unstable/testing. -- Arto Jantunen
Bug#816387: qwtplot3d FTBFS on armel and armhf
from ../include/qwt3d_openglhelper.h:8, from ../include/qwt3d_types.h:26, from ../include/qwt3d_drawable.h:7, from ../include/qwt3d_label.h:10, from ../include/qwt3d_axis.h:5, from ../include/qwt3d_coordsys.h:4, from ../src/qwt3d_coordsys.cpp:1: /usr/include/GLES3/gl3.h:70:26: note: previous declaration as 'typedef khronos_intptr_t GLintptr' typedef khronos_intptr_t GLintptr; ^ make[2]: *** [tmp/qwt3d_color.o] Error 1 Makefile:516: recipe for target 'tmp/qwt3d_color.o' failed In file included from /usr/include/GL/gl.h:2055:0, from /usr/include/GL/glu.h:38, from ../include/qwt3d_openglhelper.h:10, from ../include/qwt3d_types.h:26, from ../include/qwt3d_drawable.h:7, from ../src/qwt3d_drawable.cpp:1: /usr/include/GL/glext.h:468:19: error: conflicting declaration 'typedef ptrdiff_t GLsizeiptr' typedef ptrdiff_t GLsizeiptr; ^ In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:97:0, from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:39, from ../include/qwt3d_openglhelper.h:8, from ../include/qwt3d_types.h:26, from ../include/qwt3d_drawable.h:7, from ../src/qwt3d_drawable.cpp:1: /usr/include/GLES3/gl3.h:69:25: note: previous declaration as 'typedef khronos_ssize_t GLsizeiptr' typedef khronos_ssize_t GLsizeiptr; ^ In file included from /usr/include/GL/gl.h:2055:0, from /usr/include/GL/glu.h:38, from ../include/qwt3d_openglhelper.h:10, from ../include/qwt3d_types.h:26, from ../include/qwt3d_drawable.h:7, from ../src/qwt3d_drawable.cpp:1: /usr/include/GL/glext.h:469:19: error: conflicting declaration 'typedef ptrdiff_t GLintptr' typedef ptrdiff_t GLintptr; ^ In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:97:0, from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:39, from ../include/qwt3d_openglhelper.h:8, from ../include/qwt3d_types.h:26, from ../include/qwt3d_drawable.h:7, from ../src/qwt3d_drawable.cpp:1: /usr/include/GLES3/gl3.h:70:26: note: previous declaration as 'typedef khronos_intptr_t GLintptr' typedef khronos_intptr_t GLintptr; ^ -- Arto Jantunen
Bug#816374: apt-transport-tor: Please recommend tor instead of depending on it
Package: apt-transport-tor Version: 0.2.1-1 Severity: wishlist Depending on tor is harmful for example in chrooted installations (the host system already has tor), and there is no actual dependency between the packages (apt-transport-tor accesses tor over the network, tor could in my understanding be installed on a different machine just as well). Recommends is pretty much meant for this case, please use it instead. -- Arto Jantunen
Bug#801441: jessie-pu: package bcfg2/1.3.5-1
"Adam D. Barratt" writes: > On Sat, 2015-10-31 at 14:47 +0200, Arto Jantunen wrote: >> A new debdiff (with the migrations installed, and a proper changelog >> generated) is attached. > > After a fair amount of patch wrangling (and some wondering why it took > until a few months after the Jessie release for this to get raised), I > think this looks reasonable enough. Please go ahead; apologies for the > delays. The issue itself was known for some time before the jessie release, sadly the fix took a very long time to materialise. Upstream has still not released a Django 1.7 compatible version, and now we should be porting to 1.8 which is again different for the database layer. I'm rather annoyed about this whole mess myself, and have been pushing you pretty hard at times. My apologies for both missing the release originally, and hounding you about this later on. I have uploaded the package that was used to generate the latest debdiff in this bug report. -- Arto Jantunen
Bug#806439: ITP: sqlacodegen
"Iain R. Learmonth" writes: > Hi, > > I notice you have an ITP here, I was just about to package this. > > If you can reply in the next hour or so and say it's cool, I can package > this today. I'm happy to co-maintain it with you, I'd just like to get this > in Debian for helping with SQLAlchemy bindings for UDD. I've had the packaging done for a while now, I was waiting to see if someone else would be interested in packaging and maintaining the inflect library, which I have no real interest in. Thanks for taking care of that. I'll try to upload the package soon after inflect gets accepted (the 'try' mainly having to do with the usual holiday scheduling things). Is your inflect package available for download somewhere, I could test against it and have final binaries ready and waiting for the NEW accept? -- Arto Jantunen
Bug#801441: Upcoming stable point release (8.3)
"Adam D. Barratt" writes: > On 2015-12-18 8:20, Arto Jantunen wrote: >> "Adam D. Barratt" writes: >> >>> Hi, >>> >>> The next point release for "jessie" (8.3) is scheduled for Saturday, >>> January 23rd. Processing of new uploads into jessie-proposed-updates >>> will be frozen during the preceding weekend. >> >> Has the deadline already been missed for reviewing #801441? > > The only deadline that exists is the one mentioned in the quote you > included. So I can expect a review (from you?) and possible ack before that deadline? -- Arto Jantunen
Bug#801441: Upcoming stable point release (8.3)
"Adam D. Barratt" writes: > Hi, > > The next point release for "jessie" (8.3) is scheduled for Saturday, > January 23rd. Processing of new uploads into jessie-proposed-updates > will be frozen during the preceding weekend. Has the deadline already been missed for reviewing #801441? -- Arto Jantunen
Bug#807157: Mock fails to import
Package: python-mock Version: 1.3.0-2.1 Severity: grave Trying to import mock returns the following traceback: >>> import mock Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/mock/__init__.py", line 2, in import mock.mock as _mock File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 69, in from pbr.version import VersionInfo File "/usr/lib/python2.7/dist-packages/pbr/version.py", line 25, in import pkg_resources File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 90, in packaging = pkg_resources._vendor.packaging AttributeError: 'module' object has no attribute '_vendor' -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.6 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-mock depends on: ii python-funcsigs 0.4-2 ii python-pbr 1.8.0-4 ii python-six 1.10.0-1 pn python:any python-mock recommends no packages. Versions of packages python-mock suggests: pn python-mock-doc -- no debconf information
Bug#806450: RFP: python-inflect -- Python library for correctly generating plurals, singular nouns, ordinals, indefinite articles; convert numbers to words
Package: wnpp Severity: wishlist * Package name: python-inflect Version : 0.2.5 Upstream Author : Paul Dyson * URL : http://pypi.python.org/pypi/inflect * License : AGPLv3 Programming Lang: Python Description : Python library for correctly generating plurals, singular nouns, ordinals, indefinite articles; convert numbers to words This is a dependency of sqlacodegen.
Bug#806439: ITP: sqlacodegen -- Automatic model code generator for SQLAlchemy
Package: wnpp Severity: wishlist Owner: Arto Jantunen * Package name: sqlacodegen Version : 1.1.6 Upstream Author : Alex Grönholm * URL : https://pypi.python.org/pypi/sqlacodegen * License : MIT Programming Lang: Python Description : Automatic model code generator for SQLAlchemy This is a tool that reads the structure of an existing database and generates the appropriate SQLAlchemy model code, using the declarative style if possible.
Bug#771903: Reopen
Control: reopen -1 This bug definitely does exist in version 2.4.3-2, which is in stable. If it has been fixed in a later version you should close this bug mentioning the version where it was fixed. Closing without a version number means that the report is invalid, and that certainly is not the case here. -- Arto Jantunen
Bug#801441: jessie-pu: package bcfg2/1.3.5-1
"Adam D. Barratt" writes: >> > Shouldn't there be a corresponding set of files appearing in the second >> > package? (in /Reporting/south_migrations) >> >> I don't know the answer to that question, my understanding of Django is >> rather limited (which is also why I didn't write the patch to do >> this). The "initial migration" file grows quite a bit, so it's entirely >> possible that it ends up containing the relevant parts of those, but >> this is only a theory. > > My understanding of Django is likely less than yours, it just seems odd > to have the patch create the new files and then for them not to be > shipped. You were correct here, there was something missing from the patch. Even without the migrations in place an upgrade from the wheezy version did succeed when I tested it. Perhaps wheezy isn't old enough to need those. In any case I'll do a new upload to unstable with this fixed, I'll get back to you after that. -- Arto Jantunen
Bug#801441: jessie-pu: package bcfg2/1.3.5-1
"Adam D. Barratt" writes: >> Source debdiff is attached, > > How was that generated? It appears to be missing at least > debian/changelog. This was again generated by comparing 1.3.5-1 and 1.3.5-3, and the changelog was ignored on purpose since it will be different for an actual upload to stable. -- Arto Jantunen
Bug#801441: jessie-pu: package bcfg2/1.3.5-1
"Adam D. Barratt" writes: > On 2015-10-12 13:13, Arto Jantunen wrote: >> "Adam D. Barratt" writes: >> >>> Control: tags -1 + moreinfo >>> >>> On Sat, 2015-10-10 at 09:43 +0300, Arto Jantunen wrote: >>>> I would like to update bcfg2 in stable to match the version currently in >>>> testing to enable it to work with Django 1.7 (bug #755645). To do this I >>>> would >>>> add the attached patch, which looks much worse than it is due to the db >>>> migration files being moved around. >>> >>> That is rather noisy, yes. :-( >>> >>> Is there any chance we could have an interdiff of the before-and-after >>> patches, to highlight the actual differences between them? In any case >>> we'd need a full debdiff of a package built and tested on jessie before >>> giving a definite ack. >> >> The patch doesn't exist in jessie, so either interdiff isn't possible or >> I'm misunderstanding something. > > The latter, although possibly because I wasn't clear enough. > > The patch contains, for example: > > src/lib/Bcfg2/Reporting/migrations/0001_initial.py | 1006 > +++- > .../migrations/0002_convert_perms_to_mode.py | 171 > .../Reporting/south_migrations/0001_initial.py | 465 + > .../south_migrations/0002_convert_perms_to_mode.py | 171 > > What I was looking for was an indication of what the actual difference between > the two sets of files is, ignoring renames (e.g. are the two > 0002_convert_perms_to_mode.py files actually exactly the same?). All of those migration files are exactly the same after renaming from migrations to south_migrations. I assume the reason for the renaming to be changes made to the Django machinery that applies them. -- Arto Jantunen
Bug#801441: jessie-pu: package bcfg2/1.3.5-1
"Adam D. Barratt" writes:
> Control: tags -1 + moreinfo
>
> On Sat, 2015-10-10 at 09:43 +0300, Arto Jantunen wrote:
>> I would like to update bcfg2 in stable to match the version currently in
>> testing to enable it to work with Django 1.7 (bug #755645). To do this I
>> would
>> add the attached patch, which looks much worse than it is due to the db
>> migration files being moved around.
>
> That is rather noisy, yes. :-(
>
> Is there any chance we could have an interdiff of the before-and-after
> patches, to highlight the actual differences between them? In any case
> we'd need a full debdiff of a package built and tested on jessie before
> giving a definite ack.
The patch doesn't exist in jessie, so either interdiff isn't possible or
I'm misunderstanding something. The debdiff is attached (for convenience
built on jessie but without modifying the version number for a stable
update).
--
Arto Jantunen
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first set of .debs but not in second
-
-rw-r--r-- root/root
/usr/lib/python2.7/dist-packages/Bcfg2/Reporting/migrations/0002_convert_perms_to_mode.py
-rw-r--r-- root/root
/usr/lib/python2.7/dist-packages/Bcfg2/Reporting/migrations/0003_expand_hash_key.py
-rw-r--r-- root/root
/usr/lib/python2.7/dist-packages/Bcfg2/Reporting/migrations/0004_profile_can_be_null.py
-rw-r--r-- root/root
/usr/lib/python2.7/dist-packages/Bcfg2/Reporting/migrations/0005_add_selinux_entry_support.py
-rw-r--r-- root/root
/usr/lib/python2.7/dist-packages/Bcfg2/Reporting/migrations/0006_add_user_group_entry_support.py
Control files of package bcfg2: lines which differ (wdiff format)
-
Installed-Size: [-587-] {+683+}
Version: [-1.3.5-1-] {+1.3.5-3+}
Control files of package bcfg2-doc: lines which differ (wdiff format)
-
Installed-Size: [-9266-] {+9521+}
Version: [-1.3.5-1-] {+1.3.5-3+}
Control files of package bcfg2-server: lines which differ (wdiff format)
Depends: python (>= 2.7), python (<< 2.8), init-system-helpers (>= 1.18~),
python-lxml (>= 0.9), libxml2-utils (>= 2.6.23), lsb-base (>= 3.1-9), ucf,
bcfg2 (= [-1.3.5-1),-] {+1.3.5-3),+} openssl, python-pyinotify | python-gamin,
python-daemon
Installed-Size: [-1755-] {+1838+}
Suggests: python-cheetah, python-genshi (>= 0.4.4), python-profiler,
python-sqlalchemy (>= 0.5.0), python-django, mail-transport-agent, bcfg2-doc (=
[-1.3.5-1)-] {+1.3.5-3)+}
Version: [-1.3.5-1-] {+1.3.5-3+}
Control files of package bcfg2-web: lines which differ (wdiff format)
-
Depends: bcfg2-server (= [-1.3.5-1),-] {+1.3.5-3),+} python-django,
python-django-south (>= 0.7.5)
Installed-Size: [-105-] {+149+}
Version: [-1.3.5-1-] {+1.3.5-3+}
Bug#793281: sqlitebrowser: change of type in system_error might break with GCC-5
Control: block -1 by 793215 Matthias Klose writes: > GCC PR libstdc++/66145 is a regression in GCC 5 which won't be fixed > upstream in time for the GCC defaults change. The work around is to > rebuild the affected packages after GCC 5 is the default compiler. > Please look at the code and decide, if the package is affected. If > not, please just close the issue. If it's a real issue, I'll add > the packages affected to libstdc++6's Breaks attributes, with the > version of the package at the time of the defaults change. AFAICT sqlitebrowser inherits this issue from antlr, and thus that needs to be rebuilt before anything can be done for sqlitebrowser. Will libstdc++ generate tight enough dependencies to prevent partial upgrades, or would antlr need to do the Breaks dance with its rdeps? -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765509: current status/progress?
Johannes Schilling writes:
> any progress on this? i would be happy to see python-flask-admin
> packaged, and would be willing to do some work myself if necessary,
> but don't want to interfere with what you already got.
No, not really. This proved to be much more work than I had expected due
to the big pile of embedded minified javascript, and I ran out of time
before getting this into an uploadable state. Recently I was actually
considering marking this bug as an RFP instead. If you have the time to
work on this feel free to take over. I have attached a patch containing
my work in progress packaging.
--
Arto Jantunen
diff --git a/debian/changelog b/debian/changelog
new file mode 100644
index 000..17fa5fd
--- /dev/null
+++ b/debian/changelog
@@ -0,0 +1,6 @@
+flask-admin (1.0.9-1) unstable; urgency=low
+
+ * Initial release
+
+ -- Arto Jantunen Tue, 12 Aug 2014 15:37:50 +0300
+
diff --git a/debian/compat b/debian/compat
new file mode 100644
index 000..ec63514
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+9
diff --git a/debian/control b/debian/control
new file mode 100644
index 000..56fb522
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,74 @@
+Source: flask-admin
+Section: python
+Priority: optional
+Maintainer: Arto Jantunen
+Build-Depends: debhelper (>= 9), python-all (>= 2.6.6-3~), dh-python, python-setuptools, python3-all, python3-setuptools, python-sphinx (>= 1.0.7+dfsg-1~), python-nose, python-flask, python-wtforms, python-flask-sqlalchemy, python-pymongo
+Standards-Version: 3.9.2.0
+X-Python-Version: >= 2.5
+X-Python3-Version: >= 3.2
+
+Package: python-flask-admin
+Architecture: all
+Depends: ${python:Depends}, ${misc:Depends}, python-pkg-resources
+Suggests: python-flask-admin-doc
+Description: admin interface extension for Flask
+ Flask-Admin is a batteries-included, simple-to-use Flask extension that lets
+ you add admin interfaces to Flask applications. It is inspired by the
+ *django-admin* package, but implemented in such a way that the developer has
+ total control of the look, feel and functionality of the resulting
+ application.
+ .
+ Out-of-the-box, Flask-Admin plays nicely with various ORM's, including
+ .
+ - SQLAlchemy
+ - MongoEngine
+ - pymongo
+ - Peewee
+ .
+ It also boasts a simple file management interface and a redis client console.
+ .
+ This is the Python 2 version of the package.
+
+Package: python3-flask-admin
+Architecture: all
+Depends: ${python3:Depends}, ${misc:Depends}, python3-pkg-resources
+Suggests: python-flask-admin-doc
+Description: admin interface extension for Flask
+ Flask-Admin is a batteries-included, simple-to-use Flask extension that lets
+ you add admin interfaces to Flask applications. It is inspired by the
+ *django-admin* package, but implemented in such a way that the developer has
+ total control of the look, feel and functionality of the resulting
+ application.
+ .
+ Out-of-the-box, Flask-Admin plays nicely with various ORM's, including
+ .
+ - SQLAlchemy
+ - MongoEngine
+ - pymongo
+ - Peewee
+ .
+ It also boasts a simple file management interface and a redis client console.
+ .
+ This is the Python 3 version of the package.
+
+Package: python-flask-admin-doc
+Architecture: all
+Depends: ${misc:Depends}, ${sphinxdoc:Depends}
+Section: doc
+Description: admin interface extension for Flask
+ Flask-Admin is a batteries-included, simple-to-use Flask extension that lets
+ you add admin interfaces to Flask applications. It is inspired by the
+ *django-admin* package, but implemented in such a way that the developer has
+ total control of the look, feel and functionality of the resulting
+ application.
+ .
+ Out-of-the-box, Flask-Admin plays nicely with various ORM's, including
+ .
+ - SQLAlchemy
+ - MongoEngine
+ - pymongo
+ - Peewee
+ .
+ It also boasts a simple file management interface and a redis client console.
+ .
+ This package contains the documentation.
diff --git a/debian/copyright b/debian/copyright
new file mode 100644
index 000..e7caaa9
--- /dev/null
+++ b/debian/copyright
@@ -0,0 +1,35 @@
+This package was debianized by Arto Jantunen on
+Wed, 15 Oct 2014 13:36:01 +0300.
+
+It was downloaded from https://github.com/mrjoes/flask-admin
+
+Upstream Author: Serge S. Koval
+
+Copyright:
+
+Copyright (c) 2014, Serge S. Koval and contributors. See AUTHORS
+for more details.
+
+Some rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+* Names of the contributors may not be used to endorse or promote produc
Bug#755645: bcfg2 1.3.5 reporting fix
Jonas Jochmaring writes: > On Fri, 05 Jun 2015 11:49:55 +0200 Jonas Jochmaring > wrote: >> I've created a small patch for bcfg2 1.3.5 which fixes compatibility >> with django 1.7. I've already submitted a pull request upstream >> (https://github.com/Bcfg2/bcfg2/pull/281). >> With the upgrade to django 1.7 south is not needed for database >> migrations anymore, as this feature has been integrated into django. > > Added a django loading fix in src/lib/Bcfg2/Server/Core.py Thanks, that does allow the server to start. However I'm still seeing a couple of issues. First, on startup the server outputs this (probably from the django.setup call that was added): System check identified some issues: WARNINGS: ?: (1_6.W001) Some project unittests may not execute as expected. HINT: Django 1.6 introduced a new default test runner. It looks like this project was generated using Django 1.5 or earlier. You should ensure your tests are all running & behaving as expected. See https://docs.djangoproject.com/en/dev/releases/1.6/#new-test-runner for more information. System check identified some issues: WARNINGS: ?: (1_6.W001) Some project unittests may not execute as expected. HINT: Django 1.6 introduced a new default test runner. It looks like this project was generated using Django 1.5 or earlier. You should ensure your tests are all running & behaving as expected. See https://docs.djangoproject.com/en/dev/releases/1.6/#new-test-runner for more information. Second, the reporting plugin fails to start, both with a database that was created with the previous version and an empty database. The log output is as follows: bcfg2-server: Loading plugin Reporting Loading DjangoORM storage Failed to update database schema: Reporting: Failed to load transport: TransportImportError: Error instantiating transport DirectStore: Failed to instantiate plugin Reporting#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/dist-packages/Bcfg2/Server/Core.py", line 467, in init_plugin#012self.plugins[plugin] = plug(self, self.datastore)#012 File "/usr/lib/python2.7/dist-packages/Bcfg2/Server/Plugins/Reporting.py", line 67, in __init__#012raise PluginInitError(msg)#012PluginInitError: Reporting: Failed to load transport: TransportImportError: Error instantiating transport DirectStore: Any help with either issue would be appreciated. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787679: sqlitebrowser: testsuite fails in several environments, TestImport::csvImport(utf8chars) Compared values are not the same
Yes, I can reproduce the difference between sbuild and pbuilder. Neither build root has locales installed, but the output of locale is very different. Sbuild (the build succeeds): LANG=C.UTF-8 locale LANG=C.UTF-8 LANGUAGE= LC_CTYPE="C.UTF-8" LC_NUMERIC="C.UTF-8" LC_TIME="C.UTF-8" LC_COLLATE="C.UTF-8" LC_MONETARY="C.UTF-8" LC_MESSAGES="C.UTF-8" LC_PAPER="C.UTF-8" LC_NAME="C.UTF-8" LC_ADDRESS="C.UTF-8" LC_TELEPHONE="C.UTF-8" LC_MEASUREMENT="C.UTF-8" LC_IDENTIFICATION="C.UTF-8" LC_ALL= Pbuilder (the build fails): LANG=C.UTF-8 locale LANG=C.UTF-8 LANGUAGE= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL=C For some reason when running under pbuilder setting LANG doesn't affect the other locale settings. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787679: sqlitebrowser: testsuite fails in several environments, TestImport::csvImport(utf8chars) Compared values are not the same
peter green writes: > Package: sqlitebrowser > Severity: important > version: 3.5.1-2 > > sqlitebrowser failed to build in raspbian stretch with the following error. > > FAIL! : TestImport::csvImport(utf8chars) Compared values are not the same >Loc: [/«PKGBUILDDIR»/src/tests/TestImport.cpp(52)] > PASS : TestImport::cleanupTestCase() > Totals: 9 passed, 1 failed, 0 skipped > * Finished testing of TestImport * > make[1]: *** [override_dh_auto_test] Error 1 > > > http://buildd.raspbian.org/status/fetch.php?pkg=sqlitebrowser&arch=armhf&ver=3.5.1-2&stamp=1432558816 > > Googling the error showed that the same failure was happenin on the official > debian hurd and kfreebsd autobuilders and also on reproducable build tests on > amd64 > > https://buildd.debian.org/status/fetch.php?pkg=sqlitebrowser&arch=kfreebsd-amd64&ver=3.5.1-2&stamp=1430053385 > https://buildd.debian.org/status/fetch.php?pkg=sqlitebrowser&arch=kfreebsd-i386&ver=3.5.1-2&stamp=1430053503 > https://buildd.debian.org/status/fetch.php?pkg=sqlitebrowser&arch=hurd-i386&ver=3.5.1-2&stamp=1432997671 > https://reproducible.debian.net/rb-pkg/testing/amd64/sqlitebrowser.html > > Not sure what the common factor is, maybe something to do with locale setup in > the build chroot or so. The obvious one would be not having the C.UTF-8 locale available, but my understanding is that these days it's always supposed to be there. You could check that in your build root to make sure, though. Also, is locales installed or not? (I don't think it should matter either way, though) The obvious big difference between the normal amd64 build daemon and the reproducible test one is that reproducible builds with pbuilder instead of sbuild. I assume raspbian is built the normal way with sbuild? In any case, I'll see if I can reproduce the pbuilder vs sbuild difference here. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787553: fails to boot with a dracut generated initramfs
Martin Pitt writes: > Hello Arto, Michael, > > Michael Biebl [2015-06-02 21:44 +0200]: >> [2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=77eb82f9f0f6 > > This looks correct and sensible anyway, at least necessary for this > bug, so I cherry-picked this one for now. It might not be sufficient > yet of course, so Arto, please test this patch and report back here. I tested the patch, it is indeed sufficient to fix the bug. Thanks for the quick fix. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787553: fails to boot with a dracut generated initramfs
Package: systemd Version: 220-1 Severity: grave The new upload to unstable broke booting with dracut. The initramfs attempts to run /usr/lib/systemd/systemd-fsck to fsck the rootfs. Since on Debian (and in the initramfs) this binary is actually at /lib/systemd/systemd-fsck this fails, thus stopping the boot and dropping me into the emergency shell. It is possible to symlink those paths together and restart the failing unit (iirc systemd-fsck-root.service), which succeeds. However if I follow the instructions and simply exit the emergency shell bootup does not continue (nothing happens). -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-rc5 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.9.2-3 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.26.2-6 ii libc6 2.19-18 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2 ii libkmod220-1 ii liblzma55.1.1alpha+20120614-2+b3 ii libmount1 2.26.2-6 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 220-4 ii mount 2.26.2-6 ii sysv-rc 2.88dsf-59.2 ii udev220-4 ii util-linux 2.26.2-6 Versions of packages systemd recommends: ii dbus1.8.18-1 ii libpam-systemd 220-4 Versions of packages systemd suggests: pn systemd-ui -- Configuration Files: /etc/systemd/journald.conf changed [not included] /etc/systemd/logind.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_KILL
Attached is a patch that creates a separate service file under debian/
as requested.
--
Arto Jantunen
>From 1e30ccab0b0f486601021789248cf346517a0adc Mon Sep 17 00:00:00 2001
From: Arto Jantunen
Date: Fri, 8 May 2015 13:03:00 +0300
Subject: [PATCH] Add systemd service file
Add a new systemd service file that closely matches the behavior of the
current init script. Add build-dep on dh-systemd and use it to enable the
service file.
---
debian/control | 2 +-
debian/rules | 2 +-
debian/tor.dirs| 1 +
debian/tor.install | 1 +
debian/tor.service | 32
5 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 debian/tor.service
diff --git a/debian/control b/debian/control
index 76b8ce1..c5e1258 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: tor
Section: net
Priority: optional
Maintainer: Peter Palfrader
-Build-Depends: debhelper (>= 8.1.0~), quilt, libssl-dev, zlib1g-dev, libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), hardening-includes, asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386]
+Build-Depends: debhelper (>= 8.1.0~), quilt, libssl-dev, zlib1g-dev, libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), hardening-includes, asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386], dh-systemd
Build-Conflicts: libnacl-dev, libseccomp-dev [!amd64 !i386]
Standards-Version: 3.9.4
Homepage: https://www.torproject.org/
diff --git a/debian/rules b/debian/rules
index d404e19..eb4a8b4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ endif
%:
dh \
$@ \
- --with quilt \
+ --with quilt,systemd \
--builddirectory=build \
--parallel
diff --git a/debian/tor.dirs b/debian/tor.dirs
index f693956..7c82b44 100644
--- a/debian/tor.dirs
+++ b/debian/tor.dirs
@@ -1 +1,2 @@
etc/apparmor.d/abstractions
+lib/systemd/system
diff --git a/debian/tor.install b/debian/tor.install
index 11dc8b3..e59def8 100644
--- a/debian/tor.install
+++ b/debian/tor.install
@@ -5,3 +5,4 @@ etc/tor
contrib/client-tools/torify usr/bin
debian/tor-service-defaults-torrc usr/share/tor
+debian/tor.service lib/systemd/system
diff --git a/debian/tor.service b/debian/tor.service
new file mode 100644
index 000..953017d
--- /dev/null
+++ b/debian/tor.service
@@ -0,0 +1,32 @@
+[Unit]
+Description = Anonymizing overlay network for TCP
+After = syslog.target network.target nss-lookup.target
+
+[Service]
+Type = forking
+PIDFile = /var/run/tor/tor.pid
+PermissionsStartOnly = yes
+EnvironmentFile=-/etc/default/tor
+ExecStartPre = /usr/bin/install -Z -m 02750 -o debian-tor -g debian-tor -d /var/run/tor
+ExecStartPre = /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --verify-config
+ExecStart = /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc $ARGS
+ExecReload = /bin/kill -HUP ${MAINPID}
+KillSignal = SIGINT
+TimeoutSec = 30
+Restart = on-failure
+WatchdogSec = 1m
+LimitNOFILE = 32768
+
+# Hardening
+PrivateTmp = yes
+PrivateDevices = yes
+ProtectHome = yes
+ProtectSystem = full
+ReadOnlyDirectories = /
+ReadWriteDirectories = -/var/lib/tor
+ReadWriteDirectories = -/var/log/tor
+ReadWriteDirectories = -/var/run
+CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER
+
+[Install]
+WantedBy = multi-user.target
--
2.1.4
Bug#761403: CAP_KILL
Peter Palfrader writes: > On Wed, 06 May 2015, Arto Jantunen wrote: >> I was planning to move to Type=notify + User=debian-tor + >> RuntimeDirectory=/var/run/tor in the service file, and a separate >> config instead of the current tor-service-defaults-torrc (without >> PidFile, RunAsDaemon and User) as the next step after that. > > I assume moving the User to the service file would work only because we > give Tor CAP_NET_BIND_SERVICE, right? Yes, that would be the plan. I haven't tested this (yet), though. > Why would we want to set RuntimeDirectory? If User is set in the service file instead of torrc that would work, and would liberate us from needing to manually do the same thing with ExecStartPre. > Having Type=notify instead of simple will require modifying Tor > accordingly, correct? Nope, all of the changes are there upstream. Enabling it requires adding a build-dep on libsystemd-dev, though (this one I have tested). > Also, purely stylistic, I think I'd prefer we make our own service file > in debian/ rather than patching upstream's. Oh, ok. I'll switch to that instead. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_KILL
Peter Palfrader writes: > On Wed, 06 May 2015, Arto Jantunen wrote: > >> ++Type = forking > > I'm not sure why we'd continue to detach when running under systemd. My plan was to do this in stages, starting with a service file that works the same way as the current init script, working with the same configuration that is currently used. I was planning to move to Type=notify + User=debian-tor + RuntimeDirectory=/var/run/tor in the service file, and a separate config instead of the current tor-service-defaults-torrc (without PidFile, RunAsDaemon and User) as the next step after that. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_KILL
nusenu writes:
>>>> Actually also CAP_KILL is needed, otherwise reload will not work.
>>> >
>>> > CAP_KILL is not needed, see:
>>> > https://lists.torproject.org/pipermail/tor-dev/2015-April/008759.html
>> Well. You can either do that, or add CAP_KILL. Either will work you
>> chose one and I chose the other.
>
> With the difference that "your" tor daemons run with more capabilities
> than actually needed.
Makes sense. A new patch with that change is attached.
--
Arto Jantunen
>From 42962d2c0cc5a5df4d3348e8cdafb60304460543 Mon Sep 17 00:00:00 2001
From: Arto Jantunen
Date: Thu, 30 Apr 2015 13:56:43 +0300
Subject: [PATCH] Install and enable the systemd service file
- Patch the included service file to closely match the initscript
- Add build-dep on dh-systemd
- Install the service file
---
debian/control | 2 +-
debian/patches/debianize-systemd-service | 48
debian/patches/series| 1 +
debian/rules | 3 +-
debian/tor.dirs | 1 +
5 files changed, 53 insertions(+), 2 deletions(-)
create mode 100644 debian/patches/debianize-systemd-service
diff --git a/debian/control b/debian/control
index 76b8ce1..c5e1258 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: tor
Section: net
Priority: optional
Maintainer: Peter Palfrader
-Build-Depends: debhelper (>= 8.1.0~), quilt, libssl-dev, zlib1g-dev, libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), hardening-includes, asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386]
+Build-Depends: debhelper (>= 8.1.0~), quilt, libssl-dev, zlib1g-dev, libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), hardening-includes, asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386], dh-systemd
Build-Conflicts: libnacl-dev, libseccomp-dev [!amd64 !i386]
Standards-Version: 3.9.4
Homepage: https://www.torproject.org/
diff --git a/debian/patches/debianize-systemd-service b/debian/patches/debianize-systemd-service
new file mode 100644
index 000..1dc956e
--- /dev/null
+++ b/debian/patches/debianize-systemd-service
@@ -0,0 +1,48 @@
+From: Arto Jantunen
+Date: Wed, 29 Apr 2015 19:27:02 +0300
+Subject: Debianize systemd service file
+
+---
+ contrib/dist/tor.service.in | 15 +--
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+diff --git a/contrib/dist/tor.service.in b/contrib/dist/tor.service.in
+index c251158..848dd9b 100644
+--- a/contrib/dist/tor.service.in
b/contrib/dist/tor.service.in
+@@ -3,10 +3,12 @@ Description = Anonymizing overlay network for TCP
+ After = syslog.target network.target nss-lookup.target
+
+ [Service]
+-Type = notify
+-NotifyAccess = all
+-ExecStartPre = @BINDIR@/tor -f @CONFDIR@/torrc --verify-config
+-ExecStart = @BINDIR@/tor -f @CONFDIR@/torrc
++Type = forking
++PIDFile = /var/run/tor/tor.pid
++EnvironmentFile=-/etc/default/tor
++ExecStartPre = /usr/bin/install -Z -m 02750 -o debian-tor -g debian-tor -d @LOCALSTATEDIR@/run/tor
++ExecStartPre = @BINDIR@/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --verify-config
++ExecStart = @BINDIR@/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc $ARGS
+ ExecReload = /bin/kill -HUP ${MAINPID}
+ KillSignal = SIGINT
+ TimeoutSec = 30
+@@ -15,6 +17,7 @@ WatchdogSec = 1m
+ LimitNOFILE = 32768
+
+ # Hardening
++PermissionsStartOnly = yes
+ PrivateTmp = yes
+ PrivateDevices = yes
+ ProtectHome = yes
+@@ -22,8 +25,8 @@ ProtectSystem = full
+ ReadOnlyDirectories = /
+ ReadWriteDirectories = -@LOCALSTATEDIR@/lib/tor
+ ReadWriteDirectories = -@LOCALSTATEDIR@/log/tor
+-NoNewPrivileges = yes
+-CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
++ReadWriteDirectories = -@LOCALSTATEDIR@/run
++CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER
+
+ [Install]
+ WantedBy = multi-user.target
diff --git a/debian/patches/series b/debian/patches/series
index 19e8864..b267a32 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
improve-geoip-warning
+debianize-systemd-service
diff --git a/debian/rules b/debian/rules
index d404e19..2bf6b9b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ endif
%:
dh \
$@ \
- --with quilt \
+ --with quilt,systemd \
--builddirectory=build \
--parallel
@@ -52,6 +52,7 @@ override_dh_install:
cp debian/tor.apparmor-profile debian/tor/etc/apparmor.d/system_tor
cp debian/tor.apparmor-profile.abstraction debian/tor/etc/apparmor.d/abstractions/tor
dh_apparmor --profile-name=system_tor -ptor
+ cp build/contrib/dist/tor.service debian/tor/lib/systemd/system
override_dh_installdocs:
dh_installdocs -ptor-dbg --link-doc=tor
diff --git a/debian/tor.dirs b/debian/tor.di
Bug#761403: CAP_KILL
nusenu writes: > Arto Jantunen: >> Actually also CAP_KILL is needed, otherwise reload will not work. > > CAP_KILL is not needed, see: > https://lists.torproject.org/pipermail/tor-dev/2015-April/008759.html Well. You can either do that, or add CAP_KILL. Either will work, you chose one and I chose the other. It happens. > Feels a bit as if you are re-making my steps ;) > It might make sense to take what is there already. That may be the case. Is your version available for me to look at somewhere? -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_KILL
Actually also CAP_KILL is needed, otherwise reload will not work. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_FOWNER
nusenu writes: >>> CapabilityBoundingSet: >>> >>> Since you add CAP_FOWNER (compared to upstream): What use cases >>> require it? >> >> CAP_FOWNER is required by "ControlSocket /var/run/tor/control". >> Tor chowns the control socket on startup (and fails to start if >> this does not succeed). > > I was able to use ControlSocket without CAP_FOWNER. > Adding CAP_DAC_OVERRIDE and CAP_CHOWN was enough in my case. > > See also: > https://lists.torproject.org/pipermail/tor-dev/2015-April/008638.html > > What tor version did you test with? With 0.2.6.7. Did you test both cases where /var/run/tor exists and doesn't exist? -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761403: Update patch
The previous patch had a bug, /var/run/tor was not getting created.
Sadly as long as we emulate the init script (tor starts as root and
daemonizes) we can't use the systemd RuntimeDirectory feature. Instead
the attached updated patch uses a ExecStartPre command to create the
directory.
Also, I quickly tested obfs4 and at least that pluggable transport seems
to work even with the systemd hardening stuff enabled. I'll test some
others at a later point.
--
Arto Jantunen
>From 3f50f0225b09bee31472ea62e79fcc8da05487f5 Mon Sep 17 00:00:00 2001
From: Arto Jantunen
Date: Thu, 30 Apr 2015 13:56:43 +0300
Subject: [PATCH] Install and enable the systemd service file
- Patch the included service file to closely match the initscript
- Add build-dep on dh-systemd
- Install the service file
---
debian/control | 2 +-
debian/patches/debianize-systemd-service | 40
debian/patches/series| 1 +
debian/rules | 3 ++-
debian/tor.dirs | 1 +
5 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 debian/patches/debianize-systemd-service
diff --git a/debian/control b/debian/control
index 76b8ce1..c5e1258 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: tor
Section: net
Priority: optional
Maintainer: Peter Palfrader
-Build-Depends: debhelper (>= 8.1.0~), quilt, libssl-dev, zlib1g-dev, libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), hardening-includes, asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386]
+Build-Depends: debhelper (>= 8.1.0~), quilt, libssl-dev, zlib1g-dev, libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), hardening-includes, asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386], dh-systemd
Build-Conflicts: libnacl-dev, libseccomp-dev [!amd64 !i386]
Standards-Version: 3.9.4
Homepage: https://www.torproject.org/
diff --git a/debian/patches/debianize-systemd-service b/debian/patches/debianize-systemd-service
new file mode 100644
index 000..6243e65
--- /dev/null
+++ b/debian/patches/debianize-systemd-service
@@ -0,0 +1,40 @@
+From: Arto Jantunen
+Date: Wed, 29 Apr 2015 19:27:02 +0300
+Subject: Debianize systemd service file
+
+---
+ contrib/dist/tor.service.in | 14 --
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+diff --git a/contrib/dist/tor.service.in b/contrib/dist/tor.service.in
+index c251158..57e5ecf 100644
+--- a/contrib/dist/tor.service.in
b/contrib/dist/tor.service.in
+@@ -3,10 +3,12 @@ Description = Anonymizing overlay network for TCP
+ After = syslog.target network.target nss-lookup.target
+
+ [Service]
+-Type = notify
+-NotifyAccess = all
+-ExecStartPre = @BINDIR@/tor -f @CONFDIR@/torrc --verify-config
+-ExecStart = @BINDIR@/tor -f @CONFDIR@/torrc
++Type = forking
++PIDFile = /var/run/tor/tor.pid
++EnvironmentFile=-/etc/default/tor
++ExecStartPre = /usr/bin/install -Z -m 02750 -o debian-tor -g debian-tor -d @LOCALSTATEDIR@/run/tor
++ExecStartPre = @BINDIR@/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --verify-config
++ExecStart = @BINDIR@/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc $ARGS
+ ExecReload = /bin/kill -HUP ${MAINPID}
+ KillSignal = SIGINT
+ TimeoutSec = 30
+@@ -22,8 +24,8 @@ ProtectSystem = full
+ ReadOnlyDirectories = /
+ ReadWriteDirectories = -@LOCALSTATEDIR@/lib/tor
+ ReadWriteDirectories = -@LOCALSTATEDIR@/log/tor
+-NoNewPrivileges = yes
+-CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
++ReadWriteDirectories = -@LOCALSTATEDIR@/run
++CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER
+
+ [Install]
+ WantedBy = multi-user.target
diff --git a/debian/patches/series b/debian/patches/series
index 19e8864..b267a32 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
improve-geoip-warning
+debianize-systemd-service
diff --git a/debian/rules b/debian/rules
index d404e19..2bf6b9b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ endif
%:
dh \
$@ \
- --with quilt \
+ --with quilt,systemd \
--builddirectory=build \
--parallel
@@ -52,6 +52,7 @@ override_dh_install:
cp debian/tor.apparmor-profile debian/tor/etc/apparmor.d/system_tor
cp debian/tor.apparmor-profile.abstraction debian/tor/etc/apparmor.d/abstractions/tor
dh_apparmor --profile-name=system_tor -ptor
+ cp build/contrib/dist/tor.service debian/tor/lib/systemd/system
override_dh_installdocs:
dh_installdocs -ptor-dbg --link-doc=tor
diff --git a/debian/tor.dirs b/debian/tor.dirs
index f693956..7c82b44 100644
--- a/debian/tor.dirs
+++ b/debian/tor.dirs
@@ -1 +1,2 @@
etc/apparmor.d/abstractions
+lib/systemd/system
--
2.1.4
Bug#761403: CAP_FOWNER
Hi, > CapabilityBoundingSet: > > Since you add CAP_FOWNER (compared to upstream): What use cases > require it? CAP_FOWNER is required by "ControlSocket /var/run/tor/control". Tor chowns the control socket on startup (and fails to start if this does not succeed). -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761403: Add patch
intrigeri writes: > Arto Jantunen wrote (30 Apr 2015 17:46:00 GMT) : >> Attached is a patch to enable the systemd service file, and modify it to >> mimick the behavior of the current initscript. > > Thanks! > > Two questions: > > 1. Was this tested with pluggable transports, e.g. obfs4proxy? >I've seen occurences in the past of hardening features of systemd >breaking such things. No, it was not tested with pluggable transports. I'll do that and report back. Do we know if the upstream provided service file supports them as is, without my changes? > 2. The unit file doesn't seem to confine the Tor service with AppArmor >when available, which is a regression vs. the current initscript, >right? It might be that `AppArmorProfile = system_tor' is enough to >make this work with systemd v217+ (in experimental), although in >the past it wasn't compatible with `NoNewPrivileges = yes'. See the >discussion on Debian#760526, and the one in the "[PATCH] Move >apparmor code before the namespace setup" thread on the >systemd-de...@lists.freedesktop.org mailing-list for details. I wouldn't know where to start with apparmor, so it would probably be better if this was handled by someone else. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761403: Add patch
Control: tags -1 patch
Attached is a patch to enable the systemd service file, and modify it to
mimick the behavior of the current initscript.
>From e4bce313a44555f474989588d30ee38b48069210 Mon Sep 17 00:00:00 2001
From: Arto Jantunen
Date: Thu, 30 Apr 2015 13:56:43 +0300
Subject: [PATCH] Install and enable the systemd service file
- Patch the included service file to closely match the initscript
- Add build-dep on dh-systemd
- Install the service file
---
debian/control | 2 +-
debian/patches/debianize-systemd-service | 39
debian/patches/series| 1 +
debian/rules | 3 ++-
debian/tor.dirs | 1 +
5 files changed, 44 insertions(+), 2 deletions(-)
create mode 100644 debian/patches/debianize-systemd-service
diff --git a/debian/control b/debian/control
index 76b8ce1..c5e1258 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: tor
Section: net
Priority: optional
Maintainer: Peter Palfrader
-Build-Depends: debhelper (>= 8.1.0~), quilt, libssl-dev, zlib1g-dev, libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), hardening-includes, asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386]
+Build-Depends: debhelper (>= 8.1.0~), quilt, libssl-dev, zlib1g-dev, libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), hardening-includes, asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386], dh-systemd
Build-Conflicts: libnacl-dev, libseccomp-dev [!amd64 !i386]
Standards-Version: 3.9.4
Homepage: https://www.torproject.org/
diff --git a/debian/patches/debianize-systemd-service b/debian/patches/debianize-systemd-service
new file mode 100644
index 000..769efeb
--- /dev/null
+++ b/debian/patches/debianize-systemd-service
@@ -0,0 +1,39 @@
+From: Arto Jantunen
+Date: Wed, 29 Apr 2015 19:27:02 +0300
+Subject: Debianize systemd service file
+
+---
+ contrib/dist/tor.service.in | 13 +++--
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/contrib/dist/tor.service.in b/contrib/dist/tor.service.in
+index c251158..578bf39 100644
+--- a/contrib/dist/tor.service.in
b/contrib/dist/tor.service.in
+@@ -3,10 +3,11 @@ Description = Anonymizing overlay network for TCP
+ After = syslog.target network.target nss-lookup.target
+
+ [Service]
+-Type = notify
+-NotifyAccess = all
+-ExecStartPre = @BINDIR@/tor -f @CONFDIR@/torrc --verify-config
+-ExecStart = @BINDIR@/tor -f @CONFDIR@/torrc
++Type = forking
++PIDFile = /var/run/tor/tor.pid
++EnvironmentFile=-/etc/default/tor
++ExecStartPre = @BINDIR@/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --verify-config
++ExecStart = @BINDIR@/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc $ARGS
+ ExecReload = /bin/kill -HUP ${MAINPID}
+ KillSignal = SIGINT
+ TimeoutSec = 30
+@@ -22,8 +23,8 @@ ProtectSystem = full
+ ReadOnlyDirectories = /
+ ReadWriteDirectories = -@LOCALSTATEDIR@/lib/tor
+ ReadWriteDirectories = -@LOCALSTATEDIR@/log/tor
+-NoNewPrivileges = yes
+-CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
++ReadWriteDirectories = -@LOCALSTATEDIR@/run/tor
++CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER
+
+ [Install]
+ WantedBy = multi-user.target
diff --git a/debian/patches/series b/debian/patches/series
index 19e8864..b267a32 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
improve-geoip-warning
+debianize-systemd-service
diff --git a/debian/rules b/debian/rules
index d404e19..2bf6b9b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ endif
%:
dh \
$@ \
- --with quilt \
+ --with quilt,systemd \
--builddirectory=build \
--parallel
@@ -52,6 +52,7 @@ override_dh_install:
cp debian/tor.apparmor-profile debian/tor/etc/apparmor.d/system_tor
cp debian/tor.apparmor-profile.abstraction debian/tor/etc/apparmor.d/abstractions/tor
dh_apparmor --profile-name=system_tor -ptor
+ cp build/contrib/dist/tor.service debian/tor/lib/systemd/system
override_dh_installdocs:
dh_installdocs -ptor-dbg --link-doc=tor
diff --git a/debian/tor.dirs b/debian/tor.dirs
index f693956..7c82b44 100644
--- a/debian/tor.dirs
+++ b/debian/tor.dirs
@@ -1 +1,2 @@
etc/apparmor.d/abstractions
+lib/systemd/system
--
2.1.4
--
Arto Jantunen
Bug#772016: sqlitebrowser: When i install sqlitebrowser from apt-get i get the error: segmentation fault
Control: tags +moreinfo +unreproducible There isn't enough information in this report for me to even verify the existence of a bug. Please repond to the questions included in the reportbug template: * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? You could additionally include the full commands that you ran, and their output. Also based on the kernel version you are running (Kernel: Linux 3.17-4.towo-siduction-amd64 (SMP w/2 CPU cores; PREEMPT)) it's possible you aren't running Debian, but siduction instead. Is that the case, or is the kernel the only changed component? In the later case, can you retry with the standard Debian kernel? -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769441: Does not work with Iceweasel 33
Package: xul-ext-monkeysphere Version: 0.8-1 Severity: important Starting with Iceweasel 33 the monkeysphere extension no longer works. No error messages are shown, but a cert that validates fine with msva-query-agent is not accepted by Iceweasel. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-rc3 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xul-ext-monkeysphere depends on: ii iceweasel 33.1-1 Versions of packages xul-ext-monkeysphere recommends: ii msva-perl [monkeysphere-validation-agent] 0.9.2-1 xul-ext-monkeysphere suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682006: Gnus ignores marks from imap server
Rob Browning writes: > Arto Jantunen writes: > >> The Gnus version included in Emacs 24 ignores any marks set on an imap >> server, including is the message read or not. This makes the imap >> support of Gnus unusable for the main thing imap is used for (sharing >> one mailbox between multiple client applications). This works normally >> in Emacs 23, so this is a regression. > > Is this still a problem? > > If so, can you elaborate a bit on your situation? (I'm assuming that > Gnus normally handles this better, or we'd have heard more > complaints.) As I thought, this does happen on upgrade from Emacs 23 to 24, and can be cleared by removing .newsrc.eld. Some incompatibility with the file format, perhaps? -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762968: nmu patch
Diane Trout writes: > I tried to browse your git repository http://viiru.iki.fi/git/dnssec-trigger/ > and got a 403 forbidden. Hi. That is a plain git repo, there is no web interface configured on that host. You can only use it as a git remote (clone, add remote, pull, etc). Sorry for not being clearer in the original message. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765509: ITP: python-flask-admin -- admin interface extension for Flask
Package: wnpp Severity: wishlist Owner: Arto Jantunen * Package name: python-flask-admin Version : 1.0.8 Upstream Author : Serge S. Koval * URL : https://github.com/mrjoes/flask-admin * License : BSD Programming Lang: Python Description : admin interface extension for Flask Flask-Admin is a batteries-included, simple-to-use Flask extension that lets you add admin interfaces to Flask applications. It is inspired by the *django-admin* package, but implemented in such a way that the developer has total control of the look, feel and functionality of the resulting application. . Out-of-the-box, Flask-Admin plays nicely with various ORM's, including . - SQLAlchemy - MongoEngine - pymongo - Peewee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682006: Gnus ignores marks from imap server
Rob Browning writes: > Arto Jantunen writes: > >> The Gnus version included in Emacs 24 ignores any marks set on an imap >> server, including is the message read or not. This makes the imap >> support of Gnus unusable for the main thing imap is used for (sharing >> one mailbox between multiple client applications). This works normally >> in Emacs 23, so this is a regression. > > Is this still a problem? > > If so, can you elaborate a bit on your situation? (I'm assuming that > Gnus normally handles this better, or we'd have heard more complaints.) I had this problem immediately after upgrading from Emacs 23 to Emacs 24. IIRC wiping the .newsrc files and starting over (resubscribing all the mailboxes and such) clears it, hinting at an incompatibility between the versions. I have another 23 -> 24 upgrade coming up soonish (when jessie freezes or so) and should be able to verify this theory then. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763023: [Pkg-utopia-maintainers] Bug#763023: The unbound plugin calls dnssec-trigger-script with an incorrect path
Michael Biebl writes: > Am 27.09.2014 um 10:24 schrieb Arto Jantunen: >> With dns=unbound enabled the 01-dnssec-trigger dispatcher script isn't >> used, and NM calls dnssec-trigger-script itself. The hardcoded path in >> NM doesn't match where the script is installed on Debian, and thus the >> plugin fails. A trivial patch to fix this is attached. > > Thanks for the patch, Arto. > Unfortunately this replaces one hard-coded location with another > hard-coded location so is not upstreamable. > > Could you raise this issue upstream (like [1]) and see if we can address > e.g. via a configure switch. Considering that upstream plans to integrate the functionality of dnssec-trigger-script into the NM plugin itself this entire setup is likely to be temporary. What I hoped to achieve with this patch (and the NMU of dnssec-trigger) is to get this functionality (usable dnssec for machines that move between networks) into jessie. Beyond that I expect dnssec-trigger to be obsoleted by a more integrated setup anyway. I don't have an account on gnome bugzilla, but I can get one and file this there if you prefer. I do hope to see this fixed one way or the other before the freeze, in any case. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763023: The unbound plugin calls dnssec-trigger-script with an incorrect path
Package: network-manager
Version: 0.9.10.0-2.1
Severity: important
Tags: patch
With dns=unbound enabled the 01-dnssec-trigger dispatcher script isn't
used, and NM calls dnssec-trigger-script itself. The hardcoded path in
NM doesn't match where the script is installed on Debian, and thus the
plugin fails. A trivial patch to fix this is attached.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.17.0-rc6 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages network-manager depends on:
ii adduser3.113+nmu3
ii dbus 1.8.8-1
ii init-system-helpers1.21
ii isc-dhcp-client4.3.1-1
ii libc6 2.19-11
ii libdbus-1-31.8.8-1
ii libdbus-glib-1-2 0.102-1
ii libgcrypt111.5.4-3
ii libglib2.0-0 2.42.0-1
ii libgnutls-deb0-28 3.3.8-2
ii libgudev-1.0-0 215-4
ii libmm-glib01.4.0-1
ii libndp01.4-1
ii libnewt0.520.52.17-1
ii libnl-3-2003.2.24-2
ii libnl-genl-3-200 3.2.24-2
ii libnl-route-3-200 3.2.24-2
ii libnm-glib40.9.10.0-2.1
ii libnm-util20.9.10.0-2.1
ii libpam-systemd 215-4
ii libpolkit-gobject-1-0 0.105-7
ii libreadline6 6.3-8
ii libsoup2.4-1 2.48.0-1
ii libsystemd-daemon0 215-4
ii libsystemd-login0 215-4
ii libteamdctl0 1.12-1
ii libuuid1 2.20.1-5.8
ii lsb-base 4.1+Debian13
ii policykit-10.105-7
ii udev 215-4
ii wpasupplicant 2.2-1
Versions of packages network-manager recommends:
pn crda
pn dnsmasq-base
ii iptables 1.4.21-2
ii modemmanager 1.4.0-1
ii ppp 2.4.6-2
Versions of packages network-manager suggests:
ii avahi-autoipd 0.6.31-4
pn libteam-utils
-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
dns=unbound
[ifupdown]
managed=false
-- no debconf information
From: Arto Jantunen
Date: Sat, 27 Sep 2014 11:13:32 +0300
Subject: Use the correct path when calling dnssec-trigger-script
Debian systems don't have /usr/libexec, so the script is installed in
a different path.
---
src/dns-manager/nm-dns-unbound.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/dns-manager/nm-dns-unbound.c b/src/dns-manager/nm-dns-unbound.c
index 137fd20..439a36d 100644
--- a/src/dns-manager/nm-dns-unbound.c
+++ b/src/dns-manager/nm-dns-unbound.c
@@ -40,7 +40,7 @@ update (NMDnsPlugin *plugin,
* without calling custom scripts. The dnssec-trigger functionality
* may be eventually merged into NetworkManager.
*/
- return nm_spawn_process ("/usr/libexec/dnssec-trigger-script --async --update") == 0;
+ return nm_spawn_process ("/usr/lib/dnssec-trigger/dnssec-trigger-script --async --update") == 0;
}
static gboolean
Bug#762968: NMU patch for -1.1
Package: dnssec-trigger
Version: 0.13~svn685-1
Severity: normal
I have uploaded an NMU fixing most of the bugs in the current package to
DELAYED/5, the patch is attached. At your convenience you can also pull
the changes from http://viiru.iki.fi/git/dnssec-trigger (branch nmu, has
a signed tag).
--
Arto Jantunen
diff --git a/debian/changelog b/debian/changelog
index 0fcd0a2..b72a9da 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+dnssec-trigger (0.13~svn685-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix incorrect configure parameter name (Closes: #757320)
+ * Add missing dependency on python-gi
+ * Add missing dependency on gir1.2-networkmanager-1.0
+ * Add missing dependency on python-lockfile (Closes: #758731)
+ * Apply patch from Gerald Turner to fix paths in desktop file
+(Closes: #756149)
+ * Add tmpfiles.d config file (Closes: #758729)
+
+ -- Arto Jantunen Thu, 25 Sep 2014 19:17:04 +0300
+
dnssec-trigger (0.13~svn685-1) unstable; urgency=medium
* New upstream version 0.13~svn685 (Closes: #754853)
diff --git a/debian/control b/debian/control
index 4b637d4..1a32503 100644
--- a/debian/control
+++ b/debian/control
@@ -23,6 +23,9 @@ Depends: ${shlibs:Depends},
${misc:Depends},
${python:Depends},
python,
+ python-gi,
+ python-lockfile,
+ gir1.2-networkmanager-1.0,
unbound
Description: reconfiguration tool to make DNSSEC work
Dnssec-trigger reconfigures the local unbound DNS server. This unbound
diff --git a/debian/dnssec-trigger.conf b/debian/dnssec-trigger.conf
new file mode 100644
index 000..2f343b2
--- /dev/null
+++ b/debian/dnssec-trigger.conf
@@ -0,0 +1 @@
+d /run/dnssec-trigger 0700 root root -
diff --git a/debian/dnssec-trigger.install b/debian/dnssec-trigger.install
new file mode 100644
index 000..5513cad
--- /dev/null
+++ b/debian/dnssec-trigger.install
@@ -0,0 +1 @@
+debian/dnssec-trigger.conf usr/lib/tmpfiles.d/
diff --git a/debian/patches/fix-desktop-file-dirs.patch b/debian/patches/fix-desktop-file-dirs.patch
new file mode 100644
index 000..f98534f
--- /dev/null
+++ b/debian/patches/fix-desktop-file-dirs.patch
@@ -0,0 +1,18 @@
+From: Gerald Turner
+Subject: dnssec-trigger-panel.desktop is built without interpolating @bindir@ and @uidir@
+Date: Sat, 26 Jul 2014 11:53:06 -0700
+
+diff -ur dnssec-trigger-0.13~svn685.orig/panel/dnssec-trigger-panel.desktop.in dnssec-trigger-0.13~svn685/panel/dnssec-trigger-panel.desktop.in
+--- dnssec-trigger-0.13~svn685.orig/panel/dnssec-trigger-panel.desktop.in 2014-07-15 01:14:57.0 -0700
dnssec-trigger-0.13~svn685/panel/dnssec-trigger-panel.desktop.in 2014-07-26 11:43:13.494258925 -0700
+@@ -5,8 +5,8 @@
+ Name=DNSSEC Trigger
+ GenericName=Network Applet
+ Comment=Shows DNS state and warning dialog
+-Exec=0bindir0/dnssec-trigger-panel
+-Icon=0uidir0/status-icon.png
++Exec=@bindir@/dnssec-trigger-panel
++Icon=@uidir@/status-icon.png
+ Terminal=false
+ Categories=Utility;
+ X-KDE-StartupNotify=false
diff --git a/debian/patches/series b/debian/patches/series
index 47d8520..2fa51a1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
systemd_services_path_is_lib_systemd.patch
debian-quirks.patch
strip-version-number-from-config.patch
+fix-desktop-file-dirs.patch
diff --git a/debian/rules b/debian/rules
index b18d343..2cfa7c0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,7 +14,7 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,-z,defs -Wl,--as-needed
override_dh_auto_configure:
dh_auto_configure -- \
- --with-libexecdir=/usr/lib/dnssec-trigger \
+ --libexecdir=/usr/lib/dnssec-trigger \
--with-ssl \
--with-hooks=networkmanager \
--with-gui=gtk \
