Bug#1066313: fixed upstream
Hi, Le 11/04/2024 à 22:23, micah anderson a écrit : These issues are fixed upstream in main, but there is not a release. The fix is in commit 1171bf2fd4e7a0cab02cf5fca59090b65af9cd29. Clément would you pull that fix into the package to resolve this FTBFS? Thanks for the heads up! I'll try to upload a new version this week or early next week. I did include the fix, but there are a few lintian/policy issues I'd like to fix before an upload. Cheers, -- nodens
Bug#1066926: icingaweb2-module-x509_1: [INTL:de] updated German po file translation
Package: icingaweb2-module-x509_1 Version: 1.2.1+dfsg-3 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-x509_1 attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-x509_1_1.2.1+dfsg-3_templates.pot.bz2 Description: application/bzip
Bug#1066924: icingaweb2-module-toplevelview: [INTL:de] updated German po file translation
Package: icingaweb2-module-toplevelview Version: 0.3.3-3 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-toplevelview attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-toplevelview_0.3.3-3_templates.pot.bz2 Description: application/bzip
Bug#1066923: icingaweb2-module-generictts: [INTL:de] updated German po file translation
Package: icingaweb2-module-generictts Version: 2.1.0-2 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-generictts attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-generictts_2.1.0-2_templates.pot.bz2 Description: application/bzip
Bug#1066921: icingaweb2_module_eventdb: [INTL:de] updated German po file translation
Package: icingaweb2_module_eventdb Version: 1.3.0-4 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2_module_eventdb attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-eventdb_1.3.0-4_templates.pot.bz2 Description: application/bzip
Bug#1066920: icingaweb2-module-audit: [INTL:de] updated German po file translation
Package: icingaweb2-module-audit Version: 1.0.2-3 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-audit attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-audit_1.0.2-3_templates.pot.bz2 Description: application/bzip
Bug#1066919: icingaweb2-module-fileshipper: [INTL:de] updated German po file translation
Package: icingaweb2-module-fileshipper Version: 1.2.0-3 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-fileshipper attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-fileshipper_1.2.0-3_templates.pot.bz2 Description: application/bzip
Bug#1066915: icingaweb2-module-businessprocess: [INTL:de] updated German po file translation
Package: icingaweb2-module-businessprocess Version: 2.5.0-1 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-businessprocess attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-businessprocess_2.5.0-1_templates.pot.bz2 Description: application/bzip
Bug#1066914: icingaweb2-modulu-idoreports: [INTL:de] updated German po file translation
Package: icingaweb2-modulu-idoreports Version: 0.10.1-1 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-modulu-idoreports attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-idoreports_0.10.1-1_templates.pot.bz2 Description: application/bzip
Bug#1066913: icingaweb2-module-reporting: [INTL:de] updated German po file translation
Package: icingaweb2-module-reporting Version: 0.10.0-2 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-reporting attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-reporting_0.10.0-2_templates.pot.bz2 Description: application/bzip
Bug#1066912: icingaweb2-module-pdfexport: [INTL:de] updated German po file translation
Package: icingaweb2-module-pdfexport Version: 0.10.2+dfsg1-3 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-pdfexport attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-pdfexport_0.10.2+dfsg1-3_templates.pot.bz2 Description: application/bzip
Bug#1066906: icingaweb2-module-boxydash_0.0.1+20160321-5: [INTL:de] updated German po file translation
Package: icingaweb2-module-boxydash_0.0.1+20160321-5 Version: 0.0.1+20160321-5 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-boxydash_0.0.1+20160321-5 attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-boxydash_0.0.1+20160321-5_templates.pot.bz2 Description: application/bzip
Bug#1066102: icingaweb2-module-nagvis: [INTL:de] updated German po file translation
Package: icingaweb2-module-nagvis Version: 1.1.1-4 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-nagvis attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers
Bug#1066107: icingaweb2-module-pnp: [INTL:de] updated German po file translation
Package: icingaweb2-module-pnp Version: 1.1.0-4 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-pnp attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-pnp_1.1.0-4_templates.pot.bz2 Description: application/bzip
Bug#1066106: icingaweb2-module-nagvis: [INTL:de] updated German po file translation
Package: icingaweb2-module-nagvis Version: 1.1.1-4 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-nagvis attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-nagvis_1.1.1-4_templates.pot.bz2 Description: application/bzip
Bug#1066105: icingaweb2-module-cube: [INTL:de] updated German po file translation
Package: icingaweb2-module-cube Version: 1.3.2-1 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-cube attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-cube_1.3.2-1_templates.pot.bz2 Description: application/bzip
Bug#1066104: icingaweb2-module-graphite: [INTL:de] updated German po file translation
Package: icingaweb2-module-graphite Version: 1.2.2-3 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-graphite attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-graphite_1.2.2-3_templates.pot.bz2 Description: application/bzip
Bug#1066103: icingaweb2-module-cube: [INTL:de] updated German po file translation
Package: icingaweb2-module-cube Version: 1.3.2-1 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-cube attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers
Bug#1066101: icingaweb2-module-pnp: [INTL:de] updated German po file translation
Package: icingaweb2-module-pnp Version: 1.1.0-4 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-pnp attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers
Bug#1066099: icingaweb2-module-map: [INTL:de] updated German po file translation
Package: icingaweb2-module-map Version: 1.1.0-4 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-map attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-map_1.1.0-4_templates.pot.bz2 Description: application/bzip
Bug#1066047: icingaweb2-module-incubator: [INTL:de] updated German po file translation
Package: icingaweb2-module-incubator Version: 0.20.0-2 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-incubator attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-incubator_0.20.0-2_templates.pot.bz2 Description: application/bzip
Bug#1066041: icingaweb2-module-statusmap: [INTL:de] updated German po file translation
Package: icingaweb2-module-statusmap Version: 20160720-5 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-statusmap attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-statusmap_20160720-5_de.po.bz2 Description: application/bzip
Bug#1065083: $icingaweb2-module-director: [INTL:de] updated German icingaweb2-module-director translation\
Package: icingaweb2-module-director Version: 1.10.2-2 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for icingaweb2-module-director attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef Beckers icingaweb2-module-director_1.10.2-2.de.po.bz2 Description: application/bzip
Bug#1062831: guitarix: segfaults, when creating a preset bank
Hi Guitarix maintainer here. I've pushed a fix for that to our repository, this is the relevant patch to fix this issue: https://github.com/brummer10/guitarix/commit/80e951fb3212c058c507c421cecfacca1f6d2932 regards hermann
Bug#1055756: libasound2: some legacy midi apps (e.g. Chromium WebMIDI) are broken by alsa-lib 1.2.10
Hi, FYI I created a merge request at https://salsa.debian.org/alsa-team/alsa-lib/-/merge_requests/4 to fix this one, using upstream patch. cheers! -- nodens
Bug#1056206: graphite-web: saving graphs in dashboard is broken (only in stable version 1.1.8-2)
Package: graphite-web
Version: 1.1.8-2
Severity: normal
Tags: patch
Dear Maintainer,
graphite-web in bookworm (1.1.8-2) does not allow saving dashboards due to
missing function
htmlEncode from dashboard.js. Workaround is to install 1.1.10-1 from testing,
where
dashboard.js contains the definition of htmlEncode.
As a note to others: js is cached in the browser for quite some time, so the
showing up of the bug was delayed
Please consider the applied patch for bookwoorm which simply adds the missing
function.
Thanks and greetings
Hermann
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)
Kernel: Linux 6.5.2 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_TEST
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages graphite-web depends on:
ii adduser 3.134
ii python3 3.11.2-1+b1
ii python3-cairo 1.20.1-5+b1
ii python3-cairocffi 1.4.0-1
ii python3-django 3:3.2.19-1+deb12u1
ii python3-django-tagging 1:0.5.0-4
ii python3-pyparsing 3.0.9-1
ii python3-simplejson 3.18.3-1
ii python3-six 1.16.0-4
ii python3-tz 2022.7.1-4
ii python3-urllib3 1.26.12-1
ii python3-whisper 1.1.4-2.2
graphite-web recommends no packages.
Versions of packages graphite-web suggests:
pn graphite-carbon
pn libapache2-mod-wsgi-py3
pn python3-ldap
pn python3-memcache
pn python3-mysqldb
-- Configuration Files:
/etc/graphite/local_settings.py changed [not included]
-- no debconf information
--- gw/usr/share/graphite-web/static/js/dashboard.js2023-03-17
14:24:47.0 +0100
+++ gw10/usr/share/graphite-web/static/js/dashboard.js 2023-09-21
16:39:16.0 +0200
@@ -157,6 +157,12 @@
return false;
}
+function htmlEncode(input) {
+ return input.replace(/[^a-zA-Z0-9 ]/g, function (chr) {
+return '&#
Bug#1055756: libasound2: some legacy midi apps (e.g. Chromium WebMIDI) are broken by alsa-lib 1.2.10
Package: libasound2 Version: 1.2.10-1 Severity: normal Tags: patch upstream Dear Alsa team, alsa-lib 1.2.10 implements UMP support for seq. Unfortunately, it breaks chromium WebMIDI at least partially. This is a chromium bug, actually, but since it is a regression, upstream has implemented a workaround for it: Upstream Issue: https://github.com/alsa-project/alsa-lib/issues/360 Upstream fix: https://github.com/alsa-project/alsa-lib/commit/2fca03e792ef1b740e8a7370fdd360d0b627c84c I have a fixed version available at https://salsa.debian.org/nodens/alsa-lib. (I'd have applied to join the team or proposed a NMU, but I forgot to update my key in time and can't upload right now). Cheers, nodens -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libasound2 depends on: ii libasound2-data 1.2.10-1 ii libc62.37-12 libasound2 recommends no packages. Versions of packages libasound2 suggests: ii libasound2-plugins 1.2.7.1-1+b1 -- no debconf information
Bug#1053869: alsa-ucm-conf: Devices profiles using ucm2/common/pcm/split.conf won't load (undefined var)
Package: alsa-ucm-conf
Version: 1.2.10-1
Severity: normal
Tags: upstream
Dear Alsa team,
Since 1.2.10, profiles using ucm2/common/pcm/split.conf won't load (at
least on Arturia Minifuse 1 and 2, and Motu M4). As a result, for cards
with more than 2 outputs, the default surround profile is loaded instead.
```
~$ alsaucm listcards
ALSA lib ucm_subs.c:807:(uc_mgr_get_substituted_value) variable
'${var:__Device}' is not defined in this context!
ALSA lib parser.c:2024:(parse_verb_file) error:
/USB-Audio/Arturia/Minifuse-12-HiFi.conf failed to parse device
ALSA lib main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:1 use
case configuration -22
ALSA lib parser.c:2965:(uc_mgr_scan_master_configs) Unable to open '-hw:1':
Invalid argument
alsaucm: error failed to get card list: Invalid argument
```
Issue is known upstream
(https://github.com/alsa-project/alsa-ucm-conf/issues/346) and fixed by
https://github.com/alsa-project/alsa-ucm-conf/commit/b68aa52acdd2763fedad5eec0f435fbf43e5ccc6
Applying the change directly in
`/usr/share/alsa/ucm2/common/pcm/split.conf` fixes the issue (hence the
local modification reported by reportbug). I guess the next release of
alsa-ucm-conf will include it, but in the meantime, I suggest applying
it as a patch in Debian.
I can provide a MR on salsa if it helps.
Cheers,
nodens
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages alsa-ucm-conf depends on:
ii libasound2 1.2.10-1
alsa-ucm-conf recommends no packages.
alsa-ucm-conf suggests no packages.
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/share/alsa/ucm2/common/pcm/split.conf (from
alsa-ucm-conf package)
Bug#1037685: guitarix: ftbfs with GCC-13
Hi This bug is already fixed in upstream, here is the related patch: https://github.com/brummer10/guitarix/commit/b52736180b6966f24398f8a5ad179a58173473ec regards hermann
Bug#1017619: nautilus-wipe: Fails to build with nautilus 43
Hi, FYI, Upstream has started work on that in a branch https://git.tuxfamily.org/wipetools/nautiluswipe.git/log/?h=nautilus-extension-4-wip. There are "alpha release" but I'm not sure this will be ready for bookworm. I can try to update it in experimental, though. Cheers, -- nodens
Bug#1029048: torsocks: Consider update Debian Package with latest upstream commits on master branch
Package: torsocks Version: 2.3.0-3 Severity: wishlist Hi, upstream has some interesting commits in the Master branch (but no release). Notably, it seems now to handle syscall passthrough instead of dropping them with a warning. We might want that in Bookworm (but this need to happen soon). https://gitweb.torproject.org/torsocks.git/commit/?id=67cee6c7976b4e103e6f9c3a70e767ffe54368e0 Thanks Unit193 for pointing that out! Cheers, -- nodens -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages torsocks depends on: ii libc6 2.36-7 Versions of packages torsocks recommends: ii tor 0.4.7.12-1 torsocks suggests no packages. -- no debconf information
Bug#1028971: sub...@bugs.debian.org
Package: ndisc6 Severity: wishlist Tags: patch l10n Please find the updated German po file translation for ndisc6 attached. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Greetings hjb ndisc6_1.0.5-1_de.po.bz2 Description: application/bzip
Bug#1016881: Please update chrome-gnome-shell to version 42
Hi, Le 24/11/2022 à 07:44, Andres Salomon a écrit : On Sat, 24 Sep 2022 12:39:08 +0200 =?utf-8?q?Cl=C3=A9ment_Hermann?= wrote: > Package: chrome-gnome-shell > Version: 10.1-5 > Followup-For: Bug #1016881 > > Hi, > > Not sure it's actually a bug on chrome-gnome-shell, since what we need > is a new package that will replace this one for gnome >=42. chrome-gnome-shell should probably turn into an empty package that depends on gnome-browser-extension (once it's uploaded). It would be good to get this done before bookworm freezes. Agreed. > > The bug here is it should depends on gnome-shell <42.0, I guess. > > RFP for gnome-browser-extension: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020616 > I guess if no one else does it, I'll do it? I'm willing to help, but I'm afraid I won't find enough time to do it before the freeze since I'm a bit swamped at the moment and have no experience packaging anything using meson… Cheers -- nodens
Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696
Hi Le 25/10/2022 à 13:53, Clément Hermann a écrit : Hi Moritz, Le 25/10/2022 à 11:15, Moritz Muehlenhoff a écrit : Given that the primary use case for onionshare will be tails, my suggestion would be that CVE-2022-21689 and CVE-2022-21690 get backported fixes for the next Bullseye point release (which Tails will sync up to). What do you think? There are some users of onionshare beside in Tails, but that sounds like a viable plan. FYI, backported fixes have been uploaded and should be included in next point release (#1023981) Cheers, -- nodens
Bug#1023981: bullseye-pu: package onionshare/2.2-3+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Following discussion with Security Team about vulnerabilities in
onionshare (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014966 ), I prepared a
patched version which backport upstream fixes for CVE-2022-21689 and
CVE-2022-21690.
Moritz proposed we just use point release for those instead of uploading
to bullseye-security, hence this request. The issues aren't that
critical and we are lagging already, so it can wait a few weeks more.
[ Impact ]
If the request isn't approved, I guess I'll ask Security Team to make it
a security upload.
[ Tests ]
I modified the tests in the code, and I did test the modified
functionnality manually with a bullseye virtual machine.
[ Risks ]
Modifications are quite simple. The last relevant CVE referenced in the
bug above would mean a lot more work, and more risks (backporting a lot
of code, or actually upgrade stable to 2.5, which would imply upgrading
python-stem as well). Since it is considered an edge case, it's been
decided it would be ignored in bullseye (I intend to provide a backport
later for user who would be at risk otherwise).
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in stable
[x] the issue is verified as fixed in unstable
[ Changes ]
* Change debian-branch to debian/bullseye in d/gbp.conf (ignored for
dch)
* Backport upstream fix for CVE-2022-21690 by forcing PlainText in
QLabel
* Backport upstream fix for CVE-2022-21689 by using µsec in filenames
when receiving files
diff -Nru onionshare-2.2/debian/changelog onionshare-2.2/debian/changelog
--- onionshare-2.2/debian/changelog 2021-01-11 12:12:11.0 +0100
+++ onionshare-2.2/debian/changelog 2022-11-12 17:23:52.0 +0100
@@ -1,3 +1,10 @@
+onionshare (2.2-3+deb11u1) bullseye; urgency=medium
+
+ * Backport upstream fix for CVE-2022-21690
+ * Backport upstream fix for CVE-2022-21689
+
+ -- Clément Hermann Sat, 12 Nov 2022 17:23:52 +0100
+
onionshare (2.2-3) unstable; urgency=medium
[ Ulrike Uhlig ]
diff -Nru onionshare-2.2/debian/gbp.conf onionshare-2.2/debian/gbp.conf
--- onionshare-2.2/debian/gbp.conf 2020-08-29 19:03:20.0 +0200
+++ onionshare-2.2/debian/gbp.conf 2022-11-12 17:23:52.0 +0100
@@ -1,4 +1,4 @@
[DEFAULT]
pristine-tar = True
-debian-branch = debian/sid
+debian-branch = debian/bullseye
upstream-branch = master
diff -Nru onionshare-2.2/debian/patches/CVE-2022-21689-fix.diff
onionshare-2.2/debian/patches/CVE-2022-21689-fix.diff
--- onionshare-2.2/debian/patches/CVE-2022-21689-fix.diff 1970-01-01
01:00:00.0 +0100
+++ onionshare-2.2/debian/patches/CVE-2022-21689-fix.diff 2022-11-12
17:23:52.0 +0100
@@ -0,0 +1,54 @@
+Description: Fix for CVE-2022-21689
+ Adapted from upstream
https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377
+
+use microseconds for timestamps in filename
+
+Origin: backport,
https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377
+Bug-GitHub:
https://github.com/onionshare/onionshare/security/advisories/GHSA-jh82-c5jw-pxpc
+Last-Update: 2022-11-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/onionshare/web/receive_mode.py
b/onionshare/web/receive_mode.py
+@@ -294,7 +294,7 @@
+ # Figure out what files should be saved
+ now = datetime.now()
+ date_dir = now.strftime("%Y-%m-%d")
+-time_dir = now.strftime("%H.%M.%S")
++time_dir = now.strftime("%H.%M.%S.%f")
+ self.receive_mode_dir = os.path.join(
+ self.web.common.settings.get("data_dir"), date_dir, time_dir
+ )
+--- a/tests/GuiReceiveTest.py
b/tests/GuiReceiveTest.py
+@@ -1,3 +1,4 @@
++import glob
+ import os
+ import requests
+ from datetime import datetime, timedelta
+@@ -50,17 +51,17 @@
+ now = datetime.now()
+ for i in range(10):
+ date_dir = now.strftime("%Y-%m-%d")
+-if identical_files_at_once:
+-time_dir = now.strftime("%H.%M.%S-1")
+-else:
+-time_dir = now.strftime("%H.%M.%S")
++time_dir = now.strftime("%H.%M.%S")
+ receive_mode_dir = os.path.join(
+ self.gui.common.settings.get("data_dir"), date_dir, time_dir
+ )
+-expected_filename = os.path.join(receive_mode_dir,
expected_basename)
+-if os.path.exists(expected_filename):
+-exists = True
+-break
++# The directories have microseconds in the name, so we need
++# to use globbing against d
Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696
Hi Moritz, Le 25/10/2022 à 11:15, Moritz Muehlenhoff a écrit : Hi Clément, Sadly, upstream rectified and confirms it affects 2.2 [0], and has been tested and reproduced on Bullseye. We do need to fix it. Upstream has a few suggestions, but I guess our choices are either uploading 2.5 to stable, if that's possible. python-stem at least will need to be updated as well, from 1.8.0 to 1.8.1 which luckily is bugfix only. With the upstream confirmation about affected states I had a look at the remaining issues affecting Bullseye: Thanks! CVE-2022-21694 (https://github.com/onionshare/onionshare/security/advisories/GHSA-h29c-wcm8-883h) is not a vulnerability by itself, it's a lack of a feature at most. We can ignore it for Bullseye. Agreed, that's my reasoning too. CVE-2022-21688 (https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v) is just a stop gap, the actual issue is in QT and I'll reach out to upstream for more information when this was fixed in QT so that it can be backported to Bullseye's QT packages. Agreed. The fix for CVE-2022-21690 will provide a workaround as well. This leaves: https://security-tracker.debian.org/tracker/CVE-2022-21690 https://security-tracker.debian.org/tracker/CVE-2022-21689 https://security-tracker.debian.org/tracker/CVE-2021-41868 I think it's fair to ignore CVE-2021-41868 for Bullseye, it sounds like an edge case and invasive to fix. I'm not sure how much of an edge case it is. But I agree it's fair. We could provide a backport for users needing secure authentication, so they could use onion v3 auth for this usage (I didn't check yet how easy a backport would be, but I expect it'd be simple except maybe for the poetry build system part). This leaves CVE-2022-21690 and CVE-2022-21689 which have isolated patches which could be backported? Yes. Given that the primary use case for onionshare will be tails, my suggestion would be that CVE-2022-21689 and CVE-2022-21690 get backported fixes for the next Bullseye point release (which Tails will sync up to). What do you think? There are some users of onionshare beside in Tails, but that sounds like a viable plan. Cheers, -- nodens
Bug#1021732: [Pkg-privacy-maintainers] Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...
Hi Georg, Le 14/10/2022 à 11:12, Georg Faerber a écrit : Control: forwarded -1 https://0xacab.org/jvoisin/mat2/-/issues/178 Control: tags -1 + fixed-upstream upstream Hi Paul, On 22-10-13 19:52:35, Paul Gevers wrote: With a recent upload of libimage-exiftool-perl the autopkgtest of mat2 fails in testing when that autopkgtest is run with the binary packages of libimage-exiftool-perl from unstable. Thanks for your report. Do you mind if I cherry-pick the upstream fix and upload today ? This is blocking the perl 5.36 transition. Thanks! -- nodens
Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696
Le 24/10/2022 à 20:41, Clément Hermann a écrit : - CVE-2022-21694 <https://github.com/advisories/GHSA-h29c-wcm8-883h> affects Bullseye, but that might be an acceptable risk ? The issue is that CSP can only be turned on or off, not configured to allow js etc, so it is only useful for static websites. I believe that's the most common usage of a website with onionshare, and it's arguably a missing feature more than a vulnerability /per se/. - CVE-2022-21689 <https://github.com/advisories/GHSA-jh82-c5jw-pxpc> fix should be easy to backport, at a glance: https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377 - CVE-2021-41868 <https://github.com/advisories/GHSA-7g47-xxff-9p85> doesn't affect 2.2 I think, it must have been a mistake from mig5. I just asked for confirmation. I do hope so since it's a bad one. Sadly, upstream rectified and confirms it affects 2.2 [0], and has been tested and reproduced on Bullseye. We do need to fix it. Upstream has a few suggestions, but I guess our choices are either uploading 2.5 to stable, if that's possible. python-stem at least will need to be updated as well, from 1.8.0 to 1.8.1 which luckily is bugfix only. - CVE-2022-21690 <https://github.com/advisories/GHSA-ch22-x2v3-v6vq> seems like a one-line patch: https://github.com/onionshare/onionshare/commit/8f1e7ac224e54f57e43321bba2c2f9fdb5143bb0 - CVE-2022-21688 <https://github.com/advisories/GHSA-x7wr-283h-5h2v> seems like it should be worked around with the CVE-2022-21690 <https://github.com/advisories/GHSA-ch22-x2v3-v6vq> fix (OTF-001)? I'd welcome input on those. Of course if we choose to update onionshare to 2.5 in stable, we fix those as well. [0] https://github.com/onionshare/onionshare/issues/1633#issuecomment-1289735350 Cheers, -- nodens
Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696
Le 24/10/2022 à 18:26, Clément Hermann a écrit : Hi, Le 23/10/2022 à 18:27, Clément Hermann a écrit : Hi, Le 22/10/2022 à 15:01, Salvatore Bonaccorso a écrit : To be on safe side, explicitly confirming by upstream would be great. Agreed. And asked upstream: https://github.com/onionshare/onionshare/issues/1633. Upstream replied quickly (yay!) and confirms the known issues are fixed in 2.5. Also, the detail of the vulnerable/patched versions has been updated. Quoting from the upstream issue: Only affected >= 2.3 - < 2.5: CVE-2021-41867 <https://github.com/advisories/GHSA-6rvj-pw9w-jcvc>, CVE-2022-21691 <https://github.com/advisories/GHSA-w9m4-7w72-r766>, CVE-2022-21695 <https://github.com/advisories/GHSA-99p8-9p2c-49j4>, CVE-2022-21696 <https://github.com/advisories/GHSA-68vr-8f46-vc9f> Only affected >= 2.2 - < 2.5: CVE-2022-21694 <https://github.com/advisories/GHSA-h29c-wcm8-883h> Only affected >=2.0 - < 2.5: CVE-2022-21689 <https://github.com/advisories/GHSA-jh82-c5jw-pxpc> Only affected >=2.0 - < 2.4: CVE-2021-41868 <https://github.com/advisories/GHSA-7g47-xxff-9p85> (Receive mode bug, fixed by changing the authentication from HTTP auth to using Client Auth in Tor itself) All versions < 2.5: CVE-2022-21690 <https://github.com/advisories/GHSA-ch22-x2v3-v6vq>, and possibly depending on the Qt version, CVE-2022-21688 <https://github.com/advisories/GHSA-x7wr-283h-5h2v> GHSA-jgm9-xpfj-4fq6 <https://github.com/onionshare/onionshare/security/advisories/GHSA-jgm9-xpfj-4fq6> is a complicated one, as a fix <https://github.com/onionshare/onionshare/pull/1474> we reduced the scope of access for Flatpak but you could argue that on 'native' Debian the whole file system, or at least the parts accessible to the user running OnionShare, is available not even in read-only mode. I'm not sure there's really a 'fix' for the deb package. The advisories on https://github.com/onionshare/onionshare/security/advisories have been updated to reflect this. I did more homework. So, to summarize: - CVE-2021-41867 <https://github.com/advisories/GHSA-6rvj-pw9w-jcvc>, CVE-2022-21691 <https://github.com/advisories/GHSA-w9m4-7w72-r766>, CVE-2022-21695 <https://github.com/advisories/GHSA-99p8-9p2c-49j4>, CVE-2022-21696 <https://github.com/advisories/GHSA-68vr-8f46-vc9f> aren't affecting Debian (stable has 2.2, unstable has 2.5). Which is good because the - CVE-2022-21694 <https://github.com/advisories/GHSA-h29c-wcm8-883h> affects Bullseye, but that might be an acceptable risk ? The issue is that CSP can only be turned on or off, not configured to allow js etc, so it is only useful for static websites. I believe that's the most common usage of a website with onionshare, and it's arguably a missing feature more than a vulnerability /per se/. - CVE-2022-21689 <https://github.com/advisories/GHSA-jh82-c5jw-pxpc> fix should be easy to backport, at a glance: https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377 - CVE-2021-41868 <https://github.com/advisories/GHSA-7g47-xxff-9p85> doesn't affect 2.2 I think, it must have been a mistake from mig5. I just asked for confirmation. I do hope so since it's a bad one. - CVE-2022-21690 <https://github.com/advisories/GHSA-ch22-x2v3-v6vq> seems like a one-line patch: https://github.com/onionshare/onionshare/commit/8f1e7ac224e54f57e43321bba2c2f9fdb5143bb0 - CVE-2022-21688 <https://github.com/advisories/GHSA-x7wr-283h-5h2v> seems like it should be worked around with the CVE-2022-21690 <https://github.com/advisories/GHSA-ch22-x2v3-v6vq> fix (OTF-001)? I'd welcome input on those. Cheers, -- nodens
Bug#1022725: onionshare: Please provide Apparmor profiles (GHSA-jgm9-xpfj-4fq6)
Package: onionshare Version: 2.5-2 Severity: wishlist Quoting https://github.com/onionshare/onionshare/security/advisories/GHSA-jgm9-xpfj-4fq6 > Between September 26, 2021 and October 8, 2021, Radically Open > Security conducted a penetration test of OnionShare 2.4, funded by the > Open Technology Fund's Red Team lab. This is an issue from that > penetration test. > Vulnerability ID: OTF-013 > Vulnerability type: Improper Hardening > Threat level: Low > Description: > > The filesystem restriction could be hardened and should only allow for > pre-defined subfolders. Upstream uses Flatpak to mitigate this, which of course makes little sense on Debian. However, we could provide something similar using Apparmor. Cheers, -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages onionshare depends on: ii onionshare-cli 2.5-2 ii python33.10.6-1 ii python3-pyside2.qtcore 5.15.2-2.3+b2 ii python3-pyside2.qtwidgets 5.15.2-2.3+b2 ii python3-qrcode 7.3.1-1 onionshare recommends no packages. onionshare suggests no packages. -- no debconf information
Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696
Hi, Le 23/10/2022 à 18:27, Clément Hermann a écrit : Hi, Le 22/10/2022 à 15:01, Salvatore Bonaccorso a écrit : Thanks for the quick reply! (much appreciated). I think it would be good to get a confirmation from upstream and if possible to have those advisories updates. E.g. https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v while mentioning "affected versions < 2.4" the patched version remains "none". this might be that the < 2.4 just reflects the point in time when the advisory was filled. OTOH you have arguments with the v2.5 release information that they might all be fixed. To be on safe side, explicitly confirming by upstream would be great. Agreed. And asked upstream: https://github.com/onionshare/onionshare/issues/1633. Upstream replied quickly (yay!) and confirms the known issues are fixed in 2.5. Also, the detail of the vulnerable/patched versions has been updated. Quoting from the upstream issue: Only affected >= 2.3 - < 2.5: CVE-2021-41867 <https://github.com/advisories/GHSA-6rvj-pw9w-jcvc>, CVE-2022-21691 <https://github.com/advisories/GHSA-w9m4-7w72-r766>, CVE-2022-21695 <https://github.com/advisories/GHSA-99p8-9p2c-49j4>, CVE-2022-21696 <https://github.com/advisories/GHSA-68vr-8f46-vc9f> Only affected >= 2.2 - < 2.5: CVE-2022-21694 <https://github.com/advisories/GHSA-h29c-wcm8-883h> Only affected >=2.0 - < 2.5: CVE-2022-21689 <https://github.com/advisories/GHSA-jh82-c5jw-pxpc> Only affected >=2.0 - < 2.4: CVE-2021-41868 <https://github.com/advisories/GHSA-7g47-xxff-9p85> (Receive mode bug, fixed by changing the authentication from HTTP auth to using Client Auth in Tor itself) All versions < 2.5: CVE-2022-21690 <https://github.com/advisories/GHSA-ch22-x2v3-v6vq>, and possibly depending on the Qt version, CVE-2022-21688 <https://github.com/advisories/GHSA-x7wr-283h-5h2v> GHSA-jgm9-xpfj-4fq6 <https://github.com/onionshare/onionshare/security/advisories/GHSA-jgm9-xpfj-4fq6> is a complicated one, as a fix <https://github.com/onionshare/onionshare/pull/1474> we reduced the scope of access for Flatpak but you could argue that on 'native' Debian the whole file system, or at least the parts accessible to the user running OnionShare, is available not even in read-only mode. I'm not sure there's really a 'fix' for the deb package. The advisories on https://github.com/onionshare/onionshare/security/advisories have been updated to reflect this. -- nodens
Bug#915869: onionshare sometimes get backtrace on shutdown
Hi, have you seen the same issue with recent (2.x) versions? (asking because I never had the issue, and I'm tempted to close this as fixed in current testing version at least). Cheers, -- nodens
Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696
Hi, Le 22/10/2022 à 15:01, Salvatore Bonaccorso a écrit : Thanks for the quick reply! (much appreciated). I think it would be good to get a confirmation from upstream and if possible to have those advisories updates. E.g. https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v while mentioning "affected versions < 2.4" the patched version remains "none". this might be that the < 2.4 just reflects the point in time when the advisory was filled. OTOH you have arguments with the v2.5 release information that they might all be fixed. To be on safe side, explicitly confirming by upstream would be great. Agreed. And asked upstream: https://github.com/onionshare/onionshare/issues/1633. Cheers, -- nodens
Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)
Hi, Le 22/10/2022 à 15:59, Vincent Lefevre a écrit : Hi, On 2022-10-22 14:31:24 +0200, Clément Hermann wrote: I could reproduce your issue if I enable check_sigs option in CPAN (which is _not_ the default). OK, I forgot about that (though I think that it should be the default for security reasons, and IIRC, this was recommended for this reason in some other thread). I do think it's a good idea to enable it. Thing is, it's not a bug, really. Or not quite. It's a result of the correction of a bug in CPAN < 2.29 who would succeed silently if there is no signature/no way to check the key. You can find some context in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html I didn't know that. In particular, I had not got any announce, probably because it is still not fixed in Debian/stable. And AFAIK, http is also still used by default in Debian/stable, so that this makes the security even worse. http or not won't change much, since CPAN uses a mirror network (arguably with only "safe" mirrors now). Checking the signature of the hashes is the right way to make sure a downloaded module is really the one a developer makes available. I do agree that it's bad UX that CPAN isn't more helpful when the key isn't available, e.g. asking for it or suggesting a way to get it, but the fact that it fails if the key isn't available while the Checksums are signed is the right behavior, and your workaround (getting the key) is the right solution. CPAN doesn't have a way to centralize key themself, and probably shouldn't, either. Not sure how such error can be avoided completely (the Debian method of having a preconfigured keyring won't do for CPAN IMO), but it should at least suggest a solution. I agree. There should be at least sufficient documentation when the error occurs. If Debian could automatically provide the key and use it, this would be better, IMHO: less work for the user, and this would ensure (if correctly done) that the key is correct and still valid. Thing is, Debian cannot anticipate what modules you want to install via CPAN (so outside of Debian), so which developer keys to get, and also cannot install keys from all CPAN contributors in the user keyring… A way to fix this would be to make the message in CPAN more helpful and propose to get the key from a known source (e.g. keyserver), but I think that really ought to be done upstream. Note that in my current installation, a more helpful message is displayed at the end (possibly because I installed libmodule-signature-perl): ``` Module::Signature verification returned value 0E0 The manual says for this case: Cannot verify the OpenPGP signature, maybe due to the lack of a network connection to the key server, or if neither gnupg nor Crypt::OpenPGP exists on the system. You probably want to analyse the situation and if you cannot fix it you will have to decide whether you want to stop this session or you want to turn off signature verification. The latter would be done with the command 'o conf init check_sigs' ``` I'm guessing the key would be donwloaded with Crypt::OpenPGP installed (unfortunately not in Debian yet), but I didn't test. Please report if you test with Crypt::OpenPGP installed via CPAN: if that makes the behaviour better UX-wise, we should package it (there are a few deps but I don't see any issue at a glance). Cheers, -- nodens
Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696
Hi Salvatore, Le 22/10/2022 à 13:49, Salvatore Bonaccorso a écrit : For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-41867 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41867 [1] https://security-tracker.debian.org/tracker/CVE-2021-41868 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41868 [2] https://security-tracker.debian.org/tracker/CVE-2022-21688 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21688 [3] https://security-tracker.debian.org/tracker/CVE-2022-21689 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21689 [4] https://security-tracker.debian.org/tracker/CVE-2022-21690 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21690 [5] https://security-tracker.debian.org/tracker/CVE-2022-21691 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21691 [6] https://security-tracker.debian.org/tracker/CVE-2022-21692 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21692 [7] https://security-tracker.debian.org/tracker/CVE-2022-21693 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21693 [8] https://security-tracker.debian.org/tracker/CVE-2022-21694 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21694 [9] https://security-tracker.debian.org/tracker/CVE-2022-21695 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21695 [10] https://security-tracker.debian.org/tracker/CVE-2022-21696 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21696 From the reported list CVE-2021-41867 and CVE-2021-41868 were addressed in 2.4 upstream. But the other seem yet unfixed in 2.5, even though likely as well those who contain "has been patched in 2.5". I have not found any indication that this there is really the case. Any more insights OTOH from you on those? According to onionshare 2.5 release notes [1], and to the vulnerabilities list on the github project [2], I'd say they were fixed. All vulnerabilities are marked as affecting <2.4 since 2.5 release, and for instance for the username impersonation, it's been specified in the release notes that the security have been tightened on this front. That said, I didn't check the code for every vuln individually, and I definitely could ask upstream for clarification/confirmation if you think it's necessary. [1] https://github.com/onionshare/onionshare/releases/tag/v2.5 [2] https://github.com/onionshare/onionshare/security/advisories Cheers, -- nodens
Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)
Hi! Thanks for your report. I could reproduce your issue if I enable check_sigs option in CPAN (which is _not_ the default). Thing is, it's not a bug, really. Or not quite. It's a result of the correction of a bug in CPAN < 2.29 who would succeed silently if there is no signature/no way to check the key. You can find some context in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html I do agree that it's bad UX that CPAN isn't more helpful when the key isn't available, e.g. asking for it or suggesting a way to get it, but the fact that it fails if the key isn't available while the Checksums are signed is the right behavior, and your workaround (getting the key) is the right solution. CPAN doesn't have a way to centralize key themself, and probably shouldn't, either. Not sure how such error can be avoided completely (the Debian method of having a preconfigured keyring won't do for CPAN IMO), but it should at least suggest a solution. So setting the severity back to normal, but still leaving the bug open, since it's confusing for the user, and it could be done better (upstream). Cheers, -- nodens
Bug#1022203: openpgp-applet: since upstream move from Alioth to Salsa, uscan fails
Source: openpgp-applet Version: 1.1-3 Severity: normal Hi, Since some time, the debian/watch for opengpgp-applet can't get signatures. The signatures are in the /upload/ subdirectory, which is unpredicatable: Looking at https://salsa.debian.org/openpgp-applet-team/openpgp-applet/-/archive/OpenPGP_Applet-1.1/openpgp-applet-OpenPGP_Applet-1.1.tar.gz, we can get the download link for tarballs, but to get the signature for this file, one has to follow the link to the release desc: https://salsa.debian.org/openpgp-applet-team/openpgp-applet/-/tags/OpenPGP_Applet-1.1 in which the signature can be downloaded: https://salsa.debian.org/openpgp-applet-team/openpgp-applet/uploads/77ee3004f99643f3a2275317354bf950/OpenPGP_Applet-1.1.tar.gz.asc This is fine for humans who will figure it out, but bad for automation. Maybe there is a way to parse a specific page with the version name with uscan? Didn't find an obvious way, but would welcome pointers. Cheers -- nodens
Bug#1021901: ardour: Ardour 7.0.0 out :)
Package: ardour Version: 1:6.9.0+ds0-2+b1 Severity: wishlist Dear Maintainer, In case you didn't notice yet, Ardour 7.0.0 has been released on October 15th. Since I wanted to give it a go, I thought I'd try to upgrade to the last upstream release. So I created a MR on salsa for you to review: https://salsa.debian.org/multimedia-team/ardour/-/merge_requests/4 It's still in Draft since there are a few things to fix still (check TODO section in changelog). I intend to fix them before removing the Draft tag. Of course, feel free to beat me to it, add commits before merging, remove the draft tag and just merge and work from there; or cherry-pick what you want… I tried my best to stay consistent with the previous work / team rules, but I'm new to these packages, so I might have missed stuff. HTH, -- nodens -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ardour depends on: ii ardour-data 1:6.9.0+ds0-2 ii ardour-lv2-plugins1:6.9.0+ds0-2+b1 ii libarchive13 3.6.0-1 ii libasound21.2.7.2-1 ii libatkmm-1.6-1v5 2.28.3-1 ii libaubio5 0.4.9-4.2+b1 ii libc6 2.35-2 ii libcairo2 1.16.0-6 ii libcairomm-1.0-1v51.14.4-1 ii libcurl3-gnutls 7.85.0-1 ii libcwiid1 0.6.91-4 ii libdbus-1-3 1.14.2-1 ii libfftw3-single3 3.3.8-2 ii libfluidsynth32.3.0-1 ii libfontconfig12.13.1-4.5 ii libgcc-s1 12.2.0-5 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libglib2.0-0 2.74.0-2 ii libglibmm-2.4-1v5 2.66.5-1 ii libgtk2.0-0 2.24.33-2 ii libgtkmm-2.4-1v5 1:2.24.5-4+b1 ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-1 ii liblilv-0-0 0.24.14-1 ii liblo70.31-1 ii liblrdf0 0.6.1-2 ii libltc11 1.3.1-1 ii libpango-1.0-01.50.10+ds-1 ii libpangocairo-1.0-0 1.50.10+ds-1 ii libpangoft2-1.0-0 1.50.10+ds-1 ii libpangomm-1.4-1v52.46.3-1 ii libpulse0 16.1+dfsg1-2 ii libqm-dsp01.7.1-5 ii libreadline8 8.2-1 ii librubberband23.0.0+dfsg0-1+b1 ii libsamplerate00.2.2-2 ii libsigc++-2.0-0v5 2.10.8-1 ii libsndfile1 1.1.0-2 ii libstdc++612.2.0-5 ii libsuil-0-0 0.10.18-1 ii libtag1v5 1.12-1+b1 ii libusb-1.0-0 2:1.0.26-1 ii libvamp-hostsdk3v52.10.0-1 ii libvamp-sdk2v52.10.0-1 ii libwebsockets17 4.1.6-3 ii libx11-6 2:1.8.1-2 ii libxml2 2.9.14+dfsg-1+b1 Versions of packages ardour recommends: ii ardour-video-timeline 1:6.9.0+ds0-2 ardour suggests no packages. -- no debconf information
Bug#1016881: Please update chrome-gnome-shell to version 42
Package: chrome-gnome-shell Version: 10.1-5 Followup-For: Bug #1016881 Hi, Not sure it's actually a bug on chrome-gnome-shell, since what we need is a new package that will replace this one for gnome >=42. The bug here is it should depends on gnome-shell <42.0, I guess. RFP for gnome-browser-extension: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020616 Cheers, -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chrome-gnome-shell depends on: ii gnome-shell 42.4-2 ii python3 3.10.6-1 ii python3-gi3.42.2-2 ii python3-requests 2.27.1+dfsg-1 chrome-gnome-shell recommends no packages. Versions of packages chrome-gnome-shell suggests: ii chromium 105.0.5195.125-1 ii firefox 104.0.2-1 -- no debconf information -- nodens
Bug#1020616: RFP: gnome-browser-connector -- GNOME Shell extensions integration for web browsers
Package: wnpp Severity: wishlist * Package name: gnome-browser-connector Version : 42.1 Upstream Author : Yuri Konotopov * URL : https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome * License : GPLv3 Programming Lang: Python Description : GNOME Shell extensions integration for web browsers Provides integration with GNOME Shell extensions repository (v8 API) for Chromium (and derivatives) and Firefox . This package provides the connector that talks with the browser extension, supporting v8 API version and replacing the former chrome-gnome-shell connector
Bug#1019888: pipewire 0.3.57-1: no/crackling sound if pavucontrol is open, 0.3.56-1 is fine
Package: pipewire
Version: 0.3.57-1
Tags: fixed-upstream
Dear pipewire maintainers,
I'm a happy user of pipewire since a few month, however since the
upgrade to 0.3.57, no node can output sound if pavucontrol is open.
When pavucontrol is open, pipewire log show the following error message
(3-4/second):
```
spa.alsa: hw:sofhdadsp: snd_pcm_avail after recover: Broken pipe
```
Starting pavucontrol after the node starts playing works a little
better: there is sound, but it's choppy.
Closing pavucontrol makes the sound working again.
Downgrading pipewire to the 0.3.56-1 version fixes it as well.
I believe this is an upstream regression:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2671 (fixed in
0.3.58 it seems, but I didn't test it).
Disclaimer: I have a fairly fine-tuned configuration for low audio
latency, for pro audio apps (recording, routing, etc). It might make
things worse in this case. So while I considered tagging this `Important`
I refrained from doing so, I might be in a corner case.
The Gnome sound parameter menu works fine (but you can't enable/disable
device profiles with it, hence my usage of pavucontrol even when I'm not
using recording apps).
Please, can we get 0.3.58 sooner rather than later?
I see there are a lot of changes in the work, and I understand you want
to get them right,
as well as discuss them maybe, especially with the conversation going on
currently about pipewire.
That said, can I suggest decorellate system changes and upgrading to
latest upstream release first so this is fixed?
Thanks :)
PS: if anyone reading this needs to downgrade on **sid**, the easy way is
- adding the right snapshot in apt list from snapshots.d.o:
https://snapshot.debian.org/archive/debian/20220720T032429Z/
contrib non-free`
- and downgrade like this:
`export pwver=0.3.56-1; apt install
{pipewire{,-alsa,-bin,-jack,-pulse},libspa-0.2-{modules,bluetooth,jack},libpipewire-0.3{-0,-modules},gstreamer1.0-pipewire}=$pwver`
do *not* do this on testing, at least not blindly, you'd need to get the
right snapshot first ;)
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pipewire depends on:
ii init-system-helpers 1.64
ii libpipewire-0.3-modules 0.3.57-1
ii pipewire-bin 0.3.57-1
pipewire recommends no packages.
pipewire suggests no packages.
-- no debconf information
--
nodens
Bug#1018428: onionshare: build-depends on python3-nose or uses it for autopkgtest
Hi, Le 28/08/2022 à 20:42, Dmitry Shachnev a écrit : Source: onionshare Version: 2.2-3 User: python-modules-t...@lists.alioth.debian.org Usertags: nose-rm Dear Maintainer, Your package still uses nose [1], which is an obsolete testing framework for Python, dead and unmaintained since 2015 [2][3]. If you received this bug report, it means that your package either has a build-dependency on python3-nose or uses that package in debian/tests/control. If that is not the case, please reply and CC me explicitly. thanks for the report! The dependency is actually leftover cruft, the tests use pytest now, but the build-dep wasn't removed. It should be fixed in the next upload (which won't come immediately because new upstream release has lots of changes, work in progress). Cheers, -- nodens
Bug#472477: #472477 ssh-add -D does not remove SSH key from gnome-keyring-daemon memory (workaround)
Hi, So, my workaround for this annoying issue was to use gpg-agent instead. As a nice side effect, you can then use a gpg key to authenticate. The tricky part for me was to make sure gnome woudn't try to set SSH_AUTH_SOCK to gnome keyring anyway. In case others want to go this route, here is what I've done: - make sure your gpg-agent can handle ssh agent role by including `enable-ssh-support` in ~/.gnupg/gpg-agent.conf (you can also set ttls there while you're at it if you want, e,g, `default-cache-ttl-ssh 1200`, `max_cache_ttl-ssh 7200`) - disable ssh component of gnome-keyring in systemd user units: ``` systemctl --user mask gcr-ssh-agent.socket --now systemctl --user mask gcr-ssh-agent.service --now ``` - disable ssh component of gnome-keyring also in XDG autostart by adding the Hidden property: ``` cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/ echo "Hidden=true" >> ~/.config/autostart/gnome-keyring-ssh.desktop ``` Then restart the session. Be aware that when you use ssh-add for the first time when having the gpg-agent socket in SSH_AUTH_SOCK, you'll be first prompted by ssh-add, then by gpg-agent. Set a passphrase in gpg-agent when prompted, otherwise it will be stored in clear in your private keys. Usual gpg-agent stuff applies, it will lock whenever you lock the session, you get a timeout, etc. Cheers, -- nodens
Bug#1016363: libx11-6 1.8.1 also breaks glxinfo
With libx11-6 1.8.1 I get: |glxinfo name of display: :0 glxinfo: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: Assertion `e != ESRCH || !robust' failed. Abgebrochen| rebuilding libx11 with the --disable-thread-safety-constructor flag solved the issue. |System: Host: box Kernel: 5.18.0-rt11 arch: x86_64 bits: 64 compiler: gcc v: 12.1.0 Desktop: Cinnamon v: 5.2.7 Distro: siduction 18.3.0 Patience - cinnamon - (201805132102) base: Debian GNU/Linux bookworm/sid Machine: Type: Desktop System: Dell product: Inspiron 3668 v: N/A serial: Mobo: Dell model: 07KY25 v: A00 serial: UEFI: Dell v: 1.4.0 date: 07/19/2017 CPU: Info: quad core model: Intel Core i5-7400 bits: 64 type: MCP arch: Kaby Lake rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB Speed (MHz): avg: 3300 min/max: 800/3001 boost: enabled cores: 1: 3300 2: 3300 3: 3300 4: 3300 bogomips: 24000 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx Graphics: Device-1: Intel HD Graphics 630 vendor: Dell driver: i915 v: kernel arch: Gen-9.5 bus-ID: 00:02.0 Device-2: NVIDIA GP108 [GeForce GT 1030] vendor: Dell driver: nvidia v: 470.129.06 arch: Pascal bus-ID: 01:00.0 Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.3 driver: X: loaded: modesetting,nvidia unloaded: fbdev,nouveau,vesa gpu: i915,nvidia resolution: 1920x1080~60Hz|
Bug#990189: alsa-ucm-conf: New upstream version 1.2.7.1
Package: alsa-ucm-conf Version: 1.2.6.3-1 Followup-For: Bug #990189 Dear Maintainer, upstream is now at 1.2.7.1, and there are many interesting changes for multichannel cards. Thanks! -- nodens -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages alsa-ucm-conf depends on: ii libasound2 1.2.6.2-0.1 alsa-ucm-conf recommends no packages. alsa-ucm-conf suggests no packages. -- no debconf information
Bug#1013750: alsa-lib: new upstream release 1.2.7.1
Source: alsa-lib Version: 1.2.4-1.1 Severity: wishlist Dear Maintainer, the 1.2.7.1 upstream release is available. It's especially interesting to me because of changes in the UCM interface that allows to handle multichannel interfaces better (macros for making splitting/joining channels easier in UCM, e.g for pro-audio interfaces, and the new configs upstream need 1.2.7 alsa-lib). (I'll file a separate bug for the same request on alsa-ucm-conf). Thanks! nodens -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1003147: guitarix: New upstream release 0.44.1
Hi A new release is out, 0.44.1 While the current source in debian fails to build against recent glib, it may be time to update to the latest release. That will as well resolve all implemented patches from debian. regards hermann
Bug#1007933: cryptsetup-nuke-password: [INTL:de] initial German debconf translation
Package: cryptsetup-nuke-password Severity: wishlist Tags: patch l10n Please find the initial German debconf translation for cryptsetup-nuke-password attached. Please place this file in debian/po/ as de.po for your next upload. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Yours Hermann-Josef # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the cryptsetup-nuke-password package. # # Hermann J. Beckers , 2022. msgid "" msgstr "" "Project-Id-Version: cryptsetup-nuke-password\n" "Report-Msgid-Bugs-To: cryptsetup-nuke-passw...@packages.debian.org\n" "POT-Creation-Date: 2019-07-05 15:24+0200\n" "PO-Revision-Date: 2022-03-18 18:27+0100\n" "Last-Translator: Hermann J. Beckers \n" "Language-Team: German \n" "Language: de_DE\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" "X-Generator: Lokalize 20.04.2\n" #. Type: password #. Description #: ../cryptsetup-nuke-password.templates:1001 msgid "Nuke password:" msgstr "Zerstör-Passwort:" #. Type: password #. Description #: ../cryptsetup-nuke-password.templates:1001 msgid "" "If you setup a “nuke password”, you will be able to type this password at " "the early-boot prompt asking your passphrase to unlock your luks-encrypted " "partitions. Instead of decrypting the partitions, typing this password will " "instead wipe the encryption keys from the luks container so that it is no " "longer possible to unlock the encrypted partitions." msgstr "" "Wenn Sie ein »Zerstör-Passwort« einrichten, können Sie dieses Passwort" " eingeben, wenn Sie an der Eingabeaufforderung der frühen Systemstartphase" " nach Ihrem Passwort zum" " Entsperren Ihrer LUKS-verschlüsselten Partitionen gefragt werden. Anstatt die" " Partitionen zu entschlüsseln, löscht die Eingabe dieses Passwortes die" " Verschlüsselungs-Schlüssel aus dem LUKS-Container, so dass es nicht mehr" " möglich ist, die verschlüsselten Partitionen zu entsperren." #. Type: password #. Description #: ../cryptsetup-nuke-password.templates:1001 msgid "" "This provides a relatively stealth way to make your data unreadable in case " "you fear that your computer is going to be seized." msgstr "" "Dies bietet eine relativ verdeckte Methode, um Ihre Daten unlesbar zu machen," " falls Sie befürchten, das Ihr Computer beschlagnahmt wird. " #. Type: password #. Description #: ../cryptsetup-nuke-password.templates:1001 msgid "" "If you want to cancel this operation or disable any nuke password already " "configured, simply enter an empty password. If needed, you will be given the " "option to pick between both choices." msgstr "" "Wenn Sie die Operation abbrechen oder ein bereits konfiguriertes" " Zerstör-Passwort deaktivieren möchten, geben Sie ein leeres Password ein." " Wenn" " nötig, bekommen Sie die Gelegenheit, eine Auswahl zu treffen." #. Type: password #. Description #: ../cryptsetup-nuke-password.templates:2001 msgid "Re-enter password to verify:" msgstr "Zur Verifizierung Passwort bitte erneut eingeben:" #. Type: password #. Description #: ../cryptsetup-nuke-password.templates:2001 msgid "" "Please enter the same nuke password again to verify that you have typed it " "correctly." msgstr "" "Bitte geben Sie das gleiche Zerstör-Passwort erneut ein, um sicherzustellen," " das Sie es korrekt eingegeben haben." #. Type: error #. Description #: ../cryptsetup-nuke-password.templates:3001 msgid "Password input error" msgstr "Passwort-Eingabefehler" #. Type: error #. Description #: ../cryptsetup-nuke-password.templates:3001 msgid "The two passwords you entered were not the same. Please try again." msgstr "" "Die beiden von Ihnen eingegebenen Passwörter sind nicht gleich. Bitte" " versuchen Sie es erneut." #. Type: select #. Choices #: ../cryptsetup-nuke-password.templates:4001 msgid "Keep the current password" msgstr "Aktuelles Passwort behalten" #. Type: select #. Choices #: ../cryptsetup-nuke-password.templates:4001 msgid "Overwrite the current password" msgstr "Aktuelles Passwort überschreiben" #. Type: select #. Choices #: ../cryptsetup-nuke-password.templates:4001 msgid "Remove t
Bug#1000998: apt broken by libsystemd0 update
Package: apt Version: apt 2.3.13 apt apt 2.3.13 (armhf). After update of libsystemd0 to current (libsystemd0_247.3-6_armhf or libsystemd0_249.7-1_armhf) apt stops working with the error "|apt: /lib/arm-linux-gnueabihf/libsystemd.so.0: version `LIBSYSTEMD_221' not found (required by /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.6.0)"| || |Manually installing libsystemd0_241-7~deb10u8_armhf.deb solves the problem for apt, however i get "unmet dependencies" and "||apt --fix-broken install|||" upgrades libsystemd0 again, which leads to apt not working.
Bug#997223: guitarix: FTBFS: gatomic.h:202:45: error: invalid conversion from ‘volatile void*’ to ‘void*’ [-fpermissive]
Hi There is already a patch attached for this bug here #989206 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989206 Maybe someone could add it to the package before guitarix gets removed. regards hermann
Bug#994234: installation-reports: Would be nice if debbootstrap could recognize a link is already ok instead of failing
Package: installation-reports Severity: wishlist Tags: d-i Boot method: network Image version: https://deb.debian.org/debian/dists/bullseye/main/installer-amd64/current/images/netboot/netboot.tar.gz 20210731 Date: Machine: Fujitsu Esprimo Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[E] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Didn't want to wipe my root partition, so simply moved away all system directories on the root file system. debbootstrap then stumbles across the links in /, as it tries to create them unconditionally. The wish is here, that debbootstrap recongises the links are there instead of failing. Deleting the links and running the debbootstrap installer step again worked well. As a remark, an EFI shim for grub is installed - is that a necessary step? Thanks for a great distribution! -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210731" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux seba 5.10.0-8-amd64 #1 SMP Debian 5.10.46-3 (2021-07-28) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers [8086:3ec2] (rev 07) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:124a] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 630 (Desktop) [8086:3e92] lspci -knn: DeviceName: Onboard - Video lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:124a] lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation Cannon Lake PCH Thermal Controller [8086:a379] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller [8086:a36d] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Cannon Lake PCH HECI Controller [8086:a360] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake PCH SATA AHCI Controller [8086:a352] (rev 10) lspci -knn: DeviceName: Onboard - SATA lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:1b.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root Port #21 [8086:a32c] (rev f0) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Q370 Chipset LPC/eSPI Controller [8086:a306] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS [8086:a348] (rev 10) lspci -knn: DeviceName: Onboard - Sound lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1247] lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Cannon Lake PCH SMBus Controller [8086:a323] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller [8086:a324] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (7) I219-LM [8086:15bb] (rev 10) lspci -knn: DeviceName: Onboard - Ethernet lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1248] lspci -knn: Kernel driver in use: e1000e lspci -knn:
Bug#988128: aptitude: Security update not considered if a newer version is available
Package: aptitude Version: 0.8.13-3 Severity: normal Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: hexlaad...@ispx2cproxy001.x2c.nl To: Debian Bug Tracking System Subject: aptitude: Security update not considered if a newer version is available Bcc: hexlaad...@ispx2cproxy001.x2c.nl Package: aptitude Version: 0.8.11-7 Severity: normal Dear Maintainer, I started aptitude in UI mode to see the available security updates. Unfortunately, some security updates where missing when a newer version of the package is available from another repository. For example the apt package: $apt-cache policy apt apt: Installed: 1.8.2.1 Candidate: 1.8.2.3 Version table: 1.8.2.3 500 500 http://ftp.nl.debian.org/debian buster-updates/main amd64 Packages 1.8.2.2 500 500 http://ftp.nl.debian.org/debian buster/main amd64 Packages 500 http://security.debian.org buster/updates/main amd64 Packages 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages *** 1.8.2.1 100 100 /var/lib/dpkg/status Aptitude did not show version 1.8.2.2 under the "Security Updates" heading, but only version 1.8.2.3 under de regular "Upgradable Packages" heading. I do not regularly install all the updates from buster-updates, only certain packages after impact review. Due to the miscategorisation of the security updates, they were not installed. Suggested fix: Always show all security updates under the "Security Updates" heading. If packages meet the above conditions, show them in both/multiple sections, each with the corresponding package version. -- Package-specific info: Terminal: xterm-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.11 Compiler: g++ 8.2.0 Compiled against: apt version 5.0.2 NCurses version 6.1 libsigc++ version: 2.10.1 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.1.20181013 cwidget version: 0.5.17 Apt version: 5.0.2 aptitude linkage: linux-vdso.so.1 (0x7ffca77bc000) libapt-pkg.so.5.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7f10bbd85000) libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x7f10bbd4b000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7f10bbd1d000) libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f10bbd14000) libcwidget.so.3 => /lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f10bbc0e000) libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f10bbaec000) libboost_iostreams.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f10bbacc000) libboost_system.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f10bbac5000) libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 (0x7f10bb899000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f10bb878000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f10bb6f4000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f10bb571000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f10bb555000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f10bb394000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f10bb37a000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f10bb15c000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f10bb149000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f10bb121000) liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f10bb10) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f10bb061000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f10bb03b000) libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x7f10baf9a000) /lib64/ld-linux-x86-64.so.2 (0x7f10bc39e000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f10baf95000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f10baf89000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f10baf8) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x7f10bae62000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f10bae3f000) -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends
Bug#986626: dnsmasq: Invalid date in changelog
Package: dnsmasq Version: 2.84-1.2 Severity: normal Hi, The Debian changelog for dnsmasq contains an invalid date which aptitude is tripping over and causes a messed up display. Because of the caused mess, the exact error message can't be copied. The faulty entry is: -- Simon Kelley Tues, 13 Apr 2004 18:37:55 + Note the "Tues" instead of "Tue". -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (400, 'experimental'), (200, 'testing'), (110, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages dnsmasq depends on: ii dnsmasq-base [dnsmasq-base] 2.84-1.2 ii init-system-helpers 1.60 ii lsb-base 11.1.0 ii netbase 6.3 ii runit-helper 2.10.3 dnsmasq recommends no packages. Versions of packages dnsmasq suggests: pn resolvconf -- Configuration Files: /etc/dnsmasq.conf changed [not included] -- no debconf information
Bug#984469: guitarix: debian/copyright is inaccurate
Hi guitarix upstream maintainer here. Please downgrade the severity of this bug. The files in question don't be part of the distributed package, so there is no serious reason to mark guitarix "unfit for release". Even if the [debian/copyright] file may be wrong for those files, that haven't any relation to the distributed package, as they are only part of the source, and be in no relation to the distributed binary. If it helps, I could mark the files in question as CC-BY-1.0 so that the copyright file is correct. However, this is by far not a serious bug, so please, handle it.
Bug#981817: [Pkg-privacy-maintainers] Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'
On 10/02/2021 00:18, Jonathan Marquardt wrote: > On Fri, Feb 05, 2021 at 12:08:49PM +0100, Clément Hermann wrote: >> in a clean Buster virtual machine, I tried to pip3 install psutil then >> install onioncircuits, and I didn't get this error (though I didn't try >> with a graphical environment running). There must be something else >> going on in your environment, maybe check the permissions on /usr/local >> and below, or try to go the virtualenv route, or if you can, install the >> python modules you need using Debian Packages (psutil has a recent >> version available through buster-backports for instance). > > I played around a bit and found the following things: > > Clean install with Debian 10 with Gnome: onioncircuits works. > > After I run "pip3 install psutil" as root: onioncircuits doesn't work. > > After I run "pip3 uninstall psutil" as root: It works again. > > However I found out that it always works (on all of my systems) if I launch > onionciruits with the command: > > $ python3 /usr/bin/onionciruit > > I have no idea why. "type python3" might tell you if you are maybe using an alternate python3 interpreter located in /usr/local when doing that. The shebang in onioncircuits explicitely uses /usr/bin/python3 which might be different that the one that is first in PATH. I would recommend making sure any other, non-system python3 is self-enclosed (maybe in /opt) if needed. python-virtualenv might be a solution you want to have a look at: system python used for packages, and separated, local python for local code. I'm going to close this bug, since it's not an issue on the package. Thanks for the additional info, even if it's not a bug in the package this might be useful to other! Cheers, -- nodens
Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'
On 04/02/2021 13:04, Jonathan Marquardt wrote: > On Thu, Feb 04, 2021 at 12:23:17PM +0100, Clément Hermann wrote: >> The error message reference stuff in /usr/local: this leads me to think >> some python libs where locally installed without using the package >> system. Can you check that please ? And maybe test in a vm for instance >> to check in a clean environment ? > > I checked and you're right. This doesn't happen in a clean environment. I > figured out what causes the issue. I have psutil installed using pip (pip3 > install psutil). > > Is there a way to fix this? What even causes this? I need psutil to be > installed for some other python programs. I'm not sure in this particular case, the permission error suggests there is something on your setup that prevents the user running onioncircuits to access this file. Usually when one mixes distribution packages and pip, one would use virtualenv or something similar to ensure what is run via pip modules is self-contained. The thing is, I'm not sure why this error is on this module specifically, or that the module is pstutil is significant or it could be anyone. in a clean Buster virtual machine, I tried to pip3 install psutil then install onioncircuits, and I didn't get this error (though I didn't try with a graphical environment running). There must be something else going on in your environment, maybe check the permissions on /usr/local and below, or try to go the virtualenv route, or if you can, install the python modules you need using Debian Packages (psutil has a recent version available through buster-backports for instance). Cheers, -- nodens
Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'
Control: severity -1 normal Control: tags -1 +moreinfo Hi, Thanks for reporting a bug in onioncircuit Debian package! On 04/02/2021 10:39, Jonathan Marquardt wrote: > Package: onioncircuits > Version: 0.5-4 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I have multiple systems running the Debian Tor package with an open control > port. I always used this in combination with onioncircuits without any > problems until I upgraded to Debian Buster. Since the upgrade (or even fresh > installation of Buster) I'm unable to start onioncircuits: > > > > $ onioncircuits > Traceback (most recent call last): > File "/usr/bin/onioncircuits", line 25, in > import pycountry > File "/usr/lib/python3/dist-packages/pycountry/__init__.py", line 9, in > > from pkg_resources import resource_filename > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3191, > in > @_call_aside > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3175, > in _call_aside > f(*args, **kwargs) > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3204, > in _initialize_master_working_set > working_set = WorkingSet._build_master() > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 574, > in _build_master > ws = cls() > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 567, > in __init__ > self.add_entry(entry) > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 623, > in add_entry > for dist in find_distributions(entry, True): > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2033, > in find_on_path > for dist in factory(fullpath): > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2095, > in distributions_from_metadata > if len(os.listdir(path)) == 0: > PermissionError: [Errno 13] Permission denied: > '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info' > > > > This even happens as root. > > Is this a known issue? I don't think so. I can't reproduce this issue either on a system that already had onioncircuits installed or a newly installed system, so I'm lowering the severity. The error message reference stuff in /usr/local: this leads me to think some python libs where locally installed without using the package system. Can you check that please ? And maybe test in a vm for instance to check in a clean environment ? Cheers, -- nodens
Bug#980478: installation-reports: [armv7l] bullseye installation on BananaPro
Package: installation-reports Severity: normal Tags: patch upstream Dear Maintainer, overall installation went after an unsucessfull try end of last year rather fine, so thanks a lot for work on arm bullseye netinstall! The SoC and my setup specialities are described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934294 Appended is a patch for the kernel discussed on sunxi IRC to fix the GBIT not working in end 2020 kernels for the BananaPro devicetree, adapted from Banana M2U. Maybe the cause of the LAN failure described in #974123, too. Thanks, greetings Hermann -- Package-specific info: Boot method: network Image version: https://d-i.debian.org/daily-images/armhf/daily/netboot/netboot.tar.gz Date: 7.1.2021 Machine: BananaPro Partitions: df -Tl Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs414564 0414564 0% /dev tmpfs tmpfs95156 564 94592 1% /run /dev/md0 ext4 1891216 1580360196736 89% / tmpfs tmpfs 475764 40475724 1% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock /dev/sda3 ext4 435312240 9496524 403633328 3% /home tmpfs tmpfs95152 0 95152 0% /run/user/0 tmpfs tmpfs95152 0 95152 0% /run/user/2017 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[ ] Overall install:[O] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210107-00:05:00" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux bapro 5.10.0-1-armmp #1 SMP Debian 5.10.4-1 (2020-12-31) armv7l GNU/Linux usb-list: usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 5.10.0-1-armmp ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 01: Generic Platform OHCI controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 5.10.0-1-armmp ohci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 03 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 5.10.0-1-armmp ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 5.10.0-1-armmp ohci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub lsmod: Module Size Used by lsmod: dm_mod114688 0 lsmod: raid1 49152 1 lsmod: md_mod147456 2 raid1 lsmod: jfs 180224 0 lsmod: btrfs1335296 0 lsmod: libcrc32c 16384 1 btrfs lsmod: xor16384 1 btrfs lsmod: raid6_pq 98304 1 btrfs lsmod: vfat 24576 0 lsmod: fat69632 1 vfat lsmod: ext4 724992 1 lsmod: crc16 16384 1 ext4 lsmod: mbcache16384 1 ext4 lsmod: jbd2 114688 1 ext4 lsmod: crc32c_generic 16384 3 lsmod: brcmfmac 274432 0 lsmod: brcmutil 16384 1 brcmfmac lsmod: cfg80211 667648 1 brcmfmac lsmod: rfkill 24576 1 cfg80211 lsmod: usb_storage57344 0 lsmod: sd_mod 57344 2 lsmod: t10_pi 16384 1 sd_mod lsmod: crc_t10dif 20480 1 t10_pi lsmod: crct10dif_common 16384 1 crc_t10dif lsmod: ahci_sunxi 16384 1 lsmod: libahci_platform 20480 1 ahci_sunxi lsmod: libahci
Bug#768073: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon
Hi, On 08/01/2021 05:07, peylight wrote: > Hi Dear Debian Developers, > Can you check the 331th message of LXD packaging please: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768073#311 > Thanks for your interest in LXD packaging - and sorry for the late reply. The issue with said package is that it doesn't follow Debian packaging guidelines. We can't vendor all the deps like it's done here. Some vendoring might be OK in very specific cases, but here we have to take the long road. The progress on packaging LXD deps is tracked in gobby.debian.org at Teams/Go/lxd-deps-packaging. An http export is here: https://gobby.debian.org/export/Teams/Go/lxd-dep-packaging. As you can see, there are still a lors of dependancies. I doubt we'll be able to make this enter Debian before the soft freeze, but if enough people want to help, that might still be possible. Intested parties, please don't hesitate to just tag some entries in the Gobby doc or ping me on IRC (nodens) to tell me what you're working on. Cheers, -- nodens
Bug#976579: libgsecuredelete: FTBFS in debian (patch)`
Hi, libgsecuredelete currently fails to build in Debian: see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976579. This is due to some automake strangeness: generated valac command line seems wrong, according to Rico Tzschichholz, aka ricotz, upstream Vala contributor. The attached patch (courtesy of ricotz) allows to build properly. I also managed to successfully build and use nautilus-wipe with the resulting lib. Also, the vapi path follows vala recommendation and is put in /usr/share/vala/vapi. It was also suggested the *_vala.stamp file should be deleted before build to ensure the code is properly generated. I implemented this in the debian package (to be uploaded soon). Please, consider including this patch. Cheers, -- Clément Hermann (nodens) (with my Tails contributor and Debian Privacy Packaging Team member hats both on) Description: Fix valac call generation in gsecuredelete/Makefile.am Should avoid "already contains a definition for" errors by using vala properly Author: Rico Tzschichholz Forwarded: yes Last-Update: 2021-01-11 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ diff --git a/gsecuredelete/Makefile.am b/gsecuredelete/Makefile.am index c5c62e3..b7dcc18 100644 --- a/gsecuredelete/Makefile.am +++ b/gsecuredelete/Makefile.am @@ -26,15 +26,16 @@ libgsecuredelete_la_SOURCES = gsd-async-operation.vala \ gsd-swap-operation.vala \ gsd-utils.vala \ gsd-zeroable-operation.vala -libgsecuredelete_la_include_HEADERS = gsecuredelete.h \ - gsecuredelete.vapi +libgsecuredelete_la_include_HEADERS = gsecuredelete.h + +vapidir = $(datadir)/vala/vapi +dist_vapi_DATA = gsecuredelete.vapi test_VALAFLAGS = $(AM_VALAFLAGS) --vapidir=. --pkg=gsecuredelete test_SOURCES = main.vala test_LDADD = libgsecuredelete.la gsecuredelete.vapi: libgsecuredelete_la_vala.stamp -test_vala.stamp: gsecuredelete.vapi $(libgsecuredelete_la_SOURCES:.vala=.c): gsd-config.h
Bug#971299: [Pkg-privacy-maintainers] Bug#971299: onionshare: Switch to python3-pycryptodome
Hi, On 10/01/2021 23:46, Sebastian Ramacher wrote: > On 2020-10-05 15:18:46 +0200, Clément Hermann wrote: >> >> Hi, >> >> Control: block 971299 with 886291 >> thanks >> >> On 28/09/2020 23:29, Sebastian Ramacher wrote: >>> Source: onionshare >>> Version: 2.2-2 >>> Severity: important >>> Tags: sid bullseye >>> Usertags: pycrypto >>> >>> Dear maintainer, >>> >>> onionshare currently Build-Depends or Depends on python3-crypto from >>> PyCrypto. This project is no longer maintained and PyCryptodome >>> (https://www.pycryptodome.org/en/latest/) provides a drop in >>> replacement. Please switch to python3-pycryptodome. I'd like to >>> remove python-crypto before the release of bullseye. >> >> >> As far as I understand it, pycryptodome *can* be a drop-in replacement >> usually, but not currently in Debian since it doesn't install in Crypto >> but Cryptodomex namespace (#886291). >> >> Are there any plan to change it when python3-crypto is removed or before ? >> >> Of course, we can patch onionshare to import cryptodomex, but that patch >> would be debian-only then… Upstream already expect pycryptodome as >> Crypto module. > > Sorry for the delay. I don't have any plans other than removing > python3-crypto. CCing the pycryptodome maintainer for more input. Thanks. Meanwhile, Ulrike added a patch to import cryptodome explicitly, and I just uploaded the version with it. It's a short-term fix IMO, until #886291 is clarified, but at least it removes the dep to pycrypto. Cheers, -- nodens
Bug#978411: src:golang-gopkg-lxc-go-lxc.v2: fails to migrate to testing for too long: maintainer built arch:all binary
Hi Paul, On 27/12/2020 07:12, Paul Gevers wrote: > Source: golang-gopkg-lxc-go-lxc.v2 > Version: 0.0+git20190625.f4822c6-1 > Severity: serious > Control: close -1 0.0+git20201012.d1943fb-1 > Tags: sid bullseye pending > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > As recently announced [1], the Release Team now considers packages that > are out-of-sync between testing and unstable for more than 60 days as > having a Release Critical bug in testing. Your package > src:golang-gopkg-lxc-go-lxc.v2 in its current version in unstable has > been trying to migrate for 62 days [2]. Hence, I am filing this bug. > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on > other packages, which makes preparing for the release more difficult. > Finally, it often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that > hamper the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if > that version or a later version migrates, this bug will no longer affect > testing. I have also tagged this bug to only affect sid and bullseye, so > it doesn't affect (old-)stable. > > Your package is only blocked because the arch:all binary package(s) > aren't built on a buildd. Unfortunately the Debian infrastructure > doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will > shortly do a no-changes source-only upload to DELAYED/15, closing this > bug. Please let me know if I should delay or cancel that upload. Thanks! I'll make an upload later today with some small fixes, so you can cancel it. Cheers, -- nodens
Bug#976905: src:cyrus-imapd: Please consider enabling JMAP support
Package: src:cyrus-imapd Severity: wishlist Hi, JMAP is a (relatively) new open standard for mailboxes access, more mobile friendly and faster than IMAP. Think open source gmail api or MAPI. It has been developed by people at Fastmail and is now an IETF standard. Cyrus imapd has jmap support, please consider enabling it! See https://www.cyrusimap.org/imap/developer/jmap.html. Note that it depends on Xapian (but that seems to be in Debian already). Thanks! -- nodens
Bug#972817: ITP: golang-github-canonical-go-dqlite -- Go bindings for libdqlite
Package: wnpp Severity: wishlist Owner: Clement Hermann X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-canonical-go-dqlite Version : 1.8.0-1 Upstream Author : Canonical * URL : https://github.com/canonical/go-dqlite * License : Apache-2.0 Programming Lang: Go Description : Go bindings for libdqlite Go-dqlite provides bindings for the dqlite (https://dqlite.io) C library. This package is a dependency of LXD (#768073) and will be maintained under the Go pkg team umbrella. Note: I don't intend to provide the example program (demo API and client program) as a binary package initially. However, feel free to chime in here or file a bug in the package once it's in Debian if you think it'd be useful!
Bug#768073: ITP: lxd - The Linux Container Daemon
Hi, On 27/09/2020 20:23, Kurt Kremitzki wrote: > Hello, > > With the release of LXD 4.6 [1], it should now be a lot easier for it to be > brought to Debian: > > "Dqlite changes > > Shortly after LXD 4.5 was released, a major change was made to upstream > dqlite. > > Rather than relying on our fork of sqlite3 which was adding some hooks used > to > intercept filesystem writes and replicating to other nodes, we are now using > a > different approach to get VFS access from a standard sqlite3. > > While invisible to users, this should help packagers a fair bit by removing > two custom dependencies of LXD, that custom sqlite3 and libco. > > LXD with dqlite can now use any standard sqlite3 of version 3.25 or higher." > > [1] https://discuss.linuxcontainers.org/t/lxd-4-6-has-been-released/8981 That was indeed on the radar after discussions with upstream at FOSDEM and we were in the loop. Thanks for keeping the subscribers of this bug informed! (and sorry I didn't do it myself). And now, dqlite is actually in Debian: https://tracker.debian.org/pkg/dqlite (thanks Laszlo!). I'm happy to say I can now resume working on LXD deps and lxd itself. We might have a chance to see LXD in the next release after all! \o/ Cheers, -- nodens
Bug#971299: onionshare: Switch to python3-pycryptodome
Hi, Control: block 971299 with 886291 thanks On 28/09/2020 23:29, Sebastian Ramacher wrote: > Source: onionshare > Version: 2.2-2 > Severity: important > Tags: sid bullseye > Usertags: pycrypto > > Dear maintainer, > > onionshare currently Build-Depends or Depends on python3-crypto from > PyCrypto. This project is no longer maintained and PyCryptodome > (https://www.pycryptodome.org/en/latest/) provides a drop in > replacement. Please switch to python3-pycryptodome. I'd like to > remove python-crypto before the release of bullseye. As far as I understand it, pycryptodome *can* be a drop-in replacement usually, but not currently in Debian since it doesn't install in Crypto but Cryptodomex namespace (#886291). Are there any plan to change it when python3-crypto is removed or before ? Of course, we can patch onionshare to import cryptodomex, but that patch would be debian-only then… Upstream already expect pycryptodome as Crypto module. Take care, -- nodens
Bug#774149: Hallo
[image: image.png]
Bug#962623: ImportError: cannot import name 'parse_qs' from 'cgi' (/usr/lib/python3.8/cgi.py)
This is a multi-part MIME message sent by reportbug.
--===0522418674==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Package: graphite-web
Followup-For: Bug #962623
Dear Maintainer,
please upgrade to 1.1.7 available upstream and replace
debian/patches/settings_debian.patch
with the appended version.
This makes 1.1.7 working in testing(bullseye).
Thanks a lot,
greetings
Hermann
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (40, 'unstable')
Architecture: armhf (armv7l)
Kernel: Linux 5.7.8 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages graphite-web depends on:
ii adduser 3.118
ii python3 3.8.2-3
ii python3-cairo 1.16.2-4
ii python3-cairocffi 0.9.0-4
ii python3-django 2:2.2.15-2
ii python3-django-tagging 1:0.4.5-3
ii python3-pyparsing 2.4.7-1
ii python3-simplejson 3.17.0-1
ii python3-six 1.15.0-1
ii python3-tz 2020.1-2
ii python3-urllib3 1.25.9-1
ii python3-whisper 1.1.4-2
graphite-web recommends no packages.
Versions of packages graphite-web suggests:
pn graphite-carbon
pn libapache2-mod-wsgi-py3
pn python3-ldap
pn python3-memcache
pn python3-mysqldb
-- Configuration Files:
/etc/graphite/local_settings.py changed [not included]
-- no debconf information
--===0522418674==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="settings_debian.patch"
# HG changeset patch
# Parent bc853f64d61b2a37516e59c5c8edff74c78feccd
diff --git a/webapp/graphite/settings.py b/webapp/graphite/settings.py
--- a/webapp/graphite/settings.py
+++ b/webapp/graphite/settings.py
@@ -20,6 +20,9 @@
from warnings import warn
from importlib import import_module
+# Debian add etc/graphite into path
+sys.path.append('/etc/graphite')
+
from django import VERSION as DJANGO_VERSION
try:
from django.urls import reverse_lazy
@@ -221,7 +224,7 @@
FLUSHRRDCACHED = ''
## Load our local_settings
-SETTINGS_MODULE = os.environ.get('GRAPHITE_SETTINGS_MODULE',
'graphite.local_settings')
+SETTINGS_MODULE = os.environ.get('GRAPHITE_SETTINGS_MODULE', 'local_settings')
try:
globals().update(import_module(SETTINGS_MODULE).__dict__)
except ImportError:
--===0522418674==--
Bug#967506: guitarix: depends on deprecated GTK 2
Latest guitarix release 0.41.0 use GTK 3, so it just needs to be updated on bbuild to solve this issue. regards hermann
Bug#964367: blender: Doesn't show any text in UI
Package: blender Version: 2.83.1+dfsg-2 Severity: important Dear Maintainer, I installed blender and upon first launch, the UI doesn't show any text. No text in menus, toolbars and dialogs, nowhere. This makes blender totally useless. Upon launch, blender prints this to the console: Can't find font: /home/alex/.config/blender/2.83/datafiles/fonts/droidsans.ttf Can't find font: /home/alex/.config/blender/2.83/datafiles/fonts/bmonofont-i18n.ttf Can't find font: /home/alex/.config/blender/2.83/datafiles/fonts/bmonofont-i18n.ttf /run/user/1000/gvfs/ non-existent directory -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (400, 'experimental'), (200, 'testing'), (110, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages blender depends on: ii blender-data 2.83.1+dfsg-2 ii fonts-dejavu 2.37-2 ii libavcodec58 7:4.3-3 ii libavdevice58 7:4.3-3 ii libavformat58 7:4.3-3 ii libavutil56 7:4.3-3 ii libboost-locale1.71.0 1.71.0-6+b2 ii libc6 2.30-8 ii libfftw3-double3 3.3.8-2 ii libfreetype6 2.10.2+dfsg-2 ii libgcc-s1 10.1.0-4 ii libgl11.3.1-1 ii libglew2.12.1.0-4+b1 ii libgomp1 10.1.0-4 ii libilmbase24 2.3.0-6 ii libjack0 [libjack-0.125] 1:0.125.0-3+b1 ii libjemalloc2 5.2.1-1 ii libjpeg62-turbo 1:2.0.5-1 ii libopenal11:1.19.1-1+b1 ii libopencolorio1v5 1.1.1~dfsg0-6+b1 ii libopenexr24 2.3.0-6 ii libopenimageio2.1 2.1.17.0~dfsg0-1 ii libopenjp2-7 2.3.1-1 ii libopenvdb7.0 7.0.0-3+b1 ii libosdcpu3.4.33.4.3-3 ii libosdgpu3.4.33.4.3-3 ii libpcre3 2:8.39-13 ii libpng16-16 1.6.37-2 ii libpython3.8 3.8.4~rc1-1 ii libsdl2-2.0-0 2.0.12+dfsg1-1 ii libsndfile1 1.0.28-8 ii libspnav0 0.2.3-1+b2 ii libstdc++610.1.0-4 ii libswscale5 7:4.3-3 ii libtbb2 2020.2-2 ii libtiff5 4.1.0+git191117-2 ii libx11-6 2:1.6.9-2+b1 ii libxfixes31:5.0.3-2 ii libxi62:1.7.10-1 ii libxml2 2.9.10+dfsg-5+b1 ii libxrender1 1:0.9.10-1 ii libxxf86vm1 1:1.1.4-1+b2 ii zlib1g1:1.2.11.dfsg-2 blender recommends no packages. blender suggests no packages. -- no debconf information
Bug#963520: guitarix: depend on prename
Hi Hermann here, I'm the upstream maintainer. Thanks for you interest in our work. Let's have a look at the part were you complain about. set +e RN=$(rename -V 2>/dev/null| grep File::Rename) if [ ! -z "$RN" ] ; then use_to_rename='rename' fi if [ -z "$RN" ] ; then RN=$(prename -V 2>/dev/null| grep File::Rename) use_to_rename='prename' fi if [ -z "$RN" ] ; then RN=$(perl-rename -V 2>/dev/null| grep File::Rename) use_to_rename='perl-rename' fi if [ -z "$RN" ] ; then RNUL=$(rename -V 2>/dev/null| grep util-linux) if [ -z "$RNUL" ] ; then RNUL=$(rename.ul -V 2>/dev/null| grep util-linux) use_to_rename='rename.ul' else use_to_rename='rename' fi fi set -e So, what does that mean? We look for which rename tool is available and use the one we find first. That may differ from distribution to distribution. But looking for it, couldn't be a bug, or could it? Anyway, this is a developer tool which will never be part of any debian package. It's part of the source for documentation of what we do, and how we do it. Please consider to mark this report as done. regards hermann
Bug#962953: ITP: wahay -- Easy-to-use, secure and decentralized conference call
Package: wnpp Severity: wishlist Owner: Clement Hermann * Package name: wahay Version : 0.0~git20200606.4f8e43a-1 Upstream Author : Centro de Autonomía Digital (https://autonomia.digital) * URL : https://wahay.org * License : GPLv3 Programming Lang: Go Description : Easy-to-use, secure and decentralized conference call Wahay is voice call application that allows you to easily host and participate in conference calls, without the need for any centralized servers or services. It is meant to be as easy-to-use as possible, while still providing extremely high security and privacy out of the box. . In order to do this, it uses Tor (https://torproject.org) Onion Services in order to communicate between the end-points, and the Mumble (https://www.mumble.info) protocol for the actual voice communication.
Bug#905068: ITP: libdqlite - High-availability SQLite with Raft consensus (Was: Re: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications)
retitle -1 ITP: libdqlite - High-availability SQLite with Raft consensus thanks On Tue, 31 Jul 2018 11:24:36 +0800 (CST) "Clement Hermann" wrote: > Package: wnpp > Severity: wishlist > Owner: Clement Hermann > > * Package name: golang-github-canonicalltd-dqlite > Version : 0.0~git20180507.e5bc052-1 > Upstream Author : Canonical Ltd > * URL : https://github.com/CanonicalLtd/dqlite > * License : Apache-2.0 > Programming Lang: Go > Description : Distributed SQLite for Go applications > > dqlite can be used to replicate a SQLite database across a cluster, > using the Raft algorithm. > - No external processes needed: dqlite is just a Go library, you link >it to your application exactly like you would with SQLite. > - Full support for transactions > - No need for statements to be deterministic (e.g. you can use time()) > > This is a dependency of LXD 3 (ITP: #768973) and will be maintained under the > Go team umbrella. New description * Package name: libdqlite Version : 1.4.0 Upstream Author : Canonical Ltd * URL : https://github.com/CanonicalLtd/dqlite * License : LGPLv3 with linking exception Programming Lang: C Description : High-availability SQLite with Raft consensus dqlite is a C library that implements an embeddable and replicated SQL database engine with high-availability and automatic failover. "dqlite" stands for "distributed SQLite", meaning that dqlite extends SQLite with a network protocol that can connect together various instances of your application and have them act as a highly-available cluster, with no dependency on external databases. Design higlights: - Asynchronous single-threaded implementation using libuv as event loop. - Custom wire protocol optimized for SQLite primitives and data types. - Data replication based on the Raft algorithm and its efficient C-raft implementation.
Bug#955763: python3-coverage: Error when calling python3.8-coverage
Package: python3-coverage
Version: 4.5.2+dfsg.1-4+b1
Severity: normal
Hi,
there seems to be an issue with python3.8-coverage:
$ python3-coverage
Code coverage for Python. Use 'python3-coverage help' for help.
$ python3.7-coverage
Code coverage for Python. Use 'python3.7-coverage help' for help.
$ python3.8-coverage
Traceback (most recent call last):
File "/usr/bin/python3.8-coverage", line 11, in
load_entry_point('coverage==4.5.2', 'console_scripts',
'python3.8-coverage')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2851,
in load_entry_point
raise ImportError("Entry point %r not found" % ((group, name),))
ImportError: Entry point ('console_scripts', 'python3.8-coverage') not found
Adding the following line to
/usr/lib/python3/dist-packages/coverage-4.5.2.egg-info/entry_points.txt
seems to fix it:
python3.8-coverage = coverage.cmdline:main
Cheers, Uwe.
--
http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org
Bug#953253: duply: update manpage link to duply.net
Package: duply Version: 2.2-2 Severity: minor Tags: patch Dear Maintainer, appended patch updates the manpage to point to the current duply.net hompage. Thanks, greetings Hermann -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/6 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages duply depends on: pn duplicity Versions of packages duply recommends: ii gnupg 2.2.12-1+deb10u1 Versions of packages duply suggests: ii openssh-client 1:7.9p1-10+deb10u2 -- no debconf information # HG changeset patch # Parent 0b48ecb865ade9b58580d41d6909c4a331f51cd6 diff --git a/debian/man/duply.pod b/debian/man/duply.pod --- a/debian/man/duply.pod +++ b/debian/man/duply.pod @@ -340,7 +340,7 @@ =head1 AVAILABILITY -For newer versions see http://sourceforge.net/projects/ftplicity/. +For newer versions see http://duply.net/. =head1 COPYRIGHT and LICENSE
Bug#953251: duply should depend on python3-duplicity or duplicity
Package: duply Version: 2.2-2 Severity: normal Dear Maintainer, please depend on python3-duplicity or duplicity to allow usage of the maintained python3 version of duplicity. Thanks greetings Hermann -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/6 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages duply depends on: pn duplicity Versions of packages duply recommends: ii gnupg 2.2.12-1+deb10u1 Versions of packages duply suggests: ii openssh-client 1:7.9p1-10+deb10u2 -- no debconf information
Bug#951546: timewarrior: Bash completion doesn't work for timew
Package: timewarrior
Version: 1.2.0-1
Severity: normal
Tags: patch
Hi,
bash completion doesn't work, because the completion script is installed
in /usr/share/bash-completion/ instead of
/usr/share/bash-completion/completions/.
It would probably be better to use dh_bash-completion.
Please find a patch attached :)
(note that it will trigger a lintian warning, I'm disscussing this in
https://salsa.debian.org/lintian/lintian/merge_requests/292).
Cheers,
nodens
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8),
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages timewarrior 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
Versions of packages timewarrior recommends:
ii taskwarrior 2.5.1+dfsg-8
Versions of packages timewarrior suggests:
ii python 2.7.17-2
-- no debconf information
>From 3a78ef9487e71705e4641789a9d04a90e28a1711 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Hermann?=
Date: Fri, 14 Feb 2020 17:24:27 +0100
Subject: [PATCH] Fix bash-completion installation path
- removes dh-auto-install override
- adds --with-bash-completion to dh call
--adds d/timewarrior.bash-completion control file
- adds bash-completion to build-depends
---
debian/control | 2 +-
debian/rules | 7 +--
debian/timewarrior.bash-completion | 1 +
3 files changed, 3 insertions(+), 7 deletions(-)
create mode 100644 debian/timewarrior.bash-completion
diff --git a/debian/control b/debian/control
index 5984306..f30e6ba 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: utils
Priority: optional
Maintainer: Debian Tasktools Packaging Team
Uploaders: Gordon Ball
-Build-Depends: debhelper-compat (= 12), cmake, git, python
+Build-Depends: debhelper-compat (= 12), cmake, git, python, bash-completion
Standards-Version: 4.4.1
Homepage: https://timewarrior.net/
Vcs-Browser: https://salsa.debian.org/tasktools-team/timew
diff --git a/debian/rules b/debian/rules
index 02f9548..611059d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,17 +6,12 @@ TAG_VERSION := $(shell echo $(DEB_VERSION_UPSTREAM) | tr '~'
'.' | sed -e 's/+[d
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
%:
- dh $@
+ dh $@ --with bash-completion
override_dh_auto_configure:
find . -type f -exec sed -i '1s|^#!/usr/bin/env
python|#!/usr/bin/python|' {} \;
dh_auto_configure
-override_dh_auto_install:
- dh_auto_install
- mkdir -p debian/timewarrior/usr/share/bash-completion
- cp completion/timew-completion.bash
debian/timewarrior/usr/share/bash-completion/timew
-
override_dh_installchangelogs:
dh_installchangelogs -k ChangeLog
diff --git a/debian/timewarrior.bash-completion
b/debian/timewarrior.bash-completion
new file mode 100644
index 000..5f2d031
--- /dev/null
+++ b/debian/timewarrior.bash-completion
@@ -0,0 +1 @@
+completion/timew-completion.bash timew
--
2.25.0
Bug#951484: bash-completion: please provide dh-sequence-bash-completion virtual package
Package: bash-completion Version: 1:2.10-1 Severity: wishlist Hi, bash-completion dh sequence addon could benefit from providing the virtual package dh-sequence-bash-completion. It would allow to just add dh-sequence-bash-completion to the build-depends of a package instead of adding bash-completion as a build-dep and --with-bash-completion to dh call in d/rules. Cheers, nodens -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#951214: flatpak: text display issue in file dialogs when using "Roboto" font
Package: flatpak Version: 1.6.1-1 Severity: normal Hi, I use Roboto Regular font for most of my interface (gnome). When opening a file dialog in flatpak apps, All text in the dialog appear as squares. It works if I switch to Cantarell Regular (or, apparently, RobotoRegular Regular). Steps to reproduce: - Install Roboto fonts - (fonts-roboto-unhinted and fonts-roboto-hinted, in my case). - use gnome-tweaks to change interface text font to Roboto Regular - open gedit has a flatpak (org.gnome.gedit) - try to open a file While leaving the file dialog open, one can change font to cantarell or robotoregular (any variant), and it works fine. It might be a bug in the Roboto package. Cheers, nodens -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flatpak depends on: ii adduser3.118 ii bubblewrap 0.4.0-1 ii libappstream-glib8 0.7.16-1 ii libarchive13 3.4.0-1+b1 ii libc6 2.29-10 ii libdconf1 0.34.0-2 ii libfuse2 2.9.9-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-2 ii libglib2.0-0 2.62.4-2 ii libgpgme11 1.13.1-6 ii libjson-glib-1.0-0 1.4.4-2 ii libostree-1-1 2019.6-1 ii libpolkit-agent-1-00.105-26 ii libpolkit-gobject-1-0 0.105-26 ii libseccomp22.4.2-2 ii libsoup2.4-1 2.68.2-1 ii libsystemd0244.2-1 ii libxau61:1.0.8-1+b2 ii libxml22.9.4+dfsg1-8 ii xdg-dbus-proxy 0.1.2-1 Versions of packages flatpak recommends: ii desktop-file-utils 0.24-1 ii gtk-update-icon-cache3.24.13-1 ii hicolor-icon-theme 0.17-2 ii libpam-systemd 244.2-1 ii p11-kit 0.23.20-1 ii policykit-1 0.105-26 ii shared-mime-info 1.10-1 ii xdg-desktop-portal 1.6.0-1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend] 1.6.0-1 Versions of packages flatpak suggests: ii avahi-daemon 0.7-5 -- no debconf information
Bug#950282: libmagick++-6.q16hdri-dev: pkgconfig for HDRI case incorrect
Package: libmagick++-6.q16hdri-dev Version: 8:6.9.10.23+dfsg-2.1 Severity: normal Dear Maintainer, as you know, the DEB installs a "default" variant, as well as a variant for "quantum depth 16" and yet another variant for "quantum depth 16 + HDRI" While packaging some software, I need to depend on libmagick++-6.q16hdri-dev However, this package installs a pkg-config file, which does not work out of the box, and which sets the flags wrong, so to *disable* the HDRI feature. (1) install only libmagick++-6.q16hdri-dev this pulls the additional dependencies: libmagick++-6-headers libmagick++-6.q16hdri-8 (2) pkg-config Magick++-6.Q16HDRI --cflags > Package MagickWand was not found in the pkg-config search path. > Package 'MagickWand', required by 'Magick++-6.Q16HDRI', not found (3) now try to fix that by installing libmagick++-dev this again pulls additional dependencies: libmagick++-6.q16-dev libmagickcore-6.q16-dev libmagickwand-6.q16-dev (4) pkg-config Magick++-6.Q16HDRI --cflags > -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 \ > -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 \ > -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 \ > -I/usr/include/x86_64-linux-gnu//ImageMagick-6 ... Please note: the HDRI toggle is first enabled, but then disabled again. The reason is obviously in the two files: /usr/lib/x86_64-linux-gnu/pkgconfig/ImageMagick++-im6.Q16HDRI.pc /usr/lib/x86_64-linux-gnu/pkgconfig/MagickWand-6.Q16HDRI.pc The first one defines a... > Requires: MagickWand and the second one defines a... > Requires: MagickCore ...while in fact both should use the Q16HDRI variants Moreover, would ImageMagick++-im6.Q16HDRI.pc properly depend on MagickWand-6.Q16HDRI.pc, and this again properly depend on MagicCore-6.QHDRI, then also the problem of the missing package dependency would be solved, and the HDRI_ENABLE would be =1 correctly -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org compare: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org convert: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org composite: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org conjure: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org display: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org identify: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org import: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org mogrify: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org montage: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org stream: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (900, 'stable'), (650, 'stable'), (500, 'stable-updates'), (95, 'testing'), (80, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmagick++-6.q16hdri-dev depends on: ii dpkg 1.19.7 ii libmagick++-6-headers8:6.9.10.23+dfsg-2.1 ii libmagick++-6.q16hdri-8 8:6.9.10.23+dfsg-2.1 ii libmagickcore-6.q16hdri-dev 8:6.9.10.23+dfsg-2.1 ii libmagickwand-6.q16hdri-dev 8:6.9.10.23+dfsg-2.1 ii pkg-config 0.29-6 libmagick++-6.q16hdri-dev recommends no packages. libmagick++-6.q16hdri-dev suggests no packages. -- no debconf information
Bug#949575: RFP: bandwhich -- Terminal bandwidth utilization tool
Package: wnpp Severity: wishlist * Package name: bandwhich Version : 0.10.0 Upstream Author : Aram Drevekenin * URL : https://github.com/imsnif/bandwhich * License : MIT Programming Lang: Rust Description : Terminal bandwidth utilization tool Bandwhich is a CLI utility for displaying current network utilization by process, connection and remote IP/hostname, written in Rust. . It works by sniffing a given network interface and records IP packet size, cross referencing it with the /proc filesystem (or lsof). It is responsive to the terminal window size, displaying less info if there is no room for it. It will also attempt to resolve ips to their host name in the background using reverse DNS on a best effort basis. Dear Rust team, Please consider adding this to the rust packages library in Debian :) Cheers, nodens
Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2
On Sat, 18 Jan 2020 23:55:10 +0100 Marco d'Itri wrote: > On Jan 07, Guillaume Brocker wrote: > > > janv. 06 11:10:46 sigismund sshd[27148]: /usr/sbin/sshd: > > /lib/i386-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required > > by /usr/sbin/sshd) > Does purging libxcrypt1 make it work? > > If you can confirm this then I will make the next libcrypt1 conflict > with it. I did not expect for libxcrypt1 to be still around since it was > not shipped in buster and nobody really ever used it. I have the same issue. The symbol is in the file provided by libcrypt1, however, it is in /usr/lib. what I have in /lib is: ``` ls -l /lib/x86_64-linux-gnu/libcrypt.so.1 lrwxrwxrwx 1 root root 16 déc. 27 20:31 /lib/x86_64-linux-gnu/libcrypt.so.1 -> libcrypt-2.25.so ls -l /lib/x86_64-linux-gnu/libcrypt-2.25.so -rw-r--r-- 1 root root 39272 déc. 2 2017 libcrypt-2.25.so ``` The version (2.25) looks like it's a leftover from an older libc6 package ? no package provides libcrypt-2.25.so as a file. libcrypt has been disabled in libc6 2.29-4. It looks like a leftover or something. Removing the file and running ldconfig fixes the issue for me (but now I wonder if I have other leftover files like this…). Anyway, I think the bug, if it's not a local problem, isn't in openssh-server, but more in libc6, and an old version... Cheers, -- nodens
Bug#949347: openimageio: pybind11-dev dependency: prevent Git download
Source: openimageio Severity: normal Dear Maintainer, while backporting openimageio_2.0.12~dfsg0-1 (to Ubuntu 18.04 LTS), I stumbled over the following insidious problem with the underlying upstream-build and the DEB package. The CMake buildsystem contains a macro to check for a proper pybind11 version. However, by default, this macro (src/cmake/externalpackages.cmake, line 542) attempts to be "smart", and automatically downloads a newer version of pybind11 via Git if "necessary", instead of failing with a clear error message. We certainly do not want a Debian build silently to download sources from "somewhere" My proposed fix: (1) suppress that behaviour in debian/rules --- orig/openimageio-2.0.12~dfsg0/debian/rules 2019-10-04 12:02:14.0 +0200 +++ openimageio-2.0.12~dfsg0/debian/rules 2020-01-20 02:47:22.160681481 +0100 @@ -21,6 +21,7 @@ -DROBINMAP_INCLUDE_DIR="/usr/include/" \ -DCMAKE_SKIP_RPATH=ON \ -DPYTHON_VERSION=$(PY3VERS) \ + -DBUILD_MISSING_PYBIND11=OFF \ -DSTOP_ON_WARNING=OFF \ -DUSE_FIELD3D=OFF \ -DUSE_OPENGL=$(SETGL) (2) I'd be inclined to define a precise lower bound in the debian/control, Not sure about that though, since it causes a maintennance liability... --- orig/openimageio-2.0.12~dfsg0/debian/control2019-10-04 23:24:41.0 +0200 +++ openimageio-2.0.12~dfsg0/debian/control 2020-01-20 03:16:38.561245302 +0100 @@ -25,7 +25,7 @@ libraw-dev, libtiff-dev, libwebp-dev, - pybind11-dev, + pybind11-dev (>= 2.2.0), python3-dev, qtbase5-dev, robin-map-dev (>= 0.2.0) -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (900, 'stable'), (650, 'stable'), (500, 'stable-updates'), (95, 'testing'), (80, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#943122: guitarix: Python2 removal in sid/bullseye
The latest guitarix release 0.39.0 solve this issue as it update waf to version 2.0.19. This removes the build dependency on Python2. regards hermann
Bug#948335: New upstream
Hi, Le January 7, 2020 1:03:14 PM UTC, Bastian Germann a écrit : >Package: golang-bindata >Version: 3.0.7+git20151023.72.a0ff256-3 >Severity: normal > >The jteeuwen/go-bindata repository is not maintained anymore, according >to its README.md. Thanks for reporting this ! >Please switch to https://github.com/go-bindata/go-bindata According to https://github.com/jteeuwen/discussions/issues/2, it's unclear if that's actually the "new upstream", or even maintained (there are also merges after this discussion). So while it's clear the upstream should be changed, the question is which upstream ? Cheers -- nodens
Bug#944535: collectd: rrdtool plugin: failed to build values string
On woensdag 13 november 2019 14:43:24 CET Bernd Zeimetz wrote: > > This is supposed to be fixed by upstream [1] in 5.9.2, but the fix is not > > in the Debian package. Which leads to the question what version is in the > > packages? > whatever was as 5.9.2 tarball on https://collectd.org/files/ - if that > has a diff to the github tag, that would be unfortunate. But there is an > issue about the 'collectd release process' open on github, maybe that is > one of the reasons. I just checked. The tarball from collectd.org is indeed different from the tagged commit. The tarball from github is ok. > > If i manually apply the upstream fix to the package, the problem is gone. > I'll update the package. Thanks. -- mvg, Alex Hermann Hexla
Bug#944535: collectd: rrdtool plugin: failed to build values string
Package: collectd Version: 5.9.2-4 Severity: important Dear Maintainer, The new version in unstable renders the rrdtool plugin useless. It just fills the log with gazillions of error messages: ... Nov 11 14:22:27 waxy collectd[24269]: rrdtool plugin: failed to build values string Nov 11 14:22:27 waxy collectd[24269]: rrdtool plugin: failed to build values string Nov 11 14:22:27 waxy collectd[24269]: rrdtool plugin: failed to build values string ... This is supposed to be fixed by upstream [1] in 5.9.2, but the fix is not in the Debian package. Which leads to the question what version is in the packages? If i manually apply the upstream fix to the package, the problem is gone. [1] https://github.com/collectd/collectd/commit/d27bfc74e606290f191c04cdb4e2acc4d5e8d4a9 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (400, 'experimental'), (200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages collectd depends on: ih collectd-core 5.9.2-4 ii libc6 2.29-3 ii librrd81.7.2-3 Versions of packages collectd recommends: ii default-jre-headless 2:1.11-72 pn intel-cmt-cat ii libatasmart4 0.19-5 pn libbson-1.0-0 ii libc6 2.29-3 ii libcurl3-gnutls 7.66.0-1+b1 ii libdbi1 0.9.0-5+b1 pn libesmtp6 pn libganglia1 ii libgcc1 1:9.2.1-19 ii libgcrypt20 1.8.5-3 ii libglib2.0-0 2.62.2-3 ii libgps25 3.19-2 pn libgrpc++1 ii libhiredis0.140.14.0-4 ii libi2c0 4.1-2 ii libip4tc2 1.8.3-2 ii libip6tc2 1.8.3-2 ii libldap-2.4-2 2.4.48+dfsg-1+b2 ii liblua5.3-0 5.3.3-1.1+b1 ii libmariadb3 1:10.3.19-1 pn libmemcached11 ii libmicrohttpd12 0.9.66-1+b1 ii libmnl0 1.0.4-2+b1 pn libmodbus5 pn libmongoc-1.0-0 ii libmosquitto1 1.6.7-1 ii libnotify40.7.8-1 pn libopenipmi0 ii liboping0 1.10.0-2.1+b2 pn libowcapi-3.2-3 ii libpcap0.81.9.1-2 ii libperl5.30 5.30.0-9 ii libpq512.0-1+b1 ii libprotobuf-c11.3.2-1+b1 ii libprotobuf17 3.6.1.3-2 ii libpython3.7 3.7.5-2 pn libqpid-proton11 pn librabbitmq4 pn librdkafka1 pn libriemann-client0 ii librrd8 1.7.2-3 pn librte-eal18.11 pn librte-ethdev18.11 ii libsensors5 1:3.6.0-2 ii libsnmp35 5.8+dfsg-2 ii libssl1.1 1.1.1d-2 ii libstdc++69.2.1-19 pn libtokyotyrant3 ii libudev1 242-8 pn libvarnishapi2 ii libvirt0 5.6.0-2 ii libxenmisc4.114.11.1+92-g6c33308a8d-2+b1 ii libxml2 2.9.4+dfsg1-7+b3 ii libyajl2 2.1.0-3 collectd suggests no packages. -- Configuration Files: /etc/collectd/collectd.conf changed [not included] -- debconf information excluded
Bug#942394: python3-icalendar: python3 cli.py view not working due to an str/byte issue
Package: python3-icalendar
Version: 4.0.3-2
Severity: normal
Tags: patch
Dear Maintainer,
$ python3 -m icalendar.cli view /tmp/test.ics
Traceback (most recent call last):
File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/lib/python3/dist-packages/icalendar/cli.py", line 111, in
main()
File "/usr/lib/python3/dist-packages/icalendar/cli.py", line 104, in main
args.func(**{k: v for k, v in vars(args).items()
File "/usr/lib/python3/dist-packages/icalendar/cli.py", line 74, in view
description=event.get('description', '')).encode('utf-8'))
TypeError: write() argument must be str, not bytes
removing the encode(...) part makes it working, patch is appended.
Additionally:
$ python3 -m icalendar.cli
Traceback (most recent call last):
File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/lib/python3/dist-packages/icalendar/cli.py", line 111, in
main()
File "/usr/lib/python3/dist-packages/icalendar/cli.py", line 104, in main
args.func(**{k: v for k, v in vars(args).items()
AttributeError: 'Namespace' object has no attribute 'func'
Expected is a meaningfull error/help message, but my python3 argsparse skills
are not good
enough to propose a good solution.
Thanks,
greetings
Hermann
-- System Information:
Debian Release: 10.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-icalendar depends on:
ii python3 3.7.3-1
ii python3-dateutil 2.7.3-3
ii python3-tz2019.1-1
python3-icalendar recommends no packages.
python3-icalendar suggests no packages.
-- no debconf information
--- /usr/lib/python3/dist-packages/icalendar/cli.py 2018-10-10
09:41:19.0 +0200
+++ /tmp/cli.py 2019-10-15 17:15:15.805478145 +0200
@@ -71,7 +71,7 @@
time_to=datetime.strftime(event.get('dtend').dt, '%H:%M'),
location=event.get('location', ''),
comment=event.get('comment', ''),
-description=event.get('description', '')).encode('utf-8'))
+description=event.get('description', '')))
def main():
Bug#941095: /usr/bin/locale: 'locale' incorrectly complains about (only) 'LC_ALL', but not offending LC_* when locale not found
Package: libc-bin
Version: 2.28-10
Severity: minor
File: /usr/bin/locale
Dear Maintainer,
-- PROBLEM:
'locale' shows an error message ONLY about not being able to set LC_ALL
when any of a number of LC_ values are wrong, instead of pointing to the
offending values, as it does in other cases.
This is misleading and prevents people from easily figuring out what is
really the problem (missing locale, typo, ...), because it misdirects
attention to LC_ALL.
affected LC_s:
LANG
LC_NUMERIC
LC_TIME
LC_COLLATE
LC_MONETARY
LC_PAPER
LC_NAME
LC_ADDRESS
LC_TELEPHONE
LC_MEASUREMENT
LC_IDENTIFICATION
(potentially LANGUAGE)
-- EXPECTED:
'locale' should show an error message indicating which LC_s locale was not
found, as it does with 'LC_CTYPE' and 'LC_MESSAGES'.
-- REPRODUCE:
for l in $(locale | cut -d '=' -f 1) ; do echo "$l" ; env ${l}="MISSING"
locale > /dev/null ; echo ; done
LANG
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANGUAGE
LC_CTYPE
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_NUMERIC
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_TIME
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_COLLATE
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_MONETARY
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_MESSAGES
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_PAPER
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_NAME
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_ADDRESS
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_TELEPHONE
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_MEASUREMENT
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_IDENTIFICATION
locale: Cannot set LC_ALL to default locale: No such file or directory
LC_ALL
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
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 libc-bin depends on:
ii libc6 2.28-10
Versions of packages libc-bin recommends:
ii manpages 4.16-2
libc-bin suggests no packages.
-- no debconf information
Bug#935364: debhelper: dh_clean doesn't print info about files listed in debian/clean being removed, even with DH_VERBOSE
On 01/09/2019 08:57, Niels Thykier wrote: > Control: tags -1 moreinfo unreproducible > > On Thu, 22 Aug 2019 00:10:08 +0200 =?utf-8?q?Cl=C3=A9ment_Hermann?= > wrote: >> Package: debhelper >> Version: 12.5.3 >> Severity: normal >> >> Hi, >> >> while working on a package, I had trouble finding out why some file were >> disapearing without any reason and no entry in build log, despite using >> DH_VERBOSE. >> >> Looking at the code, it's because >> glob_expand_error_handler_silently_ignores is used, I guess to avoid >> warning about not being able to remove non-existing files. >> > > > Hi, > > I cannot reproduce the issue from the description. When I run dh_clean > with verbose it lists files/directories being removed. > > """ >> dh_clean -v foo >> rm -f debian/debhelper-build-stamp >> rm -rf debian/.debhelper/ >> rm -f -- debian/debhelper.substvars debian/dh-systemd.substvars foo >> debian/files >> ^^^ >> rm -fr -- debian/debhelper/ debian/tmp/ debian/dh-systemd/ >> [...] > """ > > (see ^^^ line) > > Can you provide a concrete example where it does not work? Hi, Apparently I missed the file when looking at my buildd logs. I tried to reproduce the issue, and it's actually here, just lost in the middle of the "rm" line. I probably was so confused about this file disappearing I wasn't able to "grep" properly (or even to set DH_VERBOSE env var) ;) Sorry for the noise. Cheers, nodens
