Bug#969135: ITP: ttf-deepin-opensymbol -- Allows you to seamlessly transit from Wingdings to Deepin OpenSymbol
Hi, On Fri, Aug 28, 2020 at 10:03 AM stan clay wrote: > > Package: wnpp > Severity: wishlist > Owner: Hu Feng > X-Debbugs-Cc: debian-de...@lists.debian.org > > > * Package name: ttf-deepin-opensymbol > Version : 1.360 > Upstream Author : leaeasy > * URL : https://github.com/linuxdeepin/deepin-opensymbol-fonts > License : Apache-2.0 Would you mind to clarify the license? The license file inside the github repository says those fonts are under "Deepin OpenSymbol Public License" while here you say it is Apache-2.0. Regards, Aron
Bug#969138: onedrive: cannot delete non-empty folders in OneDrive for Business
forwarded 969138 https://github.com/abraunegg/onedrive/issues/1041 thanks Hi Roman, I forwarded your wishlist to the issue tracker of onedrive, see above. Please feel free to chime in there! Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#969070: $console handling might result in unbootable system
On 27/08/2020 22:43, Vagrant Cascadian wrote:
Control: severity 969070 important
On 2020-08-27, Andre Heider wrote:
Since [0] flash-kernel does:
if test -n "${console}"; then
setenv bootargs "${bootargs} console=${console}"
fi
The common $console format as set by u-boot includes the leading "console=":
include/configs/arndale.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/espresso7420.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/mvebu_armada-37xx.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
include/configs/mvebu_armada-37xx.h:"console="
CONFIG_DEFAULT_CONSOLE "\0" \
include/configs/odroid.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/odroid.h: "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/odroid_xu3.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/odroid_xu3.h: "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/origen.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/peach-pi.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/peach-pit.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/s5p_goni.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/s5p_goni.h: "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/s5pc210_universal.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/s5pc210_universal.h:"console=" CONFIG_DEFAULT_CONSOLE \
include/configs/smdk5250.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/smdkv310.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/snow.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/spring.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/trats.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/trats.h:"console=" CONFIG_DEFAULT_CONSOLE \
include/configs/trats2.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/trats2.h: "console=" CONFIG_DEFAULT_CONSOLE \
So on some boards we end up with bootargs containing
"console=console=...", which, combined with a systemd bug [1] (present
in buster), makes the system unbootable:
[4.632197] systemd-udevd[90]: Starting version 241
[4.639324] systemd-udevd[91]: Failed to create udev control event
source: Operation not permitted
In debian's u-boot package, this has been patched out for some targets
(and upstream originally included the patches, but eventually reverted).
The problem stems from an inconsistancy in u-boot, as some platforms use
this argument differently(especially when you get into vendor forks of
u-boot), and I don't believe u-boot has pattern matching to be able to
handle this properly (e.g. behave differently when console=* is set).
Doing a "env delete console" and the system boots up properly. That
includes the kernel output over serial, since the kernel dts files have
contain "chosen { stdout-path = };".
Not all systems have stdout-path defined in the device-tree.
Maybe now those are the exceptions...
So I'd say appending $console to $bootargs is some historical leftover,
and it can just be removed from the generic scripts.
The problem is that *not* doing this with console can also result in an
unbootable system.
Huh, how does that break?
Reverting this would be breaking one thing to fix another. There's no
"correct" here, only different. :/
flash-kernel supports assigning different boot scripts per boards. I
mean, we could get rid of $console from the generic scripts, and then
use a different one with it for boards requiring it.
Stats:
Going by u-boot upstream, only 17 of +700 boards set $console (grep for
CONFIG_DEFAULT_CONSOLE, which too is deprecated).
Going by linux upstream, 112 of 125 arm64 boards used "stdout-path":
$ find /usr/lib/linux-image-4.19.0-10-arm64 -name \*.dtb|xargs strings
-f|grep stdout-path|wc -l
112
$ find /usr/lib/linux-image-4.19.0-10-arm64 -name \*.dtb|wc -l
125
I didn't check 32bit arm, but going by those numbers we could at least
drop it for bootscript/arm64/bootscr.uboot-generic (I ran into this
issue on arm64).
Regards,
Andre
Bug#969138: onedrive: cannot delete non-empty folders in OneDrive for Business
Package: onedrive Version: 2.4.4-1 Severity: wishlist Dear Maintainer, I do not know whether this is default for all or most OneDrive for Business setups, but in my OneDrive in Office 365, I cannot delete a directory if it contains other directories or files from the web interface. As a result I can delete such directory with a Windows desktop client, but I cannot delete it with onedrive for linux. I get the following error: ERROR: OneDrive returned an error with the following message: Error Message: HTTP request returned status code 401 (FORBIDDEN) Error Reason: Access denied. You do not have permission to perform this action or access this resource. As a workaround, I can delete the contents of the directory first and proceed with deleting the directory itself. It would be nice, if onedrive client could chain those requests automatically. Alternatively, it could provide a similar warning as the web interface does: "You have to delete all the items in this folder before you can delete the folder." >From forum discussions, I guess that it is has something to do with retention policies, but it makes no sense to me because I can easily delete the entire folders along with their contents in OneDrive Windows client. Best wishes Roman -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/6 CPU threads) Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.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 onedrive depends on: ii init-system-helpers 1.58 ii libc62.31-3 ii libgcc-s110.2.0-5 ii libglib2.0-0 2.64.4-1 ii libnotify4 0.7.9-1 ii libphobos2-ldc-shared91 1:1.21.0-1+b1 ii libsqlite3-0 3.33.0-1 onedrive recommends no packages. onedrive suggests no packages. -- no debconf information
Bug#969137: darktable: Histogram not shown
Package: darktable Version: 3.2.1-2+b1 Severity: normal Dear Maintainer, When working on a image in darktable the histogram is not shown, a user suggested I try Ctrl+Shift+H and the only change I see is a very thin dark line in the place where the histogram should be. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8), LANGUAGE=es_CL:es Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages darktable depends on: ii libc62.31-3 ii libcairo21.16.0-4 ii libcolord-gtk1 0.1.26-2 ii libcolord2 1.4.4-2 ii libcups2 2.3.3-2 ii libcurl3-gnutls 7.68.0-1+b1 ii libexiv2-27 0.27.3-3 ii libgcc-s110.2.0-5 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.64.4-1 ii libgomp1 10.2.0-5 ii libgphoto2-6 2.5.25-3 ii libgphoto2-port122.5.25-3 ii libgraphicsmagick-q16-3 1.4+really1.3.35+hg16297-1 ii libgtk-3-0 3.24.22-1 ii libilmbase25 2.5.3-2 ii libjpeg62-turbo 1:2.0.5-1.1 ii libjs-prototype 1.7.1-3 ii libjs-scriptaculous 1.9.0-2 ii libjson-glib-1.0-0 1.4.4-2 ii liblcms2-2 2.9-4+b1 ii liblensfun1 0.3.2-5 ii liblua5.3-0 5.3.3-1.1+b1 ii libopenexr25 2.5.3-2 ii libopenjp2-7 2.3.1-1 ii libosmgpsmap-1.0-1 1.1.0-7 ii libpango-1.0-0 1.46.0-2 ii libpangocairo-1.0-0 1.46.0-2 ii libpng16-16 1.6.37-2 ii libpugixml1v51.10-1 ii librsvg2-2 2.48.7-1 ii libsecret-1-00.20.3-1 ii libsoup2.4-1 2.70.0-1 ii libsqlite3-0 3.33.0-1 ii libstdc++6 10.2.0-5 ii libtiff5 4.1.0+git191117-2 ii libwebp6 0.6.1-2+b1 ii libx11-6 2:1.6.10-3 ii libxml2 2.9.10+dfsg-5+b1 ii libxrandr2 2:1.5.1-1 ii zlib1g 1:1.2.11.dfsg-2 darktable recommends no packages. darktable suggests no packages. -- no debconf information
Bug#969136: xserver-xorg-video-amdgpu: Xserver keeps crashing inside of /usr/lib/xorg/modules/drivers/amdgpu_drv.so
Package: xserver-xorg-video-amdgpu Version: 19.1.0-1 Severity: grave Justification: causes non-serious data loss Dear Maintainer, About once a day my Xserver crashes. The following stracktrace appears in the Xorg log: ``` [ 72995.788] (EE) [ 72995.788] (EE) Backtrace: [ 72995.793] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x138) [0x56449292fe88] [ 72995.794] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7f8803c4e18f] [ 72995.794] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (__nss_database_lookup+0x28131) [0x7f8803bfdc41] [ 72995.797] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x112f0f) [0x7f880208227f] [ 72995.797] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x138740) [0x7f88020ccd30] [ 72995.798] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x13b601) [0x7f88020d22f1] [ 72995.799] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (nouveau_drm_screen_create+0x1db4ac) [0x7f88023cc4bc] [ 72995.799] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (nouveau_drm_screen_create+0x1d7a0f) [0x7f88023c4e6f] [ 72995.800] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (nouveau_drm_screen_create+0x1dbf83) [0x7f88023cd923] [ 72995.800] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_zink+0x210f9) [0x7f88018aa579] [ 72995.801] (EE) 10: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x148) [0x7f87f80a0b68] [ 72995.802] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 72995.802] (EE) 11: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (?+0x0) [0x7f880313d650] [ 72995.802] (EE) 12: /usr/lib/xorg/Xorg (BlockHandler+0xa5) [0x5644927d72c5] [ 72995.802] (EE) 13: /usr/lib/xorg/Xorg (WaitForSomething+0x11a) [0x5644929296fa] [ 72995.802] (EE) 14: /usr/lib/xorg/Xorg (SendErrorToClient+0x113) [0x5644927d2723] [ 72995.802] (EE) 15: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x5644927d6914] [ 72995.803] (EE) 16: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xea) [0x7f8803a99cca] [ 72995.803] (EE) 17: /usr/lib/xorg/Xorg (_start+0x2a) [0x5644927c073a] [ 72995.803] (EE) [ 72995.803] (EE) Segmentation fault at address 0x7f87e07f9000 [ 72995.803] (EE) Fatal server error: [ 72995.803] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 72995.803] (EE) [ 72995.803] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 72995.803] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 72995.803] (EE) [ 72995.803] (II) AIGLX: Suspending AIGLX clients for VT switch ``` There's nothing specific to trigger the bug, I've had it happen while doing a variety of different things. -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev ca) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.7.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-17), GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.7.17-1 (2020-08-23) Xorg X server log files on system: -- -rw-r--r-- 1 phil phil 33987 Nov 22 2019 /home/phil/.local/share/xorg/Xorg.0.log -rw-r--r-- 1 root root 53248 Aug 27 18:30 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 72996.232] X.Org X Server 1.20.8 X Protocol Version 11, Revision 0 [ 72996.232] Build Operating System: Linux 4.19.0-8-amd64 x86_64 Debian [ 72996.232] Current Operating System: Linux rider 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) x86_64 [ 72996.232] Kernel command line: BOOT_IMAGE=/vmlinuz-5.7.0-3-amd64 root=/dev/mapper/vg00-root ro quiet [ 72996.232] Build Date: 31 March 2020 10:14:40AM [ 72996.232] xorg-server 2:1.20.8-2 (https://www.debian.org/support) [ 72996.232] Current version of pixman: 0.36.0 [ 72996.232]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 72996.232] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 72996.232] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug 27 18:29:06 2020 [ 72996.232] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 72996.232] (==) No Layout section. Using the first Screen section. [ 72996.232] (==) No
Bug#938929: Problems with libvirt and iptables
Dear Maintainer Today I updated my Debian to version 10.5 that replaced iptables with nftables. When removing iptables the libvirt package was also removed and I can no longer reinstall it due to dependence on iptables. I have installed ebtables, but isn't solve this problem. My System is: SMP Debian 5.6.14-2~bpo10+1 (2020-06-09) x86_64 GNU/Linux Regards, Márcio Bacci
Bug#957069: cbmplugs: ftbfs with GCC-10
Tags 957069 +patch thanks gcc-10 changed the behaviour around global variables defined in multiple compilation units. Defined a variable in multiple compilation units with the default compiler flags will now result in a link failure. However in this particular case the variable doesn't appear to actually be used anywhere. It looks like someone was declaring an enum, got the name and body the wrong way round and accidently ended up defining a variable. Swapping the name with the body fixes the build. I have uploaded my fix to raspbian, a debdiff should appear soon at https://debdiffs.raspbian.org/main/c/cbmplugs I may or may not NMU this in Debian later.
Bug#969135: ITP: ttf-deepin-opensymbol -- Allows you to seamlessly transit from Wingdings to Deepin OpenSymbol
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ttf-deepin-opensymbol Version : 1.360 Upstream Author : leaeasy * URL : https://github.com/linuxdeepin/deepin-opensymbol-fonts License : Apache-2.0 Programming Lang: Makefile Descriptio : Allows you to seamlessly transit from Wingdings to Deepin OpenSymbol It is a substitution for Wingdings, which can perfectly solve the issue of displaying symbols in WPS. . It allows you to seamlessly transit from Wingdings to Deepin OpenSymbol. . I intend to co-maintain this package inside the pkg-deepin group.
Bug#969134: ITP: deepin-metacity -- lightweight GTK+ window manager
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: deepin-metacity Version : 3.22.24 Upstream Author : Sian Cao * URL : https://github.com/linuxdeepin/deepin-metacity License : GPL-2 Programming Lang: C Description : lightweight GTK+ window manager Metacity is a small window manager, using GTK+ to do everything. . As the author says, metacity is a "Boring window manager for the adult in you. Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios." . This package contains the core binaries. . I intend to co-maintain this package inside the pkg-deepin group.
Bug#966904: pfstools: FTBFS: array2d.h:173:9: error: ‘__assert_fail’ was not declared in this scope; did you mean ‘MagickCore::__assert_fail’?
Tags 966904 +patch thanks The issue is that Magick++.h (indirectly) includes assert.h inside a namespace. Note that generally only the first include of a header actually does anything due to the presense of include gaurds. Therefore if assert.h is included before Magick++.h then everything is fine, the symbols from assert.h are correctly included in the global namespace. OTOH if the first include of assert.h is the one from Magick++.h then the symbols from assert.h are defined in the MagickCore namespace which breaks stuff. I would argue that is a bug in imagemagick and have filed bugs in both Debian and upstream as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969128 and https://github.com/ImageMagick/ImageMagick6/issues/95 Nevertheless this can be worked around fairly easily in pfstools by re-ordering the includes so that pfs.h (which includes assert.h) is included before Magick++.h . I have done so in Raspbian bullseye-staging The patch for the upstream code can be found at https://github.com/raspbian-packages/pfstools/blob/bullseye-staging/debian/patches/reorder-includes-imagemagick.patch a debdiff should appear soon at https://debdiffs.raspbian.org/main/p/pfstools I may or may not NMU this in Debian later.
Bug#969133: ITP: deepin-keyring -- GnuPG keys of the Deepin archive
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: deepin-keyring Version : 2019.01.09 Upstream Author : deepinzhangshuang * URL : https://github.com/linuxdeepin/deepin-keyring License : GPL Programming Lang: Makefile Description : GnuPG keys of the Deepin archive The Deepin project digitally signs its Release files. This package contains the archive keys used for that. . I intend to co-maintain this package inside the pkg-deepin group.
Bug#969132: ITP: deepin-mutter -- lightweight GTK+ window manager for Deepin
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: deepin-mutter Version : 3.20.38 Upstream Author : Havoc Pennington * URL : https://github.com/linuxdeepin/deepin-mutter License : GPL Programming Lang: C Description : lightweight GTK+ window manager for Deepin Mutter is a small window manager, using GTK+ and Clutter to do everything. . Mutter is the clutter-based evolution of Metacity, which, as the author says, is a "Boring window manager for the adult in you. Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios." . This package contains the core binaries. . I intend to co-maintain this package inside pkg-deepin group.
Bug#969131: ITP: puzzle-jigsaw -- tile puzzle game
Package: wnpp Severity: wishlist Owner: Fabio Augusto De Muzio Tobich X-Debbugs-Cc: debian-de...@lists.debian.org, ftob...@gmail.com * Package name: puzzle-jigsaw Version : 1.0.2 Upstream Author : DanSoft * URL : https://bitbucket.org/admsasha/puzzle-jigsaw * License : GPL-3+, CC0 Programming Lang: C++ Description : tile puzzle game puzzle-jigsaw is a tile puzzle that requires the assembly of often oddly shaped interlocking and mosaiced pieces.
Bug#969130: libruby2.7: ENOENT error crash some ruby scripts
Package: libruby2.7
Version: 2.7.1-3
Severity: important
X-Debbugs-Cc: ant...@friki.cat
Dear Maintainer,
Some ruby scripts fail to run from a removed directory.
% cat /tmp/test.rb
#!/usr/bin/ruby
require 'unicode'
% mkdir /tmp/foo
% cd /tmp/foo
% rmdir /tmp/foo
% /tmp/test.rb
Traceback (most recent call last):
5: from /tmp/test.rb:2:in `'
4: from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
`require'
3: from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
`require'
2: from /usr/lib/ruby/vendor_ruby/unicode.rb:2:in `'
1: from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
`require'
/usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require': cannot
load such file -- unicode/2.7/unicode_native (LoadError)
16: from /tmp/test.rb:2:in `'
15: from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
`require'
14: from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
`require'
13: from /usr/lib/ruby/vendor_ruby/unicode.rb:2:in `'
12: from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:156:in
`require'
11: from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:161:in
`rescue in require'
10: from /usr/lib/ruby/2.7.0/rubygems.rb:204:in `try_activate'
9: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:996:in
`find_by_path'
8: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:996:in `find'
7: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:996:in `each'
6: from /usr/lib/ruby/2.7.0/rubygems/specification.rb:997:in `block in
find_by_path'
5: from /usr/lib/ruby/2.7.0/rubygems/bundler_version_finder.rb:39:in
`compatible?'
4: from /usr/lib/ruby/2.7.0/rubygems/bundler_version_finder.rb:7:in
`bundler_version'
3: from /usr/lib/ruby/2.7.0/rubygems/bundler_version_finder.rb:22:in
`bundler_version_with_reason'
2: from /usr/lib/ruby/2.7.0/rubygems/bundler_version_finder.rb:73:in
`lockfile_version'
1: from /usr/lib/ruby/2.7.0/rubygems/bundler_version_finder.rb:85:in
`lockfile_contents'
/usr/lib/ruby/2.7.0/rubygems/bundler_version_finder.rb:85:in `pwd': No such
file or directory - getcwd (Errno::ENOENT)
If apt-listchanges package is installed apt crashes that way. That's why I've
switched to "important".
Following inline patch fixes the issue.
From: Antoni Villalonga
Date: Fri, 28 Aug 2020 02:09:42 +0200
Subject: Rescue getcwd ENOENT error
Forwarded: not-needed
Upstream-Author: David Rodríguez
Rescue ENOENT error allowing run ruby scripts when cwd does not exists.
Cherry-pick from upstream 96064e6f1ce100a37680dc8f9509f06b3350e9c8
--- a/lib/rubygems/bundler_version_finder.rb
+++ b/lib/rubygems/bundler_version_finder.rb
@@ -82,12 +82,19 @@
def self.lockfile_contents
gemfile = ENV["BUNDLE_GEMFILE"]
gemfile = nil if gemfile && gemfile.empty?
-Gem::Util.traverse_parents Dir.pwd do |directory|
- next unless gemfile = Gem::GEM_DEP_FILES.find { |f|
File.file?(f.tap(::UNTAINT)) }
- gemfile = File.join directory, gemfile
- break
-end unless gemfile
+unless gemfile
+ begin
+Gem::Util.traverse_parents(Dir.pwd) do |directory|
+ next unless gemfile = Gem::GEM_DEP_FILES.find { |f|
File.file?(f.tap(::UNTAINT)) }
+
+ gemfile = File.join directory, gemfile
+ break
+end
+ rescue Errno::ENOENT
+return
+ end
+end
return unless gemfile
Regards,
Bug#969129: FAT32 partitions smaller than 512M should be allowed (update to 1.1.0!)
FWIW, the debian/watch file also needs to be changed to reflect the move to GitHub. ``` version=4 opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/-$1\.tar\.gz/ \ https://github.com/ya-mouse/fatresize/tags .*/v?(\d\+S+)\.tar\.gz ``` Regards, Mingye Wang
Bug#969129: FAT32 partitions smaller than 512M should be allowed (update to 1.1.0!)
Package: fatresize Version: 1.0.2-11 Version: 1.0.2-12 It is very common to have small FAT32 partitions in EFI use, but fatresize is currently disallowing these to be smaller than 512M. The upstream has already fixed the problem in version 1.1.0.[1] Please get it into the unstable-testing-backport pipeline. [1]: https://github.com/ya-mouse/fatresize/issues/11 Regards, Mingye Wang (Artoria2e5)
Bug#969110: gemrb: New upstream release 0.8.7
Source: gemrb Severity: wishlist Hello, The recent 0.8.7 release of GemRB got a lot of attention, due to being synced with the 20 years of the project (congratulations to all the team!). It would be really nice to have access to this new version in Debian Sid repositories, especially to help getting eyes on the RC issue #936595 and its upstream blocker https://github.com/gemrb/gemrb/issues/95 - 0.8.7 release page on GitHub: https://github.com/gemrb/gemrb/releases/tag/v0.8.7 - 0.8.7 release notes: https://gemrb.org/2020/08/24/gemrb-0-8-7-released.html -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/8 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 -- no debconf information
Bug#969085: nvidia-legacy-390xx-kernel-dkms: fails to build against 5.8.x kernel due to nvidia-uvm module license
Hi Andreas > [...] > But there are some more things that need to be changed for Linux 5.8 ... > (which can be backported from 450.57). > > > Andreas you're right: I forgot to mention I previously adapted and applied a patch I found on the Gentoo Forums (1). Thanks [1] https://forums.gentoo.org/viewtopic-p-8488827.html#8488783
Bug#969128: libmagick++-6.q16-dev includes assert.h inside namespace.
Package: libmagick++-6.q16-dev
Version: 8:6.9.11.24+dfsg-1+b1
This bug is based on testing related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966904
Compiling the following simple test program fails.
#include
#include
int main() {
assert(1==2);
}
g++ `pkg-config --cflags ImageMagick++` test.cpp
In file included from test.cpp:2:
test.cpp: In function ‘int main()’:
test.cpp:4:5: error: ‘__assert_fail’ was not declared in this scope; did you
mean ‘MagickCore::__assert_fail’?
4 | assert(1==2);
| ^~
In file included from /usr/include/ImageMagick-6/magick/memory_.h:22,
from /usr/include/ImageMagick-6/magick/MagickCore.h:125,
from /usr/include/ImageMagick-6/Magick++/Include.h:45,
from /usr/include/ImageMagick-6/Magick++.h:10,
from test.cpp:1:
/usr/include/assert.h:69:13: note: ‘MagickCore::__assert_fail’ declared here
69 | extern void __assert_fail (const char *__assertion, const char *__file,
|
The same code builds fine in buster.
The issue is that Magick++/Include.h includes the imagemagick headers inside a
namespace,
unfortunately the imagemagick headers in turn include the assert.h header which
therefore
gets included inside the namespace and breaks other code that tries to use
functionality
from assert.h
A possible fix would be to have Include.h include assert.h before opening the
namespace.
(a number of other standard C headers are already included by Include.h
presumablly
for this very reason).
Bug#969127: RM: libboxfort -- NBS; After a packaging change this package become empty, so removed from the control file
Package: ftp.debian.org Severity: normal I also think that there is a bug somewhere in the cruft-report, as the packages should have been in the daily report. The problem is that the packages for the amd64 and the i386 architecture was automatically removed but the armel and armhf was unremovable because of some reverse dependency. And when that dependency were fixed, the leftover architectures were not reconsidered by the dak, although: sasa@coccia:~$ dak rm -b libboxfort -Rn Will remove the following packages from unstable: libboxfort | 0.0.0-git20200105-3e16c0a-2 | armel libboxfort | 0.0.0-git20200105-3e16c0a-6 | armhf Maintainer: SZALAY Attila --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#961723: miniupnpd: does not work with the default iptables by update-alternatives
> it seems there is no way to > enable iptables and nftables in a single binary. I wonder if we can use update-alternatives. update-alternatives x-window-manager works as explained in https://debian-handbook.info/browse/en-US/stable/sect.customizing-graphical-interface.html Ryutaroh
Bug#969097: Missing "ifquery --state" functionality breaks /etc/network/if-up.d/mountnfs
Package: ifupdown2 Version: 1.2.5-1 Severity: normal I tried ifupdown2 on a system that mounts NFS mounts at boot and the script /etc/network/if-up.d/mountnfs (from package initscripts) cannot mount the nfs mounts from /etc/fstab anymore because it relies on "ifquery --state $INTERFACE" to check if the network interface is up. The "mountnfs" script expect the return code of "ifquery --state $INTERFACE" to be 0 for an interface that is up but because the option doesn't exist on the "ifquery" of ifupdown2, it will always exit with a code of 2 and thus breaking the test.
Bug#969126: Certbot will stop working for 2,220 users with upcoming Let's Encrypt deprecation
Package: python3-certbot Version: 0.28.0-1~deb9u2 Let’s Encrypt is in the process of shutting down ACMEv1. The full shutdown process will be completed in June 2021 with temporary brown-outs starting at the beginning of the year; more specific details are available at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430. When ACMEv1 is shut down, many older versions of Certbot will be unable to get new certificates. ACMEv2 support was first made default in 0.26.0 for new certificates, but it wasn’t until 1.6.0 that certificates which had originally been issued using ACMEv1 were transitioned to ACMEv2. The original update was supposed to move people off of ACMEv1, but due to some old configuration management code, we missed a small group of early Certbot users. Based on recent counts, there are a total of 2,220 distinct non-EOL Debian users still using ACMEv1 who use the version of Certbot packaged in their system’s package manager (1,665 users of 0.28.0 on debian 9 stretch and 555 users of 0.31.0 on debian 10 buster) that will encounter this issue. These users will no longer receive certs in June, but would be automatically upgraded to ACMEv2 if the package for their system were updated. The commit that switches ACMEv1 users to ACMEv2 is here: https://github.com/certbot/certbot/commit/340a4280eacc3eac8915996d89ff0c0a0cd023f9 One option to address the upcoming shutdown is to backport the commit into older versions of Certbot. Another option to address the shutdown, which is preferable from our perspective, would be to update Certbot to 1.6.0+. First, there’s the inherent risk in backporting an individual change, especially onto much older code. Released versions are tested extensively both on our systems and by our users, so we’re much more sure of their stability than a backported patch. Additionally, Certbot continues to improve over time, closing up bugs, supporting more edge cases, improving usability, and offering more robust and modern security practices. Since we made backwards incompatible changes in 0.40.0 and 1.0.0, to update Certbot to a newer version, our other components will have to be updated as well. Certbot relies on our other libraries `acme` and `josepy`, and we have a series of plugins which will need to be updated as well, including the `certbot-nginx` and `certbot-apache` plugins, as well as our `certbot-dns-*` plugins. Certbot 1.0.0 in particular contained significant API changes, and if any of our packages are updated to 1.0.0 or newer, it will probably be easiest to update all of them. josepy may be fine depending on the version of certbot, as certbot 1.0.0 relies on `josepy>=1.1.0`, which is already available packaged on all relevant systems. But Certbot 1.0.0 also requires `acme>=0.40.0`, which is only one release behind 1.0.0, so it would probably be easier to update it to a matching version. Basically, I would recommend choosing a certbot version, then updating `acme`, `certbot-nginx`, `certbot-apache`, and `certbot-dns-*` to that version. None of our 3rd party dependencies should need to be updated. One thing to note when choosing a version is that Certbot 1.7.0 deprecated Python 3.5 support, which may be necessary on older systems, so 1.6.0 may be a better choice than later versions on older systems. Certbot 0.40.0 and 1.0.0 introduced backwards incompatible changes; these include: * CLI flags --tls-sni-01-port and --tls-sni-01-address have been removed. * The values tls-sni and tls-sni-01 for the --preferred-challenges flag are no longer accepted. * Removed the flags: `--agree-dev-preview`, `--dialog`, and `--apache-init-script` * Certbot's `config_changes` subcommand has been removed * `certbot.plugins.common.TLSSNI01` has been removed. * Deprecated attributes related to the TLS-SNI-01 challenge in `acme.challenges` and `acme.standalone` have been removed. * The functions `certbot.client.view_config_changes`, `certbot.main.config_changes`, `certbot.plugins.common.Installer.view_config_changes`, `certbot.reverter.Reverter.view_config_changes`, and `certbot.util.get_systemd_os_info` have been removed * Certbot's `register --update-registration` subcommand has been removed * When possible, default to automatically configuring the webserver so all requests redirect to secure HTTPS access. This is mostly relevant when running Certbot in non-interactive mode. Previously, the default was to not redirect all requests.
Bug#969124: RFS: libfilezilla/0.24.1-1 [Team] -- build high-performing platform-independent programs (runtime lib)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libfilezilla": * Package name: libfilezilla Version : 0.24.1-1 Upstream Author : Tim Kosse * URL : https://lib.filezilla-project.org/ * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/libfilezilla Section : libs It builds those binary packages: libfilezilla0 - build high-performing platform-independent programs (runtime lib) libfilezilla-dev - build high-performing platform-independent programs (development) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libfilezilla/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.24.1-1.dsc Changes since the last upload: libfilezilla (0.24.1-1) unstable; urgency=medium . * Team upload * New upstream version 0.24.1 * Add 'debian/upstream/metadata' Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#969125: RFS: filezilla/3.50.0-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "filezilla": * Package name: filezilla Version : 3.50.0-1 Upstream Author : Tim Kosse * URL : https://filezilla-project.org/ * License : permissive, BSD-like, GPL-2+, MIT, CC0-1.0 * Vcs : https://salsa.debian.org/debian/filezilla Section : net It builds those binary packages: filezilla-common - Architecture independent files for filezilla filezilla - Full-featured graphical FTP/FTPS/SFTP client To access further information about this package, please visit the following URL: https://mentors.debian.net/package/filezilla/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.50.0-1.dsc Changes since the last upload: filezilla (3.50.0-1) unstable; urgency=medium . * Team upload * New upstream version 3.50.0 * Updated libfilezilla-dev versioned build-dep to 0.24.1 * Add 'debian/upstream/metadata' Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#969123: webext-ublock-origin: FF80 broke ublock again
Package: webext-ublock-origin Version: 1.28.0+dfsg-1 Severity: grave Justification: renders package unusable Hey. It seems stupid *zilla broke ublock origina again with the new Firefox. All adds are shown. Cheers, Chris. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) webext-ublock-origin depends on no packages. Versions of packages webext-ublock-origin recommends: ii firefox 80.0-1 Versions of packages webext-ublock-origin suggests: pn ublock-origin-doc -- no debconf information
Bug#969009: transition: sleuthkit
* Samuel Henrique: > Hello Sebastian, cc'in Hilko (who can shout if I'm saying something > wrong here) > > I'm helping Francisco with this transition and so I figure I should chime in, > >> pytsk build depends on libtsk-dev but the binaries don't depend on >> libtsk13. Is that expected? > > Yes, pytsk bundles libtsk and so it ends up in the "Built-Using" field > instead of a dependency, I confirmed that the binaries don't get > linked to it. This is only partly true. The pytsk source package does not bundle anything. I have modified the build script to link the system's libtsk statically instead of fetching Sleuthkit sources over the network at build time. This is why the Built-Using header is there. Please refer to debian/patches/0001-Link-system-tsk-statically-talloc-dynamically-instea.patch and look for "-Wl,-Bstatic -ltsk -Wl,-Bdynamic" in the build logs, e.g. [1]. > It's my assumption that in such cases there is no need to list the > package in the transition, would say this is the correct approach? This is correct. > We will perform a new upload of the package nonetheless just so our > users can get the fresh stuff. In the case of pytsk, triggering a rebuild should be enough. Cheers, -Hilko [1] https://buildd.debian.org/status/fetch.php?pkg=pytsk=amd64=20190507-1.1%2Bb1=1586514413=0
Bug#969070: $console handling might result in unbootable system
Control: severity 969070 important
On 2020-08-27, Andre Heider wrote:
> Since [0] flash-kernel does:
>
>if test -n "${console}"; then
> setenv bootargs "${bootargs} console=${console}"
>fi
>
> The common $console format as set by u-boot includes the leading "console=":
> include/configs/arndale.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC2,115200n8\0"
> include/configs/espresso7420.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/mvebu_armada-37xx.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
> include/configs/mvebu_armada-37xx.h:"console="
> CONFIG_DEFAULT_CONSOLE "\0" \
> include/configs/odroid.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/odroid.h: "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/odroid_xu3.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC2,115200n8\0"
> include/configs/odroid_xu3.h: "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/origen.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/peach-pi.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/peach-pit.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/s5p_goni.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC2,115200n8\0"
> include/configs/s5p_goni.h: "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/s5pc210_universal.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/s5pc210_universal.h:"console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/smdk5250.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/smdkv310.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC2,115200n8\0"
> include/configs/snow.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/spring.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC1,115200n8\0"
> include/configs/trats.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC2,115200n8\0"
> include/configs/trats.h:"console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/trats2.h:#define CONFIG_DEFAULT_CONSOLE
> "console=ttySAC2,115200n8\0"
> include/configs/trats2.h: "console=" CONFIG_DEFAULT_CONSOLE \
>
> So on some boards we end up with bootargs containing
> "console=console=...", which, combined with a systemd bug [1] (present
> in buster), makes the system unbootable:
> [4.632197] systemd-udevd[90]: Starting version 241
> [4.639324] systemd-udevd[91]: Failed to create udev control event
> source: Operation not permitted
>
In debian's u-boot package, this has been patched out for some targets
(and upstream originally included the patches, but eventually reverted).
The problem stems from an inconsistancy in u-boot, as some platforms use
this argument differently(especially when you get into vendor forks of
u-boot), and I don't believe u-boot has pattern matching to be able to
handle this properly (e.g. behave differently when console=* is set).
> Doing a "env delete console" and the system boots up properly. That
> includes the kernel output over serial, since the kernel dts files have
> contain "chosen { stdout-path = };".
Not all systems have stdout-path defined in the device-tree.
Maybe now those are the exceptions...
> So I'd say appending $console to $bootargs is some historical leftover,
> and it can just be removed from the generic scripts.
The problem is that *not* doing this with console can also result in an
unbootable system.
Reverting this would be breaking one thing to fix another. There's no
"correct" here, only different. :/
Downgraded severity, as this does not affect all systems.
live well,
vagrant
signature.asc
Description: PGP signature
Bug#969121: cbp2make FTCBFS: builds for the build architecture
Source: cbp2make Version: 147+dfsg-3 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs cbp2make fails to cross build from source, because it does not pass cross tools to make. Using dh_auto_build almost fixes that except that it does not pass LD, because that variable isn't used consistently. Thus passing LD should be done explicitly. Once doing so, cbp2make can be cross built. Please consider applying the attached patch. Helmut diff --minimal -Nru cbp2make-147+dfsg/debian/changelog cbp2make-147+dfsg/debian/changelog --- cbp2make-147+dfsg/debian/changelog 2020-04-16 11:35:31.0 +0200 +++ cbp2make-147+dfsg/debian/changelog 2020-08-27 22:23:57.0 +0200 @@ -1,3 +1,11 @@ +cbp2make (147+dfsg-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make and pass LD +explicitly. (Closes: #-1) + + -- Helmut Grohne Thu, 27 Aug 2020 22:23:57 +0200 + cbp2make (147+dfsg-3) unstable; urgency=medium * Team upload diff --minimal -Nru cbp2make-147+dfsg/debian/rules cbp2make-147+dfsg/debian/rules --- cbp2make-147+dfsg/debian/rules 2020-04-16 10:53:27.0 +0200 +++ cbp2make-147+dfsg/debian/rules 2020-08-27 22:23:57.0 +0200 @@ -10,11 +10,10 @@ include /usr/share/dpkg/buildflags.mk %: - dh $@ + dh $@ --buildsystem=makefile override_dh_auto_build-arch: - ln -sf cbp2make.cbp.mak.unix Makefile - $(MAKE) release + dh_auto_build -- -f cbp2make.cbp.mak.unix release 'LD=$$(CXX)' #build-indep: # ln -sf cbp2make.cbp.mak.unix Makefile
Bug#969122: libpam-alreadyloggedin FTCBFS: does not pass cross tools to make
Source: libpam-alreadyloggedin Version: 0.3-8 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs libpam-alreadyloggedin fails to cross build from source, because it does not pass cross tools to make. The easiest way of doing so - using dh_auto_build - makes libpam-alreadyloggedin cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru libpam-alreadyloggedin-0.3/debian/changelog libpam-alreadyloggedin-0.3/debian/changelog --- libpam-alreadyloggedin-0.3/debian/changelog 2020-03-10 16:49:11.0 +0100 +++ libpam-alreadyloggedin-0.3/debian/changelog 2020-08-27 22:29:11.0 +0200 @@ -1,3 +1,9 @@ +libpam-alreadyloggedin (0.3-9) UNRELEASED; urgency=medium + + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Thu, 27 Aug 2020 22:29:11 +0200 + libpam-alreadyloggedin (0.3-8) unstable; urgency=medium * QA upload. diff --minimal -Nru libpam-alreadyloggedin-0.3/debian/rules libpam-alreadyloggedin-0.3/debian/rules --- libpam-alreadyloggedin-0.3/debian/rules 2014-02-21 13:25:49.0 +0100 +++ libpam-alreadyloggedin-0.3/debian/rules 2020-08-27 22:29:07.0 +0200 @@ -14,7 +14,7 @@ .PHONY: build build-arch build-indep build build-arch: build-stamp build-stamp: debian/control - $(MAKE) + dh_auto_build touch $(@) build-indep: ;
Bug#969120: volpack: autopkgtest failures: gcc: No such file or directory
Source: volpack Version: 1.0b3-8 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: always-fails Dear maintainer(s), With a recent upload of volpack you added an autopkgtest, great. However, it fails. I copied some of the output at the bottom of this report. It seems you're missing test dependencies. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=volpack https://ci.debian.net/data/autopkgtest/testing/amd64/v/volpack/6650275/log.gz autopkgtest [15:52:41]: test run-unit-test: [--- Begin Testing ... gcc -g -O2 -Wall classifyvolume.c -o classifyvolume -s -lvolpack make: gcc: No such file or directory make: *** [Makefile:15: classifyvolume] Error 127 autopkgtest [15:52:41]: test run-unit-test: ---] signature.asc Description: OpenPGP digital signature
Bug#969119: libquantum FTCBFS: uses AC_RUN_IFELSE
Source: libquantum Version: 1.1.1-5 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs libquantum fails to cross build from source, because it uses AC_RUN_IFELSE. In some situations, that macro is unavoidable. The use of libquantum isn't, because it is evaluating a compile-time constant. We can also check that using AC_CHECK_SIZEOF and AC_COMPUTE_INT, both of which work during cross compilation. Please consider applying the attached patch to avoid using AC_RUN_IFELSE at no cost in functionality. Helmut --- libquantum-1.1.1.orig/configure.in +++ libquantum-1.1.1/configure.in @@ -96,11 +96,15 @@ AC_MSG_ERROR([No complex number type!]) fi +AC_CHECK_SIZEOF([double]) +AC_COMPUTE_INT([SIZEOF_CF_TYPE],[sizeof($CF_TYPE)]) +SIZEOF_2DOUBLE=`expr $ac_cv_sizeof_double + $ac_cv_sizeof_double` + AC_MSG_CHECKING([for corresponding real data type]) -AC_RUN_IFELSE( - [AC_LANG_PROGRAM([], [return sizeof($CF_TYPE) == 2*sizeof(double)])], - [RF_TYPE="float"], - [RF_TYPE="double"; AC_DEFINE(USE_DOUBLE)], [float]) +AS_IF( + [test "$SIZEOF_2DOUBLE" = "$SIZEOF_CF_TYPE"], + [RF_TYPE="double"; AC_DEFINE(USE_DOUBLE)], + [RF_TYPE="float"]) AC_MSG_RESULT($RF_TYPE)
Bug#969118: RM: liblightify -- ROM; RoM
Package: ftp.debian.org Severity: normal OSRAM discontinues Lightify soon and I have not really time anymore for (upstream) development, so lets drop it from Debian. -- tobi
Bug#969117: RM: gnome-shell-extension-suspend-button -- ROM; RoM, dead upstream, not supported on newer Gnome
Package: ftp.debian.org Severity: normal The package dpes not work on newer gnome and derserves retirement, especially as gnome has now built-in support… -- tobi
Bug#969116: fcode-utils FTCBFS: strips with the build architecture strip
Source: fcode-utils Version: 1.0.2-7 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs fcode-utils fails to cross build from source, because the upstream Makefiles strip with the build architecture strip. In one place, strip isn't even substitutable. Beyond breaking cross compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym packages. It is best practice to leave stripping up to dh_strip. The attached patch implements that and fixes all mentioned issues. Please consider applying it. Helmut diff --minimal -Nru fcode-utils-1.0.2/debian/changelog fcode-utils-1.0.2/debian/changelog --- fcode-utils-1.0.2/debian/changelog 2016-01-01 00:12:23.0 +0100 +++ fcode-utils-1.0.2/debian/changelog 2020-08-27 21:56:19.0 +0200 @@ -1,3 +1,10 @@ +fcode-utils (1.0.2-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Don't strip with the build architecture strip. (Closes: #-1) + + -- Helmut Grohne Thu, 27 Aug 2020 21:56:19 +0200 + fcode-utils (1.0.2-7) unstable; urgency=medium * Backport 05-bigendian.patch from upstream to fix some issues on big-endian diff --minimal -Nru fcode-utils-1.0.2/debian/patches/nostrip.patch fcode-utils-1.0.2/debian/patches/nostrip.patch --- fcode-utils-1.0.2/debian/patches/nostrip.patch 1970-01-01 01:00:00.0 +0100 +++ fcode-utils-1.0.2/debian/patches/nostrip.patch 2020-08-27 21:55:56.0 +0200 @@ -0,0 +1,19 @@ +--- fcode-utils-1.0.2.orig/romheaders/Makefile fcode-utils-1.0.2/romheaders/Makefile +@@ -23,6 +23,7 @@ + + CC = gcc + CFLAGS += -O2 -Wall -W -ansi -I../shared ++STRIP = strip + + SOURCES = romheaders.c ../shared/classcodes.c + +@@ -32,7 +33,7 @@ + + romheaders: $(SOURCES) + $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(SOURCES) -o $@ +- strip romheaders ++ $(STRIP) romheaders + + clean: + rm -f *~ diff --minimal -Nru fcode-utils-1.0.2/debian/patches/series fcode-utils-1.0.2/debian/patches/series --- fcode-utils-1.0.2/debian/patches/series 2016-01-01 00:10:18.0 +0100 +++ fcode-utils-1.0.2/debian/patches/series 2020-08-27 21:55:32.0 +0200 @@ -3,3 +3,4 @@ 03-makefile.patch 04-getopt.patch 05-bigendian.patch +nostrip.patch diff --minimal -Nru fcode-utils-1.0.2/debian/rules fcode-utils-1.0.2/debian/rules --- fcode-utils-1.0.2/debian/rules 2014-05-29 18:52:09.0 +0200 +++ fcode-utils-1.0.2/debian/rules 2020-08-27 21:56:18.0 +0200 @@ -2,3 +2,6 @@ %: dh $@ --parallel + +override_dh_auto_build: + dh_auto_build -- STRIP=true
Bug#968894: release.debian.org: binNMUs requests for libxcrypt "transition"
Hi,
On 2020-08-23 17:06, Sebastian Ramacher wrote:
> On 2020-08-23 13:37:42 +0200, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > X-Debbugs-Cc: debian-gl...@lists.debian.org, m...@linux.it
> >
> > Dear release team,
> >
> > Back in December we moved libcrypt.so.1 from the libc6 package to the
> > libcrypt1 package, which is built from the libxcrypt source package.
> > libcrypt will eventually get removed from glibc upstream, this will
> > allow faster development independently from glibc.
> >
> > As the ABI is compatible the "transition" has been transparent, libc6
> > depending on libcrypt1, and libc6-dev depending on libcrypt-dev.
> > However it would be good to rebuild the affected packages:
> > - They will get a direct dependency on libcrypt1. That would open the
> > possibility to remove the libc6 dependency on libcrypt1 in bookworm.
> > That would also allow to identify the affected packages to remove the
> > libc6-dev dependency on libcrypt-dev, or to handle a possible ABI
> > transition.
> > - They might start using additional functionalities (e.g. hashing
> > algorithms) provided by libcrypt1.
> >
> > Many packages have already been rebuilt against libxcrypt due to source
> > uploads or unrelated binNMUs. We are now down to less than 80 affected
> > packages on amd64, so it's probably acceptable to start binNMUing them.
> >
> > You will find the list below. It has been computed on amd64 only as it's
> > a long operation involving unpacking all the packages in the archive and
> > checking all the binaries they contains. As the change has been
> > introduced at the same time on all architectures, I believe the same
> > binNMUs are need for all of them, and anyway we need to keep them in
> > sync for multiarch libraries. Once we have been able to get all of the
> > packages fixed on amd64, I'll also check the other architectures to see
> > if some of them have been missed.
[snip]
> Scheduled binNMUs on all architectures.
Thanks for scheduling the binNMUs. We are down to the following list in
sid/amd64:
apr_1.6.5-1
=> The dependency are not installable, I filled #969065.
apr-util_1.6.1-4
=> The dependency are not installable, I filled #969064.
cernlib_20061220+dfsg3-4.4
=> FTBFS due to #957080, not in testing
fgetty_0.7-6
=> It got rebuilt fine and got correctly linked against the new
libcrypt.so.1. However it's not reflected in the dependencies as the
package doesn't use ${shlibs:Depends}. I filled #969063.
francine_0.99.8+orig-2
=> FTBFS due to #957226, not in testing
gadmin-proftpd_1:0.4.2-1
=> FTBFS due to #957248, not in testing
gadmin-rsync_0.1.7-1
=> FTBFS due to #957250, not in testing
gauche_0.9.6-10
=> FTBFS due to #957256, not in testing
gauche-c-wrapper_0.6.1-11
=> FTBFS due to #925691, not in testing
geant321_1:3.21.14.dfsg-11
=> FTBFS due to #957263, not in testing
gridengine_8.1.9+dfsg-9
=> FTBFS due to #957310, not in testing
mclibs_20061220+dfsg3-3.1
=> FTBFS due to #957522, not in testing
mysql-5.7_5.7.26-1
=> FTBFS due to #969115, not in testing
netatalk_3.1.12~ds-4
=> FTBFS due to #957590, not in testing
pam_1.3.1-5
=> FTBFS due to #956355
paw_1:2.14.04.dfsg.2-9.1
=> FTBFS due to #957665, not in testing
quagga_1.2.4-4
=> FTBFS due to #957737, not in testing
In short the affected ones that are also in testing are:
apr_1.6.5-1
apr-util_1.6.1-4
fgetty_0.7-6
pam_1.3.1-5
I'll track them to see if they get fixed or removed.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Bug#969115: mysql-5.7: FTBFS with GCC 10: multiple definition of symbols
Source: mysql-5.7 Version: 5.7.26-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) mysql-5.7 fails to build from source with GCC 10: | [ 42%] Linking CXX shared module innodb_engine.so | cd /<>/builddir/plugin/innodb_memcached/innodb_memcache && /usr/bin/cmake -E cmake_link_script CMakeFiles/innodb_engine.dir/link.txt --verbose=1 | /usr/bin/x86_64-linux-gnu-g++ -fPIC -g -O2 -fdebug-prefix-map=/<>=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wall -Wextra -Wformat-security -Wvla -Wimplicit-fallthrough=2 -Woverloaded-virtual -Wno-unused-parameter -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -std=gnu++03 -DDBUG_OFF -fPIC -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -shared -o innodb_engine.so CMakeFiles/innodb_engine.dir/src/innodb_config.c.o CMakeFiles/innodb_engine.dir/src/innodb_utility.c.o CMakeFiles/innodb_engine.dir/src/hash_item_util.c.o CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o CMakeFiles/innodb_engine.dir/src/innodb_api.c.o CMakeFiles/innodb_engine.dir/src/embedded_default_engine.c.o CMakeFiles/innodb_engine.dir/src/handler_api.cc.o CMakeFiles/innodb_engine.dir/cache-src/assoc.c.o CMakeFiles/innodb_engine.dir/cache-src/items.c.o CMakeFiles/innodb_engine.dir/cache-src/slabs.c.o -lpthread ../../../archive_output_directory/libmysqlservices.a ../../../archive_output_directory/liblibmcd_util.a -lpthread | /usr/bin/ld: CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:432: multiple definition of `ib_cb_cfg_trx_level'; CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:432: first defined here | /usr/bin/ld: CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:436: multiple definition of `ib_cb_cfg_bk_commit_interval'; CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:436: first defined here | /usr/bin/ld: CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:414: multiple definition of `ib_cb_trx_release'; CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:414: first defined here | /usr/bin/ld: CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:398: multiple definition of `ib_cb_tuple_delete'; CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:398: first defined here | /usr/bin/ld: CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:435: multiple definition of `ib_cb_trx_get_start_time'; CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:435: first defined here | /usr/bin/ld: CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:413: multiple definition of `ib_cb_trx_start'; CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:413: first defined here | /usr/bin/ld: CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:438: multiple definition of `ib_cb_cursor_stmt_begin'; CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:438: first defined here | /usr/bin/ld: CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:439: multiple definition of `ib_cb_trx_read_only'; CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:439: first defined here | /usr/bin/ld:
Bug#965002: fixed in mumble 1.3.2-1
Jonathan Rubenstein: > On Thu, 27 Aug 2020 04:03:38 + Debian FTP Masters > wrote: >> Changes: >> mumble (1.3.2-1) unstable; urgency=medium >> . >> * New upstream release from 2020-07-09 >> - Fixes 7-second startup delay due to jackd (Closes: #941455) >> Thanks to Matthias Heinz for reporting the bug >> - Fixes sound lockups caused when jackd started by Mumble client >> (Closes: #952742) >> Thanks to lemmel for reporting the bug >> Thanks to Sébastien Leblanc for finding a fix >> - Fixes getCurrentUrl return value (Closes: #956379) >> - Fixes New upstream version available (Closes: #965002) >> * debian/control: >> - Update Standards-Version to 4.5.0 (no changes needed) >> * debian/mumble.gconf-defaults: >> - Remove file due to GConf being deprecated (Closes: #959108) >> Note https://bugs.debian.org/908845 for reference concerning planned >> dh_gconf removal >> Thanks to Michael Biebl for reporting the bug and >> explaining the fix >> * debian/patches: >> - Add 54-fix-mysql-start.diff to change $mysql -> mysql (Closes: #698715) >> Thanks to Tim Besard for reporting the bug and >> finding the fix > > > Thanks for your hard work! If it's still in your workflow, don't forget to > push > these changes to https://salsa.debian.org/pkg-voip-team/mumble > > - Jonathan Rubenstein Yes, I just completed that just now. :) I had to wait until DAK accepted the package before I could push the changes in Git to Salsa. I'm glad to have these issues fixed finally. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#969114: apparmor-profiles: usr.sbin.dovecot does not allow reading /usr/share/dovecot/dh.pem (dovecot fails to start)
Package: apparmor-profiles Version: 2.13.2-10 Severity: normal Tags: upstream Dear Maintainer, This is produced if usr.sbin.dovecot is copied to /etc/apparmor.d: ``` type=AVC msg=audit(1598556536.092:901): apparmor="DENIED" operation="open" profile="dovecot" name="/usr/share/dovecot/dh.pem" pid=12625 comm="doveconf" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ``` This results in dovecot failing to start: ``` Aug 27 22:31:47 systemd[1]: Started Dovecot IMAP/POP3 email server. Aug 27 22:31:47 dovecot[13693]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 50: ssl_dh: Can't open file /usr/share/dove Aug 27 22:31:47 systemd[1]: dovecot.service: Main process exited, code=exited, status=89/n/a Aug 27 22:31:47 systemd[1]: dovecot.service: Failed with result 'exit-code'. ``` It is fixed by adding single rule: ``` /usr/share/dovecot/dh.pem r, ``` -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-10-armmp-lpae (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apparmor-profiles depends on: ii apparmor 2.13.2-10 apparmor-profiles recommends no packages. apparmor-profiles suggests no packages. -- Configuration Files: /etc/apparmor.d/bin.ping changed [not included] /etc/apparmor.d/sbin.klogd changed [not included] /etc/apparmor.d/sbin.syslog-ng changed [not included] /etc/apparmor.d/sbin.syslogd changed [not included] /etc/apparmor.d/usr.sbin.avahi-daemon changed [not included] /etc/apparmor.d/usr.sbin.dnsmasq changed [not included] /etc/apparmor.d/usr.sbin.identd changed [not included] /etc/apparmor.d/usr.sbin.mdnsd changed [not included] /etc/apparmor.d/usr.sbin.nmbd changed [not included] /etc/apparmor.d/usr.sbin.nscd changed [not included] /etc/apparmor.d/usr.sbin.smbd changed [not included] /etc/apparmor.d/usr.sbin.smbldap-useradd changed [not included] /etc/apparmor.d/usr.sbin.traceroute changed [not included] -- no debconf information
Bug#969113: spell: Please upload new upstream version 1.1
Package: spell Severity: wishlist Thank you! -- tobi
Bug#969111: RFP: codimd -- Web based real time collaborative markdown editing
Package: wnpp Severity: wishlist * Package name: codimd Version : 2.2.0 * URL : https://github.com/hackmdio/codimd * License : AGPL 3.0 Programming Lang: JavaScript Description : Web based real time collaborative markdown editing CodiMD lets you collaborate in real-time with markdown. Built on HackMD source code, CodiMD lets you host and control your team's content with speed and ease. This would be a nice addition to Freedombox, and is listed on the https://wiki.debian.org/FreedomBox/LeavingTheCloud > page. -- Happy hacking Petter Reinholdtsen
Bug#969112: RM: flashplugin-nonfree -- RoQA, unmainained, several RC bugs, techology deprecated
Package: flashplugin-nonfree Severity: serious Dear Maintainer, the package has currently 12 RC bugs (after de-duplicating 3) and no upload since years. It seems that the package should be retired, considering also that flash is heavily deprecated and will lose support end of the year. There are no r-depends on the package. This makes me wonder if we should retire this package. If you don't think so, just close this bug. If you also think so, just reassign it to the ftp.debian.org pseudo package. If there is no answer, I will reassing the bug in exactly 3 months. Thanks! tobi *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 flashplugin-nonfree depends on: ii binutils 2.35-2 ii ca-certificates20200601 ii debconf [debconf-2.0] 1.5.74 ii gnupg 2.2.20-1 ii gnupg2 2.2.20-1 ii libatk1.0-02.36.0-2 ii libcairo2 1.16.0-4 ii libcurl3-gnutls7.68.0-1+b1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.2+dfsg-3 ii libgcc-s1 [libgcc1]10.1.0-4 ii libglib2.0-0 2.64.4-1 ii libgtk2.0-02.24.32-4 ii libnspr4 2:4.27-1 ii libnss32:3.55-1 pn libpango1.0-0 ii libstdc++6 10.1.0-4 ii libx11-6 2:1.6.10-3 ii libxext6 2:1.3.3-1+b2 ii libxt6 1:1.1.5-1+b3 ii wget 1.20.3-1+b3 flashplugin-nonfree recommends no packages. Versions of packages flashplugin-nonfree suggests: ii firefox-esr68.11.0esr-1 ii fonts-dejavu 2.37-2 pn hal-flash pn iceweasel pn konqueror-nsplugins pn ttf-mscorefonts-installer pn ttf-xfree86-nonfree
Bug#963290: e-antic: FTBFS: ../e-antic/e-antic.h:24:2: error: #error FLINT 2.5.2 or 2.5.3 required
tags 963290 +patch thanks I just took a look at this issue. First I did some digging in the upstream git repo. Once I figured out their branch structure (the "master0" branch is apparently where current releases are made from) I was able to find two relavent commits. 10ed02f429f75a418ee41814af2dffc8cd41101f which added support for flint 2.6.0 and cebabe52632013a70be321d590301e06c306a766 which removed the upper limit on the flint version. I applied these to the Debian package, in the process I found that 10ed02f429f75a418ee41814af2dffc8cd41101f conflicted with the existing debian patch upstream-fix-sprintf_buffer_overflow.patch, following the upstream issue report link for that patch lead to a claim the issue was fixed as part of 10ed02f429f75a418ee41814af2dffc8cd41101f so I removed upstream-fix-sprintf_buffer_overflow.patch from the series. Next I ran into an issue with a test failing to build because it could not find the newly added EANTIC_FIXED_fmpq_poly_add_fmpq symbol. I added the symbol to the version script. The final issue I ran into was that some symbols had disappeared. +#MISSING: 0.1.5+ds-2+rpi1# EANTIC_FIXED_fmpq_poly_get_str_pretty@LIBEANTIC_0_1_2 0.1.2 +#MISSING: 0.1.5+ds-2+rpi1# _EANTIC_FIXED_fmpq_poly_get_str_pretty@LIBEANTIC_0_1_2 0.1.2 +#MISSING: 0.1.5+ds-2+rpi1# _nf_elem_mod_fmpz@LIBEANTIC_0_1_2 0.1.2 +#MISSING: 0.1.5+ds-2+rpi1# nf_elem_mod_fmpz@LIBEANTIC_0_1_2 0.1.2 +#MISSING: 0.1.5+ds-2+rpi1# nf_elem_mod_fmpz_den@LIBEANTIC_0_1_2 0.1.2 I searched for EANTIC_FIXED_fmpq_poly_get_str_pretty and nf_elem_mod_fmpz on the codesearch.debian.net website . I also installed all the reverse-dependencies listed on the autoremoval list and then grepped in /usr/lib and /usr/bin . With the source search the only references I found were in the e-antic source package. With the binary search the only references I found were in libeantic.so.0.1.5 and libeantic.a. As such I decided it was probably ok to remove the symbols from the symbols file and went ahead and updated the symbols file. With that I was able to get a successful build in Raspbian bullseye-staging and I have uploaded the package to Raspbian. A debdiff should appear soon at https://debdiffs.raspbian.org/main/e/e-antic
Bug#969108: O: xxkb -- Keyboard state indicator and switcher for xkb
Package: wnpp
Severity: normal
Hi,
According to https://bugs.debian.org/964546 , I orphan package xxkb
now.
If you want to be the new maintainer, please take it -- see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions on how to adopt a package properly.
Some information about the package:
Package: xxkb
Binary: xxkb
Version: 1.11-2.1
Maintainer: Artem Chuprina
Build-Depends: debhelper (>= 7.0), xutils-dev, libx11-dev, libxpm-dev,
libxt-dev, libxext-dev
Architecture: any
Standards-Version: 3.8.3
Format: 1.0
Files:
7b70868abadd8d7d68500fa0cdf5e230 1663 xxkb_1.11-2.1.dsc
19c7f3fa2186f686760f9fda9b86f757 37251 xxkb_1.11.orig.tar.gz
892938c187068d9c35dd13e64112f3f8 7565 xxkb_1.11-2.1.diff.gz
Checksums-Sha256:
a96fd09f88259ff52a593458440c3f95f654fa48939fbb90e67168a19d05d1ec 1663
xxkb_1.11-2.1.dsc
a7eea476dc1732ced3c8d210fe9d00162fc49dc53971965c71bb63d075249f59 37251
xxkb_1.11.orig.tar.gz
d1bd8e411fb0203456f95a8072f35d30b03134f3a8e9da6ed4b8708e22b6ed72 7565
xxkb_1.11-2.1.diff.gz
Homepage: http://sourceforge.net/projects/xxkb/
Directory: pool/main/x/xxkb
Priority: source
Section: x11
Package: xxkb
Source: xxkb (1.11-2.1)
Version: 1.11-2.1+b2
Installed-Size: 117
Maintainer: Artem Chuprina
Architecture: amd64
Depends: libc6 (>= 2.14), libx11-6, libxext6, libxpm4, libxt6
Description-en: Keyboard state indicator and switcher for xkb
This program is a keyboard state indicator and switcher for xkb.
Features:
- shows current xkb group (pixmap in its own window)
- allows switch group by mouse click
- allows individual state for every window
- can install its own button (indicator/mouse switcher) on every
window's
title bar
- can restrict keyboard states for every window to only two ("main
group" -
"alternative group") if xkb set up for more than two groups.
Bugs:
- documentation is partially in Russian (koi8-r charset) only
Description-md5: 55afd4682d9e285948ad9bfe5d7a1ac9
Homepage: http://sourceforge.net/projects/xxkb/
Tag: accessibility::input, culture::russian, hardware::input,
hardware::input:keyboard, interface::graphical, interface::x11,
role::program, scope::utility, uitoolkit::xlib, x11::application
Section: x11
Priority: optional
Filename: pool/main/x/xxkb/xxkb_1.11-2.1+b2_amd64.deb
Size: 39376
MD5sum: 871c891ba6d5a4232acd2f375edde248
SHA256:
b38aa853833d17f6fdf69bab726d222ec901035827f48c65ae5a0bded1e75a98
--
Thanks,
Boyuan Yang
signature.asc
Description: This is a digitally signed message part
Bug#968637: freeimage: FTBFS against libraw 0.20.0
tags 968637 +patch thanks On 26/08/2020 06:04, peter green wrote: Upstream seem to have a fix for this. https://sourceforge.net/p/freeimage/svn/1842/ I was able to succesfully apply the upstream change to the Debian package and built it in Raspbian bullseye-staging . I also bumped the build-dependency because it was not clear to me what impact the changes would have on operation with previous libraw versions. A debdiff should appear soon at https://debdiffs.raspbian.org/main/f/freeimage/ I may or may not NMU this later.
Bug#799323: local-apt-repository: Uninstallable without systemd despite that seems supported according to the package description
Hi, Am Mittwoch, den 19.08.2020, 06:21 + schrieb Job Bautista: > Hi, any update here? I rebuilt the 0.6 package to remove the dependency on > systemd > and it works fine in my systemd-less system (though I had to manually run the > rebuild script everytime I add new packages to the repository). I consider this (not having to manually run the rebuild script) central functionality of local-apt-repository: The goal is that the user has to worry about nothing but dropping apt files in the right directory. I only know how to achieve this easily with systemd. That said, I am not using it myself these days and am happy to yield upstream and debian maintenance to anyone who cares more about this package. Cheers, Joachim -- Joachim “nomeata” Breitner • nome...@debian.org • https://j.oach.im/ signature.asc Description: This is a digitally signed message part
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
On Thu, Aug 27, 2020 at 7:37 PM 積丹尼 Dan Jacobson wrote: > > Actually I am guessing the current maintainer isn't reading these > emails, and you Sudip, should consider non-maintainer uploads or steps > on how to take over the project altogether from non-active maintainers. Thats package hijacking. And Osamu is an active developer. So, I can't do that. And besides, We are all at debconf now so please expect delayed reply. -- Regards Sudip
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
Actually I am guessing the current maintainer isn't reading these emails, and you Sudip, should consider non-maintainer uploads or steps on how to take over the project altogether from non-active maintainers.
Bug#969107: ITP: gnome-shell-extension-panel-osd -- Configure the place where notifications are shown
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: gnome-shell-extension-panel-osd Version : 1.0-46-g28656ac Upstream Author : Berend De Schouwer Jens Lody * URL : https://gitlab.com/jenslody/gnome-shell-extension-panel-osd/ * License : GPL-3+ Programming Lang: JavaScript Description : Configure the place where notifications are shown gnome-shell-extension-panel-osd is an extension to show the notification messages at any (configurable) place on the (primary) monitor. I use this extension on my personal laptop as I found it very disturbing to get all my irc notification at the default location (top-centre). Now, thanks to this extension I can define where I want my notifications. -- Regards Sudip
Bug#969085: nvidia-legacy-390xx-kernel-dkms: fails to build against 5.8.x kernel due to nvidia-uvm module license
On 8/27/20 2:23 PM, Maurizio Avogadro wrote: > kernel 5.8.x made 'radix_tree_preloads' GPL-only: the build of the > nvidia-uvm, > which is MIT licensed, fails at modpost making the whole dkms build process > fail. This only affects the nvidia-uvm kernel module, which can be disabled as follows: 1) in dkms.conf, comment out BUILD_MODULE_NAME[3]/DEST_MODULE_NAME[3]/DEST_MODULE_LOCATION[3] and 2) build with NV_EXCLUDE_KERNEL_MODULES=nvidia-uvm set in the environment In 415.18 NVIDIA changed the the module license to "Dual MIT/GPL", so this issue does not affect later driver releases (which use the same code paths that triggers the error in 390.xx). Let's hope NVIDIA changes the license for 390.xx, too, in their next 390.xx release. But there are some more things that need to be changed for Linux 5.8 ... (which can be backported from 450.57). Andreas
Bug#969106: gdm3 can only start a gnome session, any other (e.g. mate, icewm, gnome on xorg...) fails
Package: gdm3 Version: 3.36.2-1 Severity: important Dear Maintainer, I don't know exactly with which version of gdm3 this occurred, but with the current one I am forced to choose "GNOME" as a session when logging in with the login manager. Any other choice just results in getting back to the login manager. And by "any" I mean also any other GNOME session, like "GNOME on Xorg", "GNOME fallback"... Only GNOME (which defaults running on Wayland) successfuly starts a user session. Due to this, I was currently forced to install another login manager (lightdm) and use that, since that enables me to use GNOME on Xorg (quite some apps still have problems on Wayland). And I want to be able to use other sessions, in case GNOME gets temporarily broken by some sid upgrade (it happened a number of times, and being able to run MATE proved then to be absolutely necessary). I would gladly produce any debugging info that may help tracing and solving this problem. Just give me directions on what you want me to test and what log files to collect and send. Thanks, best regards Giacomo Mulas -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.17-jak (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it_IT,en_EN Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 0.6.55-3 ii adduser 3.118 ii cinnamon [x-window-manager] 4.6.7-1 ii cinnamon-session [x-session-manager] 4.6.2-1 ii cwm [x-window-manager] 6.6-2 ii dbus 1.12.20-1 ii dconf-cli0.36.0-1 ii dconf-gsettings-backend 0.36.0-1 ii debconf [debconf-2.0]1.5.74 ii gir1.2-gdm-1.0 3.36.2-1 ii gnome-session [x-session-manager]3.36.0-2 ii gnome-session-bin3.36.0-2+b1 ii gnome-session-flashback [x-session-manager] 3.36.4-1 ii gnome-settings-daemon3.36.1-1 ii gnome-shell 3.36.5-1 ii gnome-terminal [x-terminal-emulator] 3.36.2-1 ii gsettings-desktop-schemas3.36.1-1 ii icewm [x-window-manager] 1.6.6-1 ii icewm-experimental [x-window-manager]1.6.6-1 ii kitty [x-terminal-emulator] 0.18.3-1 ii konsole [x-terminal-emulator]4:20.08.0-1 ii kwin-x11 [x-window-manager] 4:5.17.5-2+b1 ii libaccountsservice0 0.6.55-3 ii libaudit11:2.8.5-3+b1 ii libc62.31-3 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libgdm1 3.36.2-1 ii libglib2.0-0 2.64.4-1 ii libglib2.0-bin 2.64.4-1 ii libgtk-3-0 3.24.22-1 ii libkeyutils1 1.6.1-2 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam-systemd 246.2-1 ii libpam0g 1.3.1-5 ii librsvg2-common 2.48.7-1 ii libselinux1 3.1-2 ii libsystemd0 246.2-1 ii libwrap0 7.6.q-30 ii libx11-6 2:1.6.10-3 ii libxau6 1:1.0.8-1+b2 ii libxcb1 1.14-2 ii libxdmcp61:1.1.2-3 ii lsb-base 11.1.0 ii marco [x-window-manager] 1.24.1-1 ii mate-session-manager [x-session-manager] 1.24.1-1 ii mate-terminal [x-terminal-emulator] 1.24.1-1 ii metacity [x-window-manager] 1:3.36.1-1 ii muffin [x-window-manager]4.6.3-1 ii mutter [x-window-manager]3.36.5-1 ii mwm [x-window-manager] 2.3.8-3 ii openbox [x-window-manager] 3.6.1-9 ii plasma-workspace [x-session-manager] 4:5.17.5-4 ii policykit-1 0.105-29 ii procps 2:3.3.16-5 ii
Bug#969105: qiv: New upstream version 2.3.2 available
Package: qiv Severity: wishlist There is a new upstream version. TIA! -- tobi
Bug#965002: fixed in mumble 1.3.2-1
On Thu, 27 Aug 2020 04:03:38 + Debian FTP Masters wrote: > Changes: > mumble (1.3.2-1) unstable; urgency=medium > . > * New upstream release from 2020-07-09 > - Fixes 7-second startup delay due to jackd (Closes: #941455) > Thanks to Matthias Heinz for reporting the bug > - Fixes sound lockups caused when jackd started by Mumble client > (Closes: #952742) > Thanks to lemmel for reporting the bug > Thanks to Sébastien Leblanc for finding a fix > - Fixes getCurrentUrl return value (Closes: #956379) > - Fixes New upstream version available (Closes: #965002) > * debian/control: > - Update Standards-Version to 4.5.0 (no changes needed) > * debian/mumble.gconf-defaults: > - Remove file due to GConf being deprecated (Closes: #959108) > Note https://bugs.debian.org/908845 for reference concerning planned > dh_gconf removal > Thanks to Michael Biebl for reporting the bug and > explaining the fix > * debian/patches: > - Add 54-fix-mysql-start.diff to change $mysql -> mysql (Closes: #698715) > Thanks to Tim Besard for reporting the bug and > finding the fix Thanks for your hard work! If it's still in your workflow, don't forget to push these changes to https://salsa.debian.org/pkg-voip-team/mumble - Jonathan Rubenstein
Bug#969104: klavaro: New upstream release 3.11
Package: klavaro Severity: wishlist please package the new upstream release! TIA! -- tobi
Bug#969093: Newer upstream version of its-playback-time
David Damerell writes ("Bug#969093: Newer upstream version of
its-playback-time"):
> Package: its-playback-time
> Version: 0.2017-08-30.3c40fd3-1
>
> The upstream source had a series of bugfixes from the Crawl developers:
> https://www.chiark.greenend.org.uk/~sgtatham/ipbt/ipbt-20190601.d1519e0.tar.gz
>
> Please can we have them in Debian? Thanks.
>
> This is pretty terse for a bug report but I don't really have anything
> else to say.
Thanks, this is precisely the bug report I wanted :-)
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#969101: sdparm: Please add homepage to d/control
Package: sdparm Severity: normal Please add http://sg.danny.cz/sg/sdparm.html to d/control! Thanks!
Bug#965148: more info
On Fri, 17 Jul 2020 13:26:24 -0400 JMinson wrote: > When the failure occurs the content of 'value' as assigned at line 374 > in /usr/lib/python3/dist-packages/pyroute2/netlink/rtnl/req.py > > is > > value[0] is > "record[a,in-unique,f96a27a5-ac31-99b9-280f-62f2da5bd7f9.local.]=120" > > value[1] is "119,192.168.1.154" > > when the target is the Denon 'value' has a length of 1 and is > "192.168.1.176" > > > > ProblemType: Crash Date: Thu Aug 27 13:35:41 2020 ExecutablePath: /usr/bin/pulseaudio-dlna ExecutableTimestamp: 1585512125 ProcCmdline: pulse_watcher ProcCwd: /home/ ProcEnviron: ProcMaps: 0040-00423000 r--p 103:03 656618 /usr/bin/python3.8 00423000-006af000 r-xp 00023000 103:03 656618 /usr/bin/python3.8 006af000-008eb000 r--p 002af000 103:03 656618 /usr/bin/python3.8 008ec000-008ed000 r--p 004eb000 103:03 656618 /usr/bin/python3.8 008ed000-00934000 rw-p 004ec000 103:03 656618 /usr/bin/python3.8 00934000-00957000 rw-p 00:00 0 01588000-01bc6000 rw-p 00:00 0 [heap] 01bc6000-01c7a000 rw-p 00:00 0 [heap] 7f1d1800-7f1d1815c000 rw-p 00:00 0 7f1d1815c000-7f1d1c00 ---p 00:00 0 7f1d2000-7f1d20021000 rw-p 00:00 0 7f1d20021000-7f1d2400 ---p 00:00 0 7f1d246e2000-7f1d248a2000 rw-p 00:00 0 7f1d248a2000-7f1d248a7000 r--p 103:03 665370 /usr/lib/x86_64-linux-gnu/libudev.so.1.6.17 7f1d248a7000-7f1d248c2000 r-xp 5000 103:03 665370 /usr/lib/x86_64-linux-gnu/libudev.so.1.6.17 7f1d248c2000-7f1d248cc000 r--p 0002 103:03 665370 /usr/lib/x86_64-linux-gnu/libudev.so.1.6.17 7f1d248cc000-7f1d248cd000 r--p 00029000 103:03 665370 /usr/lib/x86_64-linux-gnu/libudev.so.1.6.17 7f1d248cd000-7f1d248ce000 rw-p 0002a000 103:03 665370 /usr/lib/x86_64-linux-gnu/libudev.so.1.6.17 7f1d248ce000-7f1d248d2000 r--p 103:03 665460 /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4 7f1d248d2000-7f1d24964000 r-xp 4000 103:03 665460 /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4 7f1d24964000-7f1d24975000 r--p 00096000 103:03 665460 /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4 7f1d24975000-7f1d24976000 r--p 000a6000 103:03 665460 /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4 7f1d24976000-7f1d24977000 rw-p 000a7000 103:03 665460 /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4 7f1d24977000-7f1d249b9000 r--p 103:03 664748 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0.0 7f1d249b9000-7f1d24b0 r-xp 00042000 103:03 664748 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0.0 7f1d24b0-7f1d24b49000 r--p 00189000 103:03 664748 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0.0 7f1d24b49000-7f1d24b5 r--p 001d1000 103:03 664748 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0.0 7f1d24b5-7f1d24b51000 rw-p 001d8000 103:03 664748 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0.0 7f1d24b51000-7f1d24b67000 r--p 103:03 663056 /usr/lib/python3/dist-packages/apt_pkg.cpython-38-x86_64-linux-gnu.so 7f1d24b67000-7f1d24b87000 r-xp 00016000 103:03 663056 /usr/lib/python3/dist-packages/apt_pkg.cpython-38-x86_64-linux-gnu.so 7f1d24b87000-7f1d24b9f000 r--p 00036000 103:03 663056 /usr/lib/python3/dist-packages/apt_pkg.cpython-38-x86_64-linux-gnu.so 7f1d24b9f000-7f1d24ba1000 r--p 0004d000 103:03 663056 /usr/lib/python3/dist-packages/apt_pkg.cpython-38-x86_64-linux-gnu.so 7f1d24ba1000-7f1d24baa000 rw-p 0004f000 103:03 663056 /usr/lib/python3/dist-packages/apt_pkg.cpython-38-x86_64-linux-gnu.so 7f1d24baa000-7f1d24bb8000 r--p 103:03 665357 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2 7f1d24bb8000-7f1d24bc7000 r-xp e000 103:03 665357 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2 7f1d24bc7000-7f1d24bd5000 r--p 0001d000 103:03 665357 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2 7f1d24bd5000-7f1d24bd9000 r--p 0002a000 103:03 665357 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2 7f1d24bd9000-7f1d24bda000 rw-p 0002e000 103:03 665357 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2 7f1d24bda000-7f1d24bee000 r--p 103:03 665267 /usr/lib/x86_64-linux-gnu/libreadline.so.8.0 7f1d24bee000-7f1d24c17000 r-xp 00014000 103:03 665267 /usr/lib/x86_64-linux-gnu/libreadline.so.8.0 7f1d24c17000-7f1d24c21000 r--p 0003d000 103:03 665267 /usr/lib/x86_64-linux-gnu/libreadline.so.8.0
Bug#969102: sdparm: new upstream release 1.11
Package: sdparm Severity: wishlist -- tobi
Bug#969103: elpa-flycheck: causes leak in GNU Emacs 27.1
Package: elpa-flycheck
Severity: critical
X-Debbugs-Cc: none, Lev Lamberov
User: debian-emac...@lists.debian.org
Usertags: emacs27
Dear Maintainer,
elpa-flycheck causes leak in GNU Emacs 27.1 from the Debian archive
(1:27.1+1-1, currently from experimental).
Excerpt from debug log:
Debugger entered--Lisp error: (error "Lisp nesting exceeds
‘max-lisp-eval-depth’")
cl-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
seq-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
cl-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
seq-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
cl-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
seq-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
cl-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
seq-subseq([("File" 6) ("Line" 5 flycheck-error-list-entry-< :right-align t)
("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<)
("ID" 6 t) (#("Message (Checker)" 9 16 (face flycheck-error-list-checker-name))
0 t)] 0 -1)
[..]
byte-code("\302\303\304\10\305\306#\11#\207" [flycheck-error-list-format
flycheck-error-list-padding seq-reduce #f(compiled-function (offset fmt)
#) seq-subseq 0 -1] 6)
(defconst flycheck--error-list-msg-offset (byte-code
"\302\303\304\10\305\306#\11#\207" [flycheck-error-list-format
flycheck-error-list-padding seq-reduce #f(compiled-function (offset fmt)
#) seq-subseq 0 -1] 6)
("/usr/share/emacs/site-lisp/elpa/flycheck-32snapsho..." . 171725))
autoload-do-load((autoload "flycheck" "Minor mode for on-the-fly syntax
checking.\n\nWhen c..." t nil) flycheck-mode)
desktop-load-file(flycheck-mode)
With regards,
Lev
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#969099: ddpt: New upstream version available
Package: ddpt Version: 0.95-1 Severity: wishlist There has been 0.96 released on 03.03.2020. Would be great if you could package it! Thanks! -- tobi
Bug#969100: ddpt: Please add Homepage to debian/control
Package: ddpt Version: 0.95-1 Severity: normal Please add the homepage http://sg.danny.cz/sg/ddpt.html to d/control. TIA! -- tobi
Bug#969098: debrebuild: fails to download some packages from snapshot.d.o
Package: devscripts Version: 2.19.5+deb10u1 Severity: normal User: devscri...@packages.debian.org Usertags: debrebuild Hi, Sometimes debrebuild fails to download some packages from snapshot.d.o even though they exist: "cannot find dash/0.5.10.2-5/amd64 in dumpavail" https://snapshot.debian.org/package/dash/0.5.10.2-5/#dash_0.5.10.2-5 clearly has it. The full log: Thu Aug 27 07:54:10 UTC 2020 - trying to debrebuild sdcv (0.5.2-2+b1), which means building instructions how to re-create the build environment as specified in https://buildinfos.debian.net/ftp-master.debian.org/buildinfo/2019/07/21/sdcv_0.5.2-2+b1_amd64.buildinfo /usr/share/keyrings/debian-archive-keyring.gpg linking /tmp/NT6LKLqhtz/etc/apt/trusted.gpg.d/debian-archive-keyring.gpg to /usr/share/keyrings/debian-archive-keyring.gpg /usr/share/keyrings/debian-archive-removed-keys.gpg linking /tmp/NT6LKLqhtz/etc/apt/trusted.gpg.d/debian-archive-removed-keys.gpg to /usr/share/keyrings/debian-archive-removed-keys.gpg Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB] Get:2 http://deb.debian.org/debian bullseye/main amd64 Packages [7679 kB] Fetched 7795 kB in 3s (2826 kB/s) Reading package lists... parsing /tmp/NT6LKLqhtz/var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_binary-amd64_Packages... retrieving snapshot.d.o data for autoconf 2.69-11 retrieving snapshot.d.o data for automake 1:1.16.1-4 retrieving snapshot.d.o data for autopoint 0.19.8.1-9 skipping autotools-dev 20180224.1 skipping base-files 11 retrieving snapshot.d.o data for base-passwd 3.5.46 retrieving snapshot.d.o data for bash 5.0-4 retrieving snapshot.d.o data for binutils 2.32.51.20190707-1 retrieving snapshot.d.o data for binutils-common 2.32.51.20190707-1 retrieving snapshot.d.o data for binutils-x86-64-linux-gnu 2.32.51.20190707-1 retrieving snapshot.d.o data for bsdmainutils 11.1.2+b1 retrieving snapshot.d.o data for bsdutils 1:2.33.1-0.1 retrieving snapshot.d.o data for build-essential 12.6 retrieving snapshot.d.o data for bzip2 1.0.6-9.2 retrieving snapshot.d.o data for cmake 3.13.4-1 retrieving snapshot.d.o data for cmake-data 3.13.4-1 retrieving snapshot.d.o data for coreutils 8.30-3 retrieving snapshot.d.o data for cpp 4:8.3.0-1 retrieving snapshot.d.o data for cpp-8 8.3.0-19 retrieving snapshot.d.o data for dash 0.5.10.2-5 retrieving snapshot.d.o data for debconf 1.5.72 retrieving snapshot.d.o data for debhelper 12.2.3 retrieving snapshot.d.o data for debianutils 4.8.6.3 skipping dh-autoreconf 19 retrieving snapshot.d.o data for dh-strip-nondeterminism 1.2.3-1 skipping diffutils 1:3.7-3 retrieving snapshot.d.o data for dpkg 1.19.7 retrieving snapshot.d.o data for dpkg-dev 1.19.7 retrieving snapshot.d.o data for dwz 0.12.20190716-1 retrieving snapshot.d.o data for fdisk 2.33.1-0.1 retrieving snapshot.d.o data for file 1:5.37-3 retrieving snapshot.d.o data for findutils 4.6.0+git+20190510-2 retrieving snapshot.d.o data for g++ 4:8.3.0-1 retrieving snapshot.d.o data for g++-8 8.3.0-19 retrieving snapshot.d.o data for gcc 4:8.3.0-1 retrieving snapshot.d.o data for gcc-8 8.3.0-19 retrieving snapshot.d.o data for gcc-8-base 8.3.0-19 retrieving snapshot.d.o data for gcc-9-base 9.1.0-8 retrieving snapshot.d.o data for gettext 0.19.8.1-9 retrieving snapshot.d.o data for gettext-base 0.19.8.1-9 retrieving snapshot.d.o data for grep 3.3-1 retrieving snapshot.d.o data for groff-base 1.22.4-3 retrieving snapshot.d.o data for gzip 1.9-3 retrieving snapshot.d.o data for hostname 3.21 retrieving snapshot.d.o data for init-system-helpers 1.57 skipping intltool-debian 0.35.0+20060710.5 retrieving snapshot.d.o data for jq 1.5+dfsg-2+b1 retrieving snapshot.d.o data for libacl1 2.2.53-4 retrieving snapshot.d.o data for libarchive-zip-perl 1.64-1 retrieving snapshot.d.o data for libarchive13 3.3.3-4 retrieving snapshot.d.o data for libasan5 9.1.0-8 retrieving snapshot.d.o data for libatomic1 9.1.0-8 retrieving snapshot.d.o data for libattr1 1:2.4.48-4 retrieving snapshot.d.o data for libaudit-common 1:2.8.5-1 retrieving snapshot.d.o data for libaudit1 1:2.8.5-1 retrieving snapshot.d.o data for libbinutils 2.32.51.20190707-1 retrieving snapshot.d.o data for libblkid-dev 2.33.1-0.1 retrieving snapshot.d.o data for libblkid1 2.33.1-0.1 retrieving snapshot.d.o data for libbsd0 0.9.1-2 retrieving snapshot.d.o data for libbz2-1.0 1.0.6-9.2 retrieving snapshot.d.o data for libc-bin 2.28-10 retrieving snapshot.d.o data for libc-dev-bin 2.28-10 retrieving snapshot.d.o data for libc6 2.28-10 retrieving snapshot.d.o data for libc6-dev 2.28-10 retrieving snapshot.d.o data for libcap-ng0 0.7.9-2 retrieving snapshot.d.o data for libcc1-0 9.1.0-8 retrieving snapshot.d.o data for libcom-err2 1.45.2-1 retrieving snapshot.d.o data for libcroco3 0.6.12-3 retrieving snapshot.d.o data for libcurl4 7.65.1-1 skipping libdb5.3 5.3.28+dfsg1-0.6 retrieving snapshot.d.o data for libdebconfclient0 0.249 retrieving snapshot.d.o data for libdpkg-perl 1.19.7 retrieving snapshot.d.o data for
Bug#949549: Not fixed
Am Montag, den 24.08.2020, 12:11 + schrieb PICCA Frederic-Emmanuel: Hello Frederic, yes I think this is a false positive indeed. The flags are correctly passed. Thanks for digging, Thomas > Hello Thomas, > > I am wondering if this is not a false positive. > > all the code is compiled with -D_FORTIFY_SOURCE=2 > > https://salsa.debian.org/science-team/tango/-/jobs/954394/raw > > Can you confirm that it is a false positive ? > > I am not that confident when it comes to hardening flags. > > for the record I checked also the Database and it is also affected by > this.
Bug#969083: unblock: libomxil-bellagio/0.9.3-6
Hi Paul On 27-08-2020 13:22, Ying-Chun Liu (PaulLiu) wrote: > libomxil-bellagio0 can be a "plugin" of gst-omx. That means gst-omx can > be run by itself without libomxil-bellagio0 at all. > The problem happens in autopkgtest. In test, we use libomxil-bellagio0 > as a plugin to test gst-omx. So, the *test* needs a *versioned* dependency? And one can still argue that the new libomxil-bellagio breaks the version of gst-omx in testing? > Thus gst-omx originally loads that plugin (in debian/tests scripts) from > /usr/lib. But now it needs to load > > that plugin through test scripts from multi-arch path. Paul
Bug#969096: cdimage.debian.org: Bullseye Alpha2 installation freezes
Package: cdimage.debian.org Severity: normal Dear Maintainer, When I'm trying to install Bullseye alpha2 32bit in Virtualbox 5.2 (host is 64bit machine), I got the following error message after selecting the 'Install' option: "kernel panic - not syncing: Attempt to kill init!" When I'm trying to install other Debian versions (i.e. Buster 10.5), no error occurred; so it shouldn't be a problem of Virtualbox. Thanks for checking. Regards Pavlos -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#969094: [Pkg-utopia-maintainers] Bug#969094: udisks2: /lib/udev/rules.d/90-udisks2-zram.rules both in udisks2 and udisks2-zram
Am 27.08.20 um 18:21 schrieb Yannick Roehlly: > Package: udisks2 > Version: 2.9.1-1 > Severity: grave > Justification: renders package unusable > > Hi, > > The update of udisks2 to 2.9.1-1 is not possible when udisks2-zram is > installed because both packages contain '/lib/udev/rules.d/90-udisks2- > zram.rules'. Indeed. Thanks for the bug report and sorry for the inconvenience. Michael signature.asc Description: OpenPGP digital signature
Bug#969095: RM: mysql-5.7 -- ROM; superseded by mysql-8.0
Package: ftp.debian.org Severity: normal Binary movements: libmysqld-dev is gone in src:mysql-8.0 - this feature is no longer supported upstream. The other binary packages have direct replacements: libmysqlclient20 -> libmysqlclient21 s/5.7/8.0/ There's also a new binary package mysql-router. Thanks, Robie signature.asc Description: PGP signature
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
Indeed in https://github.com/getmail6/getmail6/issues/33#issuecomment-681888347 we see the trend across distributions is for a single getmail package upgraded to 6 and not two packages.
Bug#969086: apt-mark man page has a typo: "extended_status" -> "extended_states"
Package: apt Version: 2.1.10 Severity: minor Tags: patch X-Debbugs-Cc: jcgo...@protonmail.com Dear Maintainer, I believe the apt-mark man page has a typo: "extended_status" should probably be "extended_states", since the other source files and the man page itself instead reference the file `/var/lib/apt/extended_states`. I am attaching a proposed patch to solve this issue. From 9a9829eb713bdbcf396a50ec99697a1d10abd6c7 Mon Sep 17 00:00:00 2001 From: JCGoran Date: Thu, 27 Aug 2020 14:00:57 +0200 Subject: [PATCH] Fix "extended_states" typo in apt-mark(8) --- doc/apt-mark.8.xml | 2 +- doc/po/apt-doc.pot | 2 +- doc/po/de.po | 4 ++-- doc/po/es.po | 4 ++-- doc/po/fr.po | 4 ++-- doc/po/it.po | 4 ++-- doc/po/ja.po | 4 ++-- doc/po/nl.po | 4 ++-- doc/po/pl.po | 4 ++-- doc/po/pt.po | 4 ++-- doc/po/pt_BR.po| 2 +- 11 files changed, 19 insertions(+), 19 deletions(-) diff --git a/doc/apt-mark.8.xml b/doc/apt-mark.8.xml index 76675fcd0..21a7a7cba 100644 --- a/doc/apt-mark.8.xml +++ b/doc/apt-mark.8.xml @@ -98,7 +98,7 @@ Read/Write package stats from the filename given with the parameter instead of from the default location, which - is extended_status in the directory defined + is extended_states in the directory defined by the Configuration Item: Dir::State. diff --git a/doc/po/apt-doc.pot b/doc/po/apt-doc.pot index 2ac04ccaa..be0b7063f 100644 --- a/doc/po/apt-doc.pot +++ b/doc/po/apt-doc.pot @@ -2284,7 +2284,7 @@ msgstr "" msgid "" "Read/Write package stats from the filename given with the parameter " " instead of from the default location, which is " -"extended_status in the directory defined by the " +"extended_states in the directory defined by the " "Configuration Item: Dir::State." msgstr "" diff --git a/doc/po/de.po b/doc/po/de.po index f6014bc90..9df84b1bb 100644 --- a/doc/po/de.po +++ b/doc/po/de.po @@ -3214,12 +3214,12 @@ msgstr "" msgid "" "Read/Write package stats from the filename given with the parameter " " instead of from the default location, which is " -"extended_status in the directory defined by the " +"extended_states in the directory defined by the " "Configuration Item: Dir::State." msgstr "" "schreibt/liest Paketstatus von dem Dateinamen, der mit dem Parameter " ", anstatt vom Standardort, der " -"extended_status im von Konfigurationselement " +"extended_states im von Konfigurationselement " "Dir::State definierten Verzeichnis, angegeben ist." #. type: Content of: diff --git a/doc/po/es.po b/doc/po/es.po index b8e126b85..d246fcc3c 100644 --- a/doc/po/es.po +++ b/doc/po/es.po @@ -3220,12 +3220,12 @@ msgstr "" msgid "" "Read/Write package stats from the filename given with the parameter " " instead of from the default location, which is " -"extended_status in the directory defined by the " +"extended_states in the directory defined by the " "Configuration Item: Dir::State." msgstr "" "Escribe y lee las estadísticas de los paquetes con el nombre de fichero " "definido con el parámetro , en lugar de la " -"ubicación predeterminada, que es extended_status en el " +"ubicación predeterminada, que es extended_states en el " "directorio definido con la opción de configuración: Dir::State." diff --git a/doc/po/fr.po b/doc/po/fr.po index 26160cef2..ace9b2095 100644 --- a/doc/po/fr.po +++ b/doc/po/fr.po @@ -3191,11 +3191,11 @@ msgstr "" msgid "" "Read/Write package stats from the filename given with the parameter " " instead of from the default location, which is " -"extended_status in the directory defined by the " +"extended_states in the directory defined by the " "Configuration Item: Dir::State." msgstr "" "Lecture/écriture des statistiques d'un paquet dans " -"au lieu du fichier par défaut (extended_status dans le " +"au lieu du fichier par défaut (extended_states dans le " "répertoire défini par l'élément de configuration Dir::State)." diff --git a/doc/po/it.po b/doc/po/it.po index b7c42d690..d12cb8984 100644 --- a/doc/po/it.po +++ b/doc/po/it.po @@ -3214,12 +3214,12 @@ msgstr "" msgid "" "Read/Write package stats from the filename given with the parameter " " instead of from the default location, which is " -"extended_status in the directory defined by the " +"extended_states in the directory defined by the " "Configuration Item: Dir::State." msgstr "" "Legge/Scrive le statistiche sui pacchetti dal file specificato con il " "parametro invece che dalla posizione predefinita " -"che è extended_status nella directory definita dalla " +"che è extended_states nella directory definita dalla " "voce di configurazione Dir::State." #. type: Content of: diff --git a/doc/po/ja.po b/doc/po/ja.po index 576f872c9..0ca911fc2 100644 --- a/doc/po/ja.po +++ b/doc/po/ja.po @@ -3107,11 +3107,11 @@ msgstr "" msgid "" "Read/Write package stats from the filename given with the parameter " " instead of from the default
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
> "SM" == Sudip Mukherjee writes: SM> X-Debbugs-Cc: Osamu Aoki I'm not sure that line will work there. I'll CC him anyway. SM> This getmail6 will install files like: SM> /usr/bin/getmail SM> /usr/bin/getmail_fetch SM> /usr/bin/getmail_mbox SM> /usr/bin/getmail_maildir SM> /usr/bin/getmail-gmail-xoauth-tokens SM> /usr/lib/python3/dist-packages/getmailcore SM> which are also installed by getmail. SM> So, I guess the best possible way might be if getmail maintainer updates SM> to this source, else I can package getmail6 with a "Breaks: getmail". Ah, good catch! I'm estimating that the current Debian getmail maintainer would actually be very happy if you Sudip, could take over the entire Debian getmail project. Then there indeed would be no need for two independent packages!
Bug#969094: udisks2: /lib/udev/rules.d/90-udisks2-zram.rules both in udisks2 and udisks2-zram
Package: udisks2 Version: 2.9.1-1 Severity: grave Justification: renders package unusable Hi, The update of udisks2 to 2.9.1-1 is not possible when udisks2-zram is installed because both packages contain '/lib/udev/rules.d/90-udisks2- zram.rules'. Yannick -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.4 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_GB Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages udisks2 depends on: ii dbus 1.12.20-1 ii libacl12.2.53-8 ii libatasmart4 0.19-5 ii libblockdev-fs22.24-2 ii libblockdev-loop2 2.24-2 ii libblockdev-part2 2.24-2 ii libblockdev-swap2 2.24-2 ii libblockdev-utils2 2.24-2 ii libblockdev2 2.24-2 ii libc6 2.31-3 ii libglib2.0-0 2.64.4-1 ii libgudev-1.0-0 233-1 ii libmount1 2.36-2 ii libpam-systemd 246.2-1 ii libpolkit-agent-1-00.105-29 ii libpolkit-gobject-1-0 0.105-29 ii libsystemd0246.2-1 ii libudisks2-0 2.9.1-1 ii libuuid1 2.36-2 ii parted 3.3-4 ii udev 246.2-1 Versions of packages udisks2 recommends: ii dosfstools 4.1-2 ii e2fsprogs1.45.6-1 ii eject2.36-2 ii exfat-utils 1.3.0-2 ii libblockdev-crypto2 2.24-2 ii ntfs-3g 1:2017.3.23AR.3-3 ii policykit-1 0.105-29 Versions of packages udisks2 suggests: ii btrfs-progs 5.7-1 ii f2fs-tools 1.11.0-1.1 ii libblockdev-mdraid2 2.24-2 ii mdadm4.1-5 pn nilfs-tools pn reiserfsprogs ii udftools 2.2-1 pn udisks2-bcache iu udisks2-btrfs2.9.1-1 pn udisks2-lvm2 iu udisks2-zram 2.9.1-1 pn xfsprogs -- no debconf information -- If A = B and B = C, then A = C, except where void or prohibited by law. -- Roy Santoro
Bug#969093: Newer upstream version of its-playback-time
Package: its-playback-time Version: 0.2017-08-30.3c40fd3-1 The upstream source had a series of bugfixes from the Crawl developers: https://www.chiark.greenend.org.uk/~sgtatham/ipbt/ipbt-20190601.d1519e0.tar.gz Please can we have them in Debian? Thanks. This is pretty terse for a bug report but I don't really have anything else to say.
Bug#969092: spoa: Either FTBFS or baseline violation on all architectures
Source: spoa Version: 3.4.0+ds-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=spoa=3.4.0%2Bds-1 Please disable spoa_optimize_for_native again.
Bug#969091: pdns-backend-mysql: Queries calling stored procedures broken with recent MariaDB/MySQL
Package: pdns-backend-mysql
Version: 4.3.0-4+b3
Severity: important
Tags: upstream
X-Debbugs-Cc: x...@charbonnet.com
Dear Maintainer,
PowerDNS supports using stored procedures for its backend MySQL queries.
However, it seems
that when the database is MariaDB >= 10.2 (or MySQL >= 5.7), stored procedures
fail to work.
I have tested this on Stretch, using three different PowerDNS versions: 4.0.3
(from Stretch),
4.1.6 (from Buster), and 4.3.0 (from Bullseye), all compiled on Stretch. They
all have the
same behavior: on MariaDB 10.1, stored procedures work great. On MariaDB 10.2,
calls to
procedures which return any rows give the error "Could not bind parameters to
mysql
statement". The various versions of MariaDB came from the MariaDB Debian
repositories.
I have also tried this on a clean Bullseye test system, using the versions of
PowerDNS and
MariaDB which are native to Bullseye. Same problem. This is the system where
I'm running
reportbug.
I believe this other user on the pdns mailing list encountered this problem:
https://mailman.powerdns.com/pipermail/pdns-users/2020-July/026762.html
My reply failed to actually be a reply, but I also chimed in on the list:
https://mailman.powerdns.com/pipermail/pdns-users/2020-August/026810.html
The relevant code appears to be the following section. Unfortunately I don't
know enough
about using MySQL from C++ to be able to tell what to do differently. This is
where the
"Could not bind parameters" error is coming from.
#if MYSQL_VERSION_ID >= 50500
if (d_residx >= d_resnum) {
mysql_stmt_free_result(d_stmt);
while(!mysql_stmt_next_result(d_stmt)) {
if ((err = mysql_stmt_store_result(d_stmt))) {
string error(mysql_stmt_error(d_stmt));
releaseStatement();
throw SSqlException("Could not store mysql statement while
processing additional sets: " + d_query + string(": ") + error);
}
d_resnum = mysql_stmt_num_rows(d_stmt);
// XXX: For some reason mysql_stmt_result_metadata returns
NULL here, so we cannot
// ensure row field count matches first result set.
if (d_resnum > 0) { // ignore empty result set
if (d_res_bind != nullptr && (err =
mysql_stmt_bind_result(d_stmt, d_res_bind))) {
string error(mysql_stmt_error(d_stmt));
releaseStatement();
throw SSqlException("Could not bind parameters to mysql
statement: " + d_query + string(": ") + error);
}
d_residx = 0;
break;
}
mysql_stmt_free_result(d_stmt);
}
}
#endif
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 pdns-backend-mysql depends on:
ii libc62.31-2
ii libgcc-s110.1.0-6
ii libmariadb3 1:10.3.23-1
ii libstdc++6 10.1.0-6
ii pdns-server 4.3.0-4+b3
pdns-backend-mysql recommends no packages.
Versions of packages pdns-backend-mysql suggests:
pn default-mysql-server
-- no debconf information
Bug#969090: virtualbox-5.2: Installation of Debian's bullseye alpha2 version freezes
Package: virtualbox-5.2 Version: 5.2.34-133893~Ubuntu~bionic Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What exactly did you do (or not do) that was effective (or ineffective)? >> after selecting the 'install' option, installation freezes with the error message "kernel panic - not syncing: Attempt to kill init!" * What was the outcome of this action? >> none, installation freezes * What outcome did you expect instead? >> installation not to freeze *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virtualbox-5.2 depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libcurl4 7.64.0-4+deb10u1 ii libdevmapper1.02.1 2:1.02.155-3 ii libgcc11:8.3.0-6 ii libgl1 1.1.0-1 ii libopus0 1.3-1 ii libpng16-161.6.36-6 ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 ii libqt5gui5 5.11.3+dfsg1-1+deb10u3 ii libqt5opengl5 5.11.3+dfsg1-1+deb10u3 ii libqt5printsupport55.11.3+dfsg1-1+deb10u3 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u3 ii libqt5x11extras5 5.11.3-2 ii libsdl1.2debian1.2.15+dfsg2-4 ii libssl1.1 1.1.1d-0+deb10u3 ii libstdc++6 8.3.0-6 ii libvpx51.7.0-3+deb10u1 ii libx11-6 2:1.6.7-1 ii libxcb11.13.1-2 ii libxcursor11:1.1.15-2 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.4-2 ii libxml22.9.4+dfsg1-7+b3 ii libxmu62:1.1.2-2+b3 ii libxt6 1:1.1.5-1+b3 ii psmisc 23.2-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages virtualbox-5.2 recommends: ii atril [pdf-viewer] 1.20.3-1+deb10u1 ii binutils 2.31.1-16 ii gcc 4:8.3.0-1 ii kmod 26-1 ii libasound2 1.1.8-1 ii libpulse012.2-4+deb10u1 ii libsdl-ttf2.0-0 2.0.11-6 ii linux-headers-amd64 4.19+105+deb10u5 pn linux-image ii make 4.2.1-1.2 virtualbox-5.2 suggests no packages. -- debconf information: virtualbox/old-installation-found: virtualbox/module-compilation-failed: virtualbox/old-running: virtualbox/group-vboxusers:
Bug#969088: ITP: esdm -- Earth System Data Middleware for earth system simulation
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: esdm Version : 0.1.0 Upstream Author : Julian Kunkel * URL : https://github.com/ESiWACE/esdm * License : GPL Programming Lang: C Description : Earth System Data Middleware for earth system simulation The middleware for earth system data is a prototype to improve I/O performance for earth system simulation as used in climate and weather applications. ESDM exploits structural information exposed by workflows, applications as well as data description formats such as HDF5 and NetCDF to more efficiently organize metadata and data across a variety of storage backends. It is planned to maintain this within the Debian Science team; it is a growing piece of "expected functionality" on systems running climate models.
Bug#969087: lightdm-settings: does not open
Package: lightdm-settings Version: 1.4.2+dfsg.1-1 Severity: important Dear Maintainer, I've tried to open lightdm-settings from the applications menu as well as from a terminal (`$ gksudo lightdm-settings`). I'm prompted for a password, but the application never shows up afterwards. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (400, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 5.7.0-2-686 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.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 lightdm-settings depends on: ii python3 3.8.2-3 ii python3-setproctitle 1.1.10-2 ii python3-xapp 2.0.1-2 lightdm-settings recommends no packages. lightdm-settings suggests no packages. -- no debconf information
Bug#969084: buildd.d.o: please don't use a tainted buildenv
On Thu, 2020-08-27 at 13:06:56 +, Holger Levsen wrote: > On Thu, Aug 27, 2020 at 03:00:43PM +0200, Aurelien Jarno wrote: > > On 2020-08-27 13:25, Holger Levsen wrote: > > > Package: buildd.debian.org > > > Severity: wishlist > > > User: reproducible-bui...@lists.alioth.debian.org > > > Usertags: environment > > > since a while dpkg adds a small note to a .buildinfo if /usr/local/sbin > > > is populated (which I'm not sure I agree is sensible, but it's what dpkg > > > currently does), eg > > > > > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > > > rgrep Build-Tainted-By: 08/ |wc -l > > > 35473 > > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > > > find 08 -name "*.buildinfo" | wc -l > > > 37182 > > > > > > so almost all .buildinfo files from August 2020 are tainted. > > > > > > (profitbricks7 is hosting https://buildinfos.debian.net if you want to > > > check > > > for yourself easily.) > > > > > > So how are they tainted: > > > > > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > > > grep -A 2 Build-Tainted-By: > > > 08/06/firejail_0.9.62-4_ppc64el-buildd.buildinfo > > > Build-Tainted-By: > > > usr-local-has-programs > > > Installed-Build-Depends: > > > > > > > > > And then, also, not all .buildinfo files are taited by > > > "usr-local-has-programs" because > > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > > > rgrep usr-local-has-programs 08/ |wc -l > > > 35017 > > > > > > (But I guess that's probably material for another bug report.) > > > > > > Any chance the Debian buildds could not have a tained /usr/local? > > > > The only file in /usr/local is /usr/local/sbin/policy-rc.d which is > > needed to prevent daemons to start in the chroot. Not sure how we can do > > things differently. > > thanks for that info! maybe dpkg could treat /usr/local not as tainted if the > only file in /usr/local is /usr/local/sbin/policy-rc.d ? While we could perhaps add an exception in the Debian vendor profile. It does look like this is working as intended? :) This is a local file that might affect the build, which is otherwise not trackable, say what "version" (with which changes) was being used, etc. I think ideally this would be using a system pathname and be part of a package that gets then listed in the .buildinfo files. Thanks, Guillem
Bug#961663: Firefox ESR crashes on pre-SSE2 CPUs
On Wed, 27 May 2020 15:42:43 +0200 Frank wrote: > Package: firefox-esr > Version: 68.8.0esr-1~deb10u1 > Severity: important > > Firefox ESR (i386) crashes on pre-SSE2 CPUs when visiting certain > websites such as xfce-look.org. > As far as I understand Debian stretch/buster firefox-esr package should > support processors without SSE2. > Older versions of the firefox-esr package had similar issues and were > (apparently) fixed. https://wiki.debian.org/SIMDEverywhere might be helpful in developing a patch, if it isn't just a compiler flag fix -- Michael R. Crusoe signature.asc Description: OpenPGP digital signature
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
X-Debbugs-Cc: Osamu Aoki On Wed, Aug 26, 2020 at 04:51:33PM +0800, Dan Jacobson wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: 968...@bugs.debian.org > > * Package name: getmail6 > Version : 6.4 > Upstream Author : roland.punta...@gmail.com > * URL : https://github.com/getmail6 > * License : GNU GPL version 2 > Programming Lang: Python > Description : Mail retriever with support for POP3, IMAP4 and SDPS > > getmail is intended as a simple replacement for fetchmail. It retrieves mail > (either all messages, or only unread messages) from one or more > POP3/IMAP4/SDPS servers for one or more email accounts, and reliably > delivers into a qmail-style Maildir, mbox file or to a command (pipe > delivery) like maildrop or procmail, specified on a per-account basis. > getmail also has support for domain (multidrop) mailboxes. > > The current getmail package only works with python2. > > But debian has moved to python3. > > Therefore getmail6, which is designed to work with python3, should be > added to Debian. > > No need to update the current debian getmail package. > Just somebody should maintain a new independent getmail6 pacakge. This getmail6 will install files like: /usr/bin/getmail /usr/bin/getmail_fetch /usr/bin/getmail_mbox /usr/bin/getmail_maildir /usr/bin/getmail-gmail-xoauth-tokens /usr/lib/python3/dist-packages/getmailcore which are also installed by getmail. So, I guess the best possible way might be if getmail maintainer updates to this source, else I can package getmail6 with a "Breaks: getmail". -- Regards Sudip
Bug#969080: orthanc: error in systemd unit file
Package: orthanc Version: 1.7.3+dfsg-1 Severity: normal Dear Maintainer, the systemd unit file shipped in orthanc: /lib/systemd/system/orthanc.service contains the following line: Documentation=man orthanc(8) https://book.orthanc-server.com/index.html which according to systemd is incorrect: # journalctl |grep orthanc [...] /lib/systemd/system/orthanc.service:3: Invalid URL, ignoring: man /lib/systemd/system/orthanc.service:3: Invalid URL, ignoring: orthanc(8) -- 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) -- Laurent.
Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x
Gianfranco Costamagna writes ("Bug#968734: chiark-tcl: FTBFS with optimization
level -O3 and gcc-10 on s390x"):
> Hello, this worked too!
Thanks for checking. I hope to upload this at some point soon.
Ian.
Bug#969084: buildd.d.o: please don't use a tainted buildenv
hi, adding Guillem to the loop (and preserving a full quote for him). On Thu, Aug 27, 2020 at 03:00:43PM +0200, Aurelien Jarno wrote: > Hi, > > On 2020-08-27 13:25, Holger Levsen wrote: > > Package: buildd.debian.org > > Severity: wishlist > > User: reproducible-bui...@lists.alioth.debian.org > > Usertags: environment > > > > Dear buildd maintainers, > > > > since a while dpkg adds a small note to a .buildinfo if /usr/local/sbin > > is populated (which I'm not sure I agree is sensible, but it's what dpkg > > currently does), eg > > > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > > rgrep Build-Tainted-By: 08/ |wc -l > > 35473 > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > > find 08 -name "*.buildinfo" | wc -l > > 37182 > > > > so almost all .buildinfo files from August 2020 are tainted. > > > > (profitbricks7 is hosting https://buildinfos.debian.net if you want to check > > for yourself easily.) > > > > So how are they tainted: > > > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > > grep -A 2 Build-Tainted-By: > > 08/06/firejail_0.9.62-4_ppc64el-buildd.buildinfo > > Build-Tainted-By: > > usr-local-has-programs > > Installed-Build-Depends: > > > > > > And then, also, not all .buildinfo files are taited by > > "usr-local-has-programs" because > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > > rgrep usr-local-has-programs 08/ |wc -l > > 35017 > > > > (But I guess that's probably material for another bug report.) > > > > Any chance the Debian buildds could not have a tained /usr/local? > > The only file in /usr/local is /usr/local/sbin/policy-rc.d which is > needed to prevent daemons to start in the chroot. Not sure how we can do > things differently. thanks for that info! maybe dpkg could treat /usr/local not as tainted if the only file in /usr/local is /usr/local/sbin/policy-rc.d ? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Bug#969084: buildd.d.o: please don't use a tained buildenv
Hi, On 2020-08-27 13:25, Holger Levsen wrote: > Package: buildd.debian.org > Severity: wishlist > User: reproducible-bui...@lists.alioth.debian.org > Usertags: environment > > Dear buildd maintainers, > > since a while dpkg adds a small note to a .buildinfo if /usr/local/sbin > is populated (which I'm not sure I agree is sensible, but it's what dpkg > currently does), eg > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > rgrep Build-Tainted-By: 08/ |wc -l > 35473 > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > find 08 -name "*.buildinfo" | wc -l > 37182 > > so almost all .buildinfo files from August 2020 are tainted. > > (profitbricks7 is hosting https://buildinfos.debian.net if you want to check > for yourself easily.) > > So how are they tainted: > > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > grep -A 2 Build-Tainted-By: 08/06/firejail_0.9.62-4_ppc64el-buildd.buildinfo > Build-Tainted-By: > usr-local-has-programs > Installed-Build-Depends: > > > And then, also, not all .buildinfo files are taited by > "usr-local-has-programs" because > holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ > rgrep usr-local-has-programs 08/ |wc -l > 35017 > > (But I guess that's probably material for another bug report.) > > Any chance the Debian buildds could not have a tained /usr/local? The only file in /usr/local is /usr/local/sbin/policy-rc.d which is needed to prevent daemons to start in the chroot. Not sure how we can do things differently. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#969085: nvidia-legacy-390xx-kernel-dkms: fails to build against 5.8.x kernel due to nvidia-uvm module license
Package: nvidia-legacy-390xx-kernel-dkms Version: 390.138-1 Severity: important Tags: upstream Dear Maintainer, kernel 5.8.x made 'radix_tree_preloads' GPL-only: the build of the nvidia-uvm, which is MIT licensed, fails at modpost making the whole dkms build process fail. Thanks
Bug#950646: sane-utils: saned does not work if starteed via systemd
Thank you for the additional information. This gives me an additional error: aug 27 14:09:01 eaze saned[6203]: [plustek] sanei_usb_open failed: Permission denied (13) aug 27 14:09:01 eaze saned[6203]: [plustek] open failed: -1 See also the attached log file. aug 27 14:09:01 eaze saned[6203]: [sanei_debug] Setting debug level of plustek to 12. aug 27 14:09:01 eaze saned[6203]: [plustek] Plustek backend V0.52-12, part of sane-backends 1.0.27 aug 27 14:09:01 eaze saned[6203]: [plustek] Retrieving all supported and conntected devices aug 27 14:09:01 eaze saned[6203]: [plustek] Available and supported devices: aug 27 14:09:01 eaze saned[6203]: [plustek] NONE. aug 27 14:09:01 eaze saned[6203]: [plustek] ># Plustek-SANE Backend configuration file< aug 27 14:09:01 eaze saned[6203]: [plustek] ># For use with LM9831/2/3 based USB scanners< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] >< aug 27 14:09:01 eaze saned[6203]: [plustek] ># each device needs at least two lines:< aug 27 14:09:01 eaze saned[6203]: [plustek] ># - [usb] vendor-ID and product-ID< aug 27 14:09:01 eaze saned[6203]: [plustek] ># - device devicename< aug 27 14:09:01 eaze saned[6203]: [plustek] ># i.e. for Plustek (0x07B3) UT12/16/24 (0x0017)< aug 27 14:09:01 eaze saned[6203]: [plustek] ># [usb] 0x07B3 0x0017< aug 27 14:09:01 eaze saned[6203]: [plustek] ># device /dev/usbscanner< aug 27 14:09:01 eaze saned[6203]: [plustek] ># or< aug 27 14:09:01 eaze saned[6203]: [plustek] ># device libusb:bbb:ddd< aug 27 14:09:01 eaze saned[6203]: [plustek] ># where bbb is the busnumber and ddd the device number< aug 27 14:09:01 eaze saned[6203]: [plustek] ># make sure that your user has access to /proc/bus/usb/bbb/ddd< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] ># additionally you can specify some options< aug 27 14:09:01 eaze saned[6203]: [plustek] ># warmup, lOffOnEnd, lampOff< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] ># For autodetection use< aug 27 14:09:01 eaze saned[6203]: [plustek] ># [usb]< aug 27 14:09:01 eaze saned[6203]: [plustek] ># device /dev/usbscanner< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] ># or simply< aug 27 14:09:01 eaze saned[6203]: [plustek] ># [usb]< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] ># or if you want a specific device but you have no idea about the< aug 27 14:09:01 eaze saned[6203]: [plustek] ># device node or you use libusb, simply set vendor- and product-ID< aug 27 14:09:01 eaze saned[6203]: [plustek] ># [usb] 0x07B3 0x0017< aug 27 14:09:01 eaze saned[6203]: [plustek] ># device auto< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] ># NOTE: autodetection is safe, as it uses the info it got< aug 27 14:09:01 eaze saned[6203]: [plustek] ># from the USB subsystem. If you're not using the< aug 27 14:09:01 eaze saned[6203]: [plustek] ># autodetection, you MUST have attached that device< aug 27 14:09:01 eaze saned[6203]: [plustek] ># at your USB-port, that you have specified...< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] >< aug 27 14:09:01 eaze saned[6203]: [plustek] >[usb]< aug 27 14:09:01 eaze saned[6203]: [plustek] next device uses autodetection aug 27 14:09:01 eaze saned[6203]: [plustek] ... next device aug 27 14:09:01 eaze saned[6203]: [plustek] >< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] ># options for the previous USB entry< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]: [plustek] ># switch lamp off after xxx secs, 0 disables the feature< aug 27 14:09:01 eaze saned[6203]: [plustek] ># (can also be set via frontend)< aug 27 14:09:01 eaze saned[6203]: [plustek] >option lampOff 300< aug 27 14:09:01 eaze saned[6203]: [plustek] Decoding option >lampOff< aug 27 14:09:01 eaze saned[6203]: [plustek] >< aug 27 14:09:01 eaze saned[6203]: [plustek] ># warmup period in seconds, 0 means no warmup, -1 means auto-warmup< aug 27 14:09:01 eaze saned[6203]: [plustek] ># (can also be set via frontend)< aug 27 14:09:01 eaze saned[6203]: [plustek] >option warmup -1< aug 27 14:09:01 eaze saned[6203]: [plustek] Decoding option >warmup< aug 27 14:09:01 eaze saned[6203]: [plustek] >< aug 27 14:09:01 eaze saned[6203]: [plustek] ># 0 means leave lamp-status untouched, not 0 means switch off< aug 27 14:09:01 eaze saned[6203]: [plustek] ># on sane_close< aug 27 14:09:01 eaze saned[6203]: [plustek] ># (can also be set via frontend)< aug 27 14:09:01 eaze saned[6203]: [plustek] >option lOffOnEnd 1< aug 27 14:09:01 eaze saned[6203]: [plustek] Decoding option >lOffOnEnd< aug 27 14:09:01 eaze saned[6203]: [plustek] >< aug 27 14:09:01 eaze saned[6203]: [plustek] >#< aug 27 14:09:01 eaze saned[6203]:
Bug#969079: [Pkg-phototools-devel] Bug#969079: darktable: edits are not saved
Steven O'Connor writes: Control: tag -1 unreproducible > Package: darktable > Version: 3.2.1-2+b1 > Severity: important > X-Debbugs-Cc: slack...@gmail.com > > Dear Maintainer, > > When I crop a photo and go to lightbox the cropping is lost, I have tried > Ctl-e > from darkroom but the export is an uncropped image. > > I think this problem started with the upgrade to 3.2.1. > > I have tried deleting the database and config but this hasn't help. Hi Stephen; I can't duplicate the problem here. If you have a photo file that shows this problem, and is less than 10MB in size, please attach to the bug report (a standard MIME attachment in a reply should work). d
Bug#969084: buildd.d.o: please don't use a tained buildenv
Package: buildd.debian.org Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: environment Dear buildd maintainers, since a while dpkg adds a small note to a .buildinfo if /usr/local/sbin is populated (which I'm not sure I agree is sensible, but it's what dpkg currently does), eg holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ rgrep Build-Tainted-By: 08/ |wc -l 35473 holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ find 08 -name "*.buildinfo" | wc -l 37182 so almost all .buildinfo files from August 2020 are tainted. (profitbricks7 is hosting https://buildinfos.debian.net if you want to check for yourself easily.) So how are they tainted: holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ grep -A 2 Build-Tainted-By: 08/06/firejail_0.9.62-4_ppc64el-buildd.buildinfo Build-Tainted-By: usr-local-has-programs Installed-Build-Depends: And then, also, not all .buildinfo files are taited by "usr-local-has-programs" because holger@profitbricks-build7-amd64:~jenkins/userContent/reproducible/debian/ftp-master.debian.org/buildinfo/2020$ rgrep usr-local-has-programs 08/ |wc -l 35017 (But I guess that's probably material for another bug report.) Any chance the Debian buildds could not have a tained /usr/local? Thanks for maintaining all these buildds! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C "There's no glory in prevention." (Christian Drosten) signature.asc Description: PGP signature
Bug#969083: unblock: libomxil-bellagio/0.9.3-6
Hi Sebastian, gst-omx and libomxil-bellagio0 doesn't have strong dependencies. libomxil-bellagio0 can be a "plugin" of gst-omx. That means gst-omx can be run by itself without libomxil-bellagio0 at all. The problem happens in autopkgtest. In test, we use libomxil-bellagio0 as a plugin to test gst-omx. Thus gst-omx originally loads that plugin (in debian/tests scripts) from /usr/lib. But now it needs to load that plugin through test scripts from multi-arch path. Yours, Paul Sebastian Ramacher 於 2020/8/27 下午7:14 寫道: > Control: tags -1 + moreinfo > > On 2020-08-27 18:00:15, Ying-Chun Liu (PaulLiu) wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> >> Please unblock package libomxil-bellagio >> >> [ Reason ] >> >> libomxil-bellagio changes the library path to multi-arch. >> >> gst-omx will use the library for autopkgtest. So newer gst-omx loads the >> library >> >> from multi-arch path. And thus failed to pass the test for older >> libomxil-bellagio. > This sounds a lot like missing Breaks and versioned dependencies: > libomxil-bellagio0 needs Breaks on the gst-omx packages that ship the > config with the hard-coded path. > > At the same time, gst-omx does not seem to work with libomxil-bellagio > currently in testing. So this will also need versioned dependencies on a > sufficently high version of libomxil-bellagio0. And if those packages > require the shared library, why aren't the depending on it in the first > place? > > But overall, the missing Breaks and Depends seem like a real issue that > would also break the packages in partial buster -> bullseye upgrade > scenarios. > > Best > >> >> We should unblock libomxil-bellagio, and thus newer gst-omx should also >> pass all the debci tests later and automatically migrate. >> >> >> [ Impact ] >> libomxil-bellagio remains using old non-multiarch library path. >> >> [ Tests ] >> gst-omx/1.16.2-1 tests ok with libomxil-bellagio/0.9.3-6. >> It just failed with older libomxil-bellagio. >> >> [ Risks ] >> Should have no risks. autopkgtest already passed on the latest version >> of each 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 >> >> unblock libomxil-bellagio/0.9.3-6 >> >> diff -Nru libomxil-bellagio-0.9.3/debian/changelog >> libomxil-bellagio-0.9.3/debian/changelog >> --- libomxil-bellagio-0.9.3/debian/changelog 2018-09-23 03:56:46.0 >> +0800 >> +++ libomxil-bellagio-0.9.3/debian/changelog 2020-08-12 15:16:26.0 >> +0800 >> @@ -1,3 +1,25 @@ >> +libomxil-bellagio (0.9.3-6) unstable; urgency=low >> + >> + * Use linktrees instead of links. >> + >> + -- Ying-Chun Liu (PaulLiu) Wed, 12 Aug 2020 15:16:26 >> +0800 >> + >> +libomxil-bellagio (0.9.3-5) unstable; urgency=low >> + >> + * Multi-arch support >> + - Move libs to multiarch path (Closes: #928847) >> + - Add Multi-Arch foreign to -doc package. (Closes: #949568) >> + * Bump Standards-Version to 4.5.0: Nothing needs to be changed. >> + * Bump debhelper compat to 11 >> +- Remove Build-Depends on autotools-dev and dh-autoreconf >> +- Add debian/patches/0014_fix_hardening.patch: fix hardening error >> + * Remove Vcs-Git and Vcs-Browser field >> + * Remove *-dbg packages. Now we have -dbgsym packages. (Closes: #620832) >> + * Add debian/patches/0015_port_gcc_10.patch: port to gcc 10. >> +- (Closes: #957453) >> + >> + -- Ying-Chun Liu (PaulLiu) Sun, 09 Aug 2020 15:48:03 >> +0800 >> + >> libomxil-bellagio (0.9.3-4.1) unstable; urgency=medium >> >>* Non-maintainer upload. >> diff -Nru libomxil-bellagio-0.9.3/debian/clean >> libomxil-bellagio-0.9.3/debian/clean >> --- libomxil-bellagio-0.9.3/debian/clean 1970-01-01 08:00:00.0 >> +0800 >> +++ libomxil-bellagio-0.9.3/debian/clean 2020-08-09 15:48:03.0 >> +0800 >> @@ -0,0 +1 @@ >> +debian/libomxil-bellagio-bin.triggers >> diff -Nru libomxil-bellagio-0.9.3/debian/compat >> libomxil-bellagio-0.9.3/debian/compat >> --- libomxil-bellagio-0.9.3/debian/compat2016-11-13 02:59:37.0 >> +0800 >> +++ libomxil-bellagio-0.9.3/debian/compat2020-08-09 15:48:03.0 >> +0800 >> @@ -1 +1 @@ >> -8 >> +11 >> diff -Nru libomxil-bellagio-0.9.3/debian/control >> libomxil-bellagio-0.9.3/debian/control >> --- libomxil-bellagio-0.9.3/debian/control 2016-11-13 04:44:17.0 >> +0800 >> +++ libomxil-bellagio-0.9.3/debian/control 2020-08-12 15:16:26.0 >> +0800 >> @@ -2,12 +2,16 @@ >> Section: libs >> Priority: optional >> Maintainer: Ying-Chun Liu (PaulLiu) >> -Build-Depends: debhelper (>= 8), dh-autoreconf, >> - autotools-dev, libasound2-dev, libmad0-dev, libvorbis-dev, >> - doxygen, libjs-jquery >> -Standards-Version: 3.9.8 >> -Vcs-Browser: http://git.debian.org/?p=collab-maint/libomxil-bellagio.git >> -Vcs-Git:
Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x
Hello, this worked too!
thanks
G.
Il giovedì 20 agosto 2020, 20:19:37 CEST, Ian Jackson
ha scritto:
Hi. Thanks for the report.
Gianfranco Costamagna writes ("Bug#968734: chiark-tcl: FTBFS with optimization
level -O3 and gcc-10 on s390x"):
> Hello, In Ubuntu the package FTBFS on s390x, because of -O3, and some non
> initialized variables.
How odd.
> This makes no sense, because the variables are passed by reference
> to the functions, but gcc is probably not smart enough to detect it.
I think it is more likely that it can see into blockcipher_prep, but
not follow the control flow. Perhaps, for example, it doesn't know
that cht_staticerr always returns nonzero, and it thinks that those
error paths in blockcipher_prep might end up using the values in the
caller.
Instead of your suggestion, if you can easily do so, can you try
this ?
Regards,
Ian.
>From 020f536563e566c6a17eeb790d2a5e56141e2b74 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Thu, 20 Aug 2020 19:18:14 +0100
Subject: [PATCH] blockcipher_prep: Initialise out parameters to placate gcc
These are all set on the success exit path but GCC is not clever
enough to see this.
Closes: #968734
Signed-off-by: Ian Jackson
---
crypto/crypto.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/crypto.c b/crypto/crypto.c
index aee2556..6efea24 100644
--- a/crypto/crypto.c
+++ b/crypto/crypto.c
@@ -252,6 +252,14 @@ static int blockcipher_prep(Tcl_Interp *ip, Tcl_Obj
*key_obj,
int rc;
CiphKeyValue *key;
+ /* placate gcc, see Debian #968734 */
+ *key_r= 0;
+ *sched_r= 0;
+ *iv_r= 0;
+ *iv_lenbytes_r= 0;
+ *buffers_r= 0;
+ *nblocks_r= 0;
+
if (data_len % alg->blocksize)
return cht_staticerr(ip, "block cipher input not whole number of blocks",
"HBYTES BLOCKCIPHER LENGTH");
--
2.20.1
Bug#969083: unblock: libomxil-bellagio/0.9.3-6
Control: tags -1 + moreinfo
On 2020-08-27 18:00:15, Ying-Chun Liu (PaulLiu) wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
>
> Please unblock package libomxil-bellagio
>
> [ Reason ]
>
> libomxil-bellagio changes the library path to multi-arch.
>
> gst-omx will use the library for autopkgtest. So newer gst-omx loads the
> library
>
> from multi-arch path. And thus failed to pass the test for older
> libomxil-bellagio.
This sounds a lot like missing Breaks and versioned dependencies:
libomxil-bellagio0 needs Breaks on the gst-omx packages that ship the
config with the hard-coded path.
At the same time, gst-omx does not seem to work with libomxil-bellagio
currently in testing. So this will also need versioned dependencies on a
sufficently high version of libomxil-bellagio0. And if those packages
require the shared library, why aren't the depending on it in the first
place?
But overall, the missing Breaks and Depends seem like a real issue that
would also break the packages in partial buster -> bullseye upgrade
scenarios.
Best
>
>
> We should unblock libomxil-bellagio, and thus newer gst-omx should also
> pass all the debci tests later and automatically migrate.
>
>
> [ Impact ]
> libomxil-bellagio remains using old non-multiarch library path.
>
> [ Tests ]
> gst-omx/1.16.2-1 tests ok with libomxil-bellagio/0.9.3-6.
> It just failed with older libomxil-bellagio.
>
> [ Risks ]
> Should have no risks. autopkgtest already passed on the latest version
> of each 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
>
> unblock libomxil-bellagio/0.9.3-6
>
> diff -Nru libomxil-bellagio-0.9.3/debian/changelog
> libomxil-bellagio-0.9.3/debian/changelog
> --- libomxil-bellagio-0.9.3/debian/changelog 2018-09-23 03:56:46.0
> +0800
> +++ libomxil-bellagio-0.9.3/debian/changelog 2020-08-12 15:16:26.0
> +0800
> @@ -1,3 +1,25 @@
> +libomxil-bellagio (0.9.3-6) unstable; urgency=low
> +
> + * Use linktrees instead of links.
> +
> + -- Ying-Chun Liu (PaulLiu) Wed, 12 Aug 2020 15:16:26
> +0800
> +
> +libomxil-bellagio (0.9.3-5) unstable; urgency=low
> +
> + * Multi-arch support
> + - Move libs to multiarch path (Closes: #928847)
> + - Add Multi-Arch foreign to -doc package. (Closes: #949568)
> + * Bump Standards-Version to 4.5.0: Nothing needs to be changed.
> + * Bump debhelper compat to 11
> +- Remove Build-Depends on autotools-dev and dh-autoreconf
> +- Add debian/patches/0014_fix_hardening.patch: fix hardening error
> + * Remove Vcs-Git and Vcs-Browser field
> + * Remove *-dbg packages. Now we have -dbgsym packages. (Closes: #620832)
> + * Add debian/patches/0015_port_gcc_10.patch: port to gcc 10.
> +- (Closes: #957453)
> +
> + -- Ying-Chun Liu (PaulLiu) Sun, 09 Aug 2020 15:48:03
> +0800
> +
> libomxil-bellagio (0.9.3-4.1) unstable; urgency=medium
>
>* Non-maintainer upload.
> diff -Nru libomxil-bellagio-0.9.3/debian/clean
> libomxil-bellagio-0.9.3/debian/clean
> --- libomxil-bellagio-0.9.3/debian/clean 1970-01-01 08:00:00.0
> +0800
> +++ libomxil-bellagio-0.9.3/debian/clean 2020-08-09 15:48:03.0
> +0800
> @@ -0,0 +1 @@
> +debian/libomxil-bellagio-bin.triggers
> diff -Nru libomxil-bellagio-0.9.3/debian/compat
> libomxil-bellagio-0.9.3/debian/compat
> --- libomxil-bellagio-0.9.3/debian/compat 2016-11-13 02:59:37.0
> +0800
> +++ libomxil-bellagio-0.9.3/debian/compat 2020-08-09 15:48:03.0
> +0800
> @@ -1 +1 @@
> -8
> +11
> diff -Nru libomxil-bellagio-0.9.3/debian/control
> libomxil-bellagio-0.9.3/debian/control
> --- libomxil-bellagio-0.9.3/debian/control2016-11-13 04:44:17.0
> +0800
> +++ libomxil-bellagio-0.9.3/debian/control2020-08-12 15:16:26.0
> +0800
> @@ -2,12 +2,16 @@
> Section: libs
> Priority: optional
> Maintainer: Ying-Chun Liu (PaulLiu)
> -Build-Depends: debhelper (>= 8), dh-autoreconf,
> - autotools-dev, libasound2-dev, libmad0-dev, libvorbis-dev,
> - doxygen, libjs-jquery
> -Standards-Version: 3.9.8
> -Vcs-Browser: http://git.debian.org/?p=collab-maint/libomxil-bellagio.git
> -Vcs-Git: git://git.debian.org/git/collab-maint/libomxil-bellagio.git
> +Build-Depends: debhelper (>= 11),
> + dh-exec,
> + dh-linktree,
> + doxygen,
> + libasound2-dev,
> + libjs-jquery,
> + libmad0-dev,
> + libvorbis-dev,
> + node-jquery
> +Standards-Version: 4.5.0
> Homepage: http://sourceforge.net/projects/omxil/
>
> Package: libomxil-bellagio0
> @@ -15,7 +19,7 @@
> Suggests: libomxil-bellagio0-components-base
> Architecture: any
> Section: libs
> -Depends: ${shlibs:Depends}, ${misc:Depends}
> +Depends: ${misc:Depends}, ${shlibs:Depends}
>
Bug#961345: cups: daemon crashes with invalid free()
Bernhard Übelacker wrote on 27/08/2020 12:00:
> unfortunately I don't have any pointers on that httpAddrGetList.
>
> So you were able to build a package?
Yes, I patched out the fail (typo included for free):
Index: cups-2.3.3/cups/testhttp.c
===
--- cups-2.3.3.orig/cups/testhttp.c 2020-04-27 18:04:29.0 +
+++ cups-2.3.3/cups/testhttp.c 2020-08-27 10:48:23.991753579 +
@@ -416,8 +416,10 @@
}
else
{
- failures ++;
- puts("FAIL");
+ // Comment out the following failure as something in
+ // cowbuilder causes it to fail
+ //failures ++;
+ puts("FAIL (ignored because user of cowbuilder results in a fail");
}
/*
:-).
I'll install the patched packages outside of office hours and give them a test.
I might be able to do this today, otherwise it will be first thing in the
morning.
> One additional note: I guess with "quilt refresh" any new changes
> get added to the last patch. A 'dpkg-source --commit' would create a
> new separate patch file.
I figured out creating new patches with quilt eventually. :-). This page was
most useful:
https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com
Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957
signature.asc
Description: OpenPGP digital signature
Bug#961345: cups: daemon crashes with invalid free()
Hello Ronny, unfortunately I don't have any pointers on that httpAddrGetList. So you were able to build a package? One additional note: I guess with "quilt refresh" any new changes get added to the last patch. A 'dpkg-source --commit' would create a new separate patch file. Kind regards, Bernhard
Bug#959828: docker-systemctl-replacement
Hi Simon and Dmitry, Thank you for chiming in, Simon. On Thu, Aug 27, 2020 at 09:34:04AM +0100, Simon McVittie wrote: > https://packages.debian.org/sid/opentmpfiles is one known implementation > of the tmpfiles.d interface, other than systemd's. (See also #947847.) Great! > If the systemd maintainers are willing to split out systemd-tmpfiles > from the systemd binary package, that would be another possible > implementation to use in containers where the Installed-Size of systemd > is not desired. It seems they might be willing to do so, but it hasn't > been a high priority. (See #946456; its title is about -sysusers, but most > conversations around tmpfiles.d and sysusers.d seem to agree that whatever > changes might happen for one of those interfaces, it makes sense to do > the same for the other at the same time, because they're conceptually > fairly similar.) At this point, I think that whether systemd-tmpfiles becomes a real package or not is more of an implementation detail than important to the issue at hand. What is important is that systemd-tmpfiles becomes a (virtual or real) package to depend upon. Once that is in place, systemd maintainers can still go beyond and improve the container use case. > It is very common for systemd units to rely on systemd features > that are conceptually simpler/lower-level than the service manager, > such as tmpfiles.d support - for example, /etc/init.d/dbus creates > necessary files in /run and /var as needed, but dbus.service relies on > /usr/lib/tmpfiles.d/dbus.conf for that functionality - so I think a > Depends (or Recommends?) on an implementation of the tmpfiles.d interface > would make docker-systemctl-replacement able to start a lot more systemd > units successfully. Yes. Let me propose the following immediate actions: * Create a new bug asking systemd to provide systemd-tmpfiles. * Repurpose the php-fpm bug report #959174 for making opentmpfiles provide systemd-tmpfiles. That also solves the matter at hand. Block on the previous one. * Create a new bug asking debian-policy to register systemd-tmpfiles as a virtual package. (Thanks Sean). Block on the first one. * Create a new bug asking systemctl to depend or recommend systemd-tmpfiles. It is my understanding of the matter, that the above actions fully resolve Dmitry's use case. Dmitry: Is that correct? I'd like to see an explicit response from you. Unless anyone objects, I intend to perform these changes to the bts next week. I have good hope that systemd maintainers will cooperate on this. Helmut
Bug#966972: [in-toto-dev] Bug#966972: in-toto: FTBFS: ValueError: SSH supports only 1024 bit DSA keys
On Thu, Aug 27, 2020 at 10:50:42AM +0200, Lukas Puehringer wrote: > in-toto 0.5.0-1 [1] and python-securesystemslib 0.16.0-1 [2] fix this issue. > Any > chance we can get these accepted before in-toto is autoremoved from testing on > 2020-09-01? yes, I plan to upload until then. sorry for the delay. also I believe mailing the bug will delay the autoremoval further. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#961345: cups: daemon crashes with invalid free()
Bernhard Übelacker wrote on 26/08/2020 23:10: [...] > > Below patch is an attempt to add "printer-alert" in > copy_printer_attrs by using ippAddOctetString. > > The important change is in scheduler/ipp.c, the changes to > backend/ipp.c should just mark another questionable place. > > I could not test this change as I can not reproduce the crash - so it > is untested. Hi Bernhard, Thanks for the patch. After figuring out using "quilt refresh" I got a source package built with the patch included. Unfortunately my build attempt in cowbuilder hits this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916433 With this test fail: httpAddrGetList(backports.graysofwestminster.co.uk): FAIL I obviously managed to "fix" this once as I already built the package once. Going back through my google history to try and "fix" it again. And make a note of it this time. :-). I don't suppose you have any pointers on solving this one do you? Probably something missing in the build chroot... Thanks. Ronny -- Ronny Adsetts Technical Director Amazing Internet Ltd, London t: +44 20 8977 8943 w: www.amazinginternet.com Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ Registered in England. Company No. 4042957 signature.asc Description: OpenPGP digital signature
Bug#959786: node-cross-spawn removal
CC #959786 Le 27/08/2020 à 12:10, Xavier wrote to 958...@bugs.debian.org: > node-execa is the last reverse dependency of node-cross-spawn. It looks > like execa doesn't use risky features of cross-spawn but uses it to > parse command line. > > Suggestion: embed cross-spawn in node-execa and ROM-RM node-cross-spawn
Bug#958403: node-cross-spawn removal
node-execa is the last reverse dependency of node-cross-spawn. It looks like execa doesn't use risky features of cross-spawn but uses it to parse command line. Suggestion: embed cross-spawn in node-execa and ROM-RM node-cross-spawn
Bug#964308: RFS: geshi/1.0.9.1-1 [ITA] -- Generic Syntax Highlighter
Control: tags -1 moreinfo On Sun, Jul 05, 2020 at 07:15:01PM +0800, Nick Gasson wrote: >... > Changes since the last upload: Looks good, except: >... > - Update debhelper compatibility level to 13. -Build-Depends: cdbs, debhelper (>= 9) +Build-Depends: debhelper (>= 9), debhelper-compat (= 13) On the nitpick side is that debhelper-compat (= 13) is sufficient. Slightly more serious that you should document the switch from cdbs in the changelog. >... > + * debian/tests/test.php: add a simple sanity test. >... Is anything running this test? This looks like an autopkgtest without the control file. More a question is whether the Homepage in debian/control still points to the best place. The current URL points to an outdated location. > Regards, cu Adrian
