Bug#1006287: Version older than that in the archive.
On Tue, Apr 26, 2022 at 07:21:10PM -0400, rapier wrote: > On 4/26/22 3:17 PM, Bastian Germann wrote: > > Am 26.04.22 um 21:04 schrieb rapier: > > > On 4/26/22 2:17 PM, Bastian Germann wrote: > > > > On Tue, 22 Feb 2022 15:24:48 -0500 rapier wrote: > > > > > hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium > > > > The Debian revision has to be -1 and the epoch (1:) has to be removed. > > > When you say the Debian revision needs to be -1 do you > > > mean making the 1:8.8p1-hpn16v1-9 into 8.8p1-hpn16v1-1 or something > > > else? Would that take care of the epoch as well? > > That version number is fine if the upstream version 8.8p1-hpn16v1 exists > > Epoch and revision are okay with 8.8p1-hpn16v1-1. > > > Bastian, Hello debian-ment...@lists.debian.org mailinglist, > I'm sorry to bother you. I've tried to upload a new version with the changes > you suggested but it was rejected. The error is > > Rejected: > hpnssh_8.8p1hpn16v1-1.dsc: Version older than that in the archive. > 8.8p1hpn16v1-1 <= 1:8.8p1-hpn16v1-8 } 0:8.8p1hpn16v1-1 <= 1:8.8p1-hpn16v1-8 > > hpnssh (8.8p1hpn16v1-1) impish; urgency=medium > > * Submission to Debian for impish. > * Refactor binary names to have hpn prefix > > Which is why my revision number hit 9 the first time. I'm not sure how to > resolve this aside from either deleting the existing PPA and starting over > or creating a new PPA. The "repository gate keeper software" rules "epoch+1" newer as "epoch". In this case 1:placeholder being newer as 0:placeholder. I miss, this email misses, where the repository is. PPA hits it is Ubuntu. I don't known if PPA allows removal what has been uploaded. So yes, deleting and starting over or a new PPA are a path to beyond the 'Version older than that in the archive'. > Do I have any other options? No, and no need for. You are learning that "epoch" is something to rarely use. "epoch" is an escape hatch to be used in Debian packaging when Upstream publishes a new release with an older version number. $ dpkg --compare-versions 3.3 ge 3.2 && echo no need for epoch || echo Chips no need for epoch $ dpkg --compare-versions 3.3 ge 3.4 && echo no need for epoch || echo Chips Chips $ > I really appreciate the time you are spending on this. Yes, b...@debian.org is doing good work. Do known that you are also doing good by all the stuff that you are learning. > Thanks again, Thank you for being curious AND persistent. > Chris Groeten Geert Stappers DD -- Silence is hard to parse signature.asc Description: PGP signature
Bug#1010245: xorg: X segfaults on xrandr --scale
Package: xorg Version: 1:7.7+23 Severity: normal X-Debbugs-Cc: spikethehobbitm...@runbox.com Xorg segfaults when running xrandr with a --scale that isn't 1.0. This is a dual monitor setup and the problem affects both monitors. Using --scale 1.0 works, but this is a no-op since that is the default scale. I'm not sure when the problem started since I don't use --scale very often, but it was within the last few months. Backtrace from /var/log/Xorg.0.log.old: [ 5208.172] (EE) [ 5208.172] (EE) Backtrace: [ 5208.172] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135) [0x557816adc345] [ 5208.173] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7fb222ebd200] [ 5208.173] (EE) 2: ? (?+0x0) [0x0] [ 5208.174] (EE) 3: ? (?+0x0) [0x0] [ 5208.174] (EE) [ 5208.174] (EE) Segmentation fault at address 0x0 [ 5208.174] (EE) Fatal server error: [ 5208.174] (EE) Caught signal 11 (Segmentation fault). Server aborting -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Apr 18 2009 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Feb 12 03:32 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tobago PRO [Radeon R7 360 / R9 360 OEM] [1002:665f] (rev 81) Xorg X server configuration file status: -rw-r--r-- 1 root root 602 Mar 23 2020 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- Section "Files" ModulePath "/usr/lib/xorg/modules/" EndSection Section "Module" Load"extmod" Load"dri" Load"drm" Load"glx" EndSection Section "Monitor" Identifier "monitor0" Option "PreferredMode" "1600x900" Option "Primary" "True" EndSection Section "Monitor" Identifier "monitor1" Option "RightOf" "monitor0" Option "PreferredMode" "1280x1024" EndSection Section "Device" Identifier "Radeon HD4870" Option "Monitor-DVI-0" "monitor0" Option "Monitor-DVI-1" "monitor1" Driver "radeon" # BusID "PCI:0:1:0:0" EndSection Section "DRI" Group "video" Mode0660 EndSection Contents of /etc/X11/xorg.conf.d: - total 0 KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 5.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-20) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 5.17.3-1 (2022-04-18) Xorg X server log files on system: -- -rw-r--r-- 1 root root 41242 Jun 25 2019 /var/log/Xorg.2.log -rw-r--r-- 1 root root 38978 Apr 26 22:17 /var/log/Xorg.1.log -rw-r--r-- 1 root root 45860 Apr 26 22:37 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - **snip** X automatically restarts after the crash so reportbug pulls the wrong file. See attached logfile for the backtrace. (/var/log/Xorg.0.log.old) udev information: - P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 E: SUBSYSTEM=input E: PRODUCT=19/0/1/0 E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PROP=0 E: EV=3 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: USEC_INITIALIZED=8298004 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: TAGS=:seat: E: CURRENT_TAGS=:seat: P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event4 N: input/event4 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event4 E: SUBSYSTEM=input E: DEVNAME=/dev/input/event4 E: MAJOR=13 E: MINOR=68 E: USEC_INITIALIZED=8447928 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: XKBMODEL=pc101 E: XKBLAYOUT=us E: XKBOPTIONS=terminate:ctrl_alt_bksp E: BACKSPACE=guess E: LIBINPUT_DEVICE_GROUP=19/0/1:LNXPWRBN/button E: TAGS=:power-switch: E: CURRENT_TAGS=:power-switch: P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5 E: SUBSYSTEM=input E: PRODUCT=19/0/1/0 E: NAME="Power Button" E: PHYS="PNP0C0C/button/input0" E: PROP=0 E: EV=3 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: USEC_INITIALIZED=8296574 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: ID_FOR_SEAT=input-acpi-PNP0C0C_00 E: TAGS=:seat: E: CURRENT_TAGS=:seat: P:
Bug#966223: Cannot install without wiping other packages
X-Debbugs-CC: jida...@jidanni.org
Control: tags 966223 +unreproducible
Control: notfound 966223 1.10.1-2
Control: close 966223
Hi,
Obviously it was a temporary issue during Transition. Test shows that the
coinstallability issue does not exist in current Debian Stable, Debian Testing
or Debian Sid.
Thanks,
Boyuan Yang
On Sat, 25 Jul 2020 05:51:34 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson
wrote:
> Package: unar
> Version: 1.10.1-2+b6
>
> With sid:
> # aptitude install unar
> The following NEW packages will be installed:
> unar{b} (D: gnustep-base-runtime, D: libgnustep-base1.27, D: libobjc4)
> 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/1,274 kB of archives. After unpacking 6,124 kB will be used.
> The following packages have unmet dependencies:
> unar : Depends: gnustep-base-runtime (>= 1.27.0) but it is not installable
> Depends: libgnustep-base1.27 (>= 1.27.0) but it is not installable
> Depends: libobjc4 (>= 4.2.1) but it is not installable
> The following actions will resolve these dependencies:
>
> Keep the following packages at their current version:
> 1) unar [Not Installed]
>
>
>
> Accept this solution? [Y/n/q/?] n
> The following actions will resolve these dependencies:
>
> Remove the following packages:
> 1) guile-2.2-libs [2.2.7+1-5.1 (now, unstable)]
> 2) libgc1 [1:8.0.4-1 (now, unstable)]
> 3) libmailutils6 [1:3.9-3.1 (now, unstable)]
> 4) libmu-dbm6 [1:3.9-3.1 (now, unstable)]
> 5) mailutils [1:3.9-3.1 (now, unstable)]
> 6) w3m [0.5.3-38+b1 (now, unstable)]
> 7) w3m-el-snapshot [1.4.632+0.20200702.0409.dca01f9-1 (now, unstable)]
>
> Install the following packages:
> 8) gnustep-base-common [1.27.0-3 (unstable)]
> 9) gnustep-base-runtime [1.27.0-3 (unstable)]
> 10) gnustep-common [2.8.0-1 (unstable)]
> 11) libgc1c2 [1:7.6.4-0.4 (unstable)]
> 12) libgnustep-base1.27 [1.27.0-3 (unstable)]
> 13) libobjc4 [10.1.0-6 (unstable)]
>
>
signature.asc
Description: This is a digitally signed message part
Bug#1010104: cqrlog: missing AppStream metadata
On Sun, Apr 24, 2022 at 03:58:48PM +0200, asciiw...@seznam.cz wrote: > Package: cqrlog > Version: 2.5.2-1 > > The cqrlog package has no AppStream metadata file although this file is > already present in upstream[1]. Please, consider adding this file. > > [1] https://github.com/ok2cqr/cqrlog/blob/master/tools/cqrlog.appdata.xml Hi, I see the file in the current Debian package: $ debc cqrlog_2.5.2-1_amd64.changes | grep appdata.xml -rw-r--r-- root/root 1266 2022-01-11 08:26 ./usr/share/metainfo/cqrlog.appdata.xml And I also see the metadata registered for bookworm (Debian testing): https://appstream.debian.org/bookworm/main/metainfo/cqrlog.html Is there some other place where it should be included? Cheers, tony signature.asc Description: PGP signature
Bug#1010244: does not work with PHP 8.1
Package: phpsysinfo Version: 3.2.5-3 Severity: grave Tags: upstream phpsysinfo fails with: Fatal error: __autoload() is no longer supported, use spl_autoload_register() instead in /usr/share/phpsysinfo/includes/autoloader.inc.php on line 25 This has been fixed in a more recent upstream release. -- ciao, Marco signature.asc Description: PGP signature
Bug#1010243: searchmonkey: diff for NMU version 0.8.3-1.1
Control: tags -1 +patch +pending Dear maintainer, I've prepared an NMU for searchmonkey (versioned as 0.8.3-1.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards. diff -Nru searchmonkey-0.8.3/debian/changelog searchmonkey- 0.8.3/debian/changelog --- searchmonkey-0.8.3/debian/changelog 2018-03-23 13:32:19.0 -0400 +++ searchmonkey-0.8.3/debian/changelog 2022-04-26 21:46:44.0 -0400 @@ -1,3 +1,12 @@ +searchmonkey (0.8.3-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: Fix Vcs-* fields. (Closes: #1010243) + * debian/searchmonkey.desktop: Fix broken icon location. (Closes: #901934) + * debian/rules: Fix broken pixmap symlink. (Closes: #910424) + + -- Boyuan Yang Tue, 26 Apr 2022 21:46:44 -0400 + searchmonkey (0.8.3-1) unstable; urgency=medium * New upstream release diff -Nru searchmonkey-0.8.3/debian/control searchmonkey-0.8.3/debian/control --- searchmonkey-0.8.3/debian/control 2018-03-22 00:06:19.0 -0400 +++ searchmonkey-0.8.3/debian/control 2022-04-26 21:35:59.0 -0400 @@ -6,8 +6,8 @@ Build-Depends: debhelper (>= 7), cdbs, pkg-config, libgtk2.0-dev, intltool, libzip-dev, libpoppler-glib-dev Standards-Version: 4.1.2 Homepage: http://sourceforge.net/projects/searchmonkey/ -Vcs-Git: https://anonscm.debian.org/git/users/varun/searchmonkey.git -Vcs-Browser: https://anonscm.debian.org/git/users/varun/searchmonkey.git +Vcs-Git: https://salsa.debian.org/debian/searchmonkey.git +Vcs-Browser: https://salsa.debian.org/debian/searchmonkey Package: searchmonkey Architecture: any diff -Nru searchmonkey-0.8.3/debian/rules searchmonkey-0.8.3/debian/rules --- searchmonkey-0.8.3/debian/rules 2018-03-21 23:33:57.0 -0400 +++ searchmonkey-0.8.3/debian/rules 2022-04-26 21:44:35.0 -0400 @@ -6,7 +6,7 @@ install/searchmonkey:: dh_install debian/searchmonkey.desktop /usr/share/applications/ dh_install debian/searchmonkey.xpm /usr/share/pixmaps/ - dh_link /usr/share/pixmaps/searchmonkey/searchmonkey-48x48.png /usr/share/pixmaps/searchmonkey.png + dh_link usr/share/icons/hicolor/48x48/apps/searchmonkey.png usr/share/pixmaps/searchmonkey.png get-orig-source: -uscan --upstream-version 0 --rename diff -Nru searchmonkey-0.8.3/debian/searchmonkey.desktop searchmonkey- 0.8.3/debian/searchmonkey.desktop --- searchmonkey-0.8.3/debian/searchmonkey.desktop 2018-03-21 23:33:57.0 -0400 +++ searchmonkey-0.8.3/debian/searchmonkey.desktop 2022-04-26 21:40:43.0 -0400 @@ -2,7 +2,7 @@ Name=Searchmonkey Comment=Regular expression power search utility Exec=searchmonkey -Icon=/usr/share/pixmaps/searchmonkey/searchmonkey-32x32.png +Icon=searchmonkey Type=Application StartupNotify=false Terminal=false signature.asc Description: This is a digitally signed message part
Bug#1010243: searchmonkey: Defunct Vcs-* fields
Source: searchmonkey Version: 0.8.3-1 Severity: normal Tags: sid bookworm X-Debbugs-CC: bkere...@ubuntu.com va...@debian.org Dear Debian searchmonkey package maintainer, The current Vcs-Browser and Vcs-Git fields provided by package points to the defunct alioth.debian.org website. Please consider updating the information, and ideally move the git packaging repo to Salsa Debian GitLab, such as https://salsa.debian.org/debian/searchmonkey . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1010241: libdebian-source-perl: Incorrect case sensitivity in Debian::Control::Stanza::new for field names
On Wed, 27 Apr 2022 09:52:07 +1000, Ben Finney wrote: > The matching is incorrectly case-sensitive. It should accept valid > variations such as ‘VCS-Git’ and ‘VCS-Browser’, but instead it > crashes: > > Invalid field given (VCS_Git) at /usr/share/perl5/Debian/Control.pm line > 122. > > The matching should be case-insensitive, understanding ‘vcs-git’ and > ‘VCS-Git’ and ‘Vcs-Git’ and ‘vcs-Git’ to all be the same field name. Hm, interesting bug report :) First, I wanted to ask "Why?" but then I found Debian Policy 5.1: Field names are not case-sensitive, but it is usual to capitalize the field names using mixed case as shown below. Then I found t/Control.t which tests exactly this issue. And then I found the following d/changelog entry for 0.95: [ Alex Muntada ] * Debian::Control::Stanza: accept case-insensitive field names in new() as required by Debian Policy while retaining the canonical accessors. Thanks to Ben Finney for the bug report. (Closes: #860023) And #860023 from 5 years ago is also interesting :) But yeah, it's not only a déjà-vu, apparently we need to take a look at this part of the code again … Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1010242: RFS: opengnb/1.2.8.7-1 [ITP] -- via P2P to setup de-centralized layer3 network VPN
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "opengnb": * Package name : opengnb Version : 1.2.8.7-1 Upstream Author : gnbdev * URL : https://github.com/gnbdev/opengnb * License : GPL-3 * Vcs : https://salsa.debian.org/atzlinux-guest/opengnb Section : net The source builds the following binary packages: opengnb - via P2P to setup de-centralized layer3 network VPN To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opengnb/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opengnb/opengnb_1.2.8.7-1.dsc Changes for the initial release: opengnb (1.2.8.7-1) unstable; urgency=low . [ xiao sheng wen(肖盛文) ] * Initial release (Closes: #1003101) Regards, -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》https://www.atzlinux.com 基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x00186602339240CB OpenPGP_signature Description: OpenPGP digital signature
Bug#1010241: libdebian-source-perl: Incorrect case sensitivity in Debian::Control::Stanza::new for field names
Package: libdebian-source-perl Version: 0.116 Severity: normal When parsing a Debian control stanza to an internal data structure, Debhelper uses ‘Debian::Control::Stanza’. The ‘new’ function attempts to match each field name to those names known for Debian control file stanzas. The matching is incorrectly case-sensitive. It should accept valid variations such as ‘VCS-Git’ and ‘VCS-Browser’, but instead it crashes: Invalid field given (VCS_Git) at /usr/share/perl5/Debian/Control.pm line 122. The matching should be case-insensitive, understanding ‘vcs-git’ and ‘VCS-Git’ and ‘Vcs-Git’ and ‘vcs-Git’ to all be the same field name. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libdebian-source-perl depends on: ii dpkg 1.21.7 ii dpkg-dev 1.21.7 ii libapt-pkg-perl 0.1.40+b1 ii libarray-unique-perl 0.08-2.1 ii libclass-accessor-perl0.51-1 ii liblist-moreutils-perl0.430-2 ii libparse-debcontrol-perl 2.005-4.1 ii libsub-install-perl 0.928-1.1 ii libtie-ixhash-perl1.23-2.1 ii libwww-mechanize-perl 2.06-1 ii libwww-perl 6.62-1 ii perl 5.34.0-4 libdebian-source-perl recommends no packages. libdebian-source-perl suggests no packages. -- no debconf information -- \ “He was the mildest-mannered man / That ever scuttled ship or | `\ cut a throat.” —“Lord” George Gordon Noel Byron, _Don Juan_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)
Bastian, I'm sorry to bother you. I've tried to upload a new version with the changes you suggested but it was rejected. The error is Rejected: hpnssh_8.8p1hpn16v1-1.dsc: Version older than that in the archive. 8.8p1hpn16v1-1 <= 1:8.8p1-hpn16v1-8 hpnssh (8.8p1hpn16v1-1) impish; urgency=medium * Submission to Debian for impish. * Refactor binary names to have hpn prefix Which is why my revision number hit 9 the first time. I'm not sure how to resolve this aside from either deleting the existing PPA and starting over or creating a new PPA. Do I have any other options? I really appreciate the time you are spending on this. Thanks again, Chris On 4/26/22 3:17 PM, Bastian Germann wrote: Am 26.04.22 um 21:04 schrieb rapier: Bastian, On 4/26/22 2:17 PM, Bastian Germann wrote: Control: tags -1 moreinfo On Tue, 22 Feb 2022 15:24:48 -0500 rapier wrote: Changes for the initial release: hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium . * Updated copyright. Please replace your massive changelog just with one entry that closes your ITP. The Debian revision has to be -1 and the epoch (1:) has to be removed. Please target "unstable". When you have provided a new revision, please untag moreinfo. This is my first submission to Debian so I apologize for the stupid questions. When you say the Debian revision needs to be -1 do you mean making the 1:8.8p1-hpn16v1-9 into 8.8p1-hpn16v1-1 or something else? Would that take care of the epoch as well? That version number is fine if the upstream version 8.8p1-hpn16v1 exists (I did not check for it). Epoch and revision are okay with 8.8p1-hpn16v1-1. Also, what should be in the changelog? Just an update that says closing the ITP? I apologize if this is documented somewhere. I've spent time looking for a submission guide but I couldn't find one that seemed up to date. https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog The New Maintainer's Guide is generally a good read.
Bug#1008445: golang-v2ray-core: FTBFS: src/github.com/lucas-clemente/quic-go/internal/qtls/go118.go:13:2: cannot find package "github.com/marten-seemann/qtls-go1-18" in any of
Hi Lucas, I cannot reproduce this bug. Is this test be re-tested or will it be tested periodically? I've tried to build it by pbuilder using sid chroot. It builds well. Build log is as attachment. Yours, Paul golang-v2ray-core_4.34.0-5_amd64.build.xz Description: application/xz OpenPGP_signature Description: OpenPGP digital signature
Bug#1010240: broadcom-sta-dkms: cannot build module, it fails after upgrade kernel to 5.17.3-1
Package: broadcom-sta-dkms Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages broadcom-sta-dkms depends on: ii dkms 2.8.7-2 Versions of packages broadcom-sta-dkms recommends: ii wireless-tools 30~pre9-13.1 broadcom-sta-dkms suggests no packages.
Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401
Control: tags -1 moreinfo On Fri, 22 Apr 2022 10:20:06 +0200 Robin ALEXANDER wrote: Changes for the initial release: odr-dabmod (2.6.0-1) unstable; urgency=low . * Initial release. Closes: #1007104 Please fix the lintian error (JS minified, source missing) by having the unminified source in debian/missing-sources. When you have uploaded a new revision (not changing the changelog), untag moreinfo.
Bug#1009867: RFS: odr-dabmux/4.2.1-1 [ITP] -- Digital Audio Broadcasting multiplexer compliant to ETSI EN 300 401
Control: tags -1 moreinfo On Tue, 19 Apr 2022 17:05:41 +0200 Robin ALEXANDER wrote: Changes for the initial release: odr-dabmux (4.2.1-1) unstable; urgency=low . * Initial release. Closes: #1009225 Please fix the lintian errors (JS minified, source missing) by having the unminified sources in debian/missing-sources. When you have uploaded a new revision (not changing the changelog), untag moreinfo.
Bug#1005305: RFS: php-codeigniter-framework/3.1.13-1 [ITP] -- The CodeIgniter framework
Control: tags -1 moreinfo Please target unstable or experimental with new packages. Untag moreinfo when you have provided a new version.
Bug#1010239: RM: librust-sequoia-openpgp+crypto-nettle-dev -- ROM; binary package v1.3.0-4 no longer built by source v1.8.0-1
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: d...@fifthhorseman.net The rust-sequoia-openpgp source package is in good shape. But, due to #1001251 librust-sequoia-openpgp+crypto-nettle-dev was renamed to rust-sequoia-openpgp+nettle-dev. As a result, librust-sequoia-openpgp+crypto-nettle-dev 1.3.0-4 lingers in unstable, even though the source package is at 1.8.0-1. Removing the old version of librust-sequoia-openpgp+crypto-nettle-dev should be sufficient to leave the archive in an acceptable state, as the Provides: entries can satisfy what needs to be satisfied. Thanks for maintaining the unstable archive in debian! Sorry for the additional hassle. --dkg
Bug#1010238: binutils: reproducible builds: source tarball embeds build user and group
Source: binutils Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: username X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org binutils-source embeds the username, uid, group and gid in the binutils source tarball: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/armhf/diffoscope-results/binutils.html /usr/src/binutils/binutils-2.38.tar.xz -rw-r--r--···0·pbuilder1··()·pbuilder1··()18002·2022-01-22·12:14:07.00·binutils-2.38/COPYING vs. -rw-r--r--···0·pbuilder2··()·pbuilder2··()18002·2022-01-22·12:14:07.00·binutils-2.38/COPYING The attached patch fixes this by passing arguments to tar in debian/rules to ensure consistent user, group, uid and gid in the generated tarballs. Unfortunately, other issues prevent binutils from building reproducibly, but this should at least reduce the differences, making it easier to fix remaining issues. Thanks for maintaining binutils! live well, vagrant From 30c8ddb48925121e20e53039ca60968764f6b874 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Tue, 26 Apr 2022 20:25:08 + Subject: [PATCH] debian/rules: Use consistent user and group when generating source tarball. https://reproducible-builds.org/docs/archives/ --- debian/rules | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/rules b/debian/rules index 7e856a63..c795d87b 100755 --- a/debian/rules +++ b/debian/rules @@ -1406,6 +1406,7 @@ endif # ifndef BACKPORT xargs -0r touch --no-dereference --date='$(BUILD_DATE)' && \ find $(source_files) -type f -print0 | LC_ALL=C sort -z | \ tar --null -T - -c --xz --exclude=CVS --mode=go=rX,u+rw,a-s \ + --owner=0 --group=0 --numeric-owner \ --xform='s=^[^/]*\/=binutils-$(VERSION)/=' \ -f $(pwd)/$(d_src)/$(PF)/src/binutils/binutils-$(VERSION).tar.xz \ $(source_files) -- 2.30.2 signature.asc Description: PGP signature
Bug#1004093: haskell-text-icu: diff for NMU version 0.7.0.1-14.1
Dear maintainer,
since this package is currently involved in the icu transition, I've
prepared an NMU for haskell-text-icu (versioned as 0.7.0.1-14.1). The
diff is attached to this message.
Cheers
--
Sebastian Ramacher
diff -Nru haskell-text-icu-0.7.0.1/debian/changelog haskell-text-icu-0.7.0.1/debian/changelog
--- haskell-text-icu-0.7.0.1/debian/changelog 2020-08-19 12:06:30.0 +0200
+++ haskell-text-icu-0.7.0.1/debian/changelog 2022-04-26 23:04:25.0 +0200
@@ -1,3 +1,11 @@
+haskell-text-icu (0.7.0.1-14.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply patch from László Böszörményi to build with icu 70.1 (Closes:
+#1004093)
+
+ -- Sebastian Ramacher Tue, 26 Apr 2022 23:04:25 +0200
+
haskell-text-icu (0.7.0.1-14) unstable; urgency=medium
* Patch for Unicode 11.0, 12.0, and 13.0 (Closes: #962402)
diff -Nru haskell-text-icu-0.7.0.1/debian/patches/lowercase_true.patch haskell-text-icu-0.7.0.1/debian/patches/lowercase_true.patch
--- haskell-text-icu-0.7.0.1/debian/patches/lowercase_true.patch 1970-01-01 01:00:00.0 +0100
+++ haskell-text-icu-0.7.0.1/debian/patches/lowercase_true.patch 2022-04-26 23:04:13.0 +0200
@@ -0,0 +1,19 @@
+Description: since ICU 68.1 TRUE and FALSE are no longer defined
+ Use their C99 / C++ analogues, ie use them in lowercase.
+Author: Laszlo Boszormenyi (GCS)
+Forwarded: no
+Last-Update: 2022-01-20
+
+---
+
+--- haskell-text-icu-0.7.0.1.orig/cbits/text_icu.c
haskell-text-icu-0.7.0.1/cbits/text_icu.c
+@@ -305,7 +305,7 @@ int32_t __hs_u_strFoldCase(UChar *dest,
+
+ int32_t __hs_u_strCompareIter(UCharIterator *iter1, UCharIterator *iter2)
+ {
+-return u_strCompareIter(iter1, iter2, TRUE);
++return u_strCompareIter(iter1, iter2, true);
+ }
+
+ UBlockCode __hs_ublock_getCode(UChar32 c)
diff -Nru haskell-text-icu-0.7.0.1/debian/patches/newer-icu haskell-text-icu-0.7.0.1/debian/patches/newer-icu
--- haskell-text-icu-0.7.0.1/debian/patches/newer-icu 2020-08-19 12:06:30.0 +0200
+++ haskell-text-icu-0.7.0.1/debian/patches/newer-icu 2022-04-26 23:04:13.0 +0200
@@ -1,17 +1,22 @@
--- a/Data/Text/ICU/Char.hsc
+++ b/Data/Text/ICU/Char.hsc
-@@ -129,6 +129,10 @@
- | PopDirectionalFormat
- | DirNonSpacingMark
- | BoundaryNeutral
-+ | FirstStrongIsolate
-+ | LeftToRightIsolate
-+ | RightToLeftIsolate
-+ | PopDirectionalIsolate
- deriving (Eq, Enum, Show, Typeable)
-
- instance NFData Direction where
-@@ -357,6 +361,94 @@
+@@ -51,6 +51,7 @@ module Data.Text.ICU.Char
+ , LineBreak_(..)
+ , SentenceBreak_(..)
+ , WordBreak_(..)
++, BidiPairedBracketType_(..)
+ -- * Property value types
+ , BlockCode(..)
+ , Direction(..)
+@@ -66,6 +67,7 @@ module Data.Text.ICU.Char
+ , LineBreak(..)
+ , SentenceBreak(..)
+ , WordBreak(..)
++, BidiPairedBracketType(..)
+ -- * Functions
+ , blockCode
+ , charFullName
+@@ -357,6 +359,48 @@ data BlockCode =
| SoraSompeng
| SundaneseSupplement
| Takri
@@ -57,52 +62,108 @@
+ | OldHungarian
+ | SupplementalSymbolsAndPictographs
+ | SuttonSignwriting
-+ | Adlam
-+ | Bhaiksuki
-+ | CyrillicExtendedC
-+ | GlagoliticSupplement
-+ | IdeographicSymbolsAndPunctuation
-+ | Marchen
-+ | MongolianSupplement
-+ | Newa
-+ | Osage
-+ | Tangut
-+ | TangutComponents
-+ | CJKUnifiedIdeographsExtensionF
-+ | KanaExtendedA
-+ | MasaramGondi
-+ | Nushu
-+ | Soyombo
-+ | SyriacSupplement
-+ | ZanabazarSquare
-+ | ChessSymbols
-+ | Dogra
-+ | GeorgianExtended
-+ | GunjalaGondi
-+ | HanifiRohingya
-+ | IndicSiyaqNumbers
-+ | Makasar
-+ | MayanNumerals
-+ | Medefaidrin
-+ | OldSogdian
-+ | Sogdian
-+ | EgyptianHieroglyphFormatControls
-+ | Elymaic
-+ | Nandinagari
-+ | NyiakengPuachueHmong
-+ | OttomanSiyaqNumbers
-+ | SmallKanaExtension
-+ | SymbolsAndPictographsExtendedA
-+ | TamilSupplement
-+ | Wancho
-+ | Chorasmian
-+ | CjkUnifiedIdeographsExtensionG
-+ | DivesAkuru
-+ | KhitanSmallScript
-+ | LisuSupplement
-+ | SymbolsForLegacyComputing
-+ | TangutSupplement
-+ | Yezidi
deriving (Eq, Enum, Bounded, Show, Typeable)
instance NFData BlockCode where
+@@ -475,6 +519,16 @@ data Bool_ =
+ -- ^ Printable character class.
+ | POSIXXDigit
+ -- ^ Hex digit character class.
++ | Cased
++ -- ^ Cased character class. For lowercase, uppercase and titlecase characters.
++ | CaseIgnorable
++ -- ^ Used in context-sensitive case mappings.
++ | ChangesWhenLowercased
++ | ChangesWhenUppercased
++ | ChangesWhenTitlecased
++ | ChangesWhenCasefolded
++ | ChangesWhenCasemapped
++ | ChangesWhenNFKCCasefolded
+ deriving (Eq, Enum, Show, Typeable)
+
+ instance NFData Bool_ where
+@@ -678,6 +732,37 @@ data JoiningGroup =
+ | Khaph
+ | Zhain
+ | BurushaskiYehBarree
++ | FarsiYeh
++ | Nya
++ | RohingyaYeh
++ | ManichaeanAleph
++ | ManichaeanAyin
++ | ManichaeanBeth
++ | ManichaeanDaleth
++ | ManichaeanDhamedh
++ | ManichaeanFive
++ | ManichaeanGimel
++
Bug#1010237: python3-mako is missing a runtime dependency on python3-pkg-resources
Package: python3-mako Version: 1.1.3+ds1-2 Severity: normal Dear maintainer, python3-mako is missing a runtime dependency on python3-pkg-resources. It is conditionally imported in mako/utils.py and might cause crashes when users try to load plugins: https://github.com/sqlalchemy/mako/blob/rel_1_1_3/mako/util.py#L30-L44 This issue was originally reported to Ubuntu, more info here: https://bugs.launchpad.net/ubuntu/+source/mako/+bug/1970153 Cheers! -- Lucas Kanashiro
Bug#1010236: xye: Xye is stuck in an infinite loop on arm
Package: xye Version: 0.12.2+dfsg-9 Severity: grave Justification: renders package unusable X-Debbugs-Cc: krzpyrk...@gmail.com Dear Maintainer, Xye relies heavily on x86 specific feature which is signedness of char type. It builds without errors on armhf and arm64 (and possibly other architectures that are affected) but hangs in an infinite loop as soon as "Play" button is pressed. The reason for that is internally all xy coordinates are represented not by int, but a char. On x86, subtracting 1 from 0 results in -1, on arm 255. This is a root of the problem. Some examples: src/xye.cpp:1234 for (j=XYE_VERT-1;j>=0;j--) // j reaches 255 on arm src/xye:1874 dx= (dx>=XYE_HORZ)?0:(dx<0)?XYE_HORZ-1:dx; // dx is never going to be less that 0, we can't walk through map's edges I've spent a while trying to replace chars with ints here and there but I gave up after seeing how this platform-specific oddity is deeply embedded in the code. Initially I managed to get "Play" button to work, but the minions did not move. Levels containing teleporters were getting stuck in an infinite loop. I've tried building the program with clang, enabling it's magnificent -fsanitize=integer feature, that detects (among other things) char overflows. The log was all red. The proposed solution is to enforce -fsigned-char in CFLAGS and CXXFLAGS. The program worked out of the box, all the issues I've encountered so far are gone. Tested on armhf and arm64.
Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)
On Tue, Apr 26, 2022 at 09:17:21PM +0200, Bastian Germann wrote: > Am 26.04.22 um 21:04 schrieb rapier: > > Bastian, > > > > On 4/26/22 2:17 PM, Bastian Germann wrote: > > > Control: tags -1 moreinfo > > > > > > On Tue, 22 Feb 2022 15:24:48 -0500 rapier wrote: > > > > Changes for the initial release: > > > > > > > > hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium > > > > . > > > > * Updated copyright. > > > > > > Please replace your massive changelog just with one entry that closes > > > your ITP. > > > The Debian revision has to be -1 and the epoch (1:) has to be removed. > > > Please target "unstable". When you have provided a new revision, please > > > untag moreinfo. > > > > > > This is my first submission to Debian so I apologize for the stupid > > questions. When you say the Debian revision needs to be -1 do you mean > > making the 1:8.8p1-hpn16v1-9 into 8.8p1-hpn16v1-1 or something else? > > Would that take care of the epoch as well? > > That version number is fine if the upstream version 8.8p1-hpn16v1 exists (I > did not check for it). > Epoch and revision are okay with 8.8p1-hpn16v1-1. What I understand from https://www.psc.edu/hpn-ssh-home is 8.8p1 version of OpenSSH and hpn16v1 the hpn-ssh part. However two - in the version feels odd. Gut feeling says "drop one -" > > Also, what should be in the changelog? Just an update that says closing the > > ITP? Yes. Because there are no other Debian changes to logged. (debian/changelog is for reporting/documenting Debian changes) > > I apologize if this is documented somewhere. I've spent time looking for > > a submission guide but I couldn't find one that seemed up to date. > > https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog > > The New Maintainer's Guide is generally a good read. Probably advices also version number convention. Groeten Geert Stappers -- Silence is hard to parse
Bug#1010235: provide metapackage for Matplotlib with LaTex markup
Package: python3-matplotlib Source: matplotlib (3.5.1-2) Version: 3.5.1-2+b1 The dependency problems for Matplotlib with LaTex markup are so notorious that they are already mentioned in the Matplotlib tutorial [1]: "On Ubuntu and Gentoo, the base texlive install does not ship with the type1cm package. You may need to install some of the extra packages to get all the goodies that come bundled with other LaTeX distributions." That note is outdated only insofar as the problem is no longer with type1cm, a package which does not exist in recent Debian versions. Starting with Matplotlib 3.2.1, the critical dependency is rather on file type1ec.sty [2], which is provided by package cm-super (or cm-super-minimal). I see the following possibilities. Solution 1. Let python3-matplotlib depend on cm-super-minimal, dvipng, texlive-extra-utils, texlive-latex-extra. Solution 2. As solution 1. Additionally, provide a new package python3-matplotlib-minimal for basic Matplotlib without LaTex markup. Solution 3. Leave python3-matplotlib without support for LaTeX markup. Provide a new dependency package python3-matplotlib-latex that depends on python3-matplotlib, cm-super-minimal, dvipng, texlive-extra-utils, texlive-latex-extra. [1] https://matplotlib.org/3.5.0/tutorials/text/usetex.html [2] https://github.com/matplotlib/matplotlib/issues/16911 smime.p7s Description: S/MIME Cryptographic Signature
Bug#1010234: RFP: python-trimgmi -- Opinionated parsing of gemtext.
Package: wnpp Severity: wishlist * Package name: python-trimgmi Version : 0.3.0 Upstream Author : David Seaward * URL : https://gitlab.com/lofidevops/trimgmi * License : GPL-3.0-or-later Programming Lang: Python Description : Opinionated parsing of gemtext. Gemtext (GMI) is a lightweight, line-oriented markup language designed for the Gemini internet protocol. This module parses gemtext, ignoring extraneous whitespace. Text after closing ``` marks is also ignored. The resulting objects can be rendered line-by-line without further parsing logic. Also included are: * round-trip render back to GMI with minimal whitespace * simple render to CommonMark * opinionated render to HTML * primitive command line tools for the above Once installed Python modules should be able to "import trimgmi". Users should also be able to invoke "trimgmi" and "convertgmi" from the command line.
Bug#1002295: Uploaded the files
Control: tags -1 moreinfo On Sun, 26 Dec 2021 19:20:16 + Scorpion2185 wrote: I uploaded the files: https://mentors.debian.net/package/multi-timer/ You should at least have no lintian errors (and better: no warnings) on the package. When you have provided a fixed version (keeping the changelog as-is), please untag moreinfo.
Bug#1010233: glibc: reproducible builds: different file permissions on ld.so.conf* and others
Source: glibc
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Changes in the experimental packaging cause the umask of the build user
to affect the permissions of numerous files that are excluded from the
dh_fixperms call:
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/arm64/diffoscope-results/glibc.html
glibc-source_2.34-0experimental4_all.deb
-rw-r--r--···0·root ... ./usr/src/glibc/debian/local/etc/ld.so.conf
-rw-r--r--···0·root ...
./usr/src/glibc/debian/patches/any/local-ldconfig-ignore-ld.so.diff
vs.
-rw-rw-r--···0·root ... ./usr/src/glibc/debian/local/etc/ld.so.conf
-rw-rw-r--···0·root ...
./usr/src/glibc/debian/patches/any/local-ldconfig-ignore-ld.so.diff
libc-bin_2.34-0experimental4_arm64.deb
-rw-r--r--···0·root·(0)·root·(0)···34·2019-07-29·09:56:57.00·./etc/ld.so.conf
drwxr-xr-x···0·root·(0)·root·(0)0·2019-07-29·09:56:57.00·./etc/ld.so.conf.d/
-rw-r--r--···0·root·(0)·root·(0)···44·2019-07-29·09:56:57.00·./etc/ld.so.conf.d/libc.conf
vs.
-rw-rw-r--···0·root·(0)·root·(0)···34·2019-07-29·09:56:57.00·./etc/ld.so.conf
drwxrwxr-x···0·root·(0)·root·(0)0·2019-07-29·09:56:57.00·./etc/ld.so.conf.d/
-rw-rw-r--···0·root·(0)·root·(0)···44·2019-07-29·09:56:57.00·./etc/ld.so.conf.d/libc.conf
The attached patch fixes this by removing some exclusions from
dh_fixperms calls and explicitly marking the desired files as
executable.
The patch does appear to have some side-effects setting various library
files as executable that were not previously:
-rw-r--r-- root/root /lib32/libBrokenLocale.so.1
vs.
-rwxr-xr-x root/root /lib32/libBrokenLocale.so.1
Weather this is desireable or undesireable I'm not sure... further
adjustments could be made to fix this either way, of course.
With this patch applied, glibc should become reproducible on
tests.reproducible-builds.org again!
Thanks for maintaining glibc!
live well,
vagrant
From fec02c8f2ce43f4987899e842119f7a1bb2e16c0 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Tue, 26 Apr 2022 18:48:16 +
Subject: [PATCH] debian/rules.d/debhelper.mk: Fix permissions on libc.so* and
ld.so* without excluding from dh_fixperms.
The dh_fixperms exclude was overly broad, catching /etc/ld.so.conf*
and other files, resulting in different permissions when built with
different umask.
https://tests.reproducible-builds.org/debian/issues/unstable/different_due_to_umask_issue.html
---
debian/rules.d/debhelper.mk | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/debian/rules.d/debhelper.mk b/debian/rules.d/debhelper.mk
index 3762ff85d..1ef90a834 100644
--- a/debian/rules.d/debhelper.mk
+++ b/debian/rules.d/debhelper.mk
@@ -52,11 +52,14 @@ endif
dh_compress -p$(curpass)
# Keep the setuid on pt_chown (non-Linux only).
- # libc.so prints useful version information when executed.
- dh_fixperms -p$(curpass) -Xpt_chown -Xlibc.so. -Xld.so
+ dh_fixperms -p$(curpass) -Xpt_chown
# Use this instead of -X to dh_fixperms so that we can use
# an unescaped regular expression. ld.so must be executable;
+ find debian/$(curpass) -type f -name ld.so -exec chmod a+x '{}' ';'
find debian/$(curpass) -type f -regex '.*/ld.*\.so\.[0-9]' -exec chmod a+x '{}' ';'
+ # libc.so prints useful version information when executed.
+ find debian/$(curpass) -type f -name libc.so -exec chmod a+x '{}' ';'
+ find debian/$(curpass) -type f -regex '.*/libc.*\.so\.[0-9]' -exec chmod a+x '{}' ';'
dh_makeshlibs -Xgconv/ -p$(curpass) -V "$(call xx,shlib_dep)"
# Add relevant udeb: lines in shlibs files
sh ./debian/shlibs-add-udebs $(curpass)
--
2.36.0
signature.asc
Description: PGP signature
Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it
On 2022-04-26 21:31:59, Tino Mettler wrote: > Am Mon, Apr 25, 2022 at 11:56:30 -0400 schrieb Antoine Beaupré: >> On 2022-04-25 17:16:35, Tino Mettler wrote: >> > Hi, Antoine, >> > >> > I run autopkgtest after the build process with the following result: >> > >> > # autopkgtest ./ -- qemu autopkgtest-unstable.img >> > autopkgtest [15:05:05]: starting date: 2022-04-25 >> > autopkgtest [15:05:05]: version 5.21 >> > autopkgtest [15:05:05]: host mac; command line: /usr/bin/autopkgtest ./ -- >> > qemu autopkgtest-unstable.img >> > autopkgtest [15:06:00]: testbed dpkg architecture: amd64 >> > autopkgtest [15:06:06]: testbed running kernel: Linux 5.17.0-1-amd64 #1 >> > SMP PREEMPT Debian 5.17.3-1 (2022-04-18) >> > autopkgtest [15:06:07]: built-tree ./ >> > autopkgtest [15:06:07]: testing package show-in-file-manager version >> > 1.1.4-1 >> > *SKIP no tests in this package >> > autopkgtest [15:06:07]: summary >> > *SKIP no tests in this package >> > qemu-system-x86_64: terminating on signal 15 from pid 527684 >> > (/usr/bin/python3) >> > >> > I'm still unsure what you meant with "You have actually configured it in >> > the package". >> >> You haven't, I was mistaken. See other comments on the bug report. > > Hi Antoine, > > I'm currently unsure if this topic is a remaining issue regarding the > package. When you propose a different name for the source package or a > config entry for the autodep8 config, please let me know. Yes, I think this is an issue that should be fixed. I think the source (or binary at least?) package should be changed to match upstream, which should fix the above error. a. -- We are discreet sheep; we wait to see how the drove is going, and then go with the drove. - Mark Twain
Bug#1003063: RFS: su-exec/0.2-1 [ITP] -- switch user and group id, setgroups and exec
Control: tags -1 moreinfo On Mon, 03 Jan 2022 16:05:11 +0100 Matteo Chesi wrote: Changes for the initial release: su-exec (0.2-1) UNRELEASED; urgency=low . * Initial release (Closes: #1003059). You have to target unstable or experimental for new packages. When you have provided a fixed revision (keeping the changelog as-is), untag moreinfo.
Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it
Am Mon, Apr 25, 2022 at 11:56:30 -0400 schrieb Antoine Beaupré: > On 2022-04-25 17:16:35, Tino Mettler wrote: > > Hi, Antoine, > > > > I run autopkgtest after the build process with the following result: > > > > # autopkgtest ./ -- qemu autopkgtest-unstable.img > > autopkgtest [15:05:05]: starting date: 2022-04-25 > > autopkgtest [15:05:05]: version 5.21 > > autopkgtest [15:05:05]: host mac; command line: /usr/bin/autopkgtest ./ -- > > qemu autopkgtest-unstable.img > > autopkgtest [15:06:00]: testbed dpkg architecture: amd64 > > autopkgtest [15:06:06]: testbed running kernel: Linux 5.17.0-1-amd64 #1 SMP > > PREEMPT Debian 5.17.3-1 (2022-04-18) > > autopkgtest [15:06:07]: built-tree ./ > > autopkgtest [15:06:07]: testing package show-in-file-manager version 1.1.4-1 > > *SKIP no tests in this package > > autopkgtest [15:06:07]: summary > > *SKIP no tests in this package > > qemu-system-x86_64: terminating on signal 15 from pid 527684 > > (/usr/bin/python3) > > > > I'm still unsure what you meant with "You have actually configured it in > > the package". > > You haven't, I was mistaken. See other comments on the bug report. Hi Antoine, I'm currently unsure if this topic is a remaining issue regarding the package. When you propose a different name for the source package or a config entry for the autodep8 config, please let me know. Regards, Tino
Bug#1010231: android-platform-tools dropped symbols (at least causes autopkgtest regression inandroid-platform-art)
Source: android-platform-tools Control: found -1 android-platform-tools/29.0.6-9 Control: affects -1 src:android-platform-art Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks Dear maintainer(s), With a recent upload of android-platform-tools the autopkgtest of android-platform-art fails in testing when that autopkgtest is run with the binary packages of android-platform-tools from unstable. It passes when run with only packages from testing. In tabular form: passfail android-platform-tools from testing29.0.6-9 android-platform-art from testing10.0.0+r36-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Looking at the error, it seems the library dropped a symbol. That needs to be handled by bumping SONAME and going through a library transition. I might be wrong reading the signs thought. Currently this regression is blocking the migration of android-platform-tools to testing [1]. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=android-platform-tools https://ci.debian.net/data/autopkgtest/testing/amd64/a/android-platform-art/21177056/log.gz all.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/all.xml which is empty failed: /usr/bin/dexdump2 -e -l xml all.dex /usr/bin/dexlist: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/all.lst which is empty failed: /usr/bin/dexlist all.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/all.txt which is empty failed: /usr/bin/dexdump2 -adfh all.dex bytecodes.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/bytecodes.xml which is empty failed: /usr/bin/dexdump2 -e -l xml bytecodes.dex /usr/bin/dexlist: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/bytecodes.lst which is empty failed: /usr/bin/dexlist bytecodes.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/bytecodes.txt which is empty failed: /usr/bin/dexdump2 -adfh bytecodes.dex checkers.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/checkers.xml which is empty failed: /usr/bin/dexdump2 -e -l xml checkers.dex /usr/bin/dexlist: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/checkers.lst which is empty failed: /usr/bin/dexlist checkers.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/checkers.txt which is empty failed: /usr/bin/dexdump2 -adfh checkers.dex const-method-handle.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/const-method-handle.xml which is empty failed: /usr/bin/dexdump2 -e -l xml const-method-handle.dex /usr/bin/dexlist: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/const-method-handle.lst which is empty failed: /usr/bin/dexlist const-method-handle.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/const-method-handle.txt which is empty failed: /usr/bin/dexdump2 -adfh const-method-handle.dex invoke-custom.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/invoke-custom.xml which is empty failed: /usr/bin/dexdump2 -e -l xml invoke-custom.dex /usr/bin/dexlist: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/invoke-custom.lst which is empty failed: /usr/bin/dexlist invoke-custom.dex /usr/bin/dexdump2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: Crc64GenerateTable cmp: EOF on /tmp/test-1496/invoke-custom.txt which is empty failed: /usr/bin/dexdump2 -adfh invoke-custom.dex
Bug#1009726: broken build of samba_4.13.13+dfsg-1~deb11u3 on i386
Hi On Sat, Apr 23, 2022 at 10:55:28AM +0300, Michael Tokarev wrote: > Hello! > > It turned out the security-uploaded build of samba on i386 is broken. > There were several reports about smbd segfaulting at startup or other > weirdness. This is specific to i386 build, the x64 build is fine (and > I know nothing about the other architectures). > > An example bugreport is #1006935 - it has several items in the list > of broken things, but this list is definitely not complete. > Also #1009855 #1002059. > > I tried to rebuild the same source package in a local clean bullseye > chroot, apparently with the same versions of everything, in the same > environment, and I'm getting *significantly* different binaries. > Updating just one package - switching from debian-built one into my > locally-built one immediately fixes the problem for me, samba starts > working as it should without weird errors or crashes. > > The issue at hand seems to be the usage of python hashes in samba > build procedure for everything including lists of include or library > paths, lists of object files for link and everything. By default, > python hashes are randomly-ordered, - this means the order of all > this is unpredictable and each time we're getting VERY different > binaries. > > Since samba overrides many system-provided functions, and the order > of objects to link is important, in this particular build we got > an order which made it use wrong functions in the end, and the > thing started to behave in a weird way. > > Upstream tried to fix this by using PYTHONHASHSEED=1 (which *still* > gives an order which depends on the architecture, but this is a > different issue). > > So we have to fix this one in bullseye. > > I already prepared a bullseye-pu version of samba - #1009726 - > the bug#), which does not include this fix. I'll update it today > (the fix is trivial) and resubmit. The bullseye-pu version has > some more fixes than is usually okay to bring to security@ but > most of them are worth the effort. > > Now since the prob is quite serious, maybe we can fix this some > faster way? To comment on this speaking form the security team perspective: We discussed it shortly and came to conclusion that it would be fine to just include this fix in the proposed update for the next bullseye point release without need of an out of order DSA for samba to address this. Affected users running on i386 migh then fetch earlier the update from the proposed-updates suites and so not forcing the working amd64 samba installations for another update. We think the major installation base for samba servers will not be on i386. Having this updat prepared for the next point release lays ground for future samba updates needed via security. So many thanks for hinving done this fair amout of work on your shoulders! Regards, Salvatore
Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)
Am 26.04.22 um 21:04 schrieb rapier: Bastian, On 4/26/22 2:17 PM, Bastian Germann wrote: Control: tags -1 moreinfo On Tue, 22 Feb 2022 15:24:48 -0500 rapier wrote: Changes for the initial release: hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium . * Updated copyright. Please replace your massive changelog just with one entry that closes your ITP. The Debian revision has to be -1 and the epoch (1:) has to be removed. Please target "unstable". When you have provided a new revision, please untag moreinfo. This is my first submission to Debian so I apologize for the stupid questions. When you say the Debian revision needs to be -1 do you mean making the 1:8.8p1-hpn16v1-9 into 8.8p1-hpn16v1-1 or something else? Would that take care of the epoch as well? That version number is fine if the upstream version 8.8p1-hpn16v1 exists (I did not check for it). Epoch and revision are okay with 8.8p1-hpn16v1-1. Also, what should be in the changelog? Just an update that says closing the ITP? I apologize if this is documented somewhere. I've spent time looking for a submission guide but I couldn't find one that seemed up to date. https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog The New Maintainer's Guide is generally a good read.
Bug#1010230: nvidia-graphics-drivers-legacy-390xx: autopkgtest needs update for new version of dkms: includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch
Source: nvidia-graphics-drivers-legacy-390xx
Version: 390.147-4
Severity: serious
X-Debbugs-CC: d...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:dkms
Dear maintainer(s),
With a recent upload of dkms the autopkgtest of
nvidia-graphics-drivers-legacy-390xx fails in testing when that
autopkgtest is run with the binary packages of dkms from unstable on
armhf. It passes when run with only packages from testing. In tabular form:
passfail
dkms from testing3.0.3-1
nvidia-graphics-drivers-legacy-390xx from testing390.147-4
all others from testingfrom testing
I copied some of the output at the bottom of this report. As I
understand it, the dkms changes extend the testing drastically and show
a real issue.
Currently this regression is blocking the migration of dkms to testing
[1]. Of course, dkms shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in dkms was
intended and your package needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from dkms should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=dkms
https://ci.debian.net/data/autopkgtest/testing/armhf/n/nvidia-graphics-drivers-legacy-390xx/21184047/log.gz
At top level:
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:999:5:
error: unknown type name ‘NV_WORKQUEUE_DATA_T’; did you mean
‘NV_WORKQUEUE_FLUSH’?
999 | NV_WORKQUEUE_DATA_T *data
| ^~~
| NV_WORKQUEUE_FLUSH
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/nv-vm.c: In
function ‘nv_flush_caches’:
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/nv-vm.c:225:5:
error: implicit declaration of function ‘NV_ON_EACH_CPU’
[-Werror=implicit-function-declaration]
225 | NV_ON_EACH_CPU(nv_flush_cache, NULL);
| ^~
cc1: some warnings being treated as errors
make[3]: ***
[/usr/src/linux-headers-5.17.0-1-common/scripts/Makefile.build:293:
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/nv-vm.o] Error 1
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:
In function ‘os_queue_work_item’:
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:1031:5:
error: implicit declaration of function ‘NV_WORKQUEUE_INIT’; did you
mean ‘NV_WORKQUEUE_FLUSH’? [-Werror=implicit-function-declaration]
1031 | NV_WORKQUEUE_INIT(>task, os_execute_work_item,
| ^
| NV_WORKQUEUE_FLUSH
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:1031:36:
error: ‘os_execute_work_item’ undeclared (first use in this function);
did you mean ‘rm_execute_work_item’?
1031 | NV_WORKQUEUE_INIT(>task, os_execute_work_item,
|^~~~
|rm_execute_work_item
In file included from
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:15:
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:
In function ‘os_is_efi_enabled’:
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/common/inc/nv-linux.h:224:26:
warning: returning ‘bool (*)(int)’ {aka ‘_Bool (*)(int)’} from a
function with return type ‘NvS32’ {aka ‘int’} makes integer from pointer
without a cast [-Wint-conversion]
224 | #define NV_EFI_ENABLED() efi_enabled
| ^~~
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:1110:12:
note: in expansion of macro ‘NV_EFI_ENABLED’
1110 | return NV_EFI_ENABLED();
|^~
In file included from
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:15:
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:
In function ‘os_get_euid’:
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/common/inc/nv-linux.h:154:46:
error: ‘struct task_struct’ has no member named ‘euid’
154 | #define NV_CURRENT_EUID() (__kuid_val(current->euid))
| ^~
/var/lib/dkms/nvidia-legacy-390xx/390.147/build/nvidia/os-interface.c:1338:18:
note: in expansion of macro ‘NV_CURRENT_EUID’
1338 | *pSecToken = NV_CURRENT_EUID();
| ^~~
cc1: some warnings being treated as errors
make[3]: ***
Bug#1010146: modprobe: ERROR: could not insert 'amd_pstate': No such device
Hi, On Tue, Apr 26, 2022 at 03:50:21PM +0200, Vincent Blut wrote: > Package: src:linux > Followup-For: Bug #1010146 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi Tobias, > > The AMD P-State driver has been enabled in linux 5.17.3-1 available in > testing/unstable. The kernel you are using does not include it. Additionally I think at this early stage at least, not all AMD CPUs are actually supporting it. IIRC, the initial commit talked only about some of the Zen3 based ones. Cf. https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html Regards, Salvatore
Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)
Bastian, On 4/26/22 2:17 PM, Bastian Germann wrote: Control: tags -1 moreinfo On Tue, 22 Feb 2022 15:24:48 -0500 rapier wrote: Changes for the initial release: hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium . * Updated copyright. Please replace your massive changelog just with one entry that closes your ITP. The Debian revision has to be -1 and the epoch (1:) has to be removed. Please target "unstable". When you have provided a new revision, please untag moreinfo. This is my first submission to Debian so I apologize for the stupid questions. When you say the Debian revision needs to be -1 do you mean making the 1:8.8p1-hpn16v1-9 into 8.8p1-hpn16v1-1 or something else? Would that take care of the epoch as well? Also, what should be in the changelog? Just an update that says closing the ITP? I apologize if this is documented somewhere. I've spent time looking for a submission guide but I couldn't find one that seemed up to date. Chris
Bug#1010229: cosmetic: version restrictions are limited to = for Provides but also Built-Using
Source: debian-policy
Version: 4.6.1
Severity: minor
Tags: patch
Hello.
The fourth paragraph of section 7.1 says:
The relations allowed are <<... for ... , respectively.
The exception is the Provides field, for which only = is allowed.
[footnote]
[footnote]: The relations < and > were previously allowed...
I see three problems in this paragraph:
* The second sentence lies, as Built-Using introduces another
exception.
* An explicit list of exceptions in the section header is hard to keep
accurate, and not useful, at least inside the policy.
* The footnote actually concerns the previous sentence.
I suggest to remove the second sentence, and instead be explicit in
the description of the Provides field.
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -25,8 +25,7 @@
The relations allowed are ``<<``, ``<=``, ``=``, ``>=`` and ``>>`` for
strictly earlier, earlier or equal, exactly equal, later or equal and
-strictly later, respectively. The exception is the Provides field, for
-which only ``=`` is allowed. [#]_
+strictly later, respectively. [#]_
Whitespace may appear at any point in the version specification subject
to the rules in :ref:`s-controlsyntax`, and must appear
@@ -447,7 +446,9 @@ they can say:
and the ``bar-plus`` package will now also satisfy the dependency for
the ``foo`` package.
-A ``Provides`` field may contain version numbers, and such a version number
+A ``Provides`` field may contain version numbers,
+but only with the "exactly equal" ("=") relation.
+Such a version number
will be considered when considering a dependency on or conflict with the
virtual package name. For example, given the following packages:
Bug#1008849: shiboken2 - shiboken_helpers.cmake breaks with every Python transition
On Thu, Apr 21 2022, Yuri D'Elia wrote: > On Thu, Apr 21 2022, Nicholas D Steeves wrote: >> Unfortunately I'm out of time for the near future, but if you'd like I >> can upload an untested 5.15.3 package to experimental for you to test. > > I can definitely help testing this. Ping! ;)
Bug#1008584: RFS: milvus/2.0.0-1 [ITP] -- Vector database for unstructured data
Control: tags -1 moreinfo Just for the record: You have to give a URL where you provide a source package so that we can have a look at the package. I noticed an upload 2.0.0-1 at https://mentors.debian.net/package/milvus/. You have to target unstable or experimental with a new package. When you have provided a fixed version, please untag moreinfo.
Bug#1010228: policykit-1: Polkit doesn't honor the rules and actions at /usr/local/share/polkit-1
Package: polkitd Version: 0.105-33 Severity: normal X-Debbugs-Cc: rasters...@gmail.com Dear Maintainer, I was creating a patch for gnome-control-center that involved adding a new polkit action, but it didn't work until I moved the polkit files from /usr/local/share/polkit-1 into /usr/share/polkit-1. I think that polkit should accept both folders. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages policykit-1 depends on: ii pkexec 0.105-33 ii polkitd 0.105-33 policykit-1 recommends no packages. policykit-1 suggests no packages. Versions of packages polkitd depends on: ii dbus 1.14.0-1 ii libc62.33-7 ii libexpat12.4.8-1 ii libglib2.0-0 2.72.1-1 ii libpam-systemd [logind] 250.4-1 ii libpam0g 1.4.0-13 ii libpolkit-agent-1-0 0.105-33 ii libpolkit-gobject-1-00.105-33 ii libsystemd0 250.4-1 -- no debconf information
Bug#1008707: RFS: calamares-extensions/1.2.1-1 [ITP] -- Mobile module for Calamares installer framework
Control: tags -1 moreinfo On Thu, 31 Mar 2022 08:28:58 +1100 undef wrote: Changes for the initial release: calamares-extensions (1.2.1-1) UNRELEASED; urgency=medium . * Initial Release (Closes: #998858) When you propose a team-maintained package, please ask the team for sponsorship first. If you have asked and they did not respond, please explain the details. You have to target unstable or experimental with a new package. Please provide a new upload and untag moreinfo.
Bug#1010227: asmixer FTCBFS: does not pass cross tools to make
Source: asmixer Version: 0.5-15 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs asmixer fails to cross build from source, because it does not pass cross tools to make. The easiest way of doing so - using dh_auto_build - makes asmixer cross buildable. Please consider applying the attached patch. Helmut diff -u asmixer-0.5/debian/changelog asmixer-0.5/debian/changelog --- asmixer-0.5/debian/changelog +++ asmixer-0.5/debian/changelog @@ -1,3 +1,10 @@ +asmixer (0.5-15.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (closes: #-1) + + -- Helmut Grohne Tue, 26 Apr 2022 20:26:06 +0200 + asmixer (0.5-15) unstable; urgency=medium * Fix build issues (closes: #999333) diff -u asmixer-0.5/debian/rules asmixer-0.5/debian/rules --- asmixer-0.5/debian/rules +++ asmixer-0.5/debian/rules @@ -10,9 +10,7 @@ build: build-stamp build-stamp: dh_testdir - - $(MAKE) CFLAGS="-O2 -g" - + dh_auto_build -- CFLAGS="-O2 -g" touch build-stamp clean:
Bug#1010226: kgames FTCBFS: requires an exe_wrapper
Source: kgames
Version: 2.1-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
kgames fails to cross build from source, because meson requires an
exe_wrapper, but none is usually given. This happens when building a
host binary and attempting to run it (as a code generator). In this
case, the two relevant code generators are architecture-independent and
can be annotated with "native: true" to avoid the need for an
exe_wrapper. Please consider applying the attached patch.
Helmut
--- kgames-2.2.orig/xreversi/meson.build
+++ kgames-2.2/xreversi/meson.build
@@ -41,6 +41,7 @@ srcs_reversi = [
genedge = executable('genedge',
'genedge.c',
+ native: true,
install: false)
bison_gen = generator(bison,
@@ -51,6 +52,7 @@ makeedge_files = bison_gen.process('make
makeedge = executable('makeedge',
makeedge_files,
+ native: true,
install: false)
edges_in = custom_target('edges.in',
Bug#1009352: RFS: golang-github-protonmail-go-mime/0.0~git20220302.303f85f-1 [ITP] -- Go Mime Wrapper Library (library)
Where have you asked the team for sponsorship? Please always document that on (future) team-maintained packages.
Bug#1009765: RFS: vertcoin/0.18.0-1 -- peer-to-peer network based digital currency - CLI tools
Control: tags -1 moreinfo On Sun, 17 Apr 2022 00:18:31 + vertion wrote: vertcoin (0.18.0-1) unstable; urgency=medium . [ vertion ] * Initial release. You have to close your ITP with this changelog entry. Untag moreinfo when you have provided a fixed version.
Bug#1010040: RFS: quick-lint-js/2.4.1-2 -- JavaScript linter
Control: tags -1 moreinfo I would guess there are enough JS linters in Debian. If you really want to pursue this, you should get the basics right. The changelog must have one entry for the initial version that closes your ITP. It has to have a "-1" revision. Get rid of all old versions because they have never been in the Debian archive. Please untag moreinfo when you have provided a package that can be considered for review.
Bug#1010225: callaudiod FTCBFS: fails running gtk-doc scanner
Source: callaudiod Version: 0.1.4-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs callaudiod fails to cross build from source, because it fails to run the cross-built gtk-doc scanner. Fortunately, the documentation is split to an arch:all package, so we don't have to build it during an arch-only build such as a cross build. All that needs to be done here is skipping the documentation build for arch-only builds. Doing so also speeds up the build on buildds. Please consider applying the attached patch. Helmut diff --minimal -Nru callaudiod-0.1.4/debian/changelog callaudiod-0.1.4/debian/changelog --- callaudiod-0.1.4/debian/changelog 2022-03-25 10:23:38.0 +0100 +++ callaudiod-0.1.4/debian/changelog 2022-04-26 20:01:29.0 +0200 @@ -1,3 +1,10 @@ +callaudiod (0.1.4-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Do not build documentation in an arch-only build. (Closes: #-1) + + -- Helmut Grohne Tue, 26 Apr 2022 20:01:29 +0200 + callaudiod (0.1.4-1) unstable; urgency=medium * d/gbp.conf: use proper config for upstream tag. diff --minimal -Nru callaudiod-0.1.4/debian/control callaudiod-0.1.4/debian/control --- callaudiod-0.1.4/debian/control 2022-03-25 10:23:38.0 +0100 +++ callaudiod-0.1.4/debian/control 2022-04-26 20:00:32.0 +0200 @@ -6,12 +6,13 @@ Build-Depends: dbus, debhelper-compat (= 13), - gtk-doc-tools, libasound2-dev, libglib2.0-dev, libpulse-dev, meson, pkg-config, +Build-Depends-Indep: + gtk-doc-tools, Standards-Version: 4.6.0 Homepage: https://gitlab.com/mobian1/callaudiod Vcs-Git: https://salsa.debian.org/DebianOnMobile-team/callaudiod.git diff --minimal -Nru callaudiod-0.1.4/debian/rules callaudiod-0.1.4/debian/rules --- callaudiod-0.1.4/debian/rules 2022-03-25 10:23:38.0 +0100 +++ callaudiod-0.1.4/debian/rules 2022-04-26 20:01:24.0 +0200 @@ -6,7 +6,7 @@ dh $@ --builddirectory=_build override_dh_auto_configure: - dh_auto_configure -- -Dgtk_doc=true + dh_auto_configure -- -Dgtk_doc=$(if $(filter libcallaudio-doc,$(shell dh_listpackages)),true,false) override_dh_makeshlibs: dh_makeshlibs --package=libcallaudio-0-1 -- -c2
Bug#1010224: sed FTBFS on musl-any-any: missing regex library
Source: sed Version: 4.8-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap sed fails to build from source for musl-any-any, because the musl C library does not include a regex library. Even though sed ships its own, it is disabled in favour of the glibc one. Thus, I'm asking to enable the included regex library on musl only. Please consider applying the attached patch. Helmut diff --minimal -Nru sed-4.8/debian/changelog sed-4.8/debian/changelog --- sed-4.8/debian/changelog2021-08-31 14:55:13.0 +0200 +++ sed-4.8/debian/changelog2022-04-26 20:17:01.0 +0200 @@ -1,3 +1,10 @@ +sed (4.8-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS on musl-any-any: Use included regex library. closes: #-1. + + -- Helmut Grohne Tue, 26 Apr 2022 20:17:01 +0200 + sed (4.8-1) unstable; urgency=medium * New upstream version. diff --minimal -Nru sed-4.8/debian/rules sed-4.8/debian/rules --- sed-4.8/debian/rules2021-08-31 14:55:13.0 +0200 +++ sed-4.8/debian/rules2022-04-26 20:16:59.0 +0200 @@ -1,10 +1,12 @@ #! /usr/bin/make -f +include /usr/share/dpkg/architecture.mk + %: dh $@ override_dh_auto_configure: - dh_auto_configure -- --exec-prefix=/ --with-packager=Debian --without-included-regex + dh_auto_configure -- --exec-prefix=/ --with-packager=Debian --with$(if $(filter musl,$(DEB_HOST_ARCH_LIBC)),,out)-included-regex override_dh_auto_build: dh_auto_build -- HELP2MAN=/usr/bin/help2man
Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)
Control: tags -1 moreinfo On Tue, 22 Feb 2022 15:24:48 -0500 rapier wrote: Changes for the initial release: hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium . * Updated copyright. Please replace your massive changelog just with one entry that closes your ITP. The Debian revision has to be -1 and the epoch (1:) has to be removed. Please target "unstable". When you have provided a new revision, please untag moreinfo.
Bug#1010223: RFS: opencpn/5.6.2+dfsg-1~bpo11+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1~bpo11+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ or using: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo11+1.dsc This is a backport to Bullseye. The sid version builds more or less out of the box, the delta is minimal. Changes since the last upload: opencpn (5.6.2+dfsg-1~bpo11+1) bullseye-backports; urgency=medium . * Initial bullseye backport of 5.6.2+dfsg-1 Regards, -- Alec Leamas
Bug#1005309: RFS: runit-services/0.5.0 [ITP] -- UNIX init scheme with service supervision (services)
Control: tags -1 moreinfo Hi Lorenzo, Do you have any DDs in the runit team to sponsor this? If so, please RFS them. Else, you should think of removing that team and list the members as Maintainers/Uploaders. That way, your individual uploads will receive more attention. DDs will refuse to upload when they are not a team member. As long as this is not clear, I am tagging moreinfo. Please remove on providing the info. Thanks, Bastian
Bug#1009861: Additional information needed.
Hello Henrique, Thank you for your update. Here are the outputs from the requested commands. Please be informed that they are triggered on working ( non-updated ) system with intel-microcode. If you need I can run them onto updated system with most recent package. root@del40:~# du -sh /boot 112M /boot root@del40:~# 2. iucode_tool -Sv iucode_tool: system has processor(s) with signature 0x0001067a iucode_tool: assuming all processors have the same type, family and model root@del40:~# 3. root@del40:~# iucode-tool -tr -Lv /boot/initrd.img* microcode bundle 1: /boot/initrd.img-4.19.0-18-amd64 001/001: sig 0x06f2, pf_mask 0x20, 2010-10-02, rev 0x005c, size 4096 001/002: sig 0x06f2, pf_mask 0x01, 2010-10-02, rev 0x005d, size 4096 001/003: sig 0x06f6, pf_mask 0x20, 2010-10-01, rev 0x00d1, size 4096 001/004: sig 0x06f6, pf_mask 0x04, 2010-10-01, rev 0x00d2, size 4096 001/005: sig 0x06f6, pf_mask 0x01, 2010-09-30, rev 0x00d0, size 4096 001/006: sig 0x06f7, pf_mask 0x40, 2010-10-02, rev 0x006b, size 4096 001/007: sig 0x06f7, pf_mask 0x10, 2010-10-02, rev 0x006a, size 4096 001/008: sig 0x06fa, pf_mask 0x80, 2010-10-02, rev 0x0095, size 4096 001/009: sig 0x06fb, pf_mask 0x80, 2010-10-03, rev 0x00ba, size 4096 001/010: sig 0x06fb, pf_mask 0x40, 2010-10-03, rev 0x00bc, size 4096 001/011: sig 0x06fb, pf_mask 0x20, 2010-10-03, rev 0x00ba, size 4096 001/012: sig 0x06fb, pf_mask 0x10, 2010-10-03, rev 0x00ba, size 4096 001/013: sig 0x06fb, pf_mask 0x08, 2010-10-03, rev 0x00bb, size 4096 001/014: sig 0x06fb, pf_mask 0x04, 2010-10-03, rev 0x00bc, size 4096 001/015: sig 0x06fb, pf_mask 0x01, 2010-10-03, rev 0x00ba, size 4096 001/016: sig 0x06fd, pf_mask 0x80, 2010-10-02, rev 0x00a4, size 4096 001/017: sig 0x06fd, pf_mask 0x20, 2010-10-02, rev 0x00a4, size 4096 001/018: sig 0x06fd, pf_mask 0x01, 2010-10-02, rev 0x00a4, size 4096 001/019: sig 0x0f34, pf_mask 0x1d, 2005-04-21, rev 0x0017, size 7168 001/020: sig 0x0f41, pf_mask 0xbd, 2005-04-22, rev 0x0017, size 5120 001/021: sig 0x0f41, pf_mask 0x02, 2005-04-21, rev 0x0016, size 5120 001/022: sig 0x0f43, pf_mask 0x9d, 2005-04-21, rev 0x0005, size 2048 001/023: sig 0x0f44, pf_mask 0x9d, 2005-04-21, rev 0x0006, size 3072 001/024: sig 0x0f47, pf_mask 0x9d, 2005-04-21, rev 0x0003, size 3072 001/025: sig 0x0f48, pf_mask 0x5f, 2005-06-30, rev 0x0007, size 3072 001/026: sig 0x0f48, pf_mask 0x02, 2008-01-15, rev 0x000e, size 3072 001/027: sig 0x0f48, pf_mask 0x01, 2006-05-08, rev 0x000c, size 3072 001/028: sig 0x0f49, pf_mask 0xbd, 2005-04-21, rev 0x0003, size 2048 001/029: sig 0x0f4a, pf_mask 0x5d, 2005-06-10, rev 0x0002, size 2048 001/030: sig 0x0f4a, pf_mask 0x5c, 2005-12-14, rev 0x0004, size 2048 001/031: sig 0x0f62, pf_mask 0x04, 2005-12-15, rev 0x000f, size 3072 001/032: sig 0x0f64, pf_mask 0x34, 2005-12-23, rev 0x0004, size 3072 001/033: sig 0x0f64, pf_mask 0x01, 2005-12-15, rev 0x0002, size 3072 001/034: sig 0x0f65, pf_mask 0x04, 2007-05-10, rev 0x000b, size 2048 001/035: sig 0x0f65, pf_mask 0x01, 2006-04-26, rev 0x0008, size 2048 001/036: sig 0x0f68, pf_mask 0x22, 2006-07-14, rev 0x0009, size 2048 001/037: sig 0x00010661, pf_mask 0x80, 2010-10-04, rev 0x0044, size 4096 001/038: sig 0x00010661, pf_mask 0x04, 2007-05-01, rev 0x0036, size 4096 001/039: sig 0x00010661, pf_mask 0x02, 2010-10-04, rev 0x0042, size 4096 001/040: sig 0x00010661, pf_mask 0x01, 2010-10-04, rev 0x0043, size 4096 001/041: sig 0x00010676, pf_mask 0x80, 2010-09-29, rev 0x060f, size 4096 001/042: sig 0x00010676, pf_mask 0x40, 2010-09-29, rev 0x060f, size 4096 001/043: sig 0x00010676, pf_mask 0x10, 2010-09-29, rev 0x060f, size 4096 001/044: sig 0x00010676, pf_mask 0x04, 2010-09-29, rev 0x060f, size 4096 001/045: sig 0x00010676, pf_mask 0x01, 2010-09-29, rev 0x060f, size 4096 001/046: sig 0x00010677, pf_mask 0x10, 2010-09-29, rev 0x070a, size 4096 001/047: sig 0x0001067a, pf_mask 0xa0, 2010-09-28, rev 0x0a0b, size 8192 001/048: sig 0x0001067a, pf_mask 0x44, 2010-09-28, rev 0x0a0b, size 8192 001/049: sig 0x0001067a, pf_mask 0x11, 2010-09-28, rev 0x0a0b, size 8192 001/050: sig 0x000106a4, pf_mask 0x03, 2013-06-21, rev 0x0012, size 14336 001/051: sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288 001/052: sig 0x000106c2, pf_mask 0x08, 2009-04-10, rev 0x0219, size 5120 001/053: sig 0x000106c2, pf_mask 0x04, 2009-04-10, rev 0x0218, size 5120 001/054: sig 0x000106c2, pf_mask 0x01, 2009-04-10, rev 0x0217, size 5120 001/055: sig 0x000106ca, pf_mask 0x10, 2009-08-25, rev 0x0107, size 5120 001/056: sig 0x000106ca, pf_mask 0x08, 2009-08-25, rev 0x0107, size 5120 001/057: sig 0x000106ca, pf_mask 0x04, 2009-08-25, rev 0x0107, size 5120 001/058: sig 0x000106ca, pf_mask 0x01, 2009-08-25, rev 0x0107, size 5120 001/059: sig 0x000106d1, pf_mask 0x08, 2010-09-30, rev 0x0029, size 4096 001/060: sig 0x000106e5,
Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot
Hi,
I've send an updated version of autopkgtest-virt-unshare as a merge
request:
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/138
Cheers Jochen
* Jochen Sprickerhof [2022-04-17 22:10]:
Hi,
* Martin Pitt [2016-11-16 13:37]:
Johannes Schauer [2016-11-16 1:12 +0100]:
in the context of #833407 I told you about my plan of adding a
virtualization backend which would allow completely unprivileged chroot
operation by using linux user namespaces.
Nice!
In contrast to what I thought was required back then, I now managed
to write that backend using just lxc-usernsexec and lxc-unshare.
Thus, I was able to get it to work using the existing Python
modules. You can find the script attached. As you can see, it is
extremely simple, which I find makes the beauty of it all. All you
need is:
- the lxc package installed for lxc-usernsexec and lxc-unshare
I'd like to eliminate this even. util-linux' unshare has known about
--user/-U for a while now, and thus replaces lxc-unshare and
lxc-usernsexec:
$ unshare -rmU sh -c 'whoami; mount -t tmpfs foo /mnt; touch /mnt/foo; ls -l
/mnt/foo'
root
-rw-r--r-- 1 root root 0 Nov 16 12:59 /mnt/foo
And you can use util-linux' nsenter to enter an existing namespace.
These lxc-* tools were written before util-linux learned about those,
and I'm not sure if they are going to stick around forever as they are
basically obsolete. It would also avoid the lxc dependency.
Would you be willing to try this?
I have implemented this in autopkgtest-virt-unshare (attached). Would
be great to get it into the autopkgtest package.
$ sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=uchroot \
--autopkgtest-virt-server-opts="-- /srv/chroot/%r-%a-sbuild.tar.gz
/tmp/rootfs"
The path /tmp/rootfs is the path that the rootfs will be extracted to
and can be at any location that the user has access to.
I think it would be more comfortable to use mkdtemp() by default, and
provide --unpack-dir as an option?
I implemented this as well.
It would be great if this backend could be added to autopkgtest itself.
If you think that it is not a good fit for autopkgtest, then I can
maintain it in a separate package.
I think it would be a great fit, but in order to accept it I have some
stricter requirements:
* tests/autopkgtest should run at least the standard
DebTestsVirtContainer tests. Look at classes LxcRunner and LxdRunner, should
be a fairly simple extension.
This will show the limits of what the backend can do, uncover
possible encoding/locale/whatever issues, and ensure that this will
keep working over time.
* It should get a manpage, probably starting from
virt/autopkgtest-virt-chroot.1.
I can look into this if you are fine with the script in general.
As building such a chroot tarball doesn't require new tools, that
should be it (the manpage should just explain how to build them, with
sbuild-createchroot or mk-sbuild).
I actually have wanted to deprecate the "chroot" backend for a long
time, as it's inherently insecure and I never use it myself any more.
I wonder if uschroot could completely replace that? At first sight it
should have the same isolation and robustness capabilities like
lxc/lxd (at least wrt. the file system and mounting), except with a
lot fewer dependencies.
| tarball = None
| rootdir = None
|
|
| def parse_args():
| global tarball, rootdir
|
| parser = argparse.ArgumentParser()
| parser.add_argument('-d', '--debug', action='store_true',
| help='Enable debugging output')
| parser.add_argument('tarball', help='path to rootfs tarball')
|
| def hook_open():
| global tarball, rootdir
|
| # We want to find out our user and group id inside the chroot but we want
| # to avoid having to parse /etc/subuid and /etc/subgid. We solve the
| # situation by creating a temporary file from inside the user namespace
| # and then checking its user and group ids from outside the user
namespace.
| probe = VirtSubproc.check_exec(['lxc-usernsexec', 'mktemp',
| '/tmp/uchroot.XX'], outp=True)
| inner_uid = os.stat(probe)[stat.ST_UID]
| inner_gid = os.stat(probe)[stat.ST_GID]
| VirtSubproc.check_exec(['lxc-usernsexec', 'rm', probe])
| outer_uid = os.getuid()
| outer_gid = os.getgid()
This dance wouldn't even be necessary with unshare -rU -- you know
that the outside uid/gid is just the normal user, and the inside one
is root/root.
done.
I'm not sure if there is something to be gained from the UID shift --
that isolates the chroot test better, but also makes it much harder to
clean up after a failed tests, as your normal user cannot touch/rm the
temporary directories? But if you want this, there's newuidmap(1).
| # Unpack the tarball into the new directory.
| # Make sure not to extract any character special files because we cannot
| # mknod.
| VirtSubproc.check_exec(['lxc-usernsexec', '--', 'tar',
Bug#716056: [Mayhem] ldnsutils: numerous input/options parsing errors in example utilities
This has been merged in a strange way. Here are the actual testcases: ldns-dpa -f "&" -- -f for expression, a & b ldns-keyfetcher '. .' -v (does not work w/o -v) ldns-zcat /dev/null /mjt
Bug#1010222: RFP: vlc-plugin-pipewire -- Pipewire plugin for the VLC media player framework
Package: wnpp Severity: wishlist * Package name: vlc-plugin-pipewire Version : 1 Upstream Author : Rémi Denis-Courmont * URL : https://www.remlab.net/vlc-plugin-pipewire/ * License : GPL (v3) Programming Lang: C Description : Pipewire plugin for the VLC media player framework This stand-alone plug-in for the VLC media player and LibVLC-based applications provides seamless integration with the PipeWire service for audio playback. Pipewire and (Lib)VLC are already available in Debian.
Bug#576093: error: No nameservers defined in the resolver
Control: severity -1 minor Control: tag -1 + confirmed upstream Control: found -1 1.8.1-1 On Wed, 31 Mar 2010 22:52:09 +0200 Piotr Engelking wrote: Package: ldnsutils Version: 1.6.4-4 Severity: normal If the 'nameserver' option is not present in /etc/resolv.conf, drill refuses to run: Yeah, drill does not initialize a default nameserver of 127.0.0.1 in case no nameserver line is present in resolv.conf. Confirmed, marking this as a minor issue and tagging with "upstream". Thanks, /mjt
Bug#998308: /usr/bin/drill: drill does not respect the /etc/resolv.conf nameserver order
Control: severity -1 minor Control: tag -1 + wontfix upstream On Tue, 02 Nov 2021 09:27:40 +0100 Bjørn Mork wrote: Package: ldnsutils Version: 1.7.1-2+b1 Severity: normal File: /usr/bin/drill -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 ... This is the documented behaviour in debian. Quoting from resolv.conf(5) ... However, drill seems to use all entries in a random(?) order. Or at least in an order which changes from one run to another, causing failures which come and go depending on whether the nameserver works on the primary link or not. Hi Bjørn! Drill is a dns debugging tool using a special-purpose dns library. What do you read about resolv.conf is being said for the standard glibc resolver, the manpage describes how the glibc resolver works. Other tools may use the information in there in some other ways, there's no obligation an information is used only the way it was initially supposed to be used. Drill has another tidbit here: it does not use default nameserver of 127.0.0.1 if no nameserver line is specified in resolv.conf. While this might be unexpected to a new user of drill, I don't see it is a bug per se. It is the way how it works (but the lack of default nameserver is annoying). I'm lowering severity of this bug and tagging with wontfix. Rewriting the upstream-decided algorithm of nameserver query order in Debian is definitely not an option. If you think the behavior is incorrect, please file upstream bugreport about this issue. Thank you for the bug report! /mjt
Bug#1010221: backintime-qt4: drop transitional package
Package: backintime-qt4 Version: 1.3.2-0.1 Please drop backintime-qt4 because that transitional package is no longer needed.
Bug#1004451: RFS: pinpoint/1:0.1.8-6 [ITA] -- hacker-friendly presentation program
Control: tags -1 moreinfo On Fri, 28 Jan 2022 15:40:33 +0100 Bastian Germann wrote: These are all only formal changes. It would be great if you could address at least one of the open bugs to show that you are really interested in the package. Please untag moreinfo when you have uploaded a more useful revision.
Bug#1010220: startup delay of some gtk apps
Package: xdg-desktop-portal-gtk Version: 1.14.0-1 I experience long startup delays of some gtk apps, e.g. handbrake-gtk. Apparently there are problems with a portal service: % systemctl --user status xdg-desktop-portal.service x xdg-desktop-portal.service - Portal service Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static) Active: failed (Result: timeout) since Tue 2022-04-26 17:44:31 CEST; 8min ago Process: 31077 ExecStart=/usr/libexec/xdg-desktop-portal (code=killed, signal=TERM) Main PID: 31077 (code=killed, signal=TERM) CPU: 27ms Apr 26 17:43:01 cecil.afaics.de systemd[2271]: Starting Portal service... Apr 26 17:43:51 cecil.afaics.de xdg-desktop-por[31077]: Failed to create settings proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached Apr 26 17:43:51 cecil.afaics.de xdg-desktop-por[31077]: No skeleton to export Apr 26 17:44:16 cecil.afaics.de xdg-desktop-por[31077]: Failed to create file chooser proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached Apr 26 17:44:16 cecil.afaics.de xdg-desktop-por[31077]: No skeleton to export Apr 26 17:44:31 cecil.afaics.de systemd[2271]: xdg-desktop-portal.service: start operation timed out. Terminating. Apr 26 17:44:31 cecil.afaics.de systemd[2271]: xdg-desktop-portal.service: Failed with result 'timeout'. Apr 26 17:44:31 cecil.afaics.de systemd[2271]: Failed to start Portal service. % systemctl --user status xdg-desktop-portal-gtk.service x xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation) Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal-gtk.service; static) Active: failed (Result: exit-code) since Tue 2022-04-26 17:43:01 CEST; 9min ago Process: 31085 ExecStart=/usr/libexec/xdg-desktop-portal-gtk (code=exited, status=1/FAILURE) Main PID: 31085 (code=exited, status=1/FAILURE) CPU: 6ms Apr 26 17:43:01 cecil.afaics.de systemd[2271]: Starting Portal service (GTK/GNOME implementation)... Apr 26 17:43:01 cecil.afaics.de xdg-desktop-por[31085]: cannot open display: Apr 26 17:43:01 cecil.afaics.de systemd[2271]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE Apr 26 17:43:01 cecil.afaics.de systemd[2271]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'. Apr 26 17:43:01 cecil.afaics.de systemd[2271]: Failed to start Portal service (GTK/GNOME implementation). % dpkg -l xdg-desktop-portal-gtk xdg-desktop-portal Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==--- ii xdg-desktop-portal 1.14.3-1 amd64desktop integration portal for Flatpak and Snap ii xdg-desktop-portal-gtk 1.14.0-1 amd64GTK+/GNOME portal backend for xdg-desktop-portal Neither snap nor flatpak are installed. Regards Harri
Bug#965736: msp430mcu: diff for NMU version 20120406-2.2
Control: tags 965736 + patch Control: tags 965736 + pending Dear maintainer, I've prepared an NMU for msp430mcu (versioned as 20120406-2.2) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. diff -Nru msp430mcu-20120406/debian/changelog msp430mcu-20120406/debian/changelog --- msp430mcu-20120406/debian/changelog 2021-01-03 11:45:50.0 -0300 +++ msp430mcu-20120406/debian/changelog 2022-04-22 14:18:57.0 -0300 @@ -1,3 +1,14 @@ +msp430mcu (20120406-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Using new DH level format. Consequently: + - debian/compat: removed. + - debian/control: changed from 'debhelper' to 'debhelper-compat' in +Build-Depends field and bumped level to 13. + - Closes: #965736 + + -- Guilherme de Paula Xavier Segundo Fri, 22 Apr 2022 14:18:57 -0300 + msp430mcu (20120406-2.1) unstable; urgency=medium * Non maintainer upload by the Reproducible Builds team. diff -Nru msp430mcu-20120406/debian/compat msp430mcu-20120406/debian/compat --- msp430mcu-20120406/debian/compat 2012-05-10 12:16:44.0 -0300 +++ msp430mcu-20120406/debian/compat 1969-12-31 21:00:00.0 -0300 @@ -1 +0,0 @@ -5 diff -Nru msp430mcu-20120406/debian/control msp430mcu-20120406/debian/control --- msp430mcu-20120406/debian/control 2012-05-10 12:16:44.0 -0300 +++ msp430mcu-20120406/debian/control 2022-04-22 14:18:57.0 -0300 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Luca Bruno Standards-Version: 3.9.3 -Build-Depends: debhelper (>= 7) +Build-Depends: debhelper-compat (= 13) Package: msp430mcu Architecture: all
Bug#977835: Please package the lastest version >= 3.5.2
(warning, bit of rambling, plus I was interruped multiple times while
writing this and not fully awake yet either)
Nicholas D Steeves dixit:
>In an earlier update you mentioned that there were numerous regressions
>and problems with these new releases. Are these limited to non-dfsg
No, they are core UX, such as note input mode.
>Would it be useful to start a Musescore team to divide the workload,
Unclear, probably not.
I’ve got somewhat concrete plans. The situation with MuseScore 3 is
as follows:
• we currently have 3.2.3 in Debian, which is suitable for almost all
workflows 3.6.2 (the current upstream release) is, with the notable
exceptions being playable chord symbols and the new Leland font (we
*do* have the new MScore font)
• our 3.2.3 is fully compatible with mu͒.com
• I personally have issues with the 3.3+ regressions as stated above
• upstream’s 3.6.2 is the last 3.x release they want to publish, they
are politically interested in mu͒4 being the next release, but that’s
nowhere near ready yet
‣ if a 4.x is released, we’ll have to keep 3.x anyway, for old scores,
just like we need to keep 2.x around
• upstream’s 3.6.2 is also fully compatible with mu͒.com, other than
some changes to mu͒.com’s backend code that sometimes also affect 3.2.3
• 3.6.2 is a rather old (2021-02-08) and *also* buggy release
• there’s a community 3.7 effort that’s already got no less than 323
commits with bugfixes relative to 3.6.2
‣ this is what I’d probably work on if not for…
‣ this is completely unsupported on mu͒.com *and* by upstream formally
‣ it has no releases, only git snapshots, with occasional rebases,
and occasionally introduces regressions on itself
At this point in time, I believe that keeping the 3.2.3 we have and
backporting bugfixes to that, in the musescore3 package, and packaging
musescore4 once it’s out, is (given effort/gain) the best thing to do.
You *can* help in identifying commits that have gone into 3.3+ that
correct issues, I’m aware of at least the frame vs. pagebreak one.
However, we *cannot* backport some changes because they alter the
file format and the mu͒.com (and 3.3+) importers will see it’s a 3.2
file and therefore expect certain issues to be present. I’m aware
there’s at least one change we cannot do.
Note that our 3.2 package already has about a hundred backported
fixes already, too… and also note that 3.3+ use QML much more, which
involves qtweb* stuff more…
We *can* package *either* 3.6.2 *or* the 3.7 community effort, but
almost certainly(?) not both, in addition to the aforementioned plan.
However:
• until the UX regressions are addressed (and we’re sure that there
are no other regressions against the very stable 3.2 codebase we
currently use), I’d prefer this to not replace the 3.2 package
‣ we do have musescore-snapshot, which we can use, even with sid
⇒ this name would fit the 3.7 community effort better ☻
• ftpmasters might eventually protest the addition of even more
musescoreXXX packages; we have justifyable reason for at least
musescore{2,3,4} and probably -snapshot
• losing mu͒.com support is certainly a disservice to users, but so
is updating to a >1-year-old known-buggy version :~
We could, on the other hand, package git master (“to be 4.x”) now
already, to get a feeling for it. I’d treat it as almost completely
new packaging project; certainly for d/copyright at least (much of
the old code was removed, almost all of it was moved path‑ and file‐
name-wise, and all was reindented). We could do it as m-snapshot in
experimental, or even as musescore4, going through ftpmaster review
for it (but maybe not this early yet?). Things to watch out:
• qtweb* stuff (not portable to all architectures, disable)
‣ also: phones home, e.g. I disabled the Start Centre in 3.x
because it loads from yandex.ru and lately also Google Analytics
• phoning home in general (update checker, etc.)
• parts of the playback functionality is now a “freeware” binary
add-on plugin only available from their in-program download store
• … maybe more
If you have interest in *that*, it might be more long-term beneficial.
They just (end of March 2022) released the first alpha of it. And I’ll
be available for help and review, too, of course. My current focus is
on backporting fixes to our known-good 3.2.3 version, though.
Hmm. I seem to have lost my mental thread here. Eh, anyway, written
a lot already — tell me what you think.
Bug#1010219: terminology: When Terminology is autostarted it launches without window decorations.
Package: terminology Version: 1.12.1-2 Severity: normal Dear Maintainer, I'm running KDE / Plasma, I've noticed that sometimes if I just restart my PC having not closed Terminology it is autostarted but launches without any window decorations or handles so you can't move it about. Luckily you can close it by typing exit. I also note that there is no transparency. I note that closing Terminology and reopening it fixes these issues I'm guessing that this is a KDE race condition type bug but none of the other apps that I use have this problem. I also notice that when I run Terminology from the launcher it opens so quickly that the launch feedback take a while to catch up. This is not a complaint btw :) Is there any way to slow down the startup that you know of? Or make Terminology check and wait for compositing / GL to start before it continues. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.4 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages terminology depends on: ii libc6 2.33-7 ii libecore-con1 1.26.2-1+b1 ii libecore-evas11.26.2-1+b1 ii libecore-file11.26.2-1+b1 ii libecore-imf1 1.26.2-1+b1 ii libecore-input1 1.26.2-1+b1 ii libecore-ipc1 1.26.2-1+b1 ii libecore1 1.26.2-1+b1 ii libedje1 1.26.2-1+b1 ii libeet1 1.26.2-1+b1 ii libefreet-bin 1.26.2-1+b1 ii libefreet1a 1.26.2-1+b1 ii libeina1a 1.26.2-1+b1 ii libelementary11.26.2-1+b1 ii libemotion1 1.26.2-1+b1 ii libethumb-client-bin 1.26.2-1+b1 ii libethumb-client1 1.26.2-1+b1 ii libevas1 1.26.2-1+b1 ii libevas1-engines-wayland 1.26.2-1+b1 ii libevas1-engines-x1.26.2-1+b1 ii terminology-data 1.12.1-2 terminology recommends no packages. Versions of packages terminology suggests: ii libelementary-bin 1.26.2-1+b1 pn libemotion-players -- no debconf information
Bug#1001074: ldns FTCBFS: python uses the build architecture library
Control: tag -1 + moreinfo Hello! On Fri, 3 Dec 2021 17:05:59 +0100 Helmut Grohne wrote: Source: ldns Version: 1.7.1-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs ldns fails to cross build from source, because the python build misdetects the python libraries and attempts to use the build architecture ones. To fix this, one has to export _PYTHON_SYSCONFIGDATA_NAME. When building a python extension with pybuild, this is handled by pybuild, but we don't have automation for this case. Please consider applying the attached patch. Your patch: + _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH) \ How does this work in relation to #952844 ? I'm not a python expert, never dealt with python actually, and especially I know nothing about these internal variables, what does they mean. Is it documented somewhere? Are they stable (ie, will it work with/for future python versions)? (From the name of this var it does not seem so). Thanks, /mjt
Bug#1010218: armnn FTCBFS: multiple reasons
Source: armnn
Version: 20.08-10
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs
armnn fails to cross build from source for a fair number of reasons. The
majority of them are issues with Build-Depends. Beyond that, setup.py
needs to be told to perform a cross build and it needs to avoid
importing the cross built extension module. Please consider applying the
attached patch.
Helmut
--- armnn-20.08/debian/changelog
+++ armnn-20.08/debian/changelog
@@ -1,3 +1,16 @@
+armnn (20.08-10.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: (Closes: #-1)
++ Multiarchify python Build-Depends.
++ Drop python3-all as it only builds for the default python.
++ Annotate python3-numpy build dependency with :native.
++ Export cross compilation variables for setup.py
++ Let dpkg's architecture.mk initialize architecture variables.
++ Patch setup.py to avoid importing the cross built _pyarmnn_version.
+
+ -- Helmut Grohne Tue, 26 Apr 2022 17:28:39 +0200
+
armnn (20.08-10) unstable; urgency=medium
* Build with gcc-11 (Closes: #983969)
--- armnn-20.08/debian/control
+++ armnn-20.08/debian/control
@@ -8,8 +8,8 @@
libboost-log-dev (>= 1.64), libboost-program-options-dev (>= 1.64),
cmake, debhelper-compat (= 12), valgrind, libflatbuffers-dev,
libarm-compute-dev [arm64 armhf],
- swig (>= 4.0.1-5), dh-python, python3-all, python3-setuptools,
- python3-dev, python3-numpy, xxd, flatbuffers-compiler, chrpath
+ swig (>= 4.0.1-5), dh-python, python3-setuptools,
+ libpython3-dev, python3-dev:any, python3-numpy:native, xxd,
flatbuffers-compiler, chrpath
Standards-Version: 4.5.0
Vcs-Git: https://salsa.debian.org/deeplearning-team/armnn.git
Vcs-Browser: https://salsa.debian.org/deeplearning-team/armnn
--- armnn-20.08/debian/patches/cross.patch
+++ armnn-20.08/debian/patches/cross.patch
@@ -0,0 +1,21 @@
+--- a/python/pyarmnn/setup.py
b/python/pyarmnn/setup.py
+@@ -29,9 +29,6 @@
+ INCLUDE_ENV_NAME = "ARMNN_INCLUDE"
+
+
+-def check_armnn_version(*args):
+-pass
+-
+ __current_dir = os.path.dirname(os.path.realpath(__file__))
+
+ exec(open(os.path.join(__current_dir, 'src', 'pyarmnn', '_version.py'),
encoding="utf-8").read())
+@@ -63,8 +60,6 @@
+
+ if ext.name == 'pyarmnn._generated._pyarmnn_version':
+ sys.path.append(os.path.abspath(os.path.join(self.build_lib,
str(Path(ext._file_name).parent
+-from _pyarmnn_version import GetVersion
+-check_armnn_version(GetVersion(), __arm_ml_version__)
+
+ def copy_extensions_to_source(self):
+
--- armnn-20.08/debian/patches/series
+++ armnn-20.08/debian/patches/series
@@ -13,3 +13,4 @@
disable-unittests-that-can-cause-intermi
set-error-tests-by-name.patch
fix-gcc11-ftbfs.patch
+cross.patch
--- armnn-20.08/debian/rules
+++ armnn-20.08/debian/rules
@@ -1,4 +1,5 @@
#!/usr/bin/make -f
+include /usr/share/dpkg/architecture.mk
# See debhelper(7) (uncomment to enable)
# output every command that modifies files on the build system.
export DH_VERBOSE = 1
@@ -24,6 +25,8 @@
PYTHON_INCLUDE_DIR=$(shell python3 -c "from distutils.sysconfig import
get_python_inc; print(get_python_inc())")
PYTHON_LIBRARY=$(shell python3 -c "import distutils.sysconfig as sysconfig;
print(sysconfig.get_config_var('LIBDIR'))")
+export _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__${DEB_HOST_MULTIARCH}
+export _PYTHON_HOST_PLATFORM=${DEB_HOST_ARCH_OS}-$(if $(filter
amd64,${DEB_HOST_ARCH}),x86_64,${DEB_HOST_ARCH})
export DH_VERBOSE=1
%:
Bug#1010217: python3-pyarmnn should recommend some backends
Package: python3-pyarmnn Version: 20.08-10 Severity: wishlist Hi Wookey, I think python3-pyarmnn is pretty much useless unless you also install some backends. Which backends to install clearly depends on the relevant application, so a hard dependency is not reasonable. However having python3-pyarmnn recommend libarmnn-*-backend* would be very useful to improve the user experience of someone installing the package without much clue. Helmut
Bug#1010216: usetex=True won't work without file type1ec.sty from package cm-super-minimal
Package: python3-matplotlib
Source: matplotlib (3.5.1-2)
Version: 3.5.1-2+b1
Run a plot script that contains
from matplotlib import rc
rc('text', usetex=True)
and makes use of LaTeX markup (some labels containing "$...$").
Execution will fail with a long traceback and an error message from LaTeX,
appended below.
Cause:
According to https://github.com/matplotlib/matplotlib/issues/16911,
Matplotlib v3.2.1 introduced the dependence on file type1ec.sty
"so that unicode input works (#14146 and linked issues)".
Proposed solution:
Add package cm-super-minimal to list of suggested packages.
In a separate report, I will propose to elevate LaTeX dependencies
from "Suggests" to "Recommends" or "Depends".
## Error message
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 233, in
_run_checked_subprocess
report = subprocess.check_output(
File "/usr/lib/python3.10/subprocess.py", line 420, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.10/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['latex', '-interaction=nonstopmode',
'--halt-on-error', '../1acea6f6c115d0ec7a634ed0529287b9.tex']' returned non-zero
exit status 1.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3.10/tkinter/__init__.py", line 1921, in __call__
return self.func(*args)
File "/usr/lib/python3.10/tkinter/__init__.py", line 839, in callit
func(*args)
File "/usr/lib/python3/dist-packages/matplotlib/backends/_backend_tk.py",
line 251, in idle_draw
self.draw()
File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_tkagg.py",
line 9, in draw
super().draw()
File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py",
line 436, in draw
self.figure.draw(self.renderer)
File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73, in
draw_wrapper
result = draw(artist, renderer, *args, **kwargs)
File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in
draw_wrapper
return draw(artist, renderer)
File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2810, in draw
mimage._draw_list_compositing_images(
File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132, in
_draw_list_compositing_images
a.draw(renderer)
File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in
draw_wrapper
return draw(artist, renderer)
File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082, in
draw
mimage._draw_list_compositing_images(
File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132, in
_draw_list_compositing_images
a.draw(renderer)
File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in
draw_wrapper
return draw(artist, renderer)
File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1159, in draw
ticklabelBoxes, ticklabelBoxes2 = self._get_tick_bboxes(ticks_to_draw,
File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1085, in
_get_tick_bboxes
return ([tick.label1.get_window_extent(renderer)
File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1085, in
return ([tick.label1.get_window_extent(renderer)
File "/usr/lib/python3/dist-packages/matplotlib/text.py", line 910, in
get_window_extent
bbox, info, descent = self._get_layout(self._renderer)
File "/usr/lib/python3/dist-packages/matplotlib/text.py", line 309, in
_get_layout
_, lp_h, lp_d = renderer.get_text_width_height_descent(
File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py",
line 259, in get_text_width_height_descent
w, h, d = texmanager.get_text_width_height_descent(
File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 335, in
get_text_width_height_descent
dvifile = self.make_dvi(tex, fontsize)
File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 271, in
make_dvi
self._run_checked_subprocess(
File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 241, in
_run_checked_subprocess
raise RuntimeError(
RuntimeError: latex was not able to process the following string:
b'lp'
Here is the full report generated by latex:
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2022/dev/Debian)
(preloaded format=latex)
restricted \write18 enabled.
entering extended mode
(../1acea6f6c115d0ec7a634ed0529287b9.tex
LaTeX2e <2021-11-15> patch level 1
L3 programming layer <2022-01-21>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/type1cm/type1cm.sty)
Bug#862207: error: libcrypto does not provide GOST
Control: tag -1 + moreinfo On Tue, 9 May 2017 21:44:45 +0200 martin f krafft wrote: Package: ldnsutils Version: 1.7.0-1 Severity: normal When trying ti use ldns-key2ds with -g, I get an error about GOST not being available. % ldns-key2ds -g -n _combined.key error: libcrypto does not provide GOST Either the option should be disabled, or ldns-key2ds linked with a libcrypto that provides GOST. Well, GOST comes as an add-on to libcrypto. So if you install such an add-on on your system, everything will work. If we disable GOST for ldns, we'll got another bugreport, saying GOST is not enabled even if ldns supports it. I think it's best to keep it the way it is now, how do you think? /mjt
Bug#1010025: ghc: Haddock fails with internal error when calculating transitive dependencies
On Tue, 26 Apr 2022, Felix Lechner wrote: On Tue, Apr 26, 2022 at 7:23 AM Scott Talbert wrote: it's a core package and I'm new here I'm also not the right person to merge it, but I think Debian may be getting a new GHC version soon. Was the fix applied upstream? It was merged in haskell/cabal [1]. Not sure if it has trickled down into a ghc source release yet. Scott [1] https://github.com/haskell/cabal/commit/7ffcd512430e264d3e7d26a93fa8d8508497e82d
Bug#1010212: rust-ring: please update to newest v0.16.20
Quoting Jonas Smedegaard (2022-04-26 16:53:32) > Severity: important Sorry, forgot to mention: Severity raised due to a general concern about security-related bugfixes in the 1.5 years of upstream changes. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#934258: Current status?
Le 25/04/2022 à 12:45, Roland Mas a écrit : I've been delayed for a while, but I'm back on track. I'll push/upload a big handful of packages, both to NEW and to Salsa, and update my TODO-list accordingly. I'll send the update to this bug too. What are you working on? Mostly NodeJS packages… Is there a direction where I can push? Certainly… but give me a day or two so that I can push my work in order to avoid duplicating efforts :-) There. I'm up-to-date with my past self, and here's what's missing (we're talking about NodeJS packages). Not started on my side: - codemirror - y-codemirror - vscode-debugprotocol - xterm-addon-fit - nteract/transform-vdom - vega-embed - vega-lite (…and probably dependencies behind them) Started but not working: - blueprintjs (I pushed my current state of affairs; fails to build so far, but a starting point) - fortawesome-fontawesome-free (see my other mail: no source available, and I don't know what to do; split the part of jupyterlab that depend on it into a separate package in contrib? try to make do with a previous version?) Probably soon to be uploaded: - react-paginate and dependencies (but I have skeleton packages for that chain -- I'll push them even as WIP, and upload when ready) - react-highlighter (same thing) - react-json-tree which is part of redux-devtools (same thing) I'm welcoming help in the first two sections. Roland.
Bug#1004342: RFS: golang-github-gabriel-vasile-mimetype/1.4.0+dfsg1-2~bpo11+1 -- fast Go library for detecting MIME types and extensions based on magic numbers
Control: tags -1 moreinfo On Wed, 09 Feb 2022 11:26:24 + Martin Dosch wrote: Am 9. Februar 2022 11:05:47 UTC schrieb Bastian Germann : >Why do you need this backport and have you asked the maintainer team if they are okay with it? Because I want to bring go-sendxmpp to bullseye and this is a build requirement. I didn't know that I should have asked the maintainers, sorry. Please untag moreinfo when you have had a conversation with them. Easiest way is filing a bug on the package asking for a backport.
Bug#1010215: sympy breaks einsteinpy autopkgtest: name 'numpy' is not defined
Source: sympy, einsteinpy
Control: found -1 sympy/1.10.1-1
Control: found -1 einsteinpy/0.3.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of sympy the autopkgtest of einsteinpy fails in
testing when that autopkgtest is run with the binary packages of sympy
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
sympy from testing1.10.1-1
einsteinpy from testing0.3.0-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of sympy to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=sympy
https://ci.debian.net/data/autopkgtest/testing/amd64/e/einsteinpy/21184013/log.gz
=== FAILURES
===
___ test_lambdify_with_args
def test_lambdify_with_args():
x, y = symbols("x y")
T = BaseRelativityTensor([x + y, x], (x, y), config="l")
args, f = T.tensor_lambdify(y, x)
arr = np.array(f(2, 1))
/usr/lib/python3/dist-packages/einsteinpy/tests/test_symbolic/test_tensor.py:251:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
y = 2, x = 1
def _lambdifygenerated(y, x):
return numpy.array((x + y, x))
E NameError: name 'numpy' is not defined
:2: NameError
=== warnings summary
===
../../../../usr/lib/python3/dist-packages/einsteinpy/ijit.py:30
../../../../usr/lib/python3/dist-packages/einsteinpy/ijit.py:30
/usr/lib/python3/dist-packages/einsteinpy/ijit.py:30: UserWarning:
Could not import numba package. All einsteinpy functions will work
properly but the CPU intensive algorithms will be slow. Consider
installing numba to boost performance.
tests/test_plotting/test_fractal.py: 64 warnings
/usr/lib/python3/dist-packages/einsteinpy/plotting/fractal.py:20:
DeprecationWarning:
`np.complex` is a deprecated alias for the builtin `complex`. To
silence this warning, use `complex` by itself. Doing this will not
modify any behavior and is safe. If you specifically wanted the numpy
scalar type, use `np.complex128` here.
Deprecated in NumPy 1.20; for more details and guidance:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info
FAILED tests/test_symbolic/test_tensor.py::test_lambdify_with_args -
NameErro...
1 failed, 230 passed, 8 xfailed, 640002 warnings in 322.36s
(0:05:22) =
autopkgtest [12:16:46]: test command1
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1010214: paramiko breaks libcloud autopkgtest: SSHException not raised by connect
Source: paramiko, libcloud
Control: found -1 paramiko/2.10.3-1
Control: found -1 libcloud/3.4.1-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of paramiko the autopkgtest of libcloud fails in
testing when that autopkgtest is run with the binary packages of
paramiko from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
paramiko from testing2.10.3-1
libcloud from testing3.4.1-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of paramiko to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=paramiko
https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcloud/21182944/log.gz
=== FAILURES
===
__ ParamikoSSHClientTests.test_key_file_non_pem_format_error
___
self = testMethod=test_key_file_non_pem_format_error>
@patch('paramiko.SSHClient', Mock)
@unittest.skipIf(paramiko_version >= '2.7.0',
'New versions of paramiko support OPENSSH key format')
def test_key_file_non_pem_format_error(self):
path = os.path.join(os.path.dirname(__file__),
'fixtures', 'misc',
'test_rsa_non_pem_format.key')
# Supplied as key_material
with open(path, 'r') as fp:
private_key = fp.read()
conn_params = {'hostname': 'dummy.host.org',
'username': 'ubuntu',
'key_material': private_key}
mock = ParamikoSSHClient(**conn_params)
expected_msg = 'Invalid or unsupported key type'
assertRaisesRegex(self, paramiko.ssh_exception.SSHException,
expected_msg, mock.connect)
test/compute/test_ssh_client.py:167: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3/dist-packages/libcloud/utils/py3.py:145: in
assertRaisesRegex
return getattr(self, 'assertRaisesRegex')(*args, **kwargs)
E AssertionError: SSHException not raised by connect
-- Captured log call
---
DEBUGlibcloud.compute.ssh:ssh.py:365 Connecting to server
OpenPGP_signature
Description: OpenPGP digital signature
Bug#965744: nat: Removal of obsolete debhelper compat 5 and 6 in bookworm
Hi all,
I've fixed this bug. I'll do an NMU very soon. The debdiff is as attachment.
The major changes are:
1. Use debhelper 13.
2. Use DebSrc3.0. So we split diff.gz to debian/patches
If no one object this after 10 days. I'll upload this to delay/10 queue.
Yours,
Paul
diff -Nru nat-1.0/client.c nat-1.0/client.c
--- nat-1.0/client.c 2022-04-26 22:51:30.0 +0800
+++ nat-1.0/client.c 1997-02-17 11:18:04.0 +0800
@@ -2711,7 +2711,7 @@
(CVAL (inbuf, smb_rcls), SVAL (inbuf, smb_err));
/* this "can't happen" but does against misconfigured samba, fer example */
if ((cur_serr == 2) && (sec_mode & 1))
- DEBUG (1,("Wanted TCon passwd in USER-mode sec!!!\n"));
+ DEBUG (1,("Wanted TCon passwd in USER-mode sec?!??!\n"));
return(False);
} /* if smb_rcls err */
@@ -3521,7 +3521,7 @@
natprintf("[*]--- CONNECTED with name: %s\n", p);
#endif
-DEBUG(1,("session to %s (0x%x) open\n", desthost, name_type));
+DEBUG(0,("session to %s (0x%x) open\n", desthost, name_type));
phase = 2;
goto phase_2;
} else {
@@ -3613,7 +3613,7 @@
username[0] = '\0';
while (!done) {
if (!userfd || !passfd)
- done = !uppair();
+ uppair();
else {
if (fgets(password, sizeof(password), passfd) == NULL) {
rewind(passfd);
@@ -3636,11 +3636,8 @@
}
if ((! *username) && (! *password))
- done = !uppair();/* sleaze for NT */
+ uppair();/* sleaze for NT */
-if (done)
-break; /* Stop when uppair is done */
-
#ifdef VERBOSE
natprintf("[*]--- Attempting to connect with Username: `%s' Password: `%s'\n",
username, password);
diff -Nru nat-1.0/debian/changelog nat-1.0/debian/changelog
--- nat-1.0/debian/changelog 2022-04-26 22:51:30.0 +0800
+++ nat-1.0/debian/changelog 2022-04-26 22:48:16.0 +0800
@@ -1,3 +1,15 @@
+nat (1:1.0-6.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Migrate to debhelper-compat version 13 (Closes: #965744, #1004018)
+- Delete debian/compat
+- Build-Depends on debhelper-compat (= 13)
+ * Use DebSrc3.0 (quilt)
+- Split diff.gz to debian/patches
+ * debian/control: Change Priority from extra to optional
+
+ -- Ying-Chun Liu (PaulLiu) Tue, 26 Apr 2022 22:48:16 +0800
+
nat (1:1.0-6) unstable; urgency=medium
* include.h: Apply patch provided by Cyril Roelandt to fix
diff -Nru nat-1.0/debian/compat nat-1.0/debian/compat
--- nat-1.0/debian/compat 2022-04-26 22:51:30.0 +0800
+++ nat-1.0/debian/compat 1970-01-01 08:00:00.0 +0800
@@ -1 +0,0 @@
-5
diff -Nru nat-1.0/debian/control nat-1.0/debian/control
--- nat-1.0/debian/control 2022-04-26 22:51:30.0 +0800
+++ nat-1.0/debian/control 2022-04-26 22:26:59.0 +0800
@@ -1,8 +1,8 @@
Source: nat
Section: admin
-Priority: extra
+Priority: optional
Maintainer: Javier Fernandez-Sanguino Peña
-Build-Depends: debhelper (>> 3.0.0)
+Build-Depends: debhelper-compat (= 13)
Standards-Version: 3.9.6
Homepage: http://www.tux.org/pub/security/secnet/tools/nat10/
diff -Nru nat-1.0/debian/patches/0001_add_samples.patch nat-1.0/debian/patches/0001_add_samples.patch
--- nat-1.0/debian/patches/0001_add_samples.patch 1970-01-01 08:00:00.0 +0800
+++ nat-1.0/debian/patches/0001_add_samples.patch 2022-04-26 22:21:34.0 +0800
@@ -0,0 +1,99 @@
+Index: nat-1.0/samples/localhost-samba.log
+===
+--- /dev/null
nat-1.0/samples/localhost-samba.log
+@@ -0,0 +1,38 @@
++
++[*]--- Checking host: 127.0.0.1
++[*]--- Obtaining list of remote NetBIOS names
++[*]--- Remote systems name tables:
++
++ LINUX
++ LINUX
++ LINUX
++ __MSBROWSE__
++ SAMBA
++ SAMBA
++ SAMBA
++ SAMBA
++
++[*]--- Attempting to connect with name: *
++[*]--- CONNECTED with name: *
++[*]--- Attempting to connect with protocol: MICROSOFT NETWORKS 1.03
++[*]--- Remote server wants us to encrypt, telling it not to
++[*]--- Attempting to connect with protocol: PC NETWORK PROGRAM 1.0
++[*]--- Attempting to establish session
++
++[*]--- Attempting to access share: \\*\
++[*]--- Unable to access
++
++[*]--- Attempting to access share: \\*\ADMIN$
++[*]--- Unable to access
++
++[*]--- Attempting to access share: \\*\C$
++[*]--- Unable to access
++
++[*]--- Attempting to access share: \\*\D$
++[*]--- Unable to access
++
++[*]--- Attempting to access share: \\*\ROOT
++[*]--- Unable to access
++
++[*]--- Attempting to access share: \\*\WINNT$
++[*]--- Unable to access
+Index: nat-1.0/samples/w2000as.log
+===
+--- /dev/null
nat-1.0/samples/w2000as.log
+@@ -0,0 +1,51 @@
++
++[*]--- Checking host: 192.168.0.159
++[*]--- Obtaining list of remote NetBIOS names
++[*]--- Remote systems name tables:
++
++ INet~Services
++ IS~W2000AS
++ W2000AS
++ W2000AS
++ WORKGROUP
++ ADMINISTRATOR
++ W2000AS
++ WORKGROUP
++
Bug#716060: [Mayhem] Bug report on ldnsutils: ldns-keyfetcher crashes with exit status 139
Control: forcemerge -1 716056 716074 Control: tag -1 + confirmed upstream Control: found -1 1.8.1-1 Control: retitle -1 numerous input/options parsing errors in ldns example utilities ldns-dpa -f "&" -- -f for expression, a & b ldns-keyfetcher '. .' -v (does not work w/o -v) ldns-zcat /dev/null /mjt
Bug#1010213: ITP: python-flask-seeder
Package: wnpp Severity: wishlist Owner: Joao Pedro Elias de Moura * Package name : Flask-Seeder Version : v1.1.1 Upstream Author : Diddi Oskarsson * URL : https://pypi.org/project/Flask-Seeder * License : MIT Programming Lang: Python3 Description : Flask-Seeder is a Flask extension to help with seeding database with initial data This extensions primary focus is to help populating data once, for example in a demo application where the database might get wiped over and over but you still want users to have some basic data to play around with. I intend to package debian-image-finder [1] and flask-seeder is one of its dependencies. I also plan to package under the umbrella of the Debian Python Team. [1]: https://image-finder.debian.net/
Bug#1010212: rust-ring: please update to newest v0.16.20
Source: rust-ring Version: 0.16.9-4 Severity: important Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The release of Rust crate ring currently in Debian is v0.16.9 which was released upstream 2.5 years ago. Upstream has since issued 11 releases with same minor version, where the newest - v0.16.20 - was released about a year ago so seemingly relatively stable. Several applications I am working on packaging require newer release of ring, which is unsurprising given that upstream explicitly state the following: > Users of ring should always use the latest released version, and users > should upgrade to the latest released version as soon as it is > released. Please upgrade to newest upstream release. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJoB2kACgkQLHwxRsGg ASGtlA//V1It4otJ4+zrdqJWTKO45zwqX4+UxbnOJ4yWxykQ4zKqB+D2CjwIsfBr spNGFQP/1QM4h7o2SabqSk0MBseBqw1yVbYytE6uFPkIWX359WWrKBNf6uEHrq47 +iPz+daUIhgo/mFnDlIWZzL0NUl7Ub3IM4MI3oD8JOVH+oR1ye5QK7bvvkjid9iZ 3JV/MwATQCG5Arf+WpRBC5E9WHd1Ni9Ffpa7LQyMKgGuvH18QdbbB0fJOJblRThH zsrOEyx0ssJOscTL4/SwGSMbg1sRgTXAb1ezBARaJf6ltJEeHpf/gtbFKw+vL329 p8jN80lZ17sI80rY398crgAQby6w4JeoRh1A8/kmHaBmSv1NJSagd4Usab8WraJl tI8AHFDeJ85ZfPS2PB6AG6ooGcsEkyD2Lp1FY4VD/xXh7HfxkvPsMugVyL1ZCeeO eAyQnFyzDq1HStQPNlsxt26PW+ab36p4h6+ViP64Qs4Vl67Xt7MKGqIzq4mMIf6y PUqSLTDZJMWHOdHlzF/GtqN3hCSBvqLAQheD4TojMjLRnPeIenYSpX1EcN7KBsM0 sppaN+JEQP0QUZVmpn+05oh+WXvpzNbEVF89F/mpbcoZxgXT6z+fB1slqfmpatHS Yau17hEZ5HAVUBMkPslqRvnyDioHrlGwwco4sT6w7/q8gRwweH8= =t0yr -END PGP SIGNATURE-
Bug#716056: [Mayhem] Bug report on ldnsutils: ldns-dpa crashes with exit status 139
In order to make this *significantly* easier, the whole thing boils down to: ldns-dpa -f "&" /mjt
Bug#1010211: bullseye-pu: package grunt/1.3.0-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
grunt is vulnerable to path traversal
[ Impact ]
Medium security issue
[ Tests ]
Test passed, including new test
[ Risks ]
low risk, patch is trivial
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
Copy files and directories instead of symbolic links
[ Other info ]
Upstream patch applied without any change
Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index a28861f..23c3145 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+grunt (1.3.0-1+deb11u1) bullseye; urgency=medium
+
+ * Team upload
+ * Fix path traversal (Closes: #1009676, CVE-2022-0436)
+
+ -- Yadd Tue, 26 Apr 2022 16:38:52 +0200
+
grunt (1.3.0-1) unstable; urgency=medium
* Team upload
diff --git a/debian/patches/CVE-2022-0436.patch
b/debian/patches/CVE-2022-0436.patch
new file mode 100644
index 000..e10a16d
--- /dev/null
+++ b/debian/patches/CVE-2022-0436.patch
@@ -0,0 +1,81 @@
+Description: Handles symlinks by coping them as files or directories
+ This fixes "Path Traversal in GitHub repository gruntjs/grunt"
+Author: Vlad Filippov
+Origin: upstream, https://github.com/gruntjs/grunt/commit/aad3d452
+Bug: https://huntr.dev/bounties/f55315e9-9f6d-4dbb-8c40-bae50c1ae92b
+Bug-Debian: https://bugs.debian.org/1009676
+Forwarded: not-needed
+Reviewed-By: Yadd
+Last-Update: 2022-04-26
+
+--- a/lib/grunt/file.js
b/lib/grunt/file.js
+@@ -292,8 +292,11 @@
+ // Read a file, optionally processing its content, then write the output.
+ // Or read a directory, recursively creating directories, reading files,
+ // processing content, writing output.
++// Handles symlinks by coping them as files or directories.
+ file.copy = function copy(srcpath, destpath, options) {
+- if (file.isDir(srcpath)) {
++ if (file._isSymbolicLink(srcpath)) {
++file._copySymbolicLink(srcpath, destpath);
++ } else if (file.isDir(srcpath)) {
+ // Copy a directory, recursively.
+ // Explicitly create new dest directory.
+ file.mkdir(destpath);
+@@ -449,6 +452,24 @@
+ }
+ };
+
++file._isSymbolicLink = function() {
++ var filepath = path.join.apply(path, arguments);
++ return fs.lstatSync(filepath).isSymbolicLink();
++};
++
++file._copySymbolicLink = function(srcpath, destpath) {
++ var destdir = path.join(destpath, '..');
++ var fileBase = path.basename(srcpath);
++ // Use the correct relative path for the symlink
++ if (!grunt.file.isPathAbsolute(srcpath)) {
++srcpath = path.relative(destdir, srcpath) || '.';
++ }
++ file.mkdir(destdir);
++ var mode = grunt.file.isDir(srcpath) ? 'dir' : 'file';
++ var destpath = path.join(destpath, fileBase);
++ return fs.symlinkSync(srcpath, destpath, mode);
++};
++
+ // Test to see if a filepath is contained within the CWD.
+ file.isPathInCwd = function() {
+ var filepath = path.join.apply(path, arguments);
+--- a/test/grunt/file_test.js
b/test/grunt/file_test.js
+@@ -893,5 +893,28 @@
+ test.ok(grunt.file.isPathInCwd(path.resolve('deep')), 'subdirectory is
in cwd');
+ test.done();
+ },
++'symbolicLinkCopy': function(test) {
++ test.expect(4);
++ var srcfile = new Tempdir();
++ fs.symlinkSync(path.resolve('test/fixtures/octocat.png'),
path.join(srcfile.path, 'octocat.png'), 'file');
++ // test symlink copy for files
++ var destdir = new Tempdir();
++ grunt.file.copy(path.join(srcfile.path, 'octocat.png'), destdir.path);
++ test.ok(fs.lstatSync(path.join(srcfile.path,
'octocat.png')).isSymbolicLink());
++ test.ok(fs.lstatSync(path.join(destdir.path,
'octocat.png')).isSymbolicLink());
++
++ // test symlink copy for directories
++ var srcdir = new Tempdir();
++ var destdir = new Tempdir();
++ var fixtures = path.resolve('test/fixtures');
++ var symlinkSource = path.join(srcdir.path, path.basename(fixtures));
++ console.log('symlinkSource', symlinkSource);
++ fs.symlinkSync(fixtures, symlinkSource, 'dir');
++
++ grunt.file.copy(symlinkSource, destdir.path);
++ test.ok(fs.lstatSync(symlinkSource).isSymbolicLink());
++ test.ok(fs.lstatSync(path.join(destdir.path,
path.basename(fixtures))).isSymbolicLink());
++ test.done();
++},
+ }
+ };
diff --git a/debian/patches/series b/debian/patches/series
index b8abb97..24fd9f9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
add-root-variable.patch
fix-for-coffescript.diff
adapt-gruntfile.patch
+CVE-2022-0436.patch
Bug#1004018: Is smb-nat still useful?
Hi Adrian, I just went into this package and found it might be still useful. The purpose of this package is different than the samba tools. This package is trying to test some simple security holes that a samba server might expose. It will try to iterate all public shares. And tries to login into it by common user names and passwords. So it seems to me that this package is still useful. I'll prepare a NMU soon. I'll send a debdiff, waiting for 10 days. And then I'll upload to delay/10 queue. Migrate to debhelper 13 and debsrc3.0 seems not very hard to me. Yours, Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#973260: apt --mark-auto sets already installed package to manually installed
Package: apt Version: 2.2.4 Severity: normal Dear maintainer, I think stumbled upon the same issue, with a simpler example, which is easier to debug. * What led up to the situation? A package, which was already automatically installed, shall be installed again as automatically installed. * What exactly did you do (or not do) that was effective (or ineffective)? $ apt-get install --mark-auto hello (The package name does not matter.) * What was the outcome of this action? [...] hello is already the newest version (2.10-2). hello set to manually installed. [...] * What outcome did you expect instead? [...] hello is already the newest version (2.10-2). [...] Note: "apt install --mark-auto hello" does work as expected, if the package was not installed before. I want to call apt from Ansible playbooks. Ansible playbooks shall be idempotent. The easiest way to create an idempotent playbook is to only use idempotent commands. This is why I would like apt to be idempotent. Best regards, Lars Dröge smime.p7s Description: S/MIME Cryptographic Signature
Bug#1010025: ghc: Haddock fails with internal error when calculating transitive dependencies
Hi Scott, On Tue, Apr 26, 2022 at 7:23 AM Scott Talbert wrote: > > it's a core package and I'm new here I'm also not the right person to merge it, but I think Debian may be getting a new GHC version soon. Was the fix applied upstream? Kind regards Felix Lechner
Bug#1010025: ghc: Haddock fails with internal error when calculating transitive dependencies
On Sat, 23 Apr 2022, Felix Lechner wrote: Hi Scott, Warning: The documentation for the following packages are not installed. No links will be generated to these packages: dlist-0.8.0.8, hashable-1.3.0.0, transformers-compat-0.6.5 Can you please try to see if the error goes away when those prerequisites are made available? I believe they are in: libghc-dlist-doc libghc-hashable-doc libghc-transformers-compat-doc Adding those BD's makes the warning about missing links go away, but doesn't fix the internal error. There's an upstream fix that seems to fix the error, though. I've created a merge request[1] with a cherry-pick of the upstream fix. I sent a MR since it's a core package and I'm new here, but it seems like a fairly straighforward fix. Let me know if anyone has any objections. Thanks, Scott [1] https://salsa.debian.org/haskell-team/DHG_packages/-/merge_requests/18
Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4
So, is there anything else needed on my side to help this? I can re-send the debdiff (the change against the previous one was the removal of closing of #1002059 from d/changelog which slipped there by mistake, and going from -1+deb11u4 to -1~deb11u4 per carnil@ suggestion. Thanks, /mjt
Bug#1010209: linux-image-5.17.0-1-amd64: sr0 and sr1 I/O errors in the journalctl logs when running Wine
Package: src:linux Version: 5.17.3-1 Severity: normal While looking at the journalctl logs, I've noticed the following errors that have been regularly occurring since March 1: Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#7 Sense Key : Not Ready [current] Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#7 Add. Sense: Medium not present - tray closed Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#7 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#8 unaligned transfer Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 26 15:22:01 cventin kernel: Buffer I/O error on dev sr0, logical block 0, async page read Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#9 unaligned transfer Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 26 15:22:01 cventin kernel: Buffer I/O error on dev sr0, logical block 1, async page read Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#10 unaligned transfer Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 2 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 26 15:22:01 cventin kernel: Buffer I/O error on dev sr0, logical block 2, async page read Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#11 unaligned transfer Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 3 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 26 15:22:01 cventin kernel: Buffer I/O error on dev sr0, logical block 3, async page read Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#12 unaligned transfer Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 26 15:22:01 cventin kernel: Buffer I/O error on dev sr0, logical block 4, async page read Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#13 unaligned transfer Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 5 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 26 15:22:01 cventin kernel: Buffer I/O error on dev sr0, logical block 5, async page read Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#14 unaligned transfer Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 6 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 26 15:22:01 cventin kernel: Buffer I/O error on dev sr0, logical block 6, async page read Apr 26 15:22:01 cventin kernel: sr 2:0:0:0: [sr0] tag#15 unaligned transfer Apr 26 15:22:01 cventin kernel: I/O error, dev sr0, sector 7 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 26 15:22:01 cventin kernel: Buffer I/O error on dev sr0, logical block 7, async page read Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#12 Sense Key : Not Ready [deferred] Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#12 Add. Sense: Medium not present - tray closed Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#12 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 Apr 26 15:22:02 cventin kernel: I/O error, dev sr1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#13 unaligned transfer Apr 26 15:22:02 cventin kernel: Buffer I/O error on dev sr1, logical block 0, async page read Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#14 unaligned transfer Apr 26 15:22:02 cventin kernel: Buffer I/O error on dev sr1, logical block 1, async page read Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#15 unaligned transfer Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#19 unaligned transfer Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#20 unaligned transfer Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#21 unaligned transfer Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#22 unaligned transfer Apr 26 15:22:02 cventin kernel: sr 3:0:0:0: [sr1] tag#23 unaligned transfer After a search for such errors on the web, I've eventually got https://forum.endeavouros.com/t/dvd-drive-constantly-throw-errors-on-idle-state/6241/15 where it was found that this occurs when running Wine. Indeed, I use Wine to test GNU MPFR, and I can reproduce the issue by just running "wine blah" (where blah.exe doesn't exist). -- Package-specific info: ** Version: Linux version 5.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-20) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 5.17.3-1 (2022-04-18) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.17.0-1-amd64 root=UUID=4bcb3bbd-f516-4ddf-be96-6fa3a8cdc8a0 ro quiet ** Tainted: POE (12289) * proprietary
Bug#1010210: ITP: orthanc-neuro -- Neuroimaging plugin for Orthanc
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: orthanc-neuro Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://book.orthanc-server.com/plugins/neuro.html * License : GPL Programming Lang: C++ Description : Neuroimaging plugin for Orthanc This package adds support for neuroimaging in Orthanc, notably to easily convert from DICOM to NIfTI.
Bug#1010146: modprobe: ERROR: could not insert 'amd_pstate': No such device
Package: src:linux Followup-For: Bug #1010146 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Tobias, The AMD P-State driver has been enabled in linux 5.17.3-1 available in testing/unstable. The kernel you are using does not include it. Cheers, Vincent -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYmf4nQAKCRAQn1qAt/bg AatkAP46KeDriC3sYK2cnwBEHUmYdD1CWNhAMYF9Tu4YrMJJTAD+J5NBDxUSddqR EP80CuI/o9PhPDmNCNZLwYunHwzEPAw= =Mv1P -END PGP SIGNATURE-
Bug#1010208: xfce4-datetime-plugin: icon xfce-schedule is absent
Package: xfce4-datetime-plugin Version: 0.8.1-1 Severity: normal X-Debbugs-Cc: serfyo...@yandex.ru Dear Maintainer, I have xfce4 v.4.16. In the source code folder in "panel-plugin/datetime.desktop" there is a line: Icon=xfce-schedule but the "xfce-schedule" icon itself has been absenting from the very beginning to this day. Because of this, for example, in the "Panel->Add new elements" line "Date and time" is displayed without an icon. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-datetime-plugin depends on: ii libc62.33-7 ii libglib2.0-0 2.72.1-1 ii libgtk-3-0 3.24.33-1 ii libpango-1.0-0 1.50.6+ds-2 ii libxfce4panel-2.0-4 4.16.4-1 ii libxfce4ui-2-0 4.16.1-1 ii libxfce4util74.16.0-1 xfce4-datetime-plugin recommends no packages. xfce4-datetime-plugin suggests no packages. -- no debconf information
Bug#1010207: import-orig: please provide a --force option
Package: git-buildpackage Version: 0.9.22 Severity: wishlist There are cases where "gbp import-orig --uscan" exits with a no-op although a new upstream version should be available: - a new repack level in d/watch; - new subcomponents in d/watch; In both cases, the new "upstream" part of the version number is actually increased (either with +dfsgX or +~csX.Y.Z if using subcomponents), but to get there you have to perform the ugly trick of setting the latest version number in d/changelog to 0, then running gbp import-orig --uscan, then changing the version number back to its previous value. I think a "gbp import-orig --uscan --force" option would be a nice addition; it should be a simple matter of running uscan with -ddd. Thanks, Roland. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-buildpackage depends on: ii devscripts 2.21.7~bpo11+1 ii git1:2.30.2-1 ii man-db 2.9.4-2 ii python33.9.2-3 ii python3-dateutil 2.8.1-6 ii python3-pkg-resources 52.0.0-4 ii sensible-utils 0.0.14 Versions of packages git-buildpackage recommends: ii cowbuilder0.89 ii pbuilder 0.231 ii pristine-tar 1.49 ii python3-requests 2.25.1+dfsg-2 Versions of packages git-buildpackage suggests: pn python3-notify2 ii sudo 1.9.5p2-3 ii unzip6.0-26 -- no debconf information
Bug#1010206: xfce4-datetime-plugin: icon xfce-schedule is nonexistent
Package: xfce4 Version: 4.14 Severity: normal X-Debbugs-Cc: serfyo...@yandex.ru Dear Maintainer, In the source code folder in "panel-plugin/datetime.desktop" there is a line: Icon=xfce-schedule but the "xfce-schedule" icon itself has been absenting from the very beginning to this day. Because of this, for example, in the "Panel->Add new elements" line "Date and time" is displayed without an icon. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-datetime-plugin depends on: ii libc62.33-7 ii libglib2.0-0 2.72.1-1 ii libgtk-3-0 3.24.33-1 ii libpango-1.0-0 1.50.6+ds-2 ii libxfce4panel-2.0-4 4.16.4-1 ii libxfce4ui-2-0 4.16.1-1 ii libxfce4util74.16.0-1 xfce4-datetime-plugin recommends no packages. xfce4-datetime-plugin suggests no packages. -- no debconf information
Bug#1003653: Revision of removal of rename.ul from package util-linux
On Wed, 20 Apr 2022 at 15:31:13 +0100, Matthew Vernon wrote: > ===Begin Resolution A > The Technical Committee overrides the util-linux maintainer, and requires > that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary > package built from src:util-linux. The package containing rename.ul must not > conflict with the rename package nor divert /usr/bin/rename. > ===End Resolution A > > ===Begin Resolution B > The Technical Committee overrides the util-linux maintainer, and requires > that util-linux's rename should be shipped in a binary package built from > src:util-linux. If this package Conflicts with the rename package, then it > must not contain any other binaries. > ===End Resolution B > > ===Begin Resolution N > None of the above > ===End Resolution N I vote A > B > N. smcv signature.asc Description: PGP signature
Bug#1010205: git-buildpackage: gbp import-orig does not store upstream signature in pristine-tar branch
Package: git-buildpackage
Version: 0.9.25
Severity: normal
I used the following command:
$ gbp import-orig --verbose --debian-branch=debian/unstable --pristine-tar
--upstream-signatures=yes --uscan
It does not store the upstream signature in the pristine-tar branch:
$ pristine-tar checkout --s signature rapid-photo-downloader_0.9.33.orig.tar.gz
fatal: path 'rapid-photo-downloader_0.9.33.orig.tar.gz.asc' does not exist in
'refs/heads/pristine-tar'
pristine-tar: git show
refs/heads/pristine-tar:rapid-photo-downloader_0.9.33.orig.tar.gz.asc failed
This is the output of the import-orig command. In the pristine-tar command,
--signature-file is missing.
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
gbp:debug: ['git', 'status', '--porcelain']
gbp:info: Launching uscan...
gpgv: Signatur vom Fr 11 Mär 2022 19:26:52 CET
gpgv:mittels RSA-Schlüssel
E26048A9F4A803B91CB1BD648005B1F36970BE28
gpgv: Korrekte Signatur von "Damon Lynch "
gpgv: alias "Damon Lynch "
gpgv: alias "Damon Lynch "
gpgv: alias "[invalid image]"
gbp:info: Using uscan downloaded tarball
../rapid-photo-downloader_0.9.33.orig.tar.gz
gbp:debug: Signature ../rapid-photo-downloader_0.9.33.orig.tar.gz found for
../rapid-photo-downloader_0.9.33.orig.tar.gz.asc
What is the upstream version? [0.9.33]
gbp:debug: ['git', 'tag', '-l', 'v0.9.33']
gbp:debug: tar ['-C', '../tmp5kw6qihm', '-a', '-xf',
'../rapid-photo-downloader_0.9.33.orig.tar.gz'] []
gbp:debug: Unpacked '../rapid-photo-downloader_0.9.33.orig.tar.gz' to
'../tmp5kw6qihm/rapid-photo-downloader-0.9.33'
gbp:info:
gbp:info: Importing '../rapid-photo-downloader_0.9.33.orig.tar.gz' to branch
'upstream'...
gbp:info: Source package is rapid-photo-downloader
gbp:info: Upstream version is 0.9.33
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
gbp:debug: ['git', 'commit-tree', 'ff2f5aee0f4ef0258bea6cc2471ea3db545132b3',
'-p', '8b0ecdf9b84c65e1869fa995a6f700f3278a5632']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 0.9.33',
'refs/heads/upstream', '3eea0aa540a8efda7052e4da78379d6c80adbb8c',
'8b0ecdf9b84c65e1869fa995a6f700f3278a5632']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
gbp:debug: ['git', 'ls-tree', '-z', 'upstream', '--']
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: pristine-tar [] ['commit',
'../rapid-photo-downloader_0.9.33.orig.tar.gz',
'ff2f5aee0f4ef0258bea6cc2471ea3db545132b3']
gbp:debug: ['git', 'tag', '-m', 'Upstream version 0.9.33', 'v0.9.33',
'3eea0aa540a8efda7052e4da78379d6c80adbb8c']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/debian/unstable']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'debian/unstable']
gbp:debug: ['git', 'show', '--pretty=medium',
'debian/unstable:debian/source/format']
gbp:debug: 3.0 (quilt) package, replacing debian/ dir
gbp:info: Replacing upstream source on 'debian/unstable'
gbp:debug: ['git', 'ls-tree', '-z', 'v0.9.33^{tree}', '--']
gbp:debug: ['git', 'ls-tree', '-z', 'debian/unstable^{tree}', '--']
gbp:debug: Using c1c913a77a1d3f17747c01611a0c29b2fd583feb as debian/ tree
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: ['git', 'commit-tree', '82dc2eabc21969b30c37d96b6779501d99aa6811',
'-p', 'debian/unstable^{commit}', '-p', 'v0.9.33^{commit}']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: Updating debian/unstable after
import of v0.9.33', 'refs/heads/debian/unstable',
'ea3e5a0a062251588aea7fce95ce90607536b8e1']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/debian/unstable']
gbp:debug: ['git', 'reset', '--quiet', '--hard',
'ea3e5a0a062251588aea7fce95ce90607536b8e1', '--']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/debian/unstable']
gbp:debug: rm ['-rf', '../tmp5kw6qihm'] []
gbp:info: Successfully imported version 0.9.33 of
../rapid-photo-downloader_0.9.33.orig.tar.gz
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Bug#1010128: confirm
I can confirm this on my machine (2014 Macbook Pro). Note that DKMS for NVIDIA appears to work. I guess the problem is on Broadcom side using deprecated APIs. Regards
Bug#1010171: sbuild's "unshare" test fails with gpg-agent 2.2.34-1
Hi dkg, Quoting Daniel Kahn Gillmor (2022-04-25 18:49:14) > When trying to upgrade to gnupg2 from version 2.2.27-1 to version > 2.2.34-1, we see a failure in the unshare-qemuwrapper test: > > https://ci.debian.net/data/autopkgtest/testing/amd64/s/sbuild/21152998/log.gz > > + ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no -i > /tmp/autopkgtest-lxc.29hmt_yk/downtmp/autopkgtest_tmp/id_rsa -T -p 10022 > root@localhost env --chdir=/build/ AUTOPKGTEST_TMP=/tmp runuser -u user -- > ./debian/tests/unshare > Warning: Permanently added '[localhost]:10022' (ED25519) to the list of known > hosts. > gpg: keybox '/tmp/gpghome/pubring.kbx' created > gpg: /tmp/gpghome/trustdb.gpg: trustdb created > gpg: key F08FF84541F5A0C0: public key "sbuild fake uploader > " imported > gpg: key F08FF84541F5A0C0/F08FF84541F5A0C0: error sending to agent: Invalid > argument > gpg: key F08FF84541F5A0C0/A4179B1DD69E01DD: error sending to agent: Invalid > argument > gpg: key F08FF84541F5A0C0: secret key imported > gpg: Total number processed: 1 > gpg: imported: 1 > gpg: secret keys read: 1 > gpg: secret keys imported: 1 > > I traced this error down to the use of "gpg --allow-secret-key-import > --import" in the unshare script. GnuPG upstream has always maintained > that use of gpg in scripts requires use of the --batch directive, which > avoids the error. Why this error response was introduced in the change > from GnuPG 2.2.27 to 2.2.34, i don't yet fully understand, but using > --batch does avoid the problem. > > The attached patch should hopefully make the sbuild autopkgtest succeed > with either version of GnuPG2. > > thanks for maintaining sbuild in debian! thank you for tracking down the problem and submitting a patch! :) > Having to perform this workaround is unfortunate. A better approach > would be to rewrite sbuild's tooling to use OpenPGP utilities designed > for operation in a script, but doing so is a larger and more intrusive > patch. As you are the gpg expert I'd be very keen to learning which OpenPGP utilities are designed for operations in a script. Most of my interaction with dpkg is via scripts like autopkgtest or mmdebstrap and I'd like to know how to improve those. :) Thanks! cheers, josch signature.asc Description: signature
Bug#1010098: xorriso: please allow -cut-out directly from block devices
Hi, i decided to regard a device with 0 lseekable size as not suitable for -cut_out. The test for suitable type rejects S_ISDIR, S_ISLNK, S_ISFIFO, and S_ISSOCK. So if an operating system offers non-POSIX types, it will be possible to test whether they are elsewise suitable. Please give the code a thorough test, especially with weird -cut_out arguments. --- Committed are: https://dev.lovelyhq.com/libburnia/libisofs.git commit 011e2e85e6dfe6e5d882d198c29fd15c02d38e5e Author: Thomas Schmitt Date: Tue Apr 26 12:12:15 2022 +0200 Allowed lseekable device files with iso_tree_add_new_cut_out_node(). Proof-of-concept by Ivan Shmakov. commit f457a4f8b9a59906cde1b6577e7116944a37d2d0 Author: Thomas Schmitt Date: Tue Apr 26 12:06:18 2022 +0200 Added missing stream type names to a diagnostic function commit 2af17490a08c29b033942da42d27b5bda076ad05 Author: Thomas Schmitt Date: Tue Apr 26 12:03:53 2022 +0200 Bug fix: The lseek methods of IsoFileSource for local filesystem and loaded ISO returned libisofs error codes as positive off_t numbers https://dev.lovelyhq.com/libburnia/libisoburn.git commit fc587966d3c770be8b71e57e924cb5cbf7121f76 Author: Thomas Schmitt Date: Tue Apr 26 12:17:22 2022 +0200 Allowed lseekable device files with -cut_out. Proof-of-concept by Ivan Shmakov. --- Mentioning in man xorriso: === Map a byte interval of a regular disk file or of a device file into a regular file in the ISO image. The file depicted by disk_path has to support random read access. ... Another use case is copying the content of a device file as interval or as a whole into the emerging ISO filesystem. The fact that the byte_count is allowed to be unreasonably high enables copying of a whole device: -cut_out /dev/sdd3 0 1000g /content_of_sdd3 --- Behavior with the various file types and situations: === Intentional failures: --- S_IFIFO: xorriso : ERRFILE : /home/test/fifo xorriso : FAILURE : -cut_out: File type (name_pipe) is not suitable for this command: '/home/test/fifo' --- S_IFLNK: xorriso : ERRFILE : /home/test/link xorriso : FAILURE : -cut_out: File type (symbolic_link) is not suitable for this command: '/home/test/link' --- S_IFSOCK: xorriso : ERRFILE : /run/user/1000/pulse/native xorriso : FAILURE : -cut_out: File type (unix_socket) is not suitable for this command: '/run/user/1000/pulse/native' --- S_IFDIR: xorriso : ERRFILE : /run/user/1000/pulse xorriso : FAILURE : -cut_out: File type (directory) is not suitable for this command: '/run/user/1000/pulse' --- S_IFREG not large enough: xorriso : ERRFILE : /home/x xorriso : SORRY : -cut_out: Byte offset 32768 larger than addressable file size 1209 : '/home/x' --- S_IFCHR (tests are made on Linux): xorriso : FAILURE : -cut_out: Special file with addressable size range of 0 encountered xorriso : ERRFILE : /dev/zero xorriso : FAILURE : -cut_out: File (char_device) does not support random read access: '/dev/zero' --- S_IFBLK without read permission: xorriso : FAILURE : Determination of random-access readable capacity failed: '/dev/sdb' : Permission denied xorriso : ERRFILE : /dev/sdb xorriso : FAILURE : -cut_out: File (block_device) does not support random read access: '/dev/sdb' --- S_IFBLK not large enough: xorriso : ERRFILE : /dev/sdc xorriso : FAILURE : -cut_out: Byte offset 4294967296 larger than addressable file size 2004877312 : '/dev/sdc' === Successes: --- S_IFBLK of sufficient size: (only a message of severity DEBUG appears, like with the others too: xorriso : DEBUG : -cut_out from /dev/sdc , byte 1024 to 3072, and graft as /sdc ) --- S_IFREG of sufficient size: (only a message of severity DEBUG appears, like with the others too: xorriso : DEBUG : -cut_out from /home/x , byte 1024 to 3072, and graft as /x )
Bug#1010204: linux-image-5.17.0-1-amd64: asus-nb-wmi module failed to probe causes multimedia keys unusable
Package: src:linux Version: 5.17.3-1 Severity: normal X-Debbugs-Cc: lidgnuli...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Asus-nb-wmi module failed to probe. * What exactly did you do (or not do) that was effective (or ineffective)? Load manually (modprobe / insmod). * What was the outcome of this action? I get this error : modprobe: ERROR: could not insert 'asus_nb_wmi': No such device * What outcome did you expect instead? Asus_nb_wmi get loaded, multimedia keys (fn+F10/F11/F12) become usable. *** End of the template - remove these template lines *** -- Package-specific info: ** Version: Linux version 5.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-20) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 5.17.3-1 (2022-04-18) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.17.0-1-amd64 root=UUID=2d3b91ab-4936-4fb1-add6-b820adbd0b6c ro ** Not tainted ** Kernel log: [ 20.310543] input: failed to attach handler evdev to device input13, error: -2 [ 20.562469] usb 2-1.1: firmware: direct-loading firmware ath3k-1.fw [ 20.721151] iTCO_wdt iTCO_wdt.1.auto: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460) [ 20.721543] iTCO_wdt iTCO_wdt.1.auto: initialized. heartbeat=30 sec (nowayout=0) [ 20.750864] cryptd: max_cpu_qlen set to 1000 [ 20.810821] usbcore: registered new interface driver ath3k [ 20.816911] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 20.817246] cfg80211: Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [ 20.817556] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [ 20.817865] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 21.001536] usb 2-1.1: USB disconnect, device number 3 [ 21.482532] usb 2-1.1: new full-speed USB device number 5 using ehci-pci [ 21.591592] usb 2-1.1: New USB device found, idVendor=0cf3, idProduct=3005, bcdDevice= 0.01 [ 21.591610] usb 2-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 22.012697] i915 :00:02.0: [drm] Disabling ppGTT for VT-d support [ 22.012967] i915 :00:02.0: [drm] VT-d active for gfx access [ 22.012970] i915 :00:02.0: vgaarb: deactivate vga console [ 22.013516] Console: switching to colour dummy device 80x25 [ 22.013567] i915 :00:02.0: [drm] Transparent Hugepage mode 'huge=within_size' [ 22.013588] i915 :00:02.0: [drm] DMAR active, disabling use of stolen memory [ 22.015047] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [ 22.064037] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 [ 22.064364] ACPI: video: Video Device [GFX0] (multi-head: yes rom: yes post: no) [ 22.066229] acpi device:03: registered as cooling_device4 [ 22.066300] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/LNXVIDEO:00/input/input14 [ 22.067057] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 22.068797] acpi device:46: registered as cooling_device5 [ 22.069000] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input15 [ 22.084421] fbcon: i915drmfb (fb0) is primary device [ 22.304059] platform regulatory.0: firmware: direct-loading firmware regulatory.db [ 22.426453] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [ 22.919798] Console: switching to colour frame buffer device 170x48 [ 22.939368] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device [ 23.285061] mc: Linux media interface: v0.10 [ 23.294432] snd_hda_intel :00:1b.0: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 23.573581] videodev: Linux video capture interface: v2.00 [ 23.707417] ath: phy0: Set BT/WLAN RX diversity capability [ 23.758093] ath: phy0: ASPM enabled: 0x42 [ 23.758098] ath: EEPROM regdomain: 0x60 [ 23.758099] ath: EEPROM indicates we should expect a direct regpair map [ 23.758100] ath: Country alpha2 being used: 00 [ 23.758101] ath: Regpair used: 0x60 [ 23.760246] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 23.760894] ieee80211 phy0: Atheros AR9285 Rev:2 mem=0xad77c074, irq=17 [ 23.865922] ath9k :03:00.0 wlp3s0: renamed from wlan0 [ 23.963345] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC269VB: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 23.963364] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 23.963373] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 23.963379] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 23.963384] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0 [ 23.963388] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 23.963393]
Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4
26.04.2022 10:37, Salvatore Bonaccorso wrote: Hi, On Fri, Apr 15, 2022 at 05:12:38PM +0300, Michael Tokarev wrote: * switch from weird ~deb11uN to the usual +deb11uN release numbering scheme since a more recent upstream version is available in testing now It is not really a change per se, just an indication that the versioning scheme is finally back to normal. I'm not speaking autoritatively here, but please do not do that. It changes the semantics and meaning what's happening and doe not sort anymore before the 2:4.13.13+dfsg-1. Ok, I reverted this very change now. It's definitely not a big deal, I just thought it will be a good thing to do. Let it be the way it has already been in bullseye. Thank you! /mjt
Bug#1010203: bullseye-pu: package bind9/1:9.16.28-1~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [ Reason ] New upstream version update, the upstream CHANGES are: --- 9.16.28 released --- 5856. [bug] The "starting maxtime timer" message related to outgoing zone transfers was incorrectly logged at the ERROR level instead of DEBUG(1). [GL #3208] 5852. [func] Add new "reuseport" option to enable/disable load balancing of sockets. [GL #3249] 5843. [bug] When an UPDATE targets a zone that is not configured, the requested zone name is now logged in the "not authoritative" error message, so that it is easier to track down problematic update clients. [GL #3209] 5836. [bug] Quote the dns64 prefix in error messages that complain about problems with it, to avoid confusion with the following dns64 ACLs. [GL #3210] 5834. [cleanup] C99 variable-length arrays are difficult to use safely, so avoid them except in test code. [GL #3201] 5828. [bug] Replace single TCP write timer with per-TCP write timers. [GL #3200] 5824. [bug] Invalid dnssec-policy definitions were being accepted where the defined keys did not cover both KSK and ZSK roles for a given algorithm. This is now checked for and the dnssec-policy is rejected if both roles are not present for all algorithms in use. [GL #3142] And the user-friendly release notes: Notes for BIND 9.16.28 - -- New Features ~~~ - - Add a new configuration option ``reuseport`` to disable load balancing on sockets in situations where processing of Response Policy Zones (RPZ), Catalog Zones, or large zone transfers can cause service disruptions. See the BIND 9 ARM for more detail. :gl:`#3249` Bug Fixes - - Invalid ``dnssec-policy`` definitions, where the defined keys did not cover both KSK and ZSK roles for a given algorithm, were being accepted. These are now checked, and the ``dnssec-policy`` is rejected if both roles are not present for all algorithms in use. :gl:`#3142` - - Handling of TCP write timeouts has been improved to track the timeout for each TCP write separately, leading to a faster connection teardown in case the other party is not reading the data. :gl:`#3200` [ Impact ] The package will be updated when there's a new BIND 9 release containing security vulnerabilities. [ Tests ] Upstream runs automated test suite covering many different platforms and also runs a manually-triggered more extensive checks in their CI platform. [ Risks ] [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] There are two extra related changes: * Drop the libldap2-dev Build-Depends (it's not used at all) * Add more string dependency on libuv1 There are new flags (as enum members) that are being used because the BIND 9 is compiled with libuv1 >= 1.40.0, but this is something not caught by dpkg-gensymbols mechanism because that can look only at the exported symbols. When the flags that were available at the compile time are used with older libuv1 at runtime, it causes assertion failure with "invalid argument": udp.c:229: fatal error: uv_udp_init_ex failed: invalid argument [ Other info ] FTR I am BIND 9 packager and upstream at the same time. There were no reports of regressions from the users using BIND 9.16.28 from ISC provided packages or compiled from source. -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmJntMRfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcKkVg//QNOtb5iqRRuTAAz/Lqd3Sd6Vdvex3KxpeBt+a1PhEjM1RHntYAhifWMa mmyIR0oCuxHLe8WbbJIuFKvktsV9aaRTKVF1HzLedSl0k3TY6lTyNemwZ7U159mF wJavJ6CsFpYz5+K0HNoVI5/Rlaw/K890oyLtio4KLmfYai/eewsS5a9j0NDakw8S GgBxJDWyCynf6PA1yuiUKEsb2QBLme2v/9pSTW3V72vZzgXZmDS8UryPX/FhMbX2 Aqn8h/llnsSfKv4zymygjdazoWNgqm+WGV+oB1dhmTnYqA0Uft9WQ/S4rdKdJLFp +Atlo6eZv4CieMIMaFYT2u0D4YodWxb8jjoUVGlZbA44YLEh3VY56kiY64RpAWlV UkXxGbBvsqjb7rvydX71uAX7ZjVNOb/VXRh73H6o8UTg8LnSSb1AawJHeEZURchM aRkCQJR1pjxbgpSuk/ph5g3ErPNXdtH8cQ0Uw51blb5/lRSBZCjdBlqNWiVUhYgb ImACk8koo/RxEqk1QVyiEpDX1fZ67LUXC5xTE2l0Nc3i/NKa5UYgc8+Tgs9JONjN ywnGuG18TvrAWu0nhnprfwXyQhGBBbrvXzZQBiIm1UjxFj0m7BviQPvrY640C0dl 4rLkTgrmOAt/6HktZuDEY1JxXMUFmqLOyTWjevSAQMEF1LXFa+g= =hs25 -END PGP SIGNATURE-
Bug#1008823: transition: thrift
Hi On 2022-04-19 14:12:33, Sebastian Ramacher wrote: > Control: tags -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-thrift.html > > On 2022-04-02 11:48:40, László Böszörményi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi RMs, > > > > A quick transition of thrift from 0.13.0 to 0.16.0 as the only reverse > > build dependency is gnuradio. It builds with the new thrift version as > > well. > > Please go ahead Please ensure in the next upload that libthrift-0.16.0 and libthrift-c-glib0 are in Section libs. This will ensure that for the next thrift transition britney can perform a smooth update. Cheers -- Sebastian Ramacher
Bug#1010201: override: libthrift-0.16.0:libs/optional
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: override X-Debbugs-Cc: thr...@packages.debian.org libthrift-0.16.0 constains a shared library and should be placed in Section: libs. Please change the override accordingly. Cheers -- Sebastian Ramacher
