Bug#985782: unblock: cif2cell/2.0.0a1+dfsg-4
On 2021-03-25 22:05, Ivo De Decker wrote: > On Tue, Mar 23, 2021 at 02:48:01PM +0200, Andrius Merkys wrote: >> I am seeking unblocking of cif2cell/2.0.0a1+dfsg-4. > The deadline for packages that are not testing has passed. Sorry. I see. Thank you for information, and sorry for the noise. Best, Andrius
Bug#933637: Bug#933636: CVE-2019-14934
Hi Francois, On Fri, Jul 31, 2020 at 10:18:23AM +0200, Salvatore Bonaccorso wrote: > Hi Francois, > > On Mon, Feb 10, 2020 at 03:59:22PM -0800, Francois Marier wrote: > > On 2020-02-07 at 10:14:24, Salvatore Bonaccorso wrote: > > > > It looks OK to me. Tagging moreinfo until there's a final diff. > > > > > > Friendly ping, any news? (It's too late now for the upcoming point > > > release though). > > > > It's still on my list, but not a very high priority. Definitely won't happen > > until at least after the Ubuntu 20.04 Debian merge deadline. > > It would now be too late for the 10.5 buster point release, but do you > found time to finalize the debdiff for review for SRM? Then we might > target for 10.6. There are in meanwhile one more CVE which might be included. They are at this time CVE-2019-14267, CVE-2020-9549, CVE-2019-14934 and CVE-2020-20740 which are all marked no-dsa or unimportant (with negligible security impact), but maybe if you still would like to fix those for buster, we can close this report and then open a new one with a revisited debdiff? What do you think? Regards, Salvatore
Bug#979592: RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
On 2021-03-25 20:47, Mathias Gibbens wrote: > Thank you Andrius! I appreciate the time you've taken to sponsor my > packages. > > I've pushed a signed tag to each repository. > > As new releases are made, or if there's any feedback from ftpmasters, > I'll contact you directly. Thank you Mathias for your contribution! Best, Andrius
Bug#985815: RFS: usermanager/1.0.74+git20210323-1 [ITP] -- Graphical user manager
> On Mar 25, 2021, at 22:12, Adam Borowski wrote:
>
> On Wed, Mar 24, 2021 at 01:36:10PM +0100, Gürkan Myczko wrote:
>>> The menu icon for .desktop doesn't show up for me (in XFCE).
>>
>> probably because it's .gif and fd.o doesn't support it
>
> And, according to the spec:
> https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
> it's not supposed to.
>
> Could you thus convert the icon to .png, please?
>
>>> Some method of su{,do}-to-root should be providen -- as is, the program
>>> fails to start claiming it needs root, and starting it as root manually
>>> involves some bits generally unknown by users who need a clicky-clicky
>>> tool (ie, the intended audience).
>>
>> for upstream
>
> Hrm, I then don't quite see what the intended audience for this package
> could be. The basic instructions how to run a GUI program as root (start a
> shell, find out $DISPLAY, su/sudo, set up display, cp ~user/.Xauthority ~,
> invoke from cmdline) are already far more complex than just running relevant
> adduser/usermod/deluser commands from a shell.
>
> And besides, running a GUI program as root is not that good an idea,
> compared to separating out the privileged parts (be it to an unreliable dbus
> complexity, or to a simple easily-auditable setuid helper).
>
> But really, I don't know enough about crossing privilege boundaries in a GUI
> to be comfortable reviewing this bit.
FWIW, upstream seem to have an intent to resolve this,
https://github.com/xen0vas/UserManager/issues/16:
Application usage from users with limited privileges
- Implement setuid access with privilege control
xen0vas commented on Jun 27, 2020
Application usage from users with limited privileges in order to be able to
use UserManager for changing passwords and have limited access. The
implementation includes setuid setgid privilege checks as well as dropping
and restoring privileges as needed due to elevated functionality when
changing passwords and accessing system files.
Gürkan, maybe you could work with them to deal with this prior to packaging?
Bug#985815: RFS: usermanager/1.0.74+git20210323-1 [ITP] -- Graphical user manager
On Wed, Mar 24, 2021 at 01:36:10PM +0100, Gürkan Myczko wrote:
> > The menu icon for .desktop doesn't show up for me (in XFCE).
>
> probably because it's .gif and fd.o doesn't support it
And, according to the spec:
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
it's not supposed to.
Could you thus convert the icon to .png, please?
> > Some method of su{,do}-to-root should be providen -- as is, the program
> > fails to start claiming it needs root, and starting it as root manually
> > involves some bits generally unknown by users who need a clicky-clicky
> > tool (ie, the intended audience).
>
> for upstream
Hrm, I then don't quite see what the intended audience for this package
could be. The basic instructions how to run a GUI program as root (start a
shell, find out $DISPLAY, su/sudo, set up display, cp ~user/.Xauthority ~,
invoke from cmdline) are already far more complex than just running relevant
adduser/usermod/deluser commands from a shell.
And besides, running a GUI program as root is not that good an idea,
compared to separating out the privileged parts (be it to an unreliable dbus
complexity, or to a simple easily-auditable setuid helper).
But really, I don't know enough about crossing privilege boundaries in a GUI
to be comfortable reviewing this bit.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄
Bug#980923: acngtools eats all the CPU and doesn’t finish daily cron with merged pdiffs
Package: apt-cacher-ng Version: 3.6.3-1 Followup-For: Bug #980923 X-Debbugs-Cc: marcos.ca...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? The last two versions of apt-cacher-ng in testing have shown this issue. No idea what triggers it * What exactly did you do (or not do) that was effective (or ineffective)? restart service temporarily fixes it * What was the outcome of this action? apt-cacher-ng not using 100% CPU * What outcome did you expect instead? No need to restart service... *** End of the template - remove these template lines *** -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-cacher-ng depends on: ii adduser 3.118 ii debconf [debconf-2.0]1.5.75 ii dpkg 1.20.7.1 ii libbz2-1.0 1.0.8-4 ii libc62.31-9 ii libevent-2.1-7 2.1.12-stable-1 ii libevent-pthreads-2.1-7 2.1.12-stable-1 ii libgcc-s110.2.1-6 ii liblzma5 5.2.5-1.0 ii libssl1.11.1.1j-1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-3 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages apt-cacher-ng recommends: ii ca-certificates 20210119 Versions of packages apt-cacher-ng suggests: ii avahi-daemon 0.8-5 pn doc-base ii libfuse2 2.9.9-5 -- Configuration Files: /etc/apt-cacher-ng/acng.conf changed: CacheDir: /home/marcos/Files/Software/Cache/apt-cacher-ng LogDir: /var/log/apt-cacher-ng SupportDir: /usr/lib/apt-cacher-ng Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian # Debian Archives Remap-uburep: file:ubuntu_mirrors /ubuntu ; file:backends_ubuntu # Ubuntu Archives Remap-klxrep: file:kali_mirrors /kali ; file:backends_kali # Kali Linux Archives Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin # incomplete, please create this file or specify preferred mirrors here Remap-sfnet: file:sfnet_mirrors # ; file:backends_sfnet # incomplete, please create this file or specify preferred mirrors here Remap-alxrep: file:archlx_mirrors /archlinux # ; file:backend_archlx # Arch Linux Remap-fedora: file:fedora_mirrors # Fedora Linux Remap-epel: file:epel_mirrors # Fedora EPEL Remap-slrep: file:sl_mirrors # Scientific Linux Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo Archives Remap-secdeb: security.debian.org security.debian.org/debian-security deb.debian.org/debian-security /debian-security ; deb.debian.org/debian-security security.debian.org ReportPage: acng-report.html ExThreshold: 4 LocalDirs: acng-doc /usr/share/doc/apt-cacher-ng PassThroughPattern: ^(.*):443$ /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: '/etc/apt-cacher-ng/security.conf' -- debconf information: apt-cacher-ng/gentargetmode: No automated setup apt-cacher-ng/proxy: keep * apt-cacher-ng/tunnelenable: false apt-cacher-ng/bindaddress: keep apt-cacher-ng/port: keep apt-cacher-ng/cachedir: keep
Bug#985923: qemu-user-static: Unknown privilege violation (03) on 64-bit PowerPC targets when running java
Package: qemu-user-static Version: 1:5.2+dfsg-9 Severity: normal I’m getting… Unknown privilege violation (03) NIP 00400b4192c8 LR 004002967638 CTR 00400b419298 XER CPU#1 MSR 900102806901 HID0 HF 92806000 iidx 6 didx 6 TB 00010620 45613134064220 GPR00 0008 00400330dc80 cafe 00400330ee78 GPR04 1ff8 0010 000a GPR08 0030 00400b419298 0001 c0de GPR12 003f 0040033188d0 004001bbf9e8 GPR16 00400b4192d8 004002d2bcf0 00400b419298 00400330ee78 GPR20 00400b4192f8 004002d04178 03d8 004004009670 GPR24 004004009a48 00400330dcf0 004004009660 00400b419280 GPR28 004004009620 0080 004002cd8430 00400330dc80 CR 240044f8 [ E G - - G G LO L ] RES … trying to run OpenJDK 8 on either ppc64 or… Unknown privilege violation (03) NIP 00400b1b42b0 LR 0040027ddfb8 CTR 00400b1b4280 XER CPU#1 MSR 900102806901 HID0 HF 92806001 iidx 6 didx 6 TB 00010215 43873222717974 GPR00 ffbffcf55fa0 0040030a9e70 004002a8ae00 0040030ab060 GPR04 2000 0010 0001 GPR08 0030 0001 004002adae00 GPR12 00400b1b4280 0040030b48d0 004001b9f468 GPR16 004001872000 004001b9f478 0040030ab060 GPR20 00400b1b42c0 00400b1b42c8 03d8 0040040092b0 GPR24 004004009688 004002ab4430 0040030a9ed0 0040040092a0 GPR28 004004009260 00400b1b4280 004002adc140 0040030a9e70 CR 24884400 [ E G L L G G - - ] RES … ppc64el (release architecture); OpenJDK 11 is worse (it crashes after this info; 8 only dumps then continues), and, given that the buildd logs don’t contain this, it is almost certainly a qemu-user issue. https://github.com/multiarch/qemu-user-static/issues/128 is another user reporting this issue. I retried exporting QEMU_CPU=POWER8 having learnt about its existence while searching about this bug, it does not fix it though. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.0-2 Versions of packages qemu-user-static suggests: ii sudo 1.8.27-1+deb10u3 -- no debconf information
Bug#985922: unblock: u-boot/2021.01+dfsg-4
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: vagr...@debian.org, debian-b...@lists.debian.org Severity: normal Please unblock package u-boot [ Reason ] This version adds support for the pinetab platform and fixes a bug that fails to detect some pinephone platforms. This also re-adds debugging symbols that were lost late in the bullseye release cycle due to upstream buildsystem changes. [ Impact ] Hardware support for another platform (pinetab) and working installation process for another platform (pinephone). Ability to debug u-boot using debugging symbols. [ Tests ] None. [ Risks ] Very low risk to existing platforms as this involves no code changes to u-boot itself. Increases the installed size (~2MB) and .deb size nominally for the u-boot-sunxi:arm64 package. [ 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 testing [ Other info ] This is depended on by debian-installer for the arm64/armhf images, so leaving this in a blocked state could impact debian-installer update process. unblock u-boot/2021.01+dfsg-4 Thanks for your work managing the release! live well, vagrant diff -Nru u-boot-2021.01+dfsg/debian/bin/u-boot-install-sunxi u-boot-2021.01+dfsg/debian/bin/u-boot-install-sunxi --- u-boot-2021.01+dfsg/debian/bin/u-boot-install-sunxi 2021-02-28 18:14:48.0 -0800 +++ u-boot-2021.01+dfsg/debian/bin/u-boot-install-sunxi 2021-03-12 11:10:45.0 -0800 @@ -38,7 +38,9 @@ "OrangePi Zero Plus2") TARGET="/usr/lib/u-boot/orangepi_zero_plus2/" ;; "OrangePi One Plus") TARGET="/usr/lib/u-boot/orangepi_one_plus/" ;; "Pinebook") TARGET="/usr/lib/u-boot/pinebook" ;; - "Pine64 PinePhone (1."[12]")") TARGET='/usr/lib/u-boot/pinephone' ;; + "Pine64 PinePhone Braveheart (1.1)") TARGET='/usr/lib/u-boot/pinephone' ;; + "Pine64 PinePhone (1.2)") TARGET='/usr/lib/u-boot/pinephone' ;; + "PineTab") TARGET="/usr/lib/u-boot/pinetab" ;; "Pine64+") TARGET="/usr/lib/u-boot/pine64_plus" ;; "Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;; "PineRiver Mini X-Plus") TARGET="/usr/lib/u-boot/Mini-X" ;; diff -Nru u-boot-2021.01+dfsg/debian/changelog u-boot-2021.01+dfsg/debian/changelog --- u-boot-2021.01+dfsg/debian/changelog2021-03-01 00:00:18.0 -0800 +++ u-boot-2021.01+dfsg/debian/changelog2021-03-12 15:00:43.0 -0800 @@ -1,3 +1,18 @@ +u-boot (2021.01+dfsg-4) unstable; urgency=medium + + [ Arnaud Ferraris ] + * Add support for the pinetab platform (Closes: #982982) + * u-boot-install-sunxi: fix device tree model for PinePhone 1.1 +(Closes: #984704) + + [ Vagrant Cascadian ] + * debian/patches: Update PineTab patch use default bootdelay. + * debian/patches: Add Forwarded link to PineTab patch. + * debian/rules: Ensure debugging symbols are enabled. + * debian/rules: Pass argument to remove build path from debug symbols. + + -- Vagrant Cascadian Fri, 12 Mar 2021 15:00:43 -0800 + u-boot (2021.01+dfsg-3) unstable; urgency=medium [ Domenico Andreoli ] diff -Nru u-boot-2021.01+dfsg/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch u-boot-2021.01+dfsg/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch --- u-boot-2021.01+dfsg/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch 1969-12-31 16:00:00.0 -0800 +++ u-boot-2021.01+dfsg/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch 2021-03-12 11:15:15.0 -0800 @@ -0,0 +1,45 @@ +From 2c346cacb4b0841051bceb27a57058020860ab8b Mon Sep 17 00:00:00 2001 +From: Arnaud Ferraris +Date: Wed, 2 Sep 2020 09:53:50 +0200 +Subject: [PATCH] configs: add PineTab defconfig +Forwarded: https://patchwork.ozlabs.org/project/uboot/list/?series=232582 + +The PineTab device-tree is already in u-boot, this commit adds the corresponding +defconfig, based on pinephone_defconfig. + +Signed-off-by: Arnaud Ferraris + +--- + configs/pinetab_defconfig | 22 ++ + 1 file changed, 22 insertions(+) + create mode 100644 configs/pinetab_defconfig + +diff --git a/configs/pinetab_defconfig b/configs/pinetab_defconfig +new file mode 100644 +index 00..71dda9f5d9 +--- /dev/null b/configs/pinetab_defconfig +@@ -0,0 +1,20 @@ ++CONFIG_ARM=y ++CONFIG_ARCH_SUNXI=y ++CONFIG_SPL=y ++CONFIG_IDENT_STRING="" ++CONFIG_MACH_SUN50I=y ++CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y ++CONFIG_DRAM_CLK=552 ++CONFIG_DRAM_ZQ=3881949 ++CONFIG_MMC_SUNXI_SLOT_EXTRA=2 ++# CONFIG_VIDEO_DE2 is not set ++CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinetab" ++# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set ++CONFIG_SYS_CONSOLE_INFO_QUIET=y ++# CONFIG_DISPLAY_CPUINFO is not set ++# CONFIG_DISPLAY_BOARDINFO is not set ++# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set ++# CONFIG_SP
Bug#985921: installation-reports: bullseye alpha 3 installer: system fails to boot with "firmware: failed to load rtl_nic/rtl8168e-3.fw"
Package: installation-reports Severity: normal X-Debbugs-Cc: kyosellout+...@gmail.com Boot method: USB Image version: debian-bullseye-DI-alpha3-amd64-netinst.iso Date: Machine: desktop Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect media: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The install ran fine, I was not prompted to insert a USB with missing firmware during the install. I have previously installed older versions of debian on this computer and it worked. The installation itself worked, but upon booting, I just get the following error: (After starting Accounts Service): r8169 :02:00.0: firmware: failed to load rtl_nic/rtl8168e-3.fw (-2) firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware r8169 :02:00.0: Unable to load firmware rtl_nic/rtl8168e-3.fw (-2) -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20201202" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux desktop 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1 (2020-11-27) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex [1022:1410] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex [1022:1410] lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) I/O Memory Management Unit [1022:1419] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) I/O Memory Management Unit [1022:1419] lspci -knn: 00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port [1022:1412] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port [1022:1414] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port [1022:1417] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7812] (rev 03) lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7812] (rev 03) lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7801] (rev 40) lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:b002] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7807] (rev 11) lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004] lspci -knn: Kernel driver in use: ohci-pci lspci -knn: Kernel modules: ohci_pci lspci -knn: 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 11) lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: Kernel modules: ehci_pci lspci -knn: 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7807] (rev 11) lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004] lspci -knn: Kernel driver in use: ohci-pci lspci -knn: Kernel modules: ohci_pci lspci -knn: 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 11) lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5004] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: Kernel modules: ehci_pci lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:780b] (rev 14) lspci -knn: Subsystem: Advanced Micro Devi
Bug#985825: do not remove useful packages due to political issues, please
Whatever you decide, please, do not consider *removing* useful package, just due to name controversy. That is not a good path to go down, IMHO. After all, we still have several "reiserfs" named packages in Debian main, and one should well argue that Hans Reiser actions were much bigger atrocity than RMS-based one. Perhaps check-dfsg-status might be good binary name (akin to check-support-status from debian-security-support package) if you are looking for non-controversial and easier to understand name. Please do contact release team ASAP to check about what renaming possibilities are available, and in what timeframes.
Bug#985920: ca-certificates-java: -Xmx64m may not be sufficient any more
Package: ca-certificates-java Version: 20190909 Granted this is on a debian-ports architecture and with an old JDK but I just hit this error: Setting up openjdk-8-jdk:alpha (8u222-b10-1) ... update-alternatives: using /usr/lib/jvm/java-8-openjdk-alpha/bin/appletviewer to provide /usr/bin/appletviewer (appletviewer) in auto mode update-alternatives: using /usr/lib/jvm/java-8-openjdk-alpha/bin/jconsole to provide /usr/bin/jconsole (jconsole) in auto mode Processing triggers for libc-bin (2.31-10) ... Processing triggers for ca-certificates (20210119) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Error occurred during initialization of VM Too small initial heap E: /etc/ca-certificates/update.d/jks-keystore exited with code 1. done. Errors were encountered while processing: ca-certificates-java E: Sub-process /usr/bin/dpkg returned an error code (1) E: Failed to process build dependencies Might be more future-proof to raise the heap maximum size (Xmx). If concerned about memory use, you can still specify a smaller minimum heap size…
Bug#985918: ITP: bung -- backup next generation
Package: wnpp Severity: wishlist Owner: Charles Atkinson * Package name: bung Version : 3.0.3 Upstream Author : Charles Atkinson * URL : https://redmine.auroville.org.in/projects/bung/files * License : GPLv2 Programming Lang: bash Description : Backup next generation (bung) bung has been developed over eight years as a campus backup utility, running on Debian and a few Ubuntu systems. It is known to be used on more than 100 computers Documentation includes man pages and user and programmer guides. The guides' primary format is .odt. The package includes .pdf and .html Guides are available from https://redmine.auroville.org.in/projects/bung/documents Selected text from https://redmine.auroville.org.in/projects/bung/wiki/Bung_technology follows bung is a set of wrapper scripts for several backup utilities: * OpenLDAP (slapcat and tar) * mysqldump * pgdump * rsync bung also has: * A "sysinfo" facility to generate system information reports * Templated backups allowing custom backup commands. Example templates are provided for Cisco switches and MikroTik routers bung features: * Automated backup to hotplug devices when they are plugged in with on-screen notifications to both character terminals and X displays * Backup to remote file systems via ssh * Custom commands (hooks) to run before and after the backup itself * File system hierarchy standard (FHS) compliant * GPLv2 * Logging designed to ease production support * LVM snapshots * man pages * Mounting and unmounting local file systems * Remote ssh command validation Best Charles Atkinson
Bug#984953: libgtkmm-3.0-1v5: GParted crashes on Gdk::Pixbuf::get_width() const ()
Dear Maintainer, I tried to have a look at the core file and a backtrace with all needed symbols looks like in [1]. In the end it looks like in refresh_combo_devices [2] it is attempted to load a harddisk icon. This failed for some reason in [3], therefore a local variable "theme_icon" contains a null pointer, which gets unconditionally called member function get_width on and therefore crashes a few lines later. A wild guess would be that the harddisk icon file is missing or is not accessible. Possibly there is some hint written to stdout before the crash. Kind regards, Bernhard [1] (gdb) bt #0 Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389 #1 Gdk::Pixbuf::get_width (this=0x0) at pixbuf.cc:517 #2 0xaab89ca4 in GParted::Utils::mk_pixbuf (widget=..., stock_id=..., icon_size=..., icon_size@entry=...) at /usr/include/glibmm-2.4/glibmm/refptr.h:259 #3 0xaab92020 in GParted::Win_GParted::refresh_combo_devices (this=0xe960) at /usr/include/gtkmm-3.0/gtkmm/enums.h:2870 #4 0xaab95980 in GParted::Win_GParted::menu_gparted_refresh_devices (this=) at Win_GParted.cc:1674 #5 0xaab95e2c in GParted::Win_GParted::initial_device_refresh (data=) at Win_GParted.cc:1605 #6 0xf6b8dab4 in g_main_dispatch (context=0xaaca6f10) at ../../../glib/gmain.c:3325 #7 g_main_context_dispatch (context=0xaaca6f10) at ../../../glib/gmain.c:4043 #8 0xf6b8de5c in g_main_context_iterate (context=0xaaca6f10, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119 #9 0xf6b8e1b0 in g_main_loop_run (loop=loop@entry=0xabb23860) at ../../../glib/gmain.c:4317 #10 0xf70b98f0 in gtk_main () at ../../../../gtk/gtkmain.c:1328 #11 0xaab2138c in main (argc=, argv=) at main.cc:62 [2] https://gitlab.gnome.org/GNOME/gparted/-/blob/master/src/Win_GParted.cc#L727 [3] https://gitlab.gnome.org/GNOME/gparted/-/blob/master/src/Utils.cc#L109 # Bullseye/testing arm64 qemu VM 2021-03-25 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update # to speedup testing mv /etc/manpath.config /etc/manpath.config.renamed apt install libeatmydata1 export LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libeatmydata.so apt dist-upgrade apt install gdb zstd mc gparted \ gparted-dbgsym libgtk-3-0-dbgsym libgtkmm-3.0-1v5-dbgsym libglib2.0-0-dbgsym apt build-dep gparted mkdir /home/benutzer/source/gparted/orig -p cd/home/benutzer/source/gparted/orig apt source gparted cd wget "https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=984953;filename=gpartedbin.core.tar.zstd;msg=10"; -O gpartedbin.core.tar.zstd tar axf gpartedbin.core.tar.zstd gdb -q --core gpartedbin.core gdb -q /usr/sbin/gpartedbin --core gpartedbin.core set width 0 set pagination off Core was generated by `/usr/sbin/gpartedbin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xf794d760 in Gdk::Pixbuf::get_width() const () from /usr/lib/aarch64-linux-gnu/libgdkmm-3.0.so.1 [Current thread is 1 (Thread 0xf51947a0 (LWP 9937))] (gdb) set width 0 (gdb) set pagination off (gdb) bt #0 0xf794d760 in Gdk::Pixbuf::get_width() const () from /usr/lib/aarch64-linux-gnu/libgdkmm-3.0.so.1 #1 0xaab89ca4 in ?? () #2 0xaab92020 in ?? () #3 0xaab95e2c in ?? () #4 0xf6b8dab4 in g_main_context_dispatch () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 #5 0xf6b8de5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 #6 0xf6b8e1b0 in g_main_loop_run () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 #7 0xf70b98f0 in gtk_main () from /usr/lib/aarch64-linux-gnu/libgtk-3.so.0 #8 0xaab2138c in ?? () #9 0xf6707218 in __libc_start_main (main=0xaab21290, argc=1, argv=0xf4e8, init=, fini=, rtld_fini=, stack_end=) at ../csu/libc-start.c:308 #10 0xaab219ec in ?? () Backtrace stopped: not enough registers or memory available to unwind further Core was generated by `/usr/sbin/gpartedbin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389 389 ../gdkmm/pixbuf.h: No such file or directory. [Current thread is 1 (Thread 0xf51947a0 (LWP 9937))] (gdb) set width 0 (gdb) set pagination off (gdb) bt #0 Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389 #1 Gdk::Pixbuf::get_width (this=0x0) at pixbuf.cc:517 #2 0xaab89ca4 in GParted::Utils::mk_pixbuf (widget=..., stock_id=..., icon_size=..., icon_size@entry=...) at /usr/include/glibmm-2.4/glibmm/refptr.h:259 #3 0xaab92020 in GParted::Win_GParted::refresh_combo_devices (this=0xe960) at /usr/include/gtkmm-3.0/gtkmm/enums.h:2870 #4 0xaab95980 in GParted::Win_GParted::menu_gparted_refresh_devices (this=) at Win_GParted.cc:1674 #5 0xaab95e2c in GParted::Win_GParted::initial_device_
Bug#984844: 984844 was fixed by upgrading firmware-brcm80211
Control: notfound -1 20210208-4 #984844 is not observed in 20210208-4 in testing/Bullseye. Ryutaroh
Bug#985898: /usr/bin/r: /usr/bin/r is not stripped
On 25 March 2021 at 20:29, Rogério Theodoro de Brito wrote: | On March 25, 2021 1:31:11 PM GMT-03:00, Dirk Eddelbuettel wrote: | > | >Howdy, | > | >On 25 March 2021 at 13:12, Rogério Brito wrote: | >| I was looking into some of my executables and discovered that | >/usr/bin/r is | >| not stripped and it contains debugging info on my system: | >| | >| ,[ file /usr/bin/r ] | >| | /usr/bin/r: ELF 64-bit LSB pie executable, x86-64, version 1 | >(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, | >BuildID[sha1]=36aeb221c38bd7fdf3140a4c6481ff739573e634, for GNU/Linux | >3.2.0, with debug_info, not stripped | >| ` | >| | >| Is it desired? I would have expected it to work (as usual) with a | >-dbgsym | >| package being created if so needed (with all the justifications | >there). | > | >No that is likely an oversight as I need to "manually" copy the binary | >from | >the R package location to /usr/bin. | > | >common-binary-post-install-arch:: | >dh_installdirs usr/bin usr/share/man/man1 | >install -v -m 0644 $(debRlib)/littler/bin/r | >$(CURDIR)/debian/$(package)/usr/bin/ | >install -v -m 0644 $(debRlib)/littler/man-page/r.1 | >$(CURDIR)/debian/$(package)/usr/share/man/man1/ | > | >So yes -- that install call is lacking a '-s' flag. Will add it now. | > | >Thanks! | > | >Dirk | | Dear Dirk, | | I just saw your other message. I believe that, in the case of Debian, install, with or without -s may do the wrong thing. | | Just copy the files where they belong to and debhelper will do the rest (it does for my packages). | | I don't know how to integrate that cleanly with your upstream build system, though. I am not entirely sure I understand what you are suggesting, but the sources are on salsa so feel free to experiment. If you find a better way, great. If you do not, things stay the way they are. I will not have time to dig into this for you anytime soon -- sorry. Best, Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#985917: installation-reports: Bullseye Alpha 3 successful on GNOME Boxes in Mint 20
Package: installation-reports Severity: wishlist X-Debbugs-Cc: cdpa...@hotmail.com (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: GNOME Boxes, presented ISO to hypervisor as DVD. Image version: debian-bullseye-DI-alpha3-amd64-netinst.iso Date: Thu, Mar 25, 2021, approximately 5:30pm US-EDT Machine: Lenovo H30-50 desktop, Linux Mint 20 Ulyanna Cinnamon host system (fully updated prior to guest installation), Intel Pentium G3260 processor, 4GB DDR3 memory. Partitions: Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs669692 0669692 0% /dev tmpfs tmpfs 138516 884137632 1% /run /dev/sda1 ext4 19525456 3812848 14697724 21% / tmpfs tmpfs 692576 26792665784 4% /dev/shm tmpfs tmpfs 5120 4 5116 1% /run/lock tmpfs tmpfs 138512 52138460 1% /run/user/1000 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[E] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Chose defaults for all options except mirror, where I chose ftp.us.debian.org and got an error message. However, it then seemed to proceed normally. All other aspects of installation were clean, guest rebooted and installed system is normal. Chose Xfce instead of GNOME as the DE. Installation was smooth and pleasant. Please make sure that any installation logs that you think would be useful are attached to this report. Please compress large files using gzip. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20201202" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux bullseye-testing-alpha3 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1 (2020-11-27) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000] lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010] lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] lspci -knn: Kernel driver in use: ata_piix lspci -knn: Kernel modules: ata_piix, ata_generic lspci -knn: 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 03) lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] lspci -knn: 00:02.0 VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04) lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] lspci -knn: 00:03.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter [10ec:8139] (rev 20) lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] lspci -knn: Kernel driver in use: 8139cp lspci -knn: Kernel modules: 8139cp, 8139too lspci -knn: 00:04.0 Audio device [0403]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller [8086:2668] (rev 01) lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] lspci -knn: Kernel driver in use: snd_hda_intel lspci -knn: Kernel modules: snd_hda_intel lspci -knn: 00:05.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:05.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:05.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] lspci -knn: Kernel driver in us
Bug#982250: Update to mmsd version numbers
Hello, Per a suggestion, I changed the version numbers a bit to be less confusing. v0.1-1 is the upstream packaging of mmsd, and can be found here: https://salsa.debian.org/kop316/mmsd/-/tags/v0.1-1 v0.1-3 is the packaging of mmsd that includes all of the patches that I have been working on in my fork: https://salsa.debian.org/kop316/mmsd/-/tags/v0.1-3 -- Respectfully, Chris Talbot
Bug#985916: guix: Suggest to the user that they should use ~/.config/guix/current/bin/guix after running guix pull
Package: guix Version: 1.2.0-3.1 Severity: wishlist Dear Maintainer, First off thank you for packaging guix for Debian. While I was trying to install some packages from guix I was confused that I couldn't find ones that were listed in my source checkout of guix. Eventually I figured out that I needed a new version of the guix binary than what was included in the Debian guix package, and that the most current guix binary lives in ~/.config/guix/current/bin. I was wondering if the Debian guix binary should print a warning if there is a ~/.config/guix/current/bin/guix available, or maybe even be a wrapper that runs that version instead of the shipped version. What do you think? Diane -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages guix depends on: ii guile-2.2 2.2.7+1-5.4 ii guile-2.2-libs 2.2.7+1-5.4 ii guile-gcrypt0.3.0-3 ii guile-git 0.4.0-3 ii guile-gnutls3.7.0-7 ii guile-json 4.3.2-2 ii guile-lzlib 0.0.2-2 ii guile-sqlite3 0.1.3-2 ii guile-ssh 0.13.1-4 ii guile-zlib 0.0.1-3 ii libbz2-1.0 1.0.8-4 ii libc6 2.31-9 ii libgcc-s1 10.1.0-1 ii libgcrypt20 1.8.7-3 ii libsqlite3-03.34.1-3 ii libssh-dev 0.9.5-1 ii libstdc++6 10.1.0-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages guix recommends: ii nscd 2.31-9 ii systemd 247.3-3 guix suggests no packages.
Bug#985755: Modprobe tried to load incorrect module
I noticed in the "syslog" that modprobe couldn't find the module "rtw_8723de" that was not listed on the provided "hardware-summary"; instead, lsmod shows "rtw88_8723de". Then, the module "r8169" tried to load the firmware, but that module belongs to the GbE card. hardware-summary: lspci -knn: 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15) ... lspci -knn: Kernel driver in use: r8169 lspci -knn: Kernel modules: r8169 lspci -knn: 03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8723DE 802.11b/g/n PCIe Adapter [10ec:d723] ... lspci -knn: Kernel modules: rtw88_8723de syslog: Mar 25 20:35:04 main-menu[262]: (process:3599): modprobe: FATAL: Module rtw_8723de not found. Mar 25 20:35:04 main-menu[262]: (process:3599): modprobe: FATAL: Module rtw_8723de not found in directory /lib/modules/5.10.0-4-amd64 ... Mar 25 20:35:10 kernel: [ 133.234274] r8169 :02:00.0: firmware: failed to load rtl_nic/rtl8168h-2.fw (-2) Mar 25 20:35:10 kernel: [ 133.234278] r8169 :02:00.0: Direct firmware load for rtl_nic/rtl8168h-2.fw failed with error -2 Mar 25 20:35:10 kernel: [ 133.234281] r8169 :02:00.0: Unable to load firmware rtl_nic/rtl8168h-2.fw (-2)
Bug#985915: ldd: disagrees with file(1) about whether a file is dynamically or statically linked
Package: libc-bin Version: 2.31-10 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I’m debugging a weird lintian problem and found the cause to be: tglase@tglase-nb:~ $ ldd /tmp/libjsound.so statically linked tglase@tglase-nb:~ $ file /tmp/libjsound.so /tmp/libjsound.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=de56e345230aca1c7c8cf06b56e9c21ee53031f5, stripped tglase@tglase-nb:~ $ objdump -p /tmp/libjsound.so | fgrep NEED | wc -l 0 I’m attaching this file so this can be fixed in the right package. I believe that if both agree lintian won’t complain. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc-bin depends on: ii libc6 2.31-10 Versions of packages libc-bin recommends: ii manpages 5.10-1 libc-bin suggests no packages. -- no debconf information libjsound.so Description: application/sharedlib
Bug#985898: /usr/bin/r: /usr/bin/r is not stripped
On March 25, 2021 1:31:11 PM GMT-03:00, Dirk Eddelbuettel wrote: > >Howdy, > >On 25 March 2021 at 13:12, Rogério Brito wrote: >| I was looking into some of my executables and discovered that >/usr/bin/r is >| not stripped and it contains debugging info on my system: >| >| ,[ file /usr/bin/r ] >| | /usr/bin/r: ELF 64-bit LSB pie executable, x86-64, version 1 >(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, >BuildID[sha1]=36aeb221c38bd7fdf3140a4c6481ff739573e634, for GNU/Linux >3.2.0, with debug_info, not stripped >| ` >| >| Is it desired? I would have expected it to work (as usual) with a >-dbgsym >| package being created if so needed (with all the justifications >there). > >No that is likely an oversight as I need to "manually" copy the binary >from >the R package location to /usr/bin. > >common-binary-post-install-arch:: >dh_installdirs usr/bin usr/share/man/man1 >install -v -m 0644 $(debRlib)/littler/bin/r >$(CURDIR)/debian/$(package)/usr/bin/ >install -v -m 0644 $(debRlib)/littler/man-page/r.1 >$(CURDIR)/debian/$(package)/usr/share/man/man1/ > >So yes -- that install call is lacking a '-s' flag. Will add it now. > >Thanks! > >Dirk Dear Dirk, I just saw your other message. I believe that, in the case of Debian, install, with or without -s may do the wrong thing. Just copy the files where they belong to and debhelper will do the rest (it does for my packages). I don't know how to integrate that cleanly with your upstream build system, though. Thanks once again for packaging R, Rogério Brito. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#985914: steam: HOWTO use KDE xdg-desktop-portal on 64-bit systems
Package: steam Version: 1.0.0.68-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, * What led up to the situation? steam:i386 has a recommendation for xdg-desktop-portal-backend:i386 * What exactly did you do (or not do) that was effective (or ineffective)? I attempted to satisfy the recommendation with a KDE backend, as KDE Plasma is my primary desktop environment. xdg-desktop-portal-kde fails to satisfy the dependency. xdg-dekstop-portal-kde:i385 conflicts (via libkf5services-bin) with my 64-bit KDE Plasma environemtn. * What was the outcome of this action? Unable to satisfy the dependency with a KDE backend. * What outcome did you expect instead? Would like to have Steam (in particular, but also Flatpack, Snap, etc.) to use KDE applications, selectors, themes, etc. that are part of the XDG Portal Service. Even in the case of a 64-bit KDE install and a 32-bit Steam (or Flatpack application). Maybe this is not properly a steam bug, and should be handled by xdg-dekstop-portal-kde source package instead. But, I do think stream architecture-dependent dependency is a big part of why this isn't working so well for me. - -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'stable-updates'), (900, 'stable-debug'), (900, 'testing'), (900, 'stable'), (850, 'proposed-updates-debug'), (850, 'proposed-updates'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages steam depends on: ii curl 7.74.0-1.1 ii debconf [debconf-2.0] 1.5.75 ii file 1:5.39-3 ii libc6 2.31-9 ii libgcc-s1 [libgcc1]10.2.1-6 ii libgl1 1.3.2-1 ii libgl1-mesa-dri20.3.4-1 ii libgpg-error0 1.38-2 ii libstdc++6 10.2.1-6 ii libudev1 247.3-3 ii libx11-6 2:1.7.0-2 ii libxcb-dri3-0 1.14-3 ii libxcb11.14-3 ii libxinerama1 2:1.1.4-2 ii xz-utils 5.2.5-1.0 Versions of packages steam recommends: ii bubblewrap 0.4.1-3 ii ca-certificates 20210119 ii fontconfig 2.13.1-4.2 ii fonts-liberation 1:1.07.4-11 ii konsole [x-terminal-emulator]4:20.12.3-1 ii libasound2-plugins 1.2.2-2 ii libxss1 1:1.2.3-1 ii mesa-vulkan-drivers 20.3.4-1 ii steam-devices1.0.0.68-1 ii xdg-desktop-portal 1.8.1-1 ii xdg-desktop-portal-kde [xdg-desktop-portal-backend] 5.20.5-1 ii xdg-utils1.1.3-4 ii xterm [x-terminal-emulator] 366-1 ii zenity 3.32.0-6 Versions of packages steam suggests: pn nvidia-driver-libs pn nvidia-vulkan-icd Versions of packages steam is related to: ii libc6 2.31-9 ii libgl11.3.2-1 ii libgl1-mesa-dri 20.3.4-1 ii libglx-mesa0 [libglx-vendor] 20.3.4-1 pn libglx-nvidia0 ii libxcb-dri3-0 1.14-3 pn nvidia-driver pn nvidia-driver-libs pn nvidia-driver-libs-i386 - -- debconf information: * steam/license: steam/need-nvidia-i386: * steam/question: I AGREE steam/purge: -BEGIN PGP SIGNATURE- iHQEARECADQWIQTFhn3a8g2plxzZYyjnmmovsbVAWQUCYF0TghYcYnNzQGlndWFu YXN1aWNpZGUubmV0AAoJEOeaai+xtUBZ3G0Ani0lF9saXCaWh1ie/t+HcpW7AsHF AJ9yjDb8kD7jtM13ZHeBNWEOAbKBnw== =X6fC -END PGP SIGNATURE-
Bug#984953: libgtkmm-3.0-1v5: GParted crashes on Gdk::Pixbuf::get_width() const ()
Control: reassign -1 gparted 1.2.0-1 On Thu, 25 Mar 2021 at 22:22:33 +0100, Bernhard Übelacker wrote: > In the end it looks like in refresh_combo_devices [2] it > is attempted to load a harddisk icon. > > This failed for some reason in [3], therefore a local variable > "theme_icon" contains a null pointer, which gets unconditionally > called member function get_width on and therefore > crashes a few lines later. This looks like a gparted bug, rather than a libgtkmm-3.0-1v5 bug. GParted::Utils::mk_pixbuf calls Gtk::Widget::render_icon_pixbuf, presumably a wrapper around gtk_widget_render_icon_pixbuf(), which is documented to return NULL if the "stock ID" is not known (as it presumably is in this case); but then it calls theme_icon->get_width() and theme_icon->get_height() without first checking whether theme_icon is a null pointer. gtk_widget_render_icon_pixbuf() is documented as having been deprecated since GTK 3.10, released in 2013. The recommended replacement is gtk_icon_theme_load_icon(). smcv
Bug#985913: please package new release 0.3.4
Package: elpa-nov Version: 0.3.0-1 Severity: wishlist Version 0.3.4 has been released on 2021-03-23. Note the new upstream homepage https://depp.brause.cc/nov.el/
Bug#985911: , with attachment
With the attachment… --- a/debian/rules +++ b/debian/rules @@ -1,13 +1,5 @@ #!/usr/bin/make -f -# Compile specific platforms: -# dpkg-architecture -aarmhf -c debian/rules novena u-boot-imx .. - -# Build local .debs restricted to specific platforms: -# DEB_BUILD_PROFILES=pkg.u-boot.notools fakeroot \ -# dpkg-architecture -aarmhf -c debian/rules binary-arch \ -# subarchs='u-boot-rockchip ..' u-boot-rockchip_platforms='puma-rk3399 ..' - include /usr/share/dpkg/architecture.mk include /usr/share/dpkg/pkg-info.mk export DEBIAN_REVISION ?= $(shell echo $(DEB_VERSION) | sed -e 's,.*+dfsg,+dfsg,') @@ -34,12 +26,28 @@ LDFLAGS := $(patsubst -Wl$(comma)%,%,$(LDFLAGS)) notools := $(filter pkg.uboot.notools,$(DEB_BUILD_PROFILES)) -# DEB_BUILD_PROFILES=pkg.uboot.subarch.SUBARCH may -# limit builds to only certain subarchitectures -# e.g. pkg.uboot.subarch.rockchip will only build rockchip targets. -subarchs := $(or $(patsubst pkg.uboot.subarch.%,u-boot-%,\ - $(filter pkg.uboot.subarch.%,$(DEB_BUILD_PROFILES))),\ - $(shell dh_listpackages --arch --no-package=u-boot-tools)) +subarchs := $(shell dh_listpackages --arch --no-package=u-boot-tools) + +# Each .deb P in subarch contains $(P_platforms). +# These profiles remove values from $(P_platforms) for debugging. + +# DEB_BUILD_PROFILES='pkg.uboot.subarch.P1 pkg.uboot.subarch.P2' +# removes all platforms but in packages u-boot-P1 u-boot-P2. +only_subarchs := $(patsubst pkg.uboot.subarch.%,u-boot-%,\ + $(filter pkg.uboot.subarch.%,$(DEB_BUILD_PROFILES))) +ifneq (,$(only_subarchs)) + $(foreach pkg,$(filter-out $(only_subarchs),$(subarchs)),$(eval \ +$(pkg)_platforms :=)) +endif + +# DEB_BUILD_PROFILES='pkg.uboot.platform.P1 pkg.uboot.platform.P2' +# removes all platforms but P1 P2. +only_platforms := $(patsubst pkg.uboot.platforms.%,%,\ +$(filter pkg.uboot.platforms.%,$(DEB_BUILD_PROFILES))) +ifneq (,$(only_platforms)) + $(foreach pkg,$(subarchs),$(eval \ +$(pkg)_platforms := $(filter $(only_platforms),$($(pkg)_platforms +endif # Enable debugging symbols and remove build paths export HOSTCFLAGS = -g -ffile-prefix-map=$(CURDIR)=. @@ -48,7 +56,7 @@ export HOSTCFLAGS = -g -ffile-prefix-map=$(CURDIR)=. dh $@ override_dh_auto_build-indep: u-boot-qemu -override_dh_auto_build-arch: $(subarchs) debian/build/rockchip_make_fit_atf +override_dh_auto_build-arch: $(subarchs) ifeq ($(notools),) override_dh_auto_build-arch: build-tools endif @@ -65,11 +73,6 @@ define build_template # Qemu platforms set $(platform)_CROSS_COMPILE. $(platform): -# Only build platform if pkg.uboot.platform.* in DEB_BUILD_PROFILES -# matches or if no pkg.uboot.platform.* are specified -ifneq (,$(if $(filter pkg.uboot.platform.%,$(DEB_BUILD_PROFILES)),\ - $(filter pkg.uboot.platform.$(platform),$(DEB_BUILD_PROFILES)),\ - $(platform))) # debian/rules: building platform: $(platform) mkdir -p debian/build/$(platform) @@ -95,11 +98,6 @@ ifneq (,$(if $(filter pkg.uboot.platform.%,$(DEB_BUILD_PROFILES)),\ install-$(platform): dh_install -p$(package) $(addprefix debian/build/$(platform)/,$($(platform)_targets)) usr/lib/u-boot/$(platform) -else - echo "skipping $(platform), not specified in DEB_BUILD_PROFILES" - install-$(platform): - echo "skipping $(platform), not specified in DEB_BUILD_PROFILES" -endif endef $(foreach package, u-boot-qemu $(subarchs),\
Bug#985912: eapol_test does not work with IPv6 because CONFIG_IPV6 is not enabled
Package: eapoltest Severity: normal Hi, When running eapol_test against IPv6 addresses, the tool reports: Invalid IP address '2001:db8::123' eapol_test: eapol_test.c:1033: wpa_init_conf: Assertion `0' failed. because in debian/config/wpasupplicant/linux the CONFIG_IPV6=y is missing. Once adding this, the tools works just fine with IPv6 also. Please enable it. TIA! Best regards, Kilian
Bug#985911: u-boot: selection of built platforms when debugging list
Source: u-boot Severity: wishlist Tags: patch I would like your opinion on some connected issues, before maybe opening separate bugs. The attached changes are not tested, only a basis for discussion. -- > > Could you describe the problem d3d3c952 is solving? > If u-boot-rockchip is excluded using build profiles, it fails to > build, due to debian/u-boot-rockchip.install trying to install the > not created debian/build/rockchip_make_fit_atf. The attachment suggest a probably better fix, reverting to the original behaviour: build all packages, even if some eventually contain no platforms because of profiles. Files unrelated with platforms should then be handled correctly. -- e1e273b7ed11a7528311f50f24db9e35be4562da debian/rules: When pkg.uboot.platform.* is in DEB_BUILD_PROFILES, only The attached commit implements the same effect by overriding some Make variables instead of increasing the complexity of recipes. The data flow is more straightforward: targets.mk sets the default values for all variables profiles override some variables Make recipes are as independant as possible on the variable contents -- > > Profiles cannot select the 'u-boot' package. > Haven't tried, but I don't see why that wouldn't work. DEB_BUILD_PROFILES=pkg.uboot.subarch.rochchipselects u-boot-rockchip.deb but DEB_BUILD_PROFILES=pkg.uboot.subarch.u-boot fails to select u-boot-u-boot.deb On second thought, it may have worked before my changes because subarch=u-boot was a special case in some shell scripts. If you want to restore this possibility, I see two options: - special-case pkg.uboot.subarch.u-boot so that this works: DEB_BUILD_PROFILES='pkg.uboot.subarch.u-boot pkg.uboot.subarch.rockchip' - change the interface to: DEB_BUILD_PROFILES='pkg.uboot.subarch.u-boot pkg.uboot.subarch.u-boot-rockchip' Do you prefer consistency or shorter command lines?
Bug#980539: sun4i_codec kernel warnings due to missing card->owner
Hi list, What is needed to get the patch from #980539 included? Looking at the source for 5.10.24 the problem still exists and is limited to sun4i_codec and (potentially) rk3288_hdmi_analog modules. These modules have a "stuct snd_soc_card" with no "owner" set, which triggers kernel warnings when loading the module. All other 128 files with "stuct snd_soc_card" do also have "owner = THIS_MODULE". GRTNX, RobJE
Bug#985562: libclutter-imcontext-0.1-bin: post-installation script subprocess - error exit status 1
Control: clone -1 -2 Control: reassign -2 libclutter-imcontext-0.1-bin 0.1.4-3.1 Control: severity -2 serious Dear libclutter-imcontext-0.1-bin maintainer, The following was reported against upgrade-reports. On 20-03-2021 00:05, Fenimore wrote: > - Did any packages fail to upgrade? > Yes but not completely - Configuration time errors during like: > FYI: "Paramétrage" ~= "Setting up" > > Paramétrage de libclutter-imcontext-0.1-bin (0.1.4-3.1) ... > Cannot load module /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im- > ibus.so: GModule (/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im- > ibus.so) initialization check failed: GLib version too old (micro mismatch) > /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so does not > export Clutter IM module API: GModule (/usr/lib/x86_64-linux-gnu/clutter- > imcontext/immodules/im-ibus.so) initialization check failed: GLib version too > old (micro mismatch) > [1mdpkg:[0m erreur de traitement du paquet libclutter-imcontext-0.1-bin > (--configure) : > installed libclutter-imcontext-0.1-bin package post-installation script > subprocess returned error exit status 1 > > apt upgrade last lines: > FYI:"Des erreurs ont été rencontrées pendant l'exécution" ~= "errors > encountered during execution" > > Des erreurs ont été rencontrées pendant l'exécution : > libclutter-imcontext-0.1-bin > ibus-clutter:amd64 > Log ended: 2021-03-19 13:39:05 Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#985895: Any volunter to write a test for bamclipper?
On Thu, Mar 25, 2021 at 02:00:11PM -0700, Nilesh Patra wrote: > > I found those files here[1] inside examples/ dir -- it also has > outputted *.primer.bam* files, so I think it is sensible > to assume that these files work. > I follow this in other packages as well, when on adding certain bam or > sam files, "something" happens which is good for > at least a preliminary functioning test :-) > > I added a autopkgtest to the salsa repo, please take in a look. Thanks a lot - I'll check tomorrow. > PS: Please consider enabling salsa CI for any new packages that you > might push. I did so for this one for now. I'll do so for every package I'm touching and would have probably done soon for this package. However, what I would love even more if someone would fix inject-into-salsa-git to approach this automatically. Kind regards Andreas. > [1]: https://github.com/tommyau/bamclipper -- http://fam-tille.de
Bug#985903: lib3MF.so.1: undefined symbol: zip_fclose
Package: lib3mf1
Version: 1.8.1+ds-3
Severity: important
Tags: patch upstream
Dear Maintainer,
* running CGAL Demos
* Recompiled lib from sources, after debugging and patching
NB : wouldn't build as was
* cgal-demo runs and can r/w *.3mf files
* had expected cgal demo to work;
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-security
APT policy: (650, 'focal-security'), (500, 'focal-updates'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-44-lowlatency (SMP w/2 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_IE.UTF-8), LANGUAGE=en_IE (charmap=UTF-8) (ignored: LC_ALL set to
en_IE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lib3mf1 depends on:
ii libc6 2.31-0ubuntu9.2
ii libgcc-s1 10.2.0-5ubuntu1~20.04
ii libstdc++6 10.2.0-5ubuntu1~20.04
ii libuuid12.34-0.1ubuntu9.1
lib3mf1 recommends no packages.
lib3mf1 suggests no packages.
-- no debconf information
--- lib3mf-1.8.1+ds/CMakeLists.txt 2019-01-08 12:36:18.0 +
+++ ./l2/CMakeLists.txt 2021-03-25 16:41:10.790119112 +
@@ -18,14 +18,20 @@
# use the cmake option -DNMR_COM_NATIVE:BOOL=ON to build the COM interface
option(NMR_COM_NATIVE "Implement a COM interface" OFF)
+## `uname -s`
+if ("${CMAKE_HOST_SYSTEM_NAME}" STREQUAL "Linux")
+option(USE_INCLUDED_ZLIB "Use included zlib" OFF)
+option(USE_INCLUDED_LIBZIP "Use included libzip" OFF)
+else()
option(USE_INCLUDED_ZLIB "Use included zlib" ON)
option(USE_INCLUDED_LIBZIP "Use included libzip" ON)
+endif()
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
# using GCC
add_definitions(-DBUILD_DLL)
add_compile_options(-Wall)
- SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -O2")
+ SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -O2 -Wall")
elseif (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
# using GCC
add_definitions(-DBUILD_DLL)
@@ -114,6 +120,26 @@
endif()
target_link_libraries(${PROJECT_NAME}_s ${LIBUUID_PATH})
endif()
+if (NOT USE_INCLUDED_LIBZIP)
+ ZIP
+find_library(LIBZIP_PATH zip)
+if(NOT LIBZIP_PATH)
+message(FATAL_ERROR "libzip not found")
+endif()
+message("USE_INCLUDED_LIBZIP ... " ${USE_INCLUDED_LIBZIP})
+message("LIBZIP_PATH ... " ${LIBZIP_PATH})
+target_link_libraries(${PROJECT_NAME}_s ${LIBZIP_PATH})
+endif()
+if (NOT USE_INCLUDED_ZLIB)
+ ZLIB
+find_library(ZLIB_PATH zip)
+if(NOT ZLIB_PATH)
+message(FATAL_ERROR "zlib not found")
+endif()
+message("USE_INCLUDED_ZLIB ... " ${USE_INCLUDED_ZLIB})
+message("ZLIB_PATH ... " ${ZLIB_PATH})
+target_link_libraries(${PROJECT_NAME}_s ${ZLIB_PATH})
+endif()
else()
# wd4996 masks the deprecated-warning
target_compile_options(${PROJECT_NAME}_s PUBLIC
"$<$:/Od;/Ob0;/Gm;/sdl;/W3;/WX;/FC;/wd4996>")
@@ -148,9 +174,9 @@
install(FILES ${CMAKE_BINARY_DIR}/lib3MF.pc DESTINATION
${CMAKE_INSTALL_LIBDIR}/pkgconfig)
#
-option(LIB3MF_TESTS "Switch whether the tests of Lib3MF should be build" ON)
+option(LIB3MF_TESTS "Switch whether the tests of Lib3MF should be build" OFF)
+### extra dependency package googletests
if(NOT DEFINED LIB3MF_TESTS)
- set(LIB3MF_TESTS TRUE)
+ set(LIB3MF_TESTS FALSE)
endif()
message("LIB3MF_TESTS ... " ${LIB3MF_TESTS})
if(LIB3MF_TESTS)
# prevent: warning: catching polymorphic type ‘class std::bad_alloc’ by value
[-Wcatch-value=]
diff -rU 3 lib3mf-1.8.1+ds/Source/Common/Platform/NMR_ImportStream_Memory.cpp
l2/Source/Common/Platform/NMR_ImportStream_Memory.cpp
--- lib3mf-1.8.1+ds/Source/Common/Platform/NMR_ImportStream_Memory.cpp
2019-01-08 12:36:18.0 +
+++ l2/Source/Common/Platform/NMR_ImportStream_Memory.cpp 2021-03-25
15:59:44.169063834 +
@@ -62,7 +62,7 @@
try {
m_Buffer.resize((size_t)cbCapacity);
}
- catch (std::bad_alloc) {
+ catch (std::bad_alloc &x) {
throw CNMRException(NMR_ERROR_INVALIDBUFFERSIZE);
}
# prevent: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
diff -rU 3 lib3mf-1.8.1+ds/Source/Model/Reader/NMR_ModelReaderNode.cpp
l2/Source/Model/Reader/NMR_ModelReaderNode.cpp
--- lib3mf-1.8.1+ds/Source/Model/Reader/NMR_ModelReaderNode.cpp 2019-01-08
12:36:18.0 +
+++ l2/Source/Model/Reader/NMR_ModelReaderNode.cpp 2021-03-25
15:59:21.067063320 +
@@ -161,21 +161,23 @@
switch (NodeType) {
case XMLREADERNODETYPE_STARTELEMENT:
pXMLReader->GetLocalName(&pszLocalName,
&nCount);
-
Bug#985592: unblock: libnbd/1.6.2-1
Hi Hilko, On Sat, Mar 20, 2021 at 06:24:57PM +0100, Sebastian Ramacher wrote: > Control: tags -1 + moreinfo > > On 2021-03-20 15:27:28 +0100, Salvatore Bonaccorso wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > X-Debbugs-Cc: car...@debian.org,ben...@debian.org > > > > Hi Release team > > > > [Disclaimer, not the maintainer requesting the unblock, but I'm CC'ing > > Hilko to confirm]. > > > > Please unblock package libnbd > > > > [ Reason ] > > The new upstream version uploaded libnbd/1.6.2-1 contains as fix for > > CVE-2021-20286. I was announced as > > https://listman.redhat.com/archives/libguestfs/2021-March/msg00092.html > > . An isolated fix was > > https://gitlab.com/nbdkit/libnbd/-/commit/2216190ecbbd853648df6a3280c17b345b0907a0 > > . The request is done to have bullseye without this CVE open. > > > > [ Impact ] > > Denial of service. > > > > [ Tests ] > > I have not performed tests specific to the version update 1.6.1 to > > 1.6.2. > > > > [ Risks ] > > Arguably there is a new upstream version, but the attached debdiff > > collects all the changes additionally done. > > > > Again, Hilko is CC'ed to confirm if this is safe for bullseye. > > > > [ Checklist ] > > [ ] all changes are documented in the d/changelog > > [ ] I reviewed all changes and I approve them > > [x] attach debdiff against the package in testing > > > > [ Other info ] > > It should propably have an explicit acknowledgment for the unblock > > from Hilko. > > Please remove the moreinfo tag once ACKed by Hilko. Any input on this? Or was the version not aimed for bullseye? Regards, Salvatore
Bug#985895: Any volunter to write a test for bamclipper?
On 2021-03-26 01:58, Andreas Tille wrote: > Hi folks, > > I have packaged bamclipper[1] since it is a precondition for the > pipeline covpipe[2] which is developed and used in my institute. > (@Steffen, possibly another column in the spreadsheet.) > > Despite bamclipper is pretty easy I would love to have some autopkgtest > but I'm lacking the needed files (bam + bam.bai as well as bedpe). The > README.md[3] has an example that could be used as autopkgtest - so it > should not be a hard job for someone who has such files / knows how to > find some examples. I found those files here[1] inside examples/ dir -- it also has outputted *.primer.bam* files, so I think it is sensible to assume that these files work. I follow this in other packages as well, when on adding certain bam or sam files, "something" happens which is good for at least a preliminary functioning test :-) I added a autopkgtest to the salsa repo, please take in a look. PS: Please consider enabling salsa CI for any new packages that you might push. I did so for this one for now. [1]: https://github.com/tommyau/bamclipper Nilesh
Bug#972467: aom: Please package new upstream stable release (3.0.0)
Package: libaom0
Version: 1.0.0.errata1-3
Followup-For: Bug #972467
X-Debbugs-Cc: d...@jones.dk, by...@debian.org,
972467-submit...@bugs.debian.org, jcowg...@debian.org
Hi.
During the time since the bug was filed, another version of libaom was
released and it seems to be very desirable, since it is supposed to be
faster, due to optimizations.
The source, together with a message of what changed can be found at:
https://aomedia.googlesource.com/aom/+/v3.0.0
Please, if possible, upload a new version to experimental, since we are
frozen.
Thanks,
Rogério Brito.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libaom0 depends on:
ii libc6 2.31-9
libaom0 recommends no packages.
libaom0 suggests no packages.
-- no debconf information
--
Rogério Brito : rbrito@{users.sf.net,gmail.com} : GPG: 4096R/BCFC
cynic.cc/blog : https://salsa.debian.org/rbrito : cynic.cc/blog/about
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40gmail.com
Bug#985867: filter out GCC's lto flags for the skia build
severity 985867 wishlist thanks Hi, Am 25.03.21 um 08:59 schrieb Matthias Klose: > When building LO with lto turned on (https://wiki.debian.org/ToolChain/LTO), > the build fails, because one module (skia) is still built with clang, > apparently > for performance reasons. I didn't check if that's still needed for recent > compiler versions. No idea either, I just use it to not derivate from upstream unneccessarily. > So just don't use the lto flags when building the skia module. The build > system > already has a macro for that for cflags (gb_FilterOutClangCFLAGS), but is > lacking one for ldflags, and these targets seem to be autogenerated. I didn't > look into filtering this, Yeah, I gave up somewhen, too > and provided a wrapper for clang/clang++ instead. OK. Will add to git. Regards, Rene
Bug#985895: Any volunter to write a test for bamclipper?
Hi folks, I have packaged bamclipper[1] since it is a precondition for the pipeline covpipe[2] which is developed and used in my institute. (@Steffen, possibly another column in the spreadsheet.) Despite bamclipper is pretty easy I would love to have some autopkgtest but I'm lacking the needed files (bam + bam.bai as well as bedpe). The README.md[3] has an example that could be used as autopkgtest - so it should not be a hard job for someone who has such files / knows how to find some examples. Kind regards Andreas. [1] https://salsa.debian.org/med-team/bamclipper [2] https://salsa.debian.org/med-team/covpipe [3] https://salsa.debian.org/med-team/bamclipper/-/blob/master/README.md -- http://fam-tille.de
Bug#985909: ITP: open62541 -- implementation of OPC UA (IEC 62541)
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: open62541 Version : 1.2 Upstream Author : various (*) * URL : http://open62541.org * License : MPL-2.0 Programming Lang: C Description : implementation of OPC UA (IEC 62541) open62541 is an implementation of OPC UA (OPC Unified Architecture) written in the common subset of the C99 and C++98 languages. The library is usable with all major compilers and provides the necessary tools to implement dedicated OPC UA clients and servers, or to integrate OPC UA-based communication into existing applications. (*) https://github.com/open62541/open62541/blob/master/AUTHORS
Bug#985908: d/targets.mk: factor dependency of u-boot-rockchip on debian/build/rockchip_make_fit_atf
Source: u-boot
Severity: wishlist
Tags: patch
Hello.
The attached patch continues your 8e9ee998 by also sharing the Make
dependency.
>From 024f17c638379559309c943fe3e91ed1643e3bf7 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez
Date: Thu, 25 Mar 2021 19:26:53 +0100
Subject: Write only once that rockchip depends on rockchip_make_fit_atf
This follows 8e9ee998.
diff --git a/debian/targets.mk b/debian/targets.mk
index 8f39881e15..cda47c6ca2 100644
--- a/debian/targets.mk
+++ b/debian/targets.mk
@@ -1,6 +1,9 @@
# Target architectures supported by u-boot in Debian.
# debian/rules includes this Makefile snippet.
+# This dependency holds on both arm64 and armhf.
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=979483;msg=22
+u-boot-rockchip: debian/build/rockchip_make_fit_atf
debian/build/rockchip_make_fit_atf: arch/arm/mach-rockchip/make_fit_atf.py
mkdir -p debian/build
sed '1 s,/usr/bin/env python.*,/usr/bin/python3,' \
@@ -57,8 +60,6 @@ ifeq (${DEB_HOST_ARCH},arm64)
dpkg-gencontrol_args += "-Vu-boot-rockchip:Built-Using=$(shell dpkg-query
-Wf \
'$${source:Package} (= $${source:Version})' arm-trusted-firmware)"
- u-boot-rockchip: debian/build/rockchip_make_fit_atf
-
# Vagrant Cascadian
u-boot-rockchip_platforms += firefly-rk3399
firefly-rk3399_assigns := BL31=/usr/lib/arm-trusted-firmware/rk3399/bl31.elf
@@ -353,9 +354,6 @@ else ifeq (${DEB_HOST_ARCH},armhf)
# Silent a debhelper warning about an unused substvar.
dpkg-gencontrol_args += -Vu-boot-rockchip:Built-Using=
- # https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=979483;msg=22
- u-boot-rockchip: debian/build/rockchip_make_fit_atf
-
# Vagrant Cascadian , 2GB and 4GB variants
u-boot-rockchip_platforms += firefly-rk3288
firefly-rk3288_targets := idbloader.img spl/u-boot-spl.bin u-boot.bin \
Bug#985889: qemu-user-static: make binfmt setup configurable
On 25/03/2021 19:24, Michael Tokarev wrote:
> 25.03.2021 16:33, Silvano Cirujano Cuesta wrote:
>> Package: qemu-user-static
>> Version: 1:5.2+dfsg-9
>> Severity: wishlist
>> X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com
>>
>> Current packaging of qemu-user-static is providing two different things
>> at once and without any declared configuration possibility (no .conffiles):
>> * QEMU-User statically linked binaries.
>> * binfmt_misc configuration
>
> Yes, it's been this way since forever.
My wording "current packaging" was biased by my wish: that future packaging
doesn't hard-code the configuration within the package :-)
>
>> From release "buster" upwards the binfmt_misc configuration being
>> provided by this package is registering the qemu-user-static binaries
>> with the flag "fix_binary". This configuration might be convenient in
>> most cases (suppose that's was it's so now), but is a problem in some
>> others.
>
>> Not being able to configure binfmt_misc is a blocker for this package in
>> the scenarios where that default configuration doesn't fit. The
>
> So far I don't see where it doesn't fit.
We have the issue that the qemu-user binaries being provided by the host don't
support some syscalls required by some of the running containers.
With the qemu-user-static configuration there's no way around it, since the
"fix_binary" flag doesn't give the container a chance to provide it's own
fitting binaries. Reconfiguring binfmt_misc not to use the "fix_binary" flag
would only survive until next qemu-user-static upgrade.
Therefore the assumption that the qemu-user binaries provided by the host will
fit ALL consumers (containers and chroots included) is wrong for us.
So the only solution is getting rid of the persistence ("fix_binary" flag) of
the host's binaries. But how?
One option is using multiarch/qemu-user-static [1], or doing pretty much the
same ourselves: letting a container change the binfmt_misc configuration of the
host! As you can imagine, that's a security risk and a source for conflicts if
having different containers with different requirements on qemu-user binaries.
I know in fact some people doing so and facing exactly these issues.
[1] https://github.com/multiarch/qemu-user-static
Another possibility is only using qemu-user binaries provided by this package
(pretty much extracting them from the package), but not the configuration and
instead use our own configuration. This solution has less drawbacks than the
previous one, but it's still a hacky workaround to return to the pre-buster
times (where the "fix_binary" flag wasn't active).
>
>
>> configuration can be changed providing different update-binfmts
>> templates than those provided by this package and running
>> update-binfmts. But qemu-user-static upgrades overwrite the changes.
>>
>> I don't know which is the best solution, but one possible is putting
>> the update-binfmts templates now available in /usr/share/binfmts under
>> /etc and making them configuration files (adding a .conffiles).
>
> It seems like way too much trouble for both the maintainer and the user.
IMO current configuration is perfectly fine as a default, but giving the users
the possibility to change it.
I don't really see where do you see the troubles for either maintainer or user.
I wonder why the configuration has to be hard-coded into a package that is
providing very valuable binaries. I'd be happy only with the binaries and being
able to provide my own configuration.
>
>> Just for those curious when this might be an issue. Containers trying to
>> use new syscalls not provided by the QEMU-User binaries provided by the host
>> require newer QEMU-User binaries.
>
> How about installing latest qemu-user-static on host instead? It is a
> self-contained package (as all binaries are statically linked). This way
> all your containers will benefit immediately, too.
Any solution involving the installation of qemu-user-static (no matter if it's
in the host or in a priviledged container) involves using exactly the same
binaries on all consumers. And as mentioned above, doesn't always fit.
>
> Thanks,
>
> /mjt
Thanks for your quick reply,
Silvano
Bug#985890: libglib2.0-0: usage of glib_check_version() should generate tight package dependencies
On 25/03/2021 18.16, Simon McVittie wrote:
On Thu, 25 Mar 2021 at 15:05:21 +0100, Andreas Beckmann wrote:
during buster -> bullseye upgrade tests with piuparts I observed some
failures related to glib dependencies:
Setting up libclutter-imcontext-0.1-bin (0.1.4-3.1) ...
Cannot load module
/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so: GModule
(/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so)
initialization check failed: GLib version too old (micro mismatch)
This seems more like a bug in ibus-clutter to me? I would expect most
I've posted a patch to the ibus-clutter bug that tightens the dependency
to (>= upstream_version). The should be the minimal solution for
bullseye, it should be revisited for bookworm .
Perhaps it would be more reasonable to special-case this function
in the symbols file to generate a dependency on at least version
${major}.${minor}.0? That would accommodate what fcitx5-gtk does, and
seems like a better boundary for stable (x.even.z) releases at least.
I'm leaving this bug for you to implement this or downgrade severity or
close it.
Andreas
Bug#984851: qalculate-gtk (ITA)
On Mon, Mar 15, 2021 at 09:26:38AM +0900, Norbert Preining wrote: > Yeah, updating to some recent 3.N version is good. But nothing is urgent > now since we cannot push that out to unstable/testing for bullseye. Hi both, thanks for stepping up to co-maintain Qalculate! to prevent it missing Debian 12. I have today pushed to qalculate-gtk the same repo conversion to follow upstream git as I did for libqalculate. The default branch is now debian/master with master following upstream on both. I've merged all the proposed changes and made sure it builds locally, but I could still do with some help updating the packaging from 3.3.0 to 3.17.0 e.g. Files-Excluded, copyright, install, Build-Depends. Once that's done, we can upload to experimental and be ready for unstable. > Concerning IRC, yes, I hang around in a few chat rooms, any specific you > are around normally? On debian irc I am usually in #debian-ai, > #debian-kde, #debian-private, #debian-qt-kde, pluse some others on other > servers. Username normally norbert or norb. Thanks, I've joined #debian-qt-kde as it seemed the smallest/relevant one. I'm also around #debian-mentors, #debian-java, #debian-games etc. signature.asc Description: PGP signature
Bug#985858: Fails to start with seccomp violation (eventfd2)
On 25/03/2021 01:17, peter green wrote:> The second is to fix the autopkgtest. It's currently
"neutral"> due to a dependency on rust-boxxy which is not present in> Debian. From taking a
quick look it looks to me like any> tests that rely on boxxy could probablly be patched out and> the
dev-dependency dropped to allow the remainder of the> testsuite to run.
I started investigating this approach.
Unfortunately the only way I could find to prevent the build
of examples/boxxy.rs was to remove the file completely.
I then ran into a couple of issues in bench.rs,
Firstly IPv4Protocol had been renamed to IPProtocol
and moved to pktparse::ip as part of adding ipv6
support to pktparse.
https://github.com/bestouff/pktparse-rs/commit/ebb468ace109339b9833e0e633494a410549fb41
Secondly centrifuge::parse was renamed to centrifuge::parse_eth in
https://github.com/kpcyrd/sniffglue/commit/2bf3785b275fc2b52ba039fc6a11c91bb4b069f8
After fixing these issues the autopkgtest parses.
I've attatched a diff to this mail, should I go ahead and push/
upload it? (If I get no response I will upload it in a week or so)
commit fbb9a8f3bd4d7181d1f858897905a04788a4ca71
Author: Peter Michael Green
Date: Thu Mar 25 19:39:24 2021 +
fix sniffglue autopkgtest
diff --git a/src/sniffglue/debian/changelog b/src/sniffglue/debian/changelog
index 9f828e33..0ac7fcd5 100644
--- a/src/sniffglue/debian/changelog
+++ b/src/sniffglue/debian/changelog
@@ -1,8 +1,15 @@
rust-sniffglue (0.11.1-6) UNRELEASED-FIXME-AUTOGENERATED-DEBCARGO; urgency=medium
+ * Team upload.
+ * Package sniffglue 0.11.1 from crates.io using debcargo 2.4.0
+ * Drop dev-dependency on boxxy and remove examples/boxxy.rs
+to allow the rest of the tests to run.
+ * Fix a couple of compile errors in benches/bench.rs
+
+ [ kpcyrd ]
* Add missing syscalls to seccomp filter (Closes: #985858)
- -- kpcyrd Tue, 23 Mar 2021 02:42:26 +0100
+ -- Peter Michael Green Thu, 25 Mar 2021 19:15:48 +
rust-sniffglue (0.11.1-5) unstable; urgency=medium
diff --git a/src/sniffglue/debian/patches/fix-bench.patch b/src/sniffglue/debian/patches/fix-bench.patch
new file mode 100644
index ..4ec255ca
--- /dev/null
+++ b/src/sniffglue/debian/patches/fix-bench.patch
@@ -0,0 +1,49 @@
+Index: sniffglue/benches/bench.rs
+===
+--- sniffglue.orig/benches/bench.rs
sniffglue/benches/bench.rs
+@@ -43,7 +43,8 @@ mod tests {
+ use structs::tcp::TCP::Text;
+
+ use pktparse::ethernet::{MacAddress, EtherType, EthernetFrame};
+-use pktparse::ipv4::{IPv4Header, IPv4Protocol};
++use pktparse::ipv4::IPv4Header;
++use pktparse::ip::IPProtocol;
+ use pktparse::tcp::TcpHeader;
+
+ let mut pkt = Vec::new();
+@@ -72,7 +73,7 @@ mod tests {
+ flags: 2,
+ fragment_offset: 0,
+ ttl: 55,
+-protocol: IPv4Protocol::TCP,
++protocol: IPProtocol::TCP,
+ chksum: 64371,
+ source_addr: "93.184.216.34".parse().unwrap(),
+ dest_addr: "192.168.44.55".parse().unwrap(),
+@@ -98,14 +99,14 @@ mod tests {
+ Text(String::from_utf8(HTML.to_vec()).unwrap())
+ ;
+
+-let x = centrifuge::parse(&pkt);
++let x = centrifuge::parse_eth(&pkt);
+ assert_eq!(expected, x);
+ }
+
+ #[bench]
+ fn bench_empty(b: &mut Bencher) {
+ b.iter(|| {
+-centrifuge::parse(&[]).ok();
++centrifuge::parse_eth(&[]).ok();
+ });
+ }
+
+@@ -123,7 +124,7 @@ mod tests {
+ pkt.extend(HTML.iter());
+
+ b.iter(|| {
+-centrifuge::parse(&pkt).ok();
++centrifuge::parse_eth(&pkt).ok();
+ });
+ }
+ }
diff --git a/src/sniffglue/debian/patches/remove-boxxy.patch b/src/sniffglue/debian/patches/remove-boxxy.patch
new file mode 100644
index ..5df3a596
--- /dev/null
+++ b/src/sniffglue/debian/patches/remove-boxxy.patch
@@ -0,0 +1,48 @@
+Index: sniffglue/Cargo.toml
+===
+--- sniffglue.orig/Cargo.toml
sniffglue/Cargo.toml
+@@ -102,8 +102,6 @@ version = "0.5"
+
+ [dependencies.users]
+ version = "0.10"
+-[dev-dependencies.boxxy]
+-version = "0.11"
+ [target."cfg(target_os=\"linux\")".dependencies.syscallz]
+ version = "0.15.0"
+ [badges.travis-ci]
+Index: sniffglue/examples/boxxy.rs
+===
+--- sniffglue.orig/examples/boxxy.rs
/dev/null
+@@ -1,30 +0,0 @@
+-#[macro_use] extern crate boxxy;
+-extern crate sniffglue;
+-extern crate env_logger;
+-
+-fn stage1(sh: &mut boxxy::Shell, _args: Vec) -> Result<(), boxxy::Error> {
+-shprintln!(sh, "[*] starting stage1");
+-sniffglue::sandbox::activate_stage1().unwrap();
+-shprintln!(sh, "[+] activated!");
+-Ok(())
+-}
+-
+-fn stage2(sh: &mut boxxy::She
Bug#985891: dicompyler doesn't start
Control: severity -1 serious Control: tags -1 upstream Control: forwarded -1 https://github.com/bastula/dicompyler/issues/137 Hi, thanks a lot for this bug report. On Thu, Mar 25, 2021 at 03:09:56PM +0100, Cédric wrote: > raise DistributionNotFound(req, requirers) > pkg_resources.DistributionNotFound: The 'matplotlib<2.2,>=1.3.0' distribution > was not found and is required by dicompyler This is a bit misleading error output. The problem is that the code might work with some former matplotlib versions / Python3 versions but it is using a private module of matplotlib[1] which is simply forbidden. I have reported this issue upstream (see above). Since this makes dicompyler unusable I have bumped the bug severity to serious ... which will possibly mean that dicompyler will not be distributed with the next Debian release if upstream does not come up with some solution in the next 2-3 weeks. Kind regards, Andreas. [1] https://github.com/matplotlib/matplotlib/issues/10709 -- http://fam-tille.de
Bug#985453: libclutter-imcontext-0.1-bin: fails to upgrade from 'buster': insufficient dependencies
Followup-For: Bug #985453
Control: tag -1 patch
Control: retitle -1 ibus-clutter: fails to upgrade from 'buster': insufficient
dependencies
Hi,
attached is a patch that tightens the libglib2.0-0 dependency to the
(upstream) version used at build time.
This should be a minimal solution for bullseye.
For bullseye+1 please consider relaxing or dropping this version check.
Andreas
diff -Nru ibus-client-clutter-0.0+git20090728.a936bacf/debian/changelog
ibus-client-clutter-0.0+git20090728.a936bacf/debian/changelog
--- ibus-client-clutter-0.0+git20090728.a936bacf/debian/changelog
2021-01-26 11:53:02.0 +0100
+++ ibus-client-clutter-0.0+git20090728.a936bacf/debian/changelog
2021-03-25 20:11:34.0 +0100
@@ -1,3 +1,10 @@
+ibus-client-clutter (0.0+git20090728.a936bacf-7) UNRELEASED; urgency=medium
+
+ * Tighten libglib2.0-0 dependency due to glib_check_version() usage.
+(Closes: #985453)
+
+ -- Andreas Beckmann Thu, 25 Mar 2021 20:11:34 +0100
+
ibus-client-clutter (0.0+git20090728.a936bacf-6) unstable; urgency=low
* Bump Standards-Version to 4.5.0: nothing needs to be changed.
diff -Nru ibus-client-clutter-0.0+git20090728.a936bacf/debian/control
ibus-client-clutter-0.0+git20090728.a936bacf/debian/control
--- ibus-client-clutter-0.0+git20090728.a936bacf/debian/control 2021-01-26
10:41:49.0 +0100
+++ ibus-client-clutter-0.0+git20090728.a936bacf/debian/control 2021-03-25
18:56:21.0 +0100
@@ -16,6 +16,7 @@
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
Depends: libclutter-imcontext-0.1-bin, ${misc:Depends}, ${shlibs:Depends}
+ , ${glib:Depends}
Multi-Arch: same
Description: ibus input method framework for clutter
IBus is an Intelligent Input Bus. It is a new input framework for Linux OS. It
diff -Nru ibus-client-clutter-0.0+git20090728.a936bacf/debian/rules
ibus-client-clutter-0.0+git20090728.a936bacf/debian/rules
--- ibus-client-clutter-0.0+git20090728.a936bacf/debian/rules 2012-06-28
16:39:34.0 +0200
+++ ibus-client-clutter-0.0+git20090728.a936bacf/debian/rules 2021-03-25
20:11:34.0 +0100
@@ -13,6 +13,9 @@
DEB_DH_MAKESHLIBS_ARGS_ibus-clutter := -Xim-ibus
DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)\
+# tighten libglib2.0-0 dependency due to glib_check_version() usage (#985453)
+DEB_DH_GENCONTROL_ARGS_ibus-clutter = -- -V'glib:Depends=$(shell dpkg-query -f
'$${package} (>= $${source:Upstream-Version})' -W libglib2.0-0)'
+
GIT_URL = git://git.moblin.org/ibus-client-clutter
clean::
Bug#985907: rnp: accepts weak cryptographic primitives
Package: src:rnp Version: 0.14.0-6 Control: forwarded -1 https://github.com/rnpgp/rnp/issues/1281 rnp currently accepts signatures over weak or untrustworthy cryptographic primitives. At the moment, there is no API for adjusting which mechanisms are acceptable, and all implemented algorithms are accepted, including (for example) signatures from very small RSA keys, or made over known-broken digests like MD5. This is probably not a responsible way to ship the library. maybe we want to follow thunderbird's approach of baking in a more strict policy via patches until upstream offers an API that lets the library user select their desired policy. --dkg signature.asc Description: PGP signature
Bug#985906: /usr/bin/uscan: uscan: detect/notify simple cases of d/watch improvement
Package: devscripts Version: 2.21.1 Severity: wishlist File: /usr/bin/uscan Dear Maintainer, Regarding the issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985665 it would be interesting to test simple alternatives and check if it pulls greater maximum version than by the current one given by content of the d/watch file. In this case simply by replacing \.tar\.gz by @ARCHIVE_EXT@ improves the uscan result. At least, this could target then an activity for lintian-brush/Janitor & co. Thanks! -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- export DEBFULLNAME="Patrice Duroux" export DEBEMAIL="patrice.dur...@gmail.com" -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/12 CPU threads) 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 devscripts depends on: ii dpkg-dev 1.20.7.1 ii fakeroot 1.25.3-1.1 ii file 1:5.39-3 ii gnupg 2.2.27-1 ii gpgv 2.2.27-1 ii libc6 2.31-10 ii libfile-dirlist-perl 0.05-2 ii libfile-homedir-perl 1.006-1 ii libfile-touch-perl0.11-1 ii libfile-which-perl1.23-1 ii libipc-run-perl 20200505.0-1 ii libmoo-perl 2.004004-1 ii libwww-perl 6.53-1 ii patchutils0.4.2-1 ii perl 5.32.1-3 ii python3 3.9.2-2 ii sensible-utils0.0.14 ii wdiff 1.2.2-2+b1 Versions of packages devscripts recommends: ii apt 2.2.2 ii curl7.74.0-1.1 ii dctrl-tools 2.24-3+b1 ii debian-keyring 2021.03.24 pn dput | dupload ii equivs 2.3.1 ii libdistro-info-perl 1.0 ii libdpkg-perl1.20.7.1 ii libencode-locale-perl 1.05-1.1 ii libgit-wrapper-perl 0.048-1 ii libgitlab-api-v4-perl 0.26-1 ii liblist-compare-perl0.55-1 ii liblwp-protocol-https-perl 6.10-1 ii libsoap-lite-perl 1.27-1 ii libstring-shellquote-perl 1.04-1 ii libtry-tiny-perl0.30-1 ii liburi-perl 5.08-1 ii licensecheck3.1.1-2 ii lintian 2.104.0 ii man-db 2.9.4-2 ii patch 2.7.6-7 ii pristine-tar1.49 ii python3-apt 2.1.7 ii python3-debian 0.1.39 ii python3-magic 2:0.4.20-3 ii python3-requests2.25.1+dfsg-2 ii python3-unidiff 0.5.5-2 ii python3-xdg 0.27-2 ii strace 5.10-1 ii unzip 6.0-26 ii wget1.21-1+b1 ii xz-utils5.2.5-2 Versions of packages devscripts suggests: ii adequate 0.15.6 ii at3.1.23-1.1 ii autopkgtest 5.16 pn bls-standalone ii build-essential 12.9 pn check-all-the-things pn cvs-buildpackage ii debhelper 13.3.4 pn devscripts-el pn diffoscope pn disorderfs pn dose-extra pn duck pn faketime ii gnuplot-x11 [gnuplot] 5.4.1+dfsg1-1 pn how-can-i-help ii libauthen-sasl-perl 2.1600-1.1 pn libdbd-pg-perl ii libfile-desktopentry-perl 0.22-2 pn libnet-smtps-perl pn libterm-size-perl ii libtimedate-perl 2.3300-2 pn libyaml-syck-perl ii mailutils [mailx] 1:3.11.1-5 pn mmdebstrap pn mozilla-devscripts pn mutt ii openssh-client [ssh-client] 1:8.4p1-5 pn piuparts ii postgresql-client 13+225 ii postgresql-client-13 [postgresql-client] 13.2-1 pn pristine-lfs ii quilt 0.66-2.1 pn ratt pn reprotest pn svn-buildpackage pn w3m
Bug#979592: RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
On Thu, 2021-03-25 at 09:12 +0200, Andrius Merkys wrote: > On 2021-03-25 03:07, Mathias Gibbens wrote: > > On Wed, 2021-03-24 at 07:58 +0200, Andrius Merkys wrote: > > > 3. Upstream copyright entry in debian/copyright lacks years. If > > > the > > > upstream do not limit their copyright in years, I usually take > > > the > > > year > > > range spanning commits in the upstream Git repository (spotted in > > > openrct2-objects). > > > > OK, I've done as you suggest and looked at the git history to put > > some years in the d/copyright file. > > Looks good. Thanks! > > > > 4. In debian/rules of openrct2-title-sequences, there is a hard- > > > coded > > > upstream version of the package. This may easily get forgotten > > > when > > > packaging new upstream versions. I suggest replacing the hard- > > > coded > > > version with $(DEB_VERSION_UPSTREAM) from /usr/share/dpkg/pkg- > > > info.mk, > > > see [1] for example. > > > > That is indeed a nicer way to get the version. The upstream > > developers have released a few revisions of the current "version" > > that > > have a sequential letter appended, but the actual path for some of > > the > > files doesn't have that extra letter in it. I've updated the shell > > script so there's no longer a hard-coded value. > > I was about to suggest using sed to drop these sequential letters, > but I > see you already implemented this. > > > > You have indicated that you are going to be the sole maintainer > > > for > > > the > > > packages, which is OK. But have you considered team-maintaining > > > your > > > packages in Debian Games Team? Team maintenance has its > > > advantages, > > > for > > > example, team members would be able to commit and upload the > > > packages > > > fixing bugs and uploading new upstream versions. But of course > > > the > > > choice to team-maintain or not is yours. > > > > For now I'm planning to be the sole maintainer, but I'd be happy > > to > > eventually transition to a team setup as well. Beyond just getting > > openrct2 into Debian, I wanted to do all the work myself for the > > learning experience, and after going through the process of > > releasing > > updated versions as they become available once or twice, I'd be > > fine > > with bringing things under a team umbrella. > > Sounds reasonable. In the meantime you may join the Debian Games Team > if > you have not done that before. > > > > [1] https://sources.debian.org/src/byteman/4.0.12-2/debian/rules/ > > I uploaded new versions of all three packages to mentors.d.n, and > > pushed corresponding commits with the changes to the repositories: > > > > > > https://salsa.debian.org/gibmat/openrct2/-/commit/8bb65232c57b63c9ca18912772e4e78742a7cff7 > > > > https://salsa.debian.org/gibmat/openrct2-objects/-/commit/4e67cc2bac4b263c4a74c889923d2ba0e2f8effb > > > > https://salsa.debian.org/gibmat/openrct2-title-sequences/-/commit/8bbc6367390dd14e063fceb0a1346306eb30fdb5 > > > > If things are good, I believe the packages are ready. I've built > > them > > locally for my buster system, and everything that I've tested is > > working correctly. > > > > Also, once the packages are uploaded to NEW, I'll push a tag to > > each > > repository to properly record which commit corresponds to the > > uploaded > > version of each package. > > I have uploaded all three packages, and they have appeared in NEW. > Please push git tags for the commits you have mentioned (I use 'gbp > tag > --sign-tags'), and let's wait for ftpmaster's response. > > As said earlier, let me know should you need later sponsoring of > these > packages. > > Best, > Andrius > Thank you Andrius! I appreciate the time you've taken to sponsor my packages. I've pushed a signed tag to each repository. As new releases are made, or if there's any feedback from ftpmasters, I'll contact you directly. Mathias signature.asc Description: This is a digitally signed message part
Bug#985905: linux-image-5.10.0-5-amd64: inserting Hauppauge HVR-950 into USB port crashes kernel
Package: src:linux
Version: 5.10.24-1
Severity: normal
X-Debbugs-Cc: k...@resceu.s.u-tokyo.ac.jp
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Inserted a Hauppauge WinTV HVR-950 USB video capture device into a USB
port.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Nothing I have tried is effective. Removing the out-of-tree ZFS modules had no
effect. Increasing the amount of RAM installed had no effect.
* What was the outcome of this action?
Kernel crashed. Error starts with "usb 1-4: Couldn't create media mixer
entities. Error: -19". That is followed by "BUG: kernel NULL pointer
dereference, address: 0008" and then a lot more (dmesg capture
attached below). Computer appears to still be working after this but it hangs
when trying to shut down. It must be manually power cycled.
* What outcome did you expect instead?
Not a crash.
*** End of the template - remove these template lines ***
-- Package-specific info:
** Version:
Linux version 5.10.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP
Debian 5.10.24-1 (2021-03-19)
** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-5-amd64 root=/dev/mapper/stealthone--vg-root ro
** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
Unable to read kernel log; any relevant messages should be attached
relevant dmesg contents after inserting dongle:
[ 3317.011760] usb 1-4: new high-speed USB device number 4 using ehci-pci
[ 3317.168868] usb 1-4: config 1 interface 0 altsetting 0 endpoint 0x81 has
invalid wMaxPacketSize 0
[ 3317.191590] usb 1-4: New USB device found, idVendor=2040, idProduct=7200,
bcdDevice= 0.05
[ 3317.191613] usb 1-4: New USB device strings: Mfr=1, Product=2,
SerialNumber=10
[ 3317.191622] usb 1-4: Product: WinTV HVR-950
[ 3317.191630] usb 1-4: Manufacturer: Hauppauge
[ 3317.191638] usb 1-4: SerialNumber: 4035520276
[ 3317.201380] usb 1-4: Couldn't create media mixer entities. Error: -19
[ 3317.201417] BUG: kernel NULL pointer dereference, address: 0008
[ 3317.201425] #PF: supervisor read access in kernel mode
[ 3317.201432] #PF: error_code(0x) - not-present page
[ 3317.201438] PGD 0 P4D 0
[ 3317.201454] Oops: [#1] SMP NOPTI
[ 3317.201467] CPU: 0 PID: 8951 Comm: kworker/0:5 Tainted: P OE
5.10.0-5-amd64 #1 Debian 5.10.24-1
[ 3317.201474] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./Inagua CRB, BIOS 4.6.4 11/25/2011
[ 3317.201534] Workqueue: usb_hub_wq hub_event [usbcore]
[ 3317.201585] RIP: 0010:snd_media_device_create+0x1d3/0x260 [snd_usb_audio]
[ 3317.201596] Code: e8 6a cf 70 d6 8b 04 24 eb ac b8 ed ff ff ff 48 8b 7c 24
08 89 c2 48 c7 c6 a0 9d 3a c1 89 44 24 14 e8 49 cf 70 d6 48 8b 04 24 <48> 8b 50
08 8b 44 24 14 48 85 d2 0f 85 1f 21 00 00 eb 9c 49 8b 45
[ 3317.201604] RSP: 0018:b01242667908 EFLAGS: 00010246
[ 3317.201614] RAX: RBX: a04c056418b8 RCX:
[ 3317.201621] RDX: a04c3b028760 RSI: a04c3b018a00 RDI: a04c3b018a00
[ 3317.201627] RBP: c13b7c20 R08: R09: b01242667630
[ 3317.201634] R10: b01242667628 R11: 988cb368 R12: c13b7c20
[ 3317.201640] R13: a04c056418b8 R14: 0001 R15: c13974a0
[ 3317.201649] FS: () GS:a04c3b00()
knlGS:
[ 3317.201656] CS: 0010 DS: ES: CR0: 80050033
[ 3317.201663] CR2: 0008 CR3: 000133af4000 CR4: 06f0
[ 3317.201670] Call Trace:
[ 3317.201722] usb_audio_probe+0x782/0xa60 [snd_usb_audio]
[ 3317.201739] ? ktime_get_mono_fast_ns+0x4e/0x90
[ 3317.201787] usb_probe_interface+0xe2/0x2a0 [usbcore]
[ 3317.201803] really_probe+0xf2/0x440
[ 3317.201814] driver_probe_device+0xe1/0x150
[ 3317.201825] ? driver_allows_async_probing+0x50/0x50
[ 3317.201835] bus_for_each_drv+0x7e/0xc0
[ 3317.201846] __device_attach+0xd8/0x1d0
[ 3317.201857] bus_probe_device+0x8e/0xa0
[ 3317.201867] device_add+0x399/0x840
[ 3317.201915] usb_set_configuration+0x46f/0x830 [usbcore]
[ 3317.201966] usb_generic_driver_probe+0x4c/0x70 [usbcore]
[ 3317.202014] usb_probe_device+0x39/0xf0 [usbcore]
[ 3317.202027] really_probe+0xf2/0x440
[ 3317.202038] driver_probe_device+0xe1/0x150
[ 3317.202048] ? driver_allows_async_probing+0x50/0x50
[ 3317.202056] bus_for_each_drv+0x7e/0xc0
[ 3317.202067] __device_attach+0xd8/0x1d0
[ 3317.202077] bus_probe_device+0x8e/0xa0
[ 3317.202087] device_add+0x399/0x840
[ 3317.202136] usb_new_device.cold+0x111/0x2d3 [usbcore]
[ 3317.202183] hub_event+0x146a/0x17e0 [usbcore]
[ 3317.202199] ? __pm_runtime_suspend+0x51/0xf0
[ 3317.202212] process_one_work+0x1b6/0x350
[ 3317.202223] worker_thread+0x53/0x3
Bug#985853: debian-installer: Whitespace before a commented line in preseed file causes line to be parsed
On Thu, 25 Mar 2021 10:49:06 -0400
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> Well none of the examples ever have spaces before # for comments.
> The documentation page you linked to doesn't even mention comments at
> all. I would agree that perhaps it should. I have certainly
> encountered file types before where comments had to have # at the
> start of the line.
May I suggest inserting the following as the last bullet point item at
the top of "B.3. Creating a preconfiguration file" the following:
A comment consist of a line which *starts* with a sharp character ("#")
and extends the length of that line.
https://www.debian.org/releases/stable/i386/apbs03.en.html
The emphasis on the word "starts" should probably be italics, or, in
HTML, .
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Bug#985889: qemu-user-static: make binfmt setup configurable
25.03.2021 16:33, Silvano Cirujano Cuesta wrote: Package: qemu-user-static Version: 1:5.2+dfsg-9 Severity: wishlist X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com Current packaging of qemu-user-static is providing two different things at once and without any declared configuration possibility (no .conffiles): * QEMU-User statically linked binaries. * binfmt_misc configuration Yes, it's been this way since forever. From release "buster" upwards the binfmt_misc configuration being provided by this package is registering the qemu-user-static binaries with the flag "fix_binary". This configuration might be convenient in most cases (suppose that's was it's so now), but is a problem in some others. Not being able to configure binfmt_misc is a blocker for this package in the scenarios where that default configuration doesn't fit. The So far I don't see where it doesn't fit. configuration can be changed providing different update-binfmts templates than those provided by this package and running update-binfmts. But qemu-user-static upgrades overwrite the changes. I don't know which is the best solution, but one possible is putting the update-binfmts templates now available in /usr/share/binfmts under /etc and making them configuration files (adding a .conffiles). It seems like way too much trouble for both the maintainer and the user. Just for those curious when this might be an issue. Containers trying to use new syscalls not provided by the QEMU-User binaries provided by the host require newer QEMU-User binaries. How about installing latest qemu-user-static on host instead? It is a self-contained package (as all binaries are statically linked). This way all your containers will benefit immediately, too. Thanks, /mjt
Bug#985670: CVE-2020-27781 CVE-2020-27839
Source: ceph Source-Version: 14.2.18-1 On Mon, Mar 22, 2021 at 11:17:02AM +0100, Moritz Muehlenhoff wrote: > On Mon, Mar 22, 2021 at 10:11:29AM +0100, Thomas Goirand wrote: > > On 3/21/21 7:59 PM, Moritz Muehlenhoff wrote: > > > Package: ceph > > > Severity: important > > > Tags: security > > > X-Debbugs-Cc: Debian Security Team > > > > > > CVE-2020-27781 > > > https://bugs.launchpad.net/manila/+bug/1904015 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1900109 > > > https://github.com/ceph/ceph/commit/1b8a634fdcd94dfb3ba650793fb1b6d09af65e05 > > > (octopus) > > > https://github.com/ceph/ceph/commit/7e3e4e73783a98bb07ab399438eb3aab41a6fc8b > > > (nautilus) > > > https://github.com/ceph/ceph/commit/956ceb853a58f6b6847b31fac34f2f0228a70579 > > > (luminous) > > > > > > CVE-2020-27839 > > > https://tracker.ceph.com/issues/44591 > > > https://github.com/ceph/ceph/pull/38259 > > > https://github.com/ceph/ceph/commit/23f2604d6f9ac16779b4ac43aab6e4e434f2e8ec > > > > > > Cheers, > > > Moritz > > > > > > > Hi Moritz, > > > > To me, these issues were fixed in 14.2.16, which is already in > > unstable/bullseye, and aslo in Buster backports. It matches what I have > > in memory (but I'm not 100% sure). > > > > I tried applying the above patches, and that's how it felt too. > > I can confirm that CVE-2020-27781 is fixed in sid, > 7e3e4e73783a98bb07ab399438eb3aab41a6fc8b > landed in v14.2.16 and thus in unstable. I've updated the Security Tracker. > > But CVE-2020-27839 was fixed in the nautilus branch in > 843b2e9cd4cb996165d1818ebff125f1414f90c5 > which only ended up in v14.2.17 and is thus missing in unstable/testing. > Right? And so adressed it looks with the 14.2.18-1 upload to unstable, marking the bug as such fixed. Regards, Salvatore
Bug#985904: installation-reports: partman defaults to use existing ESP partitions on LVM volumes
Package: installation-reports Severity: normal X-Debbugs-Cc: vagr...@debian.org Boot method: network Image version: https://d-i.debian.org/daily-images/arm64/20210325-02:16/netboot/netboot.tar.gz Date: 2021-03-25 ~17:00 UTC Machine: apm mustang Partitions: Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs 16359696 0 16359696 0% /dev tmpfs tmpfs 3281996 524 3281472 1% /run /dev/mapper/mst0vg-mst00--root ext4 4721184 1233016 3227664 28% / tmpfs tmpfs 16409976 0 16409976 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock /dev/sda1 vfat5117204352507368 1% /boot/efi tmpfs tmpfs 3281992 0 3281992 0% /run/user/1000 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[E] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: I was performing an installation with existing LVM volumes of several virtual machines, and partman defaulted to selecting the ESP partitions that were present inside the LVM volumes of the virtual machines, but would fail to proceed during the installation. Going back to the partitioning menu and setting each of the undesired ESP partitions to "do not use this partition" eventually allowed the install to proceed. Similar issue with swap partitions, though I'm sure it would have happily proceeded to re-initialize all the swap partitions in the virtual machine images... not sure how to handle that sanely; other than potentially suspend-to-disk images, it is fairly easy to recover from having the swap signature rewritten. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210325-02:07:18" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux mst00 5.10.0-5-arm64 #1 SMP Debian 5.10.24-1 (2021-03-19) aarch64 GNU/Linux usb-list: usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Manufacturer: Linux 5.10.0-5-arm64 xhci-hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 01: xHCI Host Controller [1d6b:0003] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 03 usb-list:Manufacturer: Linux 5.10.0-5-arm64 xhci-hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 03 Device 01: xHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Manufacturer: Linux 5.10.0-5-arm64 xhci-hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 04 Device 01: xHCI Host Controller [1d6b:0003] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 03 usb-list:Manufacturer: Linux 5.10.0-5-arm64 xhci-hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub lsmod: Module Size Used by lsmod: ufs81920 0 lsmod: qnx4 24576 0 lsmod: hfsplus 110592 0 lsmod: hfs65536 0 lsmod: cdrom 61440 2 hfsplus,hfs lsmod: minix 40960 0 lsmod: msdos 24576 0 lsmod: fuse 155648 0 lsmod: nls_ascii 16384 1 lsmod: nls_cp437 20480 1 lsmod: efivarfs 20480 1 lsmod: dm_mod135168 36 lsmod: raid1 57344 1 lsmod: md_mod172032 2 raid1 lsmod: xfs 1359872 0 lsmod: jfs 192512 0 lsmod: btrfs1388544 0 lsmod: xor20480 1 btrfs lsmod: xor_neon 16384 1 xor lsmod: raid6_pq 106496 1 btrfs lsmod: libcrc32c 16384 2 btrfs,xfs lsmod: vfat 28672 1 lsmod: fat81920 2 msdos,vfat lsmod: ext4 765952 1 lsmod: crc16 16384 1 ext4 lsmod: mbcache24576 1 ext4 lsmod: jb
Bug#985453: libclutter-imcontext-0.1-bin: fails to upgrade from 'buster': insufficient dependencies
Control: reassign -1 ibus-clutter 0.0+git20090728.a936bacf-6 Control: affects -1 + libclutter-imcontext-0.1-bin On Thu, 18 Mar 2021 14:26:22 +0100 Andreas Beckmann wrote: Setting up libclutter-imcontext-0.1-bin (0.1.4-3.1) ... Cannot load module /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so: GModule (/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so) initialization check failed: GLib version too old (micro mismatch) /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so does not export Clutter IM module API: GModule (/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so) initialization check failed: GLib version too old (micro mismatch) The actual culprit is /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so from ibus-clutter. Andreas
Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs
Hi.
You have quoted the following platforms, but I have found no matching
defconfig: an Olimex TERES-I DIY laptop, several Olimex arm64 boards,
pinetab. Do you know if such defconfigs already exist?
Once crust is available, adapting u-boot should be simple because
similar changes have already been tested by Arnaud for Mobian.
--- a/debian/control
+++ b/debian/control
@@ -7,6 +7,7 @@ Build-Depends:
arm-trusted-firmware (>= 2.4+dfsg) [arm64],
bc,
bison,
+ crust-firmware [arm64],
debhelper-compat (= 13),
device-tree-compiler,
flex,
--- a/debian/targets.mk
+++ b/debian/targets.mk
@@ -187,7 +187,8 @@ ifeq (${DEB_HOST_ARCH},arm64)
# Benoit Delcour (1.2)
# Arnaud Ferraris (1.1, 1.2)
u-boot-sunxi_platforms += pinephone
- pinephone_assigns := BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
+ pinephone_assigns := BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin \
+SCP=/usr/lib/crust-firmware/pinephone.bin
pinephone_targets := arch/arm/dts/sun50i-a64-pinephone-1.1.dtb \
arch/arm/dts/sun50i-a64-pinephone-1.2.dtb spl/sunxi-spl.bin \
u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb u-boot.bin uboot.elf
Bug#985887: gscan2pdf: saves b&w scanned pages in inverted mode
Thanks for the report. Please start gscan2pdf from the command line: gscan2pdf --log=log reproduce the problem, quit, and post the input image, log file and the resulting PDF. OpenPGP_signature Description: OpenPGP digital signature
Bug#985890: libglib2.0-0: usage of glib_check_version() should generate tight package dependencies
On Thu, 25 Mar 2021 at 15:05:21 +0100, Andreas Beckmann wrote:
> during buster -> bullseye upgrade tests with piuparts I observed some
> failures related to glib dependencies:
>
> Setting up libclutter-imcontext-0.1-bin (0.1.4-3.1) ...
> Cannot load module
> /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so: GModule
> (/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so)
> initialization check failed: GLib version too old (micro mismatch)
This seems more like a bug in ibus-clutter to me? I would expect most
calls to glib_check_version() to be more like this:
if (glib_check_version (2, 64, 0) == NULL)
do something the new way
else
do something the old way
like these arbitrarily-chosen examples from codesearch:
https://sources.debian.org/src/gmime/3.2.7-1/gmime/gmime-charset.c/?hl=196#L196
https://sources.debian.org/src/pidgin-skype/20140930+svn665+dfsg-1/libskype.c/?hl=417#L417
https://sources.debian.org/src/gst-plugins-good1.0/1.18.3-1/gst/udp/gstudp.c/?hl=35#L35
If ibus-clutter wants to second-guess the dependency system and do a
runtime check, it should probably be checking against the (hard-coded)
version it requires, not the version it happens to have been compiled
against; or it seems less problematic to do a check that ignores the
micro version, like fcitx5-gtk does:
https://sources.debian.org/src/fcitx5-gtk/5.0.3-1/gtk2/fcitxim.c/?hl=24#L24
We do set the Build-Depends-Package in the symbols file, so making
ibus-clutter build-depend on its required GLib version should do the
right thing without needing any runtime checks.
> Using the glib_check_version() symbol should generate package
> dependencies that ensure the version check passes.
I think this would give us unnecessarily strict dependencies that result
in trouble with getting packages migrated - I'd prefer to avoid having
more packages stuck behind GLib than we strictly have to, and it would
seem slightly absurd for gst-plugins-good to get a dependency on GLib
2.66.8 as a result of wanting to print a warning if run against GLib
2.35 or older...
There's also a cost to this for the glib2.0 source package: we'd have
to either generate the symbols file at build-time from a template, or
remember to update the symbols file by hand when importing new upstream
releases (which is fine if there's a good reason, but not OK if it's
neutral or counterproductive).
Perhaps it would be more reasonable to special-case this function
in the symbols file to generate a dependency on at least version
${major}.${minor}.0? That would accommodate what fcitx5-gtk does, and
seems like a better boundary for stable (x.even.z) releases at least.
smcv
Bug#985902: debian-edu-config: internal web site: partially broken / wrong content
Package: debian-edu-config Version: 2.11.51 Severity: normal While testing installation of a main server using various locales I noticed that the internal web site didn't show up in case of pt_PT locale, instead a question appeared what to do with the file index.html.pt; also some translations were wrong content wise (concerning esp. links), most probably caused by a poor sed script used some time ago. Wolfgang
Bug#985719: praat: Menu bar invisible
* Joonas Kylmälä [2021-03-24 12:48]: I was able to launch GNOME/Xorg finally[1] and Praat works there just fine. The problem only happens with GNOME/Wayland. Are you able to reproduce with GNOME/Wayland? Other GTK3 programs on GNOME/Wayland seem to work OK, e.g. I tried Totem / Video player. Maybe Praat has some X11 specific code that is now causing trouble? Thank you for this followup. I will eventually try Praat on Gnome/Wayland to see if I can reproduce this bug. Best, Rafael Laboissière
Bug#985900: move bash completion files from bash-completion to apt
Package: apt Version: 2.2.2 Control: clone -1 -2 Control: reassign -2 bash-completion Control: block -2 by -1 Julian said that bash-completion files for apt-cache and apt-get located in /usr/share/bash-completion/completions should be moved from the bash-completion package to the apt package. Completions for the relatively new apt command already reside with apt. Implementation: * apt starts shipping the completions and gains versioned Replaces bash-completion. * bash-completion drops the completions. Depending on how important we consider completions, bash-completion can declare versioned Breaks on apt. Forcing an early upgrade of apt doesn't seem too bad. * The apt upload needs to be done first. Helmut
Bug#985899: apt bash-completion should complete build-dep ./somefile.dsc
Package: apt Version: 2.2.2 Severity: minor In bash, $ apt build-dep ./foo does not complete an existing file foo.dsc, while apt would happily consue it. It only completes bare package names. Helmut
Bug#985898: /usr/bin/r: /usr/bin/r is not stripped
Howdy, On 25 March 2021 at 13:12, Rogério Brito wrote: | I was looking into some of my executables and discovered that /usr/bin/r is | not stripped and it contains debugging info on my system: | | ,[ file /usr/bin/r ] | | /usr/bin/r: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=36aeb221c38bd7fdf3140a4c6481ff739573e634, for GNU/Linux 3.2.0, with debug_info, not stripped | ` | | Is it desired? I would have expected it to work (as usual) with a -dbgsym | package being created if so needed (with all the justifications there). No that is likely an oversight as I need to "manually" copy the binary from the R package location to /usr/bin. common-binary-post-install-arch:: dh_installdirs usr/bin usr/share/man/man1 install -v -m 0644 $(debRlib)/littler/bin/r $(CURDIR)/debian/$(package)/usr/bin/ install -v -m 0644 $(debRlib)/littler/man-page/r.1 $(CURDIR)/debian/$(package)/usr/share/man/man1/ So yes -- that install call is lacking a '-s' flag. Will add it now. Thanks! Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#985898: /usr/bin/r: /usr/bin/r is not stripped
Rock, meet hard place. The last change I made for Debian was just that: https://bugs.debian.org/968531 So I may have to close your bug report instead. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#985898: /usr/bin/r: /usr/bin/r is not stripped
Package: r-cran-littler
Version: 0.3.12-1
Severity: wishlist
File: /usr/bin/r
Dear Dirk,
I was looking into some of my executables and discovered that /usr/bin/r is
not stripped and it contains debugging info on my system:
,[ file /usr/bin/r ]
| /usr/bin/r: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=36aeb221c38bd7fdf3140a4c6481ff739573e634, for GNU/Linux 3.2.0,
with debug_info, not stripped
`
Is it desired? I would have expected it to work (as usual) with a -dbgsym
package being created if so needed (with all the justifications there).
Thanks for caring about R in Debian,
Rogério Brito.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages r-cran-littler depends on:
ii libc62.31-9
ii r-base-core [r-api-4.0] 4.0.4-1
r-cran-littler recommends no packages.
Versions of packages r-cran-littler suggests:
pn r-cran-getopt
-- no debconf information
--
Rogério Brito : rbrito@{users.sf.net,gmail.com} : GPG: 4096R/BCFC
cynic.cc/blog : https://salsa.debian.org/rbrito : cynic.cc/blog/about
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40gmail.com
Bug#920937: firmware-atheros: Firmware QCA6174 crashes on wakeup from suspend
I haven't used suspend for about a year now due to #911411 and remote work. No issues with hibernation though.
Bug#985897: ruby-serverspec: Bogus manpage for serverspec-init
Package: ruby-serverspec Version: 2.37.2-1 Severity: minor Dear Maintainer, the serverspec-init manpage does not refer to serverspec-init at all but to GoldenCheetah. Is that a joke or a copy&paste error? Although I'm reporting this from a Stretch box, I checked that the wrong manpage is still in the current source package: https://salsa.debian.org/ruby-team/ruby-serverspec/-/blob/master/debian/serverspec-init.1 Many thanks for providing serverspec as a Debian package. Keep up the excellent work! Best Christopher -- System Information: Debian Release: 9.13 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-14-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ruby-serverspec depends on: ii ruby 1:2.3.3 ii ruby-multi-json 1.11.2-3 ii ruby-rspec 3.5.0c3e0m0s0-1 ii ruby-rspec-its 1.2.0-2 ii ruby-specinfra 2.66.0-1 ruby-serverspec recommends no packages. ruby-serverspec suggests no packages. -- no debconf information
Bug#985896: makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels
Package: makedumpfile Version: 1:1.6.8-3 Severity: normal X-Debbugs-Cc: ioanna-maria.alifier...@canonical.com Dear Maintainer, makedumpfile does not create the dmesg. in /var/crash. This happens only on 5.10+ kernel because 5.10 kernel introduces a new lockless ringbuffer. This issue has been addressed upstream with commits : [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer) [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values) LP-bug : https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1921403 I'll open an MR shortly at https://salsa.debian.org/debian/makedumpfile [1] https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd [2] https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages makedumpfile depends on: ii libc6 2.31-10 ii libdw1 0.183-3 ii libelf10.183-3 ii liblzo2-2 2.10-2 ii perl 5.32.1-3 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages makedumpfile recommends: ii crash7.2.9-2 ii kexec-tools 1:2.0.20-2.1 makedumpfile suggests no packages. -- no debconf information
Bug#803625: grub-common: 10_linux doesn't merge rootflags= from GRUB_CMDLINE_LINUX*
> It results in a grub.cfg line like: > linux /root/boot/vmlinuz-4.2.0-1-amd64 root=UUID=d430d7ee-8059-11e5-9834-502690aa641f ro rootflags=subvol=root rootflags=degraded > and apparently the 2nd rootflags= is simply ignored. My tests shows that first "rootflags" is ignored, and the second one matters: root@pegaz# cat /boot/grub/grub.cfg | egrep subvol | head -n1 linux /pegaz/boot/vmlinuz-4.19.0-14-amd64 root=UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 ro rootflags=subvol=pegaz rootflags=space_cache=v2 quiet This one is iginored: rootflags=subvol=pegaz and this one takes effect: rootflags=space_cache=v2 so default subvolume is mounted instead of "pegaz" subvolume. This is severe and can change how system boots. My workaround is to put whole rootflags in /etc/default/grub: root@pegaz:~# egrep rootflags= /etc/default/grub GRUB_CMDLINE_LINUX="rootflags=clear_cache,space_cache=v2,subvol=pegaz" root@pegaz:~# egrep rootflags= /boot/grub/grub.cfg | head -n1 linux /pegaz/boot/vmlinuz-4.19.0-14-amd64 root=UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 ro rootflags=subvol=pegaz rootflags=clear_cache,space_cache=v2,subvol=pegaz quiet This is ignored: rootflags=subvol=pegaz and this takes effect: rootflags=clear_cache,space_cache=v2,subvol=pegaz
Bug#985895: ITP: bamclipper -- Remove gene-specific primer sequences from SAM/BAM alignments
Package: wnpp Severity: wishlist Subject: ITP: bamclipper -- Remove gene-specific primer sequences from SAM/BAM alignments Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: bamclipper Version : 1.0.0 Upstream Author : Chun Hang Au * URL : https://github.com/tommyau/bamclipper * License : MIT Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : Remove gene-specific primer sequences from SAM/BAM alignments Remove gene-specific primer sequences from SAM/BAM alignments of PCR amplicons by soft-clipping. . bamclipper.sh soft-clips gene-specific primers from BAM alignment file based on genomic coordinates of primer pairs in BEDPE format. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/bamclipper
Bug#985853: debian-installer: Whitespace before a commented line in preseed file causes line to be parsed
On Thu, Mar 25, 2021 at 09:45:17AM +1030, Andrew McDonnell wrote: > Package: debian-installer > Version: 20190702+deb10u8 > Severity: important > Tags: d-i > > In a preseed file I accidentally had a space before a comment character, which > caused my preseed to fail in unexpected ways. I could not find anythying that > stood out in the documentation (e.g. > https://www.debian.org/releases/buster/amd64/apbs04.en.html or > https://www.debian.org/releases/stable/amd64/apbs03.en.html) stating that this > would occur. > > The specific example in my case looked like this: > > #_preseed_V1 > d-i debian-installer/locale string en_AU > d-i keyboard-configuration/xkb-keymap select us > d-i keymap select us > ... etc ... > # Example of fetching a script to run > #d-i preseed/run string http://10.1.2.3/my-script.sh > > > My install was hanging and when I entered a console and looked in the syslog, > it was attempting to access that script for which the IP address does not > exist > on my network. I finally started to understand the problem when I did this, > the > latter finally triggered a parse error in the installer console: > > #d-iWHATpreseed/run string http://10.1.2.3/my-script.sh > > > #d-iWHATpreseed/runISstringHAPPENINGhttp://10.1.2.3/my-script.sh > > at this point I saw the white space, removed it and the problem went away. > > (I am also unsure whether "d-iWHAT" is also a bug or just some default > applying > if the item owner is not found) > > So I guess that either > - whitespace is disallowed before a comment character and this should be added > to https://www.debian.org/releases/stable/amd64/apbs03.en.html - it mentioned > whitespace between fields but not at the start of a line > - this is a bug Well none of the examples ever have spaces before # for comments. The documentation page you linked to doesn't even mention comments at all. I would agree that perhaps it should. I have certainly encountered file types before where comments had to have # at the start of the line. -- Len Sorensen
Bug#985894: qemu-system-x86: Unable to use http/https based drives
Package: qemu-system-x86 Version: 1:5.2+dfsg-3~bpo10+1 Severity: normal Dear Maintainer, According to the man page for qemu (qemu-system-x86_64) it should be possible to use a URL to point to a read only ISO image, with an example given to boot from a remote Fedora 20 live ISO image. eg qemu-system-x86_64 --drive media=cdrom,file=http://,readonly Any attempt to do this with the qemu binaries distributed in Debian gives the error: Unknown driver 'http' or Unknown driver 'https' I suspect this may be because the Debian binaries are compiled without the --enable-curl flag, as I'm not seeing libcurl4 in the list of dependencies. Is this deliberate? Thanks, Rob Leadbeater -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-system-x86 depends on: ii ipxe-qemu 1.0.0+git-20190125.36a4c85-1 ii libaio1 0.3.112-3 ii libasound21.1.8-1 ii libbrlapi0.6 5.6-10+deb10u1 ii libc6 2.28-10 ii libcacard01:2.6.1-1 ii libcapstone4 4.0.2-3~bpo10+1 ii libepoxy0 1.5.3-0.1 ii libfdt1 1.6.0-1~bpo10+1 ii libgbm1 18.3.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgnutls30 3.6.7-4+deb10u6 ii libibverbs1 22.1-1 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii libncursesw6 6.1+20181013-2+deb10u2 ii libnettle63.4.1-1 ii libnuma1 2.0.12-1 ii libpixman-1-0 0.36.0-1 ii libpmem1 1.9.2-1~bpo10+1 ii libpng16-16 1.6.36-6 ii librdmacm122.1-1 ii libsasl2-22.1.27+dfsg-1+deb10u1 ii libseccomp2 2.3.3-4 ii libslirp0 4.3.1-1~bpo10+1 ii libspice-server1 0.14.0-1.3+deb10u1 ii libtinfo6 6.1+20181013-2+deb10u2 ii libudev1 241-7~deb10u6 ii liburing1 0.7-3~bpo10+1 ii libusb-1.0-0 2:1.0.22-2 ii libusbredirparser10.8.0-1 ii libvdeplug2 2.3.2+r586-2.2 ii libvirglrenderer0 0.7.0-2 ii libxendevicemodel14.11.4+57-g41a822c392-2 ii libxenevtchn1 4.11.4+57-g41a822c392-2 ii libxenforeignmemory1 4.11.4+57-g41a822c392-2 ii libxengnttab1 4.11.4+57-g41a822c392-2 ii libxenmisc4.114.11.4+57-g41a822c392-2 ii libxenstore3.04.11.4+57-g41a822c392-2 ii libxentoolcore1 4.11.4+57-g41a822c392-2 ii qemu-system-common1:5.2+dfsg-3~bpo10+1 ii qemu-system-data 1:5.2+dfsg-3~bpo10+1 ii seabios 1.12.0-1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages qemu-system-x86 recommends: ii ovmf 2020.11-2 ii qemu-system-gui 1:5.2+dfsg-3~bpo10+1 ii qemu-utils 1:5.2+dfsg-3~bpo10+1 Versions of packages qemu-system-x86 suggests: pn qemu-block-extra ii qemu-system-data [sgabios] 1:5.2+dfsg-3~bpo10+1 pn samba pn vde2 -- no debconf information
Bug#985893: RFS: mmsd/0.1-2.2 [ITP] -- transmit and receive MMSes
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "mmsd": * Package name : mmsd Version : 0.1-1 (Upstream), 0.1-2.2 (my fork of it) Upstream Author : ch...@talbothome.com * URL : https://git.kernel.org/pub/scm/network/ofono/mmsd.git * License : GPL-2.0 * Vcs : https://salsa.debian.org/kop316/mmsd/-/tree/debian/latest Section : mmsd is a lower level daemon that transmits and recieves Multimedia Service Messages. The upstream package works with both the ofono stack only. I have been working to upstream multiple patches that fix various bugs in the core of mmsd, and adds a plugin to have mmsd work with the Modem Manager stack. I have been working to upstream my patches, but I have yet to recieve any responses to my patches from the Ofono Maintainers, and I suspect the upstream project is abandoned. See the following link for background on my upstream efforts: https://marc.info/?l=linux-netdev&m=161668167401221&w=2 I have packaging that works for the original upstream mmsd, and packaging that has all of my patches to make my fork of mmsd. It builds those binary packages: mmsd To access further information about this package, please visit the following URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982250 This is the ITP bug for mmsd I submitted. https://source.puri.sm/kop316/mmsd/ This is where the code for my fork lives. The "Master" branch does not include debian packaging. https://salsa.debian.org/kop316/mmsd/-/tree/debian/latest This contains the packaging for upstream mmsd. https://salsa.debian.org/kop316/mmsd/-/tree/debian/modemmanager/latest This contains the packaging for my fork of mmsd. Changes since the last upload: mmsd (0.1-2.2) UNRELEASED; urgency=medium [ Chris T ] * Initial release. [ Chris T ] * Add attachment limit size [ Chris T ] * Cleans up the commits of mmsd * Sync with commit 49603c396321074edad609fb96c209e76ec63285 in branch master * Modem Manager: Enable autoprocessing of unsent/unrecieved messages when the modem is connected Respectfully, Chris Talbot
Bug#985440: pinball-dev: depends on virtual libstdc++-dev with multiple providers
unblock asked: https://bugs.debian.org/985488
Bug#985488: New debdiff for pinball 0.3.20201218-3
Control: reopen -1
Control: tags -1 - moreinfo
Control: retitle -1 unblock: pinball/0.3.20201218-3
Hi,
Philippe added an autopkgtest to pinball. Since this game has no reverse
dependencies (except its pinball tables [2]), I think it is not risky to
unblock it.
Debian Package Tracker[1] mentions a manual block by release team,
that's why I'm reopening this issue.
Cheers,
Xavier
[1]: tracker: https://tracker.debian.org/pkg/pinball
[2]: rdeps: pinball-table-gnu, pinball-table-hurd
recommended rdeps: games-arcade, games-finest, games-simulation
unblock pinball/0.3.20201218-3
diff -Nru pinball-0.3.20201218/debian/changelog
pinball-0.3.20201218/debian/changelog
--- pinball-0.3.20201218/debian/changelog 2020-12-18 22:43:37.0
+0100
+++ pinball-0.3.20201218/debian/changelog 2021-03-20 22:33:28.0
+0100
@@ -1,3 +1,19 @@
+pinball (0.3.20201218-3) unstable; urgency=medium
+
+ * Pick 0.3.20201218-2 changes on 0.3.20201218-1 base
+ * d/control: Drop C++ dep
+ * d/control: Set team maintenance
+ * d/tests: Add help test (Closes: #985488)
+
+ -- Philippe Coval Sat, 20 Mar 2021 22:33:28 +0100
+
+pinball (0.3.20201218-2) unstable; urgency=medium
+
+ * d/control: Update preferred libstdc++ version (Closes: #985440)
+ * d/control: Update standards to latest
+
+ -- Philippe Coval Thu, 18 Mar 2021 12:06:12 +0100
+
pinball (0.3.20201218-1) unstable; urgency=medium
* New upstream release
diff -Nru pinball-0.3.20201218/debian/control
pinball-0.3.20201218/debian/control
--- pinball-0.3.20201218/debian/control 2020-12-18 22:43:37.0 +0100
+++ pinball-0.3.20201218/debian/control 2021-03-20 22:33:28.0 +0100
@@ -1,5 +1,7 @@
Source: pinball
-Maintainer: Philippe Coval
+Maintainer: Debian Games Team
+Uploaders:
+ Philippe Coval
Section: games
Priority: optional
Build-Depends: debhelper-compat (= 13),
@@ -23,8 +25,8 @@
libltdl-dev,
pkg-config
Standards-Version: 4.5.0
-Vcs-Browser: https://sourceforge.net/p/pinball/code/ci/debian/master/tree/
-Vcs-Git: https://git.code.sf.net/p/pinball/code.git
+Vcs-Browser: https://salsa.debian.org/games-team/pinball/-/tree/debian/master
+Vcs-Git: https://salsa.debian.org/games-team/pinball.git
Homepage: https://sourceforge.net/projects/pinball/
Rules-Requires-Root: binary-targets
@@ -50,8 +52,7 @@
Architecture: any
Depends: ${misc:Depends},
libc6-dev,
- pinball (= ${binary:Version}),
- libstdc++6-4.4-dev | libstdc++-dev
+ pinball (= ${binary:Version})
Description: Development files for the Emilia Pinball Emulator
The Emilia Pinball Project is a pinball simulator for Linux and other Unix
systems. There are only two levels to play with, but they are very addictive.
diff -Nru pinball-0.3.20201218/debian/tests/control
pinball-0.3.20201218/debian/tests/control
--- pinball-0.3.20201218/debian/tests/control 1970-01-01 01:00:00.0
+0100
+++ pinball-0.3.20201218/debian/tests/control 2021-03-20 22:33:28.0
+0100
@@ -0,0 +1,3 @@
+Tests: smoke
+Depends: @
+Restrictions: allow-stderr
diff -Nru pinball-0.3.20201218/debian/tests/smoke
pinball-0.3.20201218/debian/tests/smoke
--- pinball-0.3.20201218/debian/tests/smoke 1970-01-01 01:00:00.0
+0100
+++ pinball-0.3.20201218/debian/tests/smoke 2021-03-20 22:33:28.0
+0100
@@ -0,0 +1,4 @@
+#!/bin/sh -e
+
+export HOME=${AUTOPKGTEST_TMP:-${TMPDIR:-/tmp}}
+pinball -dir | grep '/usr/share/games/pinball'
Bug#985892: librime-data-emoji: Contains duplicated copy of opencc data
Package: librime-data-emoji Version: 0.38.20190120-1 Severity: normal Package librime-data-emoji has embedded opencc emoji data under /usr/share/rime-data/opencc/ . We should investigate and avoid duplication. Thanks, Boyuan yang signature.asc Description: This is a digitally signed message part
Bug#984844: 984844 was fixed by upgrading firmware-brcm80211
Control: reassign -1 firmware-brcm80211 20201218-3 Control: close -1 20210315-1 The symptom #984844 disappeared by upgrading firmware-brcm80211 from 20201218-3 to 20210315-1. Ryutaroh
Bug#982055: dia -- Diagram editor
@Philippe, Could not be more happy than hearing someone is picking up this package for maintenance. I am using the package for over 15 years, but some limitations become awkard. Upstream the source package can be downloaded in an Ubuntu VM including the complete build environment. But even in this fully configured build environment it does not build. So to see latest modifications were made in 2012. So, do know that there are some very enthousiastic and dedicated users for Dia out here! Kind regards Johannes LINKELS -- Linxtech Logo
Bug#985891: dicompyler doesn't start
Package: dicompyler
Version: 0.4.2.0+git20200106.2643e0e-1
Severity: important
X-Debbugs-Cc: desmont...@netcourrier.com
Dear Maintainer,
The dicompyler installation ends successfully but the application does not
start. It seems that matplotlib dependency is not satisfied.
In a terminal:
desmonts@debian:~$ dicompyler
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 568, in
_build_master
ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 886, in
require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 777, in
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (matplotlib 3.3.4
(/usr/lib/python3/dist-packages), Requirement.parse('matplotlib<2.2,>=1.3.0'),
{'dicompyler'})
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/dicompyler", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3243,
in
def _initialize_master_working_set():
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3226,
in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3255,
in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 570, in
_build_master
return cls._build_from_requirements(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 772, in
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'matplotlib<2.2,>=1.3.0' distribution
was not found and is required by dicompyler
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
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 dicompyler depends on:
ii python3 3.9.2-2
ii python3-dicompylercore 0.5.5-2
ii python3-matplotlib 3.3.4-1
ii python3-numpy 1:1.19.5-1
ii python3-pil 8.1.2-1
ii python3-pydicom 2.0.0-1
ii python3-tornado 6.1.0-1+b1
ii python3-wxgtk4.04.0.7+dfsg-10
dicompyler recommends no packages.
dicompyler suggests no packages.
Bug#985890: libglib2.0-0: usage of glib_check_version() should generate tight package dependencies
Package: libglib2.0-0 Version: 2.66.7-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: block 985453 with -1 Hi, during buster -> bullseye upgrade tests with piuparts I observed some failures related to glib dependencies: Setting up libclutter-imcontext-0.1-bin (0.1.4-3.1) ... Cannot load module /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so: GModule (/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so) initialization check failed: GLib version too old (micro mismatch) /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so does not export Clutter IM module API: GModule (/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so) initialization check failed: GLib version too old (micro mismatch) dpkg: error processing package libclutter-imcontext-0.1-bin (--configure): installed libclutter-imcontext-0.1-bin package post-installation script subprocess returned error exit status 1 Using the glib_check_version() symbol should generate package dependencies that ensure the version check passes. Andreas
Bug#977327: Your mail
Hi Ludovic, this seems like a problem unrelated to this bug report. the controller and the target node will by default use different python versions, unless you configure it explicitely. See #961119 for details. Regards, Lee On Fri, 19 Feb 2021 20:52:39 +0100 Ludovic Pouzenc wrote: > Hi, > > It seems that ansible 2.9 currently in testing still try to use python > 2.7. Using ansible-pull with a playbook using a ansible.builtin.apt task > that juste ask for "apt update" just break as it tries to install > "python-apt" first and this is not currently available in testing > (python3-apt is available). > > It seems important to me as bulleye soft freeze is started. > > If I can help in any way, say me. I'm a sysadmin that had occasionally > created some local packages, but I'm clearly not a dd. > > Regards, > > -- > Ludovic Pouzenc > www.pouzenc.fr > > >
Bug#985889: qemu-user-static: make binfmt setup configurable
Package: qemu-user-static Version: 1:5.2+dfsg-9 Severity: wishlist X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com Current packaging of qemu-user-static is providing two different things at once and without any declared configuration possibility (no .conffiles): * QEMU-User statically linked binaries. * binfmt_misc configuration >From release "buster" upwards the binfmt_misc configuration being provided by this package is registering the qemu-user-static binaries with the flag "fix_binary". This configuration might be convenient in most cases (suppose that's was it's so now), but is a problem in some others. Not being able to configure binfmt_misc is a blocker for this package in the scenarios where that default configuration doesn't fit. The configuration can be changed providing different update-binfmts templates than those provided by this package and running update-binfmts. But qemu-user-static upgrades overwrite the changes. I don't know which is the best solution, but one possible is putting the update-binfmts templates now available in /usr/share/binfmts under /etc and making them configuration files (adding a .conffiles). Just for those curious when this might be an issue. Containers trying to use new syscalls not provided by the QEMU-User binaries provided by the host require newer QEMU-User binaries. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-security'), (50, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.1-1 Versions of packages qemu-user-static suggests: ii sudo 1.9.5p2-3 -- no debconf information
Bug#357769: please close #357769 is ancient and is not makes sense now
fam is removed from so please mark as solvet in lasted release! Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#985888: dpkg: Add new option to skip all sync / fsync calls (Emulate libeatmydata)
Source: dpkg Severity: wishlist Tags: d-i Justification: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, Please provide a new option in dpkg 1.21.x that allows disabling all sync / fsync calls similar to how currently done by libeatmydata. There are more and more use cases that benefit from a faster dpkg but don't need any protection against sudden shutdowns or terminations of dpkg, some examples include the debian installer, building containers, temporary chroots (sbuild), temporary VMs. Currently eatmydata can be used to achive this and it has the benefit of also disabling all sync / fsync calls in maintainer scripts, triggers, ... But eatmydata uses LD_PRELOAD, which in my opinion is a hack and won't work on some hardened systems, it also adds a lot of complexity and extra steps in many different places. A new option --force-dangerous-io would allow tools to easily capture most of the performance benefits where appropiate. Of course add some big and scary warnings in the manual about how this should never be used on a system you care about. (Also discussed with guillem on irc #debian-dpkg oftc 2021-03-25)
Bug#985887: gscan2pdf: saves b&w scanned pages in inverted mode
Package: gscan2pdf Version: 2.11.0-1 Severity: normal X-Debbugs-Cc: none, Francesco Potortì This looks exactly like a bug that was fixed back in 2016: https://bugzilla.redhat.com/show_bug.cgi?id=1369984 In short, the problem occurs only with pages scanned in Grey mode. When the document is saved, the pdf document that is created has those pages in inverted mode, that is black is exchanged with white. -- Francesco Potortì (ricercatore)Voice: +39.050.621.3058 ISTI - Area della ricerca CNR Mobile: +39.348.8283.107 via G. Moruzzi 1, I-56124 Pisa Skype: wnlabisti (gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (101, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gscan2pdf depends on: ii imagemagick8:6.9.11.60+dfsg-1 ii imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1 ii libconfig-general-perl 2.63-1 ii libdate-calc-perl 6.4-1.1 ii libfilesys-df-perl 0.92-6+b6 ii libgoocanvas2-perl 0.06-2 ii libgtk3-imageview-perl 6-1 ii libgtk3-perl 0.038-1 ii libgtk3-simplelist-perl0.21-1 ii libhtml-parser-perl3.75-1+b1 ii libimage-magick-perl 8:6.9.11.60+dfsg-1 ii libimage-sane-perl 5-1+b1 ii liblist-moreutils-perl 0.430-2 ii liblocale-codes-perl 3.66-1 ii liblocale-gettext-perl 1.07-4+b1 ii liblog-log4perl-perl 1.54-1 ii libossp-uuid-perl [libdata-uuid-perl] 1.6.2-1.5+b9 ii libpdf-builder-perl3.021-1 ii libproc-processtable-perl 0.59-2+b1 ii libreadonly-perl 2.050-3 ii librsvg2-common2.50.3+dfsg-1 ii libset-intspan-perl1.19-1.1 ii libtiff-tools 4.2.0-1 ii libtry-tiny-perl 0.30-1 ii sane-utils 1.0.31-4 Versions of packages gscan2pdf recommends: ii djvulibre-bin 3.5.28-1 ii gocr0.52-3 ii pdftk 2.02-5+b1 ii pdftk-java [pdftk] 3.2.2-1 ii tesseract-ocr 4.1.1-2.1 ii unpaper 6.1-2+b2 ii xdg-utils 1.1.3-4 gscan2pdf suggests no packages. -- no debconf information
Bug#985885: unblock: ceph/14.2.18-1 (CVE-2020-27839)
Control: tags -1 moreinfo On 2021-03-25 12:12:51 +0100, Thomas Goirand wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package ceph > > This is the point release of the 14.2.x series from upstream, which includes a > fix for CVE-2020-27839 (XSS in the dashboard). I didn't even atempted to build > a debdiff, considering the size of the orig.tar.gz (ie: 124 MB), so I'm not > attaching it, though as it's still the stable branch, it contains only > bugfixes. 526 files changed, 8568 insertions(+), 2246 deletions(-) I understand that it's important to get that CVE fixed in bullseye, but that's simply to much to blindly accept. Please provide a filtered debdiff with an explanation on the other changes that are also included in this release. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#985886: klick crashes after approx. 8 klicks
Package: klick Version: 0.12.2-4.1 Severity: important X-Debbugs-Cc: rosea.grammost...@gmail.com Dear Maintainer, Start qjackctl/jackd klick -P 4 60 Jack: JackClient::SetupDriverSync driver sem in flush mode Jack: JackLinuxFutex::Connect name = jack_sem.1000_default_klick Jack: Clock source : system clock via clock_gettime Jack: JackLibClient::Open name = klick refnum = 4 Jack: JackClient::PortRegister ref = 4 name = klick:out type = 32 bit float mono audio port_index = 7 Jack: JackClient::Activate Jack: JackPosixThread::StartImp : create non RT thread Jack: JackPosixThread::ThreadHandler : start Jack: JackClient::kBufferSizeCallback buffer_size = 128 Jack: JackClient::ClientNotify ref = 4 name = klick notify = 2 Jack: JackClient::kActivateClient name = klick ref = 4 Jack: JackClient::Connect src = klick:out dst = system:playback_1 Jack: JackClient::ClientNotify ref = 4 name = klick notify = 18 Jack: JackClient::ClientNotify ref = 4 name = klick notify = 18 Jack: JackClient::Connect src = klick:out dst = system:playback_2 Jack: JackClient::ClientNotify ref = 4 name = klick notify = 18 Jack: JackClient::ClientNotify ref = 4 name = klick notify = 18 Jack: JackClient::Deactivate Jack: JackClient::Deactivate res = 0 Jack: JackPosixThread::Kill Jack: jack_client_close Jack: JackClient::Close ref = 4 Jack: JackClient::Deactivate Jack: JackSocketClientChannel::Stop Jack: JackPosixThread::Kill Jack: JackClientSocket::Close Jack: JackClientSocket::Close Jack: JackLibClient::~JackLibClient Jack: JackShmReadWritePtr1::~JackShmReadWritePtr1 4 Jack: Succeeded in unlocking 426 byte memory area Jack: JackLibGlobals Destroy ed308700 Jack: ~JackLibGlobals Jack: no message buffer overruns Jack: JackPosixThread::Stop Jack: JackPosixThread::ThreadHandler : exit Jack: JackShmReadWritePtr::~JackShmReadWritePtr 1 Jack: Succeeded in unlocking 1187 byte memory area Jack: JackShmReadWritePtr::~JackShmReadWritePtr 0 Jack: Succeeded in unlocking 107341338 byte memory area Jack: jack_client_close res = 0 -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-2-rt-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages klick depends on: ii libc6 2.31-9 ii libgcc-s1 10.2.1-6 ii libjack-jackd2-0 [libjack-0.125] 1.9.17~dfsg-1 ii liblo70.31-1 ii librubberband21.9.0-1 ii libsamplerate00.2.1+ds0-1 ii libsndfile1 1.0.31-1 ii libstdc++610.2.1-6 klick recommends no packages. Versions of packages klick suggests: pn gtklick -- no debconf information
Bug#985060: openjdk-11-jre-headless: leaves alternatives after purge: /usr/bin/jfr -> /etc/alternatives/jfr
Control: tags -1 + pending On 3/25/21 11:59 AM, Andreas Beckmann wrote: > Followup-For: Bug #985060 > Control: tag -1 patch > > Please see the attached patches for cleaning up the dangling > alternative and tempfile usage. > I've tested these in my piuparts instance on buster->bullseye > upgrades. thanks!
Bug#985885: unblock: ceph/14.2.18-1 (CVE-2020-27839)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package ceph This is the point release of the 14.2.x series from upstream, which includes a fix for CVE-2020-27839 (XSS in the dashboard). I didn't even atempted to build a debdiff, considering the size of the orig.tar.gz (ie: 124 MB), so I'm not attaching it, though as it's still the stable branch, it contains only bugfixes. Please unblock ceph/14.2.18-1
Bug#985884: porting/libperl.t tests fail when building with lto
Package: src:perl Version: 5.32.1-3 porting/libperl.t tests fail when building with lto. see https://wiki.debian.org/ToolChain/LTO I just disabled the test in Ubuntu, http://launchpadlibrarian.net/529417162/perl_5.32.1-3ubuntu1_5.32.1-3ubuntu2.diff.gz it's not run on other architectures, and it's only testing the (almost unused) static library, afaics. I didn't look into "fixing" the test. Test results for autopkg tests triggered by perl look good so far.
Bug#985060: openjdk-11-jre-headless: leaves alternatives after purge: /usr/bin/jfr -> /etc/alternatives/jfr
Followup-For: Bug #985060 Control: tag -1 patch Please see the attached patches for cleaning up the dangling alternative and tempfile usage. I've tested these in my piuparts instance on buster->bullseye upgrades. Andreas >From 061f326aa6a11f9bd15f6b98095546626a2ffc35 Mon Sep 17 00:00:00 2001 From: Andreas Beckmann Date: Tue, 23 Mar 2021 10:10:40 +0100 Subject: [PATCH 1/2] remove dangling jfr alternative on upgrades if no jdk is installed --- debian/JB-jre-headless.postinst.in | 5 + debian/changelog | 7 +++ 2 files changed, 12 insertions(+) diff --git a/debian/JB-jre-headless.postinst.in b/debian/JB-jre-headless.postinst.in index 4af7413..6849034 100644 --- a/debian/JB-jre-headless.postinst.in +++ b/debian/JB-jre-headless.postinst.in @@ -52,6 +52,11 @@ configure) done fi +if dpkg --compare-versions "$2" lt-nl "11.0.11+7-2~" ; then +# jfr moved from jre to jdk, remove dangling alternative on upgrades + test -x $basedir/bin/jfr || update-alternatives --remove jfr $basedir/bin/jfr +fi + if [ "$update_alternatives" = y ]; then if [ -n "$multiarch" ] && [ "$DPKG_MAINTSCRIPT_ARCH" != $(dpkg --print-architecture) ]; then priority=$(expr $priority - 1) diff --git a/debian/changelog b/debian/changelog index 090f8e9..c5bbc38 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +openjdk-11 (11.0.11+7-2) UNRELEASED; urgency=medium + + * Remove dangling jfr alternative on upgrades if no jdk is installed. +(Closes: #985060) + + -- Andreas Beckmann Tue, 23 Mar 2021 10:07:52 +0100 + openjdk-11 (11.0.11+7-1) unstable; urgency=medium * OpenJDK 11.0.11+7 build (early access). -- 2.20.1 >From 76157ae455d9402aad4cce3aed24423371281192 Mon Sep 17 00:00:00 2001 From: Andreas Beckmann Date: Wed, 24 Mar 2021 12:48:46 +0100 Subject: [PATCH 2/2] use mktemp instead of tempfile in maintainer scripts --- debian/JB-jre-headless.postinst.in | 4 ++-- debian/changelog | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/debian/JB-jre-headless.postinst.in b/debian/JB-jre-headless.postinst.in index 6849034..8410cad 100644 --- a/debian/JB-jre-headless.postinst.in +++ b/debian/JB-jre-headless.postinst.in @@ -101,7 +101,7 @@ configure) # activate class data sharing case @jvmarch@ in i386|i586|sparc) rm -f $basedir/lib/client/classes.jsa - log=$(tempfile) + log=$(mktemp) if ! $basedir/bin/java -client -Xshare:dump -XX:PermSize=128m > $log; then cat >&2 $log rm -f $log @@ -113,7 +113,7 @@ configure) esac case @jvmarch@ in amd64|i386|i586|sparc) rm -f $basedir/lib/server/classes.jsa - log=$(tempfile) + log=$(mktemp) if ! $basedir/bin/java -server -Xshare:dump > $log; then cat >&2 $log rm -f $log diff --git a/debian/changelog b/debian/changelog index c5bbc38..22f9f1c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,7 @@ openjdk-11 (11.0.11+7-2) UNRELEASED; urgency=medium * Remove dangling jfr alternative on upgrades if no jdk is installed. (Closes: #985060) + * Use mktemp instead of tempfile in maintainer scripts. -- Andreas Beckmann Tue, 23 Mar 2021 10:07:52 +0100 -- 2.20.1
Bug#982996: buster-pu: package awstats/7.6+dfsg-2
Hi Salvatore, On Tue, 23 Mar 2021 13:35:48 +0100 Salvatore Bonaccorso wrote: > > On Sat, Mar 13, 2021 at 05:16:24PM +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Wed, 2021-02-17 at 23:33 +0100, Håvard Flaget Aasen wrote: > > > These are the same changes which was implemented in stretch, two > > > upstream patches. Both of these patches resolves a path traversal > > > flaw, which was first discovered with CVE-2017-1000501. > > > > > > > Please go ahead. > > Was this uploaded? Can you still do it, but will be late for 10.9 now. > Since I'm not a DD, I uploaded it to the mentors site. I haven't found any sponsor yet.. Regards, Håvard
Bug#985862: linux: Please enable support for NXP/Freescale iMX8
Control: tag -1 + pending Hello Wookey, On Thu, Mar 25, 2021 at 05:13:02AM +, Wookey wrote: > Source: linux > Severity: normal > > The iMX8 SoC is used on various boards, widely available to debian > users and well supported by free software, but the platform is not > enabled in debian kernels, which is a rather major omission. I don't > know why not (I guess no-one filed this bug?). > > These are all avilable today and should at least mostly work with > mainline: > Nitrogen 8M > https://boundarydevices.com/product/nitrogen8m/ > Solidrun > Cubox M https://shop.solid-run.com/product/SRMP8QDWB1D04GE008X00CE/ > Hummingboard Pulse > https://shop.solid-run.com/product-category/embedded-computers/nxp-family/hummingboard-m/ > Purism > Librem 5 Phone https://en.wikipedia.org/wiki/Librem_5 > Compulab > SBC-iMX8X > https://www.compulab.com/products/sbcs/sbc-imx8x-nxp-i-mx-8x-single-board-computer/ > (supported since 5.4.24) > Toradex > Apalis iMX8 CoM > https://www.toradex.com/computer-on-modules/apalis-arm-family/nxp-imx-8 > > I believe that all that is needed is adding > CONFIG_ARCH_MXC=y in debian/config/arm64/config > Which is set by default upstream. I enabled a few more settings in our sid branch. See https://deb.li/3fUTV . > (There may be other drivers that should enabled too for some of these > platforms?) > > I just built the kernel with the above config change and it builds > fine on arm64, and installs and boots on softiron. I don't have an > iMX8 here to test on, but we can find some, I'm sure. I have an i.MX8 here, but didn't do any tests (yet). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#772917: iwlwifi: iwl4965 crashes when network usage is intense
Le 25/03/2021 à 10:29, maximilian attems a écrit : tags 772917 moreinfo stop [584941.834142] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24 Can you reproduce this with an up to date debian testing? thank you. I tried to download a debian iso file for test and didn't see any disconnection.
Bug#985868: shotcut-data: broken symlinks: /usr/share/shotcut/qml/filters/webvfx_threejs_text/three.min.js -> ../../../../javascript/three/three.min.js
Hi Andreas, Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. From the attached log (scroll to the bottom...): 0m24.0s ERROR: FAIL: Broken symlinks: /usr/share/shotcut/qml/filters/webvfx_threejs_text/three.min.js -> ../../../../javascript/three/three.min.js (shotcut-data) /usr/share/shotcut/qml/filters/webvfx_ruttetraizer/three.js -> ../../../../javascript/three/three.js (shotcut-data) Is shotcut-data missing a Depends/Recommends/Suggests: libjs-three ? Good catch, yes obviously, will fix asap. cheers, Andreas cheers,
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hello, On Wed, Mar 24, 2021 at 09:59:59AM +0100, Christoph Biedl wrote: > Felix Lechner wrote... > > > By the way, the suggestion behind this bug may not be implemented > > anytime soon. It would cause Lintian's output to change over time > > (same Lintian version on same package). Such tags are hard to test in > > Lintian's test suite. > > That argument seems fairly weird to me: Abandon or deny features because > they are difficult to test. By the way, to test behaviour over time, > faketime(1) serves me good enough. But that's your design decision. Just to make this suggestion more obvious as I got (and needed) this hint: A sensible date to fake (or compare to) would probably be the changelog date. Then the output doesn't vary over time and we also don't get bad positives for old packages. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#985883: python3-pep8: Does not install /usr/bin/pep8
Package: python3-pep8 Version: 1.7.1-9 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 python3-pep8 does not install the pep8 executable under /bin or /usr/bin. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAmBcWCIACgkQrNSfiF5U Um7nRRAAmfryaKXqyaymeC1BxEBJy3MD++Oes1JkAQ/UEhaZmzX3Pguhl4mwNnba brOQ+ShKM1BNppnQZvvEu3cdFcHm5fmIlDe6zWCxA8k56P5UZmTMFHLQ2zsRdvuW 6+BRJ5hw/YpRq93h0iJGQ72AZGnO+4dorWq1okPxQbhh8SbVqCdejUQEH15YeLPZ SHKNCD5qzAXR6oz1SE3Q3BFKVgUgC/qkfTdQFwdxS161cUu1qIRB2q/7auYabN74 1xkarDJIwdJUd5HhuZw8khfxHTL0ce2/dP31fH6ehplMtAPw+XiyKj6MOmw8nqNb fT4TV04tXZFx+kjWuKFEYvXk4qFMXI//sqCAS3MbDrHQUWI0hE26GL9wyjO2Sz6x ZT+9b2v3zwsaYWIGuuRTbcpgrde9R4syNJdo8lFJrveujFtuwovg92uD80E6LMBx OeLCyG2gLVa5rWhiPDK6IL6RMD3a340CCSph1z1ksjTSnjgDr6o9a6YffWNCjthy fkWbYmOdBYqNIOXdiS6AxNwf9kPolo5RSoLYThEFZ45sxG0jyW84LxRQV3VnpZcJ BaijLAw6CtQZ2sKnIAAYpa1r6E+7AMT9bryVGL1M9eOAkLiI6GiH0JZ2msTGUfhp eYTVynGXr4/ZRchzdQ9eXIgpAR5BfIW9JtMQqAZBNEGcNQzJ4Eo= =Ljmp -END PGP SIGNATURE-
Bug#985882: wminput: broken symlink: /usr/share/wminput/plugins -> ../../lib/wminput/plugins
Package: wminput Version: 0.6.91-2 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 0m25.6s ERROR: FAIL: Broken symlinks: /usr/share/wminput/plugins -> ../../lib/wminput/plugins (wminput) There is no /usr/lib/wminput/plugins in any package. cheers, Andreas wminput_0.6.91-2+b1.log.gz Description: application/gzip
Bug#985881: libvtk6-qt-dev: broken symlinks: /usr/lib/x86_64-linux-gnu/libvtk*-6.3.so -> libvtk*-6.3.so.6.3
Package: libvtk6-qt-dev Version: 6.3.0+dfsg2-8 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 2m2.8s ERROR: FAIL: Broken symlinks: /usr/lib/x86_64-linux-gnu/libvtkViewsQt-6.3.so -> libvtkViewsQt-6.3.so.6.3 (libvtk6-qt-dev) /usr/lib/x86_64-linux-gnu/libvtkRenderingQt-6.3.so -> libvtkRenderingQt-6.3.so.6.3 (libvtk6-qt-dev) /usr/lib/x86_64-linux-gnu/libvtkGUISupportQtWebkit-6.3.so -> libvtkGUISupportQtWebkit-6.3.so.6.3 (libvtk6-qt-dev) /usr/lib/x86_64-linux-gnu/libvtkGUISupportQtSQL-6.3.so -> libvtkGUISupportQtSQL-6.3.so.6.3 (libvtk6-qt-dev) /usr/lib/x86_64-linux-gnu/libvtkGUISupportQtOpenGL-6.3.so -> libvtkGUISupportQtOpenGL-6.3.so.6.3 (libvtk6-qt-dev) /usr/lib/x86_64-linux-gnu/libvtkGUISupportQt-6.3.so -> libvtkGUISupportQt-6.3.so.6.3 (libvtk6-qt-dev) cheers, Andreas libvtk6-qt-dev_6.3.0+dfsg2-8.log.gz Description: application/gzip
Bug#985880: ruby-flot-rails: broken symlinks: /usr/share/ruby-flot-rails/vendor/assets/javascripts/jquery.flot.canvas.* -> ../../../../javascript/jquery-flot/jquery.flot.canvas.*
Package: ruby-flot-rails Version: 0.0.7-1.1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 0m30.1s ERROR: FAIL: Broken symlinks: /usr/share/ruby-flot-rails/vendor/assets/javascripts/jquery.flot.canvas.min.js -> ../../../../javascript/jquery-flot/jquery.flot.canvas.min.js (ruby-flot-rails) /usr/share/ruby-flot-rails/vendor/assets/javascripts/jquery.flot.canvas.js -> ../../../../javascript/jquery-flot/jquery.flot.canvas.js (ruby-flot-rails) jquery.flot.canvas.* is no longer part of libjs-jquery-flot cheers, Andreas ruby-flot-rails_0.0.7-1.1.log.gz Description: application/gzip
Bug#772917: iwlwifi: iwl4965 crashes when network usage is intense
tags 772917 moreinfo stop > [584941.834142] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24 Can you reproduce this with an up to date debian testing? thank you.
Bug#885958: hostapd: iwlwifi 5GHz hw_mode=a causes microcode fault
tags 885958 moreinfo stop > [51085.431413] iwlwifi :03:00.0: Loaded firmware version: 29.541020.0 Can you reproduce this with up to date Debian testing? thank you for your report.
