Bug#1068647: python-pot: autopkgtest regression on i386 with NumPy 1.26.4
Control: forwarded -1 https://github.com/PythonOT/POT/issues/618 Thanks for the bug report. This seems like a simple case of a missing floating point tolerance in upstream's test. It's easy to patch, but I've sent a reproducible example upstream [1] as they're likely to have better insight into the appropriate floating point tolerance level for the test. [1] https://github.com/PythonOT/POT/issues/618 Best, Gard
Bug#1062932: Error building nvidia-kernel-dkms while installing nvidia-driver package
On 4 April 2024 02:52:29 CEST, David Landry wrote: >Good evening, > >The bug involving compiling/installing nvidia-kernel-dkms is still present. >The result of the bug is that following a reboot after the erroneous >installation noted below, my display drivers get completely disabled, >including nouveau, resulting in my external display not functioning and my >primary laptop display having very low resolution. > >I followed the instructions to install NVIDIA proprietary drivers here: >https://wiki.debian.org/NvidiaGraphicsDrivers > >When I executed: >sudo apt install nvidia-driver firmware-misc-nonfree >I received the following errors, as recorded from the output of the above >command: >Setting up nvidia-kernel-dkms (525.147.05-4~deb12u1) ... Hello, You seem to be attempting to install a package version with the bug (525.147.05-4~deb12u1). As you can see from the very bugreport you're replying to, the fixed version for Bookworm is 525.147.05-7~deb12u1 (https://lists.debian.org/debian-stable-announce/2024/02/msg2.html). Are you sure you have bookworm-updates enabled? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1064568: ITP: curldd -- This is a Application for putting a iso or raw image directly to a physical drive without downloading it firstly
On February 24, 2024 11:42:49 AM GMT+01:00, User0 wrote: >Package: wnpp >Severity: wishlist >Owner: User0 >X-Debbugs-Cc: debian-de...@lists.debian.org, cur...@proton.me > > Package name: curldd > Version : 1.0.0-1 > Upstream Contact: User0 > URL : https://github.com/user0-tb/curldd/ > License : CC0 > Programming Lang: Shell Script > Description : This is a Application for putting a iso or raw image > directly to a physical drive without downloading it firstly > >Tired of downloading ISOs or any other raw files just to DD them and delete >them after that? This is the Solution! It uses cURL to curl the file >byte-by-byte and uses DD to put the curled output to a Physical Drive! Also it >displays all physical devices with lsblk and waits 15 seconds to terminate the >program if it was started wit wrong arguments. >Usage: curldd url.to/iso /dev/sdX > Hello, Piping together two commands and prefixing them by lsblk and sleep, does not make up something that warrants a Debian package on its own. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1061099: MR on Salsa
Control: tags 1061099 patch A fix is available as MR 1 on Salsa: https://salsa.debian.org/yangfl-guest/imgui/-/merge_requests/1 Best, Gard signature.asc Description: PGP signature
Bug#1061100: imgui: Please tag git commits that correspond to versions in the archive
Source: imgui X-Debbugs-Cc: g...@nonempty.org Version: 1.86+ds-1 Severity: minor ImGui is currently available in the following distributions and versions: * bullseye: 1.81+ds-1 * bookworm: 1.86+ds-1 * trixie: 1.89.6+ds-1 * sid: 1.89.6+ds-1 Of these, only the bullseye version is properly tagged in the git repository shared on Salsa. Please tag the git commit corresponding every version uploaded to the Debian archives to make the life of other DDs easier. (In my case, the lack of tags was a great annoyance when investigating #1061099) Best, Gard signature.asc Description: PGP signature
Bug#1061099: libimgui-dev: Please build sdlrenderer backend
Package: libimgui-dev X-Debbugs-Cc: g...@nonempty.org Version: 1.86+ds-1 Severity: normal The ImGui package's custom makefile currently does not build the sdlrenderer backend. Enabling building of it is as simple as adding backends/imgui_impl_sdlrenderer.cpp to said makefile's SRCS variable. Please consider making this change, as it likely has no drawbacks, only benefits. Best, Gard signature.asc Description: PGP signature
Bug#1059612: libgudhi-doc: HTML documentation causes requests to third-party website when viewed
Package: libgudhi-doc X-Debbugs-Cc: g...@nonempty.org Version: 3.8.0+dfsg-1 Severity: important This is to document that libgudhi-doc contains HTML documentation that causes requests to a third-party website when viewed, potentially violating user privacy expectations. This seems to me to be due to a bug in Doxygen. signature.asc Description: PGP signature
Bug#1059611: doxygen: Generated documentation pulls in JS from third-party source in some cases
Package: doxygen X-Debbugs-Cc: g...@nonempty.org Version: 1.9.8+ds-2 Severity: normal Tags: upstream As documented upstream in issue 10354 [1], Doxygen will when MathJax is enabled generate documentation that makes requests to a third-party website when viewed. This is obviously problematic from a privacy point of view, as users expect offline documentation to be offline. For examples of this happening, see e.g. reports for Lintian's privacy-breach-generic tag [2]. Upstream's version 1.10.0 was released just a few days ago, and fixes the issue [3]. Alternatively, the behavior should be easy to patch out (I'm happy to provide a patch/MR). [1] https://github.com/doxygen/doxygen/issues/10354 [2] https://udd.debian.org/lintian-tag.cgi?tag=privacy-breach-generic [3] https://www.doxygen.nl/manual/changelog.html#log_1_10_0 signature.asc Description: PGP signature
Bug#1059100: rust-wasm-bindgen: Please consider producing a binary for wasm-bindgen-cli also
Source: rust-wasm-bindgen X-Debbugs-Cc: g...@nonempty.org Version: 0.2.87-1 Severity: wishlist In order to use wasm-bindgen to write Rust code that interacts with Javascript, the binaries output by rustc need to be passed through postprocessing with the utility wasm-bindgen-cli. That bin crate is a workspace member upstream, but is not currently packaged in Debian. Having it would greatly improve the usefulness of wasm-bindgen. It seems that the cli crate does have dependencies that are not yet in Debian, so this may well be a non-trivial amount of work.
Bug#1039001: Tests disabled
Source: hera Version: 1.0.0+dfsg-2 Followup-For: Bug #1039001 Control: severity 1039001 wishlist Uploading catch2 v3 also made hera FTBFS (#1054686), and it is not clear whether the catch2 package will provide backwards-compatible headers (#1055237). Since updating hera is not entirely trivial, the fix for #1054686 was to temporarily disable tests. With tests disabled, I'm lowering the severity of this bug. signature.asc Description: PGP signature
Bug#1039474: ghc: GHCi sometimes segfaults
Package: ghc Version: 9.0.2-4 Severity: normal Tags: upstream X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, GHCi seems to segfault randomly every now and then, after seemingly failing to allocate memory for simple operations, e.g.: $ ghci GHCi, version 9.0.2: https://www.haskell.org/ghc/ :? for help ghci> 750+850 1600 ghc: mmap 4096 bytes at (nil): Cannot allocate memory ghc: Try specifying an address with +RTS -xm -RTS zsh: segmentation fault ghci Shortly afterwards, the same commands may work perfectly well. I've observed this happen on two completely different machines, but have been unable to consistently reproduce. Upstream describes the issue at https://discourse.haskell.org/t/facing-mmap-4096-bytes-at-nil-cannot-allocate-memory-youre-not-alone/6259 but it seems that the fix has not been backported to 9.0.x. I have no idea how hard it would be to do. Sorry for not catching this before Bookworm released. I do believe I saw the segfault once or twice before the release, but I must have chalked it up to a hardware fault or something :-/ -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ghc depends on: ii dpkg1.21.22 ii gcc 4:12.2.0-3 ii libbsd-dev 0.11.7-2 ii libc6 2.36-9 ii libc6-dev 2.36-9 ii libffi-dev 3.4.4-1 ii libffi8 3.4.4-1 ii libgmp-dev 2:6.2.1+dfsg1-1.1 ii libgmp102:6.2.1+dfsg1-1.1 ii libncurses-dev 6.4-4 ii libtinfo6 6.4-4 ghc recommends no packages. Versions of packages ghc suggests: pn ghc-doc pn ghc-prof pn haskell-doc ii llvm-13 1:13.0.1-11+b2 ii perl 5.36.0-7 -- no debconf information signature.asc Description: PGP signature
Bug#1039002: gudhi: Updating GUDHI to version 3.8.0
Source: gudhi Version: 3.7.1+dfsg-1 Severity: wishlist X-Debbugs-Cc: g...@nonempty.org This bug is meant to document the fact that that updating the GUDHI package to version 3.8.0 (or later) is currently blocked by #1039001. signature.asc Description: PGP signature
Bug#1039001: hera: Updating to version 2.0.0
Source: hera Version: 1.0.0+dfsg-1 Severity: wishlist X-Debbugs-Cc: g...@nonempty.org Upstream released Hera 2.0.0 a while ago. Updating the package is taking a while, because upstream now bundles a quite modified copy of PHAT. While we can probably live with that, a bigger problem is that upstream hasn't reconciled what I believe are incompatible licenses for PHAT and Hera itself. An issue has been filed [1]. This bug is intended to serve as documentation. [1] https://github.com/anigmetov/hera/issues/13 -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#1034448: bind9: Typo in documentation file name
Package: bind9 Version: 1:9.16.37-1~deb11u1 Severity: minor X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, /etc/bind/named.conf refers to documentation in /usr/share/doc/bind9/README.Debian.gz. The correct file name is seemingly /usr/share/doc/bind9/README.Debian. -- Gard signature.asc Description: PGP signature
Bug#1034165: unblock: waypipe/0.8.4-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: wayp...@packages.debian.org, g...@nonempty.org
Control: affects -1 + src:waypipe
Please unblock package waypipe.
[ Reason ]
Waypipe versions prior to 0.8.6 contain a memory leak that is documented
as bug #1034163 [1]. I have cherry-picked a one-line fix from upstream
[2], and have verified that it fixes the problem. I have uploaded
0.8.4-3 to unstable with that patch as the only change. A debdiff
against 0.8.4-2 (in testing) is attached.
[ Impact ]
If the unblock isn't granted, Bookworm will ship with a version of
waypipe that leaks memory, making long-running sessions
problematic. Since waypipe's job is to provide SSH forwarding (à la "ssh
-X") to software running under Wayland, such long-running sessions are
expected.
[ Tests ]
By running waypipe in debug mode, e.g.
waypipe -d ssh localhost weston-simple-shm 2>&1 | grep "in flight"
one can watch the "number of bytes in flight" messages report an
ever-increasing number of bytes in the version of waypipe in Bookworm
(0.8.4-2). With the fixed version from unstable (0.8.4-3), the number
of bytes in flight remains bounded.
This test was recommended to me by waypipe's upstream author.
[ Risks ]
The fix is a one-line patch, authored by upstream and already released
as part of upstream's version 0.8.6.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034163
[2]
https://gitlab.freedesktop.org/mstoeckl/waypipe/-/commit/9070c4c527c906cb186588ca410d92d2f7f3c7ba
unblock waypipe/0.8.4-3
diff -Nru waypipe-0.8.4/debian/changelog waypipe-0.8.4/debian/changelog
--- waypipe-0.8.4/debian/changelog 2022-11-23 17:11:16.0 +0100
+++ waypipe-0.8.4/debian/changelog 2023-04-10 15:51:36.0 +0200
@@ -1,3 +1,9 @@
+waypipe (0.8.4-3) unstable; urgency=medium
+
+ * Add upstream patch to fix memory leak. (Closes: #1034163)
+
+ -- Gard Spreemann Mon, 10 Apr 2023 15:51:36 +0200
+
waypipe (0.8.4-2) unstable; urgency=medium
* Increase timeout limit for build-time tests. (Closes: #1011322)
diff -Nru waypipe-0.8.4/debian/patches/0001-Fix-a-memory-leak.patch waypipe-0.8.4/debian/patches/0001-Fix-a-memory-leak.patch
--- waypipe-0.8.4/debian/patches/0001-Fix-a-memory-leak.patch 1970-01-01 01:00:00.0 +0100
+++ waypipe-0.8.4/debian/patches/0001-Fix-a-memory-leak.patch 2023-04-10 15:51:36.00000 +0200
@@ -0,0 +1,29 @@
+From: Gard Spreemann
+Date: Mon, 10 Apr 2023 12:21:18 +0200
+Subject: Fix a memory leak
+
+This cherry-picks upstream commit
+9070c4c527c906cb186588ca410d92d2f7f3c7ba. The original commit message
+follows.
+
+This was introduced by a0f6bfa191f55b99e4ff68dd0063aa0c0e12dcbd
+incorrectly checking when to increase the value of
+cxs->last_confirmed_msgno. As a result, one of the two Waypipe
+processes would leak all the messages sent to the other process.
+---
+ src/mainloop.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/mainloop.c b/src/mainloop.c
+index 181319c..38a084d 100644
+--- a/src/mainloop.c
b/src/mainloop.c
+@@ -280,7 +280,7 @@ static int interpret_chanmsg(struct chan_msg_state *cmsg,
+ } else if (type == WMSG_ACK_NBLOCKS) {
+ struct wmsg_ack *ackm = (struct wmsg_ack *)packet;
+ if (msgno_gt(ackm->messages_received,
+-cxs->last_received_msgno)) {
++cxs->last_confirmed_msgno)) {
+ cxs->last_confirmed_msgno = ackm->messages_received;
+ }
+ return 0;
diff -Nru waypipe-0.8.4/debian/patches/series waypipe-0.8.4/debian/patches/series
--- waypipe-0.8.4/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ waypipe-0.8.4/debian/patches/series 2023-04-10 15:51:36.0 +0200
@@ -0,0 +1 @@
+0001-Fix-a-memory-leak.patch
signature.asc
Description: PGP signature
Bug#1034163: waypipe: Leaks memory
Package: waypipe Version: 0.8.4-2 Severity: important X-Debbugs-Cc: g...@nonempty.org Upstream commit 9070c4c527c906cb186588ca410d92d2f7f3c7ba fixes and documents a memory leak [1] present in versions prior to 0.8.6. The leak can be reproduced by running e.g. waypipe -d ssh localhost weston-simple-shm 2>&1 | grep "in flight" and watching the number of bytes in flight steadily increasing as time goes by. [1] https://gitlab.freedesktop.org/mstoeckl/waypipe/-/commit/9070c4c527c906cb186588ca410d92d2f7f3c7ba -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages waypipe depends on: ii libavcodec59 7:5.1.2-3 ii libavutil57 7:5.1.2-3 ii libc6 2.36-8 ii libgbm1 22.3.6-1+deb12u1 ii liblz4-1 1.9.4-1 ii libswscale6 7:5.1.2-3 ii libva22.17.0-1 ii libzstd1 1.5.4+dfsg2-5 Versions of packages waypipe recommends: ii openssh-client 1:9.2p1-2 ii openssh-server 1:9.2p1-2 waypipe suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
Hilmar Preuße writes: > The issue is reported against texlive-binaries: > #922500 . Fair enough - feel free to close #1031949 then. Thanks, and sorry for the noise :-) -- Gard signature.asc Description: PGP signature
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
Norbert Preining writes: >> that my user had set. But it still seems like a bug that postinst fails >> if the system doesn't have a certain locale. Or maybe I'm viewing this >> incorrectly? > > Yes, you do ;-) > > Certain programs, in this case luatex, require correct locale setup to > work. It would be nice if we could detect these problems beforehand and > warn the user with a clear message, but also this is non-trivial. > > If the locale are incorrectly setup, there is not much to do but fail. > > Think about: You could configure to set your shell to > /bin/IamNotThereBash > and it would of course create a lot of problems. Maintainer scripts > cannot work around all possible misconfiguration of a system. Fair enough - you've convinved me :-) But should this bug remain open, with lowered severity and a better title and description, to document this fact for users? Unless there's already a bug covering this matter. Thanks for the help. Best, Gard signature.asc Description: PGP signature
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
Hilmar Preusse writes: > On 25.02.23 Gard Spreemann (g...@nonempty.org) wrote: > > Hi Gard, > >> Installing a combination like >> >> texlive-latex-base texlive-latex-recommended texlive-latex-extra >> texlive-pictures texlive-luatex texlive-pictures-doc >> >> on a fresh Bullseye system with no TeX packages present fails with >> >> Building format(s) --all. >> This may take some time... >> fmtutil failed. Output has been stored in >> /tmp/fmtutil.LCLt5oyh >> Please include this file if you report a bug. >> > > Does [1] describe and (eventually) solve your issue? > Hi Hilmar, It seems to describe it, yes. And I solved it by generating the locales that my user had set. But it still seems like a bug that postinst fails if the system doesn't have a certain locale. Or maybe I'm viewing this incorrectly? Best, Gard signature.asc Description: PGP signature
Bug#1031949: Due to missing locales
On closer inspection, this seems to be due to missing locales. -- Gard signature.asc Description: PGP signature
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
Package: tex-common Version: 6.16 Severity: normal Dear Maintainer, Installing a combination like texlive-latex-base texlive-latex-recommended texlive-latex-extra texlive-pictures texlive-luatex texlive-pictures-doc on a fresh Bullseye system with no TeX packages present fails with Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.LCLt5oyh Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): installed tex-common package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: tex-common E: Sub-process /usr/bin/dpkg returned an error code (1) Bug #1016055 seems related, but was closed as caused by a full filesystem. On my system, the partition in question has hundreds of GB free. The log file mentioned above contains: fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order): fmtutil: /usr/share/texmf/web2c/fmtutil.cnf fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes: fmtutil: /etc/texmf/web2c/fmtutil.cnf fmtutil [INFO]: writing formats under /var/lib/texmf/web2c fmtutil [INFO]: --- remaking luatex with luatex fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ... Unable to read environment locale: exit now. fmtutil [INFO]: --- remaking tex with tex fmtutil: running `tex -ini -jobname=tex -progname=tex tex.ini' ... This is TeX, Version 3.14159265 (TeX Live 2020/Debian) (INITEX) (/usr/share/texlive/texmf-dist/tex/plain/config/tex.ini (/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)) ) Beginning to dump on file tex.fmt (preloaded format=tex 2023.2.25) 2027 strings of total length 29296 4990 memory locations dumped; current usage is 110&4877 926 multiletter control sequences \font\nullfont=nullfont \font\tenrm=cmr10 \font\preloaded=cmr9 \font\preloaded=cmr8 \font\sevenrm=cmr7 \font\preloaded=cmr6 \font\fiverm=cmr5 \font\teni=cmmi10 \font\preloaded=cmmi9 \font\preloaded=cmmi8 \font\seveni=cmmi7 \font\preloaded=cmmi6 \font\fivei=cmmi5 \font\tensy=cmsy10 \font\preloaded=cmsy9 \font\preloaded=cmsy8 \font\sevensy=cmsy7 \font\preloaded=cmsy6 \font\fivesy=cmsy5 \font\tenex=cmex10 \font\preloaded=cmss10 \font\preloaded=cmssq8 \font\preloaded=cmssi10 \font\preloaded=cmssqi8 \font\tenbf=cmbx10 \font\preloaded=cmbx9 \font\preloaded=cmbx8 \font\sevenbf=cmbx7 \font\preloaded=cmbx6 \font\fivebf=cmbx5 \font\tentt=cmtt10 \font\preloaded=cmtt9 \font\preloaded=cmtt8 \font\preloaded=cmsltt10 \font\tensl=cmsl10 \font\preloaded=cmsl9 \font\preloaded=cmsl8 \font\tenit=cmti10 \font\preloaded=cmti9 \font\preloaded=cmti8 \font\preloaded=cmti7 \font\preloaded=cmu10 \font\preloaded=cmmib10 \font\preloaded=cmbsy10 \font\preloaded=cmcsc10 \font\preloaded=cmssbx10 \font\preloaded=cmdunh10 \font\preloaded=cmr7 at 14.51799pt \font\preloaded=cmtt10 at 14.4pt \font\preloaded=cmssbx10 at 14.4pt \font\preloaded=manfnt 14787 words of font info for 50 preloaded fonts 14 hyphenation exceptions Hyphenation trie of length 6075 has 181 ops out of 35111 181 for language 0 No pages of output. Transcript written on tex.log. fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/tex/tex.log fmtutil [INFO]: /var/lib/texmf/web2c/tex/tex.fmt installed. fmtutil [INFO]: --- remaking pdftex with pdftex fmtutil: running `pdftex -ini -jobname=pdftex -progname=pdftex -translate-file=cp227.tcx *pdfetex.ini' ... This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) (INITEX) restricted \write18 enabled. (/usr/share/texlive/texmf-dist/web2c/cp227.tcx) entering extended mode (/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini (/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex) (/usr/share/texlive/texmf-dist/tex/plain/etex/etex.src (/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex [skipping from \patterns to end-of-file...])) (/usr/share/texlive/texmf-dist/tex/plain/etex/etexdefs.lib Skipping module "grouptypes"; Loading module "interactionmodes"; Skipping module "nodetypes"; Skipping module "iftypes";) (/var/lib/texmf/tex/generic/config/language.def (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)) Augmenting the Plain TeX definitions: \tracingall; Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone, register allocation; extended register allocation; Recycling: \addlanguage, \@nswer (not defined), \@sk, \b@dresponsetrue, \b@dresponsefalse, \ch@ckforyn, \mayber@cycle, \et@xabort,
Bug#1031706: optuna: test_create_new_trial randomly fails on s390x
"Rebecca N. Palmer" writes: > test_create_new_trial (both parts) sometimes fails on s390x, failing > the autopkgtest. > > It might make sense to remove this package on s390x, if it isn't > reasonable to actually fix this. Thanks for the report! I've brought this to upstream's attention [1], but I'm a bit confused as the upstream tests seem to make some surprising assumptions about monotonicity of `datetime.now()` [2]. I'll hold off on further investigation until I've figured out whether I've just misunderstood something on their part. In the worst case I'll disable autopkgtests – or this particular test – on s390x. [1] https://github.com/optuna/optuna/issues/4453 [2] https://github.com/optuna/optuna/issues/4455 Best, Gard signature.asc Description: PGP signature
Bug#1030145: r-cran-fastcluster: Missing copyright information
Source: r-cran-fastcluster Version: 1.1.24-1 Severity: normal X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, The upstream author of the package has specified that "all changes from version 1.1.24 on" are copyright Google Inc. [1]. The current d/copyright therefore only accurately represents the situation prior to version 1.1.24-1. [1] https://cran.r-project.org/web/packages/fastcluster/LICENSE signature.asc Description: PGP signature
Bug#1030142: scipy: Has reverted to using bundled copy of L-BFSG-B library
Source: scipy
Version: 1.10.0-2
Severity: normal
Tags: patch
X-Debbugs-Cc: g...@nonempty.org
Dear Maintainer,
Ever since #778635, the SciPy package has carried a patch that makes it
use the system LBFGSB library provided by liblbfgsb0 instead of the
bundled copy that upstream uses. It seems that this patch no longer does
the trick with SciPy's move to building with Meson, as has become
evident with 1.10.0-2 entering unstable:
* python3-scipy no longer depends on liblbfgsb0
*
/usr/lib/python3/dist-packages/scipy/optimize/_lbfgsb.cpython-311-x86_64-linux-gnu.so
has no reference to liblbfgsb.so.0
Attached is an updated patch, to replace the old one with the same name,
that seems to rectify the situation. I have tested that it restores
linking with liblbfgsb.so.0, and that no tests fail.
Best,
Gard
From: Gard Spreemann
Date: Sun, 29 Jan 2023 19:55:15 +0100
Subject: Use system LBFGSB.
---
scipy/optimize/meson.build | 5 +
scipy/optimize/setup.py| 4 +++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/scipy/optimize/meson.build b/scipy/optimize/meson.build
index c7079e7..78a006f 100644
--- a/scipy/optimize/meson.build
+++ b/scipy/optimize/meson.build
@@ -100,15 +100,12 @@ lbfgsb_module = custom_target('lbfgsb_module',
_lbfgsb = py3.extension_module('_lbfgsb',
[
-'lbfgsb_src/lbfgsb.f',
-'lbfgsb_src/linpack.f',
-'lbfgsb_src/timer.f',
lbfgsb_module,
],
c_args: numpy_nodepr_api,
fortran_args: fortran_ignore_warnings,
include_directories: [inc_np, inc_f2py],
- link_args: version_link_args,
+ link_args: version_link_args + ['-llbfgsb'],
dependencies: [lapack, fortranobject_dep],
install: true,
link_language: 'fortran',
diff --git a/scipy/optimize/setup.py b/scipy/optimize/setup.py
index c24ef50..1dabc2b 100644
--- a/scipy/optimize/setup.py
+++ b/scipy/optimize/setup.py
@@ -64,8 +64,10 @@ def configuration(parent_package='', top_path=None):
pre_build_hook = None
lapack = combine_dict(lapack, numpy_nodepr_api)
+lapack.setdefault('libraries', [])
+lapack['libraries'].append('lbfgsb')
-sources = ['lbfgsb.pyf', 'lbfgsb.f', 'linpack.f', 'timer.f']
+sources = ['lbfgsb.pyf']
ext = config.add_extension('_lbfgsb',
sources=[join('lbfgsb_src', x)
for x in sources],
signature.asc
Description: PGP signature
Bug#1028643: Also seems to cause artifacts under XWayland
In addition to the quite negative changes described by others in this bug report – which I fully agree with – it also seems that the new fontconfig version causes a new rendering artifact with emacs running under XWayland. While text rendering wasn't perfect under XWayland before either, the weird color artifacts that now show up make things even worse in my opinion. See attached screenshot. -- Gard signature.asc Description: PGP signature
Bug#1027819: tikzit: Segfaults when pressing the b key
Package: tikzit X-Debbugs-Cc: g...@nonempty.org Version: 2.1.6-3 Severity: normal As reported upstream [1], TikZiT will segfault and crash if one presses the b key. This seems related to a hotkey for a functionality that used to, but no longer does, exist in the program. I am preparing a patch to disable the b key functionality. [1] https://github.com/tikzit/tikzit/issues/140 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tikzit depends on: ii libc6 2.36-7 ii libgcc-s1 12.2.0-11 ii libpoppler-qt5-1 22.08.0-2.1 ii libqt5core5a 5.15.7+dfsg-2 ii libqt5gui55.15.7+dfsg-2 ii libqt5network55.15.7+dfsg-2 ii libqt5widgets55.15.7+dfsg-2 ii libstdc++612.2.0-11 ii tex-common6.18 Versions of packages tikzit recommends: ii preview-latex-style 12.2-1 ii texlive-latex-base 2022.20221123-1 ii texlive-pictures 2022.20221123-1 tikzit suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1027221: python-cmaes: autopkgtest fail with numpy/1.24.1
Sandro Tosi writes: > Hello, > recently numpy/1.24.1 has been uploaded to experimental, and this package > autopkgtest fail when running against it. > > An overview of the upstream changes in the 1.24.x series is available at: > > https://numpy.org/doc/stable/release/1.24.0-notes.html > > Several of the errors are in the form of: > > AttributeError: module 'numpy' has no attribute 'X' > > with X in [float, int, bool, object, ...]. This is because, numpy upstream in > 1.24.0, finally decided to expire > > > https://numpy.org/doc/stable/release/1.24.0-notes.html#:~:text=The%20deprecation%20for%20the%20aliases > > some deprecations introduced in 1.20.0 > > > https://numpy.org/doc/stable/release/1.20.0-notes.html#using-the-aliases-of-builtin-types-like-np-int-is-deprecated > > (released almost 2 years ago). > > All of those are quite straightforward to fix, since often it's just necessary > to stop importing them from numpy and use the python native types. > > Other changes may requires a bit more rework to be addressed. > > Currently numpy/1.24.x is in experimental, but given the possible longer > support > that it'll receive from upstream, we're hopeful to include this in bookworm, > so > your help is necessary to address this bug ASAP. Hi, Thanks for the report. Do you have an example of such a failing autopkgtest? Of the ones on [1], I only see two labeled as using NumPy 1.24.x from experimental (one for x=0, one for x=1). One of them passed [2], and the one that failed [3] seems to have failed not because of deprecated NumPy features, but rather due to the unrelated #1027466 [4]. Am I overlooking something? [1] https://ci.debian.net/packages/p/python-cmaes/unstable/amd64/ [2] https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-cmaes/29522260/log.gz [3] https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-cmaes/29749368/log.gz [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027466 Best, Gard signature.asc Description: PGP signature
Bug#1027466: python-cmaes: flaky autopkgtest: Unreliable test timings
Paul Gevers writes: > I looked at the results of the autopkgtest of your package. I noticed > that it regularly fails on some architectures, particularly on s390x, > but not exclusively there. Yesterday I triggered 5 or 6 reference runs > on every architecture and 6/6 failed on s390x and 1/5 failed on > ppc64el. The error message suggests the solution is to turn deadlines > off. Can you consider doing that? The same error happened at least > once also on amd64, so it's not only the "obscure" release > architectures. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. Thanks a lot for this report. I am making an upload with a patch that bumps the test deadline by an order of magnitude. That seems to fix the flakiness, as far as I can tell. But of course, this failure wasn't 100% reproducible, so please don't hesitate to reopen if the problem persists. Best, Gard signature.asc Description: PGP signature
Bug#1024903: pytorch: CVE-2022-45907: torch.jit.annotations.parse_type_line prone to command injection
Hi,
Turning upstream commit 767f6aa49fe20a2766b9843d01e3b7f7793df6a3 into a
patch seems straightforward on 1.12.1-1 and 1.7.1-7. At least both
versions still build fine with the patch. I will see if I can get around
to running the test soon enough.
Meanwhile, attached are the two corresponding patches.
I don't know if this is worth fixing, since upstream's comments seem to
indicate that the code in question is only for Python 2
compatibility.
Best,
Gard
From: Gard Spreemann
Date: Tue, 29 Nov 2022 17:51:18 +0100
Subject: Do not blindly eval input string
This fix for CVE-2022-45907 is based on upstream commit
767f6aa49fe20a2766b9843d01e3b7f7793df6a3 , whose message follows.
---
commit 767f6aa49fe20a2766b9843d01e3b7f7793df6a3
Author: Nikita Shulga
Date: Thu Nov 17 22:05:27 2022 +
[JIT][Security] Do not blindly eval input string (#89189)
Introduce `_eval_no_call` method, that evaluates statement only if it
does not contain any calls(done by examining the bytecode), thus preventing command injection exploit
Added simple unit test to check for that
`torch.jit.annotations.get_signature` would not result in calling random
code.
Although, this code path exists for Python-2 compatibility, and perhaps
should be simply removed.
Fixes https://github.com/pytorch/pytorch/issues/88868
Pull Request resolved: https://github.com/pytorch/pytorch/pull/89189
Approved by: https://github.com/suo
---
test/test_jit.py | 8
torch/csrc/jit/frontend/script_type_parser.cpp | 2 +-
torch/jit/annotations.py | 14 --
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/test/test_jit.py b/test/test_jit.py
index fb9f6fa..49b51dd 100644
--- a/test/test_jit.py
+++ b/test/test_jit.py
@@ -3422,6 +3422,14 @@ def foo(x):
return a + 2
torch.jit.script(invalid4)
+def test_calls_in_type_annotations(self):
+with self.assertRaisesRegex(RuntimeError, "Type annotation should not contain calls"):
+def spooky(a):
+# type: print("Hello") -> Tensor # noqa: F723
+return a + 2
+print(torch.__file__)
+torch.jit.annotations.get_signature(spooky, None, 1, True)
+
def test_is_optional(self):
ann = Union[List[int], List[float]]
torch._jit_internal.is_optional(ann)
diff --git a/torch/csrc/jit/frontend/script_type_parser.cpp b/torch/csrc/jit/frontend/script_type_parser.cpp
index bec9e87..2e014c9 100644
--- a/torch/csrc/jit/frontend/script_type_parser.cpp
+++ b/torch/csrc/jit/frontend/script_type_parser.cpp
@@ -229,7 +229,7 @@ std::vector ScriptTypeParser::evaluateDefaults(
// We then run constant prop on this graph and check the results are
// constant. This approach avoids having to have separate handling of
// default arguments from standard expressions by piecing together existing
- // machinery for graph generation, constant propgation, and constant
+ // machinery for graph generation, constant propagation, and constant
// extraction.
auto tuple_type = Subscript::create(
r,
diff --git a/torch/jit/annotations.py b/torch/jit/annotations.py
index ba68920..bb09f96 100644
--- a/torch/jit/annotations.py
+++ b/torch/jit/annotations.py
@@ -1,4 +1,5 @@
import ast
+import dis
import enum
import inspect
import re
@@ -135,6 +136,15 @@ def check_fn(fn, loc):
raise torch.jit.frontend.FrontendError(loc, "Expected a single top-level function")
+def _eval_no_call(stmt, glob, loc):
+"""Evaluate statement as long as it does not contain any method/function calls"""
+bytecode = compile(stmt, "", mode="eval")
+for insn in dis.get_instructions(bytecode):
+if "CALL" in insn.opname:
+raise RuntimeError(f"Type annotation should not contain calls, but '{stmt}' does")
+return eval(bytecode, glob, loc) # type: ignore[arg-type] # noqa: P204
+
+
def parse_type_line(type_line, rcb, loc):
"""Parses a type annotation specified as a comment.
@@ -145,7 +155,7 @@ def parse_type_line(type_line, rcb, loc):
arg_ann_str, ret_ann_str = split_type_line(type_line)
try:
-arg_ann = eval(arg_ann_str, {}, EvalEnv(rcb)) # type: ignore # noqa: P204
+arg_ann = _eval_no_call(arg_ann_str, {}, EvalEnv(rcb))
except (NameError, SyntaxError) as e:
raise RuntimeError("Failed to parse the argument list of a type annotation") from e
@@ -153,7 +163,7 @@ def parse_type_line(type_line, rcb, loc):
arg_ann = (arg_ann,)
try:
-ret_ann = eval(ret_ann_str, {}, EvalEnv(rcb)) # type: ignore # noqa: P204
+ret_ann = _eval_no_call(ret_ann_str, {}, EvalEnv(rcb))
except (NameError, SyntaxError) as e:
raise RuntimeError("Failed to parse the
Bug#1022308:
Hi, I have verified that adding libglu1-mesa-dev to the build-deps makes the package again build successfully. -- Gard signature.asc Description: PGP signature
Bug#1002638: ITP
Hi, This seems immensely useful! I've started packaging [1], and will upload shortly. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017994 -- Gard signature.asc Description: PGP signature
Bug#1017994: ITP: zigpy -- Python Zigbee stack
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Gard Spreemann Severity: wishlist * Package name: zigpy Version : 0.50.1 Upstream Author : Russell Cloran and contributors * URL : https://github.com/zigpy/zigpy * License : GPL-3+ Programming Lang: Python Description : Python Zigbee stack zigpy is a hardware independent Zigbee protocol stack integration project to implement Zigbee standard specifications as a Python 3 library. Zigbee integration via zigpy allows you to connect one of many off-the-shelf Zigbee Coordinator adapters using one of the available Zigbee radio library modules compatible with zigpy to control Zigbee based devices. There is currently support for controlling Zigbee device types such as binary sensors (e.g., motion and door sensors), sensors (e.g., temperature sensors), lights, switches, buttons, covers, fans, climate control equipment, locks, and intruder alarm system devices. The package is useful for interacting over the increasingly widespread Zigbee home automation and IoT protocol. An RFP was made last year [1]. I intend to maintain the package myself. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002638 signature.asc Description: PGP signature
Bug#1016535: Merge request
A merge request that accomplishes this has been filed on Salsa: https://salsa.debian.org/debian/ns3/-/merge_requests/4 -- Gard signature.asc Description: PGP signature
Bug#1016535: ns3: Please enable building of version module
Source: ns3
X-Debbugs-Cc: g...@nonempty.org
Version: 3.36.1+dfsg-4
Severity: wishlist
Dear Maintainer,
As of upstream 3.32, ns3 comes with an optional "version" module
[1]. This module gives run-time access to ns3 version information [2].
The module is useful, and I encourage you to please enable its building
and inclusion into the Debian package. Due to upstream's convoluted
build system ("helpfully" trying to extract this information from
git(!)), it's a bit of a struggle. I have a working suggestion that I'll
create a Salsa merge request for shortly.
[1] https://www.nsnam.org/docs/tutorial/html/getting-started.html#build-version
[2] https://www.nsnam.org/docs/release/3.36/doxygen/classns3_1_1_version.html
Best,
Gard
signature.asc
Description: PGP signature
Bug#1003165: Is march=native used for anything but probing the compiler?
Hi, > I admit I'm not sure at what point / what tool might inject this > string and I'm also not sure whether the option -march=native is > really used in the amd64 case. From my (very limited!) understanding, this is just setuptools(?) trying out various compiler options. The actual C compiler invocations look more à la: x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.10/sklearn/ensemble/_hist_gradient_boosting/_bitset.o -Lbuild/temp.linux-x86_64-3.10 -o /<>/.pybuild/cpython3_3.10/build/sklearn/ensemble/_hist_gradient_boosting/_bitset.cpython-310-x86_64-linux-gnu.so -fopenmp Moreover, the build finishes with: ### EXT COMPILER OPTIMIZATION ### Platform : Architecture: x64 Compiler: gcc CPU baseline : Requested : 'min' Enabled : SSE SSE2 SSE3 Flags : -msse -msse2 -msse3 Extra checks: none CPU dispatch : Requested : 'max -xop -fma4' Enabled : SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_KNL AVX512_KNM AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL Generated : none CCompilerOpt.cache_flush[809] : write cache to path -> /<>/build/temp.linux-x86_64-3.10/ccompiler_opt_cache_ext.py ### CLIB COMPILER OPTIMIZATION ### Platform : Architecture: x64 Compiler: gcc CPU baseline : Requested : 'min' Enabled : SSE SSE2 SSE3 Flags : -msse -msse2 -msse3 Extra checks: none CPU dispatch : Requested : 'max -xop -fma4' Enabled : SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_KNL AVX512_KNM AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL Generated : none ... and similarly on armel. I don't know the internal magic of these tools at all, but it seems superficially plausible that the march=native invocations are just instances of the compiler being probed. -- Gard signature.asc Description: PGP signature
Bug#1000755: stellarium: Dialog boxes cause segfault crash under Wayland
Bernhard Übelacker writes: > Control: tags -1 - moreinfo unreproducible > > > Hello Gard, > tried to reproduce on real hardware with an older Intel integrated > graphics, but It still did not crash for me, sorry. > > One thing to test might be to add another user and check if the crash > happens there too. > > Otherwise the maintainer might be able to reproduce. Very strange! Thanks for checking. I'll see if I can find any more clues. Best, Gard signature.asc Description: PGP signature
Bug#1000755: stellarium: Dialog boxes cause segfault crash under Wayland
Bernhard Übelacker writes: > Control: tags -1 + moreinfo unreproducible > > > Hello Gard, > I tried to reproduce the issue with current bookworm/testing. > But inside a minimal VM running a plasma wayland session following > the given steps I was not able to trigger the crash any more. > This was with stellarium 0.22.1-1. > > Can you still observe this crash at your side? Hi, Still reproducible here on 0.22.1-1, , sorry to say. Could it be that this is some kind of video hardware issue? I'm seeing this on Intel graphics. Best, Gard signature.asc Description: PGP signature
Bug#1013318: [pkg-gnupg-maint] Behavioral change for pinentry-qt 1.2.0-1
Daniel Kahn Gillmor writes:
> On Thu 2022-06-23 12:24:30 +0200, Gard Spreemann wrote:
>
>> Just needed to wait for my account to be approved. It's done now:
>> https://dev.gnupg.org/T6041
>
> Thanks for this! On that bug report, Ingo linked it to this proposed
> patch from qlyiss on https://dev.gnupg.org/D549 :
>
>
> Index: qt/pinentrydialog.cpp
> ===
> --- qt/pinentrydialog.cpp
> +++ qt/pinentrydialog.cpp
> @@ -280,6 +280,7 @@
> mainLayout->addLayout(hbox);
> mainLayout->addStretch(1);
> mainLayout->addWidget(buttons);
> +mainLayout->setSizeConstraint(QLayout::SetFixedSize);
>
> auto capsLockWatcher = new CapsLockWatcher{this};
> connect(capsLockWatcher, ::stateChanged,
>
>
> This seems much more narrowly targeted! Gard, can you test this against
> 1.2.0? If you can confirm that it works for you, i'd be happy to patch
> the debian package.
Hah, that is indeed a lot simpler – and I can confirm that it works :-)
Thanks!
Best,
Gard
signature.asc
Description: PGP signature
Bug#1012664: already opened issue upstream (https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/97)
On June 23, 2022 8:57:58 AM GMT+02:00, "Thomas Löscher" wrote: >Hello, > >there is already an open issue on upstream project: >https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/97 > >perhaps, if more people express a need for this modification, it will >get some attention. >best regards >Thomas Thanks! I have no idea how I missed that! -- Gard -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1013338: ITP: optuna -- Hyperparameter optimization framework
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Gard Spreemann X-Debbugs-Cc: g...@nonempty.org Severity: wishlist * Package name: optuna Version : 2.10.0 Upstream Author : Preferred Networks, Inc. * URL : https://optuna.org/ * License : Expat Programming Lang: Python Description : Hyperparameter optimization framework Optuna is a Python library for hyperparameter (or other "black box") optimization. Being framework-independent, it works with a variety of deep learning frameworks. I plan to maintain the package myself. Although, considering its popularity, I will consider team-maintenance within the math team if the burden becomes too big. signature.asc Description: PGP signature
Bug#1013337: ITP: python-cmaes -- Python implementation of CMA-ES algorithms
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Gard Spreemann X-Debbugs-Cc: g...@nonempty.org Severity: wishlist * Package name: python-cmaes Version : 0.8.2 Upstream Author : CybgerAgent Inc. * URL : https://github.com/CyberAgentAILab/cmaes/ * License : Expat Programming Lang: Python Description : Python implementation of CMA-ES algorithms Lightweight Covariance Matrix Adaptation Evolution Strategy (CMA-ES) implementation based on arXiv:1604.00772. I will maintain the package myself. Its usefulness stems primarily from being a dependency of Optuna, which I also aim to package. signature.asc Description: PGP signature
Bug#1013318: pinentry-qt: Dialog window no longer floats under Sway
Package: pinentry-qt
X-Debbugs-Cc: g...@nonempty.org
Version: 1.2.0-1
Severity: normal
Dear Maintainer,
With pinentry-qt 1.1.0-4, running
echo getpin | pinentry-qt --display "Test"
would display a *floating* dialog box under the Sway WM. This is the
desired behavior. As of 1.2.0-1, it instead displays a "full-size"/tiled
window.
I bisected through upstream's later commits, and found that
dd9f765258230cad6704afb4fab6c3deb4a8de56
fixes the problem. I'm including a patch based on
8f239a2b133cae8ca9c1876c732d4e00d06c7d26
7d5c123f802abce11c711d57e8796d58d6ff1a16
dd9f765258230cad6704afb4fab6c3deb4a8de56
(read top to bottom) that I have confirmed fixes the problem. I'll also
place an MR on Salsa.
Best,
Gard
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-1-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pinentry-qt depends on:
ii libassuan0 2.5.5-3
ii libc6 2.33-7
ii libgcc-s1 12.1.0-2
ii libgpg-error0 1.45-2
ii libncursesw66.3+20220423-2
ii libqt5core5a5.15.2+dfsg-16+b2
ii libqt5gui5 5.15.2+dfsg-16+b2
ii libqt5widgets5 5.15.2+dfsg-16+b2
ii libstdc++6 12.1.0-2
ii libtinfo6 6.3+20220423-2
pinentry-qt recommends no packages.
Versions of packages pinentry-qt suggests:
pn pinentry-doc
-- no debconf information
From: Gard Spreemann
Date: Tue, 21 Jun 2022 16:37:46 +0200
Subject: Fix floating behavior
At some point, pinentry-qt stopped producing a floating dialog box
under Sway (and perhaps other tiling Wayland WMs). Instead, it
produced a full-blown window.
The problem is fixed upstream as of dd9f765. We here cherry-pick
changes from upstream's
8f239a2b133cae8ca9c1876c732d4e00d06c7d26
7d5c123f802abce11c711d57e8796d58d6ff1a16
dd9f765258230cad6704afb4fab6c3deb4a8de56
in order to fix the behavior.
---
qt/pinentrydialog.cpp | 199 +++---
1 file changed, 106 insertions(+), 93 deletions(-)
diff --git a/qt/pinentrydialog.cpp b/qt/pinentrydialog.cpp
index 53e394f..73caca6 100644
--- a/qt/pinentrydialog.cpp
+++ b/qt/pinentrydialog.cpp
@@ -106,6 +106,7 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name,
mRepeat(NULL),
mRepeatError{nullptr},
_grabbed(false),
+ _have_quality_bar{enable_quality_bar},
_disable_echo_allowed(true),
mEnforceConstraints(false),
mFormatPassphrase{false},
@@ -125,58 +126,125 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name,
setWindowModality(Qt::ApplicationModal);
}
+QPalette redTextPalette;
+redTextPalette.setColor(QPalette::WindowText, Qt::red);
+
+auto *const mainLayout = new QVBoxLayout{this};
+
+auto *const hbox = new QHBoxLayout;
+
_icon = new QLabel(this);
_icon->setPixmap(icon());
+hbox->addWidget(_icon, 0, Qt::AlignVCenter | Qt::AlignLeft);
-QPalette redTextPalette;
-redTextPalette.setColor(QPalette::WindowText, Qt::red);
+auto *const grid = new QGridLayout;
+int row = 1;
_error = new QLabel(this);
_error->setPalette(redTextPalette);
_error->hide();
+grid->addWidget(_error, row, 1, 1, 2);
+
+row++;
+_desc = new QLabel(this);
+_desc->hide();
+grid->addWidget(_desc, row, 1, 1, 2);
+row++;
mCapsLockHint = new QLabel(this);
mCapsLockHint->setPalette(redTextPalette);
mCapsLockHint->setAlignment(Qt::AlignCenter);
mCapsLockHint->setVisible(false);
+grid->addWidget(mCapsLockHint, row, 1, 1, 2);
-_desc = new QLabel(this);
-_desc->hide();
-
-_prompt = new QLabel(this);
-_prompt->hide();
+row++;
+{
+_prompt = new QLabel(this);
+_prompt->hide();
+grid->addWidget(_prompt, row, 1);
-_edit = new PinLineEdit(this);
-_edit->setMaxLength(256);
-_edit->setMinimumWidth(_edit->fontMetrics().averageCharWidth()*20 + 48);
-_edit->setEchoMode(QLineEdit::Password);
+const auto l = new QHBoxLayout;
+_edit = new PinLineEdit(this);
+_edit->setMaxLength(256);
+_edit->setMinimumWidth(_edit->fontMetrics().averageCharWidth()*20 + 48);
+_edit->setEchoMode(QLineEdit::Password);
+_prompt->setBuddy(_edit);
+l->addWidget(_edit, 1);
-_prompt->setBuddy(_edit);
+if (!repeatString.isNull()) {
+mGenerateButton = new QPushButton{this};
+mGenerateButton->setIcon(QIcon(QLatin1String(":/icons/password-generate")));
+
Bug#1012664: Rudamentary patch
A prebuilt package with the patch can be found at https://nonempty.org/packages/sid/network-manager-openvpn/ -- Gard signature.asc Description: PGP signature
Bug#1012664: Rudamentary patch
Hello,
I'm also affected by this bug. Inspection of the upstream code shows
that the NetworkManager OpenVPN plugin has no notion of the
--data-ciphers flag of OpenVPN. The previously used --cipher flag, which
NM does know about, used to imply appending the cipher to the
--data-ciphers list, but that is no longer the case as of OpenVPN 2.6 [1].
I've attached a very rudamentary patch that adds support for
--data-ciphers to network-manager-openvpn, and passes the corresponding
string on as an OpenVPN argument. The patch is a bit crude, and treats
--data-ciphers _exactly_ like --ciphers was already treated. That might
not be appropriate, as the former has the structure of a colon-separated
list, and any GUI/TUI interface might want to reflect that
visually/functionally. My patch treats it as an opaque string.
With the patch, one can in a network-manager-openvpn VPN connection add
an entry of the form
data-ciphers = WHATEVER
to the .data field of the VPN connection, and WHATEVER will be passed on
to OpenVPN's --data-ciphers argument.
I'll try to have this patch upstreamed, but in the meantime it might be
appropriate for inclusion into Debian so as not to break people's
NM-managed VPN connections upon upgrading OpenVPN.
PS: Simon, you incidate that you are having trouble due to being
unfamiliar with Debian packaging. Do let me know if you'd like me to
provide a precompiled package with the patch included.
[1]
https://github.com/OpenVPN/openvpn/blob/0dbcaba4f301c21e68a5cd032a4b56eb75c17c37/Changes.rst
Best,
Gard
From: Gard Spreemann
Date: Tue, 21 Jun 2022 11:20:25 +0200
Subject: Add support for OpenVPN's --data-ciphers
---
properties/import-export.c| 11 +++
properties/tests/test-import-export.c | 12
shared/nm-service-defines.h | 1 +
shared/utils.h| 1 +
src/nm-openvpn-service.c | 3 +++
5 files changed, 28 insertions(+)
diff --git a/properties/import-export.c b/properties/import-export.c
index 51049de..2ab3bf3 100644
--- a/properties/import-export.c
+++ b/properties/import-export.c
@@ -1344,6 +1344,15 @@ do_import (const char *path, const char *contents, gsize contents_len, GError **
continue;
}
+ if (NM_IN_STRSET (params[0], NMV_OVPN_TAG_DATA_CIPHERS)) {
+ if (!args_params_check_nargs_n (params, 1, _error))
+goto handle_line_error;
+ if (!args_params_check_arg_utf8 (params, 1, NULL, _error))
+goto handle_line_error;
+ setting_vpn_add_data_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS, params[1]);
+ continue;
+ }
+
if (NM_IN_STRSET (params[0], NMV_OVPN_TAG_TLS_CIPHER)) {
if (!args_params_check_nargs_n (params, 1, _error))
goto handle_line_error;
@@ -2103,6 +2112,8 @@ do_export_create (NMConnection *connection, const char *path, GError **error)
args_write_line_setting_value (f, NMV_OVPN_TAG_CIPHER, s_vpn, NM_OPENVPN_KEY_CIPHER);
+ args_write_line_setting_value (f, NMV_OVPN_TAG_DATA_CIPHERS, s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS);
+
args_write_line_setting_value (f, NMV_OVPN_TAG_TLS_CIPHER, s_vpn, NM_OPENVPN_KEY_TLS_CIPHER);
args_write_line_setting_value_int (f, NMV_OVPN_TAG_KEYSIZE, s_vpn, NM_OPENVPN_KEY_KEYSIZE);
diff --git a/properties/tests/test-import-export.c b/properties/tests/test-import-export.c
index cefb2b1..369b61e 100644
--- a/properties/tests/test-import-export.c
+++ b/properties/tests/test-import-export.c
@@ -226,6 +226,7 @@ test_password_import (void)
_check_item (s_vpn, NM_OPENVPN_KEY_TA, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_TA_DIR, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_CIPHER, "AES-256-CBC");
+ _check_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_LOCAL_IP, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_REMOTE_IP, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_AUTH, NULL);
@@ -319,6 +320,7 @@ test_tls_import (void)
_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY_DIRECTION, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_CIPHER, NULL);
+ _check_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_LOCAL_IP, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_REMOTE_IP, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_AUTH, NULL);
@@ -366,6 +368,7 @@ test_tls_import_2 (void)
_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY_DIRECTION, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_CIPHER, NULL);
+ _check_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_LOCAL_IP, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_REMOTE_IP, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_AUTH, NULL);
@@ -410,6 +413,7 @@ test_tls_import_3 (void)
_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY_DIRECTION, NULL);
_check_item (s_vpn, NM_OPENVPN_KEY_CIPHER, NULL);
+ _check_item (s_vpn, NM_OPENVPN_KEY_DATA_CIP
Bug#1013123: librust-bindgen-dev: Fails to build bindings against libraries that include SSE intrinsics headers
Package: librust-bindgen-dev X-Debbugs-Cc: g...@nonempty.org Version: 0.59.2-2+b1 Severity: normal Dear Maintainer, Bindgen fails to generate bindings for C code that includes SSE intrinsics headers like emmintrin.h: /usr/lib/llvm-13/lib/clang/13.0.1/include/emmintrin.h:2374:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size /usr/lib/llvm-13/lib/clang/13.0.1/include/emmintrin.h:2394:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size /usr/lib/llvm-13/lib/clang/13.0.1/include/emmintrin.h:2414:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size /usr/lib/llvm-13/lib/clang/13.0.1/include/emmintrin.h:2434:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size /usr/lib/llvm-13/lib/clang/13.0.1/include/emmintrin.h:2374:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size, err: true /usr/lib/llvm-13/lib/clang/13.0.1/include/emmintrin.h:2394:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size, err: true /usr/lib/llvm-13/lib/clang/13.0.1/include/emmintrin.h:2414:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size, err: true /usr/lib/llvm-13/lib/clang/13.0.1/include/emmintrin.h:2434:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size, err: true thread 'main' panicked at 'Unable to generate bindings.: ()', build.rs:15:10 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace This bug report is meant as documentation, as it seems that 0.60.1 (already in sid) fixes the issue. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-1-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librust-bindgen-dev depends on: ii clang1:13.0-54 ii librust-bitflags-dev [librust-bitflags-1+default-dev]1.3.2-2 ii librust-cexpr-dev [librust-cexpr-0.6+default-dev]0.6.0-2 pn librust-clang-sys-1+clang-6-0-dev ii librust-clang-sys-dev [librust-clang-sys-1+default-dev] 1.3.0-1 ii librust-lazy-static-dev [librust-lazy-static-1+default-dev] 1.4.0-1 ii librust-lazycell-dev [librust-lazycell-1+default-dev]1.3.0-3 ii librust-peeking-take-while-dev [librust-peeking-take-while-0.1+ 0.1.2-1+b1 ii librust-proc-macro2-dev [librust-proc-macro2-1-dev] 1.0.28-1 ii librust-quote-dev [librust-quote-1-dev] 1.0.9-1 ii librust-regex+unicode-dev [librust-regex-1+unicode-dev] 1.5.5-1 ii librust-regex-dev [librust-regex-1+std-dev] 1.5.5-1 ii librust-rustc-hash-dev [librust-rustc-hash-1+default-dev]1.1.0-1 ii librust-shlex-dev [librust-shlex-0.1+default-dev]0.1.1-1+b1 Versions of packages librust-bindgen-dev recommends: ii librust-bindgen+default-dev 0.59.2-2+b1 Versions of packages librust-bindgen-dev suggests: ii librust-bindgen+clap-dev0.59.2-2+b1 ii librust-bindgen+env-logger-dev 0.59.2-2+b1 ii librust-bindgen+log-dev 0.59.2-2+b1 ii librust-bindgen+logging-dev 0.59.2-2+b1 ii librust-bindgen+runtime-dev 0.59.2-2+b1 pn librust-bindgen+static-dev ii librust-bindgen+which-dev 0.59.2-2+b1 -- no debconf information signature.asc Description: PGP signature
Bug#1012773: gudhi: drops libtbb dependency when built with 2021.5.0
Graham Inggs writes: > Source: gudhi > Version: 3.5.0+dfsg-2 > Severity: important > > Hi Maintainer > > When gudhi was recently binNMU'd for the onetbb transition, it > silently lost its dependency on libtbb. Compare the "Depends:" line > of the python3-gudhi binary package in the most recent build log [1], > to the previous one [2]. > > I did not find any errors in the most recent log, but I did notice > that the lines below, from the previous log, were missing. > > Regards > Graham > > > [1] > https://buildd.debian.org/status/fetch.php?pkg=gudhi=amd64=3.5.0%2Bdfsg-2%2Bb1=1655137074=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=gudhi=amd64=3.5.0%2Bdfsg-2=1651405629=0 > > > -- Performing Test TBB_without_pthread > -- Performing Test TBB_without_pthread - Failed > -- Performing Test TBB_with_pthread > -- Performing Test TBB_with_pthread - Success > -- Found Intel TBB > TBB found in /usr/lib/x86_64-linux-gnu Hello, Thanks a lot for this report. Upstream is aware of the problem [1], and I will work with them to try to rectify it. [1] https://github.com/GUDHI/gudhi-devel/issues/511 Best, Gard signature.asc Description: PGP signature
Bug#1012712: ITP: ai -- PHP library to develop easily SQL queries usable in web pages
Georges Khaznadar writes: > Package: wnpp > Severity: wishlist > Owner: Georges Khaznadar > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: ai > Version : 0.03 > Upstream Author : François Élie > * URL : https://gitlab.adullact.net/felie/ai > * License : AGPL > Programming Lang: PHP > Description : PHP library to develop easily SQL queries usable in web > pages > > AI is an Allmighty Intelligence: just think about the SQL query which > you would use in MySQL's command line, or in phpmyadmin, and AI offers you > the right code to display its results in a web page. Unfortunately, AI > can not yet read your mind directly: you've got to type the query. Hi, The proposed very generic, two-letter source package name "ai" seems like too prime namespace real estate for something like this, being an established initialism for a well-known and entirely unrelated concept. How about something along the lines of "allmighty-intelligence"? Best, Gard signature.asc Description: PGP signature
Bug#1012270: opentyrian: New upstream version available
Source: opentyrian X-Debbugs-Cc: g...@nonempty.org Version: 2.1.20130907+dfsg-4 Severity: wishlist Dear Maintainer, In March, upstream made its first new release in years. In addition to general improvements, two changes are of particular interest to Debian: * The game now uses SDL2 * The macosx/ directory that was the reason for the DFSG repack has been dropped Please consider updating the package to the 2.1.20220318 release. I'm happy to help, but couldn't figure out the branch structure on Salsa. signature.asc Description: PGP signature
Bug#1011322: waypipe: ftbfs on riscv64 (Timeout: 2)
Bo YU writes: > On Fri, May 20, 2022 at 02:35:45PM +0200, Gard Spreemann wrote: >>Hello, and thanks you the bug report and patch. >> >>Bo YU writes: >> >>> […] >>> >>> The attached patch is simple to disable tests like mips do that. >>> >>> If you need me to do more test, please let me know. >> >>I believe upstream has made changes that look like they might deal with >>the test failures on all architectures. From >>https://gitlab.freedesktop.org/mstoeckl/waypipe/ it looks like commits >> >> ffd2d4379e481372ca6240f4b3bcedbd943dec4c >> >> 15aab5c344636336f5327d91d3e6a92733503312 >> >>might do the trick (on all architectures). I was waiting for upstream to >>make a new release with those changes, but they haven't yet. If you >>could cherry-pick those two commits and see if they fix the bug on >>riscv64, then that would be most appreciated. Thanks! > > Ok, very happy to do it:) > > But there is some trickes for me: how to cherry-pick these commits > into package that is come from `apt source`? > > One way is put the two commits into one patch and apply it into > d/patches? I think the way you're suggesting is a good idea. That's anyway how I'd represent the commits when applying the fix to the Debian package. Thanks! PS: This shouldn't be a high priority. At some point, upstream will surely release a new version with these fixes in place, obsoleting the patch :-) Best, Gard signature.asc Description: PGP signature
Bug#1011322: waypipe: ftbfs on riscv64 (Timeout: 2)
Hello, and thanks you the bug report and patch. Bo YU writes: > Package: waypipe > Version: 0.8.2-3 > Severity: normal > Tags: ftbfs, patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > > Dear Maintainer, > > The waypipe package has a ftbfs issue on riscv64 arch: > > […] > > The attached patch is simple to disable tests like mips do that. > > If you need me to do more test, please let me know. I believe upstream has made changes that look like they might deal with the test failures on all architectures. From https://gitlab.freedesktop.org/mstoeckl/waypipe/ it looks like commits ffd2d4379e481372ca6240f4b3bcedbd943dec4c 15aab5c344636336f5327d91d3e6a92733503312 might do the trick (on all architectures). I was waiting for upstream to make a new release with those changes, but they haven't yet. If you could cherry-pick those two commits and see if they fix the bug on riscv64, then that would be most appreciated. Thanks! Best, Gard signature.asc Description: PGP signature
Bug#987360: swaylock: Occassional unlock without password entered
X-Debbugs-CC: pe...@riseup.net Pelle writes: >>I cannot answer for Pelle, but I was also experiencing this bug back >>when it was reported. FWIW: I'm unable to reproduce it with 1.6-1. That >>being said, triggering the bug does seem somewhat stochastic, so I can't >>rule out that a bunch more suspend/resume cycles would trigger it. But >>so far, so good! > > Same here, no crashes recently, yay, Great! > however, I think that this crash bug illustrates the more general > issue that the lock screen is bypassed on any crash. Swaylock should > be able to restart itself on failure, perhaps with a daemon. There > could be more vulnerabilities of this class, right? I believe > XScreensaver has a strategy for mitigating these types of vulns too. Indeed. I believe this is what Jonas was referring to when he linked to https://github.com/swaywm/sway/pull/6879 (it is about Sway supporting an extension to the Wayland protocol for performing this kind of locking reliably). This is of course the right way forward, but for now, I think we at least should downgrade the severity of this bug and let swaylock re-enter testing. Best, Gard signature.asc Description: PGP signature
Bug#1009303: imv: Upstream homepage has moved, and incorrect watch file
Package: imv Version: 4.3.0-1 Severity: minor X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, The package currently has Homepage: https://github.com/eXeC64/imv while upstream has moved to https://sr.ht/~exec64/imv/ This also causes d/watch to monitor stale sources for new releases. -- Gard signature.asc Description: PGP signature
Bug#987360: swaylock: Occassional unlock without password entered
X-Debbugs-CC: d...@jones.dk,pe...@riseup.net Hi all. Jonas Smedegaard writes: > Hi Pelle, > > You reported this issue for swaylock 1.5-2. > > Do you still experience same isue with swaylock 1.6-1 now in Debian > unstable? I cannot answer for Pelle, but I was also experiencing this bug back when it was reported. FWIW: I'm unable to reproduce it with 1.6-1. That being said, triggering the bug does seem somewhat stochastic, so I can't rule out that a bunch more suspend/resume cycles would trigger it. But so far, so good! > Perhaps sensible to lower severity of this issue, to allow more exposure > to it in Debian testing - and then hopefully close it for good soon, > when work on ext-session-lock-v1 is finalized: > https://github.com/swaywm/sway/pull/6879 I agree; I think we can lower the severity and let swaylock back into testing, and just raise the severity back up if anyone is able to reproduce on 1.6-1. Best, Gard signature.asc Description: PGP signature
Bug#1009022: Duplicate?
Is this the same as #1006543? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006543 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1006543: NMU
I've done an NMU to DELAYED/5. A debdiff is attached, and the changes
have been pushed to the salsa branch that the aforementioned MR refers
to.
diff -Nru imv-4.3.0/debian/changelog imv-4.3.0/debian/changelog
--- imv-4.3.0/debian/changelog 2021-10-31 17:53:45.0 +0100
+++ imv-4.3.0/debian/changelog 2022-04-07 09:15:36.0 +0200
@@ -1,3 +1,11 @@
+imv (4.3.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * d/patches: add 0002-Fix-segfault-with-latest-wlroots.patch to fix
+segfault with newer wlroots (Closes: #1006543)
+
+ -- Gard Spreemann Thu, 07 Apr 2022 09:15:36 +0200
+
imv (4.3.0-1) unstable; urgency=medium
* New upstream version 4.3.0.
diff -Nru imv-4.3.0/debian/patches/0002-Fix-segfault-with-latest-wlroots.patch imv-4.3.0/debian/patches/0002-Fix-segfault-with-latest-wlroots.patch
--- imv-4.3.0/debian/patches/0002-Fix-segfault-with-latest-wlroots.patch 1970-01-01 01:00:00.0 +0100
+++ imv-4.3.0/debian/patches/0002-Fix-segfault-with-latest-wlroots.patch 2022-04-06 13:19:10.0 +0200
@@ -0,0 +1,45 @@
+From: Gard Spreemann
+Date: Wed, 6 Apr 2022 13:18:10 +0200
+Subject: Fix segfault with latest wlroots
+
+For fixing #1006543.
+
+Based on upstream commit 00d07c0a103fbf685473c73ef676f73c52fd371a.
+---
+ src/wl_window.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/src/wl_window.c b/src/wl_window.c
+index d7025d2..5efa42f 100644
+--- a/src/wl_window.c
b/src/wl_window.c
+@@ -18,6 +18,8 @@
+ #include
+ #include "xdg-shell-client-protocol.h"
+
++#define imv_min(a,b) ((a) > (b) ? (b) : (a))
++
+ struct imv_window {
+ struct wl_display*wl_display;
+ struct wl_registry *wl_registry;
+@@ -502,16 +504,20 @@ static void on_global(void *data, struct wl_registry *registry, uint32_t id,
+ struct imv_window *window = data;
+
+ if (!strcmp(interface, "wl_compositor")) {
++version = imv_min(version, 4);
+ window->wl_compositor =
+ wl_registry_bind(registry, id, _compositor_interface, version);
+ } else if (!strcmp(interface, "xdg_wm_base")) {
++version = imv_min(version, 2);
+ window->wl_xdg =
+ wl_registry_bind(registry, id, _wm_base_interface, version);
+ xdg_wm_base_add_listener(window->wl_xdg, _listener_xdg, window);
+ } else if (!strcmp(interface, "wl_seat")) {
++version = imv_min(version, 7);
+ window->wl_seat = wl_registry_bind(registry, id, _seat_interface, version);
+ wl_seat_add_listener(window->wl_seat, _listener, window);
+ } else if (!strcmp(interface, "wl_output")) {
++version = imv_min(version, 3);
+ struct output_data *output_data = calloc(1, sizeof *output_data);
+ output_data->wl_output = wl_registry_bind(registry, id, _output_interface, version);
+ output_data->pending_scale = 1;
diff -Nru imv-4.3.0/debian/patches/series imv-4.3.0/debian/patches/series
--- imv-4.3.0/debian/patches/series 2021-10-31 17:53:45.0 +0100
+++ imv-4.3.0/debian/patches/series 2022-04-06 13:19:10.0 +0200
@@ -1 +1,2 @@
call-imv-from-libexec.patch
+0002-Fix-segfault-with-latest-wlroots.patch
Best,
Gard
Bug#1006543: Patch
I've made an MR on Salsa with a patch that I have verified fixes the bug[1]. Although, as has been mentioned, the best thing is probably just to package upstream's 4.3.1. But since this bug has been around for a while, I will do an NMU to DELAYED/5 with the fix from the MR if I don't hear back in the next few days. [1] https://salsa.debian.org/debian-phototools-team/imv/-/merge_requests/2 Best, Gard
Bug#1004782: A patch
Hello,
Attached is a patch with which the package successfully build with
FFMPEG 7:5.0-3 from experimental.
*NOTE:* The patch is FUNCTIONALLY UNTESTED. It's based on my limited
understanding of the recommended replacements for deprecated and removed
FFMPEG functionality. If someone could test it, or suggest a good way
for me to do so, that would be great. I have never used the video
features of Caffe, so I would need to know what to try out.
Best,
Gard
From: Gard Spreemann
Date: Fri, 11 Feb 2022 20:59:35 +0100
Subject: FFMPEG 5.0 support
---
caffe2/video/video_decoder.cc | 77 ++-
caffe2/video/video_decoder.h | 1 +
2 files changed, 55 insertions(+), 23 deletions(-)
diff --git a/caffe2/video/video_decoder.cc b/caffe2/video/video_decoder.cc
index d40bc05..9ab7271 100644
--- a/caffe2/video/video_decoder.cc
+++ b/caffe2/video/video_decoder.cc
@@ -12,8 +12,10 @@ VideoDecoder::VideoDecoder() {
static std::mutex gMutex;
std::unique_lock lock(gMutex);
if (!gInitialized) {
+#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(58, 10, 100)
av_register_all();
avcodec_register_all();
+#endif
avformat_network_init();
gInitialized = true;
}
@@ -27,8 +29,20 @@ void VideoDecoder::getAudioSample(
Callback& callback,
const Params& params) {
int frame_finished = 0;
- auto result = avcodec_decode_audio4(
- audioCodecContext_, audioStreamFrame_, _finished, );
+
+ int result = avcodec_send_packet(audioCodecContext_, );
+ if (result < 0) {
+LOG(ERROR) << "Failed to decode audio packet: " << ffmpegErrorStr(result);
+return;
+ }
+ result = avcodec_receive_frame(audioCodecContext_, audioStreamFrame_);
+ if (result == 0) {
+frame_finished = 1;
+ }
+ else if (result < 0 && result != AVERROR(EAGAIN) && result != AVERROR_EOF) {
+LOG(ERROR) << "Failed to decode audio packet: " << ffmpegErrorStr(result);
+return;
+ }
if (frame_finished) {
// from
@@ -185,12 +199,12 @@ void VideoDecoder::decodeLoop(
if (params.streamIndex_ == -1) {
for (int i = 0; i < inputContext->nb_streams; i++) {
auto stream = inputContext->streams[i];
-if (stream->codec->codec_type == AVMEDIA_TYPE_VIDEO &&
+if (stream->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
videoStreamIndex_ == -1) {
videoStreamIndex_ = i;
videoStream_ = stream;
} else if (
-stream->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
+stream->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
audioStreamIndex_ == -1) {
audioStreamIndex_ = i;
}
@@ -207,7 +221,11 @@ void VideoDecoder::decodeLoop(
// Initialize codec
AVDictionary* opts = nullptr;
-videoCodecContext_ = videoStream_->codec;
+ret = avcodec_parameters_to_context(videoCodecContext_, videoStream_->codecpar);
+if (ret < 0) {
+ LOG(ERROR) << "Cannot get codec context from parameters";
+ return;
+}
try {
ret = avcodec_open2(
videoCodecContext_,
@@ -226,7 +244,11 @@ void VideoDecoder::decodeLoop(
if (params.getAudio_ && audioStreamIndex_ >= 0) {
// see e.g. ridge/decoder/StreamDecoder.cpp
- audioCodecContext_ = inputContext->streams[audioStreamIndex_]->codec;
+ ret = avcodec_parameters_to_context(audioCodecContext_, inputContext->streams[audioStreamIndex_]->codecpar);
+ if (ret < 0) {
+LOG(ERROR) << "Failed to get codec parameters: " << ffmpegErrorStr(ret);
+return;
+ }
ret = avcodec_open2(
audioCodecContext_,
avcodec_find_decoder(audioCodecContext_->codec_id),
@@ -452,12 +474,12 @@ void VideoDecoder::decodeLoop(
ret = av_read_frame(inputContext, );
if (ret == AVERROR_EOF) {
eof = 1;
-av_free_packet();
+av_packet_unref();
packet.data = nullptr;
packet.size = 0;
// stay in the while loop to flush frames
} else if (ret == AVERROR(EAGAIN)) {
-av_free_packet();
+av_packet_unref();
continue;
} else if (ret < 0) {
LOG(ERROR) << "Error reading packet : " << ffmpegErrorStr(ret);
@@ -483,13 +505,17 @@ void VideoDecoder::decodeLoop(
}
if (si != videoStreamIndex_) {
-av_free_packet();
+av_packet_unref();
continue;
}
}
-ret = avcodec_decode_video2(
-videoCodecContext_, videoStreamFrame_, , );
+ret = avcodec_send_packet(videoCodecContext_, );
+if (ret < 0) {
+ LOG(ERROR) << "Error decoding video frame : " <
Bug#1005062: looking-glass: Bundles library that is present in Debian
Source: looking-glass Version: 0+b4+dfsg.1-1 Severity: normal Dear Maintainer, looking-glass's upstream bundles some external code as git submodules, and the Debian package uses these. In the time since looking-glass entered the archive, one of those bundled libraries – relacy – also became part of Debian as librelacy-dev. The version of relacy provided by librelacy-dev and the one bundled in looking-glass seem to be identical, and looking-glass should therefore use the Debian package. -- Gard
Bug#1005061: looking-glass-client: Please package new upstream version
Package: looking-glass-client Severity: wishlist Dear Maintainer, Upstream has released the "b5" version. It would be great if the package could be updated to that version. PS: It seems that something is broken with the package's d/watch, as uscan seems to think the "b5-rc1" version is the latest upstream. -- Gard
Bug#1004782: Upstream bug report
Hi, This is related to the video decoder in caffe2/video/video_decoder.cc using long-deprecated parts of the FFMPEG API that were finally dropped in 5.0. I filed a bug upstream [1] where I also gave a partial patch that takes care of some of the changes. Someone upstream more knowledgeable about the video decoder in Caffe2 should deal with replacing avcodec_decode_video2 and friends with avcodec_receive_frame though (a purely mechanical change there might be a bit harder). Since the bug is present also in upstream's git HEAD, and is confined to a single file, it should be quite easy to backport a fix as soon as one appears upstream. I'll monitor upstream. [1] https://github.com/pytorch/pytorch/issues/72254 -- Gard
Bug#1002879: python3-pot: ships /usr/lib/python3/dist-packages/benchmarks/*.py
Andreas Beckmann writes: > Package: python3-pot > Version: 0.8.1+dfsg-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > python3-pot ships python scripts with generic names at a generic > location, causing file conflicts with packages doing the same mistake: > > /usr/lib/python3/dist-packages/benchmarks > /usr/lib/python3/dist-packages/benchmarks/__init__.py > /usr/lib/python3/dist-packages/benchmarks/benchmark.py > /usr/lib/python3/dist-packages/benchmarks/emd.py > /usr/lib/python3/dist-packages/benchmarks/sinkhorn_knopp.py > > Either these should not be shipped at all or they should be moved > to a package specific subdirectory. Thank you for noticing and reporting this! They should not have been shipped at all. I'll get a new version out ASAP, and also notify upstream. Best, Gard signature.asc Description: PGP signature
Bug#1000755: stellarium: Dialog boxes cause segfault crash under Wayland
Package: stellarium Version: 0.20.4-3 Severity: important X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, When using Stellarium under Wayland, certain file picker dialogs cause Stellarium to segfault. The bug is perhaps in Qt, but since I am unable to reproduce it with any other Qt program (I tried several), I am filing a bug for Stellarium since that is where I can observe it. Steps to reproduce: 1: Launch Stellarium under Wayland (QT_QPA_PLATFORM=wayland). 2: Observe that much of the program works just fine. 3: Open a file picker dialog, such as under View -> Landscape -> Add/Remove -> Install a new landscape from a zip archive. 4: Observe segfault. The same steps work fine under X11. A backtrace follows. -- Backtrace -- #0 QDialogButtonBoxPrivate::layoutButtons (this=0x64867cb0) at widgets/qdialogbuttonbox.cpp:270 #1 0x77b1bfd4 in QDialogButtonBoxPrivate::resetLayout (this=) at widgets/qdialogbuttonbox.cpp:218 #2 0x77ba0bb2 in Ui_QFileDialog::setupUi (this=0x63fb4290, QFileDialog=0x7fffcd10) at .uic/ui_qfiledialog.h:238 #3 0x77b9afaf in QFileDialogPrivate::createWidgets (this=0x64047b40) at dialogs/qfiledialog.cpp:3110 #4 0x77b9c770 in QFileDialogPrivate::init (this=0x64047b40, args=...) at dialogs/qfiledialog.cpp:3040 #5 0x77b9d41d in QFileDialog::QFileDialog (this=0x7fffcd10, args=...) at dialogs/qfiledialog.cpp:390 #6 0x77b9d4e2 in QFileDialog::getOpenFileUrl (parent=parent@entry=0x0, caption=..., dir=..., filter=..., selectedFilter=selectedFilter@entry=0x0, options=..., supportedSchemes=...) at dialogs/qfiledialog.cpp:2259 #7 0x77b9d7b2 in QFileDialog::getOpenFileName (parent=parent@entry=0x0, caption=..., dir=..., filter=..., selectedFilter=selectedFilter@entry=0x0, options=...) at dialogs/qfiledialog.cpp:2210 #8 0x55893c4e in AddRemoveLandscapesDialog::browseForArchiveClicked (this=0x6406c810) at ./src/gui/AddRemoveLandscapesDialog.cpp:118 #9 0x76907df8 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x77a7 in QAbstractButton::clicked (this=this@entry=0x6385e270, _t1=) at .moc/moc_qabstractbutton.cpp:308 #11 0x77a7249a in QAbstractButtonPrivate::emitClicked (this=0x62bd6260) at widgets/qabstractbutton.cpp:415 #12 0x77a74060 in QAbstractButtonPrivate::click (this=0x62bd6260) at widgets/qabstractbutton.cpp:408 #13 0x77a74283 in QAbstractButton::mouseReleaseEvent (this=0x6385e270, e=0x7fffd520) at widgets/qabstractbutton.cpp:1044 #14 0x779c131e in QWidget::event (this=0x6385e270, event=0x7fffd520) at kernel/qwidget.cpp:9019 #15 0x7797f6af in QApplicationPrivate::notify_helper (this=this@entry=0x566df060, receiver=receiver@entry=0x6385e270, e=e@entry=0x7fffd520) at kernel/qapplication.cpp:3632 #16 0x779871b4 in QApplication::notify (this=, receiver=0x6385e270, e=0x7fffd520) at kernel/qapplication.cpp:3076 #17 0x768d175a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x77985cc3 in QApplicationPrivate::sendMouseEvent (receiver=0x6385e270, event=event@entry=0x7fffd520, alienWidget=alienWidget@entry=0x6385e270, nativeWidget=0x63456d60, buttonDown=buttonDown@entry=0x7fffd4b8, lastMouseReceiver=..., spontaneous=true, onlyDispatchEnterLeave=false) at kernel/qapplication.cpp:2614 #19 0x77ca6256 in QGraphicsProxyWidgetPrivate::sendWidgetMouseEvent (this=0x63faaa10, event=0x7fffd8a0) at graphicsview/qgraphicsproxywidget.cpp:309 #20 0x77c90188 in QGraphicsItem::sceneEvent (this=0x647fc3e0, event=0x7fffd8a0) at graphicsview/qgraphicsitem.cpp:6928 #21 0x77cb2d71 in QGraphicsScenePrivate::sendMouseEvent (this=this@entry=0x56ac5290, mouseEvent=mouseEvent@entry=0x7fffd8a0) at graphicsview/qgraphicsscene.cpp:1335 #22 0x77cb88fc in QGraphicsScene::mouseReleaseEvent (this=, mouseEvent=0x7fffd8a0) at graphicsview/qgraphicsscene.cpp:4123 #23 0x77cc54f1 in QGraphicsScene::event (this=0x56892c60, event=0x7fffd8a0) at graphicsview/qgraphicsscene.cpp:3436 #24 0x7797f6af in QApplicationPrivate::notify_helper (this=, receiver=0x56892c60, e=0x7fffd8a0) at kernel/qapplication.cpp:3632 #25 0x768d175a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #26 0x77ce2cc0 in QGraphicsView::mouseReleaseEvent (this=0x7fffe5d0, event=0x7fffde50) at graphicsview/qgraphicsview.cpp:3430 #27 0x779c131e in QWidget::event (this=0x7fffe5d0, event=0x7fffde50) at kernel/qwidget.cpp:9019 #28 0x77a6d74e in QFrame::event (this=0x7fffe5d0, e=0x7fffde50) at widgets/qframe.cpp:550 #29 0x768d14c2 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from
Bug#1000708: python3-pot: Incompatible numpy version
Thanks for pointing this out, Marc! Stupid oversight on my part. Uploading a fix with the ABI dependency now. Best, Gard Marc Glisse writes: > Package: python3-pot > Version: 0.8.0+dfsg-2+b1 > Severity: normal > > Dear Maintainer, > > trying to use POT, I see > > $ python3 > Python 3.9.9 (main, Nov 16 2021, 10:24:31) > [GCC 11.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. import ot > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/ot/__init__.py", line 26, in > from . import lp > File "/usr/lib/python3/dist-packages/ot/lp/__init__.py", line 22, in > > from .emd_wrap import emd_c, check_result, emd_1d_sorted > File "ot/lp/emd_wrap.pyx", line 1, in init ot.lp.emd_wrap > ValueError: numpy.ndarray size changed, may indicate binary incompatibility. > Expected 88 from C header, got 80 from PyObject > > Maybe this package needs a dependency like python3-numpy-abi9? I am > surprised lintian doesn't report missing-dependency-on-numpy-abi for > this package if that's the case. > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing-debug > APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, > 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), > (50, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.15.0-1-amd64 (SMP w/16 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages python3-pot depends on: > ii libc6 2.32-4 > ii libgcc-s1 11.2.0-10 > ii libgomp1 11.2.0-10 > ii libstdc++6 11.2.0-10 > ii python33.9.7-1 > ii python3-numpy 1:1.19.5-1 > ii python3-scipy 1.7.1-2 > > Versions of packages python3-pot recommends: > ii python3-sklearn 0.23.2-5 > > python3-pot suggests no packages. > > -- no debconf information signature.asc Description: PGP signature
Bug#984270: Bug persists on arm64
Reopening because the patch did not properly fix the issue on arm64. The patch has been updated in 5efbe42a on Salsa. -- Gard signature.asc Description: PGP signature
Bug#984270: Fix uploaded to salsa
I believe Salsa commit ba393a45 [1] fixes this bug. However, other build problems relating to the shipped symbols prevent me from uploading the fixed version. [1] https://salsa.debian.org/deeplearning-team/onednn signature.asc Description: PGP signature
Bug#998244: lists.debian.org: request for debian-math mailing list
Hi, I would subscribe and contribute to the discussion on the debian-math list if it were created. Best, Gard signature.asc Description: PGP signature
Bug#939405: Waypipe packaging
Gard Spreemann writes: > Hi Birger, > > In 2019 you filed an ITP for Waypipe (#939405 [1]). It doesn't seem that > the packaging was finished. I would be more than happy to take over the > packaging and maintenance, or to assist you, if you need any help. > > Let me know! > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939405 I've prepared a package here that works well: https://salsa.debian.org/gspr/waypipe/ I won't upload until/if I get your blessing, I don't wanna step on your feet here :-) Best, Gard signature.asc Description: PGP signature
Bug#996244: multimedia-devel: Recommended package libphat-dev is no longer a relevant recommendation
Package: multimedia-devel X-Debbugs-Cc: g...@nonempty.org Version: 0.10 Severity: minor Dear Maintainer, Once upon a time, src:phat and its libphat-dev were multimedia-related packages. The latter is recommended by multimedia-devel. These packages were removed from Debian in 2014 [1]. Since they were removed due to being abandoned upstream, I in 2019 decided to re-use the names src:phat and libphat-dev for an entirely unrelated package also named PHAT [2]. I did not then or since notice that multimedia-devel still recommends libphat-dev. It should not do so. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751276 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920912 Regards, Gard signature.asc Description: PGP signature
Bug#995776: libns3-dev: ns3++ helper script uses wrong path
Package: libns3-dev X-Debbugs-Cc: g...@nonempty.org Version: 3.31+dfsg-3 Severity: normal Dear Maintainer, libns3-dev ships /usr/bin/ns3++, a Debian-specific helper script that is meant to call g++ with NS3's sometimes finicky compiler flags. That helper script hasn't been updated since before the multi-arch days, and therefore fails as it looks for shared objects in /usr/lib instead of the currently used /usr/lib/ARCHITECTURE-TRIPLET. I have submitted merge request #3 on Salsa with a proposed fix. -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libns3-dev depends on: ii g++ 4:10.2.1-1 ii libns3-3v5 3.31+dfsg-3 libns3-dev recommends no packages. libns3-dev suggests no packages.
Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents
Diederik de Haas writes: > I only looked at the pdf and it's a very nice start, thanks! > > […] Thanks for the feedback. Daniel Lange's email made me think that there should perhaps be an authoritative version of the text, from which PDF, whatever-printable, HTML, etc. can be generated (using for example pandoc)? -- Gard signature.asc Description: PGP signature
Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents
Diederik de Haas writes: > I wanted to print the Debian Social Contract, which turned out to be WAY > more difficult then I expected and then it should be. > > So I went to https://www.debian.org/social_contract and wanted to print > that. Apparently there isn't a print stylesheet for it, so if you print > that, you also get 'Blog', 'Micronews', 'Planet' and a search box. > Of course I didn't mind the Debian logo. > The last page (of the print preview) shows that it's available in a whole > bunch of languages, which is good, but undesirable for a print version. > And then you get a bunch of links, also undesirable for a print version. > > Then I went looking for a PDF version and didn't find anything. > > I did find a 'social-contract.txt.gz' (why compressed?), but that's > missing any form of nice formatting (that the webpage does have). > I did try 'zcat ' and editing that in > LibreOffice Writer, but apparently I've lost my skills in office > programs, so I bailed on that. Are any of these helpful? I'm happy to do more iterations – perhaps using LuaLaTeX and better fonts? This is so far just rushed lunch-work: https://nonempty.org/~gspr/social.tex https://nonempty.org/~gspr/social.pdf -- Gard signature.asc Description: PGP signature
Bug#993031: ripser FTCBFS: hard codes the build architecture compiler
Thanks! Including your patch in a new upload now. -- Gard
Bug#987360: Help needed?
I'm sad to see that we shipped Bullseye without an essential component of Sway. Is there anything I can do to assist in getting this bug fixed, perhaps for a potential future bullseye-packports package? -- Gard signature.asc Description: PGP signature
Bug#989381: lintian: spelling-error-in-copyright is triggering on names
Package: lintian Version: 2.104.0 Severity: normal X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, Lintian is triggering spelling-error-in-copyright upon seeing my first name (Gard) in the copyright field of some packages (example: [1]). It suggests that I should be named Guard instead. A bug filed with my parents was closed with wontfix, so I'll try the second best thing. I do not know how one would go about exempting names from such spellchecks, but could one perhaps at least whitelist the known quantity that is the maintainer's name? The bug seems at least superficially similar to #922233. [1] https://lintian.debian.org/sources/python-cdsapi Best, Gard -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.2-2 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.9 ii dpkg-dev1.20.9 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.39 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.9 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012001-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.1-4 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl -- no debconf information
Bug#987883: unblock: clblast/1.5.2-2
Subject: unblock: clblast/1.5.2-2 Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: g...@nonempty.org Severity: normal Please unblock package clblast [ Reason ] During discussion of #949767, a capitalization typo was discovered in libclblast-dev. The one non-cosmetic impact of this typo is that users that expect to be able to find the library using CMake are unable to, unless they reproduce the typo. This is documented as bug #987881, which clblast/1.5.2-2 fixes. [ Impact ] Unless unblocked, users of libclblast-dev will be unable to find the library in the expected way provided by upstream unless they are aware of the bug and work around it by reproducing the typo in third-party code. [ Tests ] The patch introduced in clblast/1.5.2-2 touches only the installation path of a CMake file, plus three purely cosmetic occurrences in *code comments only*. The new installation path has been verified as correct. [ Risks ] The patch touches only a single character in a single installation path, and three lines of code *comments*. I consider it to be risk-free. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing [ Other info ] None. unblock clblast/1.5.2-2 clblast.debdiff Description: Binary data signature.asc Description: PGP signature
Bug#987881: libclblast-dev: Capitalization typo hinders detection and use through CMake
Subject: libclblast-dev: Capitalization typo hinders detection and use through CMake Package: libclblast-dev X-Debbugs-Cc: g...@nonempty.org Version: 1.5.2-1 Severity: important During discussion of bug #949767, a capitalization typo was uncovered in libclblast-dev. This typo causes CLBlast's CLBlastConfig.cmake to be installed at a misspelled location, which in turn hinders third parties from discovering the library through CMake. This severely limits the use of libclblast-dev in many cases, warranting a severity of Important. The fix has been forwarded upstream [1]. [1] https://github.com/CNugteren/CLBlast/pull/417 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libclblast-dev depends on: ii libclblast1 1.5.2-1 ii ocl-icd-opencl-dev [opencl-dev] 2.2.14-2 libclblast-dev recommends no packages. libclblast-dev suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#949767: arrayfire update fails in configure step
Gard Spreemann writes: > Gard Spreemann writes: > >> Andreas Tille writes: >> >>> Hi Aaron, >>> >>> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote: >>>> Please try adding a build dependency on libclfft-dev and replacing >>>> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call >>>> to >>>> >>>> find_package(clFFT) >>>> >>>> > Thanks a lot for your initial hint >>> >>> Thanks again. I now tried to learn from this and added a similar patch >>> for CLBLast[1] but as you can see in the new log[2] it is not that >>> simple. I tried to compare the content of >>> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb >>> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking >>> like and I need to admit I have no idea why this fails. >> >> This seems to be just a typo on my part. The logs have >> >> *** >> CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package): >> By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has >> asked CMake to find a package configuration file provided by "CLBLast", but >> CMake did not find one. >> Could not find a package configuration file provided by "CLBLast" with any >> of the following names: >> CLBLastConfig.cmake >> clblast-config.cmake >> Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set >> "CLBLast_DIR" to a directory containing one of the above files. If >> "CLBLast" provides a separate development package or SDK, be sure it has >> been installed. >> *** >> >> libclblast-dev ships >> >> /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake >> >> Notice that there's both "CLBLast" and "CLBlast" in there! I'll >> investigate. > > Looks like an upstream bug; consider the inconsistent capitalization of > the second l in "clblast" online 363 in > > > https://salsa.debian.org/gspr/clblast/-/blob/54e86eec37593623a5f692a39d78355043a402ad/CMakeLists.txt#L363 > > I'll report it upstream and patch src:clblast. Could you try with the patch from the debian/gspr/typo branch of [1]? Alternatively, I put a built version of the patched clblast up at [2]. [1] https://salsa.debian.org/gspr/clblast.git [2] https://nonempty.org/~gspr/clblast-typo/ Best, Gard signature.asc Description: PGP signature
Bug#949767: arrayfire update fails in configure step
Gard Spreemann writes: > Andreas Tille writes: > >> Hi Aaron, >> >> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote: >>> Please try adding a build dependency on libclfft-dev and replacing >>> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call >>> to >>> >>> find_package(clFFT) >>> >>> > Thanks a lot for your initial hint >> >> Thanks again. I now tried to learn from this and added a similar patch >> for CLBLast[1] but as you can see in the new log[2] it is not that >> simple. I tried to compare the content of >> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb >> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking >> like and I need to admit I have no idea why this fails. > > This seems to be just a typo on my part. The logs have > > *** > CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package): > By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by "CLBLast", but > CMake did not find one. > Could not find a package configuration file provided by "CLBLast" with any > of the following names: > CLBLastConfig.cmake > clblast-config.cmake > Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set > "CLBLast_DIR" to a directory containing one of the above files. If > "CLBLast" provides a separate development package or SDK, be sure it has > been installed. > *** > > libclblast-dev ships > > /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake > > Notice that there's both "CLBLast" and "CLBlast" in there! I'll > investigate. Looks like an upstream bug; consider the inconsistent capitalization of the second l in "clblast" online 363 in https://salsa.debian.org/gspr/clblast/-/blob/54e86eec37593623a5f692a39d78355043a402ad/CMakeLists.txt#L363 I'll report it upstream and patch src:clblast. Best, Gard
Bug#949767: arrayfire update fails in configure step
Andreas Tille writes: > Hi Aaron, > > On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote: >> Please try adding a build dependency on libclfft-dev and replacing >> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call >> to >> >> find_package(clFFT) >> >> > Thanks a lot for your initial hint > > Thanks again. I now tried to learn from this and added a similar patch > for CLBLast[1] but as you can see in the new log[2] it is not that > simple. I tried to compare the content of > libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb > how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking > like and I need to admit I have no idea why this fails. This seems to be just a typo on my part. The logs have *** CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package): By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "CLBLast", but CMake did not find one. Could not find a package configuration file provided by "CLBLast" with any of the following names: CLBLastConfig.cmake clblast-config.cmake Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set "CLBLast_DIR" to a directory containing one of the above files. If "CLBLast" provides a separate development package or SDK, be sure it has been installed. *** libclblast-dev ships /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake Notice that there's both "CLBLast" and "CLBlast" in there! I'll investigate. Best, Gard
Bug#987670: jami: Fails to start on Wayland (also with XWayland available)
Package: jami X-Debbugs-Cc: g...@nonempty.org Version: 20210104.4.dda80df~ds1-1 Severity: normal Dear Maintainer, jami-gnome fails to start under Wayland, even when XWayland is available and other GTK applications run fine. Trying to start it results in $ jami-gnome ** Message: 15:59:46.531: Jami GNOME client version: f6d50ba8bd027d9d02964f0954b40275c472267b ** Message: 15:59:46.531: git ref: unknown (jami-gnome:88955): Clutter-Gtk-ERROR **: 15:59:46.535: *** Unsupported backend. zsh: trace trap jami-gnome -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jami depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 pn jami-daemon ii libayatana-appindicator3-1 0.5.5-2 ii libc62.31-11 ii libcairo21.16.0-5 pn libcanberra-gtk3-0 ii libcanberra0 0.30-7 pn libclutter-1.0-0 pn libclutter-gtk-1.0-0 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-3 ii libnm0 1.30.0-2 ii libnotify4 0.7.9-3 ii libpango-1.0-0 1.46.2-3 ii libqrencode4 4.1.1-1 ii libqt5core5a 5.15.2+dfsg-5 ii libqt5dbus5 5.15.2+dfsg-5 ii libqt5gui5 5.15.2+dfsg-5 ii libqt5sql5 5.15.2+dfsg-5 ii libqt5sql5-sqlite5.15.2+dfsg-5 ii libstdc++6 10.2.1-6 ii libwebkit2gtk-4.0-37 2.30.6-1 ii libx11-6 2:1.7.0-2 jami recommends no packages. jami suggests no packages. signature.asc Description: PGP signature
Bug#949767: arrayfire update fails in configure step
Andreas Tille writes: > Hi, > > I personally have no interest in arrayfire but I realised that the > Debian packaged version depends clblas (and is the only remaining > package that needs cblas and I would like to see it removed from Debian > due to bug #949767) Hi, FWIW: It seems that arrayfire (which I know nothing about in general) has support [1,2] for using clblast (with a t) as an alternative to clblas. We do have a clblast package [3]. Could that be a way forward? [1] https://github.com/arrayfire/arrayfire/pull/1727 [2] https://github.com/arrayfire/arrayfire/issues/1956 [3] https://tracker.debian.org/pkg/clblast -- Gard signature.asc Description: PGP signature
Bug#985728: ITP: howdy -- Infrared Facial Authentication Module for Linux
Lem Severein writes: > Hey Gard, > > Thanks for the helpful links, I fully understand your concern. > > I can do away with the numpy and opencv installs through the (much more > outdated) python-numpy and python-opencv debian packages respectively. > However, dlib does not seem to have such a package yet and having to > maintain that would be out of scope for me. I'm only a dlib user, not a > contributor, and i don't think it would be my place to package it. https://tracker.debian.org/pkg/dlib ? Or is this a different dlib? > However, dlib is available through pip and running that command would be > idempotent. OK, but your package cannot rely on stuff installed through pip! > (I wrongly hit "Reply" instead of "Reply All" in my last email, thanks for > letting me know) No problem. And I hope I'm not coming across as too negative; I just wanna make sure you're not wasting a lot of effort on packaging something that ends up being undistributable in Debian :-) -- Gard signature.asc Description: PGP signature
Bug#985728: ITP: howdy -- Infrared Facial Authentication Module for Linux
Lem Severein writes: > Unfortunately the dlib compilation step is necessary to be executed on the > machine itself. The build automatically enables certain hardware > accelerations, depending on system components. I think people would be quite upset with a d/postinst script that not only builds third-party software (already a problem), but also reaches out to the internet to fetch said software (without even getting into the fact that the authenticity of the downloaded software is not verified, which is a separate problem independent of Debian). Additionally, the current maintainer scripts don't look very idempotent (Policy § 6.2 [1]). > If complete offline installation is a must I could move the dlib into the > Howdy deb file. Not sure how that would work license wise. This sounds like a violation of Policy § 4.13 [2]. If the local dlib compilation is indeed a requirement for this package, I would hazard a guess that it is not distributable in Debian. [1] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#maintainer-scripts-idempotency [2] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies Best, Gard signature.asc Description: PGP signature
Bug#985728: ITP: howdy -- Infrared Facial Authentication Module for Linux
Lem Severein writes: > Version 3.0.0 will introduce large changes and make Howdy a lot more > mature. I think it's time to try and package it within the main debian > archive. > > I am the main developer and maintainer of this package, and i > intend to continue to support Howdy. I'm not sure in what team > this package would fit, but a sponsor would be nice. Maybe this is already covered under the discussion of the more mature version 3 coming up, but: the shenanigans going on in the postinst script (like downloading stuff from the internet) seem to me quite worrisome. Best, Gard signature.asc Description: PGP signature
Bug#985189: ITP: et -- Eternal Terminal (ET) is a remote shell that automatically reconnects without interrupting the session.
Jason Gauci writes: > Package name: et > Version : 6.1.4 > Upstream Author : Jason Gauci > URL : https://eternalterminal.dev/ > License : Apache > Programming Lang: C++ > Description : Eternal Terminal (ET) is a remote shell that > automatically reconnects without interrupting the session. > > Eternal Terminal (ET) is a remote shell that automatically reconnects without > interrupting the session. Hi, Might it be sensible to consider the full name "eternalterminal" (or "eternal-terminal") for this package? This would take pressure off the two-letter package name space, without giving up much (any?) discoverability. -- Gard signature.asc Description: PGP signature
Bug#940613: Any updates?
Hi, I see version 1.0 of this software was just released, and has been making its way around the web. It looks really neat! Do you think you'll be interested in picking back up your packaging efforts for after the Bullseye release? I'm happy to lend a hand. Best, Gard
Bug#983517: pytorch: Build documentation
Source: pytorch Version: 1.7.1-7 Severity: wishlist X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, It would be nice to have a python-torch-doc package with the HTML documentation available, if it's not a complicated process. This is of course not urgent. I can look into the matter after the Bullseye release. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#980917: libpmix-dev fails to upgrade from 3.2.2~rc1-1 to 4.0.0-4
Package: libpmix-dev X-Debbugs-Cc: g...@nonempty.org Version: 4.0.0-4 Severity: serious Justification: Policy 7.6 Dear Maintainer, Upgrading libpmix-dev from 3.2.2~rc1-1 to 4.0.0-4 fails with dpkg: error processing archive /tmp/apt-dpkg-install-xYYyH5/070-libpmix-dev_4.0.0-4_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/pmix2/lib/libmca_common_dstore.so', which is also in package libpmix2:amd64 3.2.2~rc1-1 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpmix-dev depends on: iu libpmix2 4.0.0-4 libpmix-dev recommends no packages. libpmix-dev suggests no packages. signature.asc Description: PGP signature
Bug#980538: elpa-company should recommend clang
David Bremner writes: > Gard Spreemann writes: > >> David Bremner writes: >> >>> Can you try with a more minimal init file? I don't have clang installed, >>> and I don't see that failure. > >> Note that I see the error when starting company-mode in a buffer that's >> in c++-mode. If the buffer is in for example fundamental-mode, I can >> start company-mode without problems. > > Ah, that makes sense. I can duplicate that. > > Clang is pretty heavyweight for a recommends. For me it was going to > install another 300+ MB of disk space. That would be OK if most people > were installing company for C++ development, but I guess that's not > really the case. > > We could certainly add a suggests (for what little that is worth) or > perhaps disable company-clang by default. That sounds very reasonable. At least that'll be a hint to a user experiencing the error message. Thanks. -- Gard
Bug#980538: elpa-company should recommend clang
David Bremner writes: > Can you try with a more minimal init file? I don't have clang installed, > and I don't see that failure. I'm seeing the same error on a different machine with default emacs settings, where I freshly installed emacs and elpa-company, and where the ~/.emacs file is empty. Note that I see the error when starting company-mode in a buffer that's in c++-mode. If the buffer is in for example fundamental-mode, I can start company-mode without problems. -- Gard
Bug#980538: elpa-company should recommend clang
Package: elpa-company Version: 0.9.13-1 Severity: normal Dear Maintainer, If elpa-company is installed on a system where clang is not available, starting company-mode fails with Company backend ’company-clang’ could not be initialized: Company found no clang executable I believe it would be helpful if the package would recommend the clang package. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-company depends on: ii dh-elpa-helper 2.0.6 ii emacsen-common 3.0.4 elpa-company recommends no packages. elpa-company suggests no packages. -- no debconf information
Bug#978191: gudhi: FTBFS: Tangential_complex.h:957:40: error: no type named ‘Power_center_d’ in ‘Gudhi::tangential_complex::Tangential_complex, CGAL::Dynamic
Thank you for reporting this. It also revealed an upstream bug, which has been forwarded. I'm uploading a fix now. Best, Gard
Bug#977907:
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-de...@lists.debian.org, g...@nonempty.org * Package name: CLBlast Version : 1.5.1 Upstream Author : Cedric Nugteren and others * URL : https://cnugteren.github.io/clblast/clblast.html * License : Apache-2.0 Programming Lang: C++ Description : Tuned OpenCL BLAS library CLBlast is an OpenCL BLAS library that often can sometimes offer better performance than the clblas that's already in the archive. I will maintain the package, although I might also reach out to the science team.
Bug#975534: foot: Ship terminfo files in separate package with fewer dependencies
Source: foot Version: 1.5.3-1 Severity: wishlist X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, Foot comes with some terminfo files that for a better experience can be installed on systems that a user expects to SSH into from a foot terminal elsewhere. The foot package in Debian currently ships these files – /usr/share/terminfo/f/foot* – as part of the foot binary package. It would be nice if these could be split out into a separate foot-terminfo package for people who want to install only these on a remote machine without having to install the dependencies of the main foot package. Thanks. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#973309: See also ITP bug
You may also want to check out the ITP bug #923851 [1], in particular
the observation in message 10 ("780 MB and 3285 files" sounds like a
very hard packaging job).
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923851
Best,
Gard
Bug#972686: python3-gudhi: EagerPy support should be enabled
Package: python3-gudhi Version: 3.3.0+dfsg-3 Severity: wishlist X-Debbugs-Cc: g...@nonempty.org GUDHI's Python interface can work with EagerPy [1]. Support for this will be enabled in the package when the EagerPy package enters Debian (#972680). This bug documents the missing feature until then. [1] https://eagerpy.jonasrauber.de/ -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-3-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-gudhi depends on: ii libc6 2.31-4 ii libgcc-s1 10.2.0-15 ii libgmp10 2:6.2.0+dfsg-6 ii libmpfr6 4.1.0-3 ii libstdc++6 10.2.0-15 ii libtbb22020.3-1 ii python33.8.2-3 ii python3-numpy 1:1.19.2-2+b1 Versions of packages python3-gudhi recommends: ii python3-matplotlib 3.3.2-1+b1 ii python3-pot 0.7.0+dfsg-2+b1 ii python3-scipy 1.5.2-2+b1 ii python3-sklearn 0.23.2-3 python3-gudhi suggests no packages. -- no debconf information
Bug#972680: ITP: eagerpy -- Wrapper around various Python multidimensional array types
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-de...@lists.debian.org, g...@nonempty.org * Package name: eagerpy Version : 0.29.0 Upstream Author : Jonas Rauber * URL : https://eagerpy.jonasrauber.de/ * License : MIT Programming Lang: Python Description : Wrapper around various Python multidimensional array types EagerPy is a Python framework that lets you write code that automatically works natively with PyTorch, TensorFlow, JAX, and NumPy. The package is useful because it allows you to abstract away various types of multidimensional arrays and write common code. I will maintain the package, although I might also reach out to the science team.
Bug#972009: gudhi ftbfs with python3.9 as supported python version
Matthias Klose writes: > Package: src:gudhi > Version: 3.3.0+dfsg-1 > Severity: important > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: python3.9 > > seem to be a packaging error Indeed! Thanks for reporting. I think I know what's wrong, and will get to it soon.
Bug#969543: Related bug
Indeed. This seems to be related to #421344 [1]. Deleting the config symlink and reinstalling works. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421344 --- Gard
Bug#969543: solaar: Solaar should autostart with --window=hide
Package: solaar Version: 1.0.3+dfsg-1 Severity: normal X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, As of recently, solaar seems to be autostarting both on the system tray and as a standalone application window. Upstream ships share/autostart/solaar.desktop. It starts solaar with the --window=hide option, which causes it to launch without the main application window. This seems like a more appropriate behavior, but the Debian package instead installs a /etc/xdg/autostart/solaar.desktop that launches solaar without said option. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-3-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages solaar depends on: ii adduser 3.118 ii debconf [debconf-2.0]1.5.74 ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2 ii gir1.2-gtk-3.0 3.24.22-1 ii gir1.2-notify-0.70.7.9-1 ii passwd 1:4.8.1-1 ii python3 3.8.2-3 ii python3-gi 3.36.1-1 ii python3-pyudev 0.21.0-3 ii udev 246.3-1 Versions of packages solaar recommends: ii python3-dbus 1.2.16-3 ii upower0.99.11-2 solaar suggests no packages. -- debconf information excluded
