Bug#956011: netfilter: pkttype broadcast cant be matched in OUTPUT chain (INPUT works)
Control: reassign -1 nftables
On Lu, 06 apr 20, 07:57:15, Simon H wrote:
> Package: netfilter
> Version: nftables
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> im trying to filter broadcasts with netfilter in the output chain. input is
> workiing with pkttype broadcast, but on output i get no matches. i tested
> that by using the destination addr 255.255.255.255 for catching broadcasts
> and that works. basically im trying to allow DHCP communication (the
> broadcast part)
>
> you can easily test this by inserting those rules directly at the top of
> output chain f.e. (on input it works)
> rule: nft add rule inet t1 c_output oifname ${zone_dev} meta pkttype {
> broadcast, multicast} counter goto ${zone_out}
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: 10.3
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
--
Looking after bugs filled against unknown packages
signature.asc
Description: PGP signature
Bug#956015: anarchism: new upstream version is available
Package: anarchism Version: 15.3-2 Severity: wishlist Dear Maintainer, there's a new upstream version, 15.4 (17-Mar-2020). Please, update the package. Thanks for your work on the package. Cheers! 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.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages anarchism depends on: ii xdg-utils 1.1.3-2 anarchism recommends no packages. Versions of packages anarchism suggests: ii chromium [www-browser] 80.0.3987.162-1 ii firefox [www-browser] 74.0.1-1 pn fortune-anarchism ii lynx [www-browser] 2.9.0dev.5-1 ii w3m [www-browser] 0.5.3-37+b1 ii yelp3.34.0-1 -- no debconf information
Bug#955687: [Pkg-kde-extras] Bug#955687: wacomtablet: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/
reassign 955687 libwacom-dev libwacom/1.3-1 retitle 955687 missing libgudev-1.0-dev dependency severity 955687 serious bts affects 955687 src:wacomtablet thanks In data venerdì 3 aprile 2020 21:56:25 CEST, Lucas Nussbaum ha scritto: > Source: wacomtablet > Version: 3.2.0-3 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200402 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > make[2]: Entering directory > > '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' > > Building C object CMakeFiles/cmTC_56fac.dir/CheckFunctionExists.c.o > > /usr/bin/cc -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2 > > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=iso9899:1990 > > -fno-common -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security > > -Wno-long-long -Wpointer-arith -Wundef -Wmissing-format-attribute > > -Wwrite-strings -Werror=implicit-function-declaration > > -DCHECK_FUNCTION_EXISTS=shmat -o > > CMakeFiles/cmTC_56fac.dir/CheckFunctionExists.c.o -c > > /usr/share/cmake-3.16/Modules/CheckFunctionExists.c > > Linking C executable cmTC_56fac > > /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_56fac.dir/link.txt > > --verbose=1 > > /usr/bin/cc -g -O2 -fdebug-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > > -D_FORTIFY_SOURCE=2 -std=iso9899:1990 -fno-common -Wall -Wextra > > -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long > > -Wpointer-arith -Wundef -Wmissing-format-attribute -Wwrite-strings > > -Werror=implicit-function-declaration -DCHECK_FUNCTION_EXISTS=shmat > > -Wl,-z,relro -Wl,-z,now -rdynamic > > CMakeFiles/cmTC_56fac.dir/CheckFunctionExists.c.o -o cmTC_56fac > > make[2]: Leaving directory > > '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' > > make[1]: Leaving directory > > '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' > > > > > > > > dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake > > -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None > > -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var > > -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON > > -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON > > -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" > > -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_AUTOGEN_VERBOSE=ON > > -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. returned exit code 1 > > make: *** [debian/rules:8: build] Error 2 > > The full build log is available from: >http://qa-logs.debian.net/2020/04/02/wacomtablet_3.2.0-3_unstable.log This build was attempted with libwacom 1.3-1, whose libwacom-dev lacked a dependency and thus the libwacom detection (via pkg-config) in wacomtablet failed. This was already fixed in src:libwacom, so I'm reassigning this there, and closing it after that. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Le 05/04/2020 à 16:40, Paride Legovini a écrit : Hello Ludovic, On Fri, 3 Apr 2020 15:37:20 +0200 Ludovic Rousseau wrote: When it fails: - is the socket /var/run/pcscd/pcscd.comm still present? This was a hint in the right direction and I think it makes most of the logs I collected useless. Apparently when the problem occurs the /var/run/pcscd/pcscd.comm socket is not there anymore, but systemd still have a file descriptor open for it, as I found out using lsof: COMMAND PID TID TASKCMD USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd1 root 45u unix 0xa066a5154400 0t0 3172053 /run/pcscd/pcscd.comm type=STREAM I think the systemd socket unit (pcscd.socket) does not recreate the socket because of this, and passes a "dead" file descriptor to pcscd. What exactly deletes the pcscd.comm socket is not clear to me. Now after fiddling with pcscd I don't think I have clean logs to provide, I prefer to wait for the problem to happen again and then check if anything relevant is logged. I did try to suspend/resume a few times but but I didn't manage to reproduce the issue. But maybe you know what could be deleting the socket. pcscd can remove the /var/run/pcscd/pcscd.comm socket but only when NOT started by systemd. This is done on init and exit of pcscd. When pcscd is started by systemd you have a log message like: Apr 03 12:51:52 stramonio pcscd[98472]: 0032 pcscdaemon.c:451:main() Started by systemd Maybe, sometimes, pcscd does not detect it is started by systemd. But in this case the socket should be re-created by pcscd so that should not be the correct explanation. Or maybe the problem is on the systemd side? You can continue generating logs. They are a good indication of what is happening. You can limit logs to the info level using --info instead of --debug. You can also remove the --apdu argument. If I read correctly your previous message you have logs with: - pcscd is started by systemd - pcscd correctly indicates "Started by systemd" - but the communication is broken (pcsc_scan fails) and I guess the file /var/run/pcscd/pcscd.comm is missing - you stop pcscd: systemctl stop pcscd - you start pcscd: systemctl start pcscd - pcscd correctly indicates "Started by systemd" - the communication is still broken and, I guess, the file /var/run/pcscd/pcscd.comm is still missing To re-create the file /var/run/pcscd/pcscd.comm you need to use: systemctl stop pcscd.socket systemctl start pcscd.socket See also https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html I still have no clue when and why the socket file is removed. PS: maybe you should change your smart card password if it starts with "c". That was already a temporary password as I did fear the debugging logs might leak it, but thanks for the warning :) Adding a note on the website where the instructions on how to collect logs are given might be a good idea. Good point. Done. Bye -- Dr. Ludovic Rousseau
Bug#955707: debian-edu-config: use DuckDuckGo as Chromium's default search provider
Control: block -1 #956012 Hi Holger, On So 05 Apr 2020 13:28:21 CEST, Holger Levsen wrote: On Fri, Apr 03, 2020 at 10:20:37PM +, Mike Gabriel wrote: Possibly an option for Debian Edu? Maybe even for Chromium in Debian? yes, I'd suggest to close this bug and file a new one against chromium... done. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956012 I'd like to keep this open as a tracking bug. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpKKZbdO3PBE.pgp Description: Digitale PGP-Signatur
Bug#956009: gvfs: Nautilus not mounting filesystems in /run/user/1000/gvfs
On Sun, 05 Apr 2020 at 11:45:07 -0700, Bill Wohler wrote: > Since a recent upgrade to bullseye from stretch Skipping a version when upgrading is not supported. Each version of Debian represents about 2 years of development, and an upgrade path that applies 4 years of changes in a single transaction (and in particular ends up running user-space processes on a kernel 4 years older than the one they were tested with) is not something we can rely on. If you have other Debian 9 'stretch' systems, please upgrade them to Debian 10 'buster' and reboot, before attempting to upgrade to bullseye (which is going to be Debian 11 when it gets released). > navigating to a remote > Samba directory via Nautilus or running "gio mount smb://server/share" > no longer creates a mount point in /run/user/1000/gvfs. Do you have gvfs-fuse installed? That's the package that is responsible for mounting these FUSE filesystems in Debian. Perhaps it should be a Recommends or Suggests; we should certainly set up the reportbug metadata so that when you report gvfs bugs, the presence or absence of gvfs-fuse is part of the bug report. > I didn't find a Debian glib package. The closest I found was > glib-networking:amd64, 2.64.1-1. The source package for GLib in Debian is glib2.0, and the actual shared library is in the libglib2.0-0 binary package. You have version 2.64.1-1, according to reportbug. smcv
Bug#944491: firmware-iwlwifi: firmware does not load with error -110 with Intel 7260
Package: firmware-iwlwifi Version: 20190717-2 Followup-For: Bug #944491 Dear maintainers, i confirm that with kernel version 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux the bug is still alive: *model lspci |grep -i net ->> 3e:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b) * when removing and reloading the module iwlmvm or iwlwifi, there's a delay of ~2-3 seconds before failure, and /var/log/syslog gives the same error messages: Intel(R) Wireless WiFi driver for Linux Copyright(c) 2003- 2015 Intel Corporation iwlwifi :3e:00.0: firmware: direct-loading firmware iwlwifi-7260-17.ucode iwlwifi :3e:00.0: loaded firmware version 17.3216344376.0 op_mode iwlmvm iwlwifi :3e:00.0: Detected Intel(R) Dual Band Wireless N 7260, REV=0x144 iwlwifi :3e:00.0: Failed to load firmware chunk! iwlwifi :3e:00.0: iwlwifi transaction failed, dumping registers iwlwifi :3e:00.0: iwlwifi device config registers: iwlwifi :3e:00.0: : 08b18086 00100406 0280006b 0010 d014 iwlwifi :3e:00.0: 0020: c0608086 00c8 0100 iwlwifi :3e:00.0: 0040: 00020010 10008ec0 00130c10 0106ec11 101100ca iwlwifi :3e:00.0: 0060: 00080812 0405 00010001 iwlwifi :3e:00.0: 0080: iwlwifi :3e:00.0: 00a0: iwlwifi :3e:00.0: 00c0: c823d001 0d00 00814005 fee00558 iwlwifi :3e:00.0: 00e0: iwlwifi :3e:00.0: 0100: 14010001 4000 00462031 2000 2000 000e iwlwifi :3e:00.0: 0120: iwlwifi :3e:00.0: 0140: 14c10003 ff3f55b6 a4c494ff 15410018 08460846 0001000b 0141cafe 00f01e1f iwlwifi :3e:00.0: iwlwifi device memory mapped registers: iwlwifi :3e:00.0: : 40489204 8040 2000 0800 iwlwifi :3e:00.0: 0020: 0009 080003c5 0144 8000 803a 80008040 00080046 iwlwifi :3e:00.0: iwlwifi device AER capability structure: iwlwifi :3e:00.0: : 14010001 4000 00462031 2000 2000 000e iwlwifi :3e:00.0: 0020: iwlwifi :3e:00.0: iwlwifi parent port (:3d:01.0) config registers: iwlwifi :3d:01.0: : 240412d8 00180407 06040005 00010010 003e3e3d 01f1 iwlwifi :3d:01.0: 0020: d010d010 0001fff1 0040 0002010a iwlwifi :3d:01.0: 0040: ffc34c01 0008 00816405 fee002f8 iwlwifi :3d:01.0: 0060: 0034b009 04001060 04000800 8000 0a730100 76b50080 21901d27 iwlwifi :3d:01.0: 0080: 000f 3308 00790010 8000 116b 000f0022 iwlwifi :3d:01.0: 00a0: c00d 240412d8 iwlwifi :3d:01.0: 00c0: 00620010 8001 0010 01203c11 10110042 014803c0 iwlwifi :3d:01.0: 00e0: 00040800 0400 00010042 iwlwifi :3d:01.0: 0100: 14010001 00062011 2000 00a0 iwlwifi :3d:01.0: 0120: iwlwifi :3d:01.0: 0140: 20c10002 0800 047f0009 8001 iwlwifi :3d:01.0: 0160: iwlwifi :3d:01.0: 0180: iwlwifi :3d:01.0: 01a0: iwlwifi :3d:01.0: 01c0: iwlwifi :3d:01.0: 01e0: iwlwifi :3d:01.0: 0200: iwlwifi :3e:00.0: Could not load the [0] uCode section iwlwifi :3e:00.0: Failed to start INIT ucode: -110 iwlwifi :3e:00.0: Collecting data: trigger 16 fired. iwlwifi :3e:00.0: Not valid error log pointer 0x for Init uCode iwlwifi :3e:00.0: Fseq Registers: iwlwifi :3e:00.0: 0x | FSEQ_ERROR_CODE iwlwifi :3e:00.0: 0x | FSEQ_TOP_INIT_VERSION iwlwifi :3e:00.0: 0x | FSEQ_CNVIO_INIT_VERSION iwlwifi :3e:00.0: 0x | FSEQ_OTP_VERSION iwlwifi :3e:00.0: 0x0
Bug#950578: linux-image-5.5.0-1-armmp: enable Raspberry Pi 4 NIC module "bcmgenet"
Package: src:linux Version: 5.5.13-2 Severity: normal Dear Maintainer, Since the module for the NIC of raspberry Pi 4 was enabled in Linux 5.5.13-2 arm64: $ grep CONFIG_BCMGENET config-5.5.0-1-arm64 CONFIG_BCMGENET=m However, it's not enabled in armhf: $ grep CONFIG_BCMGENET config-5.5.0-1-armmp-lpae # CONFIG_BCMGENET is not set Is that possible you can enable it for armhf architecture in the next release? Some people still would like to use armhf for raspberry Pi 4. Thank you very much. Steven -- Steven Shiau Public Key Server PGP Key ID: 4096R/163E3FB0 Fingerprint: EB1D D5BF 6F88 820B BCF5 356C 8E94 C9CD 163E 3FB0
Bug#956016: Add Flight Levels
X-debbugs-Cc: adri...@gnu.org Package: units Version: 2.19-1 Severity: wishlist File: /usr/share/units/definitions.units Add https://en.wikipedia.org/wiki/Flight_level 1 FL = 1 hectoft = 1e2 ft By the way one wants to write e.g., FL310, not 310FL, but nevermind.
Bug#731435: warning: iteration 55823u invokes undefined behavior [-Waggressive-loop-optimizations]
Control: tags -1 patch
On Sun, Apr 5, 2020 at 8:27 PM Alberto Garcia wrote:
>
> On Thu, Dec 05, 2013 at 02:00:59PM +0100, Mathieu Malaterre wrote:
> > /«PKGBUILDDIR»/Utilities/gdcmjpeg/jccolor.c: In function 'rgb_ycc_start':
> > /«PKGBUILDDIR»/Utilities/gdcmjpeg/jccolor.c:99:43: warning: iteration
> > 55823u invokes undefined behavior [-Waggressive-loop-optimizations]
> > rgb_ycc_tab[i+G_Y_OFF] = FIX(0.58700) * i;
> >^
> > /«PKGBUILDDIR»/Utilities/gdcmjpeg/jccolor.c:97:3: note: containing loop
> >for (i = 0; i <= MAXJSAMPLE; i++) {
> >^
>
> This has already been reported upstream, and it seems exactly the same
> as #731433, which was fixed upstream in DCMTK:
>
>https://support.dcmtk.org/redmine/issues/759
>
> Berto
>
http://git.dcmtk.org/?p=dcmtk.git;a=commit;h=180d9b9
Bug#956002: pitivi: Python SyntaxWarning in package setup - bad identity comparisons against literals
On Sun, 2020-04-05 at 17:36 -0400, Phil Miller wrote: > Package: pitivi > Version: 0.999-2 > Severity: normal > > running python rtupdate hooks for python3.8... > [snip other packages with the same warning] > /usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/application.py:328: > SyntaxWarning: "is" with a literal. Did you mean "=="? > elif status is "UNSUPPORTED": > /usr/lib/x86_64-linux- > gnu/pitivi/python/pitivi/timeline/previewers.py:869: SyntaxWarning: > "is" with a literal. Did you mean "=="? > if self._image_size[0] is 0: Thanks for reporting. This is already fixed since quite a while upstream, and many other things too. We'll get the fix together with the next release in the hopefully not too distant future. signature.asc Description: This is a digitally signed message part
Bug#956017: gnome-maps: no results when searching for an address
Package: gnome-maps Version: 3.30.3-1 Severity: grave Justification: renders package unusable Dear Maintainer, when entering an address into the search box of GNOME Maps on Debian Stable, I get a loading animation for a few seconds and then "No results found". The same applies for entering an address into the start or end point of the routing panel. This problem is fixed in newer versions of the package, but I believe it should also get a bug fix for stable because in its current state, GNOME Maps doesn't provide the basic functionality users would want from a map application. I'm not quite sure whether Debian provides bug fixes for stable in situations like this, though, so sorry if I did something wrong with this bug report. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-maps depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii geoclue-2.0 2.5.2-1 ii gir1.2-champlain-0.120.12.16-3 ii gir1.2-clutter-1.0 1.26.2+dfsg-10 ii gir1.2-cogl-1.0 1.22.2-6 ii gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1 ii gir1.2-geoclue-2.0 2.5.2-1 ii gir1.2-geocodeglib-1.0 3.26.1-1 ii gir1.2-gfbgraph-0.2 0.2.3-3 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-goa-1.0 3.30.1-2 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-gtkchamplain-0.12 0.12.16-3 ii gir1.2-gtkclutter-1.01.8.4-4 ii gir1.2-gweather-3.0 3.28.2-2 ii gir1.2-rest-0.7 0.8.1-1 ii gir1.2-secret-1 0.18.7-1 ii gir1.2-soup-2.4 2.64.2-2 ii gir1.2-webkit2-4.0 2.26.4-1~deb10u2 ii gjs 1.54.3-1 ii libc62.28-10 ii libchamplain-0.12-0 0.12.16-3 ii libfolks25 0.11.4-1+b2 ii libgee-0.8-2 0.20.1-2 ii libgeocode-glib0 3.26.1-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libglib2.0-bin 2.58.3-2+deb10u2 ii librest-0.7-00.8.1-1 ii libxml2 2.9.4+dfsg1-7+b3 gnome-maps recommends no packages. gnome-maps suggests no packages. -- no debconf information
Bug#956018: iptables-converter needs a source-only upload
Package: iptables-converter Version: 0.9.8-1.1 Severity: serious x-debugs-cc: z...@debian.org The release team have decreed that non-buildd binaries can no longer migrate to testing, please make a source-only upload so your package can migrate.
Bug#373148: hylafax-server: Failed to properly detect high-speed data carrier
Hi, sorry, no longer on any such systems since long, you can close the bug as see fit. thanx regards -- oopla
Bug#955977: openldap: No manual page for module 'pw-argon2'
Hi, On Sonntag, 5. April 2020 19:41:54 CEST Ryan Tandy wrote: > Hi Peter, thanks again for contributing these man pages. I will include > this in the next upload. (Maybe just the man page; I'm not installing > its README in the package right now, and probably won't, now that there > is a man page.) absolutely fine with me. I just wanted to give a consistent & complete patch for upstream. > Is there already an ITS# for this one? I searched the bugzilla just now > but didn't find it. Thank you! Now there is: https://bugs.openldap.org/show_bug.cgi?id=9203[1] Best Peter -- Peter Marschall pe...@adpm.de [1] https://bugs.openldap.org/show_bug.cgi?id=9203
Bug#956019: mlpy: needs a source-only upload
Package: mlpy Version: 3.5.0+ds-1 Severity: serious The release team have decreed that non-buildd binaries can no longer migrate to testing, please make a source-only upload so your package can migrate.
Bug#731435: warning: iteration 55823u invokes undefined behavior [-Waggressive-loop-optimizations]
On Mon, Apr 06, 2020 at 10:29:35AM +0200, Mathieu Malaterre wrote: > http://git.dcmtk.org/?p=dcmtk.git;a=commit;h=180d9b9 I have to say that I don't see how the changes to jccolor.c solve the problem ... the warning that we have is about this line: rgb_ycc_tab[i+G_Y_OFF] = FIX(0.58700) * i; This is round(0.58700 * 65536) * 55823 = 2147510810, which exceeds INT32_MAX and therefore cannot be stored in rgb_ycc_tab, no matter how many casts you use. Berto
Bug#955821: [Pkg-privacy-maintainers] Bug#955821: torbrowser-launcher: include upstream patch to allow access to u2f tokens
Hi Birger! > it would be great if U2F devices (like a yubikey) would be usable by > default with torbrowser. I created an upstream merge request to allow > these devices in the apparmor profile a couple of months ago and it was > was merged [0] (thanks to intrigeri!), but there was no new torbrowser > release since then. > Would it be possible to include the patch in the debian package? That > would allow using salsa with U2F tokens (and any other Gitlab instance > that might come up ;)) > [0] https://github.com/micahflee/torbrowser-launcher/pull/434 Great! How do you feel about creating a pull request on https://salsa.debian.org/pkg-privacy-team/torbrowser-launcher ? If people on the privacy team list agree, we can give you access to the repository. Cheers! u.
Bug#956020: mydumper FTBFS on armel/armhf/mips/mipsel , needs to link against libm.
Package: mydumper Version: 0.9.5-1 Severity: serious (note on versioning, this failure was seen with 1.1 I strongly suspect this also affects -1, however -1 is currently unbuildable in testing due to a missing build-dependency. The history on the reproducible builds site shows failures on armhf for -1 but I don't think it has logs available for them). mydumper is failing to build on armel, armhf, mips and mipsel (and a bunch of non-release errors) with the following error. /usr/bin/cc -Wall -Wno-deprecated-declarations -Wunused -Wwrite-strings -Wno-strict-aliasing -Wextra -Wshadow -Werror -O3 -g -I/usr/include/mariadb -I/usr/include/mariadb/mysql -Wl,-z,relro -rdynamic CMakeFiles/mydumper.dir/mydumper.c.o CMakeFiles/mydumper.dir/server_detect.c.o CMakeFiles/mydumper.dir/g_unix_signal.c.o CMakeFiles/mydumper.dir/connection.c.o CMakeFiles/mydumper.dir/getPassword.c.o -o mydumper -lmariadb -lglib-2.0 -lgthread-2.0 -lpcre -lz -lstdc++ /usr/bin/ld: CMakeFiles/mydumper.dir/mydumper.c.o: undefined reference to symbol 'ceilf@@GLIBC_2.4' /usr/bin/ld: /lib/arm-linux-gnueabi/libm.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[3]: *** [CMakeFiles/mydumper.dir/build.make:152: mydumper] Error 1 This is generally caused by using math functions and forgetting to link against libm, you get away with this on some architectures due to use of inline implementations by glibc. Please modify your buildsystem to link against libm
Bug#956021: Syntax warnings while upgrading python3-pandas
Package: python3-pandas Version: 0.25.3+dfsg-9 Severity: normal Dear Maintainer, I got the following Syntax Warnings while upgrading python3-pandas. Please fix them - Setting up python3-pandas (0.25.3+dfsg-9) ... /usr/lib/python3/dist-packages/pandas/tests/frame/test_alter_axes.py:241: SyntaxWarning: "is" with a literal. Did you mean "=="? False if (keys[0] is "A" and keys[1] is "A") else drop # noqa: F632 /usr/lib/python3/dist-packages/pandas/tests/frame/test_alter_axes.py:241: SyntaxWarning: "is" with a literal. Did you mean "=="? False if (keys[0] is "A" and keys[1] is "A") else drop # noqa: F632 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-debug'), (100, 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pandas depends on: ii python33.8.2-2 ii python3-dateutil 2.7.3-3 ii python3-numpy 1:1.17.4-5 ii python3-pandas-lib 0.25.3+dfsg-9 ii python3-pkg-resources 44.0.0-1 ii python3-six1.14.0-2 ii python3-tz 2019.3-1 Versions of packages python3-pandas recommends: ii python3-bs4 4.8.2-1 ii python3-html5lib1.0.1-2 ii python3-lxml4.5.0-1 ii python3-matplotlib 3.1.2-2 ii python3-numexpr 2.7.1-1 ii python3-openpyxl3.0.3-1 ii python3-scipy 1.3.3-3 ii python3-tables 3.6.1-2 ii python3-xlrd1.1.0-5 ii python3-xlwt1.3.0-3 Versions of packages python3-pandas suggests: pn python-pandas-doc pn python3-statsmodels -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#956017: gnome-maps: no results when searching for an address
I dug into this a little and it seems that this is a problem with geocode-glib: An exception is caught at geocodeService.js:47 saying: Gio.IOErrorEnum: Service Unavailable > when entering an address into the search box of GNOME Maps on Debian > Stable, I get a loading animation for a few seconds and then "No > results > found". The same applies for entering an address into the start or > end > point of the routing panel. > > This problem is fixed in newer versions of the package, but I believe > it > should also get a bug fix for stable because in its current state, > GNOME > Maps doesn't provide the basic functionality users would want from a > map > application. > > I'm not quite sure whether Debian provides bug fixes for stable in > situations like this, though, so sorry if I did something wrong with > this bug report. signature.asc Description: This is a digitally signed message part
Bug#951964: gkrellm-tz: diff for NMU version 0.8-1.1
Control: tags 951964 + patch Control: tags 951964 + pending Dear maintainer, I've prepared an NMU for gkrellm-tz (versioned as 0.8-1.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru gkrellm-tz-0.8/debian/changelog gkrellm-tz-0.8/debian/changelog --- gkrellm-tz-0.8/debian/changelog 2016-04-15 12:34:16.0 +0300 +++ gkrellm-tz-0.8/debian/changelog 2020-04-06 12:35:25.0 +0300 @@ -1,3 +1,10 @@ +gkrellm-tz (0.8-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build without -Werror. (Closes: #951964) + + -- Adrian Bunk Mon, 06 Apr 2020 12:35:25 +0300 + gkrellm-tz (0.8-1) unstable; urgency=low * Initial release (Closes: #743902) diff -Nru gkrellm-tz-0.8/debian/patches/install.patch gkrellm-tz-0.8/debian/patches/install.patch --- gkrellm-tz-0.8/debian/patches/install.patch 2016-04-14 00:16:45.0 +0300 +++ gkrellm-tz-0.8/debian/patches/install.patch 2020-04-06 09:29:24.0 +0300 @@ -12,7 +12,7 @@ -CFLAGS = -fPIC -Wall -Werror -g $(GKRELLM_CFLAGS) -DVERSION=\"$(VERSION)\" -LDFLAGS = -shared $(GKRELLM_LDFLAGS) +CFLAGS += $(shell dpkg-buildflags --get CPPFLAGS) -+CFLAGS += -fPIC -Wall -Werror -g $(GKRELLM_CFLAGS) -DVERSION=\"$(VERSION)\" ++CFLAGS += -fPIC -Wall -g $(GKRELLM_CFLAGS) -DVERSION=\"$(VERSION)\" +LDFLAGS += -shared $(GKRELLM_LDFLAGS) OBJS = list.o config.o gkrellm-tz.o
Bug#956022: using -config switch in unit file instead of passing each parameter by hand?
Package: vip-manager Version: 0.6+ds-3 Severity: wishlist Hi Michael et al., is there a reason you are passing all parameters explicitly [1] to vip-manager instead of using the `-config` switch to pass the .yml file directly to vip-manager, as upstream does [2]? If there isn't a specifig reason to be passing parameters explicitly then I'd propose to switch to `-config` instead. Thanks a lot! *t [1] https://salsa.debian.org/postgresql/vip-manager/-/blob/master/debian/vip-manager@.service#L19 [2] https://github.com/cybertec-postgresql/vip-manager/blob/c98501181d4cfb0504357d1841028d260569b478/package/scripts/vip-manager.service#L9 -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956023: komi FTCBFS: does not pass cross tools to make
Source: komi Version: 1.04-5 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs komi 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 komi cross buildable. Please consider applying the attached patch. Helmut diff -u komi-1.04/debian/rules komi-1.04/debian/rules --- komi-1.04/debian/rules +++ komi-1.04/debian/rules @@ -21,7 +21,7 @@ # Compile package build-stamp: dh_testdir - $(MAKE) DATAPATH=/usr/share/games/komi/ OPT="$(OPT)" + dh_auto_build -- DATAPATH=/usr/share/games/komi/ OPT="$(OPT)" touch build-stamp build-indep: diff -u komi-1.04/debian/changelog komi-1.04/debian/changelog --- komi-1.04/debian/changelog +++ komi-1.04/debian/changelog @@ -1,3 +1,10 @@ +komi (1.04-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Mon, 06 Apr 2020 08:56:10 +0200 + komi (1.04-5) unstable; urgency=low * Fixed problem in Makefile that caused komi to link against many libraries
Bug#956024: trinty: build verbosely by default
Source: trinity Version: 1.9+git20200331.4d2343bd18c7b-1 Tags: patch A trinty build log does not include the compiler invocations by default. However, doing so is recommended best practice. Please make the build verbose by default. I've attached a patch for your convenience. Helmut diff --minimal -Nru trinity-1.9+git20200331.4d2343bd18c7b/debian/changelog trinity-1.9+git20200331.4d2343bd18c7b/debian/changelog --- trinity-1.9+git20200331.4d2343bd18c7b/debian/changelog 2020-03-31 23:57:23.0 +0200 +++ trinity-1.9+git20200331.4d2343bd18c7b/debian/changelog 2020-04-06 09:53:22.0 +0200 @@ -1,3 +1,10 @@ +trinity (1.9+git20200331.4d2343bd18c7b-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Make the build verbose by default. (Closes: #-1) + + -- Helmut Grohne Mon, 06 Apr 2020 09:53:22 +0200 + trinity (1.9+git20200331.4d2343bd18c7b-1) unstable; urgency=medium * Package an upstream snapshot (Closes: #954588) diff --minimal -Nru trinity-1.9+git20200331.4d2343bd18c7b/debian/rules trinity-1.9+git20200331.4d2343bd18c7b/debian/rules --- trinity-1.9+git20200331.4d2343bd18c7b/debian/rules 2020-03-31 23:57:23.0 +0200 +++ trinity-1.9+git20200331.4d2343bd18c7b/debian/rules 2020-04-06 09:53:21.0 +0200 @@ -7,6 +7,11 @@ include /usr/share/dpkg/buildflags.mk export DEB_BUILD_MAINT_OPTIONS=hardening=+all +ifeq (,$(filter terse,$(DEB_BUILD_OPTIONS))) +override_dh_auto_build: + dh_auto_build -- V=1 +endif + override_dh_auto_install: make install DESTDIR=./usr
Bug#955438: grpc: libupb.so.9 is not installed in any binary package
On Mon, Apr 6, 2020 at 8:28 am, László Böszörményi (GCS) wrote: On Wed, Apr 1, 2020 at 1:39 AM László Böszörményi (GCS) wrote: On Tue, Mar 31, 2020 at 8:12 PM Pirate Praveen wrote: > dh_missing --list-missing > dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so.9 exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.so.9.0.0 exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/x86_64-linux-gnu/libupb.a exists in > debian/tmp but is not installed to anywhere Reason is simple. It's an _external_ project and does _not_ needed in Sid / Bullseye as those use the normal protobuf packages. Please see that it's a third_party library[1] in gRPC, developed independently[2] and that it's _not_ a full implementation (but a micro, subset one)[3]. Just for the record, I've packaged upb [4] if you might need it for something. It's in the NEW queue as well, hopefully it will be accepted soon. Still no intention to ship it from gRPC, especially that your problem lies elsewhere, in dh_dwz. After adding debhelper >= 12.3~ in control, dh_dwz error is gone, but we are back with missing libupb.so.9 error (dpkg-shlibdeps comes after a dh_dwz so grpc is now failing in debhelper-compat 11 and 12). So some options I can think of, 1. Wait til upb clears NEW and migrate to testing. 2. Try if removing upb from build process will help it pick protobuf See new log below, dh_dwz dwz: debian/libgrpc9/usr/lib/x86_64-linux-gnu/libaddress_sorting.so.9.0.0: .debug_info section not present dwz: debian/libgrpc9/usr/lib/x86_64-linux-gnu/libgpr.so.9.0.0: .debug_info section not present dwz: debian/libgrpc9/usr/lib/x86_64-linux-gnu/libgrpc.so.9.0.0: .debug_info section not present dwz: debian/libgrpc9/usr/lib/x86_64-linux-gnu/libgrpc_cronet.so.9.0.0: .debug_info section not present dwz: debian/libgrpc9/usr/lib/x86_64-linux-gnu/libgrpc_unsecure.so.9.0.0: .debug_info section not present dwz: Too few files for multifile optimization dh_dwz: warning: No dwz multifile created, but not explicitly requested either so ignoring it. dh_dwz: warning: Common issues include no debug information at all (missing -g) and dh_dwz: warning: compressed debug information (#931891). dwz: debian/libgrpc++1/usr/lib/x86_64-linux-gnu/libgrpc++.so.1.26.0: .debug_info section not present dwz: debian/libgrpc++1/usr/lib/x86_64-linux-gnu/libgrpc++_error_details.so.1.26.0: .debug_info section not present dwz: debian/libgrpc++1/usr/lib/x86_64-linux-gnu/libgrpc++_reflection.so.1.26.0: .debug_info section not present dwz: debian/libgrpc++1/usr/lib/x86_64-linux-gnu/libgrpc++_unsecure.so.1.26.0: .debug_info section not present dwz: debian/libgrpc++1/usr/lib/x86_64-linux-gnu/libgrpcpp_channelz.so.1.26.0: .debug_info section not present dwz: Too few files for multifile optimization dh_dwz: warning: No dwz multifile created, but not explicitly requested either so ignoring it. dh_dwz: warning: Common issues include no debug information at all (missing -g) and dh_dwz: warning: compressed debug information (#931891). dwz: debian/ruby-grpc/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/extensions/x86_64-linux/2.5.0/grpc-1.26.0/grpc/grpc_c.so: .debug_info section not present dwz: debian/ruby-grpc/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.26.0/src/ruby/lib/grpc/grpc_c.so: .debug_info section not present dwz: Too few files for multifile optimization dh_dwz: warning: No dwz multifile created, but not explicitly requested either so ignoring it. dh_dwz: warning: Common issues include no debug information at all (missing -g) and dh_dwz: warning: compressed debug information (#931891). dh_strip dh_makeshlibs dh_shlibdeps dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python3-grpcio/usr/lib/python3/dist-packages/grpc/_cython/cygrpc.cpython-37m-x86_64-linux-gnu.so was not linked against librt.so.1 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/protobuf-compiler-grpc/usr/bin/grpc_php_plugin debian/protobuf-compiler-grpc/usr/bin/grpc_ruby_plugin debian/protobuf-compiler-grpc/usr/bin/grpc_objective_c_plugin debian/protobuf-compiler-grpc/usr/bin/grpc_node_plugin debian/protobuf-compiler-grpc/usr/bin/grpc_cpp_plugin debian/protobuf-compiler-grpc/usr/bin/grpc_python_plugin debian/protobuf-compiler-grpc/usr/bin/grpc_csharp_plugin were not linked against libcares.so.2 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/protobuf-compiler-grpc/usr/bin/grpc_php_plugin debian/protobuf-compiler-grpc/usr/bin/grpc_ruby_plugin debian/protobuf-compiler-grpc/usr/bin/grpc_objective_c_plugin debian/protobuf-compiler-grpc/usr/bin/
Bug#956025: ITP: r-cran-maxstat -- Maximally Selected Rank Statistics
Package: wnpp Severity: wishlist Subject: ITP: r-cran-maxstat -- Maximally Selected Rank Statistics Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-maxstat Version : 0.7 Upstream Author : Copyright: (FIXME: year)-2017 Torsten Hothorn * URL : https://cran.r-project.org/package=maxstat * License : GPL-2+ Programming Lang: GNU R Description : Maximally Selected Rank Statistics Maximally selected rank statistics with several p-value approximations. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-maxstat
Bug#955438: Processed: Reassign to debhelper
On Sun, Apr 5, 2020 at 8:58 pm, Niels Thykier wrote: Hi Pirate Praveen It is not really clear to me what you think the bug is. But most likely you are looking for #933541 or a newer version of dwz (if not possible, use dh_dwz --no-dwz-multifile or skip dh_dwz). Either way, it involves bumping Build-Depends or changing the d/rules of grpc (possibly "backports-only"). Thanks, bumping Build-Depends: debhelper (>= 12.3~) fixes this error. Though original error by dpkg-shlibdeps is still there (which is something to be fixed in grpc). If you still feel there is something for debhelper to do, then I would like you to be explicit about which part you consider the bug in debhelper when reassigning the bug. Since this means updating build deps in every ruby native package and golang package we backport, would it be possible to include this fix in a stable update? ~Niels
Bug#956026: RFS: ortp/1:1.0.2-1.1 [NMU, RC] -- Development files for the ortp RTP library
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ortp" * Package name: ortp Version : 1:1.0.2-1.1 Upstream Author : Simon Morlat * URL : http://www.linphone.org/technical-corner/ortp/overview * License : GPL-2+ * Vcs : https://salsa.debian.org/pkg-voip-team/ortp Section : libs It builds those binary packages: libortp-dev - Development files for the ortp RTP library libortp-doc - oRTP API documentation libortp13 - Real-time Transport Protocol (RTP) stack To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ortp Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/ortp/ortp_1.0.2-1.1.dsc Changes since the last upload: * Non-maintainer upload. * Fix ftbfs with GCC. (Closes: #925798) -- Regards Sudip
Bug#925798: ortp: diff for NMU version 1:1.0.2-1.1
Control: tags 925798 + patch
Control: tags 925798 + pending
Dear maintainer,
I've prepared an NMU for ortp (versioned as 1:1.0.2-1.1) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.
--
Regards
Sudip
diff -Nru ortp-1.0.2/debian/changelog ortp-1.0.2/debian/changelog
--- ortp-1.0.2/debian/changelog 2018-10-10 21:50:59.0 +0100
+++ ortp-1.0.2/debian/changelog 2020-04-06 10:50:38.0 +0100
@@ -1,3 +1,10 @@
+ortp (1:1.0.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC. (Closes: #925798)
+
+ -- Sudip Mukherjee Mon, 06 Apr 2020 10:50:38
+0100
+
ortp (1:1.0.2-1) unstable; urgency=medium
* Team upload.
diff -Nru ortp-1.0.2/debian/patches/fix_strcat.patch
ortp-1.0.2/debian/patches/fix_strcat.patch
--- ortp-1.0.2/debian/patches/fix_strcat.patch 1970-01-01 01:00:00.0
+0100
+++ ortp-1.0.2/debian/patches/fix_strcat.patch 2020-04-06 10:50:17.0
+0100
@@ -0,0 +1,20 @@
+Description: use strcat() instead of strncat()
+ It is doing strncat() and the length mentioned is the full length of
+ the string. We can use strcat() instead of strncat() with full string.
+
+Author: Sudip Mukherjee
+Bug-Debian: https://bugs.debian.org/925798
+
+---
+
+--- ortp-1.0.2.orig/src/logging.c
ortp-1.0.2/src/logging.c
+@@ -217,7 +217,7 @@ char * ortp_strcat_vprintf(char* dst, co
+ retlen = strlen(ret);
+
+ if ((dst = ortp_realloc(dst, dstlen+retlen+1)) != NULL){
+- strncat(dst,ret,retlen);
++ strcat(dst,ret);
+ dst[dstlen+retlen] = '\0';
+ ortp_free(ret);
+ return dst;
diff -Nru ortp-1.0.2/debian/patches/series ortp-1.0.2/debian/patches/series
--- ortp-1.0.2/debian/patches/series2018-10-10 21:50:59.0 +0100
+++ ortp-1.0.2/debian/patches/series2020-04-06 10:50:30.0 +0100
@@ -1 +1,2 @@
fix-spelling
+fix_strcat.patch
Bug#956027: libjs-popper.js: Upgrading libjs-popper.js buster -> bullseye results in an empty /usr/share/javascript/popper.js
Package: libjs-popper.js Version: 1.16.0+ds2-1 Severity: important Dear Maintainer, When upgrading libjs-popper.js from buster to bullseye, an empty /usr/share/javascript/popper.js/ directory is left and prevents the creation of the symlink to ../nodejs/popper.js/dist , thus breaking anything that expects files in /usr/share/javascript/ To reproduce, it's enough to install libjs-popper.js on a buster system (e.g. a freshly debootstrapped one) and upgrade it to bullseye. Removing manually the directory and reinstalling (apt install --reinstall libjs-popper.js) fixes the problem, as it does removing and installing again the package. Thanks in advance -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libjs-popper.js depends on: ii javascript-common 11 Versions of packages libjs-popper.js recommends: pn node-jquery libjs-popper.js suggests no packages. -- no debconf information
Bug#955821: [Pkg-privacy-maintainers] Bug#955821: torbrowser-launcher: include upstream patch to allow access to u2f tokens
Hi! On 4/6/20 10:57 AM, Ulrike Uhlig wrote: > Hi Birger! > >> it would be great if U2F devices (like a yubikey) would be usable by >> default with torbrowser. I created an upstream merge request to allow >> these devices in the apparmor profile a couple of months ago and it was >> was merged [0] (thanks to intrigeri!), but there was no new torbrowser >> release since then. >> Would it be possible to include the patch in the debian package? That >> would allow using salsa with U2F tokens (and any other Gitlab instance >> that might come up ;)) > >> [0] https://github.com/micahflee/torbrowser-launcher/pull/434 > > Great! > > How do you feel about creating a pull request on > https://salsa.debian.org/pkg-privacy-team/torbrowser-launcher ? Done ;) https://salsa.debian.org/pkg-privacy-team/torbrowser-launcher/-/merge_requests/1 > > If people on the privacy team list agree, we can give you access to the > repository. > Well, for now it seems to be a one time contribution, but if I happen to find other itches to scratch, that might make things easier ;) cheers, Birger > Cheers! > u. > signature.asc Description: OpenPGP digital signature
Bug#956017: gnome-maps: no results when searching for an address
Turns out geocode-glib uses https://nominatim.gnome.org, which is currently down (I don't know since when). The more recent version of GNOME maps doesn't use geocode-glib for geocoding, so it doesn't experience this problem. I will write a mail to the person hosting GNOME's nominatim service. signature.asc Description: This is a digitally signed message part
Bug#951971: gxneur: diff for NMU version 0.20.0-2.1
Control: tags 951971 + patch Control: tags 951971 + pending Dear maintainer, I've prepared an NMU for gxneur (versioned as 0.20.0-2.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru gxneur-0.20.0/debian/changelog gxneur-0.20.0/debian/changelog --- gxneur-0.20.0/debian/changelog 2018-09-12 01:14:50.0 +0300 +++ gxneur-0.20.0/debian/changelog 2020-04-06 12:45:46.0 +0300 @@ -1,3 +1,10 @@ +gxneur (0.20.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build without -Werror. (Closes: #951971) + + -- Adrian Bunk Mon, 06 Apr 2020 12:45:46 +0300 + gxneur (0.20.0-2) unstable; urgency=medium * d/control: Move Vcs-* to salsa. diff -Nru gxneur-0.20.0/debian/patches/04-no-werror.patch gxneur-0.20.0/debian/patches/04-no-werror.patch --- gxneur-0.20.0/debian/patches/04-no-werror.patch 1970-01-01 02:00:00.0 +0200 +++ gxneur-0.20.0/debian/patches/04-no-werror.patch 2020-04-06 12:45:46.0 +0300 @@ -0,0 +1,15 @@ +Description: Build without -Werror +Author: Adrian Bunk +Bug-Debian: https://bugs.debian.org/951971 + +--- gxneur-0.20.0.orig/configure.ac gxneur-0.20.0/configure.ac +@@ -85,7 +85,7 @@ AC_DEFINE(PACKAGE_GSETTINGS_DIR, "com." + + AC_DEFINE(KB_PROP_COMMAND, "/usr/bin/gnome-control-center region layouts", [Define keyboard properties command]) + +-DEFAULT_CFLAGS="-Wall -Wextra -Werror -g0 -fPIC -std=gnu99" ++DEFAULT_CFLAGS="-Wall -Wextra -g0 -fPIC -std=gnu99" + AC_SUBST(DEFAULT_CFLAGS) + + AC_OUTPUT([Makefile gxneur.desktop data/Makefile src/Makefile pixmaps/Makefile ui/Makefile po/Makefile.in]) diff -Nru gxneur-0.20.0/debian/patches/series gxneur-0.20.0/debian/patches/series --- gxneur-0.20.0/debian/patches/series 2018-09-12 00:50:49.0 +0300 +++ gxneur-0.20.0/debian/patches/series 2020-04-06 12:45:46.0 +0300 @@ -1,3 +1,4 @@ 01-gconf.patch 02-gconf.patch 03-glib-deprecated.patch +04-no-werror.patch
Bug#956028: wine-development: FTBFS on arm64, armel, armhf
Source: wine-development Version: 5.5-3 Severity: serious Hello, the 5.5-3 fixed amd64, but there still is a FTBFS because of install failure on arm* architectures. following a snippet of the build log: make[1]: Leaving directory '/<>' dh_install -a -O--parallel install -d debian/.debhelper/generated/wine-development install -d debian/.debhelper/generated/wine32-development install -d debian/wine64-development//usr/lib/wine-development cp --reflink=auto -a debian/tmp/usr/lib/wine-development/wine64 debian/wine64-development//usr/lib/wine-development/ cp --reflink=auto -a ./debian/tmp/wineserver64 debian/wine64-development/usr/lib/wine-development/ install -d debian/.debhelper/generated/wine64-development install -d debian/.debhelper/generated/wine32-development-preloader install -d debian/wine64-development-preloader//usr/lib/wine-development cp --reflink=auto -a debian/tmp/usr/lib/wine-development/wine64-preloader debian/wine64-development-preloader//usr/lib/wine-development/ install -d debian/.debhelper/generated/wine64-development-preloader install -d debian/.debhelper/generated/wine32-development-tools install -d debian/wine64-development-tools//usr/lib/wine-development cp --reflink=auto -a debian/tmp/usr/lib/wine-development/widl debian/tmp/usr/lib/wine-development/winebuild debian/tmp/usr/lib/wine-development/winecpp debian/tmp/usr/lib/wine-development/winedump debian/tmp/usr/lib/wine-development/wineg\+\+ debian/tmp/usr/lib/wine-development/winegcc debian/tmp/usr/lib/wine-development/winemaker debian/tmp/usr/lib/wine-development/wmc debian/tmp/usr/lib/wine-development/wrc debian/wine64-development-tools//usr/lib/wine-development/ install -d debian/wine64-development-tools/usr/bin cp --reflink=auto -a ./debian/tmp/winegcc-development debian/tmp/usr/lib/wine-development/function_grep.pl debian/wine64-development-tools/usr/bin/ dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.com" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.com dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.dll" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.dll dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.drv" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.drv dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.exe" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.exe dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.acm" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.acm dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.cpl" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.cpl dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.ocx" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.ocx dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.sys" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.sys dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/lib/*/*/*.tlb" (tried in ., debian/tmp) dh_install: warning: libwine-development missing files: debian/tmp/usr/lib/*/*/*.tlb dh_install: error: missing files, aborting install -d debian/.debhelper/generated/wine64-development-tools install -d debian/.debhelper/generated/libwine-development install -d debian/.debhelper/generated/libwine-development-dev make: *** [debian/rules:122: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 thanks Gianfranco
Bug#949373: postgrey: 'service postgrey reload' failure
Package: postgrey Version: 1.36-5.1 Followup-For: Bug #949373 Dear Maintainer, 'postgrey reload' fails: # service postgrey reload Job for postgrey.service failed. See "systemctl status postgrey.service" and "journalctl -xe" for details. # systemctl status postgrey.service âostgrey.service - LSB: Start/stop the postgrey daemon Loaded: loaded (/etc/init.d/postgrey; generated) Active: active (running) since Mon 2020-04-06 12:37:20 CEST; 2min 8s ago Docs: man:systemd-sysv-generator(8) Process: 32067 ExecStart=/etc/init.d/postgrey start (code=exited, status=0/SUCCESS) Process: 32215 ExecReload=/etc/init.d/postgrey reload (code=exited, status=2) Tasks: 1 (limit: 2380) Memory: 17.5M CGroup: /system.slice/postgrey.service â2073 postgrey --pidfile=/var/run/postgrey.pid --daemonize --pidfile=/run/postgrey.pid --inet=10023 --delay=180 --whitelist-clients=/etc/postgrey/whitelist Log: Apr 06 12:37:20 binky.tuxfriends.net postgrey[32073]: Resolved [localhost]:10023 to [::1]:10023, IPv6 Apr 06 12:37:20 binky.tuxfriends.net postgrey[32073]: Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4 Apr 06 12:37:20 binky.tuxfriends.net postgrey[32073]: Binding to TCP port 10023 on host ::1 with IPv6 Apr 06 12:37:20 binky.tuxfriends.net postgrey[32073]: Binding to TCP port 10023 on host 127.0.0.1 with IPv4 Apr 06 12:37:20 binky.tuxfriends.net postgrey[32073]: Setting gid to "122 122" Apr 06 12:37:20 binky.tuxfriends.net postgrey[32073]: Setting uid to "114" Apr 06 12:39:23 binky.tuxfriends.net systemd[1]: Reloading LSB: Start/stop the postgrey daemon. Apr 06 12:39:23 binky.tuxfriends.net postgrey[32215]: Reloading postfix greylisting daemon: postgreystart-stop-daemon: matching only on non-root pidfile /var/run/postgr Apr 06 12:39:23 binky.tuxfriends.net systemd[1]: postgrey.service: Control process exited, code=exited, status=2/INVALIDARGUMENT Apr 06 12:39:23 binky.tuxfriends.net systemd[1]: Reload failed for LSB: Start/stop the postgrey daemon. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/2 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postgrey depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii libberkeleydb-perl 0.55-2 ii libnet-dns-perl1.19-1 ii libnet-server-perl 2.009-1 ii libnetaddr-ip-perl 4.079+dfsg-1+b3 ii perl 5.28.1-6 ii ucf3.0038+nmu1 Versions of packages postgrey recommends: ii libnet-rblclient-perl 0.5-3 ii libparse-syslog-perl 1.10-3 ii postfix3.4.8-0+10debu1 postgrey suggests no packages. -- debconf information: postgrey/1.32-3_changeport:
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Ludovic Rousseau wrote on 06/04/2020: > Le 05/04/2020 à 16:40, Paride Legovini a écrit : >> Hello Ludovic, >> >> On Fri, 3 Apr 2020 15:37:20 +0200 Ludovic Rousseau >> wrote: > >>> When it fails: >>> - is the socket /var/run/pcscd/pcscd.comm still present? >> >> This was a hint in the right direction and I think it makes most of the >> logs I collected useless. Apparently when the problem occurs the >> /var/run/pcscd/pcscd.comm socket is not there anymore, but systemd still >> have a file descriptor open for it, as I found out using lsof: >> >> COMMAND PID TID TASKCMD USER FD TYPE DEVICE >> SIZE/OFF NODE NAME >> systemd 1 root 45u unix 0xa066a5154400 >> 0t0 3172053 /run/pcscd/pcscd.comm type=STREAM >> >> I think the systemd socket unit (pcscd.socket) does not recreate the >> socket because of this, and passes a "dead" file descriptor to pcscd. >> What exactly deletes the pcscd.comm socket is not clear to me. Now after >> fiddling with pcscd I don't think I have clean logs to provide, I prefer >> to wait for the problem to happen again and then check if anything >> relevant is logged. I did try to suspend/resume a few times but but I >> didn't manage to reproduce the issue. But maybe you know what could be >> deleting the socket. > > pcscd can remove the /var/run/pcscd/pcscd.comm socket but only when NOT > started by systemd. This is done on init and exit of pcscd. > When pcscd is started by systemd you have a log message like: > Apr 03 12:51:52 stramonio pcscd[98472]: 0032 pcscdaemon.c:451:main() > Started by systemd > > Maybe, sometimes, pcscd does not detect it is started by systemd. But in > this case the socket should be re-created by pcscd so that should not be > the correct explanation. > > Or maybe the problem is on the systemd side? > > You can continue generating logs. They are a good indication of what is > happening. > You can limit logs to the info level using --info instead of --debug. > You can also remove the --apdu argument. > > If I read correctly your previous message you have logs with: > - pcscd is started by systemd > - pcscd correctly indicates "Started by systemd" > - but the communication is broken (pcsc_scan fails) and I guess the file > /var/run/pcscd/pcscd.comm is missing > - you stop pcscd: systemctl stop pcscd > - you start pcscd: systemctl start pcscd > - pcscd correctly indicates "Started by systemd" > - the communication is still broken and, I guess, the file > /var/run/pcscd/pcscd.comm is still missing All correct, this fits what I observe and I think it is what is happening, but before digging more I want to collect some cleaner logs, just to be sure. While trying to debug this I tried different things, including starting pcscd manually (outside systemd), so my logs are dirty now, and I don't want to lose time on a red herring. > To re-create the file /var/run/pcscd/pcscd.comm you need to use: > systemctl stop pcscd.socket > systemctl start pcscd.socket Correct. > See also > https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html > > > I still have no clue when and why the socket file is removed. Thanks, all useful information. I'll keep the service running with --info and try to understand what happens when the socket is lost. Paride
Bug#954654: transition: hdf5
On 28/03/2020 10:50, Gilles Filippini wrote: > Emilio Pozuelo Monfort a écrit le 27/03/2020 à 13:29 : >> Control: tags -1 confirmed >> >> On 22/03/2020 12:19, Gilles Filippini wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Hi Release Team, >>> >>> I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in >>> experimental. >>> >>> Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures >>> aren't related to the transition: >>> jhdf KO - #875584 - Not in testing >>> openmolcas KO - Not in testing >>> sra-sdkKO - #952623 - Removal from testing on the 10/04/2020 >>> xmds2 KO - #938925 - Not in testing >>> ants KO - Multiple RC bugs - Not in testing >>> siconosKO - #954497 - Removal from testing on the 29/03/2020 >>> simpleitk KO - #949355 - Not in testing >> >> Sounds good. Go ahead. > > Uploaded! hdf5 is currently blocked from migrating to testing on mpich due to #954244. Cheers, Emilio
Bug#956030: ITP: r-cran-parsetools -- GNU R parse tools
Package: wnpp Severity: wishlist Subject: ITP: r-cran-parsetools -- GNU R parse tools Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-parsetools Version : 0.1.2 Upstream Author : Andrew Redd, R Consortium * URL : https://cran.r-project.org/package=parsetools * License : GPL-2 Programming Lang: GNU R Description : GNU R parse tools Tools and utilities for dealing with parse data. Parse data represents the parse tree as data with location and type information. This package provides functions for navigating the parse tree as a data frame. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-parsetools
Bug#956029: ITP: r-cran-pkgcond -- GNU R classed error and warning conditions
Package: wnpp Severity: wishlist Subject: ITP: r-cran-pkgcond -- GNU R classed error and warning conditions Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-pkgcond Version : 0.1.0 Upstream Author : Andrew Redd, * URL : https://cran.r-project.org/package=pkgcond * License : GPL-2 Programming Lang: GNU R Description : GNU R classed error and warning conditions This GNU R package provides utilities for creating classed error and warning conditions based on where the error originated. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-pkgcond
Bug#955438: grpc: libupb.so.9 is not installed in any binary package
On Mon, Apr 6, 2020 at 3:30 pm, Pirate Praveen wrote: So some options I can think of, 1. Wait til upb clears NEW and migrate to testing. 2. Try if removing upb from build process will help it pick protobuf Tried adding export GRPC_PYTHON_BUILD_SYSTEM_PROTOBUF = 1 in debian/rules but that seems not enough to force using protobuf instead of upb. Should we ask upstream to provide an easy way to skip upb and use full protobuf instead during build?
Bug#956021: Syntax warnings while upgrading python3-pandas
Control: tag -1 upstream patch (untested) This is in test code not library code, so it should be fine to ignore the warnings for now. A nearby comment notes that a simple == won't work on all the types that keys[0] can be, but this probably will: --- a/pandas/tests/frame/test_alter_axes.py +++ b/pandas/tests/frame/test_alter_axes.py @@ -238,7 +238,7 @@ class TestDataFrameAlterAxes: # cannot drop the same column twice; # use "is" because == would give ambiguous Boolean error for containers first_drop = ( -False if (keys[0] is "A" and keys[1] is "A") else drop # noqa: F632 +False if (type(keys[0]) == str and keys[0] == "A" and type(keys[1]) == str and keys[1] == "A") else drop # noqa: F632 ) # to test against already-tested behaviour, we add sequentially, # hence second append always True; must wrap keys in list, otherwise
Bug#956031: RM: kerneloops -- ROM; became useless
Package: ftp.debian.org Severity: normal Please remove kerneloops from the archive. It became useless because the service collecting the logs stopped: #953172 Thanks, Balint -- Balint Reczey Ubuntu & Debian Developer
Bug#954209: Do we want to add a fork of utls (ITP #954209)?
Hi Ana! On 03.04.20 15:36, Ana Custura wrote: > On 16/03/2020 18:12, Ulrike Uhlig wrote: > >> If I understand correctly from a quick look, Yawning distributes his >> changes under GNU GPL, while uTLS upstream has a BSD 3-Clause license >> [https://github.com/refraction-networking/utls/blob/master/LICENSE]. >> >> The BSD 3-Clause is in line with the Debian Free Software Guidelines >> (DFSG)[https://wiki.debian.org/DFSGLicenses#The_BSD-3-clause_License]. >> >> From my understanding, in Debian packaging, licenses generally apply to >> files but it also seems possible (I never encountered such a case) to >> have several licenses for one file >> [https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax]. >> Maybe someone could confirm that this is accepted. >> >> I'm now unsure to what we referred to previously when saying that there >> might be licensing issues with Yawning's fork. It does not look like >> there are. Or am I missing something crucial here? If I don't, then to move >> forward, one would need to open an RFP or ITP >> (Intent to Package) bug on the Debian bugtracker and then package this >> fork of uTLS. > To sum up the concerns that came from looking at it last time: > > golang-yawning-utls-dev is a fork of utls, which is itself a fork of the > golang tls library. This is a hard fork, any improvements cannot be > shipped upstream due to the difference in licensing that you've > identified. The upstream is very active - go has >1500 contributors, > uTLS has >50 contributors. The fork we want to package is maintained by > very few people, if I'm not mistaken, Yawning is the only core contributor. While this is not ideal, there are other packages in Debian that suffer, or have suffered, from a similar setup, like torbrowser-launcher, or onionshare. > I think there is a security implication here - if there is a security > advisory for the golang library, the Debian Security team needs to work > with the upstreams to apply security patches to it and all of its forks > in Debian, meaning this one too. If the delta from upstream increases > with every fork this could mean a lot of pain. On https://wiki.debian.org/Teams/Security I read: For stable: "The preferred situation is that the regular maintainer of an affected package (who is most familiar with its ins and outs) prepares updated packages or a ready to use patch which, after approval, will be uploaded to security-master. If the regular maintainer can't or won't provide updates (in time), the security team will take the task of creating the updated packages. Security for testing and unstable is not officially guaranteed, but the team tracks those distributions as well in the security tracker. " However, I think it would be useful that the person maintaining that package also has an eye on the golang TLS library, to be informed early on about potential security issues. (I could not find that package in the Debian archive, and as I'm totally unfamiliar with Go, I wouldn't know how to monitor that situation.) It would be helpful if the Debian package maintainer could create pull requests, or at least open issues, on yawning's repository, when a security issue is reported. My understanding is that this does not prevent us from uploading the package to the Debian archive, as long as Yawning's code is actively maintained. Correct me if I'm wrong. > However, my understanding of the dynamics could be entirely wrong, so > let me know if I'm off the mark. > Sending this to the Debian Security team, to ask if they see any > problems here. Including the source link: > https://gitlab.com/yawning/utls and ITP: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954209 Good idea. > If we're all good, I'd be very happy to help with packaging or even > sponsoring this (I've recently completed the process to become DD, now > under review!). I'm very happy to read this. Congratulations! :) >> → actually that package was uploaded to mentors.debian.org and could go >> to experimental. > Happy to update this to the latest policy and reupload if this is > something we want to do. Yay from me. Let's see if anyone else, besides the security team, has a comment on this. >>> Hey, I'm new to the debian packaging space but am happy to help out here. > Awesome, thank you for helping with this :) Cheers! ulrike PS: Ana, are you subscribed to pkg-privacy-maintain...@alioth-lists.debian.net or do you prefer to be Cc:ed?
Bug#955742: prelink: mark as Multi-Arch: allowed
On Sat, 04 Apr 2020 13:52:54 +0100 Luca Boccassi
wrote:
> Package: prelink
> Version:
>
> Dear Maintainer(s),
>
> amd64 builds of prelink and execstack seem to work fine on i386
> binaries, so it would be great if they could be marked as Multi-Arch:
> allowed so that they can be used for multi-arch builds. Upstream Wine
> packages currently use prelink at build time.
>
> Unless there are objections, given this package hasn't seen updates
in
> a long time, I'll NMU this next week to DELAY/7.
>
> Simple test:
>
> root@luca-desktop:/tmp# file less
> less: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=b25dffd1325e7e87e5ad2ba56d195d89846f7465, for GNU/Linux
3.2.0, stripped
> root@luca-desktop:/tmp# ldd less
> linux-gate.so.1 (0xf7f71000)
> libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xf7f0)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d1c000)
> /lib/ld-linux.so.2 (0xf7f73000)
> root@luca-desktop:/tmp# prelink -vm less
> Laying out 1 libraries in virtual address space 4100-5000
> Assigned virtual address space slots for libraries:
> /lib/ld-
linux.so.2 4100-41029940
> /lib/i386-linux-
gnu/libc.so.64102c000-4120ff4c
>
less 4100-
41033df8
> /lib/i386-linux-
gnu/libtinfo.so.641212000-4123b72c
> Prelinking /tmp/less
> root@luca-desktop:/tmp# file less
> less: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=b25dffd1325e7e87e5ad2ba56d195d89846f7465, for GNU/Linux
3.2.0, stripped
> root@luca-desktop:/tmp# ldd less
> linux-gate.so.1 (0xf7f6c000)
> libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0x41212000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d75000)
> /lib/ld-linux.so.2 (0xf7f6e000)
> root@luca-desktop:/tmp# ./less --version
> less 551 (GNU regular expressions)
> Copyright (C) 1984-2019 Mark Nudelman
>
> less comes with NO WARRANTY, to the extent permitted by law.
> For information about the terms of redistribution,
> see the file named README in the less distribution.
> Home page: http://www.greenwoodsoftware.com/less
NMU'ed do DELAYED/7, debdiff inlined.
--
Kind regards,
Luca Boccassi
diff -Nru prelink-0.0.20131005/debian/changelog
prelink-0.0.20131005/debian/changelog
--- prelink-0.0.20131005/debian/changelog 2017-05-25 00:20:10.0
+0100
+++ prelink-0.0.20131005/debian/changelog 2020-04-06 12:15:25.0
+0100
@@ -1,3 +1,12 @@
+prelink (0.0.20131005-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Mark prelink and execstack as Multi-Arch: allowed, so that they can
+satisfy dependencies for local cross-builds. amd64 builds seem to be
+able to successfully edit i386 binaries. (Closes: #955742)
+
+ -- Luca Boccassi Mon, 06 Apr 2020 12:15:25 +0100
+
prelink (0.0.20131005-1) unstable; urgency=medium
* New upstream release, matching Fedora version 0.5.0-3. (Mostly just
diff -Nru prelink-0.0.20131005/debian/control
prelink-0.0.20131005/debian/control
--- prelink-0.0.20131005/debian/control 2017-05-24 23:49:57.0 +0100
+++ prelink-0.0.20131005/debian/control 2020-04-06 12:12:35.0 +0100
@@ -7,6 +7,7 @@
Package: prelink
Architecture: any
+Multi-Arch: allowed
Depends: ${shlibs:Depends}, ${misc:Depends}, execstack
Built-Using: ${built-using}
Description: ELF prelinking utility to speed up dynamic linking
@@ -16,6 +17,7 @@
Package: execstack
Architecture: any
+Multi-Arch: allowed
Depends: ${shlibs:Depends}, ${misc:Depends}
Conflicts: prelink (<< 0.0.20090311-2)
Replaces: prelink
signature.asc
Description: This is a digitally signed message part
Bug#955742: prelink: mark as Multi-Arch: allowed
On 4/6/20 1:21 PM, Luca Boccassi wrote: On Sat, 04 Apr 2020 13:52:54 +0100 Luca Boccassi wrote: Package: prelink Version: Dear Maintainer(s), amd64 builds of prelink and execstack seem to work fine on i386 binaries, so it would be great if they could be marked as Multi-Arch: allowed so that they can be used for multi-arch builds. Upstream Wine packages currently use prelink at build time. Unless there are objections, given this package hasn't seen updates in a long time, I'll NMU this next week to DELAY/7. Simple test: root@luca-desktop:/tmp# file less less: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=b25dffd1325e7e87e5ad2ba56d195d89846f7465, for GNU/Linux 3.2.0, stripped root@luca-desktop:/tmp# ldd less linux-gate.so.1 (0xf7f71000) libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xf7f0) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d1c000) /lib/ld-linux.so.2 (0xf7f73000) root@luca-desktop:/tmp# prelink -vm less Laying out 1 libraries in virtual address space 4100-5000 Assigned virtual address space slots for libraries: /lib/ld- linux.so.2 4100-41029940 /lib/i386-linux- gnu/libc.so.64102c000-4120ff4c less 4100- 41033df8 /lib/i386-linux- gnu/libtinfo.so.641212000-4123b72c Prelinking /tmp/less root@luca-desktop:/tmp# file less less: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=b25dffd1325e7e87e5ad2ba56d195d89846f7465, for GNU/Linux 3.2.0, stripped root@luca-desktop:/tmp# ldd less linux-gate.so.1 (0xf7f6c000) libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0x41212000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d75000) /lib/ld-linux.so.2 (0xf7f6e000) root@luca-desktop:/tmp# ./less --version less 551 (GNU regular expressions) Copyright (C) 1984-2019 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Home page: http://www.greenwoodsoftware.com/less NMU'ed do DELAYED/7, debdiff inlined.
Bug#956027: [Pkg-javascript-devel] Bug#956027: libjs-popper.js: Upgrading libjs-popper.js buster -> bullseye results in an empty /usr/share/javascript/popper.js
Control: severity -1 serious On Mon, Apr 06, 2020 at 12:27:46PM +0200, Elena ``of Valhalla'' wrote: > When upgrading libjs-popper.js from buster to bullseye, an empty > /usr/share/javascript/popper.js/ directory is left and prevents the This is a missed directory-to-symlink migration, RC. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#954654: transition: hdf5
Hi, There is a fix for #954244 in experimental but I there are other more serious problems with mpich-3.4a4-2 Upstream quietly reset the soversion to 0 (as its an alpha package). The code works but any users of libmpich12 break. 3.4 when released will bump the soversion (it drops some symbols). The simplest solution for mpich is to leave the blocker so that the dodgy package doesn't transition, until mpich 3.4 is released. I don't have a timetable for the mpich 3.4 release, which now entangles hdf5. Alternatively, we can pre-empt and increment the mpich soversion (as I've tested in experimental) and start an mpich transition. regards Alastair On 06/04/2020 11:54, Emilio Pozuelo Monfort wrote: > On 28/03/2020 10:50, Gilles Filippini wrote: >> Emilio Pozuelo Monfort a écrit le 27/03/2020 à 13:29 : >>> Control: tags -1 confirmed >>> >>> On 22/03/2020 12:19, Gilles Filippini wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi Release Team, I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in experimental. Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures aren't related to the transition: jhdf KO - #875584 - Not in testing openmolcas KO - Not in testing sra-sdkKO - #952623 - Removal from testing on the 10/04/2020 xmds2 KO - #938925 - Not in testing ants KO - Multiple RC bugs - Not in testing siconosKO - #954497 - Removal from testing on the 29/03/2020 simpleitk KO - #949355 - Not in testing >>> Sounds good. Go ahead. >> Uploaded! > hdf5 is currently blocked from migrating to testing on mpich due to #954244. > > Cheers, > Emilio > -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#955999: openmsx: Issues with pressing multiple keys
Hi Manuel, Thanks for your reply. On Mon, 6 Apr 2020 00:25:59 +0200 Manuel Bilderbeek < manuel.bilderb...@gmail.com> wrote: > Hi, > > I can't reproduce the problem. Just walking the right in MoG and > jumping, I keep walking to the right. > > Are you sure you didn't change something with keyboard hardware or some > other keyboard settings? I didn't configure anything on my system related to the keyboard. It's enough to use my desktop environment defaults for me. Regarding openMSX, the only setting related to the keyboard I've done is the key-click sound option. This is my settings.xml: psgdirectioncallback dihaltcallback 0 0 0 3 SDL > Can you confirm the problem doesn't occur by compiling a previous > version and trying that? I've tried the following today: * On Debian 10 Buster the bug is present on version 0.15.0-2. * On Debian 10 Buster the bug is present on version 0.13.0-1 (the version found in Stretch repos). * On Debian 9 Stretch the bug is *not* present on version 0.13.0-1. * On Ubuntu 18.04 the bug is *not* present on version 0.14.0-2. I've also noticed today that the bug is only present under Buster when playing fullscreen (pressing the F12 key). Maybe it's an SDL bug? Regards, Jesus.
Bug#954654: transition: hdf5
On 4/6/20 1:43 PM, Alastair McKinstry wrote: > There is a fix for #954244 in experimental but I there are other more > serious problems with mpich-3.4a4-2 > > Upstream quietly reset the soversion to 0 (as its an alpha package). The > code works but any users of libmpich12 break. > > 3.4 when released will bump the soversion (it drops some symbols). > > The simplest solution for mpich is to leave the blocker so that the > dodgy package doesn't transition, until mpich 3.4 is released. > > I don't have a timetable for the mpich 3.4 release, which now entangles > hdf5. > > Alternatively, we can pre-empt and increment the mpich soversion (as > I've tested in experimental) and start an mpich transition. Can't mpich in unstable be reverted to 3.3.3 which built successfully? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#955438: grpc: libupb.so.9 is not installed in any binary package
On Mon, Apr 6, 2020 at 4:28 pm, Pirate Praveen wrote: On Mon, Apr 6, 2020 at 3:30 pm, Pirate Praveen wrote: So some options I can think of, 1. Wait til upb clears NEW and migrate to testing. 2. Try if removing upb from build process will help it pick protobuf Tried adding export GRPC_PYTHON_BUILD_SYSTEM_PROTOBUF = 1 in debian/rules but that seems not enough to force using protobuf instead of upb. Should we ask upstream to provide an easy way to skip upb and use full protobuf instead during build? This patch makes the build successful. https://salsa.debian.org/debian/grpc/-/blob/buster-backports/debian/patches/no-link-upb.patch I think we can close this bug unless you want to purse removing upb from source tree.
Bug#956013: Fails to install
Am 06.04.20 um 08:38 schrieb David Prévot: > Hi, > > Thanks for updating those translations. Unfortunately, there is an > unhandled upgrade path (missing Breaks and Replace on manpages-fr-extra > (<< 20151231something), and of course the manpages-fr-extra counterpart > update). Hi David, thanks for reporting this bug. Yes, I've thought about this during the preparation of this package. However, I forgot to actually add the -extra package for French. Hrm. I'll correct this with another upload, probably tomorrow. And I'll ask ftpmaster if they would be willing to fast-track this package, as it will end up in NEW again. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#956033: ITP: idseq-bench -- Benchmark generator for the IDseq Portal
Package: wnpp Severity: wishlist Owner: Sao I Kuan * Package name: idseq-bench Version : 0.0~git20191121.9623264 Upstream Author : Chan Zuckerberg Initiative * URL : https://github.com/chanzuckerberg/idseq-bench * License : Expat Programming Lang: Python Description : Benchmark generator for the IDseq Portal IDseq (Infectious Disease Sequencing Platform) is an unbiased global software platform that helps scientists identify pathogens in metagenomic sequencing data. . * Discover - Identify the pathogen landscape * Detect - Monitor and review potential outbreaks * Decipher - Find potential infecting organisms in large datasets . This package provides the benchmark generator for the IDseq Portal. This package is a work which is part of COVID-19 BioHackathon [1,2]. The package will be team maintained (med-team). [1] https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/Covid-19-hackathon [2] https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/COVID-19-Hackathon-packages-needing-work
Bug#815240: libwildmagic: diff for NMU version 5.13-1.1
Control: tags 815240 + patch
Control: tags 815240 + pending
Control: tags 951972 + patch
Control: tags 951972 + pending
Dear maintainer,
I've prepared an NMU for libwildmagic (versioned as 5.13-1.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru libwildmagic-5.13/debian/changelog libwildmagic-5.13/debian/changelog
--- libwildmagic-5.13/debian/changelog 2014-08-13 13:04:25.0 +0300
+++ libwildmagic-5.13/debian/changelog 2020-04-06 14:53:56.0 +0300
@@ -1,3 +1,11 @@
+libwildmagic (5.13-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add the missing build dependency on libxext-dev. (Closes: #951972)
+ * Architecture: linux-any (Closes: #815240)
+
+ -- Adrian Bunk Mon, 06 Apr 2020 14:53:56 +0300
+
libwildmagic (5.13-1) unstable; urgency=low
* New upstream version implementing all the stuff that I used to put in
diff -Nru libwildmagic-5.13/debian/control libwildmagic-5.13/debian/control
--- libwildmagic-5.13/debian/control 2014-08-13 13:04:25.0 +0300
+++ libwildmagic-5.13/debian/control 2020-04-06 14:53:56.0 +0300
@@ -5,6 +5,7 @@
Build-Depends: debhelper (>= 9.2),
dpkg-dev (>= 1.16.1~),
libglu1-mesa-dev (>= 9.0.0),
+ libxext-dev,
quilt,
docbook-to-man
Standards-Version: 3.9.5
@@ -15,7 +16,7 @@
Package: libwildmagic-dev
Section: libdevel
-Architecture: any
+Architecture: linux-any
Depends: ${misc:Depends},
libwildmagic5 (= ${binary:Version})
Description: libraries for mathematics, physics, numerical methods - dev files
@@ -41,7 +42,7 @@
This package ships the library development files.
Package: libwildmagic5
-Architecture: any
+Architecture: linux-any
Depends: libwildmagic-common (= ${source:Version}),
${shlibs:Depends},
${misc:Depends}
@@ -68,7 +69,7 @@
Package: libwildmagic5-dbg
Section: debug
Priority: extra
-Architecture: any
+Architecture: linux-any
Depends: libwildmagic-common (= ${source:Version}),
libwildmagic5 (= ${binary:Version}),
${misc:Depends}
@@ -113,7 +114,7 @@
Package: libwildmagic-examples
-Architecture: any
+Architecture: linux-any
Depends: ${shlibs:Depends}, ${misc:Depends},
libwildmagic5 (= ${binary:Version})
Suggests:
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Drew Parsons a écrit le 06/04/2020 à 05:08 :
> On 2020-04-06 09:56, Drew Parsons wrote:
>> On 2020-04-06 01:48, Gilles Filippini wrote:
>>> Drew Parsons a écrit le 05/04/2020 à 18:57 :
Another option is to create an environment variable to force h5py to
load the mpi version even when run in a serial environment without
mpirun. Easy enough to set up, though I'm interested to see if "mpirun
-n 1 dh_auto_build" or a variation of that is viable. Maybe
%:
mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
>>>
>>> This, way the test cases run against python3.7 is OK, but it fails
>>> against python3.8 with:
>>>
>>> I: pybuild base:217: cd
>>> /build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
>>>
>>> python3.8 -m unittest discover -v
>>> [pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
>>> line 112
>>> *** An error occurred in MPI_Init_thread
>>> *** on a NULL communicator
>>> *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
>>> *** and potentially your MPI job)
>>> [pinibrem15:43725] Local abort before MPI_INIT completed completed
>>> successfully, but am not able to aggregate error messages, and not able
>>> to guarantee that all other processes were killed!
>>> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
>>> cd
>>> /build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
>>>
>>> python3.8 -m unittest discover -v
>>> dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
>>> returned exit code 13
>>>
>>> But the HDF5 error is no more present with python3.7. So it seems a good
>>> point.
>>
>>
>> Strange again. I would have expected the same behaviour in python3.8
>> and python3.7, whether successful or unsuccessful.
>
>
> Putting dh into mpirun seems to be interfering with process spawning.
> Once MPI is initialised (for the python3.7 test) it's not reinitialised
> for the python3.8 and so it's in a bad state for the test. Something
> like that.
>
> It's only in the tests where h5py is invoked that we get the problems.
> This variant works, applying mpirun separately for each test run:
>
> override_dh_auto_test:
> set -e; \
> for py in `py3versions -s -v`; do \
> mpirun -n 1 pybuild --test -i python{version} -p $$py; \
> done
>
> (could use mpirun -n $(NPROC) for real mpi testing).
Yes, it works! \o/
> Do we want to use this as a solution? Or would you prefer an environment
> variable that h5py can check to allow mpi invocation on a serial process?
I let this decision up to you. Whatever you choose it deserve a bit fat
note in README.Debian.
> Note that this means bitshuffle as built now is expressly tied in with
> hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and
> debian/control, though the Build-Depends must be updated to
> python3-h5py-mpi). It's a separate question whether it's desirable to
> also support a hdf5-serial build of bitshuffle. Likewise we need to
> think about what we want to happen when bitshuffle is invoked in a
> serial process.
I'll let that to the bitshuffle maintainer. I'll propose a patch to fix
the current FTBFS, sticking on the mpi flavour to be conservative vs
bitshuffle's previous builds.
> I think part of the confusion here is that bitshuffle (at least in the
> tests) is double-handling the HDF5 library, with direct calls on the one
> hand, but indirectly through h5py as well, on the other hand.
Thanks,
_g.
signature.asc
Description: OpenPGP digital signature
Bug#956034: nvidia-legacy-340xx-driver: Fails to build with kernel 5.5
Package: nvidia-legacy-340xx-driver Version: 340.108-3 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, As with my previous bug reports for kernels 5.2 to 5.4, here is a new one for 5.5. Building it fails like so https://gist.github.com/pitsi/54af884134b251c237a6c810a7f4148b Please excuse the use of github's gits, but the log was too big for any of the pastebin services to handle (1.1MB). I will delete it once the bug is resolved. And here is the relevant patch, from arch's aur repo https://aur.archlinux.org/cgit/aur.git/plain/03-unfuck- for-5.5.x.patch?h=nvidia-340xx I do not know how to patch it myself and how to force dkms to rebuild it once I patch it. -- Package-specific info: uname -a: Linux mitsos 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux /proc/version: Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 9.2.1 20200123 (Debian 9.2.1-25) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.318029] Console: colour VGA+ 80x25 [0.743767] pci :01:00.0: vgaarb: setting as boot VGA device [0.743767] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.743767] pci :01:00.0: vgaarb: bridge control possible [0.743767] vgaarb: loaded [0.928344] Linux agpgart interface v0.103 [3.349739] nvidia: loading out-of-tree module taints kernel. [3.349751] nvidia: module license 'NVIDIA' taints kernel. [3.378206] nvidia: module verification failed: signature and/or required key missing - tainting kernel [3.386836] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.390037] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.390050] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [3.861937] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [5.089395] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input17 [5.089479] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input18 [5.095512] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input23 [5.095611] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25 [8.712492] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Apr 6 14:24 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Apr 6 14:25 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Apr 6 14:25 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Apr 6 14:24 pci-:01:00.0-card -> ../card0 video:*:44:jim OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 5 09:29 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 44 Jan 5 09:29 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 25 Jan 5 09:29 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jan 5 09:29 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jan 5 09:29 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 Jan 5 09:29 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 Jan 5 09:29 /etc/alternatives/glx--nvidia-loa
Bug#956035: Doesn't work with linux 5.6
Package: virtualbox-dkms Version: 6.1.4-dfsg-2 Severity: wishlist When running linux 5.6 kernel, dkms build fails. This is tracked at upstream in https://www.virtualbox.org/ticket/19312, and they have just released a test build few days ago. Thanks, Anthony
Bug#956013: Fails to install
Am 06.04.20 um 08:38 schrieb David Prévot: > Thanks for updating those translations. Unfortunately, there is an > unhandled upgrade path (missing Breaks and Replace on manpages-fr-extra > (<< 20151231something), and of course the manpages-fr-extra counterpart > update). Hi David, I think that this bug is now fixed in git. If you have the time, I'd value your input if I've thought of everything before I start another upload cycle. Regards, Tobias Git repository: https://salsa.debian.org/debian/manpages-de Hopefully fixing commit: https://salsa.debian.org/debian/manpages-de/-/commit/33c242f69a18af92a2d51d696860d7e1a8f1fb2c signature.asc Description: OpenPGP digital signature
Bug#955527: kernelshark: Crash (SIGSEGV) when pressing the "+" button
Control: tags 955527 upstream fixed-upstream This has been fixed in https://bugzilla.kernel.org/show_bug.cgi?id=204195 I think I will wait for few more days for the fix to: https://bugzilla.kernel.org/show_bug.cgi?id=207069 and then package both together. -- Regards Sudip
Bug#956036: RM: mpich -- ROM; Bad soversion, blocking a transition
Package: ftp.debian.org Severity: normal mpich-3.4a4-2 has a problem due to a silent SOVERSION change in upstream; (SOVERSION set to 0). It must not progress to testing. A new release will be done based on the previous upstream release (ie 3.3.2-3 will be uploaded when 3.4~a2-2 is removed). Regards Alastair McKinstry
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
Control: tags -1 + patch
Gilles Filippini a écrit le 06/04/2020 à 14:23 :
> Drew Parsons a écrit le 06/04/2020 à 05:08 :
>> On 2020-04-06 09:56, Drew Parsons wrote:
>>> On 2020-04-06 01:48, Gilles Filippini wrote:
Drew Parsons a écrit le 05/04/2020 à 18:57 :
>
> Another option is to create an environment variable to force h5py to
> load the mpi version even when run in a serial environment without
> mpirun. Easy enough to set up, though I'm interested to see if "mpirun
> -n 1 dh_auto_build" or a variation of that is viable. Maybe
> %:
> mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:
I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not able
to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13
But the HDF5 error is no more present with python3.7. So it seems a good
point.
>>>
>>>
>>> Strange again. I would have expected the same behaviour in python3.8
>>> and python3.7, whether successful or unsuccessful.
>>
>>
>> Putting dh into mpirun seems to be interfering with process spawning.
>> Once MPI is initialised (for the python3.7 test) it's not reinitialised
>> for the python3.8 and so it's in a bad state for the test. Something
>> like that.
>>
>> It's only in the tests where h5py is invoked that we get the problems.
>> This variant works, applying mpirun separately for each test run:
>>
>> override_dh_auto_test:
>> set -e; \
>> for py in `py3versions -s -v`; do \
>> mpirun -n 1 pybuild --test -i python{version} -p $$py; \
>> done
>>
>> (could use mpirun -n $(NPROC) for real mpi testing).
>
> Yes, it works! \o/
>
>> Do we want to use this as a solution? Or would you prefer an environment
>> variable that h5py can check to allow mpi invocation on a serial process?
>
> I let this decision up to you. Whatever you choose it deserve a bit fat
> note in README.Debian.
>
>> Note that this means bitshuffle as built now is expressly tied in with
>> hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and
>> debian/control, though the Build-Depends must be updated to
>> python3-h5py-mpi). It's a separate question whether it's desirable to
>> also support a hdf5-serial build of bitshuffle. Likewise we need to
>> think about what we want to happen when bitshuffle is invoked in a
>> serial process.
>
> I'll let that to the bitshuffle maintainer. I'll propose a patch to fix
> the current FTBFS, sticking on the mpi flavour to be conservative vs
> bitshuffle's previous builds.
Here it is.
_g.
diff -Nru bitshuffle-0.3.5/debian/changelog bitshuffle-0.3.5/debian/changelog
--- bitshuffle-0.3.5/debian/changelog 2019-12-01 19:03:38.0 +0100
+++ bitshuffle-0.3.5/debian/changelog 2020-04-06 14:47:10.0 +0200
@@ -1,3 +1,21 @@
+bitshuffle (0.3.5-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Drew Parsons , Gilles Filippini ]
+ * Closes: #955456
+- fix-deprecated.patch: fix test_h5filter.py and test_h5plugin.py
+ to open files with flag 'w' when required
+- Build-Depends: python3-h5py-mpi to force using the mpi flavour
+ of h5py
+- override_dh_auto_test:
+ - Run the tests via mpirun so that h5py knows it has to invoke its
+mpi implementation
+ - Launch the tests for each python version separatly to permit MPI
+initialization at each run
+
+ -- Gilles Filippini Mon, 06 Apr 2020 14:47:10 +0200
+
bitshuffle (0.3.5-3) unstable; urgency=medium
* don't use -march=native when building the package
diff -Nru bitshuffle-0.3.5/debian/control bitshuffle-0.3.5/debian/control
--- bitshuffle-0.3.5/debian/control 2019-12-01 19:03:38.0 +0100
+++ bitshuffle-0.3.5/debian/control 2020-04-06 14:46:51.0 +0200
@@ -11,7 +11,7 @@
# , libopenmpi-dev
, openmpi-bin
, python3-setuptools
- , python3-h5py
+ , python3-h5py-mpi
, quilt
, cmake
, pkg-config
diff -Nru bitshuffle-0.3.5/debian/patches/fix-deprecated.patch
bitshuf
Bug#956037: speech-dispatcher: Init script fails with "ln: failed to create symbolic link"
Package: speech-dispatcher Version: 0.9.0-5 Severity: normal Dear Maintainer, Starting speech-dispatcher using the SysV init script errors out with: rah@lotus:~$ sudo /etc/init.d/speech-dispatcher start [] Starting Speech Dispatcher: speech-dispatcherln: failed to create symbolic link '/var/run/speech-dispatcher/.cache/speech-dispatcher/log': No such file or directory rah@lotus:~$ Looking at the script, the creation of the LOGDIR2 LOGDIR2=$PIDDIR/.cache/speech-dispatcher/log [ -e $LOGDIR2 ] || ln -s /var/log/speech-dispatcher $LOGDIR2 fails because the $PIDDIR/.cache/speech-dispatcher directory doesn't exist. Regards, Bob Ham -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (991, 'stable'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable'), (70, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-linux-latest-31 (SMP w/16 CPU cores; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages speech-dispatcher depends on: ii adduser 3.118 ii init-system-helpers 1.56+nmu1 ii libc62.28-10 ii libdotconf0 1.3-0.3 ii libglib2.0-0 2.58.3-2+deb10u2 ii libltdl7 2.4.6-9 ii libsndfile1 1.0.28-6 ii libspeechd2 0.9.0-5 ii lsb-base 10.2019051400 ii speech-dispatcher-audio-plugins 0.9.0-5 Versions of packages speech-dispatcher recommends: pn pulseaudio ii sound-icons 0.1-6 ii speech-dispatcher-espeak-ng 0.9.0-5 Versions of packages speech-dispatcher suggests: pn espeak pn libttspico-utils pn mbrola pn speech-dispatcher-cicero pn speech-dispatcher-doc-cs pn speech-dispatcher-espeak pn speech-dispatcher-festival pn speech-dispatcher-flite -- Configuration Files: /etc/speech-dispatcher/speechd.conf changed [not included] -- no debconf information
Bug#956036: RM: mpich -- ROM; Bad soversion, blocking a transition
On 4/6/20 3:05 PM, Alastair McKinstry wrote: > Package: ftp.debian.org > Severity: normal > > mpich-3.4a4-2 has a problem due to a silent SOVERSION change in upstream; > (SOVERSION set to 0). It must not progress to testing. > A new release will be done based on the previous upstream release > (ie 3.3.2-3 will be uploaded when 3.4~a2-2 is removed). Why are asking the ftp team to remove the package entirely? To revert the package in unstable to 3.3.2 you should upload a +really revision: https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#954654: transition: hdf5
On 06/04/2020 12:53, Sebastiaan Couwenberg wrote: > On 4/6/20 1:43 PM, Alastair McKinstry wrote: >> There is a fix for #954244 in experimental but I there are other more >> serious problems with mpich-3.4a4-2 >> > Can't mpich in unstable be reverted to 3.3.3 which built successfully? Yes, it could. I'm requesting a ROM from unstable, then revert with a 3.3.2 upload. > Kind Regards, > > Bas > -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#956039: needrestart: check that loaded modules are the same version as on disk
Package: needrestart Severity: wishlist On Debian using dkms or module-assistant one can dynamically build and load existing and new modules. There are modules in Debian that have different build and upload cycles than the Linux kernel in Debian. It would be nice for needrestart to report when the module in memory is different to the one on disk and therefore needs to be reloaded. It appears that there is a way to tell if the loaded module is the same as the one on disk by using the Build-Id exposed by the Linux kernel in sysfs with the Build-Id present in the module file on disk. When the two Build-Ids are different, the module definitely needs reloading but when they are the same the module should not need to be reloaded. Usually it isn't safe to unload and reload a module so that should be left to the system administrator to do. The report should only happen when the Linux kernel version on disk is the same as the one in memory, since when Linux itself has been updated a full reboot is needed so reloading modules and then rebooting is not particularly useful. On systems with the Linux kernel livepatch support enabled, some modules might be different to the normal modules as IIRC the Linux kernel code in RAM gets patched via modules. $ modinfo realtek | head -n1 filename: /lib/modules/5.4.0-4-amd64/kernel/drivers/net/phy/realtek.ko $ file /lib/modules/5.4.0-4-amd64/kernel/drivers/net/phy/realtek.ko /lib/modules/5.4.0-4-amd64/kernel/drivers/net/phy/realtek.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=b5a51fad4e4a91c3cef79b3d5412d90c87e7dd2a, not stripped $ objdump -s --section .note.gnu.build-id /lib/modules/5.4.0-4-amd64/kernel/drivers/net/phy/realtek.ko /lib/modules/5.4.0-4-amd64/kernel/drivers/net/phy/realtek.ko: file format elf64-x86-64 Contents of section .note.gnu.build-id: 0400 1400 0300 474e5500 GNU. 0010 b5a51fad 4e4a91c3 cef79b3d 5412d90c NJ.=T... 0020 87e7dd2a ...* $ hd /sys/module/realtek/notes/.note.gnu.build-id 04 00 00 00 14 00 00 00 03 00 00 00 47 4e 55 00 |GNU.| 0010 b5 a5 1f ad 4e 4a 91 c3 ce f7 9b 3d 54 12 d9 0c |NJ.=T...| 0020 87 e7 dd 2a |...*| 0024 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#956038: mkvtoolnix: please update boost dependency
Source: mkvtoolnix Version: 45.0.0-1 Severity: important tags: patch Hello, please take this patch from Ubuntu: +mkvtoolnix (43.0.0-1ubuntu1) focal; urgency=medium + + * Update build-deps for boost 1.71 + + -- Rico Tzschichholz Tue, 11 Feb 2020 08:25:41 +0100 and change libboost-filesystem1.67-dev to libboost-filesystem-dev - qt5-default (>= 5.9~), libboost-filesystem1.67-dev, nlohmann-json3-dev, + qt5-default (>= 5.9~), libboost-filesystem-dev, nlohmann-json3-dev, this will ease the boost transition a lot! thanks Gianfranco
Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist
On 2020-04-06 20:23, Gilles Filippini wrote: Drew Parsons a écrit le 06/04/2020 à 05:08 : Do we want to use this as a solution? Or would you prefer an environment variable that h5py can check to allow mpi invocation on a serial process? I let this decision up to you. I think it's reasonable to give h5py an environment variable to work with, since the same problem might occur for other applications (including user apps). It's conceivable some users might want their hdf5 (h5py) apps to build against mpi, even if also used in serial mode. Whatever you choose it deserve a bit fat note in README.Debian. Certainly. Note that this means bitshuffle as built now is expressly tied in with hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and debian/control, though the Build-Depends must be updated to python3-h5py-mpi). It's a separate question whether it's desirable to also support a hdf5-serial build of bitshuffle. Likewise we need to think about what we want to happen when bitshuffle is invoked in a serial process. I'll let that to the bitshuffle maintainer. More puzzles for Thorsten to spend the weekends on :) I'll propose a patch to fix the current FTBFS, sticking on the mpi flavour to be conservative vs bitshuffle's previous builds. Thanks for your help. Drew
Bug#956036: RM: mpich -- ROM; Bad soversion, blocking a transition
On Mon, 2020-04-06 at 15:23 +0200, Sebastiaan Couwenberg wrote: > On 4/6/20 3:05 PM, Alastair McKinstry wrote: > > Package: ftp.debian.org > > Severity: normal > > > > mpich-3.4a4-2 has a problem due to a silent SOVERSION change in > > upstream; > > (SOVERSION set to 0). It must not progress to testing. > > A new release will be done based on the previous upstream release > > (ie 3.3.2-3 will be uploaded when 3.4~a2-2 is removed). > > Why are asking the ftp team to remove the package entirely? It also won't help, as the version in the archive can't go backwards (modulo epochs etc) and some people will already have the broken version installed. You want a fixed upload with either epoch or +really ASAP, and possibly an RC bug in the meantime. Regards, Adam
Bug#922317: FTBFS - rspamd on ppc64el fails with many errors
rspamd v2.5 seems to build on ppc64el [1]. Can this be closed? [1]: https://buildd.debian.org/status/logs.php?pkg=rspamd&ver=2.5-1&arch=ppc64el
Bug#956034: nvidia-legacy-340xx-driver: Fails to build with kernel 5.5
Package: nvidia-legacy-340xx-driver Version: 340.108-3 Followup-For: Bug #956034 Got it! Patching was as easy as patch /usr/src/nvidia-legacy-340xx-340.108/uvm/Makefile < 03-unfuck- for-5.5.x.patch and forcing dkms to rebuild it was done with dkms autoinstall via the recovery mode. Now I have a working nvidia 340.xx on kernel 5.5. -- Package-specific info: uname -a: Linux mitsos 5.5.0-1-amd64 #1 SMP Debian 5.5.13-2 (2020-03-30) x86_64 GNU/Linux /proc/version: Linux version 5.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 9.3.0 (Debian 9.3.0-8) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.319348] Console: colour VGA+ 80x25 [0.751062] pci :01:00.0: vgaarb: setting as boot VGA device [0.751062] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.751062] pci :01:00.0: vgaarb: bridge control possible [0.751062] vgaarb: loaded [0.933623] Linux agpgart interface v0.103 [3.228114] nvidia: loading out-of-tree module taints kernel. [3.228125] nvidia: module license 'NVIDIA' taints kernel. [3.278200] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.283530] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.283552] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [3.602961] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [4.836981] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input17 [4.837062] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input18 [4.837136] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input24 [4.837206] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25 [8.483374] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Apr 6 16:52 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Apr 6 16:52 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Apr 6 16:52 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Apr 6 16:52 pci-:01:00.0-card -> ../card0 video:*:44:jim OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 5 09:29 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 44 Jan 5 09:29 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 25 Jan 5 09:29 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jan 5 09:29 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jan 5 09:29 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 Jan 5 09:29 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 Jan 5 09:29 /etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf lrwxrwxrwx 1 root root 32 Jan 5 09:29 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root 29 Jan 5 09:29 /etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 28 Jan 5 09:27 /etc/alternatives/nvidia -> /usr/lib/nvidia/legacy-340xx lrwxrwxrwx 1 root root 57 Jan 5 09:27 /etc/alternatives/nvidia--libEGL.so.1-x86_64-linux-gnu -> /usr/li
Bug#955290: maven-archiver version 3.5.0 is out
On Wed, Apr 01, 2020 at 09:56:16PM -0700, tony mancill wrote: > On Sun, Mar 29, 2020 at 02:49:13PM +0200, Mathieu Malaterre wrote: > > Source: maven-archiver > > Version: 3.2.0-2 > > > > It would be super nice to have maven-archiver 3.5.0 in archive. Please > > package it. > > Hi Mathieu, > > I'm working on updating the build-dependencies. maven-archiver needs a > newer plexus-archiver, which in turn needs a newer plexus-io (which I > have just uploaded). And there might be a few more... Here's an update on this effort. plexus-archiver 4.2.2 has been uploaded to experimental because it would cause build failures in unstable due to API changes. Specifically, (2) API signatures have been removed which causes breakage for 20-odd packages. The ratt run detected 30 failures out of 639 packages total, but some of these are failing for reasons other than the API changes. I'm going to look what it would take to update those packages, but I might use a trick that Emmanuel has used in the past, which is to restore the removed methods. In case people are interested, the removed methods (from japi-compliance-checker) are: > plexus-archiver.jar, AbstractUnArchiver.class > package org.codehaus.plexus.archiver > AbstractUnArchiver.extractFile ( File srcF, File dir, InputStream > compressedInputStream, String entryName, Date entryDate, boolean isDirectory, > Integer mode, String symlinkDestination ) : void > > plexus-archiver.jar, TarUnArchiver.class > package org.codehaus.plexus.archiver.tar > TarUnArchiver.execute ( File sourceFile, File destDirectory ) : void Cheers, tony signature.asc Description: PGP signature
Bug#956036: RM: mpich -- ROM; Bad soversion, blocking a transition
On 06/04/2020 14:54, Adam D. Barratt wrote: > On Mon, 2020-04-06 at 15:23 +0200, Sebastiaan Couwenberg wrote: >> On 4/6/20 3:05 PM, Alastair McKinstry wrote: >>> Package: ftp.debian.org >>> Severity: normal >>> >>> mpich-3.4a4-2 has a problem due to a silent SOVERSION change in >>> upstream; >>> (SOVERSION set to 0). It must not progress to testing. >>> A new release will be done based on the previous upstream release >>> (ie 3.3.2-3 will be uploaded when 3.4~a2-2 is removed). >> Why are asking the ftp team to remove the package entirely? > It also won't help, as the version in the archive can't go backwards > (modulo epochs etc) and some people will already have the broken > version installed. > > You want a fixed upload with either epoch or +really ASAP, and possibly > an RC bug in the meantime. Thanks, I've uploaded a +really version. Alastair > Regards, > > Adam > -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#956040: ITP: golang-github-lucas-clemente-quic-go -- A QUIC implementation in pure go
Package: wnpp Severity: wishlist Owner: Alexandre Viau * Package name: golang-github-lucas-clemente-quic-go Version : 0.7.0-1 Upstream Author : Lucas Clemente * URL : https://github.com/lucas-clemente/quic-go * License : Expat Programming Lang: Go Description : A QUIC implementation in pure go This is needed for syncthing. -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#956036: RM: mpich -- ROM; Bad soversion, blocking a transition
On 4/6/20 4:47 PM, Alastair McKinstry wrote: > On 06/04/2020 14:54, Adam D. Barratt wrote: >> On Mon, 2020-04-06 at 15:23 +0200, Sebastiaan Couwenberg wrote: >>> On 4/6/20 3:05 PM, Alastair McKinstry wrote: Package: ftp.debian.org Severity: normal mpich-3.4a4-2 has a problem due to a silent SOVERSION change in upstream; (SOVERSION set to 0). It must not progress to testing. A new release will be done based on the previous upstream release (ie 3.3.2-3 will be uploaded when 3.4~a2-2 is removed). >>> Why are asking the ftp team to remove the package entirely? >> It also won't help, as the version in the archive can't go backwards >> (modulo epochs etc) and some people will already have the broken >> version installed. >> >> You want a fixed upload with either epoch or +really ASAP, and possibly >> an RC bug in the meantime. > > Thanks, I've uploaded a +really version. Then you should close this RM bug to prevent it from inadvertently being removed from unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc
Source: libmaxminddb Version: 1.3.2-1 Severity: important Tags: ftbfs Justification: fails to build from source on ports architectures Dependency installability problem for [140]libmaxminddb on sh4: libmaxminddb build-depends on missing: - [141]pandoc:sh4 Dependency installability problem for [142]libmaxminddb on x32: libmaxminddb build-depends on missing: - [143]pandoc:x32 Please do ensure to only ever Build-Depends-Indep on pandoc and that the build really only needs it for the arch:all build. This is now very critical, because bind9 recently gained a B-D on libmaxminddb ☹
Bug#956042: ITP: golang-github-bifurcation-mint -- A Minimal TLS 1.3 Implementation in Go
Package: wnpp Severity: wishlist Owner: Alexandre Viau * Package name: golang-github-bifurcation-mint Version : 0.0~git20200214.93c820e-1 Upstream Author : Richard Barnes * URL : https://github.com/bifurcation/mint * License : Expat Programming Lang: Go Description : A Minimal TLS 1.3 Implementation in Go This is needed for syncthing. -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#952603: python-tinyalign: license of buildwheels.sh is CC0
On Wed, Feb 26, 2020 at 12:22:14PM -0700, Sean Whitton wrote: > Hello Andreas, > > On Wed 26 Feb 2020 at 05:00PM +01, Andreas Tille wrote: > > > Hi Sean, > > > > On Wed, Feb 26, 2020 at 08:18:54AM -0700, Sean Whitton wrote: > >> Following the GitHub trail suggests that buildwheels.sh has license CC0 > >> not Expat. > > > > Do you have a link where we can get Copyright and license from? > > https://github.com/pypa/python-manylinux-demo is the repo mentioned in > the script; that's where I looked. Hi Sean, The buildwheels.sh in tinyalign is a derived work (there are multiple non-trivial modifications) from the upstream build-wheels.sh in pypa/python-manylinux-demo project, so I'm not sure that it's correct to say that it is necessarily licensed under the CC0. That is, since CC0 is a "no rights reserved" license, what is prevent the author of the derived work from releasing under MIT without attribution? I am basing that on my reading of the CC0 [1] and its FAQ [2], specifically the statement: CC0 is a useful tool for clarifying that you do not claim copyright in a work anywhere in the world. IANAL and I'm not trying to bikeshed the license question, but it seems to me that works derived from CC0-licensed works might be different in this regard. I patched the debian/copyright in [3] to refer to the original work and its CC0 license, but stopped short of indicating that the file in tinyalign is licensed under the CC0 because that seems to impinge upon the rights of author of the derived work. Does that address your concerns with the copyright for this file? Thank you, tony [1] https://creativecommons.org/share-your-work/public-domain/cc0/ [2] https://wiki.creativecommons.org/wiki/CC0_FAQ [3] https://salsa.debian.org/med-team/python-tinyalign/-/commit/66aa3198205eaf7ce23c73132dcec9e667d372ac signature.asc Description: PGP signature
Bug#956044: qnapi FTCBFS: calls the build architecture qmake
Source: qnapi Version: 0.2.3-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs qnapi fails to cross build from source, because it calls the build architecture qmake. The easiest way of calling the host qmake - using dh_auto_configure - makes qnapi cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru qnapi-0.2.3/debian/changelog qnapi-0.2.3/debian/changelog --- qnapi-0.2.3/debian/changelog2020-03-21 20:00:45.0 +0100 +++ qnapi-0.2.3/debian/changelog2020-04-06 17:08:35.0 +0200 @@ -1,3 +1,10 @@ +qnapi (0.2.3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure call a cross qmake. (Closes: #-1) + + -- Helmut Grohne Mon, 06 Apr 2020 17:08:35 +0200 + qnapi (0.2.3-1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru qnapi-0.2.3/debian/rules qnapi-0.2.3/debian/rules --- qnapi-0.2.3/debian/rules2020-03-17 02:56:35.0 +0100 +++ qnapi-0.2.3/debian/rules2020-04-06 17:08:35.0 +0200 @@ -9,7 +9,7 @@ dh $@ override_dh_auto_configure: - qmake -makefile QMAKE_STRIP=: PREFIX=/usr QMAKE_CFLAGS_ISYSTEM=-I + dh_auto_configure -- QMAKE_CFLAGS_ISYSTEM=-I override_dh_install: rm debian/qnapi/usr/share/doc/qnapi/LICENSE*
Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
On Thu, 19 Mar 2020, Thorsten Glaser wrote:
> Nevermind, I found the real culprit. SCMP_SYS() is defined to return int.
I’ll be uploading this to debian-ports’ unreleased repo to get the
builds going again. Full debdiff and build log attached.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
**
Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.
Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.
**diff -Nru libseccomp-2.4.3/debian/changelog libseccomp-2.4.3/debian/changelog
--- libseccomp-2.4.3/debian/changelog 2020-03-12 23:35:13.0 +0100
+++ libseccomp-2.4.3/debian/changelog 2020-04-06 17:49:04.0 +0200
@@ -1,3 +1,10 @@
+libseccomp (2.4.3-1+x32.1) unreleased; urgency=high
+
+ * Non-maintainer upload.
+ * debian/patches/fix-SCMP_SYS.patch: (Closes: #954294)
+
+ -- Thorsten Glaser Mon, 06 Apr 2020 17:49:04 +0200
+
libseccomp (2.4.3-1) unstable; urgency=medium
* New upstream release.
diff -Nru libseccomp-2.4.3/debian/patches/fix-SCMP_SYS.patch
libseccomp-2.4.3/debian/patches/fix-SCMP_SYS.patch
--- libseccomp-2.4.3/debian/patches/fix-SCMP_SYS.patch 1970-01-01
01:00:00.0 +0100
+++ libseccomp-2.4.3/debian/patches/fix-SCMP_SYS.patch 2020-04-06
17:48:53.0 +0200
@@ -0,0 +1,26 @@
+Author: mirabilos
+Description: Fix the return value of SCMP_SYS, it’s documented to be int
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294
+
+--- a/include/seccomp.h
b/include/seccomp.h
+@@ -197,7 +197,7 @@ struct scmp_arg_cmp {
+ * Convert a syscall name into the associated syscall number
+ * @param x the syscall name
+ */
+-#define SCMP_SYS(x) (__SNR_##x)
++#define SCMP_SYS(x) ((int)__SNR_##x)
+
+ /* Helpers for the argument comparison macros, DO NOT USE directly */
+ #define _SCMP_VA_NUM_ARGS(...)_SCMP_VA_NUM_ARGS_IMPL(__VA_ARGS__,2,1)
+--- a/include/seccomp.h.in
b/include/seccomp.h.in
+@@ -209,7 +209,7 @@ struct scmp_arg_cmp {
+ * Convert a syscall name into the associated syscall number
+ * @param x the syscall name
+ */
+-#define SCMP_SYS(x) (__SNR_##x)
++#define SCMP_SYS(x) ((int)__SNR_##x)
+
+ /* Helpers for the argument comparison macros, DO NOT USE directly */
+ #define _SCMP_VA_NUM_ARGS(...)_SCMP_VA_NUM_ARGS_IMPL(__VA_ARGS__,2,1)
diff -Nru libseccomp-2.4.3/debian/patches/series
libseccomp-2.4.3/debian/patches/series
--- libseccomp-2.4.3/debian/patches/series 2020-03-10 19:31:58.0
+0100
+++ libseccomp-2.4.3/debian/patches/series 2020-04-06 17:48:57.0
+0200
@@ -1,2 +1,3 @@
cython3.patch
riscv64_support.patch
+fix-SCMP_SYS.patch
libseccomp_2.4.3-1+x32.1_x32.build.xz
Description: application/xz
Bug#956043: pd-wiimote FTCBFS: strips with the wrong strip
Source: pd-wiimote
Version: 0.3.2-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
pd-wiimote fails to cross build from source, because it strips using the
build architecture strip during make install. Beyond breaking cross
compilation, doing so also breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. It is best practice to let dh_strip
perform all stripping. Please consider applying the attached patch.
Helmut
diff --minimal -Nru pd-wiimote-0.3.2/debian/changelog
pd-wiimote-0.3.2/debian/changelog
--- pd-wiimote-0.3.2/debian/changelog 2018-02-01 23:43:11.0 +0100
+++ pd-wiimote-0.3.2/debian/changelog 2020-04-06 16:15:42.0 +0200
@@ -1,3 +1,10 @@
+pd-wiimote (0.3.2-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Don't strip during make install. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 06 Apr 2020 16:15:42 +0200
+
pd-wiimote (0.3.2-3) unstable; urgency=medium
* Simplified & unified d/rules
diff --minimal -Nru pd-wiimote-0.3.2/debian/rules pd-wiimote-0.3.2/debian/rules
--- pd-wiimote-0.3.2/debian/rules 2018-02-01 23:43:11.0 +0100
+++ pd-wiimote-0.3.2/debian/rules 2020-04-06 16:15:40.0 +0200
@@ -23,7 +23,7 @@
$(empty)
override_dh_auto_install:
- dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
+ dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=true
# fix permissions
find $(CURDIR)/debian/*/$(pkglibdir) -name "*.pd_linux" -exec \
chmod 0664 {} +
Bug#955290: maven-archiver version 3.5.0 is out
Le 06/04/2020 à 16:41, tony mancill a écrit : > I'm going to look what it would take to update those packages, but I > might use a trick that Emmanuel has used in the past, which is to > restore the removed methods. Yes that's definitely the recommended solution :) Emmanuel Bourg
Bug#954311: Not just rendering issues...
On 6.4.2020 1.55, Pascal Giard wrote: > Thanks A LOT for the /etc/drirc trick, it fixed the problem > detailed below for me. > Took me over an hour to figure out what was wrong and to end up on this > bug report. > > I have a Thinkpad T480 (Intel UHD 620). > > The new iris driver causes all my video players to crash (e.g., VLC or > mpv) and prevents Zoom from converting my recorded sessions. Do you use xserver-xorg-video-intel? If yes, get rid of it. -- t
Bug#956046: python3-pycryptodome: SyntaxWarning: "is" with a literal
Package: python3-pycryptodome Version: 3.6.1-3 Hello, on config, a Python script in python3-pycryptodome spits out a warning: /usr/lib/python3/dist-packages/Cryptodome/SelfTest/Random/test_random.py:103: SyntaxWarning: "is" with a literal. Did you mean "=="? if sys.version_info[0] is 3: Regards, Gabriele Stilli
Bug#956045: gnome-keyring: several cryptographic vulnerabilities
Package: gnome-keyring Version: 3.36.0-1 Severity: important Tags: security upstream gnome-keyring has several vulnerabilities with regard to its handling of its encrypted data files. First, the code to verify the integrity hash is done with memcmp. This is not safe against timing attacks, so an attacker can tamper with the data and determine how much of the hash matches based on the amount of time it takes[0]. This comparison should be done in a constant-time way. Second, because the integrity algorithm used is MD5, which is vulnerable to collisions, it doesn't uniquely identify a sequence of bytes. Consequently, the padding must be checked to be zero, and it must be done in constant time with the actual integrity algorithm, such that a failure of either takes exactly the same amount of time. Third, the metadata that occurs unencrypted in the file is hashed with MD5. Since MD5 is cheap to compute, an attacker can guess to see if the items they want to access are in the keyring without needing to decrypt the data. The keys themselves are also stored unencrypted, which makes it easy to determine which types of objects and how many of each type are stored in the keyring. For example, GnuPG stores a "keygrip" attribute. This violates user privacy and leaks a significant amount of data. All of this data should be stored encrypted. Even storing both keys and values as MACs using a secret key would leak which keys and values are repeated, which in many cases would still leak a significant amount of information. Fourth, the metadata stored unencrypted is also stored without any sort of integrity check. As a result, an attacker can modify it at will without any detection whatsoever. All data stored in the file, including version numbers, algorithm identifiers, and other structural content, as well as encrypted data, should be protected either by an AEAD encryption algorithm or a strong MAC (such as HMAC with SHA-2, SHA-3, or BLAKE2). This was originally reported to the Debian Security Team on February 3, but they were unable to issue a CVE, so I reported it to the GNOME Security Team on February 4. The response was the gnome-keyring team is "aware of those issues" but they "don't think those issues are severe enough to urge an immediate fix" and plan to address them at an unspecified point in the future. Since 45 days have elapsed since the initial report and no fix is forthcoming[1], I've opened this bug to disclose this issue publicly. This is probably severity grave, but I don't have a true proof-of-concept demonstrating that it allows access to user accounts, so I opted for important. Feel free to change as you see fit. Please ensure CVEs are issued for these bugs. [0] This can be a problem with an untrusted container with the user's home directory mounted in it. There's documentation for VS Code that tells people how to do exactly this, so it's clearly a common situation. [1] https://github.com/bk2204/dev-practices/tree/master/security-research -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-keyring depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 ii dbus-x11 [dbus-session-bus] 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gcr 3.36.0-2 ii libc6 2.30-4 ii libcap-ng00.7.9-2.1+b2 ii libcap2-bin 1:2.33-1 ii libgck-1-03.36.0-2 ii libgcr-base-3-1 3.36.0-2 ii libgcrypt20 1.8.5-5 ii libglib2.0-0 2.64.1-1 ii p11-kit 0.23.20-1 ii pinentry-gnome3 1.1.0-3+b1 Versions of packages gnome-keyring recommends: ii gnome-keyring-pkcs11 3.36.0-1 ii libpam-gnome-keyring 3.36.0-1 gnome-keyring suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#954496: cwltool: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.7 3.8" returned exit code 13
On Mon, Mar 30, 2020 at 05:49:42PM +0900, Kentaro Hayashi wrote: > > /usr/lib/python3/dist-packages/coloredlogs/__init__.py:192: in > > from humanfriendly.terminal import ANSI_COLOR_CODES, ansi_wrap, > > terminal_supports_colors > > E ModuleNotFoundError: No module named 'humanfriendly.terminal' > > Hi, It seems this bug was already fixed by #954640, and you should use latest > humanfriendly/8.1-2. > > python3-humanfriendly: humanfriendly.terminal module missing from package > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954640 > > http://qa-logs.debian.net/2020/03/21/cwltool_2.0.20200224214940+dfsg-1_unstable.log > indicates that it uses humanfriendly/8.1-1 (old version). > This package lacks humanfiriendly.terminal module. > > FYI: Here is the d/changelog about 8.1-2 > > Changes: > humanfriendly (8.1-2) unstable; urgency=medium > . >* Team upload. > . >[Christian Pommranz] > . >* Install humanfriendly.terminal module (Closes: #954640) I can confirm that building against humanfriendly (=8.1-2) [1] addresses this FTBFS, and this version migrated into tested on 2020-04-02. python3-humanfriendly is being pulled in transitively via python3-coloredlogs. Is there anything else to do for this? Thanks, tony [1] https://tracker.debian.org/news/1112315/accepted-humanfriendly-81-2-source-into-unstable/ signature.asc Description: PGP signature
Bug#956047: ITP: golang-github-alangpierce-go-forceexport -- access unexported functions from other packages
Package: wnpp Severity: wishlist Owner: Alexandre Viau * Package name: golang-github-alangpierce-go-forceexport Version : 0.0~git20160317.8f1d694-1 Upstream Author : Alan Pierce * URL : https://github.com/alangpierce/go-forceexport * License : Expat Programming Lang: Go Description : A golang package that allows you to access unexported functions from other packages This is indirectly needeed for Syncthing. Cheers, -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#955366: 955366 is Important
Control: severity -1 important Raising this to Important. The lack of a KSM is a regression from the generic kernel that is impacting the usefulness of this kernel build in the environment in which it's intended to be used. This should get fixed in buster.
Bug#910368: apache2: Apache does not start reliably after reboot
Quack, Xavier, I see no such fix in Debian stable (where my problem lies). Additionally I had a look at the sources for 2.4.41-1~bpo10+1, 2.4.43-1, as well as the git master content, and I see no such thing. Are you sure you pushed that work and it got included? \_o< -- Marc Dequènes
Bug#956013: Fails to install
Le 06/04/2020 à 02:39, Dr. Tobias Quathamer a écrit : > I think that this bug is now fixed in git. If you have the time, I'd > value your input if I've thought of everything before I start another > upload cycle. I very much doubt it is manpages-l10n task to take over manpages-fr-extra (especially via a transnational dummy package). Anyway, adding a manpages-fr-extra package with a version lower the one currently in unstable will not supersede it. Regards David signature.asc Description: OpenPGP digital signature
Bug#956046: [Python-modules-team] Bug#956046: python3-pycryptodome: SyntaxWarning: "is" with a literal
Hi, I've just push to salsa a new upstream release (3.9.7) that fix this warning. Cheers, Arias Emmanuel @eamanu http://eamanu.com El lun., 6 de abr. de 2020 a la(s) 13:18, Gabriele Stilli (superenz...@libero.it) escribió: > > Package: python3-pycryptodome > Version: 3.6.1-3 > > Hello, > > on config, a Python script in python3-pycryptodome spits out a warning: > > /usr/lib/python3/dist-packages/Cryptodome/SelfTest/Random/test_random.py:103: > SyntaxWarning: "is" with a literal. Did you mean "=="? > if sys.version_info[0] is 3: > > Regards, > Gabriele Stilli > > ___ > Python-modules-team mailing list > python-modules-t...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
Bug#956048: ITP: extension-helpers -- Utilities for building and installing packages
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-de...@lists.debian.org * Package name: extension-helpers Version : 0.1 Upstream Author : The Astropy Developers * URL : https://pypi.org/project/extension-helpers/ * License : BSD-3-Clause Programming Lang: Python Description : Utilities for building and installing packages The extension-helpers package includes convenience helpers to assist with building Python packages with compiled C/Cython extensions. It is developed by the Astropy project but is intended to be general and usable by any Python package. This is not a traditional package in the sense that it is not intended to be installed directly by users or developers. Instead, it is meant to be accessed when the setup.py command is run and should be defined as a build-time dependency in pyproject.toml files. This package is a new dependency of many astropy affiliated packages. I intend to maintain it under the DPMT hood, so the salsa git dir will be https://salsa.debian.org/python-team/modules/extension-helpers Best regards Ole
Bug#955366: 955366 is Important
Control: tags -1 + patch Proposed fix for buster at https://salsa.debian.org/kernel-team/linux/-/merge_requests/229
Bug#956049: No error message from failed mount with idmap=file and incomplete gidfile
Package: sshfs Version: 3.7.0+repack-1 Severity: normal (I will clone this for two related bugs with the same setup.) On remote host: $ id uid=1000(user1) gid=1000(user1) groups=1000(user1),…,50(staff),… $ cd /srv/www/site1 $ ls -lAd drwxrwsr-x 8 user1 staff 4096 Oct 30 16:44 . $ ls -lA total 20 drwxrwsr-x 2 user1 staff 4096 Mar 17 2019 config drwxrwsr-x 3 user1 staff 4096 Mar 16 21:19 data drwxrwsr-x 4 user1 staff 4096 Apr 5 12:36 .hg -rw-rw-r-- 1 user1 staff 223 Mar 10 2019 .hgignore drwxrwsr-x 7 user1 staff 4096 Apr 5 18:19 home $ ls -lA config total 32 -rwxrwxr-x 1 user1 staff 1213 Mar 10 2019 checkuser -rw-rw-r-- 1 user1 staff 873 Mar 10 2019 permissions -rwxrwxr-x 1 user1 staff 1862 Mar 10 2019 register -rw-rw-r-- 1 user1 staff 5274 Mar 17 2019 rws.conf -rwxrwxr-x 1 user1 staff 105 Mar 10 2019 sync-reg -rwxrwxr-x 1 user1 staff 178 Mar 10 2019 sync-srv -rwxrwxr-x 1 user1 staff 3202 Mar 10 2019 updateprofile On local host: $ id uid=1001(mrvn) gid=1001(mrvn) groups=1001(mrvn),…,50(staff),… $ ls -lA total 12 drwxrwxr-x 2 mrvn mrvn 4096 Apr 5 11:33 remote -rw-r--r-- 1 mrvn mrvn 19 Apr 6 11:24 .remote-gidmap -rw-r--r-- 1 mrvn mrvn 10 Apr 5 14:27 .remote-uidmap $ ls -lA remote total 0 $ cat .remote-uidmap mrvn:1000 $ cat .remote-gidmap mrvn:1000 Bug #1: No error message from failed mount with idmap=file and incomplete gidfile On local host: $ sshfs user1@remote:/srv/www/site1 remote -o idmap=file,uidfile=.remote-uidmap,gidfile=.remote-gidmap $ echo $? 1 And the remote file system is not mounted. Bug #2: Unable to read top-level mounted directory with idmap=file On local host: $ echo staff:50 >> .remote-gidmap $ cat .remote-gidmap mrvn:1000 staff:50 $ sshfs user1@remote:/srv/www/site1 remote -o idmap=file,uidfile=.remote-uidmap,gidfile=.remote-gidmap $ echo $? 0 $ ls -lA total 12 drwxrwsr-x 1 mrvn staff 4096 Oct 30 16:44 remote -rw-r--r-- 1 mrvn mrvn19 Apr 6 12:24 .remote-gidmap -rw-r--r-- 1 mrvn mrvn10 Apr 5 14:27 .remote-uidmap $ ls -lA remote ls: reading directory 'remote': Operation not permitted total 0 $ ls -lA remote/config total 32 -rwxrwxr-x 1 mrvn staff 1213 Mar 10 2019 checkuser -rw-rw-r-- 1 mrvn staff 873 Mar 10 2019 permissions -rwxrwxr-x 1 mrvn staff 1862 Mar 10 2019 register -rw-rw-r-- 1 mrvn staff 5274 Mar 17 2019 rws.conf -rwxrwxr-x 1 mrvn staff 105 Mar 10 2019 sync-reg -rwxrwxr-x 1 mrvn staff 178 Mar 10 2019 sync-srv -rwxrwxr-x 1 mrvn staff 3202 Mar 10 2019 updateprofile $ fusermount -u remote Adding nomap=ignore fixes the problem (why?): $ sshfs user1@remote:/srv/www/site1 remote -o idmap=file,uidfile=.remote-uidmap,gidfile=.remote-gidmap,nomap=ignore $ echo $? 0 $ ls -lA total 12 drwxrwsr-x 1 mrvn staff 4096 Oct 30 16:44 remote -rw-r--r-- 1 mrvn mrvn19 Apr 6 12:24 .remote-gidmap -rw-r--r-- 1 mrvn mrvn10 Apr 5 14:27 .remote-uidmap $ ls -lA remote total 20 drwxrwsr-x 1 mrvn staff 4096 Mar 17 2019 config drwxrwsr-x 1 mrvn staff 4096 Mar 16 21:19 data drwxrwsr-x 1 mrvn staff 4096 Apr 5 12:36 .hg -rw-rw-r-- 1 mrvn staff 223 Mar 10 2019 .hgignore drwxrwsr-x 1 mrvn staff 4096 Apr 5 18:19 home $ ls -lA remote/config total 32 -rwxrwxr-x 1 mrvn staff 1213 Mar 10 2019 checkuser -rw-rw-r-- 1 mrvn staff 873 Mar 10 2019 permissions -rwxrwxr-x 1 mrvn staff 1862 Mar 10 2019 register -rw-rw-r-- 1 mrvn staff 5274 Mar 17 2019 rws.conf -rwxrwxr-x 1 mrvn staff 105 Mar 10 2019 sync-reg -rwxrwxr-x 1 mrvn staff 178 Mar 10 2019 sync-srv -rwxrwxr-x 1 mrvn staff 3202 Mar 10 2019 updateprofile $ fusermount -u remote -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages sshfs depends on: ii fuse3 3.9.0-2 ii libc6 2.30-4 ii libfuse3-3 3.9.0-2 ii libglib2.0-02.64.1-1 ii openssh-client 1:8.2p1-4 sshfs recommends no packages. sshfs suggests no packages. -- no debconf information
Bug#956049: clone for second bug
Control: clone -1 -2 Control: retitle -2 Unable to read top-level mounted directory with idmap=file
Bug#951697: Info received (Update - works after removing i915.enable_psr=1)
Works with new kernel after removing i915.enable_psr=1, this one is simmilar: https://bugs.freedesktop.org/show_bug.cgi?id=112159
Bug#951697: GDM crashes with non-default i915 parameters on dual-GPU system, NVIDIA proprietary + i915 + bumblebee
Control: retitle 951697 GDM crashes with non-default i915 parameters on dual-GPU system, NVIDIA proprietary + i915 + bumblebee Control: reassign 951697 src:linux 4.19.98-1 On Sat, 22 Feb 2020 at 15:39:09 +0100, hardko...@gmail.com wrote: > It works well on before upgrade kernel: 4.19.0-6-amd64 > I'm using the following parameters: > GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_rev_override=1 i915.enable_fbc=1 > i915.disable_power_well=0 i915.enable_psr=1 iwlwifi.power_save=1" > > I have dell xps 9560 with bumblebee and nvidia properitary drivers > configured in the according to debian wiki. I'm reassigning this to the kernel since it seems to be a kernel regression, but I suspect the kernel maintainers will not be able to help you, because you are using proprietary drivers that only NVIDIA can debug. If gdm crashes when using a series of non-default kernel module parameters, I would recommend not using those parameters. (Full text of bug report below for kernel people.) smcv On Thu, 20 Feb 2020 at 10:54:59 +0100, korczy...@gmail.com wrote: > After last update GDM crashing after provided credentials to login in. > It displays grey background and I can't switch to other terminal with > ctrl+alt+function key. It only reacts to hardware power button - shut > down normally. > Going to other terminal before providing password in gdm and issuing > startx works and my gnome session is loaded. > > Feb 20 10:30:53 dionizos gsettings[1872]: unable to open file > '/var/lib/gdm3/greeter-dconf-defaults': /var/lib/gdm3/greeter-dconf- > defaults: invalid gvdb header; expect degraded performance > Feb 20 10:30:53 dionizos gnome-session-b[1871]: unable to open file > '/var/lib/gdm3/greeter-dconf-defaults': /var/lib/gdm3/greeter-dconf- > defaults: invalid gvdb header; expect degraded performa > nce > Feb 20 10:30:53 dionizos gnome-shell[1879]: unable to open file > '/var/lib/gdm3/greeter-dconf-defaults': /var/lib/gdm3/greeter-dconf- > defaults: invalid gvdb header; expect degraded performance > Feb 20 10:30:53 dionizos org.gnome.Shell.desktop[1879]: can't load > /usr/lib/x86_64-linux-gnu/spa/support/libspa-support.so: > /usr/lib/x86_64-linux-gnu/spa/support/libspa-support.so: nie można > otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu > Feb 20 10:31:17 dionizos kernel: [ 83.698475] bbswitch: enabling > discrete graphics > Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: could not > connect to wayland server > Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: (EE) > Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: Fatal server > error: > Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: (EE) Couldn't > add screen > Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: (EE) > > > What was updated: > Start-Date: 2020-02-20 10:14:11 > Commandline: apt upgrade > Install: linux-headers-4.19.0-8-common:amd64 (4.19.98-1, automatic), > linux-headers-4.19.0-8-amd64:amd64 (4.19.98-1, automatic), linux-image- > 4.19.0-8-amd64:amd64 (4.19.98-1, automatic) > Upgrade: libpython3.7-minimal:amd64 (3.7.3-2, 3.7.3-2+deb10u1), > evince:amd64 (3.30.2-3, 3.30.2-3+deb10u1), libperl4-corelibs-perl:amd64 > (0.004-1, 0.004-1+deb10u1), libopenjp2-7:amd64 (2.3.0-2, 2.3.0- > 2+deb10u1), libopenjp2-7:i386 (2.3.0-2, 2.3.0-2+deb10u1), libcom- > err2:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libcom-err2:i386 > (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libcups2:amd64 (2.2.10-6+deb10u1, > 2.2.10-6+deb10u2), libcups2:i386 (2.2.10-6+deb10u1, 2.2.10-6+deb10u2), > linux-libc-dev:amd64 (4.19.67-2+deb10u2, 4.19.98-1), libevdocument3- > 4:amd64 (3.30.2-3, 3.30.2-3+deb10u1), libvncclient1:amd64 (0.9.11+dfsg- > 1.3, 0.9.11+dfsg-1.3+deb10u2), libegl-mesa0:amd64 (18.3.6-2, 18.3.6- > 2+deb10u1), signal-desktop:amd64 (1.30.1, 1.31.0), libsystemd0:amd64 > (241-7~deb10u2, 241-7~deb10u3), libsystemd0:i386 (241-7~deb10u2, 241- > 7~deb10u3), libglapi-mesa:amd64 (18.3.6-2, 18.3.6-2+deb10u1), libglapi- > mesa:i386 (18.3.6-2, 18.3.6-2+deb10u1), mariadb-common:amd64 > (1:10.3.18-0+deb10u1, 1:10.3.22-0+deb10u1), e2fsprogs:amd64 (1.44.5- > 1+deb10u2, 1.44.5-1+deb10u3), sudo:amd64 (1.8.27-1+deb10u1, 1.8.27- > 1+deb10u2), google-chrome-stable:amd64 (79.0.3945.130-1, 80.0.3987.116- > 1), libpython3.7:amd64 (3.7.3-2, 3.7.3-2+deb10u1), python3.7:amd64 > (3.7.3-2, 3.7.3-2+deb10u1), gir1.2-evince-3.0:amd64 (3.30.2-3, 3.30.2- > 3+deb10u1), libxatracker2:amd64 (18.3.6-2, 18.3.6-2+deb10u1), > libwinpr2-2:amd64 (2.0.0~git20190204.1.2693389a+dfsg1-1, > 2.0.0~git20190204.1.2693389a+dfsg1-1+deb10u1), udev:amd64 (241- > 7~deb10u2, 241-7~deb10u3), linux-compiler-gcc-8-x86:amd64 (4.19.67- > 2+deb10u2, 4.19.98-1), python3.7-dev:amd64 (3.7.3-2, 3.7.3-2+deb10u1), > cups-server-common:amd64 (2.2.10-6+deb10u1, 2.2.10-6+deb10u2), cups- > common:amd64 (2.2.10-6+deb10u1, 2.2.10-6+deb10u2), libcpupower1:amd64 > (4.19.67-2+deb10u2, 4.19.98-1), libpython3.7-stdlib:amd64 (3.7.3-2, > 3.7.3-2+deb10u1), libudev1:amd64 (241-7~deb10u2, 241-7~deb10u3)
Bug#956013: Fails to install
Hi David, David Prévot schrieb am Mo., 6. Apr. 2020, 18:51: > Le 06/04/2020 à 02:39, Dr. Tobias Quathamer a écrit : > > > I think that this bug is now fixed in git. If you have the time, I'd > > value your input if I've thought of everything before I start another > > upload cycle. > > I very much doubt it is manpages-l10n task to take over > manpages-fr-extra (especially via a transnational dummy package). > It *is* the task of manpages-l10n because the source tarball contains translations which were previously maintained within manpages-fr-extra. Well, alternatively we could disable the man pages which come from there and keep publishing the old manpages-fr-extra package again and again, with all the outdated stuff it contains. Doesn't make sense at all. Instead, let's go a step ahead and switch to up-to-date man pages. Best Regards, Mario Anyway, adding a manpages-fr-extra package with a version lower the one > currently in unstable will not supersede it. > > Regards > > David > >
Bug#956051: ITP: ruby-minitest-global-expectations -- Support minitest expectation methods for all objects
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-minitest-global-expectations Version : 1.0.1 Upstream Author : Jeremy Evans * URL : https://github.com/jeremyevans/minitest-global_expectations * License : Expat Programming Lang : Ruby Description : Support minitest expectation methods for all objects minitest-global_expectations allows one to keep using simple code in one's minitest specs, without having to wrap every single object one is calling an expectation method on with an underscore.
Bug#956013: Fails to install
Am 6. April 2020 18:51:31 MESZ schrieb "David Prévot" : >Le 06/04/2020 à 02:39, Dr. Tobias Quathamer a écrit : > >> I think that this bug is now fixed in git. If you have the time, I'd >> value your input if I've thought of everything before I start another >> upload cycle. > >I very much doubt it is manpages-l10n task to take over >manpages-fr-extra (especially via a transnational dummy package). > >Anyway, adding a manpages-fr-extra package with a version lower the one >currently in unstable will not supersede it. > >Regards > >David Hi David, I'm not sure if I understand correctly what you want to say. Do you mean that the separate package manpages-fr-extra should stay as a separate package? If so, please note that all existing translations from manpages-fr-extra have been imported into manpages-l10n, so I thought that we could supersede and remove manpages-fr-extra. If this is not wanted, I can of course remove those translations, so that manpages-fr-extra can still exist as an own project. Regarding the version number: I've added a special case for manpages-fr-extra in d/rules, so that the new version number of that package is greater than the current version in unstable (20200406 vs. 20151231). Please tell me if the French translation team would like to keep manpages-fr-extra, I certainly don't want to step on anyone's toes. Regards, Tobias
Bug#956013: Fails to install
Hi, Le 06/04/2020 à 07:46, Mario Blättermann a écrit : > David Prévot schrieb am Mo., 6. Apr. 2020, 18:51: >> Le 06/04/2020 à 02:39, Dr. Tobias Quathamer a écrit : >> >>> I think that this bug is now fixed in git. If you have the time, I'd >>> value your input if I've thought of everything before I start another >>> upload cycle. >> >> I very much doubt it is manpages-l10n task to take over >> manpages-fr-extra (especially via a transnational dummy package). > > It *is* the task of manpages-l10n because the source tarball contains > translations which were previously maintained within manpages-fr-extra. Ho, that’s nice to hear. I totally failed to notice the takeover of glibc, openssl, bash, coreutils, most, etc. manpage translations that manpages-fr-extra used to provide. Anyway, you could simply upload a manpages-fr-extra update providing the dummy package instead of adding it in manpages-l10n (and be bugged by version handling and NEW processing) if you want this issue resolved quickly. Regards David signature.asc Description: OpenPGP digital signature
