Bug#1069181: sd: typo in description: defualts -> defaults
Package: sd Version: 0.80.really.0.7.6-1+deb12u1 Severity: minor Tags: patch Please replace "defualts" in the package description with "defaults". Thank you & greetings, * -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sd depends on: ii libc6 2.36-9+deb12u4 ii libgcc-s1 12.2.0-14 sd recommends no packages. sd suggests no packages.
Bug#1066029: secnet: please correct long description that says that hippotat is not packaged
Package: secnet Version: 0.6.7 Severity: minor The secnet long description reads: > secnet works well with userv-ipif (allowing it to run without needing root > privilege) and hippotat (not currently in Debian) However hippotat seems to be packaged: https://packages.debian.org/search?keywords=hippotat Please correct the description. Thanks a lot! *t -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages secnet depends on: ii init-system-helpers1.65.2 pn libadns1 ii libc6 2.36-9+deb12u4 ii libgmp10 2:6.2.1+dfsg1-1.1 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages secnet recommends: ii python3 3.11.2-1+b1 secnet suggests no packages.
Bug#887035: cron: one "easy" way to get cron output
Nice, thanks a lot Georges!!! *t On Thu, 29 Feb 2024, Georges Khaznadar wrote: Hello Tomas, with the current version of cron in trixie, - the build was done with debugging active - man cron provides information about the `-x` flag. So, I close the bug report. Please feel free to reopen it when necessary, or send another bug report if something doe not fulfill your needs. Best regards, Georges. On Fri, 22 Jul 2022 15:59:17 +0200 Tomas Pospisek wrote: @Georges Khaznadar : what do you think about: 1. enabling debugging by default? 2. documenting `-x` ? If Debian would enable the "debbugging feature" of its cron by default, then this would add this overhead in a few places: if ( (DebugFlags & (mask) ) ) printf message; Since DebugFlags is 0 by default, this will ad an overhead of about two machine instructions I guess to a few places, which is a neglible waste/slowdown IMHO. With the "debugging feature" enabled Debian's cron will gain the very nice features: a) for the sysadmin to be able to debug what cron is doing and why and b) use the sysadmin being able to use Debian's cron in docker and kubernetes. IMHO a huge gain that costs nothing.
Bug#1063759: tracker: Please update project homepage URL
Source: tracker Version: 3.4.2-1 Severity: minor Please update the project's homepage. The homepage that is declared in the debian/control file, https://wiki.gnome.org/Projects/Tracker, leads to a "This page does not exist yet" page. The project seems to have a maintained and working homepage at https://tracker.gnome.org/. Thanks a lot, greetings, *t -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1059464: notepadqq: fix description "designed by developers"
Source: notepadqq Version: 2.0.0~beta1-4 Severity: minor Tags: patch The package's description should read gramatically ... correctly: Notepadqq is a text editor designed by developers, for developers. instead of: Notepadqq is a text editor designed from developers, for developers. Thanks & have nice christmas holidays! *t -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-15-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1053310: Fixes for stable/oldstable?
On Tue, 31 Oct 2023, Andreas Metzler wrote:
On 2023-10-31 Tomas Pospisek wrote:
[...]
PS: I'd prefer this bugreport to be open as long as the stable and
oldstable packages are still vulnerable...
Hello Thomas,
The Debian BTS does not use a simple open/close logic, it tracks which
specific versions a bug applies to. If you look at
https://bugs.debian.org/cgi-bin/1053310 there is both textual info
("Found in version exim4/4.94.2-7 Fixed in version exim4/4.97~RC2-2")
and a nice graph in red and green to display this and the overview pages
can also show bugs applying to specific distributions. (Menu items at
the bottom of the page.) e.g.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;package=exim4-base
does not show this bug under "Resolved bugs".
Alright, thank you. Every time I see those "found in"/"fixed in"
bugreport pages I'm at a loss to be 100% clear in what precise state those
bugsreport are. Oh well. Many, many thanks for the explanations!
*t
Bug#1053310: Fixes for stable/oldstable?
Hi Salvatore, thanks a lot for your reply (more below): On Tue, 31 Oct 2023, Salvatore Bonaccorso wrote: Hi Tomas, On Tue, Oct 31, 2023 at 11:07:06AM +0100, Tomas Pospisek wrote: Hello Exim maintainers, this ticket, asking for packages with fixes for CVE-2023-42117 and other security relavant issues is closed. However only a package for unstable has been released: https://security-tracker.debian.org/tracker/CVE-2023-42117 all other Debian releases (stable, oldstable) still seem to be carrying the vulnerable Exim4 version. What is the status of releasing fixed Exims for Debian stable, oldstable? Is anybody working on it? Is help needed? Fixes for CVE-2023-42117 and CVE-2023-42119 are right now considered no-dsa (see comment on the security-tracker about it), and are going to be fixed in the next point releases. The notes say: *** [bookworm] - exim4 (Only an issue if Exim4 run behind an untrusted proxy-protocol proxy) [bullseye] - exim4 (Only an issue if Exim4 run behind an untrusted proxy-protocol proxy) [buster] - exim4 (Only an issue if Exim4 run behind an untrusted proxy-protocol proxy) https://www.zerodayinitiative.com/advisories/ZDI-23-1471/ https://bugs.exim.org/show_bug.cgi?id=3031 https://www.openwall.com/lists/oss-security/2023/09/29/5 https://www.openwall.com/lists/oss-security/2023/10/01/4 https://exim.org/static/doc/security/CVE-2023-zdi.txt *** So I think I can parse from those that CVE-2023-42117 is only critical when exim is run behind a "untrusted proxy-protocol proxy". Questions if you will: * what does "no-dsa" mean? DSA seems to mean Debian Security Announce. Does it mean there is no DSA for that problem yet? What does it mean when a CVE is considered "no-dsa" then? That no DSA will be released for it? * what is a "untrusted proxy-protocol proxy" in the context of a mail transport agent? So exim shouldn't be used behind an untrusted socks proxy? Well I have no real control who connects how to a public MTA... anybody can connect to it to try his luck sending me email. That includes untrusted socks proxies... So to wrap I it /seems/ that I'm probably fine, however the details are so terse that my assessement seems to be rather shaky... Does this help? A bit. Thanks a lot Best greetings! *t
Bug#1053310: Fixes for stable/oldstable?
Hello Exim maintainers, this ticket, asking for packages with fixes for CVE-2023-42117 and other security relavant issues is closed. However only a package for unstable has been released: https://security-tracker.debian.org/tracker/CVE-2023-42117 all other Debian releases (stable, oldstable) still seem to be carrying the vulnerable Exim4 version. What is the status of releasing fixed Exims for Debian stable, oldstable? Is anybody working on it? Is help needed? *t PS: I'd prefer this bugreport to be open as long as the stable and oldstable packages are still vulnerable...
Bug#1038946: please add a long description
Instead of solely having a short description that says "$FOO is a $BAZ for $BAR" where it's not immediately clear without particular knowledge what $FOO and $BAR are, please add a short text, that explains what $FOO and $BAR actually do. Something like: "Xapp is an application that does . xdg-desktop-portal allows you to do this and that. This package adds infrastructure to support Xapp via xdg-desktop-portal on Cinnamon, MATE and Xfce." Thanks, *t
Bug#1038946: please add a long description
On Mon, 26 Jun 2023, Fabio Fantoni wrote: Il 26/06/2023 12:30, Tomas Pospisek ha scritto: Instead of solely having a short description that says "$FOO is a $BAZ for $BAR" where it's not immediately clear without particular knowledge what $FOO and $BAR are, please add a short text, that explains what $FOO and $BAR actually do. Something like: "Xapp is an application that does . xdg-desktop-portal allows you to do this and that. This package adds infrastructure to support Xapp via xdg-desktop-portal on Cinnamon, MATE and Xfce." Thanks, *t Thanks for reply, long description was already added to git of the package: https://salsa.debian.org/cinnamon-team/xdg-desktop-portal-xapp/-/blob/debian/latest/debian/control Description: Xapp's Cinnamon, MATE and Xfce backends for xdg-desktop-portal xdg-desktop-portal-xapp provides an implementation for the desktop-agnostic xdg-desktop-portal service for Cinnamon, MATE and Xfce. This allows sandboxed applications to request services and information from outside the sandbox in the MATE, Xfce and Cinnamon environments. I taken as base the upstream one (for mint packages) and tried to improve it but suggestions on further improvements are appreciated I think the long description on Salsa is fine. Thanks a lot Fabio! *t
Bug#1036077: please reassign to xserver
Since this seems to be a xserver problem, could you please reassign the ticket to the correct xserver package? *t
Bug#941966: Hibernate bug still occuring?
Hi Thorsten, does the bug you described in https://bugs.debian.org/941966 still occur? I.e.: * do you still have that system? * did you maybe upgrade it to a more recent bullseye kernel? Greetings, *t
Bug#970819: Hibernate bug still occuring?
Hi Cameron, does the bug you described in https://bugs.debian.org/970819 still occur? I.e.: * do you still have that system? * did you maybe upgrade it from Debian buster to bullseye? Greetings, *t
Bug#929077: Hibernate bug still occuring?
Hi Chris, does the bug you described in https://bugs.debian.org/929077 still occur? I.e.: * do you still have that system? * did you maybe upgrade it from Debian buster to bullseye? Greetings, *t
Bug#1027483: thank you!
and I guess #1027483 can be closed as it is still open along with #1027430 ? On Wed, 25 Jan 2023, Tomas Pospisek wrote: Woah guys, a new Debian stable kernel came my way and finally sound works again consistently. Many, many, many thanks to you for bisecting, patching and shipping the fix. Muito, muito obrigado! *t
Bug#1027483: thank you!
Woah guys, a new Debian stable kernel came my way and finally sound works again consistently. Many, many, many thanks to you for bisecting, patching and shipping the fix. Muito, muito obrigado! *t
Bug#989943: Problem still occuring in unattenden-upgrades from bullseye
Package: unattended-upgrades
Version: 2.8
Followup-For: Bug #989943
X-Debbugs-Cc: Michael Vogt
Hi,
I'm still seeing this problem in unattended-upgrades from Debian bullseye.
Thanks a lot for unattended-upgrades and the maintainance!!!
*t
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-22-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages unattended-upgrades depends on:
ii debconf [debconf-2.0] 1.5.77
ii lsb-base 11.1.0
ii lsb-release11.1.0
ii python33.9.2-3
ii python3-apt2.2.1
ii python3-dbus 1.2.16-5
ii python3-distro-info1.0
ii ucf3.0043
ii xz-utils 5.2.5-2.1~deb11u1
Versions of packages unattended-upgrades recommends:
ii cron [cron-daemon] 3.0pl1-137
Versions of packages unattended-upgrades suggests:
ii bsd-mailx 8.1.2-0.20180807cvs-2
pn needrestart
ii nullmailer [mail-transport-agent] 1:2.2-3
pn powermgmt-base
ii python3-gi 3.38.0-2
-- debconf information:
* unattended-upgrades/enable_auto_updates: true
unattended-upgrades/origins_pattern:
"origin=Debian,codename=${distro_codename},label=Debian-Security";
Bug#998950: mailsync: diff for NMU version 5.2.7-3.1
On Thu, 3 Nov 2022, Marcos Talau wrote: Control: tags 998950 + patch Control: tags 998950 + pending Dear maintainer, I've prepared an NMU for mailsync (versioned as 5.2.7-3.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Many, many thanks Marcos! *t
Bug#1003974: Screenshot of missing icons in Impress
see previous email in this bugreport for context
Bug#1003974: libreoffice-impress: Some icons do not get displayed in Impress
Hello Nicolas and Libre Office maintainers, (Not sure what's going on, I'm submitting this bug report for the third time since for unknown reason it doesn't make it into the BTS) My Libre Office Impress is not displaying some icons - see attached screenshot that I will send in the next email. I think this *might* be the same problem as Nicolas reported. I also have XFCE as a desktop, like Nicolas does. I have the libreoffice-gtk3 (1:7.4.1-1~bpo11+2) integration library installed. My libreoffice package is from bullseye-backports running on a bullseye system. I did not have the problems with the icons with the package from the bullseye distro (that is with the 1:7.0.4-4+deb11u4 packages). Thank you for the libreoffice packages dear maintainers! *t -- Package-specific info: -- System Information: Debian Release: 11.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-impress depends on: ii libbox2d2.3.02.3.1+ds-7 ii libc62.31-13+deb11u4 ii libepoxy01.5.5-1 ii libetonyek-0.1-1 0.1.9-4 ii libgcc-s110.2.1-6 ii libodfgen-0.1-1 0.1.8-2 ii libreoffice-common 1:7.4.1-1~bpo11+2 ii libreoffice-core 1:7.4.1-1~bpo11+2 ii libreoffice-draw 1:7.4.1-1~bpo11+2 ii librevenge-0.0-0 0.0.4-6+b1 ii libstaroffice-0.0-0 0.0.7-1 ii libstdc++6 10.2.1-6 ii libuno-cppu3 1:7.0.4-4+deb11u4 ii libuno-cppuhelpergcc3-3 1:7.4.1-1~bpo11+2 ii libuno-sal3 1:7.4.1-1~bpo11+2 ii libuno-salhelpergcc3-3 1:7.0.4-4+deb11u4 ii ucf 3.0043 ii uno-libs-private 1:7.4.1-1~bpo11+2 libreoffice-impress recommends no packages. Versions of packages libreoffice-impress suggests: ii bluez 5.55-3.1 Versions of packages libreoffice-core depends on: ii fontconfig 2.13.1-4.2 ii fonts-opensymbol2:102.12+LibO7.4.1-1~bpo11+2 ii libabsl20200923 0~20200923.3-2 ii libboost-filesystem1.74.0 1.74.0-9 ii libboost-iostreams1.74.01.74.0-9 ii libboost-locale1.74.0 1.74.0-9 ii libc6 2.31-13+deb11u4 ii libcairo2 1.16.0-5 ii libclucene-contribs1v5 2.3.3.4+dfsg-1+b1 ii libclucene-core1v5 2.3.3.4+dfsg-1+b1 ii libcups22.3.3op2-3+deb11u2 ii libcurl3-gnutls 7.74.0-1.3+deb11u3 ii libdbus-1-3 1.12.24-0+deb11u1 ii libdconf1 0.38.0-2 ii libeot0 0.01-5+b1 ii libepoxy0 1.5.5-1 ii libexpat1 2.2.10-2+deb11u5 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1+deb11u1 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.8-1 ii libgpgmepp6 1.14.0-1+b2 ii libgraphite2-3 1.3.14-1 ii libgstreamer-plugins-base1.0-0 1.18.4-dmo1 ii libgstreamer1.0-0 1.18.4-2.1 ii libharfbuzz-icu02.7.4-1 ii libharfbuzz0b 2.7.4-1 ii libhunspell-1.7-0 1.7.0-3 ii libhyphen0 2.8.8-7 ii libice6 2:1.0.10-1 ii libicu6767.1-7 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-2 2.12~rc1-2 ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1 ii libmythes-1.2-0 2:1.2.4-3+b1 ii libnspr42:4.29-1 ii libnss3 2:3.61-1+deb11u2 ii libopenjp2-72.4.0-3 ii libpng16-16 1.6.37-3 ii libpoppler102 20.09.0-3.1+deb11u1 ii libraptor2-02.0.14-1.2 ii librdf0 1.0.17-1.1+b1 ii libreoffice-common 1:7.4.1-1~bpo11+2 ii librevenge-0.0-00.0.4-6+b1 ii libsm6 2:1.2.3-1 ii libstdc++6 10.2.1-6 ii libtiff54.2.0-1+deb11u1 ii libuno-cppu31:7.0.4-4+deb11u4 ii libuno-cppuhelpergcc3-3 1:7.4.1-1~bpo11+2 ii libuno-sal3 1:7.4.1-1~bpo11+2 ii libuno-salhelpergcc3-3 1:7.0.4-4+deb11u4 ii libwebp60.6.1-2.1 ii libx11-62:1.7.2-1 ii libx11-xcb1 2:1.7.2-1 ii libxext62:1.3.3-1.1 ii libxinerama12:1.1.4-2 ii libxml2
Bug#1003974: similar bugs having to do with icons not appearing
Hi bug reporters and Libre Office maintainers, there's a number of bugs related to Icon rendering that seem to be simlar or identical. Herewith I'm posting to them to crosslink them. I have however *not* looked at them in depth. Here are the bug reports: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661818 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969977 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003974 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972280 The idea of posting to all of them/crosslinking them is the hope that maybe the reporters and or maintainers can verify that they are the same and/or find workarounds or root causes/fixes to all of them... *t
Bug#1020279: hcloud-cli: please package a newer version (wish: --label suport)
Package: hcloud-cli Version: 1.13.0-2+b6 Severity: wishlist X-Debbugs-Cc: Thorsten Alteholz Hi, thanks for packaging hcloud-cli. I'd be glad if a more recent hcloud-cli version would be available in Debian, specifically one > 1.16, because that version supports the `--label` flag on server commands, which I need to do categorize Hetzner resources. Thanks for the hcloud package! *t -- System Information: Debian Release: 11.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-18-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hcloud-cli depends on: ii libc6 2.31-13+deb11u4 hcloud-cli recommends no packages. hcloud-cli suggests no packages. -- no debconf information
Bug#887035: cron: Patch by Greek adapted for cron 3.0pl1-137
Hi Georges, first off: this patch is completely irrelevant IMHO. We should not be discussing it. What's relevant is [1]. On Sun, 24 Jul 2022, Georges Khaznadar wrote: two remarks: 1) most of Greek's patches which you adapted is about making cron installable without the package syslog. That is what it claims but not what it does AFAICS. What it does is adapt the `log_it` function so that it takes a `priority` parameter. But again. This patch is irrelevant. [1] is relevant IMO. Were are the parts about "log-to-stdout-when-in-foreground"? It's at [2]. But it's irrelevant. [1] is relevant. I see that one patch modifies debian/patches/series, mentioning the file log-to-stdout-when-in-foreground, but that file is provided nowhere by the set of patches. Again see [2]. But it's irrelevant. [1] is relevant. By the way, do you know who is "Greek"? No She or he did not reply to questions which I submitted about Bug#887014 ... It's been 4 years since this bug has been filed so "Greek" might have moved on since. Is "Greek" a pseudonyme of yours? No 2) I shall not patch cron 3.0pl1-137. You can do it if you want, for your own usage, of course. If I modify debian's cron package, I must do it in the testing distribution, so please propose patches targetting at least cron 3.0pl1-147. Then, if the modification you are wishing is accepted in debian/testing, I can create a backport to use in debian/bullseye later, for example a release such as cron 3.0pl1-149~bpo11+1, to be published in bullseye-backports. Ack. However I do not want that patch to be included because as I said as far as I can see it does *not* activate output to STDOUT, contrary to what the origianl message by "Greek" claims. That patch is irrelevant, I have only posted it in case somebody is interested in using it. But I am *not* interested in it. I am interested in [1] only. Thanks! *t [1] - enable debugging logs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887035#15/ [2] - debian/patches: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=887035;filename=log-to-stdout-when-in-foreground;msg=25 Best regards, Georges. Tomas Pospisek a écrit : Package: cron Version: 3.0pl1-137 Followup-For: Bug #887035 X-Debbugs-Cc: Georges Khaznadar If anybody wants to use Greek's patch (see [1] and [2]) then I'm attaching my version of it adapted to cron 3.0pl1-137 (the version in Debian bullseye). It comes in two parts: one is the patch and one is cron-3.0pl1/debian/patches/log-to-stdout-when-in-foreground to satisfy the Debian build infrastructure. Use the patch like this to build a new, patched cron package: apt-get source cron sudo apt-get build-dep cron patch -p0 < cron-syslog-fix-and-foreground-stdout.for-new-cron.debianized.patch cp log-to-stdout-when-in-foreground cron-3.0pl1/debian/patches cd cron-3.0pl1 && dpkg-buildpackage -rfakeroot *t [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887035#5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=887035;filename=cron-syslog-fix-and-foreground-stdout.patch;msg=5 -- Package-specific info: --- EDITOR: --- /usr/bin/editor: /usr/bin/vim.gtk3 --- /usr/bin/crontab: -rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab --- /var/spool/cron: drwxr-xr-x 3 root root 4096 Apr 10 2021 /var/spool/cron --- /var/spool/cron/crontabs: drwx-wx--T 2 root crontab 4096 Feb 22 2021 /var/spool/cron/crontabs --- /etc/cron.d: drwxr-xr-x 2 root root 4096 Jul 22 15:03 /etc/cron.d --- /etc/cron.daily: drwxr-xr-x 2 root root 4096 Jul 11 09:33 /etc/cron.daily --- /etc/cron.hourly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.hourly --- /etc/cron.monthly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.monthly --- /etc/cron.weekly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.weekly -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cron depends on: ii adduser 3.118 ii debianutils 4.11.2 ii init-system-helpers 1.60 ii libc62.31-13+deb11u3 ii libpam-runtime 1.4.0-9+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libselinux1 3.1-3 ii lsb-base 11.1.0 ii sensible-utils 0.0.14 Versions of packages cron recommends: ii msmtp-mta [mail-transport-agent] 1.8.11-2.1 Versions of packages cron suggests: ii anacron2.3-30 pn checksecurity ii logrotate 3.18.0-2+deb11u1 Versions of packages cron is related to: pn libnss-l
Bug#887035: cron: one "easy" way to get cron output
Hello Georges, On Fri, 22 Jul 2022, Georges Khaznadar wrote: Would it seem reasonable, for your needs, to find two separate binary packages in Debian, "cron" and let us say, "cron-debug"? Both package would be built from the same source, the first one with no special build parameter, the second one with debugging activated (and output to stdout activated by the switch -f)? * yes, having a separate package would be fine * in case you want to go with a separate package than I'd suggest `cron-log-to-stderr` as the name because that makes it explicit what that package is about. * however why not keep it in one single package and just make the debug feature available? * as is the `-f` switch will *not* activate output to STDOUT. The patch provided by `Greek` [1] does *not* make `-f` log to STDOUT (instead the main function of the patch is to add the `priority` parameter to the `log_it` function that does the logging to STDERR and to syslog). * the command line option that switches on logging to STDERR is `-x what_to_log`. Again, I'd argue to make the `-x` aka "debugging output" *feature* available by default (it will *not* make cron log to STDERR by default. That needs to be done explicitly by supplying the `-x` switch) and continue with a single package. It there any technical reason why the "debugging output" *feature* should not be available? Thanks a lot for caring about this issue! *t [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=887035;filename=cron-syslog-fix-and-foreground-stdout.patch;msg=5 (I've snipped off the rest of the toplevel posting.)
Bug#887035: cron: Patch by Greek adapted for cron 3.0pl1-137
Package: cron
Version: 3.0pl1-137
Followup-For: Bug #887035
X-Debbugs-Cc: Georges Khaznadar
If anybody wants to use Greek's patch (see [1] and [2]) then I'm attaching my
version of it adapted to cron 3.0pl1-137 (the version in Debian bullseye).
It comes in two parts: one is the patch and one is
cron-3.0pl1/debian/patches/log-to-stdout-when-in-foreground to satisfy
the Debian build infrastructure.
Use the patch like this to build a new, patched cron package:
apt-get source cron
sudo apt-get build-dep cron
patch -p0 <
cron-syslog-fix-and-foreground-stdout.for-new-cron.debianized.patch
cp log-to-stdout-when-in-foreground cron-3.0pl1/debian/patches
cd cron-3.0pl1 && dpkg-buildpackage -rfakeroot
*t
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887035#5
[2]
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=887035;filename=cron-syslog-fix-and-foreground-stdout.patch;msg=5
-- Package-specific info:
--- EDITOR:
--- /usr/bin/editor:
/usr/bin/vim.gtk3
--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab
--- /var/spool/cron:
drwxr-xr-x 3 root root 4096 Apr 10 2021 /var/spool/cron
--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Feb 22 2021 /var/spool/cron/crontabs
--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Jul 22 15:03 /etc/cron.d
--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Jul 11 09:33 /etc/cron.daily
--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.hourly
--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.monthly
--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.weekly
-- System Information:
Debian Release: 11.4
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8),
LANGUAGE=de_CH:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cron depends on:
ii adduser 3.118
ii debianutils 4.11.2
ii init-system-helpers 1.60
ii libc62.31-13+deb11u3
ii libpam-runtime 1.4.0-9+deb11u1
ii libpam0g 1.4.0-9+deb11u1
ii libselinux1 3.1-3
ii lsb-base 11.1.0
ii sensible-utils 0.0.14
Versions of packages cron recommends:
ii msmtp-mta [mail-transport-agent] 1.8.11-2.1
Versions of packages cron suggests:
ii anacron2.3-30
pn checksecurity
ii logrotate 3.18.0-2+deb11u1
Versions of packages cron is related to:
pn libnss-ldap
pn libnss-ldapd
pn libpam-ldap
pn libpam-mount
pn nis
pn nscd
-- no debconf information
diff -u -r orig/cron-3.0pl1/cron.c cron-3.0pl1/cron.c
--- orig/cron-3.0pl1/cron.c 2022-07-19 12:18:36.0 +0200
+++ cron-3.0pl1/cron.c 2022-07-19 14:24:39.0 +0200
@@ -122,12 +122,12 @@
} else if (!stay_foreground) {
switch (fork()) {
case -1:
- log_it("CRON",getpid(),"DEATH","can't fork");
+ log_it(LOG_ERR, "CRON",getpid(),"DEATH","can't fork");
exit(0);
break;
case 0:
/* child process */
- log_it("CRON",getpid(),"STARTUP","fork ok");
+ log_it(LOG_INFO, "CRON",getpid(),"STARTUP","fork ok");
(void) setsid();
freopen("/dev/null", "r", stdin);
freopen("/dev/null", "w", stdout);
@@ -281,18 +281,18 @@
/* Run on actual reboot, rather than cron restart */
if (access(REBOOT_FILE, F_OK) == 0) {
/* File exists, return */
- log_it("CRON", getpid(),"INFO",
+ log_it(LOG_INFO, "CRON", getpid(),"INFO",
"Skipping @reboot jobs -- not system startup");
return;
}
/* Create the file */
if ((rbfd = creat(REBOOT_FILE, S_IRUSR & S_IWUSR)) < 0) {
/* Bad news, bail out */
- log_it("CRON",getpid(),"DEATH","Can't create reboot check
file");
+ log_it(LOG_ERR, "CRON",getpid(),"DEATH","Can't create reboot
check file");
exit(0);
} else {
close(rbfd);
- log_it("CRON", getpid(),"INFO", "Running @reboot jobs");
+ log_it(LOG_INFO, "CRON", getpid(),"INFO", "Running @reboot
jobs");
}
Debug(DMISC, ("[%d], running reboot jobs\n", getpid()));
for (u = db->head; u != NULL; u = u->next) {
diff -u -r orig/cron-3.0pl1/cron.h cron-3.0pl1/cron.h
--- orig/cron-3.0pl1/cron.h 2022-07-19 12:18:36.0 +0200
+++ cron-3.0pl1/cron.h 2022-07-19 14:24:39.0 +0200
@@ -144,6 +144,20 @@
#define
Bug#887035: cron: one "easy" way to get cron output
Package: cron Version: 3.0pl1-137 Followup-For: Bug #887035 X-Debbugs-Cc: Greek , Javier Fernández-Sanguino Peña , Georges Khaznadar Instead of patching cron, an easy way to get cron output to stdout is to: * rebuild it with debugging enabled: $ apt-get source cron $ apt-get build-dep cron $ cd cron-3.0pl1 $ DEB_BUILD_OPTIONS=debug dpkg-buildpackage -rfakeroot * use the undocumented `-x` option of Debian's cron to start it: # cron -f -L 15 -x misc (I found the `misc` debug log the most suiting) * wrap the whole thing to redirect stderr to stdout: $ cat run-cron #!/bin/sh exec cron -f -L 15 -x misc 2>&1 @Georges Khaznadar : what do you think about: 1. enabling debugging by default? 2. documenting `-x` ? If Debian would enable the "debbugging feature" of its cron by default, then this would add this overhead in a few places: if ( (DebugFlags & (mask) ) ) printf message; Since DebugFlags is 0 by default, this will ad an overhead of about two machine instructions I guess to a few places, which is a neglible waste/slowdown IMHO. With the "debugging feature" enabled Debian's cron will gain the very nice features: a) for the sysadmin to be able to debug what cron is doing and why and b) use the sysadmin being able to use Debian's cron in docker and kubernetes. IMHO a huge gain that costs nothing. ? *t -- Package-specific info: --- EDITOR: --- /usr/bin/editor: /usr/bin/vim.gtk3 --- /usr/bin/crontab: -rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab --- /var/spool/cron: drwxr-xr-x 3 root root 4096 Apr 10 2021 /var/spool/cron --- /var/spool/cron/crontabs: drwx-wx--T 2 root crontab 4096 Feb 22 2021 /var/spool/cron/crontabs --- /etc/cron.d: drwxr-xr-x 2 root root 4096 Jul 22 15:03 /etc/cron.d --- /etc/cron.daily: drwxr-xr-x 2 root root 4096 Jul 11 09:33 /etc/cron.daily --- /etc/cron.hourly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.hourly --- /etc/cron.monthly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.monthly --- /etc/cron.weekly: drwxr-xr-x 2 root root 4096 Apr 10 2021 /etc/cron.weekly -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cron depends on: ii adduser 3.118 ii debianutils 4.11.2 ii init-system-helpers 1.60 ii libc62.31-13+deb11u3 ii libpam-runtime 1.4.0-9+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libselinux1 3.1-3 ii lsb-base 11.1.0 ii sensible-utils 0.0.14 Versions of packages cron recommends: ii msmtp-mta [mail-transport-agent] 1.8.11-2.1 Versions of packages cron suggests: ii anacron2.3-30 pn checksecurity ii logrotate 3.18.0-2+deb11u1 Versions of packages cron is related to: pn libnss-ldap pn libnss-ldapd pn libpam-ldap pn libpam-mount pn nis pn nscd -- no debconf information
Bug#1008813: ITP: cargo-strip -- subcommand that reduces the size of Rust binaries
On 02.04.22 03:46, Josenilson Ferreira da Silva wrote: Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com * Package name: cargo-strip Version : 0.2.2 Upstream Author : Guillaume Valadon * URL : https://github.com/guedou/cargo-strip/issues * License : MIT/X, Programming Lang: rust Description : subcommand that reduces the size of Rust binaries subcommand that reduces the size of Rust binaries As of Rust 1.59, the charge command is now able to remove a binary. This can be activated in your Cargo.toml. "the charge command is now able to remove a binary". You mean like `rm /usr/local/bin/foobar`? I /think/ that's not what you wanted to express? *t
Bug#1008575: Wi-Fi works with loglevel=3 but not without
I wrote: Wi-Fi stops working after upgrading from -12- to linux-image-5.10.0-13-amd64 (iwlwifi: probe of :00:14.3 failed with error -110)) So in order to get more debug info, I set `loglevel=3` in grub in the kernel command line. That changed two things: * now while booting I get to see the line on screen: iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) That wouldn't get displayed previously when booting without `loglevel=3` * now Wi-Fi actually works! kernel logs say: Mar 29 09:03:29 enfi kernel: [4.631274] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-59.ucode Mar 29 09:03:29 enfi kernel: [4.631282] iwlwifi :00:14.3: api flags index 2 larger than supported by driver Mar 29 09:03:29 enfi kernel: [4.631290] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 65.3.35.22 Mar 29 09:03:29 enfi kernel: [4.631539] iwlwifi :00:14.3: loaded firmware version 59.601f3a66.0 QuZ-a0-hr-b0-59.ucode op_mode iwlmvm Mar 29 09:03:29 enfi kernel: [4.631551] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) [...] Mar 29 09:03:29 enfi kernel: [4.893787] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x354 Repeatedly switching back and forth between booting kernel ...-13 with or without `loglevel=3` will alternate between working and non-working Wi-Fi. *t On Mon, 28 Mar 2022, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1008575: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008575. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 1008...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 1008575: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008575 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1008575: linux-image-5.10.0-13-amd64: Wi-Fi stops working after upgrading from -12- to linux-image-5.10.0-13-amd64 (iwlwifi: probe of 0000:00:14.3 failed with error -110)
Package: src:linux Version: 5.10.106-1 Severity: important Dear Kernel maintainers and other Debian users that maybe have the same problem, After upgrading from linux-image-5.10.0-12-amd64 to linux-image-5.10.0-13-amd64 the iwlwifi is unable to initialise the Intel Corporation Wi-Fi 6 AX201 (rev 20) Wi-Fi device. Before: [4.549794] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-59.ucode [4.549800] iwlwifi :00:14.3: api flags index 2 larger than supported by driver [4.549808] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 65.3.35.22 [4.550084] iwlwifi :00:14.3: loaded firmware version 59.601f3a66.0 QuZ-a0-hr-b0-59.ucode op_mode iwlmvm [4.550099] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) After: [4.481502] iwlwifi: probe of :00:14.3 failed with error -110 The bug looks remotely similar to: https://bugs.debian.org/976110 https://bugs.debian.org/1003026 https://bugs.debian.org/976110 I've given the bug the severity: important, because this laptop is mostly used for being online and thus without that function is becomes more or less useless. I'll check whether I find something upstream. And report back. *t -- Package-specific info: ** Version: Linux version 5.10.0-12-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.103-1 (2022-03-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-12-amd64 root=UUID=2fd78bce-bb85-4405-82b5-2779947d695e ro quiet ** Not tainted ** Kernel log: ** Model information sys_vendor: HP product_name: HP ENVY Laptop 17-cg1xxx product_version: Type1ProductConfigId chassis_vendor: HP chassis_version: Chassis Version bios_vendor: Insyde bios_version: F.12 board_vendor: HP board_name: 8822 board_version: 49.36 ** Loaded modules: ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg bnep binfmt_misc dm_crypt dm_mod snd_soc_skl_hda_dsp snd_soc_hdac_hdmi snd_soc_dmic mei_hdcp intel_rapl_msr x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_sof_xtensa_dsp snd_sof snd_sof_intel_hda snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi irqbypass ledtrig_audio intel_cstate intel_uncore snd_hda_intel joydev snd_intel_dspcfg soundwire_intel soundwire_generic_allocation btusb iwlmvm snd_soc_core btrtl btbcm btintel snd_compress pcspkr soundwire_cadence bluetooth mac80211 serio_raw efi_pstore hp_wmi snd_hda_codec libarc4 wmi_bmof snd_hda_core snd_hwdep iwlwifi soundwire_bus uvcvideo jitterentropy_rng snd_pcm videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common drbg snd_timer videodev snd ansi_cprng iTCO_wdt intel_pmc_bxt iTCO_vendor_support cfg80211 ee1004 watchdog soundcore ecdh_generic mmc_block mc ecc mei_me mei rfkill hid_multitouch ucsi_acpi processor_thermal_device typec_ucsi intel_rapl_common intel_soc_dts_iosf typec tpm_crb int3403_thermal tpm_tis int340x_thermal_zone tpm_tis_core ac tpm intel_hid sparse_keymap rng_core soc_button_array int3400_thermal acpi_pad evdev acpi_thermal_rel intel_pmc_core msr parport_pc ppdev lp parport fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod i915 i2c_algo_bit nvme crc32_pclmul spi_pxa2xx_platform crc32c_intel drm_kms_helper nvme_core hid_generic dw_dmac ahci dw_dmac_core libahci t10_pi rtsx_pci_sdmmc ghash_clmulni_intel crc_t10dif libata mmc_core cec crct10dif_generic drm aesni_intel scsi_mod xhci_pci xhci_hcd libaes crct10dif_pclmul crypto_simd crct10dif_common usbcore cryptd glue_helper vmd rtsx_pci i2c_i801 intel_lpss_pci i2c_smbus intel_lpss idma64 usb_common i2c_hid fan wmi hid battery video button ** PCI devices: :00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01) Subsystem: Hewlett-Packard Company 11th Gen Core Processor Host Bridge/DRAM Registers [103c:8822] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- :00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Iris Xe Graphics [103c:8822] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915
Bug#1003887: terminology: outputs error on start: Could not fetch a node located at 0x40000004529e
Package: terminology Version: 1.9.0-2 Severity: minor When starting terminology I see: ``` ERR<148513>:elementary ../src/lib/elementary/efl_ui_focus_manager_calc.c:1529 _efl_ui_focus_manager_calc_efl_ui_focus_manager_manager_focus_set() Could not fetch a node located at 0x4004529e ## Copy & Paste the below (until EOF) into a terminal, then hit Enter eina_btlog << EOF /lib/x86_64-linux-gnu/libeina.so.1 0x7f2e06086ebc 0x7f2e0605a000 /lib/x86_64-linux-gnu/libeina.so.1 0x7f2e060880c1 0x7f2e0605a000 /lib/x86_64-linux-gnu/libeina.so.1 0x7f2e060896f3 0x7f2e0605a000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05ebe24e 0x7f2e05b61000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05eb8552 0x7f2e05b61000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05ebb925 0x7f2e05b61000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05eb915a 0x7f2e05b61000 /usr/bin/terminology 0x55cc71f83d73 0x55cc71f2c000 /usr/bin/terminology 0x55cc71f878bd 0x55cc71f2c000 /lib/x86_64-linux-gnu/libeo.so.1 0x7f2e057b28e2 0x7f2e0579b000 /lib/x86_64-linux-gnu/libeo.so.1 0x7f2e057ad090 0x7f2e0579b000 /lib/x86_64-linux-gnu/libelementary.so.1 0x7f2e05e8cd45 0x7f2e05b61000 /lib/x86_64-linux-gnu/libecore_evas.so.1 0x7f2e05b405b9 0x7f2e05b2d000 /lib/x86_64-linux-gnu/ecore_evas/engines/x/v-1.25/module.so 0x7f2e00fb3429 0x7f2e00fa7000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e06120480 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e06129642 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e06122439 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e0612130c 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e0611bef6 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e0611c6e5 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e06122295 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e061215cc 0x7f2e060fa000 /lib/x86_64-linux-gnu/libecore.so.1 0x7f2e0611c7d7 0x7f2e060fa000 /usr/bin/terminology 0x55cc71f4d16e 0x55cc71f2c000 /usr/bin/terminology 0x55cc71f4169d 0x55cc71f2c000 /lib/x86_64-linux-gnu/libc.so.6 0x7f2e057e9d0a 0x7f2e057c3000 /usr/bin/terminology 0x55cc71f416da 0x55cc71f2c000 EOF ``` This is not very nice, but terminology still works. Thus I'm assigning a severitfy of "minor". Piping that to eina_btlog gives: ``` /lib/x86_64-linux-gnu/libeina.so.1 | ??/?? : 32655 @ _eina_semaphore_free() /lib/x86_64-linux-gnu/libeina.so.1 | ??/?? : 32655 @ eina_log_print_cb_stdout() /lib/x86_64-linux-gnu/libeina.so.1 | ??/?? : 32655 @ eina_log_print() /lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ efl_ui_focus_manager_calc_update_order() y/lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ efl_ui_focus_manager_focus_set() /lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ efl_ui_focus_manager_calc_update_order() /lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ efl_ui_focus_manager_pop_history_stack() /usr/bin/terminology | ??/?? : 32655 @ MD5Final() /usr/bin/terminology | ??/?? : 32655 @ MD5Final() /lib/x86_64-linux-gnu/libeo.so.1| ??/?? : 32655 @ efl_provider_unregister() /lib/x86_64-linux-gnu/libeo.so.1| ??/?? : 32655 @ efl_event_callback_legacy_call() /lib/x86_64-linux-gnu/libelementary.so.1| ??/?? : 32655 @ elm_win_rotation_with_resize_set() /lib/x86_64-linux-gnu/libecore_evas.so.1| ??/?? : 32655 @ _ecore_evas_focus_device_set() /lib/x86_64-linux-gnu/ecore_evas/engines/x/v-1.25/module.so | /: 0 @ () /lib/x86_64-linux-gnu/libecore.so.1 | ??/?? : 0 @ ecore_main_fd_handler_active_set() /lib/x86_64-linux-gnu/libecore.so.1 | ??/?? : 0 @ efl_loop_message_handler_message_call() /lib/x86_64-linux-gnu/libecore.so.1 | ??/?? : 0 @ efl_loop_timeout() /lib/x86_64-linux-gnu/libecore.so.1 | ??/?? : 0 @ efl_loop_message_process() /lib/x86_64-linux-gnu/libecore.so.1 | ??/??
Bug#978650: podman: Failing by default?
Package: podman Followup-For: Bug #978650 X-Debbugs-Cc: Antonio Terceiro , Reinhard Tartler , Andrej Shadura Debian's podman isn't able to resolve short names out of the box. It seems however that upstream is (I have not verified that - I'm infering that from looking at an example [1]). Behaving differently from vanilla upstream will mean that recipes working out of the box with upstream will fail on Debian. I respect and consider valid the argument about the security aspect of using short-names brought forward by Reinhard in [2]. What I'd like to question is the weighting of: * convenience * being compatible with upstream versus * security aspect We gain securty by breaking convenience and compatibility with upstream. That's the price we pay here for that bit of security. Now let's consider the security part. It's a given that if you are using a random container image then you *will* get a random container image. Which is maybe not a very wise thing to do. However *are* people using random images without a second thought? And additionaly: do we want to protect people from using random images from the internet? It is a given that Unix is giving you the gun and if you point it at your foot and pull the trigger then the result will be bad. Being a Unix system admin one *must* be traditionally careful. How is this different with short-names? Why do we now have to protect the admin or the user? I think just like with everything else, recipes on the internet do *not* include random short-names but instead standard ones, such as official python or debian images. Also users are aware that installing a random container will execute random code on one's system. Therefore I'd like to argue that going with upstream behavior would be the better setting. Whichever way the argument goes: thanks a lot for maintaining podman! *t [1] https://github.com/ansible-community/ansible-bender/blob/master/simple-playbook.yaml [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978650#90 -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.0.25+ds1-1.1 ii containernetworking-plugins 0.9.0-1+b6 ii golang-github-containers-common 0.33.4+ds1-1 ii init-system-helpers 1.60 ii iptables 1.8.7-1 ii libc62.31-13+deb11u2 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1+deb11u1 ii runc 1.0.0~rc93+ds1-5+b2 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1+b6 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7 ii slirp4netns 1.0.1-2 ii tini 0.19.0-1 ii uidmap1:4.8.1-1 Versions of packages podman suggests: pn containers-storage ii docker-compose 1.25.0-1 -- Configuration Files: /etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Keine Berechtigung: '/etc/cni/net.d/87-podman-ptp.conflist' -- no debconf information
Bug#922499: spamassassin: sa-update fails with error "Cannot open file ..."
Hi Noah and ticket participants, I've been recently getting the Cannot open file /var/lib/spamassassin/3.004002/updates_spamassassin_org/1896304.tar.gz: No such file or directory at /usr/bin/sa-update line 1600. error from cron. Since you wrote: I believe that the fix from https://svn.apache.org/viewvc/spamassassin/branches/3.4/sa-update.raw?r1=1842326=1842325=1842326 should be sufficient and easily backportable. please allow me to ask: is there a particular reason why you don't publish a package with the patch applied? This is not meant as a critique or application of pressure but as a attempt to understand. * is there a need to test the patch and report back on whether it works? * is it that you do not want to do the work to release an updated package (which is completely legitimate to me). In which case would it be OK if somebody else pushed (NMU...) a patched version? For context: I certainly can patch my local spamassassin version however I guess it'd be more helpful, if all users of spamassasin would get the fix. That said, my system is still running oldstable, so maybe it's just not worth the effort and the better path forward is just to upgrade to the bullseye... Thanks a lot!!! (And I wish everybody nice holiday and soon a happy and good new year!) *t
Bug#1002573: follow-up 4
Hi Detlev, On Mon, 27 Dec 2021, detlev schmidtke wrote: and I do not agree that this is a sole kernel problem fstrim --verbose should report something, anything * there still isn't a text only output (as opposed to an image) of what you are seeing in the bugreport. So people that get emails from this bugreport tendentially do not know what you are talking about. Again: please add a text-only output of what the problem is to the bug report * Debian's bug tracking system is a bit weird in that by default (as far as I know) only the package maintainer gets an email. The ticket now being assigned to the kernel, the maintainer of linux-utils did not get any notice about what you wrote above. You have to include him explicitly (which I've done in this email). *t
Bug#1002573: please include console output in text form
Hi nst0022, I have reassigned your bugreport to the correct package, namely util-linux. Please when filing a bug report, assign the bug to the correct package in the first place, otherwise: * you'll be generating triage work for others * your bug report won't be seen by the maintainers and therefore be possibly useles Also please do *not* attach screenshots, when you can copy/paste text. Images are not searchable as oposed to text, which easily is. Also images are harder to manage (how do I cite text in your image?). So could you please write a follow up to your report, that includes the *text* only (no screen shot). Thanks, *t
Bug#1001461: network-manager-openconnect: the problem is not having installed the network-manager-openconnect-gnome package
Package: network-manager-openconnect Version: 1.2.6-1 Followup-For: Bug #1001461 When I try to a VPN connection by executing `nm-connection-editor`, after pressing the button "Create..." I see in the console: ** (nm-connection-editor:27682): WARNING **: 15:31:07.165: Could not load editor VPN plugin for ?org.freedesktop.NetworkManager.openconnect? (missing plugin file "/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-vpn-plugin-openconnect-editor.so"). (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.165: gtk_widget_get_parent: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): GLib-GObject-CRITICAL **: 15:31:07.165: g_object_set_data: assertion 'G_IS_OBJECT (object)' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.165: gtk_notebook_insert_page: assertion 'GTK_IS_WIDGET (child)' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.166: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.167: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): libnm-CRITICAL **: 15:31:07.167: ((libnm/nm-vpn-editor.c:49)): assertion '' failed ** Message: 15:31:07.167: Cannot save connection due to error: Invalid setting VPN: unspecified error (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.167: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): libnm-CRITICAL **: 15:31:07.191: ((libnm/nm-vpn-editor.c:49)): assertion '' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.191: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): libnm-CRITICAL **: 15:31:07.191: ((libnm/nm-vpn-editor.c:49)): assertion '' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.191: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (nm-connection-editor:27682): libnm-CRITICAL **: 15:31:07.210: ((libnm/nm-vpn-editor.c:49)): assertion '' failed (nm-connection-editor:27682): Gtk-CRITICAL **: 15:31:07.210: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed when I search for `/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-vpn-plugin-openconnect-editor.so` I see that it is in the package network-manager-openconnect-gnome. Since I am running Xfce it is not self-evident that I have to install a package that says that it is for Gnome. So I think that it'd be optimal to: * add a note to the package description saying: "you'll probably need the network-manager-openconnect-gnome package as well, if you want to manage the connections from the GUI" * maybe add a "Suggests: network-manager-openconnect-gnome" to the package? * and the nm-applet should not fail silently if it doesn't find an editor component, but instead it should say so: "I could not find the VPN editor component. Did you install the network-manager-openconnect-gnome package?" *t -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-openconnect depends on: ii adduser 3.118 ii libc62.31-13+deb11u2 ii libglib2.0-0 2.66.8-1 ii libnm0 1.30.0-2 ii libopenconnect5 8.10-2+b1 ii network-manager 1.30.0-2 ii openconnect 8.10-2+b1 network-manager-openconnect recommends no packages. network-manager-openconnect suggests no packages. -- no debconf information
Bug#1001461: network-manager-openconnect: doesn't have a VPN tab to configure the VPN gateway
Package: network-manager-openconnect Version: 1.2.6-1 Severity: important Hi, after installing network-manager-openconnect there's no VPN tab in the configuration dialog and so I can't enter the VPN gateway address anywhere to set up the VPN connection. I did restart NM via sudo systemctl restart NetworkManager and I did also restart the nm-applet via killall nm-applet; nohup nm-applet & but no luck. What I do: * click on the applet * click on "VPN Connections" * click on "Add a VPN connection..." * select "Cisco AnyConnect or openconnect (OpenConnect)" (I can also select Juniper, PaloAlto or Pulse - there won't be a VPN tab in either case) * click on "Create..." * the config dialog is shown * only "General", "Proxy", "IPv4 Settings", "IPv6 Settings" tabs are shown * there's no place I found to enter the VPN gateway * also whatever I do in that dialog, the "Save" button is always greyed out -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-openconnect depends on: ii adduser 3.118 ii libc62.31-13+deb11u2 ii libglib2.0-0 2.66.8-1 ii libnm0 1.30.0-2 ii libopenconnect5 8.10-2+b1 ii network-manager 1.30.0-2 ii openconnect 8.10-2+b1 network-manager-openconnect recommends no packages. network-manager-openconnect suggests no packages. -- no debconf information
Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]
On 06.12.21 20:43, Noah Meyerhans wrote: On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote: So what's happening with chromium in both sid and stable? I saw on d-release that it was removed from testing (#998676 and #998732), with a discussion about ending security support for it in stable. The problem really is lack of maintenance. In my opinion, chromium deserves an active *team* to support it in Debian. <...> The security team doesn't have the bandwidth to do it themselves, they need a team to help them. Sorry for a silly question, but whatʼs so wrong with the build done by linuxmint.com [1], so Debian needs a whole team to duplicate their effort? Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my (limited) experience. Well, you can start with the fact that the Mint chromium source packages don't even include the chromium source, let alone the sources for all the other things they build (NodeJS, and more). The biggest difficulty, as far as I can tell from my look at Chromium from several months ago, is that our patch set [1] needs a lot of attention with every chromium release. Mint doesn't apply any patches at all to the source, at least none of any real complexity. One lesson we may take from Mint, though, is that it's not worth trying to patch Chromium as much as we'd like. Anything that we can do to simplify the Chromium packaging will help us keep the package up-to-date, which in turn will help us keep our users safer. In my opinion, we should be pretty aggressive about dropping as many of the Chromium patches as possible, even if that means we link against bundled/vendored dependencies. Legal/licensing considerations are still important and I don't know if we actually *can* ship builds based on the bundled stuff. But based on the number of patches we have to disable various things [2] or build against system dependencies [3], I can't help but think we'd have an easier time keeping this package fresh if we could drop some of those. noah 1. https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series 2. https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable 3. https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system I'd also like to point out, that the ungoogled-chromium project has some overlap in goals with Debian and it'd possibly be interessing to join forces: https://github.com/ungoogled-software/ungoogled-chromium-debian (I have been running an ungoogled-chromium for a while (ca. a year ago?), however at that time their chrome wasn't extremely stable so I gave up again. Does anybody have experience using it recently?) *t
Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages
Rustam wrote on 12 Oct 2021: Hi Guillem, Any news on the proposed patch? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664#49 Can it be merged already? ;) Ubuntu packages are already using zstd compression. So tools like Mainline don't work on Debian any more, see e.g. https://github.com/bkw777/mainline/issues/121 More than that: AFAIU Ubuntu has in fact switched its default compressor to zstd [1], so Debian's tools haven't been able to understand Ubuntu's freshly generated packages from 2021-06-14 on. I have applied [2] Bálint's commit to *current* dpkg from git: * there was a trivial merge conflict in man/deb.pod, which is easily fixed [3] * in my dpkg git repo and zstd branch I have changed the patch author (including the merge conflict fix) back from me to Bálint [3], which might not be the right/clean way to do things, but that's a minor thing I can fix if Guillem would want that * dpkg-buildpackage built the patched package fine * I only did a smoketest with the resulting dpkg : `dpkg -x sbsigntool_0.9.4-2ubuntu1_amd64.deb foodir` [4] which successfully unpacked Ubuntu's zstd compressed sbsigntool package into the foodir directory So I am reporting that Bálint's patch [4] applies cleanly (with a trivially to solve merge conflict (see above)) and works (again see above for the minimal testing I did), has been in production in Ubuntu since 2021-04-14 and zstd is beeng used as default compressor in Ubtuntu since 2021-06-14. Of course I would welcome it very much if Debian's tools would be compatible and allow to work with Ubtuntu's packages. Concrete point in case: it would have made my life easier figuring out Ubuntu's mechanism to sign user-generated modules [5]. Thanks a lot to all involved! For Guillem's work on dpkg, Bálint for the patch and all others for their contributions here and in Ubuntu!!! Greets, *t [1] http://changelogs.ubuntu.com/changelogs/pool/main/d/dpkg/dpkg_1.20.9ubuntu2/changelog [2] https://salsa.debian.org/tpo/dpkg/-/tree/zstd [3] https://salsa.debian.org/tpo/dpkg/-/commit/e7cb231bc289d356f563c1e2c761d94c85aa7055 [4] https://packages.ubuntu.com/impish/amd64/sbsigntool/download [5] https://salsa.debian.org/rbalint/dpkg/-/commit/eb38de93eeb9524a54e80525c480df249828e84f [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939392
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Thu, 18 Nov 2021, Thomas Goirand wrote: On 11/17/21 11:01 AM, Tomas Pospisek wrote: Our instructions on Secure Boot [1] are a bit scatterbrained and do not specify precisely where the key should exist at. I was the one who wrote them, after *A LOT* of research about it on the internet. It was hard to find, really. I just explained how to sign, with no intention to have this automated (at the time), so no wonder there's no standard path... I did not intend my characterisation of the instructions as a critique of your work. I am extremely happy that you actually *did* the work for all of us so we can stand on the shoulders of what you did. Very much +1 and many thanks really!!! (And thanks & cheers to the Debian EFI Team as well :-D ) I would edit those instruction so that they create the key at the same location Ubuntu has its MOK keys. However I would prefer not to collide with some tools or automation or scripts that do the same at the same place. Please go ahead, and explain that this is the Ubuntu path. Done. I think it'd be preferable if Debian created (or however Ubuntu does it) it's key automatically at that same place as Ubuntu has them, which would make most of the instructions in the wiki [1] unnecessary and would make the user experience much easier and smoother since the (upstream) virtualbox package could install and sign it's modules by itself without any user interaction, just like it happens under Ubuntu (?). ? Well, to begin with, I wonder why the upstream virtualbox package is pushing its compiled modules at the wrong location, but yeah, sure! I guess one can always talk to upstream... Hopefully, we can have the automation to sign DKMS modules in a non-leaf package. I would strongly suggest we get a package with a very explicit name in it, like "dkms-automatic-mok-signing" so it would do the work. I would absolutely *not* go the path of disabling secure boot when a DKMS module gets installed... Since I have not looked further I am *guessing* that Ubuntu does the automatic creation of the MOK key in the shim-signed package. So I think it should be possible to lift Ubuntu's work out of there and also put it into the shim-signed package, into postinst or so. *t
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Wed, 17 Nov 2021, Tomas Pospisek wrote: I would edit those [wiki] instruction so that they create the key at the same location Ubuntu has its MOK keys. However I would prefer not to collide with some tools or automation or scripts that do the same at the same place. [...] [1] https://wiki.debian.org/SecureBoot I just updated the instructions accordingly with a pointer to this bug report in case Debian would generate the MOK key automatically in the future. *t
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
(Thomas I hope you don't mind I put you in the Cc) Leif Lindholm wrote: Currently, if dkms is installed, shim-signed prompts to disable kernel/module verification on next boot on some trigger events - to ensure the system will successfully boot (something, not necessarily untampered with) after a kernel upgrade. According to Vorlon, in Ubuntu: "that's since been superseded by code to instead generate and enroll a MOK key and sign all dkms modules with it." This sounds like a very useful feature that would be worth bringing into Debian. I'd like to expand on this. When I install upstream (Oracle's) virtualbox-6.1 then the package tries to compile and sign the required virtualbox modules and fails due to not being able to sign them. As far as I understand the code, the upstream virtualbox-6.1 package expects the MOK keys to be at: # grep "^DEB_.*KEY=" /usr/lib/virtualbox/vboxdrv.sh DEB_PUB_KEY=/var/lib/shim-signed/mok/MOK.der DEB_PRIV_KEY=/var/lib/shim-signed/mok/MOK.priv On a Ubuntu box (I checked on a focal) the keys are there: -rw--- 1 root root 1704 Jul 13 2018 /var/lib/shim-signed/mok/MOK.priv I do not know how they happen to appear there. I tried to find out, but failed due to not having direct access to that focal box. Our instructions on Secure Boot [1] are a bit scatterbrained and do not specify precisely where the key should exist at. I would edit those instruction so that they create the key at the same location Ubuntu has its MOK keys. However I would prefer not to collide with some tools or automation or scripts that do the same at the same place. I think it'd be preferable if Debian created (or however Ubuntu does it) it's key automatically at that same place as Ubuntu has them, which would make most of the instructions in the wiki [1] unnecessary and would make the user experience much easier and smoother since the (upstream) virtualbox package could install and sign it's modules by itself without any user interaction, just like it happens under Ubuntu (?). ? *t [1] https://wiki.debian.org/SecureBoot
Bug#999604: firefox-esr: is Firefox 78 still supported/ESR upstream? mfsa2021-49 without v78 release candidate?
Thanks a lot for the info Salvatore! I'll raise the severity of the issue accordingly, so that it gets a more "prominent" place in the tickets and so that other users will notice more easily the state this problem's at. *t On Sat, 13 Nov 2021, Salvatore Bonaccorso wrote: Hi Tomas, On Sat, Nov 13, 2021 at 11:18:39AM +0100, Tomas Pospisek wrote: Package: firefox-esr Version: 78.15.0esr-1~deb11u1 Severity: normal Tags: security X-Debbugs-Cc: secur...@debian.org, Debian Security Team Dear Firefox maintainers, I note that Mozillas Security Advisory mfsa2021-49 [1] has been released on 2021-11-02 thus nearly two weeks ago and contains a big stash of security fixes ... but only for Firefox 91 (ESR). I have searched (but not for very long; I do not seem to have enough permissions in Mozilla's Bugzilla to see the respective tickets) if the CVE's mentioned in the MFSA also apply to FF 78 or if they are being fixed for FF 78 as well. But I couldn't find any information about it. Thus I suppose that at least some of those security problems also *do* apply to FF 78. This is the crucial question here. In case those CVE would also apply to FF 78 then the follow up question would naturally be: is there a release with fixes for FF 78 forthcoming? Is there an ETA for them? If the answers to those questions above are not really clear, then I'd like to suggest to consider the question to what degree FF 78 is still supported upstream? The motivation behind these questions is of course that I am a bit uneasy browsing the internet with a browser that has a lot of known open security problems. That's something that concerns a lot of Debian users. In case FF 78 would not be very much supported upstream then maybe it'd be good if Debian officially dropped security support for FF 78? Finally: I am aware that this ticket is based on a *lot* of unverified hypotheticals. Please pardon me that and please do not get too upset about it. I just wanted to raise a flag about the fact that there are *a lot* of CVEs fixed in a current FF 91 ESR release but no corresponding FF 78 release. Trying to keep the answer short: Firefox 78.15.0 ESR was the last one in the 78 series, upstream support mvoed to ESR 91. https://www.mozilla.org/en-US/firefox/78.15.0/releasenotes/ https://www.mozilla.org/en-US/security/advisories/mfsa2021-44/ For Debian this means, the next DSA for firefox (which would be actually in the works), will be based on the 91 series. The update is delayed, because the toolchain is not yet ready, there are updates needed for rustc, which in turns needs llvm update as well. As such the issues are currently tracked as: https://security-tracker.debian.org/tracker/source-package/firefox-esr And (usually Moritz) will release updates once they are ready. Hope this helps, Regards, Salvatore
Bug#999604: firefox-esr: is Firefox 78 still supported/ESR upstream? mfsa2021-49 without v78 release candidate?
Package: firefox-esr Version: 78.15.0esr-1~deb11u1 Severity: normal Tags: security X-Debbugs-Cc: secur...@debian.org, Debian Security Team Dear Firefox maintainers, I note that Mozillas Security Advisory mfsa2021-49 [1] has been released on 2021-11-02 thus nearly two weeks ago and contains a big stash of security fixes ... but only for Firefox 91 (ESR). I have searched (but not for very long; I do not seem to have enough permissions in Mozilla's Bugzilla to see the respective tickets) if the CVE's mentioned in the MFSA also apply to FF 78 or if they are being fixed for FF 78 as well. But I couldn't find any information about it. Thus I suppose that at least some of those security problems also *do* apply to FF 78. This is the crucial question here. In case those CVE would also apply to FF 78 then the follow up question would naturally be: is there a release with fixes for FF 78 forthcoming? Is there an ETA for them? If the answers to those questions above are not really clear, then I'd like to suggest to consider the question to what degree FF 78 is still supported upstream? The motivation behind these questions is of course that I am a bit uneasy browsing the internet with a browser that has a lot of known open security problems. That's something that concerns a lot of Debian users. In case FF 78 would not be very much supported upstream then maybe it'd be good if Debian officially dropped security support for FF 78? Finally: I am aware that this ticket is based on a *lot* of unverified hypotheticals. Please pardon me that and please do not get too upset about it. I just wanted to raise a flag about the fact that there are *a lot* of CVEs fixed in a current FF 91 ESR release but no corresponding FF 78 release. Thanks a lot for maintaining FF! *t [1] https://www.mozilla.org/en-US/security/advisories/mfsa2021-49/ -- Package-specific info: -- Addons package information -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u2 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-2 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4 ii libnspr4 2:4.29-1 ii libnss3 2:3.61-1 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.2-1 ii libx11-xcb1 2:1.7.2-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrender1 1:0.9.10-1 ii procps 2:3.3.17-5 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.3.3-0+deb11u1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-6.1 pn fonts-stix | otf-stix ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.18.3-6+deb11u1 ii libgtk2.0-02.24.33-2 ii pulseaudio 14.2-2 -- no debconf information
Bug#992258: packages.debian.org still not showing bullseye-security packages
Hi, I'm running Debian bullseye and have firefox 78.15.0esr-1~deb11u1 from bullseye-security, but packages.debian.org is still showing 78.14.0esr-1~deb11u1 as the firefox-esr version available in Debian bullseye [1]. So the patch of Rhonda D'Vine, did not have an effect on at least the info that's displayed about the firefox-esr package in Debian bullseye. ? *t [1] https://packages.debian.org/search?keywords=firefox-esr
Bug#989586: firefox-esr: Letras borradas no jornal digital da Folha de São Paulo.
Hi Flávio, Is it this URL https://www.folha.uol.com.br/ you are referring to? It works for me (firefox 78.15.0esr-1~deb11u1), I have no blurred font. Would you mind sending a screenshot (not to me but to the bugreport (989...@bugs.debian.org)? *t
Bug#992155: alternative approach to automatically updating extrepo repo keys
An alternative approach could be that an `apt update` would trigger an `extrepo update`. I don't know enough about apt hooks etc. to be able to say if that would be feasible or - in case such a mechanism isn't available today - if apt's maintainers would be in favor of it? Installing a cron job that periodically retrieves extrepo updates would be easier to implement. However the problem of offline systems should be considered then. What do you do with systems (laptops f.ex.) that sleep when a cron job would be triggered or that are not connected to the internet at that time? One could look into systemd's timer mechanisms if the support being deferred until the system wakes up and is connected to the internet. *t
Bug#993488: maybe reason for wontfix?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a "wontfix + close" but no rationale. Which leaves the original reporter with a large "?" I guess. I am guessing that the reason for the "wontfix" is "that's just how Unix works unfortunately" aka "that's a Unix design bug"? Is my guess correct? One other question - any idea on a way forward here? I would guess that behaviour (changing group membership won't change group membership of running processes) is rooted somewhere quite low in the stack, maybe in the kernel itself (or in posix :-#)? So if the original reporter would want to go ahead and look to that problem beeing fixed would he need to go talk to the kernel mailing list or do you have idea where he could go to? *t
Bug#907336: still relevant? revert?
Dear ImageMagick Packaging Team, Short version: is it safe today to reenable PDF/PS conversion again these days? Long version: Today I was affected by the problem reported in [1], notably: convert: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/408. When I check /etc/ImageMagick-6/policy.xml I see that plenty of conversions to/from (?) PDF/(E)PS* are apparently disabled by default as delivered by Debian. Which actually covers part of the requests in this (#907336) bugreport. The mentioned stackoverflow Q however mentions that: Make sure ghostscript is updated kb.cert.org/vuls/id/332928 Which refers to a fix in Ghostscript 9.24 which is ages ago when compared to the Ghostscript version 9.53 currently in Debian stable. I have *zero* insight into the issues leading to PDF/PS conversion being disabled in Debian and if they still are relevant and still are of the same concern as they were at the times before Ghostscript 9.24. Or posed differently: does it make sense to reevaluate these issues and - if it turns out they are of no concern any more today - could the respective converters be re-enabled by default again? Thanks a lot for maintaining ImageMagick! Greetings, *t [1] https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion
Bug#991972: More information
So I'm not sure what to do about this ticket. The current situation is: * we have backports.org - which does *not* belong to Debian * when accessing it, some variations of the URL get forwarded to https://backports.debian.org/ and some break in various way My opinion on this is: let's let the backports.org URL die or be broken like it is. If people notice then let them manually switch the URL they use to https://backports.debian.org/. *t On Sun, 15 Aug 2021, Xan Charbonnet wrote: Sorry, I should have checked this on more than one browser before reporting. For some reason my ancient Firefox profile, when I browse to "backports.org", redirects to https://www.backports.org/. Perhaps this was a cached permanent redirect, or something to do with HSTS. On a naive profile (with seemingly any browser), browsing to "backports.org" fails, because backports.org has no A record. Not terribly friendly but not a problem. It sounds like your browser has some memory that points backports.org to backports.debian.org. A naive browser has no way to return anything for https://backports.org/ or http://backports.org/. www.backports.org does have a CNAME record: it points to backports.debian.org, which seems to have the same IP address as debian.org. Browsing to http://www.backports.org/ is successful: the Debian webserver redirects the request to https://backports.debian.org/, and when accessed via that name, the Debian webserver correctly serves the backports page. However, when you browse to https://www.backports.org/ (note the secure protocol), that's when it breaks. The Debian webserver defaults to serving the Debian homepage, complete with the TLS certificate for debian.org. This causes a nasty security error in the browser, and if bypassed, results in the Debian homepage loading at https://www.backports.org/ rather than the Backports page. The only remaining mystery is why my Firefox profile is handling "backports.org" the way it is. I'm trying to figure out how to diagnose that, but it doesn't seem like there's much visibility to that kind of thing. It could be something that affects everybody who visited backports.org during a particular timeframe. -- To unsubscribe, send mail to 991972-unsubscr...@bugs.debian.org.
Bug#992348: mapserver: please re-enable build of ruby-mapscript package
Hi Bas, frankly I find it very nice to hear you say no. Very refreshing and the argumentation is very sound - I completely concur. Nothing else to add to that other than thanks a lot to you for maintaining mapserver! I will discuss with my peers here whether and how to put effort into packaging ruby-mapserver. In case we get something going I'll eventually send you an URL and you'll be able to re-evaluate your assessment if you'll deem worth it. Again, thanks a lot for maintining mapserver, appreciate it a lot!!! Best greetings! *t On Tue, 17 Aug 2021, Sebastiaan Couwenberg wrote: tags 992348 wontfix thanks On 8/17/21 5:35 PM, Tomas Pospisek wrote: tldr: would it be possible to re-enable the ruby-mapscript package build? While possible, I'd rather not. Extended explication: requiring a packaged version of ruby-mapscript on Ubuntu 20.04 I today basically reverted commits [1] and [2] and ruby-mapscript built just fine. A quick test showed ruby-mapscript to work. Then I did the same thing on bullseye and again, ruby-mapscript build fine. Then you are one of the very few actual users of ruby-mapscript. Questions: * would it be possible to start building the ruby-mapscript package again? * I see commit [1] that says "Build Ruby MapScript only for default version", but it doesn't say why builds for other ruby versions are being dropped. What was the reason for dropping the build of ruby-mapscript for the various existing Ruby versions? Building for more than one ruby/php/python/etc version requires building mapserver again, this makes the build time significantly longer for very little gain during transitions to new interpreter versions. * half an hour later there's a commit [2] that drops ruby-mapscript alltogether. I couldn't find a log of the respective FTBS. But maybe it doesn't matter any more since it does seem to build just fine now. Because popcon showed no actual users of ruby-mapscript keeping the package around just causes unnecessary busy work. I don't use Ruby nor ruby-mapscript, but I do have to spend time maintaining those bits in mapserver. So would it be possible to revert [1] and [2]? Or should I fork the project on Salsa and file a PR? Don't bother with a PR, just maintain the fork of the packaging for your personal repo. If I could count on your long term commitment on maintaining the Ruby support in the mapserver package, I might consider merging your changes. But my experience with onboarding new contributors has been disappointing, they tend to disappear not long after their work got in the archive and don't stick around for long term maintenance. I'm not keen on increasing the amount of packaging I have to maintain but don't actually use. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#992348: mapserver: please re-enable build of ruby-mapscript package
Source: mapserver Version: 7.6.4-1 Severity: wishlist Hi Debian GIS maintainers, hi Bas! tldr: would it be possible to re-enable the ruby-mapscript package build? Extended explication: requiring a packaged version of ruby-mapscript on Ubuntu 20.04 I today basically reverted commits [1] and [2] and ruby-mapscript built just fine. A quick test showed ruby-mapscript to work. Then I did the same thing on bullseye and again, ruby-mapscript build fine. Questions: * would it be possible to start building the ruby-mapscript package again? * I see commit [1] that says "Build Ruby MapScript only for default version", but it doesn't say why builds for other ruby versions are being dropped. What was the reason for dropping the build of ruby-mapscript for the various existing Ruby versions? * half an hour later there's a commit [2] that drops ruby-mapscript alltogether. I couldn't find a log of the respective FTBS. But maybe it doesn't matter any more since it does seem to build just fine now. So would it be possible to revert [1] and [2]? Or should I fork the project on Salsa and file a PR? Either way: *thanks a lot for maintaining mapserver*!!! Greetings, *t [1] https://salsa.debian.org/debian-gis-team/mapserver/-/commit/45f6f67e4272122d9d9fa0c49f247d68690c659a [2] https://salsa.debian.org/debian-gis-team/mapserver/-/commit/8d14c0fe55e33ef1922ac529e23cbb04776afd9a -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#991853: reassign to ftp.debian.org
reassign 991853 ftp.debian.org thanks the archive.debian.org certificate problem seems to rather concern the ftp.debian.org pseudo package & DDs, thus I'm reassigning to it.
Bug#990807: thunderbird incapable to run only with ~/.thunderbird that was migrated from icedove
Thanks a lot for the explanation Carsten! *t On Thu, 15 Jul 2021, Carsten Schoenert wrote: Hello Tomas, Am 12.07.21 um 11:07 schrieb Tomas Pospisek: If I'd like to get rid of ~/.icedove and only have a standard ~/.thunderbird directory - which I am assuming is possible - then what would the correct way to do that be? the main mess is you will need to go to your profile and replace all occurrences of ".icdeove" with ".thunderbird" within the files. Doing this for .js|.json|.xml and so on files will be mostly easy, but it's possible that there is also something in the encrypted files and also in the .sqlite files. It's all doable, and I wanted to start something that is doing that trick, but it's in the end a more cleaner way to export the profile and later re import it again. But exporting a profile by TB directly isn't still full featured. As long as nobody is digging into this we will need to live with the symlinked folder. -- Regards Carsten
Bug#950941: see also #990807
see also #990807
Bug#990807: thunderbird incapable to run only with ~/.thunderbird that was migrated from icedove
Package: thunderbird Version: 1:78.11.0-2 Severity: normal X-Debbugs-Cc: Carsten Schoenert , Paul Menzel I'd like to describe my problem, which is related to #950941. I have copyied over ~/thunderbird from my old laptop. Now when I start thunderbird, it start's normally. However at next start it will fail and complain and tell me that I should resolve the situation. Why? Because on first start, the second layer of wrappers will apparently make a **copy** of ~/.thunderbird to ~/.icedove. And on the second start the first layer wrapper will see: $ ls -l .thunderbird/ .icedove/ -d drwx-- 3 me mi 4096 7. Jul 22:24 .icedove/ drwx-- 5 me mi 4096 2. Jul 21:57 .thunderbird/ and ... fail. So I've tried to find out. Took me now over 1.5 hours and I still haven't found out because... well it's complex. And even with the whole complexity the wrapper is still not able to handle (in the sense of behaving like thunderbird itself would in the same situation) the situation. So I'd suggest something in the vein of: $ cat /usr/bin/thunderbird #!/bin/bash if [ "$SKIP_THUNDERBIRD_WRAPPER" != "" ]; then /usr/lib/thunderbird/thunderbird "$@"; fi But then again one could simply do: alias thunderbird=/usr/lib/thunderbird/thunderbird (the path /usr/lib/thunderbird/thunderbird not being trivial to find...). Or maybe [also] document that... Yet another alternative is to use upstream? What do you think? Greetings and thanks! *t -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libatk1.0-0 2.36.0-2 ii libbotan-2-172.17.3+dfsg-2 ii libbz2-1.0 1.0.8-4 ii libc62.31-12 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-2 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4 ii libicu67 67.1-6 ii libjson-c5 0.15-2 ii libnspr4 2:4.29-1 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.1-1 ii libx11-xcb1 2:1.7.1-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxext6 2:1.3.3-1.1 ii libxrender1 1:0.9.10-1 ii psmisc 23.4-2 ii x11-utils7.7+5 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages thunderbird recommends: ii hunspell-de-de [hunspell-dictionary] 20161207-9 ii hunspell-en-us [hunspell-dictionary] 1:2019.10.06-1 Versions of packages thunderbird suggests: ii apparmor 2.13.6-10 pn fonts-lyx ii libgssapi-krb5-2 1.18.3-5 ii libgtk2.0-0 2.24.33-2 -- no debconf information
Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1
reassign 990411 linux-image-5.10.0-7-amd64 - Thanks Michael, reassigning as proposed. Though I'm wondering (and not finding) whether there would be a more general package to assign this ticket to (such as linux-image-5.x or something). Any thoughts on this problem in the security or the kernel team? Thanks and greets to all of you! *t On Mon, 28 Jun 2021, Michael Biebl wrote: Am 28.06.21 um 14:52 schrieb Tomas Pospisek: Package: systemd Version: 247.3-5 Severity: wishlist Tags: security X-Debbugs-Cc: Debian Security Team Hi, TLDR: $ sudo sysctl kernel.unprivileged_bpf_disabled kernel.unprivileged_bpf_disabled = 0 please disable unprivileged BPF by default, it seems that it is not safe to be allowed by default in the general case. I'm not sure if systemd is the right place to report this security/wishlist ticket against. I've chosen systemd because it ships `/etc/sysctl.d/99-sysctl.conf` which seems to me to be the nearest fit to where `kernel.unprivileged_bpf_disabled` should be set. Please reassign if there's a better package to stick this report to. /etc/sysctl.d/99-sysctl.conf is just a symlink pointing at 99-sysctl.conf -> ../sysctl.conf $ dpkg -S /etc/sysctl.conf procps: /etc/sysctl.conf tbh, I'd prefer the security oder kernel team to make that judgement call.
Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1
Package: systemd Version: 247.3-5 Severity: wishlist Tags: security X-Debbugs-Cc: Debian Security Team Hi, TLDR: $ sudo sysctl kernel.unprivileged_bpf_disabled kernel.unprivileged_bpf_disabled = 0 please disable unprivileged BPF by default, it seems that it is not safe to be allowed by default in the general case. I'm not sure if systemd is the right place to report this security/wishlist ticket against. I've chosen systemd because it ships `/etc/sysctl.d/99-sysctl.conf` which seems to me to be the nearest fit to where `kernel.unprivileged_bpf_disabled` should be set. Please reassign if there's a better package to stick this report to. After reading https://lwn.net/Articles/860597/ I'm under the impression that allowing unprivileged BPF is too big of a barn door to leave open at these times. Currently * I have no idea which packages that I install use or will use BPF * I don't know how I could even find out * even if I knew that a given program *does* use BPF, I estimate that it'd require me a non-trivial effort to analyze how security critical that fact is in my context * considering myself quite a seasoned sysadmin I very much doubt that the general Debian consumer is even remotely capable of correctly assesing the preceeding points Therefore I'd suggest to seriously consider to disable the unprivileged BPF gun *by default* on freshly installed Debian systems. Thanks a lot for taking care of Debian! *t -- Package-specific info: -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-10 ii libapparmor1 2.13.6-10 ii libaudit11:3.0-2 ii libblkid12.36.1-7 ii libc62.31-12 ii libcap2 1:2.44-1 ii libcrypt11:4.4.18-4 ii libcryptsetup12 2:2.3.5-1 ii libgcrypt20 1.8.7-3 ii libgnutls30 3.7.1-3 ii libgpg-error01.38-2 ii libip4tc21.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libmount12.36.1-7 ii libpam0g 1.4.0-7 ii libseccomp2 2.5.1-1 ii libselinux1 3.1-3 ii libsystemd0 247.3-5 ii libzstd1 1.4.8+dfsg-2.1 ii mount2.36.1-7 ii systemd-timesyncd [time-daemon] 247.3-5 ii util-linux 2.36.1-7 Versions of packages systemd recommends: ii dbus 1.12.20-2 Versions of packages systemd suggests: ii policykit-10.105-31 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 ii libnss-systemd 247.3-5 ii libpam-systemd 247.3-5 ii udev 247.3-5 -- no debconf information
Bug#989943: maybe use at instead of shutdown -r $TIME
Argh, that should of course be:
--- /usr/bin/unattended-upgrade.orig2021-06-18 09:46:37.434386824 +0200
+++ /usr/bin/unattended-upgrade 2021-06-18 09:47:03.958639111 +0200
@@ -1353,11 +1353,12 @@
when = apt_pkg.config.find(
"Unattended-Upgrade::Automatic-Reboot-Time", "now")
logging.warning("Found %s, rebooting" % REBOOT_REQUIRED_FILE)
-cmd = ["/sbin/shutdown", "-r", when]
+cmd = ["/usr/bin/at", when]
try:
-shutdown_msg = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
-if shutdown_msg.strip():
-logging.warning("Shutdown msg: %s", shutdown_msg.strip())
+p = subprocess.Popen(cmd, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+p_out = p.communicate(input=b'shutdown -r
now\n')[0].decode('utf-8').strip()
+if p_out:
+logging.warning("Shutdown msg: %s", p_out)
except Exception as e:
logging.error("Failed to issue shutdown: %s", e)
(s/shutdown -h/shutdown -r/)
As always: feedback appreciated
Thanks & greetings,
*t
Bug#989943: maybe use at instead of shutdown -r $TIME
On Thu, 17 Jun 2021, Tomas Pospisek wrote:
With respect to "unattended-upgrades blocking other cron.daily scripts via
shutdown -r" I reflected:
Now what would a "correct" or "better" behavior be?
I suggest to trigger an asynchronous shutdown, that is *not*
to wait for `shutdown -r $TIME` to come back so that whatever
daily menial taks are scheduled via /etc/cron.daily are able
to be executed.
What about the idea of using
echo "shutdown -r now" | at $TIME
instead of directly calling
shutdown -r now
Pro:
* async execution. unattended-update can finish it's stuff and
the rest of cron.daily finishes correctly
* consoles won't be flooded with repeat "Systeme will be going
doing in XX hours"
Con:
* does care have to be taken that unattended-upgrade won't re-run
while it wants the system to reboot?
* behavior change (this should be triggering a major semver change...)
* this could be worked around with yet another config option
(UseAtInstead=True)
* users on the system won't be warned of the system going down in
XX hours
What do you think?
The idea in code:
--- /usr/bin/unattended-upgrade.orig2021-06-18 09:46:37.434386824
+0200
+++ /usr/bin/unattended-upgrade 2021-06-18 09:47:03.958639111 +0200
@@ -1353,11 +1353,12 @@
when = apt_pkg.config.find(
"Unattended-Upgrade::Automatic-Reboot-Time", "now")
logging.warning("Found %s, rebooting" % REBOOT_REQUIRED_FILE)
-cmd = ["/sbin/shutdown", "-r", when]
+cmd = ["/usr/bin/at", when]
try:
-shutdown_msg = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
-if shutdown_msg.strip():
-logging.warning("Shutdown msg: %s", shutdown_msg.strip())
+p = subprocess.Popen(cmd, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+p_out = p.communicate(input=b'shutdown -h
now\n')[0].decode('utf-8').strip()
+if p_out:
+logging.warning("Shutdown msg: %s", p_out)
except Exception as e:
logging.error("Failed to issue shutdown: %s", e)
Feedback about whether this is a good idea is appreciated.
Thanks & greetings,
*t
Bug#989794: please pull improvement via Salsa
https://salsa.debian.org/debian/debianutils/-/merge_requests/8
Bug#243676: any reason not to add --debug flag?
Hi Clint, here's the corresponding pull request: https://salsa.debian.org/debian/debianutils/-/merge_requests/7 please pull :-) ! Thanks! *t On Mon, 14 Jun 2021, Tomas Pospisek wrote: Hello Clint! On Sun, 13 Jun 2021, Clint Adams wrote: On Sun, Jun 13, 2021 at 11:46:31AM +0200, Tomas Pospisek wrote: thanks for maintaining debianutils. Is there any reason Christoph Biedl's patch to add a --debug flag doesn't get applied? It does look like being useful? I have no memory of ever seeing this before, but I have pushed it and the newline fix to master. Thanks a lot! A man page update would be good; maybe I will remember to do that when I have time. Here's the manpage update: $ git diff run-parts.8 diff --git run-parts.8 run-parts.8 index bb8c2a1..cadbe58 100644 --- run-parts.8 +++ run-parts.8 @@ -11,7 +11,7 @@ run\-parts \- run scripts or programs in a directory .SH SYNOPSIS .PP .B run\-parts -[\-\-test] [\-\-verbose] [\-\-report] [\-\-lsbsysinit] [\-\-regex=RE] +[\-\-test] [\-\-verbose] [\-\-debug] [\-\-report] [\-\-lsbsysinit] [\-\-regex=RE] [\-\-umask=umask] [\-\-arg=argument] [\-\-exit\-on\-error] [\-\-help] [\-\-version] [\-\-list] [\-\-reverse] [\-\-] DIRECTORY .PP @@ -58,6 +58,9 @@ This option cannot be used with \-\-test. .B \-v, \-\-verbose print the name of each script to stderr before running. .TP +.B \-d, \-\-debug +print to stderr which scripts get selected for running and which don't. +.TP .B \-\-report similar to .BR \-\-verbose ,
Bug#989943: maybe use at instead of shutdown -r $TIME
With respect to "unattended-upgrades blocking other cron.daily scripts via shutdown -r" I reflected: Now what would a "correct" or "better" behavior be? I suggest to trigger an asynchronous shutdown, that is *not* to wait for `shutdown -r $TIME` to come back so that whatever daily menial taks are scheduled via /etc/cron.daily are able to be executed. What about the idea of using echo "shutdown -r now" | at $TIME instead of directly calling shutdown -r now Pro: * async execution. unattended-update can finish it's stuff and the rest of cron.daily finishes correctly * consoles won't be flooded with repeat "Systeme will be going doing in XX hours" Con: * does care have to be taken that unattended-upgrade won't re-run while it wants the system to reboot? * behavior change (this should be triggering a major semver change...) * this could be worked around with yet another config option (UseAtInstead=True) * users on the system won't be warned of the system going down in XX hours What do you think? *t
Bug#989943: unattended-upgrades blocking other cron.daily scripts or "'invoke-rc.d rsyslog rotate' called during shutdown sequence."
Package: unattended-upgrades Version: 1.11.2 Severity: normal Hi! There are several systems where I get Date: Tue, 15 Jun 2021 06:00:17 +0200 From: Cron Daemon Subject: Cron test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) /etc/cron.daily/logrotate: invoke-rc.d: - invoke-rc.d: WARNING: 'invoke-rc.d rsyslog rotate' called invoke-rc.d: during shutdown sequence. invoke-rc.d: enabling safe mode: initscript policy layer disabled invoke-rc.d: - whenever unattended-upgrades needs to reboot. *Before* the reboot the system looks like this: root 835 0.0 0.0 8504 2336 ?Ss Jun15 0:00 /usr/sbin/cron root 12595 0.0 0.0 9120 2316 ?S06:25 0:00 \_ /usr/sbin/CRON root 12596 0.0 0.0 2388 700 ?Ss 06:25 0:00 \_ /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) root 12597 0.0 0.0 2284 688 ?S06:25 0:00 \_ run-parts --report /etc/cron.daily root 12598 0.0 0.0 2388 764 ?S06:25 0:00 \_ /bin/sh /usr/lib/apt/apt.systemd.daily root 12733 0.0 0.0 2388 1488 ?S06:41 0:00 \_ /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held root 13047 0.0 0.2 123308 34548 ?Sl 06:41 0:00 \_ /usr/bin/python3 /usr/bin/unattended-upgrade root 13057 0.0 0.0 2372 1752 ?S06:41 0:00 \_ /sbin/shutdown -r 06:00 In human language: this morning at 06:25 cron.daily ran, which triggered unattended-upgrades, which triggered `/sbin/shutdown -r 06:00`. Now one problem here is that `/sbin/shutdown -r 06:00` is actually blocking. It will *not* exit, but instead will count waiting time to zero and reboot after. We are on a system with `sysv-rc` and not `systemd`. I have *not* verified whether `shutdown -r $TIME` behavior is identical on a `systemd` system. The system apparently shut down at: # cat /var/log/messages Jun 15 06:00:14 dom shutdown[13634]: shutting down for system reboot also # cat /var/log/daemon.log Jun 15 06:00:15 dom init: Switching to runlevel: 6 also # last -F reboot system boot 4.19.0-16-amd64 Tue Jun 15 06:00:28 2021 - Wed Jun 16 10:34:57 2021 (1+04:34) So my interpretation is this: 1. cron.daily runs 2. it executes unattended-upgrade 3. unattended-upgrade blocks when it calls shutdown -r 06:00 4. in our case that stops the other cron.daily tasks that are sorted after /etc/cron.daily/apt-compat (that is pretty much all others since apt-compat is first in the alphabet) from running 5. the clock hits 06:00:00 and shutdown exits (this is my guess - I think it's the same behavior as with `shutdown -r now` which also exits and so you sometimes see/get back to the prompt before the sytstem *actually* warm reboots) 6. after `shutdown -r 06:00` exits unattended-upgrade finishes whatever it was doing, exits and cron.daily continues with the execution with the other scripts in /etc/cron.daily/ that alphabetically follow apt-compat, which makes a mess, because we're actually in runlevel 6/shutdown now. which triggers the warning we saw above from logrotate/cron. Now what would a "correct" or "better" behavior be? I suggest to trigger an asynchronous shutdown, that is *not* to wait for `shutdown -r $TIME` to come back so that whatever daily menial taks are scheduled via /etc/cron.daily are able to be executed. In other words: fork & exec shutdown... ? Thanks a lot for maintaining unattended-upgrades Greetings, *t -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages unattended-upgrades depends on: ii debconf [debconf-2.0] 1.5.71 ii lsb-base 10.2019051400 ii lsb-release10.2019051400 ii python33.7.3-1 ii python3-apt1.8.4.3 ii python3-dbus 1.2.8-3 ii python3-distro-info0.21 ii ucf3.0038+nmu1 ii xz-utils 5.2.4-1 Versions of packages unattended-upgrades recommends: ii cron [cron-daemon] 3.0pl1-134+deb10u1 Versions of packages unattended-upgrades suggests: ii bsd-mailx 8.1.2-0.20180807cvs-1 pn needrestart ii nullmailer [mail-transport-agent] 1:2.2-3 pn powermgmt-base ii python3-gi 3.30.4-1 -- debconf information: *
Bug#243676: any reason not to add --debug flag?
Hello Clint! On Sun, 13 Jun 2021, Clint Adams wrote: On Sun, Jun 13, 2021 at 11:46:31AM +0200, Tomas Pospisek wrote: thanks for maintaining debianutils. Is there any reason Christoph Biedl's patch to add a --debug flag doesn't get applied? It does look like being useful? I have no memory of ever seeing this before, but I have pushed it and the newline fix to master. Thanks a lot! A man page update would be good; maybe I will remember to do that when I have time. Here's the manpage update: $ git diff run-parts.8 diff --git run-parts.8 run-parts.8 index bb8c2a1..cadbe58 100644 --- run-parts.8 +++ run-parts.8 @@ -11,7 +11,7 @@ run\-parts \- run scripts or programs in a directory .SH SYNOPSIS .PP .B run\-parts -[\-\-test] [\-\-verbose] [\-\-report] [\-\-lsbsysinit] [\-\-regex=RE] +[\-\-test] [\-\-verbose] [\-\-debug] [\-\-report] [\-\-lsbsysinit] [\-\-regex=RE] [\-\-umask=umask] [\-\-arg=argument] [\-\-exit\-on\-error] [\-\-help] [\-\-version] [\-\-list] [\-\-reverse] [\-\-] DIRECTORY .PP @@ -58,6 +58,9 @@ This option cannot be used with \-\-test. .B \-v, \-\-verbose print the name of each script to stderr before running. .TP +.B \-d, \-\-debug +print to stderr which scripts get selected for running and which don't. +.TP .B \-\-report similar to .BR \-\-verbose ,
Bug#989794: please mention that run-parts executes files sequentially
Package: debianutils Version: 4.11.2 Severity: wishlist Tags: patch See attached patch Thanks for maintaining debuanutils! *t -- System Information: Debian Release: 10.9 APT prefers stable APT policy: (503, 'stable'), (501, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debianutils depends on: ii libc6 2.28-10 debianutils recommends no packages. debianutils suggests no packages. -- no debconf information --- run-parts.8 2021-06-13 11:53:21.513440149 +0200 +++ run-parts.8 2020-08-19 15:11:17.0 +0200 @@ -39,10 +39,10 @@ If the \-\-regex option is given, the names must match the custom extended regular expression specified as that option's argument. -Files are run sequentially, one after the other, in the lexical sort -order (according to the C/POSIX locale character collation rules) of -their names unless the \-\-reverse option is given, in which case -they are run in the opposite order. +Files are run in the lexical sort order (according to the C/POSIX +locale character collation rules) of their names unless the +\-\-reverse option is given, in which case they are run in the +opposite order. .SH OPTIONS .TP
Bug#989793: please mention that run-parts executes files sequentially
Package: debianutils Version: 4.11.2 Severity: wishlist Tags: patch -- System Information: Debian Release: 10.9 APT prefers stable APT policy: (503, 'stable'), (501, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debianutils depends on: ii libc6 2.28-10 debianutils recommends no packages. debianutils suggests no packages. -- no debconf information --- run-parts.8.new 2021-06-13 11:53:21.513440149 +0200 +++ run-parts.8 2020-08-19 15:11:17.0 +0200 @@ -39,10 +39,10 @@ If the \-\-regex option is given, the names must match the custom extended regular expression specified as that option's argument. -Files are run sequentially, one after the other, in the lexical sort -order (according to the C/POSIX locale character collation rules) of -their names unless the \-\-reverse option is given, in which case -they are run in the opposite order. +Files are run in the lexical sort order (according to the C/POSIX +locale character collation rules) of their names unless the +\-\-reverse option is given, in which case they are run in the +opposite order. .SH OPTIONS .TP
Bug#243676: any reason not to add --debug flag?
Hi, thanks for maintaining debianutils. Is there any reason Christoph Biedl's patch to add a --debug flag doesn't get applied? It does look like being useful? ? Greetings & thanks, *t
Bug#711054: closed by j...@debian.org (Closing this bug)
Danke für die Triage Moritz! *t On Sat, 24 Apr 2021, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:linux package: #711054: synaptics touchpad becomes unusable under load It has been closed by j...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact j...@debian.org by replying to this email. -- 711054: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711054 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#987335: ITP: dpa-ext-gnomekeyring -- GNOME keyring extension for dde-polkit-agent
On 22.04.21 04:04, clay stan wrote: Package: wnpp Severity: wishlist Owner: clay stan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dpa-ext-gnomekeyring Version : 5.0.4 Upstream Author : linuxdeepin * URL : https://github.com/linuxdeepin/dpa-ext-gnomekeyring License : GPL-3+ Same here, oh please add a description, such as (I'm guessing here): This extension makes it possible to access the GNOME keyring from Deepin applications.
Bug#987336: ITP: dtkcommon -- dtk common files
On 22.04.21 05:21, clay stan wrote: Package: wnpp Severity: wishlist Owner: clay stan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dtkcommon Version : 5.5.2 Upstream Author : linuxdeepin * URL : https://github.com/linuxdeepin/dtkcommon License : GPL-3+ Please add a description what this package is good for/contains and/or respectively what "dtk" is. Thanks & Greetings, *t
Bug#986506: The released version of debian-installer still has the old kernel
I had checked that my installer had 5.10.0 and if your assessement is right then my installer must have been a daily build. Thanks a lot Roland for keeping the finger on this issue! *t On Wed, 14 Apr 2021, Roland Clobus wrote: reopen 986506 thanks On 14/04/2021 08:58, Tomas Pospisek wrote: debian-installer now has 5.10.0-5 kernel ... thus I'm closing the bug report Hello Tomas, I think this bug report is closed a little too early. I've seen in the git commit cb6b94900c27495ed58b698fb8a4d4e00d0962b1 that the kernel version even has been bumped to 5.10.0-6, but only for the *daily builds*. The *released version* of the debian-installer still is 20201202 [1]. This is the version that is used per default by the live-build tool, which downloads from the regular location [2]. I known that the final deadline for releasing Debian 11 is getting real close, so I'm not sure whether you should be burdened by creating intermediate releases. With kind regards, Roland Clobus [1] https://packages.debian.org/bullseye/debian-installer [2] http://deb.debian.org/debian/dists/bullseye/main/installer-amd64/current
Bug#740499: why doesn't d-i include firmware-b43-installer and firmware-b43legacy-installer?
In #740499 Chris Bainbridge writes that: [...] but firmware-7.4.0-amd64-netinst.iso does not contain Broadcom firmware (at least not b43). I can see that there are firmware packages for Broadcom b43 in contrib: https://packages.debian.org/search?suite=bullseye=all=any=names=firmware-b Could anybody in the known comment why those firmware packages are not included in the non-free installer images? Is there anything preventing their inclusion? Or asked in a different way: could they be included so the Debian installer supports the users with that hardware? Thanks, *t
Bug#934383: Package fails attempting to access [Panda PAU06 Wifi dongle, RT5372, USB WiFi rt2800us]
Hi William, if you still have access to the hardware it would be nice if you could test whether the coming Debian bullseye installer still fails with it - I assume this should have been fixed in the meanwhile - so this bug report could be closed? Thanks, *t
Bug#985164: 403 Forbidden
> My IP address has changed and I have no record of the previous one (VPN). So there's not much Debian can do I guess and thus I close this report. *t On 14.03.21 14:13, Scott C. MacCallum wrote: My IP address has changed and I have no record of the previous one (VPN). Original Message On Mar 14, 2021, 8:02 AM, Tomas Pospisek < t...@sourcepole.ch> wrote: Hi Scott, On 13.03.21 22:28, Scott C. MacCallum wrote: > Package: www.debian.org <http://www.debian.org> > URL: https://wiki.debian.org/UnattendedUpgrades <https://wiki.debian.org/UnattendedUpgrades> > > Forbidden > > You are not allowed to access this! On the other hand I *am* allowed to access it. So there must be something that's different between me and you. I guess it's the IP address. What's yours? Could you please add your IP address to the bug report? *t
Bug#985164: 403 Forbidden
Hi Scott, On 13.03.21 22:28, Scott C. MacCallum wrote: Package: www.debian.org URL: https://wiki.debian.org/UnattendedUpgrades Forbidden You are not allowed to access this! On the other hand I *am* allowed to access it. So there must be something that's different between me and you. I guess it's the IP address. What's yours? Could you please add your IP address to the bug report? *t
Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron
On Fri, 26 Feb 2021, Javier Fernandez-Sanguino wrote: El jue., 25 feb. 2021 12:52, Tomas Pospisek escribió: Javier, seeing that you do not seem to have been working on cron for a few years would it be OK with you if I posted something along these lines to debian-devel: I can send a message along the lines of your proposal below to d-d. Will schedule it to do it soon. https://bugs.debian.org/984736 Thanks Javier! *t
Bug#983842: please add more specific description
:+1 ! Thank you! *t On Tue, 2 Mar 2021, Aloïs Micard wrote: Hello Tomas, As far as I can see "manage" is about as specific as the word "do": srcode lets you do "something" with your codebase. Now what is it **exactly** that srcode is offering? Could you please describe that both in the long as well as in the short description? Thanks for your constructive feedback! I agree that the description lacks of clarity, I'll take care of that in the package description & will update that upstream too. Thanks. Cheers, -- Aloïs Micard (creekorful) GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2
Bug#983842: please add more specific description
Hi Alois, you write: Package name: srcode Description : Tool that help developers to manage their codebase in an effective & productive way. srcode is a tool that help developers to manage their codebase in an effective & productive way. this description however is arguably not productive. What does "manage" mean exactly? * ext4 lets you manage your files in an effective & productive way * dpkg lets you manage your files in an effictive & productive way * vim lets you ... * and so on Based solely on that description, how do I, the user, browsing the Debian packages decide whether I want to install ext4, dpkg, vim or for the matter srcode? As far as I can see "manage" is about as specific as the word "do": srcode lets you do "something" with your codebase. Now what is it **exactly** that srcode is offering? Could you please describe that both in the long as well as in the short description? Thanks a lot! *t
Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron
:+1 thanks Javier! On Fri, 26 Feb 2021, Javier Fernandez-Sanguino wrote: Dear Tomas, El jue., 25 feb. 2021 12:52, Tomas Pospisek escribió: Javier, seeing that you do not seem to have been working on cron for a few years would it be OK with you if I posted something along these lines to debian-devel: I can send a message along the lines of your proposal below to d-d. Will schedule it to do it soon.
Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron
Javier, seeing that you do not seem to have been working on cron for a few years would it be OK with you if I posted something along these lines to debian-devel: Request for adoption/request for help: cron cron's recently active maintainer has removed himself from its uploaders. So there is currently no active maintainer of cron. It would be good if cron was actively maintaned. Helping hands or somebody taking the lead as a cron maintainer would be very welcome! signed: tpo with Javier's OK ? Thanks & greetings, *t On Tue, 23 Feb 2021, Christian Kastner wrote: On 2021-02-23 09:03, Tomas Pospisek wrote: On Mon, 22 Feb 2021, Christian Kastner wrote: Oh, this is news indeed. I think Javier hasn't been working on for the last 3 years [1]? So I'd say you Christian have been cron's defacto maintainer? While possibly so, I must note that effective with the last upload, I have removed myself from the Uploaders field, and therefore no longer am a cron maintainer. So if the plan to migrate Debian's cron to cronie has been abandoned (by you) and instead the plan is to drop cron and instead use systemd timers as the default "cron" mechanism in Debian then I think this defacto decision should be communicated clearly. The default "cron" mechanism in Debian will continue to be, well, cron. This is defined by the Debian Policy, and hence would need a Policy change, which almost certainly won't happen fast, and without discussion. The switch to systemd timers is just something that I have observed in practice. Packages shipping both timers and crontabs, with the latter being no-ops when systemd is detected. I, personally, believe that this is the right practice. The switch to cronie as default "cron" is indeed something that I possibly could have effected alone (as it doesn't require a Policy change), but recently abandoned. As you might have seen I have added some suggestions on how people could help with the migration from cron to cronie on cron's Debian wiki page [2]. If the plan to migrate to cronie has been abandoned then such initiatives do not make sense any more...? I think those suggestions are still spot on, and I believe migrating from cron to cronie is still the right thing to do. I'm just the wrong person for driving this :-) In the meantime, I have become fully occupied with other projects within Debian, and simply cannot drive this effort, or continue to be a maintainer at all. However, if anyone else wants to take over the effort, and I can help as a mentor and/or upload sponsor, feel free to do so. I have filed an RFA for cronie a while ago (#974038) and have received pings from some interested parties, but no results yet. My plans for cronie were probably too big anyway: instead of carrying over all of our features, perhaps it would be better to stick with standard "upstream" cronie instead, and to focus on making the switching process as easy as possible. If anyone wants to try this, feel free to contact me any time. Best, Christian [1] https://metadata.ftp-master.debian.org/changelogs//main/c/cron/cron_3.0pl1-137_changelog [2] https://wiki.debian.org/cron?action=diff=9=10<
Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron
On Mon, 22 Feb 2021, Christian Kastner wrote: On 21.02.21 15:46, Laurent Combe wrote: near 3 years i report this issue i joined a patch and after all that time nothing, not even a "confirmed" tag. very disappointing. What can I do to help this issue be accepted more quickly ? I can't speak for Javier, but in the meantime, I myself have mostly given up on cron, in the sense that I consider systemd timers a superior solution. Oh, this is news indeed. I think Javier hasn't been working on for the last 3 years [1]? So I'd say you Christian have been cron's defacto maintainer? So if the plan to migrate Debian's cron to cronie has been abandoned (by you) and instead the plan is to drop cron and instead use systemd timers as the default "cron" mechanism in Debian then I think this defacto decision should be communicated clearly. As you might have seen I have added some suggestions on how people could help with the migration from cron to cronie on cron's Debian wiki page [2]. If the plan to migrate to cronie has been abandoned then such initiatives do not make sense any more...? It'd be very nice if you Christian and Javier could clarify the situation. Greetings & thanks for your work on cron! *t [1] https://metadata.ftp-master.debian.org/changelogs//main/c/cron/cron_3.0pl1-137_changelog [2] https://wiki.debian.org/cron?action=diff=9=10
Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron
Greets all. I've added those suggestions to the cron wiki page (https://wiki.debian.org/cron) in the hope that people that would like to help to move cron in Debian move forward can jump in and do things that are possible and useful. I hope that's fine with you guys! *t On Mon, 22 Feb 2021, Tomas Pospisek wrote: Hi Laurent, let me start by saying the gentlemen above are probably working on cron in their free time. They do not owe anybody anything. So I think you can be disapointed, but saying so will probably not have a positive impact. Maybe it will on the contrary drain them. That said, thanks for your offer for help. I want to explore a bit how you (or I?) could help. After I've seen your email I visited the package page: https://packages.debian.org/search?keywords=cron and I've noticed, that the `cron` in experimental is in fact `cronie` (coming from RH/Fedora) which reminded that the plan was to replace cron in Debian with cronie, since cron is not maintained upstream any more. You can read about it here: https://wiki.debian.org/cron So I think the following things would be helpful: * port features that Debian's cron has, but cronie is missing from cron to cronie. Since both Debian's cron and cronie are forks of the original cron, the should be somewhat compatible. Also Debian cron has now split off its diff from the original cron into patches under debian/patches. So the theory would be that you can take one patch after the other, see what feature it implements and port it over to cronie. Once the port is done you could submit that patch upstream with the accompanying rationale that this feature is needed for Debian in order to be able to migrate to cronie. Also you could fork Debian's cronie repo and submin pull requests, so Debian can integrate the missing features into cronie. * you could install cronie on your systems and see what's missing or if its working how it should and submit error or success reports to the Samba repo (I guess). * you could go through cron's bugs page https://bugs.debian.org/cron and see which of those bugs is fixed in cronie and comment inside the bug. Maybe the maintainers would like to add a tag "implemented-in-cronie" or such, so that they can see at a glance, which bugs would be automatically closed by cronie. What do you think? *t On Sun, 21 Feb 2021, Laurent Combe wrote: near 3 years i report this issue i joined a patch and after all that time nothing, not even a "confirmed" tag. very disappointing. What can I do to help this issue be accepted more quickly ?
Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron
Hi Laurent, let me start by saying the gentlemen above are probably working on cron in their free time. They do not owe anybody anything. So I think you can be disapointed, but saying so will probably not have a positive impact. Maybe it will on the contrary drain them. That said, thanks for your offer for help. I want to explore a bit how you (or I?) could help. After I've seen your email I visited the package page: https://packages.debian.org/search?keywords=cron and I've noticed, that the `cron` in experimental is in fact `cronie` (coming from RH/Fedora) which reminded that the plan was to replace cron in Debian with cronie, since cron is not maintained upstream any more. You can read about it here: https://wiki.debian.org/cron So I think the following things would be helpful: * port features that Debian's cron has, but cronie is missing from cron to cronie. Since both Debian's cron and cronie are forks of the original cron, the should be somewhat compatible. Also Debian cron has now split off its diff from the original cron into patches under debian/patches. So the theory would be that you can take one patch after the other, see what feature it implements and port it over to cronie. Once the port is done you could submit that patch upstream with the accompanying rationale that this feature is needed for Debian in order to be able to migrate to cronie. Also you could fork Debian's cronie repo and submin pull requests, so Debian can integrate the missing features into cronie. * you could install cronie on your systems and see what's missing or if its working how it should and submit error or success reports to the Samba repo (I guess). * you could go through cron's bugs page https://bugs.debian.org/cron and see which of those bugs is fixed in cronie and comment inside the bug. Maybe the maintainers would like to add a tag "implemented-in-cronie" or such, so that they can see at a glance, which bugs would be automatically closed by cronie. What do you think? *t On Sun, 21 Feb 2021, Laurent Combe wrote: near 3 years i report this issue i joined a patch and after all that time nothing, not even a "confirmed" tag. very disappointing. What can I do to help this issue be accepted more quickly ?
Bug#983304: please document "Protected" field
Source: debian-policy Version: 4.5.1.0 Severity: wishlist In Julian Andres Klode's blog I've [1] glimpsed: > New features > [...] > The Protected field is now supported. It replaces the previous Important > field and is like Essential, but only for installed packages (some minor > more differences maybe in terms of ordering the installs). So I've tried to find out what the "Protected" field is for. The only info about it that I could find is from `man 1 dpkg`: > Protected packages contain mostly important system boot infrastructure. > Removing them might cause the whole system to be unable to boot, so use > with caution. That seems a bit vague and sparse. Is there maybe more rigid information for what *exactly* the "Protected" field should and will be used? Either way, if there's a new control field, then I think it should get documented in the `debian-policy`? Thanks, *t [1] https://blog.jak-linux.org/2021/02/18/apt-2.2/ -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#929959: cron: please support /etc/mailname
See also the related feature request/patch in bugs.debian.org/898177 i.e. allowing to set MAILFROM
Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron
Related feature request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929959 aka "please support /etc/mailname".
Bug#898177: please add MAILFROM to cron
Hi all, configuring a Debian system so that cron emails get correctly sent seems like *major rocket science*. There are innumerable postings on the internet wondering how to set up the system to receive cron's emails. I spent this whole morning trying to figure it out. A major problem is that cron is sending email as "root (Cron Daemon)". Of course many a MTA will - IMO correctly - refuse an email with such a sender. One can try to set /etc/mailname as is suggested in many places on the internet, but Debian's cron will ignore that setting... So the local sendmail needs to come to the rescue and start replacing and correcting the sender (and the recipient) that cron gives them with something that makes sense for the receiving end. Unless the local MTA is not feature richt enough to be able to do it, such as my local sendmail which is msmtp, but other small local sendmails have similar pains (nullmailer, dragonmailer, etc. - I did not check them all) and so still, mails from cron end up in /dev/null. Unless it *would* be possible to correctly set the sender (MAILTO) and the receiver (MAILFROM) in cron itself. Which actually many cron daemons are capable of. And which is the advice in many a helpful HOWTOs and stackoverflow answers ... except that Debian's cron doesn't support MAILFROM. Until now that is. Maybe. I hope. So that was the long rant and rationale and the plea to please allow to set MAILFROM in Debian's cron. I think Laurent Combe's patch fixes that nicely (it's missing the mailfrom variable declaration, but that's fixed below). So without more ado, please, please, pretty please add MAILFROM to cron. The attached patch should do. I am successfully running cron with that patch here. You should only need to tweak the changelog entry Christian and that should be it. Thanks a lot for keeping cron going Christian, and Javier in the past and Laurent for the patch and cronie for blasting the path. Greetings, *tdiff -u -r --new-file cron_3.0pl1-136.debian/changelog cron_3.0pl1-136.1.debian/changelog --- cron-3.0pl1/debian/changelog 2020-02-10 20:16:06.0 +0100 +++ cron-3.0pl1/debian/changelog 2021-02-16 11:28:04.0 +0100 @@ -1,3 +1,12 @@ +cron (3.0pl1-136.1) unstable; urgency=medium + + * allow to set MAILFROM +* patch from Laurent Combe , thank you! +* inspired by cronie +* Closes: #898177 + + -- Tomas Pospisek Tue, 16 Feb 2021 11:28:04 +0100 + cron (3.0pl1-136) unstable; urgency=medium * Convert package to source format 3.0 (quilt). Finally. diff -u -r --new-file cron_3.0pl1-136.debian/patches/features/Add-MAILFROM-environment-variable.patch cron_3.0pl1-136.1.debian/patches/features/Add-MAILFROM-environment-variable.patch --- cron-3.0pl1/debian/patches/features/Add-MAILFROM-environment-variable.patch 1970-01-01 01:00:00.0 +0100 +++ cron-3.0pl1/debian/patches/features/Add-MAILFROM-environment-variable.patch 2021-02-16 11:28:04.0 +0100 @@ -0,0 +1,91 @@ +Description: use MAILFROM environment variable if set + This patch lets cron use the MAILFROM variable to set the sender + as which it will send emails. MAILFROM has the same semantics as + the same environment variabl in cronie. + . + The patch has been written by Laurent Combe + and has been inspired by the same feature in cronie. + +Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898177 +Bug: +Bug-Debian: https://bugs.debian.org/898177 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1750051 +Last-Update: 2021-02-16 + +--- cron-3.0pl1.orig/cron.8 cron-3.0pl1/cron.8 +@@ -123,7 +123,9 @@ then wakes up every minute, examining al + each command to see if it should be run in the current minute. When + executing commands, any output is mailed to the owner of the crontab + (or to the user named in the MAILTO environment variable in the +-crontab, if such exists). The children copies of cron running these ++crontab, if such exists) as the owner of the crontab (or from the email ++address given in the MAILFROM environment variable in the crontab, if ++such exists). The children copies of cron running these + processes have their name coerced to uppercase, as will be seen in the + syslog and ps output. + .PP +--- cron-3.0pl1.orig/crontab.5 cron-3.0pl1/crontab.5 +@@ -100,12 +100,16 @@ on these systems, USER will be set also. + .PP + In addition to LOGNAME, HOME, and SHELL, + .IR cron (8) +-will look at MAILTO if it has any reason to send mail as a result of running +-commands in ``this'' crontab. If MAILTO is defined (and non-empty), mail is +-sent to the user so named. MAILTO may also be used to direct mail to multiple +-recipients by separating recipient users with a comma. If MAILTO is defined +-but empty (MAILTO=""), no mail will be sent. Otherwise mail is sent to the +-owner of the crontab. ++will look at MAILTO and MAILFROM if it has any reason to send mail as a result ++of running commands in ``t
Bug#975695: please allow to use UUIDs for "paste numbers"
Cool, thanks (-: <3 ! *t On Mon, 8 Feb 2021, Patrick Matthäi wrote: Hi Am 25.11.20 um 09:54 schrieb Tomas Pospisek: Source: pnopaste Version: 1.7.4 Severity: wishlist Having "pastes" with monotonically increasing numbers allows an "attacker" to discover all pastes by simply counting through them from 0 on. Assigning UUIDs to pastes would make that computationally impossible. Something like http://nopaste.linux-dev.org/?jA7vBQ8927 or such. *t first thanks for your other patch. I support this idea and I will implement it with the next release, which also gets backports then. But first I have release and uploaded today version 1.8 with a small adjustment for pnopaste-cli, so that this client supports in the future also UUID paste numbers.
Bug#694101: closed by Bernhard Schmidt (Closing bugs opened for old Gtk client)
Thanks a lot Bernhard that makes sense! *t On Fri, 15 Jan 2021, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the linphone package: #694101: immediate segfault without config file It has been closed by Bernhard Schmidt . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Bernhard Schmidt by replying to this email. -- 694101: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694101 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#979464: ITP: qbrz -- Qt frontend for breezy
On 06.01.21 23:42, Jelmer Vernooij wrote: Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org, breezy-c...@googlegroups.com * Package name: qbrz Version : 0.1 Upstream Author : RJL situp and qbzr authors * URL : https://launchpad.net/qbrz * License : GPL Programming Lang: PYthon Description : Qt frontend for breezy QBrz is a cross platform, Qt-based front-end for Breezy, providing GUI applications for many core breezy commands. In addition, it provides several special dialogs and helper commands. Equivalents for core breezy commands have the same names as CLI commands but with a prefix of "q". Could you please add some info to the description on what Breezy is? (The Debian breezy release? I have no idea)
Bug#973848: security update of chromium in Debian stable?
On Mon, 28 Dec 2020, Jan Luca Naumann wrote: I have got a successful buster build half an hour ago :) Yay! As soon as [1] is fixed or at least worked around (so we do not release a version with a regression), I think we could do the update. Do you have your build available anywhere? Because maybe I or passers by could then install your build and help testing whatever workaround comes out of [1]? I will contact the security team now to discuss the update. +1 !!! Thanks a lot! *t [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977870 Am 28.12.20 um 12:37 schrieb Tomas Pospisek: Hi Jan Luca, are you working on or respectively are you planing to do the stable build? (I am not sure if I would be able to get access to a powerful enough machine to do the build and get up to speed within reasonable time on how to build chromium and on how to do it efficiently so that I do not have to wait 24 hours for the build to proceed and fail again before I apply the next fix...?) Greetings! *t
Bug#973848: security update of chromium in Debian stable?
Hi Jan Luca, are you working on or respectively are you planing to do the stable build? (I am not sure if I would be able to get access to a powerful enough machine to do the build and get up to speed within reasonable time on how to build chromium and on how to do it efficiently so that I do not have to wait 24 hours for the build to proceed and fail again before I apply the next fix...?) Greetings! *t
Bug#973848: security update of chromium in Debian stable?
It seems like Linux Mint was able to build Chromium v87 for "debbie": http://packages.linuxmint.com/search.php?release=any=any=chromium which is as far as I understand based on Debian buster. So I am *assuming* they have somehow resolved the "SFINAE" problem? All this is just slightly informed guessing since in truth I do not understand a thing about how Linux Mint is building stuff... ? *t On Wed, 23 Dec 2020, Jan Luca Naumann wrote: Hey, parallel to Michel's very nice work to get chromium into unstable (thanks to him!), I tried to build the current version in a buster chroot. At the moment I struggle that there seems a difference how SFINAE[1] in a special case [2] is handled different between buster's and unstable's clang version. Since I had not so much time I have not found a fix to work around this. If people are more experienced with C++ templates than me, I would be happy to share the problem and the build log ;) Best, Jan [1] https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error [2] In file included from ../../third_party/blink/common/privacy_budget/identifiability_metric_builder.cc:5: In file included from ../../third_party/blink/public/common/privacy_budget/identifiability_metric_builder.h:9: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/vector:60: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algobase.h:64: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_pair.h:59: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/move.h:55: /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/type_traits:2046:15: error: only enumeration types have underlying types typedef __underlying_type(_Tp) type; ^ ../../third_party/blink/public/common/privacy_budget/identifiable_token.h:121:40: note: in instantiation of template class 'std::underlying_type >' requested here typename U = typename std::underlying_type::type, Am 23.12.20 um 12:13 schrieb Tomas Pospisek: Hi all, now that sid has seen an update of Chromium to v87 (hooray and thanks everybody!) does anybody know it there's activity or plans towards updating chromium in Debian stable? Chromium from sid is not installable in Debian stable due to Depends: libc6 (>= 2.29) whereas stable has 2.28. I'm not sure what the correct procedure would be to kickstart the Debian stable update? *t
Bug#973848: security update of chromium in Debian stable?
Hi all, now that sid has seen an update of Chromium to v87 (hooray and thanks everybody!) does anybody know it there's activity or plans towards updating chromium in Debian stable? Chromium from sid is not installable in Debian stable due to Depends: libc6 (>= 2.29) whereas stable has 2.28. I'm not sure what the correct procedure would be to kickstart the Debian stable update? *t
Bug#977367: debsources: search results point to not existing sources?
Package: qa.debian.org Severity: normal Go to https://codesearch.debian.net/search?q=Client+sent+an+HTTP+request+to+an+HTTPS+server select first link https://codesearch.debian.net/show?file=gcc-10_10.2.1-1%2Fgcc-10.2.0%2Flibgo%2Fgo%2Fnet%2Fhttp%2Fserver.go=1798 get a 404 with a list of 12 alternative source files of different versions of gcc-XX/XX.Y.Z-W/gcc-XX.V.U/libgo/go/net/http/server.go each returning a 404. I have now clicked through quite a few links to source files, but have yet to find one that won't return a 404...? Maybe the search index would need to be purged of source files that have disappeared (been updated) or something? Anyway, thanks a lot for the service, very, very appreciated and useful, *t -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores) Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#976162: closed by Sebastiaan Couwenberg (Re: Bug#976162: postgis v3.0.3 pdpg package for amd64 for Ubuntu focal missing)
Sebastiaan Couwenberg wrote on Mon, 30 Nov: On 11/30/20 7:56 PM, Tomas Pospisek wrote: There is no 3.0.3 package for postgis for focal on pdgd for amd64: The Debian BTS is not appropriate for this issue, use the pgsql-pkg-deb...@postgresql.org mailing list, or https://redmine.postgresql.org/projects/pgapt/issues instead. Ah, thanks. I was pointed to https://wiki.postgresql.org/wiki/Apt#Bugs and it reads there: Bugs Please report bugs: * on the pgsql-pkg-deb...@postgresql.org mailing list, or * open an issue in Redmine, or * open a bug in the Debian BTS. Which as you explained should probably read * open a bug in the Debian BTS only if it's a bug in a package released through Debian's own package repository. ? Thanks! *t
Bug#976162: postgis v3.0.3 pdpg package for amd64 for Ubuntu focal missing
Source: postgis Version: 3.0.3 Severity: normal There is no 3.0.3 package for postgis for focal on pdgd for amd64: http://apt.postgresql.org/pub/repos/apt/dists/focal-pgdg/main/binary-amd64/Packages Weirdly enough it apparently *was* built for non-Intel/AMD architectures but not for amd64: https://www.postgresql.org/message-id/E1khVKm-0005cE-Kc%40atalia.postgresql.org Note also that the line with focal and amd64 in it is apparently also missing the "source"? Thanks *a lot* <3 <3 <3! for building these *t -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores) Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#975695: please allow to use UUIDs for "paste numbers"
Source: pnopaste Version: 1.7.4 Severity: wishlist Having "pastes" with monotonically increasing numbers allows an "attacker" to discover all pastes by simply counting through them from 0 on. Assigning UUIDs to pastes would make that computationally impossible. Something like http://nopaste.linux-dev.org/?jA7vBQ8927 or such. *t -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores) Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#975632: please enable setting proxy via environment
Package: pnopaste-cli Version: 1.7-4 Severity: wishlist Tags: patch Hi Patrick, could you please enable proxy settings detection? After the line: my $Agent = LWP:UserAgent->new; add the line: $Agent->env_proxy; that's it. Now pnopaste-cli will recognize: http_proxy=... https_proxy=... Environment variables and use them correctly. Thanks a lot for pnopaste! *t -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores) Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pnopaste-cli depends on: ii libwww-perl 6.36-2 ii perl 5.28.1-6+deb10u1 pnopaste-cli recommends no packages. Versions of packages pnopaste-cli suggests: pn pnopaste
Bug#930543: workaround
The chromium-driver will apparently try to use /usr/bin/google-chrome *first*, no matter what. It even ignores the search $PATH. So if one does not intend to delete /usr/bin/google-chrome, then one work around is to binary patch /usr/bin/chromedriver: 1. install a binary editor, such as bvi 2. edit /usr/bin/chromedriver 3. find google-chrome in the binary 4. replace it with google-chromE *t
