Bug#1080096: fail to build with kernel 6.10.6+bpo-amd64 - implicit declaration of function ‘follow_pfn’
On Fri, Sep 06, 2024 at 05:21:36PM +0200, Andreas Beckmann wrote: > src:nvidia-graphics-drivers for bookworm-backports is in BACKPORTS-NEW. Awesome, thank you. > Just curious: Why didn't you simply rebuild the package from sid for > bookworm instead of digging for patches on the internet? I only have Debian stable APT entries on my laptop and nobody mentioned here in the bug report that it was fixed in sid, so I had no idea. FWIW, I did not dig for patches on the internet myself, I just gave a try to the workaround someone else proposed on this bug report (thank you!), as it seemed promising. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . https://upsilon.cc/zack _. ^ ._ Full professor of Computer Science o o o \/|V|\/ Télécom Paris, Polytechnic Institute of Paris o o o <\> Co-founder & CTO Software Heritageo o o o /\|^|/\ https://twitter.com/zacchiro . https://mastodon.xyz/@zacchiro '" V "' signature.asc Description: PGP signature
Bug#1080096: fail to build with kernel 6.10.6+bpo-amd64 - implicit declaration of function ‘follow_pfn’
tags 1080096 patch
thanks
On Tue, Sep 03, 2024 at 06:35:06PM +0200, fr.hame...@gmail.com wrote:
> To solve it have applied the patches given by nvidia the 21 of July
> here :
> https://forums.developer.nvidia.com/t/gpl-only-symbols-follow-pte-and-rcu-read-unlock-prevent-470-256-02-to-build-with-kernel-6-10/300052/4
I can confirm it worked for me too, thanks a lot for the pointer!
For convenience, I'm attaching the patch I used to this message (its 2
messages down from the above, but it's not directly downloadable).
It does not apply cleanly to nvidia-kernel-dkms 535.183.01-1~deb12u1 ,
but it's trivial to fix manually.
Cheers
diff -ruNb a/kernel/conftest.sh b/kernel/conftest.sh
--- a/conftest.sh2024-07-19 04:36:26.183701185 -0500
+++ b/conftest.sh2024-07-19 04:36:26.230366381 -0500
@@ -4464,20 +4464,22 @@
compile_check_conftest "$CODE" "NV_DRM_GEM_OBJECT_VMAP_HAS_MAP_ARG" "" "types"
;;
-unsafe_follow_pfn)
+follow_pfn)
#
-# Determine if unsafe_follow_pfn() is present.
+# Determine if follow_pfn() is present.
#
-# unsafe_follow_pfn() was added by commit 69bacee7f9ad
-# ("mm: Add unsafe_follow_pfn") in v5.13-rc1.
+# follow_pfn() was added by commit 3b6748e2dd69
+# ("mm: introduce follow_pfn()") in v2.6.31-rc1, and removed
+# by commit 233eb0bf3b94 ("mm: remove follow_pfn")
+# from linux-next 233eb0bf3b94.
#
CODE="
#include
-void conftest_unsafe_follow_pfn(void) {
-unsafe_follow_pfn();
+void conftest_follow_pfn(void) {
+follow_pfn();
}"
-compile_check_conftest "$CODE" "NV_UNSAFE_FOLLOW_PFN_PRESENT" "" "functions"
+compile_check_conftest "$CODE" "NV_FOLLOW_PFN_PRESENT" "" "functions"
;;
drm_plane_atomic_check_has_atomic_state_arg)
diff -ruNb a/kernel/nvidia/nvidia.Kbuild b/kernel/nvidia/nvidia.Kbuild
--- a/nvidia/nvidia.Kbuild 2022-10-12 04:29:57.0 -0500
+++ b/nvidia/nvidia.Kbuild 2024-07-19 05:17:39.148448922 -0500
@@ -164,7 +164,7 @@ NV_CONFTEST_FUNCTION_COMPILE_TESTS += cc
NV_CONFTEST_FUNCTION_COMPILE_TESTS += iterate_fd
NV_CONFTEST_FUNCTION_COMPILE_TESTS += seq_read_iter
NV_CONFTEST_FUNCTION_COMPILE_TESTS += sg_page_iter_page
-NV_CONFTEST_FUNCTION_COMPILE_TESTS += unsafe_follow_pfn
+NV_CONFTEST_FUNCTION_COMPILE_TESTS += follow_pfn
NV_CONFTEST_FUNCTION_COMPILE_TESTS += drm_gem_object_get
NV_CONFTEST_FUNCTION_COMPILE_TESTS += drm_gem_object_put_unlocked
NV_CONFTEST_FUNCTION_COMPILE_TESTS += set_close_on_exec
diff -ruNb a/kernel/nvidia/os-mlock.c b/kernel/nvidia/os-mlock.c
--- a/nvidia/os-mlock.c 2022-10-12 04:30:26.0 -0500
+++ b/nvidia/os-mlock.c 2024-07-19 04:36:26.230366381 -0500
@@ -18,10 +18,10 @@
unsigned long address,
unsigned long *pfn)
{
-#if defined(NV_UNSAFE_FOLLOW_PFN_PRESENT)
-return unsafe_follow_pfn(vma, address, pfn);
-#else
+#if defined(NV_FOLLOW_PFN_PRESENT)
return follow_pfn(vma, address, pfn);
+#else
+return -1;
#endif
}
Bug#1017835: elpa-evil: emacs 28.1 upgrade fails with byte compiling elpa-evil
On Sun, Aug 21, 2022 at 12:29:21PM +0200, Gregory Mounie wrote: > Upgrading to emacs-gtk 28.1 fails with byte co[m]piling elpa-evil* [...] > In toplevel form: > evil.el:133:1: Error: Wrong number of arguments: (3 . 4), 2 > ERROR: install script from elpa-evil package failed Confirmed, I'm seeing this as well and it's breaking the overall installation of emacs-28 (if you've elpa-evil installed). As a workaround, the following works: remove the "elpa-evil" Debian package, install the same package via "M-x package-install" and then "evil". That will give you evil version 1.15.0, which is compatible with Emacs 28. (But also get you out of the comfort zone of Debian packages, you've been warned!) Hope this helps, Cheers
Bug#991215: local copy of rust book does not allow to hide the navigation bar as the online version does
Package: rust-doc Version: 1.52.1+dfsg1-1~exp3 Severity: minor File: /usr/share/doc/rust-doc/html/book Heya, it looks like the HTML version of the Rust book shipped with rust-doc lacks some of the (CSS/JS) elements of the version of the book online at https://doc.rust-lang.org/book/ . Most notably, the top-left button that allow to toggle the left navigation bar is missing when browsing the local HTML version. That is annoying as, on small screens the left navigation bar can take a lot of space and it would be nice to be able to hide it. I've noticed the following error in the javascript console when browsing the local version: book.js:572 Uncaught ReferenceError: ClipboardJS is not defined at clipboard (book.js:572) at book.js:594 which I do not get when browsing the live version on rust-lang.org. (Even if the book.js is installed and properly resolvable from the HTML page.) Thanks for maintaining rust(-doc) in Debian! Cheers -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 rust-doc depends on: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 ii fonts-open-sans 1.11-1.1 ii libjs-highlight.js 9.18.5+dfsg1-1 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-mathjax 2.7.9+dfsg-1 Versions of packages rust-doc recommends: ii cargo-doc 0.47.0-3 rust-doc suggests no packages. -- no debconf information
Bug#988127: neomutt hangs for minutes while checking S/MIME signed mails
retitle 988127 neomutt hangs for minutes while checking S/MIME signed mails found 988127 20201127+dfsg.1-1.1 thanks Heya, I've cloned/reassigned this issue from mutt to neomutt, because it does happen to me with neomutt right now (version 20201127+dfsg.1-1.1 ), exactly as described in the original mutt bug report. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#961638: proposal: stocat - probabilistic cat
On Tue, May 26, 2020 at 11:39:42PM +0200, Stefano Zacchiroli wrote: > I'm hereby proposing the inclusion of the attached "stocat" utility to > moreutils. It's like cat, but output lines with a given probability, > defaulting to 10%. It's very useful for random sampling (and *much* > more efficient at that than using "shuf" which is unwieldy on very > large inputs) and, while it can be implemented instead with awk/perl > oneliners, those oneliners aren't very mnemonic and are error prone. Heya, as I haven't heard back about this, but others have asked me about how to best use stocat, I've now released it as an independent tool here: https://gitlab.com/zacchiro/stocat I'm happy to reconsider if/when it gets integrated into moreutils. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error
Hi Sudip, thanks for your reply, On Fri, Feb 12, 2021 at 05:00:04PM +, Sudip Mukherjee wrote: > Thanks for the report. Can you please paste your offlineimaprc file > after removing any sensitive information, and I can try to reproduce > the error in my setup. in fact, it turns out this is a duplicate of #981063, which I failed to identify initially because it didn't have the actual final error in the message. The workaround in that bug report worked for me. I've tried to merge the bugs, but it failed with an error on locking a spool file on the BTS server. (I've just tried again.) FWIW, I think #981063 should be severity serious and fixed in time for bullseye. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error
Package: offlineimap
Version: 7.3.3+dfsg1-1+0.0~git20210105.00d395b+dfsg-2
Severity: serious
In Debian testing offlineimap plain authentication over SSL started to fail for
me in the following way:
$ offlineimap -c ~/.config/offlineimap/offlineimaprc -u basic --info
OfflineIMAP 7.3.0
Licensed under the GNU GPL v2 or any later version (with an OpenSSL
exception)
imaplib2 v3.05, Python v3.9.1+, OpenSSL 1.1.1i 8 Dec 2020
imaplib2: 3.05
Remote repository 'Censored: type 'IMAP'
Host: mail.example.org Port: None SSL: True
Establishing connection to mail.example.org:993 (Censored)
Traceback (most recent call last):
File "/usr/bin/offlineimap", line 22, in
oi.run()
File "/usr/share/offlineimap3/offlineimap/init.py", line 88, in run
self.__serverdiagnostics(options)
File "/usr/share/offlineimap3/offlineimap/init.py", line 518, in
__serverdiagnostics
account.serverdiagnostics()
File "/usr/share/offlineimap3/offlineimap/accounts.py", line 197, in
serverdiagnostics
self.ui.serverdiagnostics(remote_repo, 'Remote')
File "/usr/share/offlineimap3/offlineimap/ui/UIBase.py", line 450, in
serverdiagnostics
conn = repository.imapserver.acquireconnection()
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 592, in
acquireconnection
self.__authn_helper(imapobj)
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 449, in
__authn_helper
if func(imapobj):
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 375, in
__authn_plain
imapobj.authenticate('PLAIN', self.__plainhandler)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 691, in
authenticate
typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
File "/usr/lib/python3/dist-packages/imaplib2.py", line 1684, in
_simple_command
return self._command_complete(self._command(name, *args), kw)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 1404, in _command
literal = literator(data, rqb)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 2247, in process
ret = self.mech(self.decode(data))
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 217, in
__plainhandler
retval = NULL.join((authz, authc, passwd))
TypeError: sequence item 2: expected str instance, bytes found
The server in question has a valid letsencrypt certificate, which I can use and
authenticate fine with other clients.
Not sure if the problem is actually in offlineimap or in imaplib2, but no
relevant bugs seems to be reported against the latter either.
Thanks for maintaining offlineimap,
Cheers
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 offlineimap depends on:
ii offlineimap3 0.0~git20210105.00d395b+dfsg-2
offlineimap recommends no packages.
offlineimap suggests no packages.
-- no debconf information
Bug#975560: M-x pyvenv-workon fails with "No such file or directory, python"
Package: elpa-pyvenv Version: 1.21-1 Severity: important Since the removal of the /usr/bin/python -> python3 symlink, M-x pyvenv-workon fails with the following error message: zsh:1: command not found: python apply: Searching for program: No such file or directory, python Installing python-is-python3 fixes the issue, but is clearly not the right solution. pyvenv should be able to enter a virtualenv no matter what, given that is where the "right" python version will be found. Thanks a lot for maintaining elpa-pyvenv in Debian! Cheers -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 elpa-pyvenv depends on: ii dh-elpa-helper 2.0.6 ii emacsen-common 3.0.4 ii virtualenv 20.1.0+ds-1 Versions of packages elpa-pyvenv recommends: ii emacs 1:27.1+1-3 ii emacs-gtk [emacs] 1:27.1+1-3 ii virtualenvwrapper 4.8.4-4 elpa-pyvenv suggests no packages. -- no debconf information
Bug#970904: arc diff emits a lot of warnings about implode() PHP function
Package: arcanist Version: 0~git20190207-1 Severity: normal File: /usr/bin/arc Sample output: $ arc diff [2020-09-25 07:38:58] ERROR 8192: implode(): Passing glue string after array is deprecated. Swap the parameters at [/usr/share/libphutil/src/utils/utils.php:1572] arcanist(), phutil() #0 implode(array, string) called at [/src/utils/utils.php:1572] #1 phutil_build_http_querystring(array) called at [/src/future/http/HTTPSFuture.php:526] #2 HTTPSFuture::formatRequestDataForCURL() called at [/src/future/http/HTTPSFuture.php:247] #3 HTTPSFuture::isReady() called at [/src/future/Future.php:37] #4 Future::resolve(NULL) called at [/src/future/FutureProxy.php:34] #5 FutureProxy::resolve() called at [/src/conduit/ConduitClient.php:64] #6 ConduitClient::callMethodSynchronous(string, array) called at [/src/workflow/ArcanistWorkflow.php:332] #7 ArcanistWorkflow::authenticateConduit() called at [/scripts/arcanist.php:356] [2020-09-25 07:38:58] ERROR 8192: implode(): Passing glue string after array is deprecated. Swap the parameters at [/usr/share/libphutil/src/utils/utils.php:1572] arcanist(), phutil() #0 implode(array, string) called at [/src/utils/utils.php:1572] #1 phutil_build_http_querystring(array) called at [/src/future/http/HTTPSFuture.php:526] #2 HTTPSFuture::formatRequestDataForCURL() called at [/src/future/http/HTTPSFuture.php:247] #3 HTTPSFuture::isReady() called at [/src/future/Future.php:37] #4 Future::resolve(NULL) called at [/src/future/FutureProxy.php:34] #5 FutureProxy::resolve() called at [/src/conduit/ConduitClient.php:64] #6 ConduitClient::callMethodSynchronous(string, array) called at [/src/workflow/ArcanistDiffWorkflow.php:1597] #7 ArcanistDiffWorkflow::getCommitMessageFromUser() called at [/src/workflow/ArcanistDiffWorkflow.php:1501] #8 ArcanistDiffWorkflow::buildCommitMessage() called at [/src/workflow/ArcanistDiffWorkflow.php:469] #9 ArcanistDiffWorkflow::run() called at [/scripts/arcanist.php:394] [2020-09-25 07:39:04] ERROR 8192: implode(): Passing glue string after array is deprecated. Swap the parameters at [/usr/share/libphutil/src/utils/utils.php:1572] arcanist(), phutil() #0 implode(array, string) called at [/src/utils/utils.php:1572] #1 phutil_build_http_querystring(array) called at [/src/future/http/HTTPSFuture.php:526] #2 HTTPSFuture::formatRequestDataForCURL() called at [/src/future/http/HTTPSFuture.php:247] #3 HTTPSFuture::isReady() called at [/src/future/Future.php:37] #4 Future::resolve(NULL) called at [/src/future/FutureProxy.php:34] #5 FutureProxy::resolve() called at [/src/conduit/ConduitClient.php:64] #6 ConduitClient::callMethodSynchronous(string, array) called at [/src/differential/ArcanistDifferentialCommitMessage.php:48] #7 ArcanistDifferentialCommitMessage::pullDataFromConduit(ConduitClient) called at [/src/workflow/ArcanistDiffWorkflow.php:1695] #8 ArcanistDiffWorkflow::getCommitMessageFromUser() called at [/src/workflow/ArcanistDiffWorkflow.php:1501] #9 ArcanistDiffWorkflow::buildCommitMessage() called at [/src/workflow/ArcanistDiffWorkflow.php:469] #10 ArcanistDiffWorkflow::run() called at [/scripts/arcanist.php:394] as this is shown in the terminal during interactive use of arc diff, it makes using the tool quite painful at the moment. Cheers -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 arcanist depends on: ii libphutil 0~git20190207-1 ii php-cli 2:7.4+76 ii php-curl2:7.4+76 ii php-xml 2:7.4+76 ii php7.4-cli [php-cli]7.4.9-2 ii php7.4-curl [php-curl] 7.4.9-2 ii php7.4-xml [php-xml]7.4.9-2 arcanist recommends no packages. Versions of packages arcanist suggests: pn python -- no debconf information
Bug#969576: nextcloud-desktop: Main window not visible/constructable
On Wed, Sep 09, 2020 at 07:24:04PM +0200, Paul van Tilburg wrote: > I have to reaffirm that I used an iterative approach to install each of > these to get rid of all warnings and have the main interface appear. > I'm afraid that all dependencies listed above seem necessary, maybe > you had the others for other reasons already? Yeah, it is entirely possible. So please test what is actually needed (e.g., in a fresh debian chroot) rather than relying on my very narrow data point. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#969576: nextcloud-desktop: Main window not visible/constructable
severity serious thanks On Sat, Sep 05, 2020 at 11:59:46AM +0200, Paul van Tilburg wrote: > The upgrade to 3.0 of the Nextcloud client led to the main window not > being visible anymore. It seems that the QT QML modules are missing to > make it work. Consider the warnings in the logs: I can confirm this. I'm raising the severity because the desktop UI is de facto non usable due to this. > After installing the following packages, I can see the main window again > (although it still disappears on me sometimes): > > * qml-module-qtquick-layouts > * qml-module-qtquick-controls2 > * qml-module-qtgraphicaleffects > * qml-module-qtqml-models2 > * qml-module-qtqml Thanks for this. After "apt install"-ing the above packages the issue was fixed for me too. For what is worth, the packages that were *actually* missing on my system prior to the installation were just: qml-module-qtquick-controls2 qml-module-qtquick-templates2 so I'd expect that adding either (if they depend on one another) or both to the package dependencies would fix this issue. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#964334: segfault repeatedly
I've seen this bug has been marked as "more info" (with no comment), but I'm not clear on which additional info are needed and how I can provide them. Advice on how I can help is welcome :-)
Bug#964334: segfault repeatedly
Package: chromium Version: 83.0.4103.116-2 Severity: grave I've upgraded chromium to the current version in testing, and it segfaults repeatedly (and very "reliably"! :-)) after usually ~1 minute of runtime, even when not used in foreground, with a stack trace like this one: - $ chromium (chromium:1480721): Gtk-WARNING **: 21:03:45.963: Theme parsing error: gtk.css:6:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings' [1480760:1480760:0705/210346.245467:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. [1480764:1480779:0705/210348.465499:ERROR:nss_util.cc(283)] After loading Root Certs, loaded==false: NSS error code: -8018 libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space not permitted on grayscale PNG libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space not permitted on grayscale PNG libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile Received signal 11 SEGV_MAPERR 7f01744946c7 #0 0x557d36628c69 (/usr/lib/chromium/chromium+0x52b3c68) #1 0x557d36587ef3 (/usr/lib/chromium/chromium+0x5212ef2) #2 0x557d366287f1 (/usr/lib/chromium/chromium+0x52b37f0) #3 0x7f1a95d8d110 (/usr/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f) #4 0x7f1a90e78d3c (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b) #5 0x7f1a90e7af33 (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32) #6 0x7f1a90e7cbf9 __libc_malloc #7 0x557d366409be operator new() #8 0x7f1a91103a2c std::__cxx11::basic_string<>::reserve() #9 0x7f1a910f9498 std::__cxx11::basic_stringbuf<>::overflow() #10 0x7f1a9110204a std::basic_streambuf<>::xsputn() #11 0x7f1a910f4714 std::__ostream_insert<>() #12 0x557d36628d39 (/usr/lib/chromium/chromium+0x52b3d38) #13 0x557d36629054 (/usr/lib/chromium/chromium+0x52b4053) #14 0x557d3659a412 (/usr/lib/chromium/chromium+0x5225411) #15 0x557d3659c548 (/usr/lib/chromium/chromium+0x5227547) #16 0x557d34ce212a (/usr/lib/chromium/chromium+0x396d129) #17 0x557d34ce217e (/usr/lib/chromium/chromium+0x396d17d) #18 0x557d34337387 (/usr/lib/chromium/chromium+0x2fc2386) #19 0x557d34c9b3d9 (/usr/lib/chromium/chromium+0x39263d8) #20 0x557d34c9b61e (/usr/lib/chromium/chromium+0x392661d) #21 0x557d34ce5967 (/usr/lib/chromium/chromium+0x3970966) #22 0x557d34d114c7 (/usr/lib/chromium/chromium+0x399c4c6) #23 0x557d34d1177e (/usr/lib/chromium/chromium+0x399c77d) #24 0x557d34ce213f (/usr/lib/chromium/chromium+0x396d13e) #25 0x557d34ce217e (/usr/lib/chromium/chromium+0x396d17d) #26 0x557d34337387 (/usr/lib/chromium/chromium+0x2fc2386) #27 0x557d345fa7a3 (/usr/lib/chromium/chromium+0x32857a2) #28 0x557d349690bc (/usr/lib/chromium/chromium+0x35f40bb) #29 0x557d3675a45f (/usr/lib/chromium/chromium+0x53e545e) #30 0x557d36760a24 (/usr/lib/chromium/chromium+0x53eba23) #31 0x557d3675eb62 (/usr/lib/chromium/chromium+0x53e9b61) #32 0x557d3675d82d (/usr/lib/chromium/chromium+0x53e882c) #33 0x557d36756213 (/usr/lib/chromium/chromium+0x53e1212) #34 0x557d36771abb (/usr/lib/chromium/chromium+0x53fcaba) #35 0x557d36771de0 (/usr/lib/chromium/chromium+0x53fcddf) #36 0x557d36771370 (/usr/lib/chromium/chromium+0x53fc36f) #37 0x557d345e3c46 (/usr/lib/chromium/chromium+0x326ec45) #38 0x557d345e376c (/usr/lib/chromium/chromium+0x326e76b) #39 0x557d345dfeed (/usr/lib/chromium/chromium+0x326aeec) #40 0x557d345d674b (/usr/lib/chromium/chromium+0x326174a) #41 0x557d345c9044 (/usr/lib/chromium/chromium+0x3254043) #42 0x557d345c8d75 (/usr/lib/chromium/chromium+0x3253d74) #43 0x557d345e7426 (/usr/lib/chromium/chromium+0x3272425) #44 0x557d366460e0 (/usr/lib/chromium/chromium+0x52d10df) #45 0x7f1a94b42b0f (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7.0.0+0x23b0e) #46 0x7f1a94b4324f event_base_loop #47 0x557d3664638e (/usr/lib/chromium/chromium+0x52d138d) #48 0x557d365e65d5 (/usr/lib/chromium/chromium+0x52715d4) #49 0x557d365be670 (/usr/lib/chromium/chromium+0x524966f) #50 0x557d349043b3 (/usr/lib/chromium/chromium+0x358f3b2) #51 0x557d365fc2a9 (/usr/lib/chromium/chromium+0x52872a8) #52 0x557d36638c9e (/usr/lib/chromium/chromium+0x52c3c9d) #53 0x7f1a95d81f27 start_thread #54 0x7f1a90ef031f clone r8: 0077 r9: 0050 r10: 0004 r11: 007c r12: 7f1a7420 r13: 7f1a7430 r14: 7f1a74736850 r15: 0020 di: 0021 si: 0004 bp: 0020 bx: 7f01744946bf dx: 7f1a7480 ax: 7f1a742d4d90 cx: 7f01744946bf sp: 7f1a826d3440 ip: 7f1a90e78d3c efl: 00010202 cgf: 002b0033 erf: 0004 trp: 000e msk: cr2: 7f01744946c7 [end of stack trace] Calling _exit(1). Core file will not be generated. - Thanks a lot for maintaining chromium in Debian, Hope this helps -- System Information: Debian
Bug#962051: segfault when locking screen
forcemerge 959883 962051 thanks On Tue, Jun 02, 2020 at 09:54:15PM +0100, Simon McVittie wrote: > On Tue, 02 Jun 2020 at 17:22:54 +0200, Stefano Zacchiroli wrote: > > heya, since yesterday under Debian/testing gnome-shell crashes (and then > > restarts) when trying to lock screen. > > This seems like #959883. Please try disabling any extensions you have > enabled, and/or upgrading to the snapshot in experimental. Yup, that was it! I guess I missed it because I've only looked at open bugs, my apologies. Upgrading to the experimental snapshot fixed the issue for me too. Merging/closing. Thanks for your super quick solution! Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#962051: segfault when locking screen
Package: gnome-shell Version: 3.36.2-1 Severity: important heya, since yesterday under Debian/testing gnome-shell crashes (and then restarts) when trying to lock screen. Here's the diagnostic I can find under journalctl: giu 02 17:17:32 noziere kernel: gnome-shell[106365]: segfault at 0 ip 7fb2305fd467 sp 7ffd001db960 error 4 in libst-1.0.so[7fb2305de000+4a000] giu 02 17:17:32 noziere kernel: Code: 00 00 00 48 83 c3 01 41 39 9f 30 01 00 00 0f 8e 2f 01 00 00 49 8b 87 28 01 00 00 48 8d 35 d6 f5 02 00 48 8b 2c d8 48 8b 45 00 <48> 8b 00 4c 8b 20 4c 89 e7 e8 3b 28 fe ff 85 c0 74 c7 41 80 7c 24 giu 02 17:17:32 noziere polkitd(authority=local)[718]: Unregistered Authentication Agent for unix-session:2 (system bus name :1.168, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) giu 02 17:17:32 noziere gsd-media-keys[2202]: Couldn't lock screen: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying giu 02 17:17:32 noziere systemd[1768]: gnome-shell-x11.service: Main process exited, code=killed, status=11/SEGV giu 02 17:17:32 noziere systemd[1768]: gnome-shell-x11.service: Failed with result 'signal'. giu 02 17:17:32 noziere systemd[1768]: gnome-shell-x11.service: Scheduled restart job, restart counter is at 11. giu 02 17:17:32 noziere systemd[1768]: Stopped target GNOME X11 Session (session: gnome). giu 02 17:17:32 noziere systemd[1768]: Stopping GNOME X11 Session (session: gnome). giu 02 17:17:32 noziere systemd[1768]: Stopped target GNOME X11 Session. giu 02 17:17:32 noziere systemd[1768]: Stopping GNOME X11 Session. giu 02 17:17:32 noziere systemd[1768]: Stopped target GNOME Shell on X11. giu 02 17:17:32 noziere systemd[1768]: Stopping GNOME Shell on X11. giu 02 17:17:32 noziere systemd[1768]: Stopped GNOME Shell on X11. giu 02 17:17:32 noziere systemd[1768]: Starting GNOME Shell on X11... It happens systematically, both when trying to lock screen on demand (Ctrl+Alt+L) and when the laptop suspends (meaning that when it wakes up the desktop is happily unlocked... this might make this bug warrant a security + severity bump: I'll let this up to the maintainers to decide). As shown above the shell immediately restarts afterwards, without causing any session disruption/logout/etc. Thanks for maintaining GNOME in Debian! Cheers -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii evolution-data-server3.36.2-1 ii gir1.2-accountsservice-1.0 0.6.55-2 ii gir1.2-atspi-2.0 2.36.0-2 ii gir1.2-freedesktop 1.64.1-1 ii gir1.2-gcr-3 3.36.0-2 ii gir1.2-gdesktopenums-3.0 3.36.1-1 ii gir1.2-gdm-1.0 3.34.1-3 ii gir1.2-geoclue-2.0 2.5.6-1 ii gir1.2-glib-2.0 1.64.1-1 ii gir1.2-gnomebluetooth-1.03.34.1-1 ii gir1.2-gnomedesktop-3.0 3.36.2-1 ii gir1.2-gtk-3.0 3.24.20-1 ii gir1.2-gweather-3.0 3.36.0-1 ii gir1.2-ibus-1.0 1.5.22-5 ii gir1.2-mutter-6 3.36.2-3 ii gir1.2-nm-1.01.24.0-1 ii gir1.2-nma-1.0 1.8.28-2 ii gir1.2-pango-1.0 1.44.7-4 ii gir1.2-polkit-1.00.105-26 ii gir1.2-rsvg-2.0 2.48.4+dfsg-1 ii gir1.2-soup-2.4 2.70.0-1 ii gir1.2-upowerglib-1.00.99.11-2 ii gjs 1.64.2-1 ii gnome-backgrounds3.36.0-1 ii gnome-settings-daemon3.36.1-1 ii gnome-shell-common 3.36.2-1 ii gsettings-desktop-schemas3.36.1-1 ii libatk-bridge2.0-0 2.34.1-3 ii libatk1.0-0 2.36.0-2 ii libc62.30-8 ii libcairo21.16.0-4 ii libecal-2.0-13.36.2-1 ii libedataserver-1.2-243.36.2-1 ii libgcr-base-3-1 3.36.0-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-4 ii libgirepository-1.0-
Bug#961638: proposal: stocat - probabilistic cat
Package: moreutils
Version: 0.63-1+b1
Severity: wishlist
Tags: patch upstream
I'm hereby proposing the inclusion of the attached "stocat" utility to
moreutils. It's like cat, but output lines with a given probability, defaulting
to 10%. It's very useful for random sampling (and *much* more efficient at that
than using "shuf" which is unwieldy on very large inputs) and, while it can be
implemented instead with awk/perl oneliners, those oneliners aren't very
mnemonic and are error prone.
If desired, it could be extended by adding a reservoir sampling option, to
guarantee a selection of exactly K items.
Thanks a lot for moreutils!
Cheers
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages moreutils depends on:
ii libc6 2.30-8
ii libipc-run-perl20200505.0-1
ii libtime-duration-perl 1.21-1
ii libtimedate-perl 2.3200-1
ii perl 5.30.2-1
moreutils recommends no packages.
moreutils suggests no packages.
-- no debconf information
#!/usr/bin/perl
=head1 NAME
stocat - stochastic cat, selecting lines with uniform probability
=head1 SYNOPSIS
=over
=item B [B<-p>|B<--probability> PROBABILITY] [I|B<->]...
=back
=head1 DESCRIPTION
Concatenate FILE(s) to standard output, but printing each input line to output
only with a given probability, defaulting to 0.1 (i.e., 10%).
With no FILE or when FILE is B<->, read standard input.
=head1 OPTIONS
=over 4
=item -p, --probability
Output lines with the given probability, specified as a number between 0 (0%
probability) and 1 (100% probability). Default: 0.1 (i.e., 10% probability).
=back
=head1 SEE ALSO
L
=head1 AUTHOR
Copyright 2020 by Stefano Zacchiroli
Licensed under the GNU GPL.
=cut
use Getopt::Long;
sub die_usage() {
die "Usage: $0 [--probability|-p PROBABILITY] [file|-]\n";
}
my $probability = 0.1;
if (! GetOptions("probability|p=f" => \$probability)) {
die_usage();
}
if ($probability < 0 || $probability > 1) {
die_usage();
}
while (<>) {
print $_ if rand() <= $probability;
}
Bug#952465: please set debian-project@lists.d.o as moderated
Package: lists.debian.org Severity: normal Dear listmasters, in light of repeated trolling and abuse targeting individual Debian contributors distributed via debian-project@lists.d.o, I'd like to ask for that mailing list to be set to moderated for the time being. A group of more than 30 Debian project members have volunteered to share the burden of moderating the list. Once this bug report is accepted by the BTS, I'll followup to the listmaster contact address with the list of moderators email addresses and account names. Thanks a lot for your work on Debian mailing lists, (which has certainly being unduly tiresome in recent times,) Cheers -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#952449: please shipe "tlsh" binary and manpage
Package: tlsh-tools Version: 3.4.4+20151206-1.3+b1 Severity: minor Tags: patch Heya, it's a bit weird that the main binary for this package is called "tlsh_unittest". The upstream doc has this to say on the matter: Building TLSH (see below) will create a static library in the lib directory, and the tlsh executable (a symbolic link to tlsh_unittest). but that's indeed not true :-). The symbolic link is *not* built and hence not shipped by the Debian package. But it would be *nice* to ship it! So please find attached a .links file that, if dropped into the debian/ dir, will make the tlsh-tools package ship /usr/bin/tlsh (as a symbolic link) and its manpage. Can you consider applying it? Thanks a lot for maintaining tlsh in Debian, Cheers -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tlsh-tools depends on: ii libc62.29-10 ii libgcc-s1 [libgcc1] 10-20200211-1 ii libgcc1 1:10-20200211-1 ii libstdc++6 10-20200211-1 ii libtlsh0 3.4.4+20151206-1.3+b1 tlsh-tools recommends no packages. tlsh-tools suggests no packages. -- no debconf information usr/bin/tlsh_unittest usr/bin/tlsh usr/share/man/man1/tlsh_unittest.1 usr/share/man/man1/tlsh.1
Bug#928073: unblock: beancount/2.2.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package beancount
Santiago Villa has discovered an unpredictability in the cleanup of a gnupg
socket file, which might randomly make the package FTBFS. The version I've just
uploaded to unstable includes a patch by Santiago that fixes this. It would be
nice to have this fix in testing, to make rebuilding the next stable release
more predicatble.
debdiff attached.
unblock beancount/2.2.0-3
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru beancount-2.2.0/debian/changelog beancount-2.2.0/debian/changelog
--- beancount-2.2.0/debian/changelog2019-01-14 10:01:37.0 +0100
+++ beancount-2.2.0/debian/changelog2019-04-21 17:00:36.0 +0200
@@ -1,3 +1,11 @@
+beancount (2.2.0-3) unstable; urgency=medium
+
+ [ Santiago Vila ]
+ * patches/0003: Ignore FileNotFoundError from self.tmpdir.cleanup().
+Fixes a FTBFS problem which happens randomly (Closes: #923606)
+
+ -- Stefano Zacchiroli Sun, 21 Apr 2019 17:00:36 +0200
+
beancount (2.2.0-2) unstable; urgency=medium
* rules: do not ship *.picklecache files with Python examples (fixes
diff -Nru
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
---
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
1970-01-01 01:00:00.0 +0100
+++
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
2019-04-21 17:00:36.0 +0200
@@ -0,0 +1,18 @@
+From: Santiago Vila
+Date: Sun, 21 Apr 2019 16:48:40 +0200
+Subject: Ignore FileNotFoundError from self.tmpdir.cleanup()
+
+--- a/beancount/utils/encryption_test.py
b/beancount/utils/encryption_test.py
+@@ -98,7 +98,10 @@
+ self.run_gpg('--import', stdin=TEST_SECRET_KEY.encode('ascii'))
+
+ def tearDown(self):
+-self.tmpdir.cleanup()
++try:
++self.tmpdir.cleanup()
++except FileNotFoundError:
++pass
+
+ def run_gpg(self, *args, **kw):
+ command = ('gpg',
diff -Nru beancount-2.2.0/debian/patches/series
beancount-2.2.0/debian/patches/series
--- beancount-2.2.0/debian/patches/series 2019-01-14 10:01:37.0
+0100
+++ beancount-2.2.0/debian/patches/series 2019-04-21 17:00:36.0
+0200
@@ -1,2 +1,3 @@
0001-Remove-fonts.googleapis.com-links-for-the-bean-web-t.patch
0002-make-test_version-more-lax-to-accept-non-git-hg-vers.patch
+0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
Bug#923606: beancount: FTBFS randomly (gpg-related race condition)
On Sun, Apr 21, 2019 at 05:52:36PM +0200, Santiago Vila wrote: > In other words: My "merge request" is below. Thanks Santiago, patch applied --- both in the master branch in git and in a dedicated minimal upload targeting sid. I'll request an unblock as soon as the upload hits the archive. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#927070: ITP: ledger2beancount -- Convert Ledger-based textual ledgers to Beancount ones
Thanks Jelmer ! :-) On April 14, 2019 6:49:26 PM GMT+02:00, Jelmer Vernooij wrote: >Package: wnpp >Severity: wishlist >Owner: Jelmer Vernooij > >* Package name: ledger2beancount > Version : 1.6 > Upstream Author : Stefano Zacchiroli >Martin Michlmayr >* URL : https://github.com/zacchiro/ledger2beancount >* License : GPLv3 > Programming Lang: Perl >Description : Convert Ledger-based textual ledgers to Beancount >ones > >A script to automatically convert Ledger-based textual ledgers to >Beancount >ones. > >Conversion is based on (concrete) syntax, so that information that is >not >meaningful for accounting reasons but still valuable (e.g., comments, >formatting, etc.) can be preserved. -- Sent from my mobile phone. Please excuse my brevity and top-posting.
Bug#923606: beancount: FTBFS randomly (gpg-related race condition)
Hi Santiago, On Tue, Apr 09, 2019 at 10:38:10AM +0200, Santiago Vila wrote: > I obviously have interest to fix this before the release, because I > can build 99.99% of packages in my setup and this is an inconvenient > exception for me. I don't like NMUs. Should I join the Python > Applications Packaging Team? Please tell me how I would proceed. either way is fine, and also just submitting a merge request would do (although please let this bug log know if you do so, to make sure it doesn't get overlooked). Thanks! -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#923606: beancount: FTBFS randomly (gpg-related race condition)
Hi Santiago, On Tue, Mar 05, 2019 at 10:52:47AM +0100, Santiago Vila wrote: > Also, I hope you will surely agree that telling me that you can build > the package in your computer does not help me at all to build the > package in my computer. In this case I'm just doing QA, but if I > wanted to modify the software, the end result is that I could not. sure, I agree with you on this, and I'm also very grateful for the QA work you're doing. > So, while we are not violating the DFSG in strict sense, as we are > still distributing the source, the user still can't exercise their > right to modify the software in practical terms. Here is where I disagree with you, on the perceived severity of this issue. I still haven't seen any other build setup than yours where this build failure happens. So, while I totally trust you and concede that my view of the matter might be biased; I think yours might be too, in the opposite sense. Hence, as an independent test, I'm relying on the official Debian build infrastructure (and associated services, like reproducible build), as a proxy of what users are most likely to encounter when trying to rebuild the package. That's all I'm saying. If you disagree with this, which is totally fine, the severity can be raised and I'll happily punt to the release team to decide what to do with beancount. > (I'm not changing the severity, and I'm still offering a test machine > for you to reproduce the issue if you need it). Thanks a lot for this. I don't think it's needed to determine the actual fix, which is fairly obvious. My main issue is that I also want to update to latest upstream release for the next package upload, which is a minor version update, but in which the code layout changed a bit, requiring other changes in the packaging. I will not have time to do so in time for the freeze, so I'm just trying to postpone this work post-freeze, and I'll address this then. If you, or others, have time and interest to fix this before, by all means go ahead. The package is team-maintained, and I'm very happy to receive useful NMUs to "my" packages anyway. I hope this clarifies, Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#923606: beancount: FTBFS randomly (gpg-related race condition)
severity -1 important thanks Hi Santiago, On Sat, Mar 02, 2019 at 06:03:10PM +, Santiago Vila wrote: > I tried to build this package in buster but it failed: > [...] > try: > > os.unlink(entry.name, dir_fd=topfd) > E FileNotFoundError: [Errno 2] No such file or directory: > 'S.gpg-agent.browser' [...] > The above is just how the build ends and not necessarily the most relevant > part, > so I've put a bunch of failed build logs here: > > https://people.debian.org/~sanvila/build-logs/beancount/ > > The failure happens randomly. Sometimes it happens, sometimes it does not, > but the failure rate is so high that we can't really say that the package > "builds from source and without failure". thanks for this bug report, I had no idea about this flakiness in the build. > This failure is similar to another one which I reported before in another > package: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906335 > > but I'm not really sure if that helps. > > If you need a test machine where this happens almost all the time, please > contact me > privately and I will gladly offer ssh access. Similarly to the other bug you mention, I think the incidence of this FTBFS is low... at least elsewhere w.r.t. your build environment. I've personal never witnessed this, and I'm aware of a bunch of other people who have built from scratch without issues. More to the point, reproducible building the package is working fine on at least four architectures, including the one you are testing on: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/beancount.html On that basis, I'm lowering the priority to important. Still, I think the bug should be fixed, and I will do so (most likely ignoring the rm error, as that means no cleanup is needed). But I will not necessarily do this in time for the next release. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#918641: pkg_resources.DistributionNotFound: The 'cheroot' distribution was not found and is required by fava
Package: python3-fava Version: 1.9-3 Severity: serious As per subject, running fava fails with the following traceback: Traceback (most recent call last): File "/usr/bin/fava", line 6, in from pkg_resources import load_entry_point File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3126, in @_call_aside File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3110, in _call_aside f(*args, **kwargs) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3139, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 581, in _build_master ws.require(__requires__) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 898, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 784, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'cheroot' distribution was not found and is required by fava this should ideally be fixed by having cheroot ship an egg-info dir, but it's being filed against fava for now to avoid testing migration. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-fava depends on: ii python3 3.7.1-3 ii python3-babel2.6.0+dfsg.1-1 ii python3-beancount2.1.3+hg20181225-3 ii python3-click6.7+git20180829-1 ii python3-flask1.0.2-3 ii python3-flask-babel 0.11.2-2 ii python3-jinja2 2.10-1 ii python3-markdown22.3.7-1 ii python3-ply 3.11-3 ii python3-simplejson 3.15.0-1+b1 python3-fava recommends no packages. python3-fava suggests no packages. -- no debconf information
Bug#917954: fava: Incomplete debian/copyright?
On Tue, Jan 01, 2019 at 03:07:02PM +, Chris Lamb wrote: > I just ACCEPTed fava from NEW but noticed it was missing attribution > in debian/copyright for at least some code embedded in fava/static/gen/app.js. > > This is in no way exhaustive so please check over the entire package > carefully and address these on your next upload. Thanks, nice catch. I've fixed this specific occurrence (in git) and looked for others, without finding any. I'm postponing package upload, waiting for beancount (a fava dependency) to clear NEW too. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
tag 917532 + pending thanks Fava is now in NEW. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
On Sun, Dec 30, 2018 at 01:24:23AM +0100, Pierre-Elliott Bécue wrote: > I think a webserver config + WSGI handling is quite overkill. Do you agree? Yeah, I agree. Upstream is reluctant to even document easy setup recipes on the basis that Fava is essentially a personal service. I've myself setup a "public" Fava, behind HTTPS auth of course, but I see value in not making it "too easy" in this case, for fear of unsavvy users leaking personal information out of the box. If anything, we should work with upstream on the deployment documentation side, and make sure said documentation is shipped with the package. Cheers PS I commented on IRC about that, but FWIW: I think the reference on the package description to "beancount" as package name is correct, because there is such a binary package and it is the end-user oriented entry point to Beancount in Debian -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
On Sat, Dec 29, 2018 at 09:11:23PM +0100, Pierre-Elliott Bécue wrote: > It's in new now. :) Thanks! :-) -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
Looks like a fava dependency is missing in Debian: [python3-]markdown2, https://pypi.org/project/markdown2/ (There's python3-markdown in the archive, but that's a different one: https://pypi.org/project/Markdown/) Volunteers to package markdown2 are welcome; I'm not going to package it myself. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
A package skeleton is now available on salsa: https://salsa.debian.org/python-team/applications/fava Help and co-maintainers are welcome. (It's not clear to me if I should do anything else, other than creating the project on salsa, to make sure other members of PAPT can directly commit to the repo. If so, I'd appreciate someone letting me know.) Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
Package: wnpp Severity: wishlist * Package name: fava Version : 1.9 Upstream Author : Dominik Aumayr * URL : https://beancount.github.io/fava/ * License : MIT Programming Lang: Python Description : web interface for the Beancount accounting tool Fava is a web interface for the double-entry bookkeeping software Beancount with a focus on features and usability. Beancount is packaged in Debian as "beancount".
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
The package is now sitting in NEW, waiting to land in experimental. I've also pushed a couple of minor improvements on salsa, waiting for the next upload. As soon as it passes NEW, I plan to upload again to unstable, hoping to make the freeze cut (you never know... :-)) Please let me know if you have objections and please test the package and let this bug report know if you encounter any showstopper. For my part I've migrated my local use of beancount to the current version of the package and it is working just fine for my needs. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
On Mon, Dec 24, 2018 at 07:30:31PM +0200, Martin Michlmayr wrote: > So this issue was reported and fixed already upstream: > > Here's the original bug report: > > https://bitbucket.org/blais/beancount/issues/341/test_utilsfind_repository_root-doesnt-work Thanks Martin for finding this, and thanks James for raising it upstream after last time I tried it out. I've updated the package to a hg snapshot of today (which includes the commits with the fix, and more). The source package as it is on salsa now builds fine on a fresh unstable chroot. Testing welcome. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
On Sun, Dec 09, 2018 at 05:23:35PM +0200, Martin Michlmayr wrote: > Is the delay because of the test failures mentioned by Zack? The main current issue is that several tests, at least when run under sbuild/cowbuilder, enters infinite loops stat()-ing forever "/PKG-INFO". I have been unable to find the cause, but it's somewhat specific to the Debian build environment in conjunction with pytest. In addition to that there are some test failures too, but they look easy to fix (and the patches should probably be sent upstream for integration). I don't see myself having more time than I already devoted to this in time for the next freeze. But if you're up to tackling this, I can provide more info, e.g., I've a list of the affected tests, in case it might help finding a pattern. The *general* pattern is that tests that exec() stuff are impacted, but it's not specific enough (at least for me) to pinpoint the issue. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
I've updated the package at
https://salsa.debian.org/python-team/applications/beancount to match
latest release (2.1.2) + mercurial snapshot and fixed one failing test.
Two tests still fail.
The corresponding functionalities work in the package after installed.
Also, they fail in very weird ways, only under python3.7, which are not
reproducible outside the package build environment.
I'm tempted to just push the attached patch to ignore the two tests and
upload. That will give us some user testing time before buster is frozen
and, when 3.7 become the default, reassess whether the tests still fail
or not.
Thoughts?
--
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
From: Stefano Zacchiroli
Date: Mon, 1 Oct 2018 22:58:39 +0200
Subject: ignore tests that fail with pytest 3.7 in a 3.6 environment
the tests runs fine outside the build process and the corresponding
functionalities work when the package is installed
---
beancount/ingest/identify_test.py | 2 ++
beancount/scripts/tutorial_test.py | 2 ++
2 files changed, 4 insertions(+)
diff --git a/beancount/ingest/identify_test.py b/beancount/ingest/identify_test.py
index f6689da..2d37cb6 100644
--- a/beancount/ingest/identify_test.py
+++ b/beancount/ingest/identify_test.py
@@ -4,6 +4,7 @@ __license__ = "GNU GPLv2"
from os import path
from unittest import mock
import os
+import pytest
import re
import subprocess
import sys
@@ -72,6 +73,7 @@ class TestScriptIdentifyFunctions(test_utils.TestTempdirMixin, unittest.TestCase
class TestScriptIdentify(scripts_utils.TestScriptsBase):
+@pytest.mark.skip
def test_identify(self):
regexp = textwrap.dedent("""\
\*\*\*\* .*/Downloads/ofxdownload.ofx
diff --git a/beancount/scripts/tutorial_test.py b/beancount/scripts/tutorial_test.py
index e2b3e32..6dcb5c2 100644
--- a/beancount/scripts/tutorial_test.py
+++ b/beancount/scripts/tutorial_test.py
@@ -2,6 +2,7 @@ __copyright__ = "Copyright (C) 2014, 2016 Martin Blais"
__license__ = "GNU GPLv2"
import os
+import pytest
import shutil
import tempfile
from os import path
@@ -12,6 +13,7 @@ from beancount.scripts import tutorial
class TestTutorial(test_utils.TestCase):
+@pytest.mark.skip
def test_generate_tutorial(self):
rootdir = test_utils.find_repository_root(__file__)
example_beancount = path.join(rootdir, 'examples', 'example.beancount')
Bug#907165: package installation fails with "ERROR: install script from ess package failed"
On Fri, Aug 24, 2018 at 06:40:24AM -0500, Dirk Eddelbuettel wrote: > and it is as 17.11-4 in 'experimental' (I was debating dropping it into [...] > Can you try the 'elpa-ess' and 'ess' (transition) package set, please? > >https://packages.debian.org/source/experimental/ess I can confirm that installing elpa-ess 17.11-4 for experimental worked just fine. Thanks! -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#907165: package installation fails with "ERROR: install script from ess package failed"
Package: ess Version: 17.11-3 Severity: serious scaramouche $ sudo dpkg --configure ess Setting up ess (17.11-3) ... Install emacsen-common for emacs25 emacsen-common: Handling install of emacsen flavor emacs25 Install ess for emacs25 install/ess: Handling install for emacsen flavor emacs25 ERROR: install script from ess package failed dpkg: error processing package ess (--configure): installed ess package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: ess I've noticed the above failure while upgrading testing. I've tried removing (worked) and installing from scratch (failed in the same way as above). Previous version in testing was working fine. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ess depends on: ii dpkg1.19.0.5+b1 ii emacsen-common 2.0.8 ii install-info6.5.0.dfsg.1-4 Versions of packages ess recommends: ii r-base-core 3.5.1-1+b1 Versions of packages ess suggests: pn jags pn julia pn pspp pn xlispstat -- no debconf information
Bug#873335: please ship full (org-mode) documentation as part of the binary package
Package: elpa-magithub Version: 0.1.3-1 Severity: normal magithub comes with a nice extended documentation, which can be seen rendered here https://github.com/vermiculus/magithub/blob/master/magithub.org , but is also available as an org-mode file in the upstream tarball (and Debian source package). It would be nice to ship that org-mode file under /usr/share/doc/, as the currently shipped README file is really minimal. As this package is for Emacs user, I suspect that just shipping the .org file should be enough, no need to render it (e.g., to HTML) during build, IMHO. Thanks for maintaining magithub in Debian! Cheers. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages elpa-magithub depends on: ii elpa-ghub+ 0.1.4-2 ii elpa-magit 2.10.3-1 ii elpa-s 1.11.0-4 ii emacsen-common 2.0.8 Versions of packages elpa-magithub recommends: ii emacs 47.0 elpa-magithub suggests no packages. -- no debconf information
Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
Hi Adrian,
On Mon, Mar 20, 2017 at 02:18:27AM -0300, Adrian Alves wrote:
> Pass is a simple password store. This fork changes a few
> things while trying to maintain most of it intact,
> specially the core idea. I will keep pulling pass commits,
> and also pushing my modifications to them.
as a pass user, I'm interesting in having a look at this. However, the
description is not particularly telling about what are the differences
("a few things" :-)) and why this fork exists. Can you update the
description of the final package to address this?
TIA,
Cheers.
--
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: PGP signature
Bug#856020: mktexpk: don't know how to create bitmap font for txsys
On Fri, Feb 24, 2017 at 01:25:35PM +0100, Hilmar Preuße wrote: > Missed one: Could you temporarily rename that file and try again? > /home/zack/.texlive2016/texmf-var/fonts/map/pdftex/updmap/pdftex.map Moving it away fixed the issue. Thanks! Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#856020: mktexpk: don't know how to create bitmap font for txsys
First of all thanks for your quick feedback, Hilmar! On Fri, Feb 24, 2017 at 11:33:48AM +0100, Hilmar Preuße wrote: > I've no clue why mktexpk is even started, as the txsys is available as type1 > font. The MWE works fine on my box. Please enter a few commands and send the > output: > > locate txsys > grep txsys /usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex* > grep txsys /var/lib/texmf/fonts/map/pdftex/updmap/pdftex* zack@timira:~$ locate txsys /home/srv/src/unix-history-repo/sys/boot/i386/btx/lib/btxsys.s /home/srv/src/unix-history-repo/sys/boot/pc98/btx/lib/btxsys.s /usr/share/texlive/texmf-dist/fonts/tfm/public/newtx/txsys.tfm /usr/share/texlive/texmf-dist/fonts/type1/public/newtx/txsys.pfb zack@timira:~$ grep txsys /usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex* /usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex_dl14.map:txsys txsys
Bug#856020: mktexpk: don't know how to create bitmap font for txsys
Package: texlive-fonts-extra
Version: 2016.20170123-3
Severity: serious
Heya, the version of texlive-fonts-extra currently in Debian/etxting causes
failure in building (with pdflatex) LaTeX files that use the "txsys" font. See
below for a minimal example, and the attached .fls and .tex files.
The error message is:
kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 0+540/600 --dpi 540
txsys
mktexpk: don't know how to create bitmap font for txsys.
mktexpk: perhaps txsys is missing from the map file.
kpathsea: Appending font creation commands to missfont.log.
)
!pdfTeX error: pdflatex (file txsys): Font txsys at 540 not found
==> Fatal error occurred, no output PDF file produced!
I've tried both package version -3 (currently in testing) and -4 (in unstable,
waiting for unblock), and they both fail in the same way.
Suggestions on how to temporarily work-around this issue are very welcome, as
it's blocking for me.
With many thanks for your help and for maintaining TeXLive in Debian!
Cheers.
-- Package-specific info:
##
\documentclass[sigconf]{acmart}
\begin{document}
Lorem Ipsum
\begin{itemize}
\item foo
\end{itemize}
\end{document}
##
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages texlive-fonts-extra depends on:
ii fonts-cabin1.5-2
ii fonts-comfortaa2.003-1
ii fonts-croscore 20161116-1
ii fonts-crosextra-caladea20130214-1
ii fonts-crosextra-carlito20130920-1
ii fonts-dejavu-core 2.37-1
ii fonts-dejavu-extra 2.37-1
ii fonts-ebgaramond 0.016-1
ii fonts-ebgaramond-extra 0.016-1
ii fonts-font-awesome 4.7.0~dfsg-1
ii fonts-freefont-otf 20120503-6
ii fonts-freefont-ttf 20120503-6
ii fonts-gfs-artemisia1.1-5
ii fonts-gfs-complutum1.1-6
ii fonts-gfs-didot1.1-6
ii fonts-gfs-neohellenic 1.1-6
ii fonts-gfs-olga 1.1-5
ii fonts-gfs-solomos 1.1-5
ii fonts-junicode 0.7.8-2
ii fonts-lato 2.0-1
ii fonts-linuxlibertine 5.3.0-2
ii fonts-lobstertwo 2.0-2
ii fonts-noto-hinted 20161116-1
ii fonts-oflb-asana-math 000.907-6
ii fonts-roboto-hinted2:0~20160106-2
ii fonts-sil-gentium 20081126:1.03-1
ii fonts-sil-gentium-basic1.1-7
ii fonts-sil-gentiumplus 5.000-1
ii fonts-sil-gentiumplus-compact 5.000-2
ii fonts-stix 1.1.1-4
ii tex-common 6.06
ii texlive-base 2016.20170123-3
ii ttf-adf-accanthis 0.20090423-2
ii ttf-adf-gillius0.20090423-2
ii ttf-adf-universalis0.20090423-2
Versions of packages texlive-fonts-extra recommends:
ii texlive-fonts-extra-doc 2016.20170123-3
ii texlive-latex-extra 2016.20170123-3
Versions of packages texlive-fonts-extra suggests:
pn cm-super
Versions of packages tex-common depends on:
ii dpkg 1.18.22
ii ucf 3.0036
Versions of packages tex-common suggests:
ii debhelper 10.2.5
Versions of packages texlive-fonts-extra is related to:
ii tex-common6.06
ii texlive-binaries 2016.20160513.41080.dfsg-1
-- debconf information:
tex-common/check_texmf_missing:
tex-common/check_texmf_wrong:
\documentclass[sigconf]{acmart}
\begin{document}
Lorem Ipsum
\begin{itemize}
\item foo
\end{itemize}
\end{document}
PWD /tmp
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
INPUT txsys-missing-from-map-file.tex
OUTPUT txsys-missing-from-map-file.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/acmart/acmart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/acmart/acmart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkeyval.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkvutils.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/keyval.tex
INPUT /usr/share/texlive/texmf-dist/tex/latex/amscls/amsart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/amscls/amsart.cls
INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr9.tfm
INPUT /usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/
Bug#851974: choice of "gnome classic" session sticks, and make it impossible to go back to default "gnome" session
Package: gdm3 Version: 3.22.1-1 Severity: important Heya, yesterday evening my GNOME session (the default one) didn't want to start properly, and just left me with the screen background after login - no Shell, no anything else. So I've tried logging in choosing the "GNOME Classic" session (not the metacity one, the one based on GNOME Shell, but the panel-like look & feel). It worked properly, and still does. The problem is I can no longer go back to the "GNOME" session: when I choose it upon login, I still get the "GNOME Classic" session, and I've no idea about how to go back to the default GNOME session. Any idea of how to fix and/or further debug this? TIA, Cheers PS I'm not entirely sure it's GDM's fault. It might be gnome-session, gnome-shell, or something else. Feel free to reassign as needed. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gdm3 depends on: ii accountsservice 0.6.43-1 ii adduser 3.115 ii awesome [x-window-manager] 3.5.9-1 ii dconf-cli0.26.0-2 ii dconf-gsettings-backend 0.26.0-2 ii debconf [debconf-2.0]1.5.59 ii gir1.2-gdm-1.0 3.22.1-1 ii gnome-session [x-session-manager]3.22.2-1 ii gnome-session-bin3.22.2-1 ii gnome-session-flashback [x-session-manager] 3.22.0-3 ii gnome-settings-daemon3.22.1-1 ii gnome-shell 3.22.2-1 ii gnome-terminal [x-terminal-emulator] 3.22.1-1 ii gsettings-desktop-schemas3.22.0-1 ii libaccountsservice0 0.6.43-1 ii libaudit11:2.6.7-1 ii libc62.24-8 ii libcanberra-gtk3-0 0.30-3 ii libcanberra0 0.30-3 ii libgdk-pixbuf2.0-0 2.36.3-1 ii libgdm1 3.22.1-1 ii libglib2.0-0 2.50.2-2 ii libglib2.0-bin 2.50.2-2 ii libgtk-3-0 3.22.6-1 ii libkeyutils1 1.5.9-9 ii libpam-modules 1.1.8-3.5 ii libpam-runtime 1.1.8-3.5 ii libpam-systemd 232-8 ii libpam0g 1.1.8-3.5 ii librsvg2-common 2.40.16-1 ii libselinux1 2.6-3 ii libsystemd0 232-8 ii libwrap0 7.6.q-26 ii libx11-6 2:1.6.4-2 ii libxau6 1:1.0.8-1 ii libxdmcp61:1.1.2-1.1 ii lsb-base 9.20161125 ii metacity [x-window-manager] 1:3.22.1-1 ii mutter [x-window-manager]3.22.2-3 ii policykit-1 0.105-17 ii ucf 3.0036 ii x11-common 1:7.7+18 ii x11-xserver-utils7.7+7 ii xterm [x-terminal-emulator] 327-2 Versions of packages gdm3 recommends: ii at-spi2-core2.22.0-5 ii desktop-base9.0.0 ii x11-xkb-utils 7.7+3 ii xserver-xephyr 2:1.19.0-3 ii xserver-xorg1:7.7+18 ii zenity 3.22.0-1 Versions of packages gdm3 suggests: ii gnome-orca3.22.2-1 ii libpam-gnome-keyring 3.20.0-3 -- Configuration Files: /etc/gdm3/daemon.conf changed: [daemon] WaylandEnable=false [security] [xdmcp] [greeter] [chooser] [debug] -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3
Bug#846476: apt: fill up disk space with many /var/lib/apt/lists/partial/*.FAILED files
Package: apt Version: 1.0.9.8.3 Severity: important Heya, I've just cleand up ~12 GB of /var/lib/apt/lists/partial/*.FAILED (on a 20GB partition :-)) and I wonder what apt could do better in order to avoid similar situations. Some details: those *.FAILED files are due to hash mismatches when periodically consulting httpredir.debian.org, due to unattended-upgrades cron job. Of course the update failures there are not apt's fault. Most of the files seem to be diffs to Packages, Sources, or Translation files, with the former dominating disk space consumption. OTOH, neither "apt-get clean" nor the daily apt cron job seem to clean up *.FAILED files, that stay around for at least several months (I've seen in there files as old as early September). Maybe either, or both, of the clean action of apt and its cron job can be modified to cater for cleaning up and avoiding filling the disk? Many thanks in advance for your consideration, and for maintaining apt! Cheers. -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages apt depends on: ii debian-archive-keyring 2014.3 ii gnupg 1.4.18-7+deb8u3 ii libapt-pkg4.12 1.0.9.8.3 ii libc6 2.19-18+deb8u6 ii libgcc1 1:4.9.2-10 ii libstdc++6 4.9.2-10 apt recommends no packages. Versions of packages apt suggests: pn apt-doc ii aptitude0.6.11-1+b1 ii dpkg-dev1.17.27 ii python-apt 0.9.3.12 -- no debconf information
Bug#844201: debsources: updater broken by recent (Sources.gz removal, maybe sha1 removal) dak changes
Package: qa.debian.org Severity: serious User: qa.debian@packages.debian.org Usertags: debsources Context is: https://lists.debian.org/debian-devel-announce/2016/11/msg5.html Here are some relevant entries from debsources.log: Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Errors: Download of dists/squeeze-lts/Release failed Ignoring failed Release files Ignoring missing Release file for dists/sid/main/source/Sources.gz Ignoring missing Release file for dists/sid/contrib/source/Sources.gz Ignoring missing Release file for dists/sid/non-free/source/Sources.gz Ignoring missing Release file for dists/squeeze-lts/main/source/Sources.gz Ignoring missing Release file for dists/squeeze-lts/contrib/source/Sources.gz Ignoring missing Release file for dists/squeeze-lts/non-free/source/Sources.gz Ignoring missing Release file for dists/experimental/main/source/Sources.gz Ignoring missing Release file for dists/experimental/contrib/source/Sources.gz Ignoring missing Release file for dists/experimental/non-free/source/Sources.gz /srv/debsources/bin/debsources-main: I: debsources-update... Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#842353: confusing naming of newcomer bug sections
Package: how-can-i-help Version: 14 Severity: minor Heya, when running how-can-i-help I see multiple sections listing newcomer bugs, and most notably: - Bugs suitable for new contributors (tagged 'newcomer'): - Bugs affecting Debian infrastructure (tagged 'newcomer'): That is a bit confusing, because the heading of the first section hints at listing *all* newcomer bugs, while the heading of the second only a specific sub-class (without being a subsection of the previous section). The first section might be listing only package-related bugs, but I'm not sure. If so the first section could be renamed to mention "packages" somewhere. Alternatively one might introduce subsections, with a macro-section about "newcomers", and two subsections about packages/infrastructure. With many thanks for maintaining how-can-i-help! Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages how-can-i-help depends on: ii ruby 1:2.3.0+4 ii ruby-debian 0.3.9+b6 ii ruby-json2.0.1+dfsg-2 how-can-i-help recommends no packages. how-can-i-help suggests no packages. -- no debconf information
Bug#839190: wordpress 4.1+dfsg-1+deb8u10 regression
On Fri, Sep 30, 2016 at 10:20:30AM +0200, Yves-Alexis Perez wrote: > thanks for the report, we're aware of the regression. Can you try the attached > patch against functions.php and report back, as soon as possible? I've tried the patch, and it fixed the regression for me. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#835033: debsources: [PATCH] Retain line context on 404s by appending the hash for specific links
Package: qa.debian.org
Severity: minor
User: qa.debian@packages.debian.org
Usertags: debsources
Forwarding to the BTS for record keeping.
- Forwarded message from Chris Lamb -
Date: Sun, 21 Aug 2016 11:41:27 +0100
From: Chris Lamb
To: debian...@lists.debian.org
Cc: i...@sources.debian.net
Subject: debsources: [PATCH] Retain line context on 404s by appending the hash
for specific links
Message-Id: <1471776087.3092845.701483073.410a5...@webmail.messagingengine.com>
Hi,
Attached is the following:
commit a0a47c965d364fb41d1b0fde2480252a9c328479
Author: Chris Lamb
Date: Sun Aug 21 11:39:25 2016 +0100
Retain line context on 404s by appending the hash for specific links
Signed-off-by: Chris Lamb
debsources/app/sources/templates/sources/404_suggestions.html | 2 +-
debsources/app/templates/footer.inc.html | 8
2 files changed, 9 insertions(+), 1 deletion(-)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
>From a0a47c965d364fb41d1b0fde2480252a9c328479 Mon Sep 17 00:00:00 2001
From: Chris Lamb
Date: Sun, 21 Aug 2016 11:39:25 +0100
Subject: [PATCH] Retain line context on 404s by appending the hash for
specific links
Signed-off-by: Chris Lamb
---
debsources/app/sources/templates/sources/404_suggestions.html | 2 +-
debsources/app/templates/footer.inc.html | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/debsources/app/sources/templates/sources/404_suggestions.html
b/debsources/app/sources/templates/sources/404_suggestions.html
index bf4609e..f1127f7 100644
--- a/debsources/app/sources/templates/sources/404_suggestions.html
+++ b/debsources/app/sources/templates/sources/404_suggestions.html
@@ -11,7 +11,7 @@ The file you are looking for might exist in one of the
following
versions:
{% for s in suggestions %}
- {{ s }}
+ {{ s }}
{% endfor %}
diff --git a/debsources/app/templates/footer.inc.html
b/debsources/app/templates/footer.inc.html
index 29d1d14..8636672 100644
--- a/debsources/app/templates/footer.inc.html
+++ b/debsources/app/templates/footer.inc.html
@@ -32,3 +32,11 @@
Last update: {{ last_update }}.
+
+
+var elems = document.querySelectorAll('.js-append-window-location-hash');
+
+for (var i = 0; i < elems.length; ++i) {
+ elems[i].setAttribute('href', elems[i].getAttribute('href') +
window.location.hash);
+}
+
--
2.9.3
- End forwarded message -
--
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Bug#833596: [pkg-gnupg-maint] Bug#833596: systemd user service {gpg-agent, dirmngr} breaks GNOME session startup
On Wed, Aug 10, 2016 at 11:46:55AM -0400, Daniel Kahn Gillmor wrote: > That's the exact same stack i used for my test, and i didn't see the > error. so yeah, i'd like to try to track it down. So I've tried again. I've good and bad news. Good news: I can no longer reproduce the session startup failure. GNOME starts just fine, and this is how the two services in question look: --- $ systemctl status --user dirmngr.service ● dirmngr.service - GnuPG network certificate management daemon Loaded: loaded (/usr/lib/systemd/user/dirmngr.service; enabled; vendor preset: enabled) Active: active (running) since mer 2016-08-17 09:09:06 CEST; 5min ago Docs: man:dirmngr(8) Process: 21506 ExecStart=/usr/bin/dirmngr --daemon --homedir %h/.gnupg (code=exited, status=0/SUCCESS) Main PID: 21509 (dirmngr) CGroup: /user.slice/user-1000.slice/user@1000.service/dirmngr.service └─21509 /usr/bin/dirmngr --daemon --homedir /home/zack/.gnupg ago 17 09:09:06 timira systemd[21502]: Starting GnuPG network certificate management daemon... ago 17 09:09:06 timira dirmngr[21506]: dirmngr[21506.0]: WARNING: *** ago 17 09:09:06 timira systemd[21502]: Started GnuPG network certificate management daemon. $ systemctl status --user gpg-agent.service ● gpg-agent.service - GnuPG secret key agent and passphrase cache Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; enabled; vendor preset: enabled) Active: active (running) since mer 2016-08-17 09:09:06 CEST; 5min ago Docs: man:gpg-agent(1) Process: 21507 ExecStart=/usr/bin/gpg-agent --daemon --homedir %h/.gnupg (code=exited, status=0/SUCCESS) Main PID: 21508 (gpg-agent) CGroup: /user.slice/user-1000.slice/user@1000.service/gpg-agent.service └─21508 /usr/bin/gpg-agent --daemon --homedir /home/zack/.gnupg ago 17 09:09:06 timira systemd[21502]: Starting GnuPG secret key agent and passphrase cache... ago 17 09:09:06 timira systemd[21502]: Started GnuPG secret key agent and passphrase cache. --- Bad news: I checked where the services belong in the service tree (as you suggested on debian-devel [1]) and they are still not part of the session scope: --- └─user.slice └─user-1000.slice ├─user@1000.service │ ├─gpg-agent.service │ │ └─21508 /usr/bin/gpg-agent --daemon --homedir /home/zack/.gnupg │ ├─dirmngr.service │ │ └─21509 /usr/bin/dirmngr --daemon --homedir /home/zack/.gnupg │ └─init.scope │ ├─21502 /lib/systemd/systemd --user │ └─21503 (sd-pam) └─session-1209.scope --- [1]: https://lists.debian.org/debian-devel/2016/08/msg00085.html FWIW I've checked and there are no other dirmngr or gpg-agent services running in the whole tree. Is this the expected behavior? In your test where did the two services ended up being located in the service tree? Hope this helps, Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#833596: [pkg-gnupg-maint] Bug#833596: systemd user service {gpg-agent, dirmngr} breaks GNOME session startup
On Wed, Aug 10, 2016 at 12:12:27AM -0400, Daniel Kahn Gillmor wrote: > So i'm not able to reproduce this behavior. > > Zack, can you help me narrow down how this is happening for you? Sure, I'll be happy to. But as I mentioned before I wonder if it's worth to do it with my current package mix: I'm using testing, where the GNOME stack seems to be still in flux, apparently), with gnupg2 coming from experimental. I can debug, but I wonder if it'd be a good time investment. Unless you consider this issue potentially blocking for uploading to unstable, I'd rather wait for gnupg2 to land in testing and try again. After all the issue is for a non-default behavior that one should explicitly enabled, right? OTOH if you do consider this a blocker, I'll roll up my sleeves and have a look ASAP :-) > do you have logs of the failed login session someplace, or other details > that might help diagnose? I can look up logs, but I could use some guidance about where the GNOME user session logs are supposed to be. ~/.xsession-errors seems to be obsolete --- or else it hasn't received log entries on my laptop since March 2016, which seems unlikely... Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#833596: systemd user service {gpg-agent,dirmngr} breaks GNOME session startup
Package: gnupg
Version: 2.1.14-3
Forwarding from debian-devel
https://lists.debian.org/debian-devel/2016/08/msg00093.html , as
requested by dkg.
- Forwarded message from Stefano Zacchiroli -
Date: Sat, 6 Aug 2016 12:32:39 +0200
From: Stefano Zacchiroli
To: debian-de...@lists.debian.org
Subject: Re: [pkg-gnupg-maint] Beware of leftover gpg-agent processes
Message-ID: <20160806103239.ga12...@upsilon.cc>
Resent-From: debian-de...@lists.debian.org
[ quoted text reordered ]
On Fri, Aug 05, 2016 at 02:43:30PM -0400, Daniel Kahn Gillmor wrote:
> The simplest way to see the control group hierarchy is with "systemctl
> status". When these processes are launched by the user service, they'll
> end up in the user@.service like this:
[...]
> If they've been autolaunched, they'll end up in the sesion-X.scope
> sub-tree.
It was indeed the case for me: they had been auto-launched.
> > On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> >> On desktop systems (where i'd expect the majority of secret key access
> >> happens), for folks who are running systemd, i recommend enabling the
> >> systemd user services, as documented in
> >> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
> >>
> >> systemctl --user enable gpg-agent
> >> systemctl --user enable dirmngr
OTOH, doing this inhibited a proper start of my GNOME session at next
login: only Nautilus started (I can tell because I've it handle my
desktop icons) and I could use it to browse the filesystem, but GNOME
Shell didn't see to be running. Reverting the above with "disable" [*]
fixed the issue, and at next login GNOME session started properly,
including GNOME Shell.
I haven't yet filed this as a bug report, because my package mix is
kinda unusual at present: Debian testing + hand-picked gpg from
experimental. But it might be useful for you to know about this. Let me
know how I can debug it further and/or if you'd like to move this
discussion into a dedicated bug report (and when).
Cheers.
[*] actually, I manually removed the symlinks from
.config/systemd/user/default.target.wants/, but AFAICT the effect is
the same
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Bug#823142: mutt-patched: First letter of Mailboxes' names is not shown
On Sun, May 01, 2016 at 02:00:51PM +0200, Muammar El Khatib wrote: > Recently, the first letter of Mailboxes's names is being "stripped" in > mutt-pached. I am sending attached to this bug report a screenshot so > that you can see. This is not an important bug, but it is annoying. I > solved this by adding the following¹: Confirmed, I'm seeing the same issue. The responsible upgrade on my (testing) laptop is this one (from dpkg.log): 2016-05-04 20:55:18 upgrade notmuch-mutt:all 0.21-3 0.22-1 The same upgrade also broke this setting from my .muttrc: # set sidebar_delim_chars="/" which I had to comment out as it's no longer recognized. But I've no idea whether this is related to the first-letter bug or not. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#823035: --all command line option is not documented in manpage
Package: gitg Version: 0.2.7-3 Severity: minor File: /usr/bin/gitg As per bug subject: gitg seems to support the --all command line option (with the same semantics of gitk --all), but that option is not documented in the manpage, nor in the output of gitg --help. Thanks for maintaining gitg in Debian! Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gitg depends on: ii dbus-x11 1.10.8-1 ii dconf-gsettings-backend [gsettings-backend] 0.26.0-1 ii git 1:2.8.1-1 ii gsettings-desktop-schemas3.18.1-1 ii libc62.22-7 ii libcairo21.14.6-1+b1 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libglib2.0-0 2.48.0-1 ii libgtk-3-0 3.18.9-1 ii libgtksourceview-3.0-1 3.18.2-1 ii libpango-1.0-0 1.40.1-1 ii libpangocairo-1.0-0 1.40.1-1 gitg recommends no packages. gitg suggests no packages. -- no debconf information
Bug#821248: ITP: fgallery -- modern, minimalist javascript photo gallery
On Sun, Apr 17, 2016 at 01:23:14AM +0200, Andreas Tille wrote: > * Package name: fgallery fgallery seems to already be in the archive: https://tracker.debian.org/pkg/fgallery Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#818463: archive changes: md5/sha1, gz/xz
Package: ftp.debian.org Reporting this to track the various breakages on Debian infrastructure components. - Forwarded message from Joerg Jaspert - Date: Tue, 15 Mar 2016 23:15:16 +0100 From: Joerg Jaspert To: debian-devel-annou...@lists.debian.org Subject: Archive changes Message-ID: <87k2l3xua3@gkar.ganneff.de> Resent-From: debian-devel-annou...@lists.debian.org Hi, I've just activated a few changes to the archive we talk(ed) about for a long time. And while it is not exactly the start of this release cycle, it should still work out nicely (so one hopes). As of now, InRelease/Release files, Packages and Sources no longer provide MD5Sum and SHA1sums, only SHA256. Additionally I turned off generating gzip compressed versions of those files, xz is there. To test it, this is limited to experimental. We hope nothing breaks on it, but lets try for a few days. If that works out, we should adjust unstable, and another short time later coordinate with the release team to adjust testing, so it ends up in the next release. Have fun. - End forwarded message - -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#818498: migrate from debmirror to archvsync
Package: qa.debian.org Severity: important User: qa.debian@packages.debian.org Usertags: debsources debmirror shortcomings have been bugging debsources for quite a while lately. Let's migrate away from it to archvsync [1], as that will put us in a more "normal" situation w.r.t. how actual Debian mirrors are maintained around the world. [1]: https://ftp-master.debian.org/git/archvsync.git I'm marking this bug as important because, after the recent archive changes, debmirror isn't properly mirroring experimental (due to its having been switched to Sources.xz). Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#818324: updates of packages in experimental are currently ignored
severity 818324 serious thanks I'm raising the severity of 818324, because Sources.gz are already gone for experimental, meaning that we are effectively ignoring them on sources.debian.net until this is fixed. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#818324: debsources: migrate from Sources.gz to Sources.xz
Package: qa.debian.org Severity: important User: qa.debian@packages.debian.org Usertags: debsources Due to the mail below (and also at https://lists.debian.org/debian-devel-announce/2016/03/msg6.html ) we need to migrate the mirror lister module of Debsources from using Sources.gz to using Sources.xz. See: https://anonscm.debian.org/cgit/qa/debsources.git/tree/debsources/debmirror.py#n195 for a *starting* point. Cheers. - Forwarded message from Joerg Jaspert - Date: Tue, 15 Mar 2016 23:15:16 +0100 From: Joerg Jaspert To: debian-devel-annou...@lists.debian.org Subject: Archive changes Message-ID: <87k2l3xua3@gkar.ganneff.de> Resent-From: debian-devel-annou...@lists.debian.org Hi, I've just activated a few changes to the archive we talk(ed) about for a long time. And while it is not exactly the start of this release cycle, it should still work out nicely (so one hopes). As of now, InRelease/Release files, Packages and Sources no longer provide MD5Sum and SHA1sums, only SHA256. Additionally I turned off generating gzip compressed versions of those files, xz is there. To test it, this is limited to experimental. We hope nothing breaks on it, but lets try for a few days. If that works out, we should adjust unstable, and another short time later coordinate with the release team to adjust testing, so it ends up in the next release. Have fun. - End forwarded message - -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#816711: package description only mentions JSON Schema draft3, but the package actually supports draft4
Package: python3-jsonschema Version: 2.5.1-4 Severity: minor As per subject. Thanks for maintaining jsonschema! -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-jsonschema depends on: ii python3 3.5.1-2 pn python3:any python3-jsonschema recommends no packages. python3-jsonschema suggests no packages. -- no debconf information
Bug#815060: Encouraging removal of nvidia kernel modules from Debian non-free archive.
On Sat, Feb 20, 2016 at 09:34:48AM -0800, Bradley M. Kuhn wrote: > I'm speaking here as a Debian user and Free Software citizen, although I > First, I think Ben's explanation on the problems are salient. But, more > importantly and generally, IMO, Debian should err on the side of caution > in these situations. FWIW I agree with this. And, to follow-up onto Holger's reasonable "[citation needed]" request, I don't think that legal advice, or legal opinions in general, should be the primary input that Debian uses to decide on this specific matter. There are expert FOSS lawyers that consider proprietary Linux kernel modules to be GPL violations in a number of circumstances, and others with opposed views. And there are no relevant legal ruling yet AFAIK. What is certain however is that a significant amount of Linux kernel developers do consider proprietary modules like the nvidia one to be GPL violations that infringe on their copyrights. Those developers contribute code to the Linux kernel considering that 3rd party modules should be released as Free Software too. Some of them also put money and energies into fighting those who try to get away with proprietary modules, free riding on their work. Morally, I've no doubt on which side of those fights Debian should be. And by distributing proprietary modules we are not helping our fellow Free Software developers, quite the contrary. But even putting moral considerations aside for a moment, Debian should not be in the political position of being cross with Linux kernel developers on the ground of alleged copyright infringement. The political/legal Free Software battleground is already enough of a mess; we should not contribute to make it worse by risking community infights. Especially when there is a technical alternative that provides an almost identical user experience for Debian users who need nvidia.ko: a downloader/installer package like nvidia-graphics-drivers used to be many years ago [1,2]. Cheers. [1]: http://sources.debian.net/src/nvidia-graphics-drivers/1.0.7174-3/debian/changelog/#L352-L354 [2]: http://sources.debian.net/src/nvidia-kernel-src/1.0.2880-1/debian/changelog/ -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#815006: Renaming Iceweasel to Firefox
On Thu, Feb 18, 2016 at 07:48:25AM +0800, Paul Wise wrote: > Mozilla's trademark policy isn't clear about how much modification > requires Mozilla's written consent. Any written consent except for a > clarification to Mozilla's trademark guidelines would be specific to > Debian and thus would be in violation of DFSG item 8. Debian cannot > make agreements with Mozilla about this that don't also apply to all > distributors of modified versions of Mozilla's software. > > What is the plan to solve this dilemma? Let's take the worst case scenario: Mozilla's policy gets so extreme that *every* derived works must be rebranded away from Mozilla's marks---assuming for a moment that that is something that could be enforced using trademark law in the first place. Such a policy would be fine w.r.t. DFSG §4. If a policy is less clear cut than that (as Mozilla's is), and we (Debian) decide to use the marks anyhow, what we are doing is a risk assessment exercise. We consider in good faith that the patches we will apply will be OK w.r.t. the (unclear) policy and that therefore Mozilla will not force us to rebrand. But we might be wrong, and Mozilla might decide to force us to rebrand, which will be a PITA if it has to happen in stable. AFAIU there is no formal/contractual guarantee that Mozilla is giving Debian here, nor they are giving us a trademark license. So DFSG §8 is respected. Mozilla just recognizes that the kind of work that Debian Firefox maintainers have done in the past, if continued in the future, *should* be fine w.r.t. their trademark policy. As per my understanding of trademark law, and given no trademark license is being given to Debian, others (including our downstreams) will be able to apply the same changes to Firefox without being forced to rebrand either. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#815006: Iceweasel / Firefox: Trademarks?
On February 17, 2016 5:55:26 PM GMT+01:00, "Paul R. Tagliamonte" wrote: >At minimum, the trademark guidelines say we can't charge for the >software, >what's our stance on that? We are building our own binaries and not using Mozilla's "unaltered binaries", so that clause (which BTW I hate and consider cause for the non-free-ness of upstream binaries) doesn't apply to us. Neither it applies to our downstream; so it isn't even a "specific to Debian" DFSG issue. Cheers. -- Sent from my mobile phone with K-9 Mail. Please excuse my brevity.
Bug#798199: New list: debian-outre...@lists.debian.org
On Sun, Sep 06, 2015 at 07:32:43PM +0200, Nicolas Dandrimont wrote: > Name: > debian-outreach > > Short description: > Public discussion of the Outreach Team's activities Seconded. > Category: > I'm torn between Developers and Misc Debian, with a slight > preference for the latter. I'd say Misc Debian. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#812210: please ship a (more) complete manpage for /usr/bin/arc
Package: arcanist Version: 0~git20150906-1 Severity: minor "man arc" provides the manpage equivalent of "arc help", which is a nice overview of the various command, but with no specific details about any of them. "arc help --full" on the other hand provide all needed details. The output of *that* command should be in the manpage, rather than the output of the non-full version. Can you please update the shipped manpage so that that is the case? With many thanks for maintaining arcanist in Debian! Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages arcanist depends on: ii libphutil 0~git20150906-1 ii php5-cli 5.6.17+dfsg-3 ii php5-curl 5.6.17+dfsg-3 arcanist recommends no packages. Versions of packages arcanist suggests: ii python 2.7.11-1 -- no debconf information
Bug#809705: general: let people use non-free software but opt-out of non-open software
On Tue, Jan 05, 2016 at 08:15:37AM +0100, Johannes Schauer wrote: > while I would welcome this sort of information being captured using debtags, > this would not help me if I wanted to tell apt which packages are okay for me > and which ones are not because apt cannot set pin priorities according to a > package's debtags, right? Right, but you need to start encoding the information in a machine parsable way somewhere. Once you've that, you can exploit the information, not before. > Also, can the reason why something is in non-free not be captured by > increased and a more structured use of DEP-5 (machine-readable > debian/copyright)? Policy §12.5 already requires to explain why a package is in non-free: Packages in the contrib or non-free archive areas should state in the copyright file that the package is not part of the Debian distribution and briefly explain why. and DEP-5 prescribes the Disclaimer field to that end. Unfortunately, no further (machine-readable) structure *within* the content of that field is prescribed by DEP-5. So, yes, we will need to improve that part of DEP-5 if we want to exploit information in there. I duly note that, out of the box, having the information in d/copyright won't help with APT pinning either. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#809705: general: let people use non-free software but opt-out of non-open software
On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote: > Your second item has been brought up before with different > focus/rationale/purpose. At least I remember there being an interest > in splitting "non-free" into "non-free/firmware" vs. various other > non-free sub components. Another one that is worth mentioning here --- which I discussed in the context of non-free.org with Dafydd Harries and others --- is introducing a debtags facet to capture the reason why a package is in non-free. At least two hierarchies come to mind: 1) which point of DFSG is not respected, and 2) which one of the 4 freedoms are not granted. I've had on my TODO list proposing the relevant debtags facets since at least 2 years, but never found the time to actually do that. This is a very actionable item: it is enough to follow the procedure for proposing a new debtags. (Procedure that I cannot find right now, but IIRC it includes coming up with a list of tag names + a list of at least N packages, with N relatively low, that are already in the archive and that would carry each tag.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#808216: debmirror: Debmirror seeems to have problems with new SHA256 in Packages.diff/Index files
On Thu, Dec 17, 2015 at 06:45:13PM +0800, Michael Bergbauer wrote: > For a fews days (Dec 09, to be exact, in GMT+8), my debmirror cronjob pulling > from ftp.us is running in an infinite loop - using up 100% of a core. After > having a closer look, it seems that the culprit code is in lines 2460ff with a > $_ value of e.g. 'SHA256-Current: > d4228ed8d1591732f9a3af33f4064c4e0d173d16218d12b930d1c5de3673d7ce39582357\n', > when parsing my .temp/dists/sid/main/binary-i386/Packages.diff/Index file. Confirmed here too: Debsources/sources.debian.net hasn't been updated since December 8th due to this bug. It'd be great to have a backported debmirror with this fix. I'll try Colin's oneliner patch as a work-around to get Debsources back up running. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#807267: please provide a python3-twill package
Package: python-twill Version: 0.9-3 Severity: normal As per subject. Thanks! -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-twill depends on: ii python2.7.9-1 ii python-mechanize 1:0.2.5-3 ii python-pyparsing 2.0.3+dfsg1-1 ii python2.7 2.7.10-5+b1 Versions of packages python-twill recommends: ii doc-base 0.10.6 python-twill suggests no packages. -- no debconf information
Bug#807054: ITP: flask-testing -- unit testing utilities for the Flask micro web framework
Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli
* Package name: flask-testing
Version : 0.4.2
Upstream Author : Dan Jacob
* URL : http://pythonhosted.org/Flask-Testing/
* License : BSD-3-clause
Programming Lang: Python
Description : unit testing utilities for the Flask micro web framework
(Long description forthcoming.)
The binary packages will be named python{,3}-flask.ext.testing.
The package Git repository will be put under the DPMT umbrella.
Bug#807053: ITP: flask-api -- browsable web APIs for the Flask micro web framework
Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli
* Package name: flask-api
Version : 0.6.4
Upstream Author : Tom Christie
* URL : http://www.flaskapi.org/
* License : BSD-2-clause
Programming Lang: Python
Description : browsable web APIs for the Flask micro web framework
Flask API is an implementation of the same web browsable APIs that the
Django REST framework provides. It gives you properly content negotiated
responses and smart request parsing.
The binary packages will be named python{,3}-flask-api.
The package Git repository will be put under the DPMT umbrella.
Bug#803658: boot hangs before cryptsetup passphrase prompt
On Sun, Nov 29, 2015 at 09:20:55PM +0100, Laurent Bigonville wrote: > >- it now works, YAY (and thanks!). But I conclude from the whole > > experience that before now plymouth was somehow able to fallback to > > askpass after self-detecting some sort of failure, while new versions > > aren't any more. If that's the case, this might affect other users > > Before the last update, plymouth was not enabled at all if splash was not > passed to the kernel cmdline, now the plymouth daemon is started even if > it's not passed, that probably explain the change of behavior. Possibly. Although please note that "splash" *is* on my kernel cmdline, and has been since forever. > >- does the above mean that now non-free firmware is required to use > > plymouth on i915 hardware? Or was the warning about something else > > that is not strictly needed to make plymouth work? (sorry, I haven't > > yet tried to re-remove the firmware and see what happens) > > I'm not sure, I don't have a machine with an intel card to test, you should > test without them. I've tested this. Even after purging firmware-misc-nonfree (and rebuilding the initramfs, which results in the aforementioned warning) the boot still works fine. > >-http://upsilon.cc/~zack/stuff/IMG_20151129_174719.jpg > >-http://upsilon.cc/~zack/stuff/IMG_20151129_174736.jpg > >-http://upsilon.cc/~zack/stuff/IMG_20151129_174751.jpg > > I cannot reproduce this without an intel card, could you please report this > upstream? To be frank, I don't think I've a decent enough understanding of what is supposed to happen to be able to file a proper upstream bug report. In particular, I've no idea of whether plymouth is supposed to work without adding i915 to /etc/initramfs-tools/modules or not. If adding the module there is a requirement, then arguably this bug is actually PEBKAC. But if users (at least in Debian) started to rely on that behavior, than a work-around might be needed. Not sure if it should be upstream or distro-level though. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#803658: boot hangs before cryptsetup passphrase prompt
On Sun, Nov 29, 2015 at 02:44:55PM +0100, Laurent Bigonville wrote:
> >Do you have a KMS driver loaded in the initramfs?
After discussion on IRC, I've done the following:
- added "i915" to /etc/initramfs-tools/modules
- update-initramfs
- got a warning stating some firmware might be missing
- apt-get install firmware-misc-nonfree
- update-initramfs again (verifying that the warning is now gone)
After the above, the boot works fine.
Comments/questions:
- it now works, YAY (and thanks!). But I conclude from the whole
experience that before now plymouth was somehow able to fallback to
askpass after self-detecting some sort of failure, while new versions
aren't any more. If that's the case, this might affect other users
- does the above mean that now non-free firmware is required to use
plymouth on i915 hardware? Or was the warning about something else
that is not strictly needed to make plymouth work? (sorry, I haven't
yet tried to re-remove the firmware and see what happens)
> >I'm a bit surprised by the error message that I see in your 3rd picture, I
> >cannot reproduce this on my laptop even with plymouth completely disabled.
> >Did you modify anything in the initramfs scripts?
> >({/etc,/usr/share}/initramfs-tools/scripts)
I've had those messages since as long as I remember (with this laptop
having been bought in July 2014). According to debsums/etckeeper the
only relevant local change is:
- /etc/modprobe.d/dkms.conf, which is now empty, but used to contain
commented lines. It looks like it has been emptied by some postinst
script
> You can also try to add plymouth.debug to the kernel cmdline (or
> plymouth.debug=stream:/dev/kmsg)
I've done that, and took screenshots of all the debug messages before
the boot hangs. The 1st picture is the first page (obtained going back
up with Shift+PagUp); the 2nd picture is the 2nd page (overlapping with
the first one); the 3rd picture is the 2nd page, but in landscape rather
than portrait mode:
- http://upsilon.cc/~zack/stuff/IMG_20151129_174719.jpg
- http://upsilon.cc/~zack/stuff/IMG_20151129_174736.jpg
- http://upsilon.cc/~zack/stuff/IMG_20151129_174751.jpg
Thanks a lot for your help,
Cheers.
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Bug#803658: boot hangs before cryptsetup passphrase prompt
On Thu, Nov 26, 2015 at 11:41:55AM +0100, Stefano Zacchiroli wrote: > I'll eagerly wait feedback from the Plymouth maintainers on how to > help them debug this further :) [ Following up with information that Laurent asked via IRC. ] I've done "update-initramfs -k 3.16.0-4-amd64 -u" and I confirm that after that also 3.16 became broken: it hangs before asking the LUKS password, whereas it used to work before update-initramfs. Linux 4.1 still boots properly (asking the password via askpass), because I haven't update-initramfs'd it. So it is something that sneaks in upon initramfs creation, and that used not to sneak in with older plymouth versions. I can also confirm that the workaround of passing plymouth.enable=0 on the kernel cmdline sidesteps the problem. I'm now running 4.3 from experimental, which boots properly with plymouth.enable=0. Hope this helps, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#803658: boot hangs before cryptsetup passphrase prompt
On Wed, Nov 25, 2015 at 09:38:29PM +, Ben Hutchings wrote: > > So this bug might deserve a reassign to plymouth, I guess. Thanks for doing this, Ben. I'll eagerly wait feedback from the Plymouth maintainers on how to help them debug this further :) > > Still, why are kernels 4.2 and 4.3 triggering plymouth usage, whereas > > 4.1 is not? (FWIW, all my grub entries have "splash" on the kernel > > cmdline.) > > Perhaps you installed plymouth after Linux 4.2? Only the newest > initramfs is updated when you install plymouth (and most other > packages that trigger an initramfs update). No, that's not it. I've had Plymouth installed since ever. FWIW, here are the plymouth packages I've installed on my machine: dpkg -l '*plymouth*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-===-===- ii libplymouth4:amd640.9.2-3 amd64 graphical boot animation and logger - shared libraries ii plymouth 0.9.2-3 amd64 boot animation, logger and I/O multiplexer rc plymouth-drm 0.9.0-4 amd64 Graphical Boot Animation and Logger (DRM) un plymouth-theme (no description available) ii plymouth-themes 0.9.2-3 amd64 boot animation, logger and I/O multiplexer - themes un plymouth-themes-all (no description available) un plymouth-themes-fade-in (no description available) un plymouth-themes-glow (no description available) un plymouth-themes-script (no description available) un plymouth-themes-solar(no description available) un plymouth-themes-spinfinity (no description available) un plymouth-themes-spinner (no description available) ii plymouth-x11 0.9.2-3 amd64 boot animation, logger and I/O multiplexer - X11 renderer No idea why old kernel versions weren't calling plymouth to ask for the luks password. Just in case: is "dpkg --purge plymouth" supposed to be a safe way out of this bug these days? Or do we now require plymouth in order to be able to ask for luks password during boot? Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#803658: boot hangs before cryptsetup passphrase prompt
TL;DR: it seems to be a plymouth issue. On Sun, Nov 22, 2015 at 10:19:12PM +, Ben Hutchings wrote: > Can you try this: > > - Boot with the added parameter: break=top > - In the shell, run: > echo 1 >/proc/sys/kernel/sysrq > openvt > exit > - Once the system has hung, press Alt-SysRq, Alt-W, Alt-SysRq, Alt-L > - Switch to VT 2 then show the kernel log with: dmesg | less > - Send photos of all the call traces I haven't done all of the above, because I don't know what generates a SysRq on ThinkPad's keyboards. Do you know? I've a T440s. (I guess the web would probably tell me, but I'm writing this on a plane w/o net connection..., sorry about that.) Nonetheless I've used the shell obtained with openvt to compare the running processes in the linux 4.1 and 4.3 cases. In 4.1 (where the boot works) the processes asking for the luks password is "/lib/cryptsetup/askpass Please unlock disk sda3_crypt:" ; in 4.3 (where the boot doesn't work) is "plymouth ask-for-password --prompt Please unlock disk sda3_crypt". In both cases, the process with the next PID, after askpass/plymouth, is "/sbin/cryptsetup -T 1 --allow-discards open --type luks ". So this bug might deserve a reassign to plymouth, I guess. Still, why are kernels 4.2 and 4.3 triggering plymouth usage, whereas 4.1 is not? (FWIW, all my grub entries have "splash" on the kernel cmdline.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#803658: boot hangs before cryptsetup passphrase prompt
On Sun, Nov 22, 2015 at 10:19:12PM +, Ben Hutchings wrote: > On Sun, 01 Nov 2015 15:18:46 +0100 Stefano Zacchiroli wrote: > > Package: src:linux > > Version: 4.2.3-2 > > Can you test whether this is fixed in 4.2.6-1 or 4.3-1~exp1? I'll answer this first, as it was quicker to test. I've tried the following debian-packaged kernels: $ dpkg -l 'linux-image*' | grep ^ii ii linux-image-3.16.0-4-amd643.16.7-ckt11-1 amd64Linux 3.16 for 64-bit PCs ii linux-image-4.1.0-2-amd64 4.1.6-1amd64Linux 4.1 for 64-bit PCs ii linux-image-4.2.0-1-amd64 4.2.6-1amd64Linux 4.2 for 64-bit PCs ii linux-image-4.3.0-trunk-amd64 4.3-1~exp1 amd64Linux 4.3 for 64-bit PCs Results: - work: 3.16.7, 4.1.6 - don't work: 4.2.6, 4.3 As an additional data point, before your mail I already had installed all kernels above except 4.3, which I just installed from experimental. It seems to me that: (a) it's due to something fairly recent and that is still lingering around in 4.3; (b) it is not something transient --- in particular I was thinking at something weird that might have happened one off with the initram creation just for 4.2, but that doesn't seem the case. I'll follow-up in separate mail providing the other debug information you've asked. It might take a couple of days though, as I'm currently traveling. Thanks for your help! Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#801951: debian/copyright should mention BSD3 license, not PSF
Package: python3-dateutil Version: 2.2-2 Severity: important debian/copyright currently refers to (various incarnations of...) the PSF license, whereas python-dateutil has been relicense under BSD3 a while ago. See http://sources.debian.net/src/python-dateutil/latest/LICENSE/ for reference. debian/copyright should be updated (and can be widely simplified / shortened) to refer to BSD3. Thanks a lot for maintaining python-dateutil in Debian, it's much appreciated! Cheers. -- System Information: Debian Release: stretch/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-dateutil depends on: ii python3-six 1.10.0-1 pn python3:any ii tzdata 2015g-1 python3-dateutil recommends no packages. python3-dateutil suggests no packages. -- no debconf information
Bug#801571: do not suggest to use "*apt-get* autoremove" when using *apt*
Package: apt Version: 1.1~exp12 Severity: wishlist I'm using /usr/bin/apt and loving it. As a minor glitch, when there are packages that could be autoremoved, I get the following message: Use 'apt-get autoremove' to remove them. Given "apt autoremove" works as well, it would be nice to point /usr/bin/apt users to that, rather than pointing them to /usr/bin/apt-get. Thanks for (/usr/bin/)apt! -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt depends on: ii adduser 3.113+nmu3 ii debian-archive-keyring 2014.3 ii gnupg 1.4.19-5 ii gnupg2 2.0.28-3 ii gpgv1.4.19-5 ii libapt-pkg5.0 1.1~exp12 ii libc6 2.19-22 ii libgcc1 1:5.2.1-21 ii libstdc++6 5.2.1-21 apt recommends no packages. Versions of packages apt suggests: ii apt-doc 1.1~exp8 ii aptitude0.7.2-1 ii dpkg-dev1.18.3 ii python-apt 1.0.1 -- no debconf information
Bug#799779: integrate autopkgtest/DEP8 specification into debian-policy
On Sun, Oct 11, 2015 at 06:01:59PM +0200, Bill Allombert wrote: > Hello Stefano, I have created a git branch bug799779-bill with your > patch. I needed to change a little, please review (in attachment). Looks good to me. > > There have been some requested format changes (see thread), which I > > didn't have time to implement. They're now up for grabs, hurry up! > > :-) > > If I do the conversion, would you review the new version for translation > error ? I can certainly have a look. However, as I'm not active myself in the autopkgtest team these days, it'd be better to keep the autopkgtest-devel list in the loop (I'm Cc:-ing it now). Autopkgtesters: you might want to subscribe to this policy bug report and keep an eye on this. > Thanks for moving forward with this, Same :) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#799782: Packages not updated when .deb file takes a while to be copied/created
Package: local-apt-repository Version: 0.2 Severity: normal When creation of .deb files takes a while, the Packages file index under /var/lib might miss the addition of new packages to the repository. I've reproduced the problem with at least two use cases: 1) executing dpkg-repack directly in /srv/local-apt-repository 2) wgetting packages directly in /srv/local-apt-repository in both cases, if I first create/download the .deb file to a separate dir, and then mv it to /srv/local-apt-repository, the Packages index is updated just fine. As a workaround for the problem, moving away the .deb from /srv/local-apt-repository and moving it back in works fine. I haven't debugged this thoroughly, but the feeling is that local-apt-repository gets a notification of the new .deb file too soon, when then file is still incomplete (or possibly empty), and skips it. Then, it gets no other notification when the .deb file has been fully copied/built. Thanks a lot for local-apt-repository, it's a great tool! Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages local-apt-repository depends on: ii dpkg-dev 1.18.2 ii init-system-helpers 1.23 ii systemd 225-1 local-apt-repository recommends no packages. local-apt-repository suggests no packages. -- no debconf information
Bug#799779: integrate autopkgtest/DEP8 specification into debian-policy
Package: debian-policy Severity: wishlist Tags: patch I'm filing this bug report to avoid losing track of the discussion we've had in July 2014 about merging the autopkgtest/DEP8 specification into Debian Policy. The thread is archived starting from here: https://lists.debian.org/debian-policy/2014/07/msg00057.html I've posted draft patches implementing what was discussed in the thread at the time; I'm attaching them to this message as patches. There have been some requested format changes (see thread), which I didn't have time to implement. They're now up for grabs, hurry up! :-) Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) >From 8440fe8b2bef5f99bddf3deb141a8c4b4b0354f9 Mon Sep 17 00:00:00 2001 From: Stefano Zacchiroli Date: Sun, 5 Oct 2014 23:41:40 +0200 Subject: [PATCH 1/2] autopkgtest: new specification for autopkgtest/DEP-8 tests --- .gitignore | 4 + autopkgtest.desc | 13 ++ autopkgtest/Makefile | 13 ++ autopkgtest/autopkgtest.md | 305 + debian/control | 4 +- debian/rules | 14 ++- 6 files changed, 351 insertions(+), 2 deletions(-) create mode 100644 autopkgtest.desc create mode 100644 autopkgtest/Makefile create mode 100644 autopkgtest/autopkgtest.md diff --git a/.gitignore b/.gitignore index 5c80ed5..66b5940 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,9 @@ /Process.html /README.html +/autopkgtest/version.txt +/autopkgtest/*.expanded +/autopkgtest/*.html +/autopkgtest/*.txt.gz /copyright-format/copyright-format-1.0.html /copyright-format/version.xml /debconf_spec/debconf_specification.html diff --git a/autopkgtest.desc b/autopkgtest.desc new file mode 100644 index 000..dc7ea40 --- /dev/null +++ b/autopkgtest.desc @@ -0,0 +1,13 @@ +Document: autopkgtest +Title: automatic as-installed package test specification +Author: The Debian Project +Abstract: Specification for automatic as-installed (AKA "autopkgtest", + or DEP-8) tests for Debian packages +Section: Debian + +Format: text +Files: /usr/share/doc/debian-policy/package-tests.txt.gz + +Format: HTML +Index: /usr/share/doc/debian-policy/package-tests.html +Files: /usr/share/doc/debian-policy/package-tests.html diff --git a/autopkgtest/Makefile b/autopkgtest/Makefile new file mode 100644 index 000..9552f38 --- /dev/null +++ b/autopkgtest/Makefile @@ -0,0 +1,13 @@ +all: autopkgtest.html autopkgtest.txt.gz + +autopkgtest.html: autopkgtest.md.expanded + markdown $< > $@ + +autopkgtest.txt.gz: autopkgtest.md.expanded + gzip -cf9 $< > $@ + +autopkgtest.md.expanded: autopkgtest.md version.txt + cat $^ > $@ + +clean: + rm -f autopkgtest.html autopkgtest.txt.gz $(wildcard *.expanded) diff --git a/autopkgtest/autopkgtest.md b/autopkgtest/autopkgtest.md new file mode 100644 index 000..c9f6d77 --- /dev/null +++ b/autopkgtest/autopkgtest.md @@ -0,0 +1,305 @@ +Autopkgtest - Defining tests for Debian packages + + +This document describes how the autopkgtest tester core (the program +`adt-run`) interprets and executes tests found in Debian source +packages. + +Overview + + +The source package provides a test metadata file `debian/tests/control`. +This is a file containing zero or more RFC822-style stanzas, along these +lines: + +Tests: fred bill bongo +Restrictions: needs-root breaks-testbed + +This example defines three tests, called `fred`, `bill` and `bongo`. The +tests will be performed by executing `debian/tests/fred`, +`debian/tests/bill`, etc. Each test program should, on success, exit +with status 0 and print nothing to stderr; if a test exits nonzero, or +prints to stderr, it is considered to have failed. + +The cwd of each test is guaranteed to be the root of the source package, +which will have been unpacked but not built. *However* note that the +tests must test the *installed* version of the program. Tests may not +modify the source tree (and may not have write access to it). + +If the file to be executed has no execute bits set, `chmod a+x` is +applied to it (this means that tests can be added in patches without the +need for additional chmod; contrast this with debian/rules). + +During execution of the test, the environment variable `$ADTTMP` will +point to a directory for the execution of this particular test, which +starts empty and will be deleted afterwards (so there is no need for the +test to clean up files left there). + +If tests want to create artifacts which are useful to attach to test +results, such as additional lo
Bug#747094: Updated Patch
On Wed, Sep 09, 2015 at 10:56:21AM +0200, Stefano Zacchiroli wrote: > Thanks for your patch! I've now rebuilt a local bash-completion that > uses it, and it's just great. BTW, why is this patch number 14 in the series rather than 13? I thought that was because another patch numbered 13 was in the series on the Ubuntu side, but according to https://patches.ubuntu.com/b/bash-completion/bash-completion_1:2.1-4.1ubuntu2.patch that doesn't seem to be the case. Not that I care *that* much :), I'm just trying to figure out whether some other patches from Ubuntu should be integrated or not. TIA, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#747094: Updated Patch
On Thu, Aug 13, 2015 at 09:31:57AM -0700, Brian Murray wrote: > Michael's patch was actually incomplete, I'm attaching an updated > version which completely adds apt support and is now in Ubuntu. Thanks for your patch! I've now rebuilt a local bash-completion that uses it, and it's just great. Small feature request: "apt install" can now (with the version of apt in experimental, at least) install local .deb packages, and resolve dependencies as needed. So it'd be nice if "apt install " would also complete with local *.deb files on the filesystem. Do you think you can add that? FWIW, I'm considering NMU-ing to DELAYED/XX bash-completion to fix this specific bug, as I think it'd help quite a bit with the adoption of the new apt command. (But, anyone, feel free to beat me at it!) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#797359: ITP: universal-ctags -- Generates an index (or tag) file of names found in source files
Thanks for your answer, Víctor! On Mon, Aug 31, 2015 at 10:14:10AM +0200, Víctor Cuadrado Juan wrote: > You can read a somewhat comprehensive list of changes from upstream > here[1], and more info here[2]. Very helpful! Last question: are you aware of any performance comparison between exuberant-ctags and universal-ctags? -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#797359: ITP: universal-ctags -- Generates an index (or tag) file of names found in source files
On Sun, Aug 30, 2015 at 12:44:44AM +0200, Víctor Cuadrado Juan wrote: > * Package name: universal-ctags > * URL : https://ctags.io/ > A continuation of the exuberant-ctags implementation of the ctags Hey, can you elaborate a bit on how universal-ctags compare to exuberant-ctags? This is by no means an objection to packaging this, but as a heavy user of exuberant-ctags for Debsources, I'm curious about how the two compares, specifically in terms of performances and language support. Thanks! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#796710: "moving a key signature to the correct place" loop
Package: gnupg Version: 1.4.19-3 Severity: normal Tags: upstream [ filing the bug report, as discussed with dkg and Clint at DebConf 15 ] Below you can find the screen log of a gpg session that, using a fresh GNUPGHOME: 1) fetch/reresh my key from the SKS keyserver pool 2) edit the key... 3) ...resulting in gpg "moving a key signature to the correct place" multiple times 4) save the key 5) go to 1 i.e. it seems that whatever "fixing" gpg does to the wrong packages that are present in the key material, it is undone by the next refresh from the keyserver. Allegedly, this is a bug in both gpg and the keyserver software running on the SKS pool. Note that in the session below I did also try a second edit after saving, without refreshing, and that does not make gpg trying to move the signatures again. I.e. it seems that gpg "fixing" is stable on disk; it is just not stable w.r.t. the key server. I've also tested this with gpg2, obtaining the same result. Cheers. zack@timira:~$ export KEYID=6D866396 zack@timira:~$ export GNUPGHOME=/tmp/gpg-bug zack@timira:~$ mkdir -m 700 $GNUPGHOME zack@timira:~$ gpg --keyserver pool.sks-keyservers.net --recv-keys $KEYID gpg: keyring `/tmp/gpg-bug/secring.gpg' created gpg: keyring `/tmp/gpg-bug/pubring.gpg' created gpg: requesting key 6D866396 from hkp server pool.sks-keyservers.net gpg: /tmp/gpg-bug/trustdb.gpg: trustdb created gpg: key 6D866396: public key "Stefano Zacchiroli " imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) zack@timira:~$ gpg --edit-key $KEYID gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place pub 4096R/6D866396 created: 2010-09-27 expires: 2016-09-02 usage: SC trust: unknown validity: unknown sub 4096R/02D0E74C created: 2010-09-27 expires: never usage: E sub 4096R/93412799 created: 2012-12-01 expires: 2016-09-02 usage: S [ unknown] (1). Stefano Zacchiroli [ unknown] (2) Stefano Zacchiroli [ unknown] (3) Stefano Zacchiroli [ revoked] (4) Stefano Zacchiroli [ unknown] (5) Stefano Zacchiroli [ revoked] (6) Stefano Zacchiroli (Debian Project Leader) gpg> save zack@timira:~$ gpg --edit-key $KEYID gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 4096R/6D866396 created: 2010-09-27 expires: 2016-09-02 usage: SC trust: unknown validity: unknown sub 4096R/02D0E74C created: 2010-09-27 expires: never usage: E sub 4096R/93412799 created: 2012-12-01 expires: 2016-09-02 usage: S [ unknown] (1). Stefano Zacchiroli [ unknown] (2) Stefano Zacchiroli [ unknown] (3) Stefano Zacchiroli [ revoked] (4) Stefano Zacchiroli [ unknown] (5) Stefano Zacchiroli [ revoked] (6) Stefano Zacchiroli (Debian Project Leader) gpg> quit zack@timira:~$ gpg --keyserver pool.sks-keyservers.net --recv-keys $KEYID gpg: requesting key 6D866396 from hkp server pool.sks-keyservers.net gpg: key 6D866396: "Stefano Zacchiroli " 13 new signatures gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: new signatures: 13 zack@timira:~$ gpg --edit-key $KEYID gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct place gpg: moving a key signature to the correct p
Bug#796425: notmuch-mutt: search (via F8) is broken when there are new messages in mailboxes
On Sat, Aug 22, 2015 at 10:07:17AM +0200, Tomasz Buchert wrote: > > How (often) do you run "notmuch new"? > After each offlineimap run. OK. > So when I say "new" mail I don't literally mean "newly synced > messages", but only messages that are in "new/" maildir. I now > remember that I also have a personal patch on offlineimap: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789625 If this is related to the general indexing ability of notmuch w.r.t. offlineimap, then I guess it would not be a bug in notmuch-mutt. But still, I'm not 100% sure we are on the same page. First of all, I cannot reproduce it using mutt only. I've tried flipping the new bit in mutt, sync the maildir (which moves mails to the new/ subdir), and try reconstructing the thread after that. As expected, if I do *not* run "notmuch new" before searching, the thread will be incomplete. But this is not a bug, is just the trade-off of notmuch non-synchronous updates. If I do run "notmuch new" and then search, the thread is complete; again, as expected. Do you confirm you have the same behaviour, using mutt? Then I've tried to do the same with offlineimap, verifying that the mail in new has the trailing ":2", or similar. To be sure, I've interrupted offlineimap before it completes the sync, ensuring that "notmuch new" does not kick in. As expected, notmuch cannot rebuild the complete thread. But, after a "notmuch new", it is able to do so. So it still seems to me that there is no bug here or, alternatively, that there is one I cannot reproduce. Might it be that you're looking at your maildirs while offlineimap is still running? In that case, you will immediately see new mail, but "notmuch new" hasn't been run yet, so notmuch is unaware of new messages. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#796425: notmuch-mutt: search (via F8) is broken when there are new messages in mailboxes
On Fri, Aug 21, 2015 at 10:11:22PM +0200, Tomasz Buchert wrote: > when I try to search or rebuild thread in mutt and there > are some new messages in my mailboxes, the operation does > not do what promised, but jumps into mailbox with a > new message instead. How (often) do you run "notmuch new"? According to your description it seems to me that you're running the F8 query before notmuch has had a chance to reindex, and hence realize that the new messages belong to some previously existing threat. In that situation, notmuch search will consider the new messages as part of singleton message threads. If this is the problem you're facing, I recommend plugging "notmuch new" into the tool you use to retrieve mail, e.g., as an offlineimap hook. If this is not the problem you're facing, I guess I'd need a reproducible test, because I've no (other) idea of what's going on :) Thanks for your bug report! Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#795383: please add a License field parser to the copyright module
Package: python-debian Version: 0.1.27 Severity: wishlist The debian.copyright module returns the content of the License field as a string, matching the literal value written down in the debian/copyright file. It would be nice (and will avoid duplicate work) if the module would offer a way to traverse the content of the License field as an AST, conformant to the semantics of machine-readable debian/copyright files. The AST should include at the very minimum boolean and/or combination of licenses (implementing the semantics of "," properly). Additionally, the AST could distinguish between trailing "+" for "or later" license variants, and support "with" for license exceptions. FWIW, Debsources would use this feature for rendering machine-readable copyright fiels if it were available. Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-debian depends on: ii python-chardet 2.3.0-1 ii python-six 1.9.0-3 pn python:any Versions of packages python-debian recommends: ii python-apt 1.0.0~beta3 Versions of packages python-debian suggests: ii gpgv 1.4.19-3 -- no debconf information
Bug#789647: fails to talk to quvi to download from youtube on jessie
On Mon, Jun 22, 2015 at 08:55:35PM -0400, Antoine Beaupré wrote: > Package: git-annex > Version: 5.20141125 > Severity: normal > > It seems this version of git-annex can't talk to quvi properly, even > though quvi can talk to youtube: Just confirming this bug. (FWIW I'm on Debian Stretch, but the git-annex version is the same.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788226: debsources: add package/version blacklist
Package: qa.debian.org Severity: wishlist User: qa.debian@packages.debian.org Usertags: debsources It would be nice to have a configurable package/version (and possibly /suite) blacklist, to exclude specific packages from processing. Use case: due to #753219 and #787271, we now have katoob/0.5.9.1-1.2+squeeze1 and moodle/1.9.9.dfsg2-2.1+squeeze4 which are not extractable. But nonetheless the updater try to extract them at every single update run, and fails. It's not a big deal for such small packages, but if it were to happen for lager packages it would be a problem. A blacklist would allow to ignore specific packages during update runs. Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788095: closed by Thomas Goirand (Issue fixed in pygit2 0.22.0-2?)
reopen 788095 thanks On Mon, Jun 08, 2015 at 02:21:10PM +, Debian Bug Tracking System wrote: > I tried, and I couldn't reproduce the issue. If you still see the > issue with version 0.22.0-2, please reopen this bug. I've installed (on testing) pygit2 from unstable, in the version you mentioned, and I can reproduce the bug. Again, rebuilding the package on my machine from sources (in the version above) fixed the issue. Cheers -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#788095: can't load pygit2: PermissionError: [Errno 13] Permission denied: '/usr/lib/python3/dist-packages/pygit2/__pycache__/pygit2_cffi_ea785866x5470904.c'
FYI: rebuilding the package in testing with "apt-get source -b" fixed the problem. Cheers -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788095: can't load pygit2: PermissionError: [Errno 13] Permission denied: '/usr/lib/python3/dist-packages/pygit2/__pycache__/pygit2_cffi_ea785866x5470904.c'
Package: python3-pygit2 Version: 0.22.0-1 Severity: serious It looks like pygit2 is not loadable in testing: zack@timira:~$ python3 Python 3.4.3+ (default, Jun 2 2015, 14:09:35) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pygit2 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/pygit2/__init__.py", line 35, in from .blame import Blame, BlameHunk File "/usr/lib/python3/dist-packages/pygit2/blame.py", line 32, in from .errors import check_error File "/usr/lib/python3/dist-packages/pygit2/errors.py", line 29, in from .ffi import ffi, C File "/usr/lib/python3/dist-packages/pygit2/ffi.py", line 35, in ffi, C = get_ffi() File "/usr/lib/python3/dist-packages/pygit2/_utils.py", line 101, in get_ffi include_dirs=[libgit2_include], library_dirs=[libgit2_lib]) File "/usr/lib/python3/dist-packages/cffi/api.py", line 340, in verify lib = self.verifier.load_library() File "/usr/lib/python3/dist-packages/cffi/verifier.py", line 73, in load_library self._write_source() File "/usr/lib/python3/dist-packages/cffi/verifier.py", line 125, in _write_source file = open(self.sourcefilename, 'w') PermissionError: [Errno 13] Permission denied: '/usr/lib/python3/dist-packages/pygit2/__pycache__/pygit2_cffi_ea785866x5470904.c' (FWIW, the same problem applies to the Python 2 package.) Cheers -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-pygit2 depends on: ii dpkg 1.17.25 ii libc6 2.19-18 ii libgit2-220.22.2-2 ii python3 3.4.2-2 ii python3-cffi 0.8.6-1 python3-pygit2 recommends no packages. Versions of packages python3-pygit2 suggests: pn python-pygit2-doc -- 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#787570: debsources: DB: change sha256 column data type from string to bytea or bit string
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: debsources Currently, the sha256 column of the checksum table in Debsources' Postgres DB has type character varying(64): sha256 | character varying(64) | not null Such a data type is wasteful in terms of disk space. And it shows: debsources=> select count(*) from checksums; count -- 41151812 public | checksums| table| debsources | 4890 MB| We should switch to a more economic (and efficient) data type for storing sha256 checksums. Good options seem to be either bytea [1] or fixed-size bit strings [2]. Suggestions welcome! A good, concrete way to help with this bug would be providing sample SQL snippets to create temporary tables with the new data types, and convert / inject into them the content of the current checksum table. That would allow to easily benchmark disk usage and query/index efficiency. Cheers. [1]: http://www.postgresql.org/docs/9.4/static/datatype-binary.html#AEN5497 [2]: http://www.postgresql.org/docs/9.4/static/datatype-bit.html -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753219: katoob: FTBFS: dpkg-source: error: expected ^--- in line 2 of diff `katoob-0.5.9.1/debian/patches/replace_fribidi-config_pkg-config.patch'
On Sat, May 30, 2015 at 10:04:08PM +0200, Guillem Jover wrote: > This wont be "fixed" in dpkg, that change was necessary to fix a > security issue in dpkg. In many cases it made visible existing broken > patches, like the one in moodle, which before the dpkg fix was only > getting partially applied, which renders that moodle security fix > partially moot. In others the patch was malformed and patch would > apply it correctly, but making dpkg try to distinguish between > malformed or malfeasant patches would go from either impossible, > too difficult or an arms race. Oh, I see, thanks for clarifying --- I had misinterpreted this as a regression in dpkg, while in fact it's a feature then. I'll check for fixes in the relevant packages then. FWIW, right now the only extraction failures I've noticed from the Debsources POV are moodle and katoob (but it is possible there are others, which I'm not seeing simply because they have been extracted in the past). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#753219: katoob: FTBFS: dpkg-source: error: expected ^--- in line 2 of diff `katoob-0.5.9.1/debian/patches/replace_fribidi-config_pkg-config.patch'
Heya, On Sun, Jul 06, 2014 at 11:04:09AM +0200, Guillem Jover wrote: > This also affects stable, it would be nice if a stable update could be > prepared, I'm ready to help if needed, given that the “regression” was > caused by the dpkg update. FWIW I've noticed in Debsources logs both this issue, and what seems to be another occurrence of it on the moodle package. I've now reported it here https://bugs.debian.org/787271 Is there a dpkg update planned to fix this in stable (or oldstable)? If so, I'll be glad to test it on the sources.d.n machine. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#787271: dpkg-source fails to extract old-old-stable version of moodle
Package: moodle Version: 1.9.9.dfsg2-2.1+squeeze4 Severity: serious Heya, on the old-old-stable version of moodle, dpkg-source -x fails with a non-zero exit code: zack@timira:/tmp$ dpkg-source -x moodle_1.9.9.dfsg2-2.1+squeeze4.dsc dpkg-source: info: extracting moodle in moodle-1.9.9.dfsg2 dpkg-source: info: unpacking moodle_1.9.9.dfsg2.orig.tar.gz dpkg-source: info: unpacking moodle_1.9.9.dfsg2-2.1+squeeze4.debian.tar.gz dpkg-source: info: applying MDL-23377 dpkg-source: info: applying MDL-24810 dpkg-source: info: applying MDL-24258 dpkg-source: info: applying cas1.1.3 dpkg-source: info: applying yui_file_renames dpkg-source: info: applying MDL-24523 dpkg-source: info: applying MDL-18839 dpkg-source: info: applying MDL-25122 dpkg-source: info: applying MDL-25754 dpkg-source: info: applying MDL-26030 dpkg-source: info: applying MDL-26189 dpkg-source: info: applying MDL-26966 dpkg-source: info: applying MDL-23872 dpkg-source: info: applying MDL-27464 dpkg-source: info: applying MDL-27889 dpkg-source: info: applying MDL-28197 dpkg-source: info: the patch has fuzz which is not allowed, or is malformed dpkg-source: info: if patch 'MDL-28197' is correctly applied by quilt, use 'quilt refresh' to update it dpkg-source: error: expected ^--- in line 21 of diff `moodle-1.9.9.dfsg2/debian/patches/MDL-28197' zack@timira:/tmp$ echo $? 2 zack@timira:/tmp$ Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
