Bug#1069780: RM: luajit2 -- ROM; ROM; duplicate source
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: luaj...@packages.debian.org Control: affects -1 + src:luajit2 User: ftp.debian@packages.debian.org Usertags: remove Dear ftp masters, The src:luajit2 is now a redundant package given that the upstream of src:luajit has been replaced into the upstream of src:luajit2. In that sense src:luajit and src:luajit2 are the identical source now. We do not need to keep both. Before removing src:luajit2 from unstable, we still need to make the reverse build dependencies of src:luajit2 depend on src:luajit instead. I'll later file the corresponding bugs and let them block this one. Thank you for using reportbug
Bug#1065021: golang-github-rivo-uniseg: please consider uploading new releases
Source: golang-github-rivo-uniseg Version: 0.4.4-1 Severity: wishlist Dear maintainers, Please consider packaging the latest release of this library, which is required by the latest release of fzf https://github.com/junegunn/fzf/blob/master/go.mod The latest release of fzf requires at least uniseg 0.4.6 to build. Thanks!
Bug#1060188: transition: flatbuffers
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: flatbuff...@packages.debian.org Control: affects -1 + src:flatbuffers The flatbuffers version in unstable is rather old. I'd like to start the transition. All reverse dependencies can be built on amd64. Note, the package list in transition tracker is not complete. I get the list by for each binary package from src:flatbuffers: build-rdeps package The following list should be the complete version: armnn [OK] buildbot [OK] facet-analyser [not in testing; FTBFS already] gnome-keysign [OK] kodi [OK] libsigmf [OK] magic-wormhole [OK] magic-wormhole-mailbox-server [FTBFS already; irrelevant, #1058173] paraview [OK] python-autobahn [OK] python-daphne [OK] python-django-channels [OK] pytorch [OK] [1] starlette [OK] vast [not in testing; FTBFS already] zaqar [OK] zlmdb [OK] [1] pytorch is undergoing uncoordinated transition, because pytorch is the only reverse dependency of libdnnl2/libdnnl3 and both maintained by me. The pytorch/experimental (awaits in NEW) can be successfully built against new flatbuffers. I don't know how to write the ben file because not all of them depend on libflatbuffers2 . Ben file: title = "flatbuffers"; is_affected = .depends ~ "libflatbuffers2" | .depends ~ "libflatbuffers23.5.26"; is_good = .depends ~ "libflatbuffers23.5.26"; is_bad = .depends ~ "libflatbuffers2"; Thank you for using reportbug
Bug#1060182: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: simdj...@packages.debian.org Control: affects -1 + src:simdjson Hi, simdjson upstream bumped SOVERSION from 16 to 19 in the latest release. All reverse dependencies can be rebuilt against 19 on amd64. pcm [ok] cloudflare-ddns [ok] The automatic ben file on transition tracker is correct. https://release.debian.org/transitions/html/auto-simdjson.html Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson16" | .depends ~ "libsimdjson19"; is_good = .depends ~ "libsimdjson19"; is_bad = .depends ~ "libsimdjson16"; Thank you for using reportbug
Bug#1060113: ITP: debgpt -- Chatting LLM with Debian-Specific Knowledge
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: debgpt Version : ? (CLI not yet stablized) Upstream Contact: me * URL : https://salsa.debian.org/deeplearning-team/debgpt * License : MIT/Expat Programming Lang: python Description : Chatting LLM with Debian-Specific Knowledge This tool is still under development. I may not upload it very soon, but an ITP number helps me silent lintian. I will not upload untill I finish the CLI re-design, and finish the documentation parts. There are some interesting findings while experimenting. For instance, I find this rather convenient: $ debgpt -HQ --cmd 'git diff --staged' -A 'Briefly describe the change as a git commit message.' So I further wrapped the git commit command into $ debgpt git commit which automatically generates a description for staged changes and commit them for you. Currently, some of the code of debgpt is written by debgpt, some of the git commit messages are written by `debgpt git commit`. I will try to explore more possibilities and add them in future releases. The only missing dependency before uploaindg this is only src:python-openai, which awaits in NEW as the time of writing. The following is the full package description: Large language models (LLMs) are newly emerged tools, which are capable of handling tasks that traditional software could never achieve, such as writing code based on the specification provided by the user. In this tool, we attempt to experiment and explore the possibility of leveraging LLMs to aid Debian development, in any extent. Essentially, the idea of this tool is to gather some pieces of Debian-specific knowledge, combine them together in a prompt, and then send them all to the LLM. This tool provides convenient functionality for automatically retrieving information from BTS, buildd, Debian Policy, system manual pages, tldr manuals, Debian Developer References, etc. It also provides convenient wrappers for external tools such as git, where debgpt can automatically generate the git commit message and commit the changes for you. This tool supports multiple frontends, including OpenAI and ZMQ. The ZMQ frontend/backend are provided in this tool to make it self-contained. Thank you for using reportbug
Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
On Thu, 2023-12-21 at 21:48 +, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > On Thu, Dec 21, 2023 at 10:06:23PM +0100, Salvatore Bonaccorso wrote: > > Can you as well add a bug closer for #1057455? > > And a brief description of what the vulnerability actually is, please. You > can go ahead with those changes. Thanks. I added the missing information as follows, and will upload it shortly. --- diff --git a/debian/changelog b/debian/changelog index 0c1065b..3f18ea1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,10 @@ fish (3.6.0-3.1+deb12u1) bookworm; urgency=medium - * Cherry-pick upstream fix for CVE-2023-49284. + * Cherry-pick upstream fix for CVE-2023-49284. (Closes: #1057455) +fish shell uses certain Unicode non-characters internally for marking +wildcards and expansions. It will incorrectly allow these markers to be +read on command substitution output, rather than transforming them into +a safe internal representation. -- Mo Zhou Thu, 21 Dec 2023 14:47:56 -0500 diff --git a/debian/patches/CVE-2023-49284.patch b/debian/patches/CVE-2023-49284.patch index a6fb924..5830277 100644 --- a/debian/patches/CVE-2023-49284.patch +++ b/debian/patches/CVE-2023-49284.patch @@ -4,6 +4,16 @@ Description: fixes CVE-2023-49284 The corresponding fix can be found at https://github.com/fish-shell/fish-shell/commit/09986f5563e31e2c900a606438f1d60d008f3a14 This patch is rebased from the upstream fix. + . + fish shell uses certain Unicode non-characters internally for marking + wildcards and expansions. It will incorrectly allow these markers to be read + on command substitution output, rather than transforming them into a safe + internal representation. + . + While this may cause unexpected behavior with direct input (for example, echo + \UFDD2HOME has the same output as echo $HOME), this may become a minor security + problem if the output is being fed from an external program into a command + substitution where this output may not be expected.
Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: f...@packages.debian.org
Control: affects -1 + src:fish
[ Reason ]
Cherry-pick upstream fix to CVE-2023-49284
[ Impact ]
This is a low severity security issue that affects basically
all historical releases of fish. The upstream created new
releases (i.e. 3.6.2) solely for fixing this bug.
https://github.com/fish-shell/fish-shell/commits/Integration_3.6.2/
So it would be good if we can integrate the fix into stable.
[ Tests ]
The fix is already included in fish/3.6.4-1 (sid).
The rebased patch passed my local sbuild test.
I installed the package in a chroot and tested it.
[ Risks ]
low.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Only one change. Please refer to the patch header for explanation.
[ Other info ]
diff -Nru fish-3.6.0/debian/changelog fish-3.6.0/debian/changelog
--- fish-3.6.0/debian/changelog 2023-05-01 13:01:01.0 -0400
+++ fish-3.6.0/debian/changelog 2023-12-21 14:47:56.0 -0500
@@ -1,3 +1,9 @@
+fish (3.6.0-3.1+deb12u1) bookworm; urgency=medium
+
+ * Cherry-pick upstream fix for CVE-2023-49284.
+
+ -- Mo Zhou Thu, 21 Dec 2023 14:47:56 -0500
+
fish (3.6.0-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru fish-3.6.0/debian/patches/CVE-2023-49284.patch
fish-3.6.0/debian/patches/CVE-2023-49284.patch
--- fish-3.6.0/debian/patches/CVE-2023-49284.patch 1969-12-31
19:00:00.0 -0500
+++ fish-3.6.0/debian/patches/CVE-2023-49284.patch 2023-12-21
14:44:13.0 -0500
@@ -0,0 +1,31 @@
+Description: fixes CVE-2023-49284
+ The CVE report can be found at
+
https://github.com/fish-shell/fish-shell/security/advisories/GHSA-2j9r-pm96-wp4f
+ The corresponding fix can be found at
+
https://github.com/fish-shell/fish-shell/commit/09986f5563e31e2c900a606438f1d60d008f3a14
+ This patch is rebased from the upstream fix.
+diff --git a/src/common.cpp b/src/common.cpp
+index baee97a..0e76bf1 100644
+--- a/src/common.cpp
b/src/common.cpp
+@@ -345,9 +345,7 @@ static wcstring str2wcs_internal(const char *in, const
size_t in_len) {
+ } else {
+ ret = std::mbrtowc(, [in_pos], in_len - in_pos, );
+ // Determine whether to encode this character with our crazy
scheme.
+-if (wc >= ENCODE_DIRECT_BASE && wc < ENCODE_DIRECT_BASE + 256) {
+-use_encode_direct = true;
+-} else if (wc == INTERNAL_SEPARATOR) {
++if (fish_reserved_codepoint(wc)) {
+ use_encode_direct = true;
+ } else if (ret == static_cast(-2)) {
+ // Incomplete sequence.
+@@ -1323,6 +1321,9 @@ maybe_t read_unquoted_escape(const wc
+ }
+
+ if (result_char_or_none.has_value()) {
++if (fish_reserved_codepoint(*result_char_or_none)) {
++return none();
++}
+ result->push_back(*result_char_or_none);
+ }
+
diff -Nru fish-3.6.0/debian/patches/series fish-3.6.0/debian/patches
--- fish-3.6.0/debian/patches/series2023-05-01 13:01:01.
+++ fish-3.6.0/debian/patches/series2023-12-21 14:44:23.
@@ -1,3 +1,4 @@
0001-reader-make-Escape-during-history-search-restore-com.patch
0002-reader-Remove-assert-in-history-search.patch
0003-workaround-for-Midnight-Commander.patch
+CVE-2023-49284.patch
Bug#1058657: patch
Control: tags -1 +patch https://salsa.debian.org/apt-team/python-apt/-/merge_requests/90
Bug#1055677: ITP: monaspace -- An innovative superfamily of fonts for code
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: monaspace * URL : https://github.com/githubnext/monaspace/tree/main * License : OFL-1.1 Programming Lang: N/A Description : An innovative superfamily of fonts for code I'll maintain this under the fonts team. It is not easy to find a good coding font. This one looks great. The Monaspace type system: a monospaced type superfamily with some modern tricks up its sleeves. It is comprised of five variable axis typefaces. Each one has a distinct voice, but they are all metrics- compatible with one another, allowing you to mix and match them for a more expressive typographical palette. Thank you for using reportbug
Bug#1054659: transition: utf8proc
Done. It's green on all release archs. On Fri, 2023-10-27 at 18:40 +, Graham Inggs wrote: > Control: tags -1 confirmed > > Hi Mo > > On Fri, 27 Oct 2023 at 15:36, M. Zhou wrote: > > We can start the transition for utf8proc, which recently got an > > SOVERSION bump from 2 to 3. I tested the reverse dependencies > > on ppc64el and all of them are fine. The results for amd64 should > > be the same. > > Please go ahead. > > Regards > Graham >
Bug#1054659: transition: utf8proc
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: utf8p...@packages.debian.org Control: affects -1 + src:utf8proc Dear release team, We can start the transition for utf8proc, which recently got an SOVERSION bump from 2 to 3. I tested the reverse dependencies on ppc64el and all of them are fine. The results for amd64 should be the same. Reverse Build-depends in main: -- bibledit [ok] bibledit-cloud [ok] ccextractor [ok] deepin-terminal [ok] fcft [ok] fnott [ok] foot [ok] fuzzel [ok] mame [ok] pnetcdf [ok] qterminal [ok] qtermwidget [ok] securefs [ok] subversion [ok] yambar [ok] the automatic ben file is correct: https://release.debian.org/transitions/html/auto-utf8proc.html Ben file: title = "utf8proc"; is_affected = .depends ~ "libutf8proc2" | .depends ~ "libutf8proc3"; is_good = .depends ~ "libutf8proc3"; is_bad = .depends ~ "libutf8proc2"; Thank you for using reportbug
Bug#1053910: zfs: use zpool user properties instead of zfs user properties for scrub and trim cron scripts
Source: zfs-linux Version: 2.2.0-1~exp1 Severity: normal zpool user property is supported now. We can use this feature for the cron scripts instead of abusing the zfs user property at root dataset. https://github.com/openzfs/zfs/pull/11680
Bug#1043124: [Pkg-zfsonlinux-devel] Bug#1043124: consider skipping trying to build on affected kernels?
On Sun, 2023-09-17 at 14:12 +0200, Ari wrote: > Have you, maintainers of zfs, considered configuring the packages so > that it skips trying to build of affected kernels? > This would at least reduce the time of installing any packages > drastically - currently my system tries to build it for two kernels > every time I install any package, because the kernel packages fail > the configuration stage. > Maybe with this approach it would be even feasible that the kernels' > installation state would not be failed for which compilation failed? > After all, the kernel installed correctly, but it's rather the zfs > package that is broken. While it indeed increases the speed of dpkg configuration steps, skipping the build or silently leave the kernel installation without failure is seriously wrong for many use cases, I believe.
Bug#1051520: ITP: python-expecttest -- expect test for python
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-expecttest * URL : https://github.com/ezyang/expecttest/ * License : MIT Programming Lang: (python Description : expect test for python Unit testing package for pytorch packages. Will be maintained by debian deep learning team. Thank you for using reportbug
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
On Tue, 5 Sep 2023 18:11:55 +0200 "Miguel A. Vallejo" wrote: > M. Zhou wrote: > > > But after that I noticed that the most important > > package grub-efi-amd64-signed:amd64 (1+2.06+13, > > 1+2.12~rc1+7) was not upgraded along with the other > > grub packages. > > You are right. I revised apt log and grub-efi-amd64-signed was NOT > updated, in fact, the version I have installed now is 1+2.06+13, but > all other grub packages have 2.06-3~deb11u5. > > Now, if I run apt update, and apt list --upgradable it shows: > > grub-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- 3~deb11u5] > grub-efi-amd64-bin/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- 3~deb11u5] > grub-efi-amd64-signed/unstable 1+2.12~rc1+7 amd64 [upgradable from: 1+2.06+13] > grub-efi-amd64/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- 3~deb11u5] > grub2-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- 3~deb11u5] > > > All of them with version 2.12~rc1-7 > > Is it safe to upgrade now? I'll wait a bit until I hear from the > package maintainers. I am able to boot with 2.12~rc1-7 now. And my currrent status is grub-common/unstable,now 2.12~rc1-7 amd64 [installed] grub-efi-amd64-bin/unstable,now 2.12~rc1-7 amd64 [installed,automatic] grub-efi-amd64-signed/unstable,now 1+2.12~rc1+7 amd64 [installed,automatic] grub-efi-amd64/unstable,now 2.12~rc1-7 amd64 [installed,automatic] grub2-common/unstable,now 2.12~rc1-7 amd64 [installed,automatic] I reinstalled grub using 2.12~rc1-7. But I still cannot guarantee it is safe to upgrade. I believe the issue is the missing versioned dependency, which allowed partial upgrade. If you check the testing, you will find that grub-efi-amd64-signed/1+2.06+13 Depends: grub-common (>= 2.06-13) Then, if we upgrade grub-common to 2.12~rc1-7, without upgrading grub-efi-amd64-signed itself, then the boot is broken. TLDR: the boot is broken with the following partial upgrade: grub-common/2.12~rc1-7 grub-efi-amd64-signed/2.06+13 A possible fix might be specifying Depends: grub-common (>= 2.12~rc1-7)), grub-common (<= 2.13~) to prevent incompatible grub-common and grub-efi-amd64-signed from co-existing. Although it does not help this time.
Bug#1051279: grub2 2.12~rc1-7 does no honor GRUB_CMDLINE_LINUX_DEFAULT="quiet" -- no quiet in kernel argument
Source: grub2 Version: 2.12~rc1-7 Severity: important Dear Maintainer, After the recent upgrade, some users experienced the unbootable issue #1051271 . I fixed the issue, and booted with 2.12~rc1-7, but I figured out that the newly generated grub config does not honor the GRUB_CMDLINE_LINUX_DEFAULT="quiet" in the new /etc/default/grub.ucf-dist file. As a result, the "quiet" kernel argument is missing from the generated grub.cfg in /boot/grub. For users who rely on this variable for customized kernel hbehavior, this might cause more issues. Hence I'm marking this issue as important. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Thank you for using reportbug
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
Same here. But I have some different conclusions after fixing my machine. Before my machine becoming unable to boot, the last apt log involves Start-Date: 2023-09-05 00:09:00 Commandline: apt upgrade Requested-By: lumin (1000) Upgrade: libimath-3-1-29:amd64 (3.1.9-2, 3.1.9-3), python3-brlapi:amd64 (6.6-2, 6.6-4), libtrilinos-aztecoo-13.2:amd64 (13.2.0-4, 13.2.0-5), libgtk-4-common:amd64 (4.12.1+ds-2, 4.12.1+ds-3), xbrlapi:amd64 (6.6-2, 6.6-4), libldb2:amd64 (2:2.7.2+samba4.18.6+dfsg-1, 2:2.8.0+samba4.19.0+dfsg-1), libwayland-cursor0:amd64 (1.22.0-2, 1.22.0-2.1), libbrlapi0.8:amd64 (6.6-2, 6.6-4), libtrilinos-ml- 13.2:amd64 (13.2.0-4, 13.2.0-5), libwayland-server0:amd64 (1.22.0-2, 1.22.0-2.1), libtrilinos-epetraext-13.2:amd64 (13.2.0-4, 13.2.0-5), dvisvgm:amd64 (3.1-1, 3.1.1+ds-1), libtrilinos-ifpack-13.2:amd64 (13.2.0-4, 13.2.0-5), libsuperlu6:amd64 (6.0.0+dfsg1-3, 6.0.1+dfsg1-1), libtrilinos-trilinosss-13.2:amd64 (13.2.0-4, 13.2.0-5), libtrilinos- kokkos-13.2:amd64 (13.2.0-4, 13.2.0-5), libwbclient0:amd64 (2:4.18.6+dfsg-1, 2:4.19.0+dfsg-1), libtrilinos-amesos-13.2:amd64 (13.2.0-4, 13.2.0-5), libsmbclient:amd64 (2:4.18.6+dfsg-1, 2:4.19.0+dfsg-1), gir1.2-gtk-4.0:amd64 (4.12.1+ds-2, 4.12.1+ds-3), grub-efi-amd64:amd64 (2.06-13, 2.12~rc1-7), gir1.2-accountsservice- 1.0:amd64 (23.13.9-3, 23.13.9-4), libnet-http-perl:amd64 (6.22-1, 6.23- 1), libtrilinos-epetra-13.2:amd64 (13.2.0-4, 13.2.0-5), libtrilinos- teuchos-13.2:amd64 (13.2.0-4, 13.2.0-5), libscotch-7.0:amd64 (7.0.3-2, 7.0.4-1), libtrilinos-zoltan-13.2:amd64 (13.2.0-4, 13.2.0-5), libunbound8:amd64 (1.17.1-2, 1.18.0-1), libtrilinos-galeri-13.2:amd64 (13.2.0-4, 13.2.0-5), grub-efi-amd64-bin:amd64 (2.06-13, 2.12~rc1-7), grub2-common:amd64 (2.06-13, 2.12~rc1-7), libwayland-egl1:amd64 (1.22.0-2, 1.22.0-2.1), libtrilinos-triutils-13.2:amd64 (13.2.0-4, 13.2.0-5), fonts-noto-cjk:amd64 (1:20230817+repack1-1, 1:20230817+repack1-3), grub-common:amd64 (2.06-13, 2.12~rc1-7), libgtk- 4-1:amd64 (4.12.1+ds-2, 4.12.1+ds-3), accountsservice:amd64 (23.13.9-3, 23.13.9-4), samba-libs:amd64 (2:4.18.6+dfsg-1, 2:4.19.0+dfsg-1), libptscotch-7.0:amd64 (7.0.3-2, 7.0.4-1), libgtk-4-bin:amd64 (4.12.1+ds-2, 4.12.1+ds-3), libgtk-4-media-gstreamer:amd64 (4.12.1+ds- 2, 4.12.1+ds-3), libwayland-client0:amd64 (1.22.0-2, 1.22.0-2.1), libaccountsservice0:amd64 (23.13.9-3, 23.13.9-4) End-Date: 2023-09-05 00:09:25 The machine does not boot since here. Then I wanted to reinstall grub without noticing that the package to install is no longer grub2 in the EFI era. Ignore this change. Start-Date: 2023-09-05 10:34:44 Commandline: apt install grub2 Install: grub2:amd64 (2.12~rc1-7), grub-pc-bin:amd64 (2.12~rc1-7, automatic), grub-pc:amd64 (2.12~rc1-7, automatic) Remove: grub-efi-amd64:amd64 (2.12~rc1-7) End-Date: 2023-09-05 10:34:47 I have tried some other ways to fix the boot, including rolling back grub to the testing version. But after that I noticed that the most important package grub-efi-amd64-signed:amd64 (1+2.06+13, 1+2.12~rc1+7) was not upgraded along with the other grub packages. Start-Date: 2023-09-05 10:48:36 Commandline: apt upgrade Requested-By: lumin (1000) Upgrade: evince:amd64 (45~alpha-2, 45~rc-1), libnghttp2-14:amd64 (1.55.1-1, 1.56.0-1), eog:amd64 (45~alpha-1, 45~rc-1), libevdocument3- 4:amd64 (45~alpha-2, 45~rc-1), libeatmydata1:amd64 (130-2+b1, 131-1), libevview3-3:amd64 (45~alpha-2, 45~rc-1), evince-common:amd64 (45~alpha-2, 45~rc-1), grub-efi-amd64-signed:amd64 (1+2.06+13, 1+2.12~rc1+7), gir1.2-evince-3.0:amd64 (45~alpha-2, 45~rc-1), eatmydata:amd64 (130-2, 131-1), libucx0:amd64 (1.15.0~rc3-1, 1.15.0~rc4-1) End-Date: 2023-09-05 10:48:43 After this, I removed all the extra config files I wrote in order to fix the boost. Then I did yet another clean grub install update-initramfs -k all -u update-grub2 Then reboot is successful with 1+2.12~rc1+7 . So my conclusion is that there might be something wrong in the Depends: sections of some of the grub2 packages, which did not specify versioned dependency to express incompatibility. I believe the maintainers have fully tested the grub loader before pushing it to unstable. But unfortunately, the asynchronized mirror update, resulted into partial upgrade of grub2 at the user end, which eventually affected a large amount of users. If it was a issue in the Depends field, it is still a critical bug which may damage user system, even if the trigger is partial upgrade due to mirror sync.
Bug#1050175: Missing symbol when importing torch
Sorry for the inconvenience. This is a temporary break due to the undergoing pytorch 2.0.1 upgrade work. On Mon, 2023-08-21 at 14:52 +0200, Mattias Ellert wrote: > Package: python3-torch > Version: 1.13.1+dfsg-4 > Severity: serious > > Importing torch results in failure due to missing symbols: > > $ python3 > Python 3.11.4 (main, Jun 7 2023, 10:13:09) [GCC 12.2.0] on linux > Type "help", "copyright", "credits" or "license" for more > information. > > > > import torch > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/torch/__init__.py", line 218, > in > > from torch._C import * # noqa: F403 > ^^ > ImportError: /lib/x86_64-linux-gnu/libtorch_cpu.so.1.13: undefined > symbol: _ZN4onnx7checker11check_modelERKNS_10ModelProtoE > > > > > > pytorch requires rebuild due to updated libonnx1: > > $ c++filt _ZN4onnx7checker11check_modelERKNS_10ModelProtoE > onnx::checker::check_model(onnx::ModelProto const&) > > $ dpkg-query --show python3-torch libonnx1 > libonnx1:amd641.13.1-1 > python3-torch 1.13.1+dfsg-4 > > Mattias >
Bug#1042871: transition: simdjson
Yesterday I made a mistake to reply to the old simdjson transition bug #1024380 which dates back to 1 year ago. Anyway, it has been uploaded to unstable, and successfully built for all release architectures. On Sat, 2023-08-05 at 15:50 +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2023-08-01 22:07:33 -0700, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: simdj...@packages.debian.org > > Control: affects -1 + src:simdjson > > > > Hi release team, > > > > The simdjson upstream has bumped the ABI version along with their > > new release. Thus the transition request. > > > > It has only two reverse dependencies in testing. src:vast is not > > in testing. All reverse dependencies compiles against the new > > version. > > Please go ahead > > Cheers
Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures
Control: fixed -1 2021.9.0-2 I agree. On Thu, 2023-08-03 at 00:32 +0200, Petter Reinholdtsen wrote: > [M. Zhou] > > The issue still exists with armel: > > https://buildd.debian.org/status/package.php?p=onetbb > > If so, this is a duplicate of > https://bugs.debian.org/1042009 >, which is about the armel > issue, > and should be closed. >
Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures
The issue still exists with armel: https://buildd.debian.org/status/package.php?p=onetbb On Wed, 2023-08-02 at 22:46 +0200, Petter Reinholdtsen wrote: > [M. Zhou] > > I'm aware of this issue. I'm slightly faster than buildd for > > toolchain > > upgrades. The issue will automatically disappear once our amd64 > > buildd > > migrates to gcc-13. The gcc-12 will lead to the FTBFS you see now. > > Is this still an issue?
Bug#1042871: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: simdj...@packages.debian.org Control: affects -1 + src:simdjson Hi release team, The simdjson upstream has bumped the ABI version along with their new release. Thus the transition request. It has only two reverse dependencies in testing. src:vast is not in testing. All reverse dependencies compiles against the new version. Reverse-Build-Depends = * pcm [ok] * vast [skipped. not in testing] Reverse-Build-Depends-Arch == * cloudflare-ddns [ok] The automatic transition tracker is correct. Thank you! Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson14" | .depends ~ "libsimdjson16"; is_good = .depends ~ "libsimdjson16"; is_bad = .depends ~ "libsimdjson14"; Thank you for using reportbug
Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures
Source: onetbb Version: 2021.9.0-1 Severity: serious I'm aware of this issue. I'm slightly faster than buildd for toolchain upgrades. The issue will automatically disappear once our amd64 buildd migrates to gcc-13. The gcc-12 will lead to the FTBFS you see now. Local sbuild with gcc-13 has no issue.
Bug#1038326: ITP: transformers -- State-of-the-art Machine Learning for JAX, PyTorch and TensorFlow (it ships LLMs)
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: transformers Upstream Contact: HuggingFace * URL : https://github.com/huggingface/transformers * License : Apache-2.0 Description : State-of-the-art Machine Learning for JAX, PyTorch and TensorFlow I've been using this for a while. This package provides a convenient way for people to download and run an LLM locally. Basically, if you want to run an instruct fine-tuned large language model with 7B parameters, you will need at least 16GB of CUDA memory for inference in half/bfloat16 precision. I have not tried to run any LLM with > 3B parameters with CPU ... that can be slow. LLaMa.cpp is a good choice for running LLM on CPU, but that library supports less models than this one. Meanwhile, the cpp library only supports inference. I don't know how many dependencies are still missing, but that should not be too much. Jax and TensorFlow are optional dependencies so they can be missing from our archive. But anyway, I think running a large language model locally with Debian packages will be interesting. The CUDA version of PyTorch is already in the NEW queue. That said, this is actually a very comprehensive library, which provides far more functionalities than running LLMs. Thank you for using reportbug
Bug#1038155: [Pkg-zfsonlinux-devel] Bug#1038155: zfs-linux: Provide a package based on OpenZFS master branch (a.k.a. 2.1.99)
Control: tags -1 wontfix Thanks for reaching out for this issue. I've noticed the Ubuntu updates as well. I'd personally not prefer to upload zfs-X.Y.99 anytime in the future. Since debian is volunteer-based, we don't seem to have more bandwidth than Ubuntu for dealing with regressions and serious bugs in a snapshot version. And, as mentioned, the openzfs upstream has forked our debian packaging scripts to produce the native-deb packages. Users who seriously need the cutting edge version could surely try it out. We are still the upstream for the debian packaging scripts which can be found in the openzfs repository. Yes, I'm kind of conservative regarding this. It is not subject to any rule though. On Fri, 2023-06-16 at 09:23 +0200, Damiano Albani wrote: > Package: zfs-linux > Severity: wishlist > X-Debbugs-Cc: damiano.alb...@gmail.com > > Dear Maintainer, > > Ubuntu recently started using the master branch of OpenZFS (a.k.a. 2.1.99) > for ZFS packages in Mantic: > https://launchpad.net/ubuntu/+source/zfs-linux/2.1.99-0ubuntu4. > > Would Debian consider such a move as well? > My understanding is that Debian tends to be more conservative(?) than Ubuntu > in that regard, so maybe have this 2.1.99 package in Debian Experimental? > (I don't know much about the whole Debian packaging rules, so I hope it makes > sense.) > > As you problably already know, it is *already* possible to build Debian > packages from the master branch of OpenZFS: see > https://openzfs.github.io/openzfs-docs/Developer%20Resources/Building%20ZFS.html. > While this package definition maintained by OpenZFS works totally fine, > it produces packages named like "openzfs-zfs-dkms", "openzfs-zfsutils", etc, > which is not compatible with Debian packages depending on "zfsutils-linux" > for example. > > So is it something that you would consider? > Thanks! > > Best Regards, >
Bug#1035458: libtorch-dev: broken symlinks: /usr/lib/x86_64-linux-gnu/libcaffe2_*.so -> libcaffe2_*.so.1.13
Control: severity -1 important Control: fixed -1 1.13.1+dfsg-5 I believe these symlinks were deprecated already. These symlinks are removed in 1.13.1+dfsg-5 (experimental). I'm not able to prepare a 1.13.1+dfsg-4.1 release to only remove these symlinks within a short time... too busy lately. So just downgrading the severity as it is not expected to harm any functionality.
Bug#1034624: zfs-dkms: Please revert corruption-causing optimization in 2.1.10 release
Control: fixed -1 2.1.11-1 2.1.11-1 has migrated to testing.
Bug#1035024: unblock: nvidia-cudnn/8.7.0.84~cuda11.8+1 (pre-approval)
On Sun, 2023-05-07 at 22:03 +0200, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Mo, > > On 27-04-2023 21:31, M. Zhou wrote: > > So, generally updating the package is simply to update the binary > > tarball URL in the script, along with the exact version number, > > which is very trivial. > > So why didn't you ask for only this? I thought about this choice. This package is hardly useful without the the fake library (for fixing dh_shlibdeps resolving), because it cannot serve as a component in the dependency chain for its future reverse dependencies. Even if the current testing package entered the next stable, it is still hardly useful. So if this is not going to be approved, I would prefer to get it removed from testing and prepare for the stable backports instead. > > 4. debconf template default choice is changed to "I Agree". > > This package is in non-free section. Only by setting the debconf > > default choice > > to "I Agree", can we correctly build pytorch-cuda in sbuild without > > the cuDNN > > libraries not downloaded but the bin:nvidia-cudnn package installed. > > Are we legally allowed to do this? If so, why even ask the question? According to the upstream license and the package content, the URL points to a distributable tarball depending on the user's agreement. The debconf questions shows the full license texts and asks the user whether to accept the terms. These terms, was deemed problematic by ftp-masters if we directly upload the binary blobs into the archive. At least, building the reverse dependency pytorch-cuda via sbuild, where the binary blobs will be pulled and linked against, is legal according to the license. Uploading the binary form of pytorch-cuda is ok as well. Other binary distributions like ArchLinux, Anaconda, and even PyTorch upstream have been redistributing the cuDNN binaries for years though. Although I hate dealing with annoying non-free license texts, I think it not safe to remove the debconf question prompt, because the license seems to pose even more restrictions than its dependency CUDA devkit. > Paul > PS wasn't an autopkgtest feasible such that this didn't need to be on > our radar? (too late for that now, but still) It looks like I have to refresh my memory, I thought autopkgtest won't be run for non-free packages. Writing the test scripts are easy, but I think that's not needed if I can get a manual removal or refusal. I checked the license, some simple test scripts for testing the downloader script, and do some testing compilation / linking will not violate the license. Will add them in the future. Both would work for me. I'm ok with stable backports. Afterall pytorch-cuda will only be available through backports. P.S. I really hate dealing with this package with a complicated end user agreement. It leads to my years long procrastination for the pytorch-cuda preparation. But, I was still forced to get it done solely due to the nvidia monopoly if we want a mature and high-performance version of pytorch. That said, the debian-ai@l.d.o team is diligently working on AMD's open-source ROCm, which provides alternatives for nvidia CUDA and cuDNN. When the ROCm stack is ready in our archive, I want to gradually give up the cuda branch and the corresponding effort -- pytorch-rocm can enter main, while pytorch-cuda can never.
Bug#1035354: unblock: fish/3.6.0-3.1
I'm the previous uploader of src:fish. The change looks good to me. Please feel free to go ahead with the nmu once the release managers say OK. On Mon, 2023-05-01 at 19:13 +0200, Andrej Shadura wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: f...@packages.debian.org, Mo Zhou > Control: affects -1 + src:fish > > Please unblock package fish > > As described in #1000351, mc ships fragile prompt extraction code which > was broken by a change in fish 3.3.0, leaving fish unusable in > conjunction with mc. I had hoped that this bug would be fixed in mc by > the time of bookworm release, but this didn’t happen. Instead, the > upstream developers of fish proposed a workaround and shipped it > in the bugfix release 3.6.1. > > I intend to either upload an NMU or let Mo Zhou do a maintainer’s > upload. > > This fix has very limited impact, as it specifically checks for the > presence of an mc-specific environment variable, and is a no-op > otherwise. The workaround itself is also straightforward. > > The impact of not shipping this patch is that all users of both fish and > mc (like myself) will have to put fish on hold and stay on the version > shipped in bullseye. > > [ 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 > > > Links: > > [1]: https://bugs.debian.org/1035353: the original mc bug > [2]: https://bugs.debian.org/1000351: a clone of the above for the > package fish > [3]: https://github.com/fish-shell/fish-shell/pull/9540: a pull request > in the upstream package. > > unblock fish/3.6.0-3.1
Bug#1035024: unblock: nvidia-cudnn/8.7.0.84~cuda11.8+1 (pre-approval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nvidia-cu...@packages.debian.org
Control: affects -1 + src:nvidia-cudnn
Please unblock package nvidia-cudnn. Not yet uploaded to unstable,
just asking for a pre-approval.
[ Reason ]
Our current package version in testing is 8.5.0.96~cuda11.7,
but the nvidia-cuda-toolkit version in testing is 11.8.89~11.8.0-2.
So there is a little minor version mismatch in the cuda version
(one 11.7, and the other 11.8).
This package is a downloader script that downloads the Nvidia
binary blob releases of the cuDNN library, and installs the library
to the system directories for building reverse dependencies.
So, generally updating the package is simply to update the binary
tarball URL in the script, along with the exact version number,
which is very trivial.
But unfortunately, during the cuda11.7 to cuda11.8 update,
I also introduced many changes to the package to the maintainer
scripts to let the package correctly support the pytorch-cuda build.
I'm the upstream of this package, and this looks like a low risk
update to me. But I'm not sure how the release team will think.
So asking for uploading permission in advance.
[ Impact ]
(What is the impact for the user if the unblock isn't granted?)
Nearly no impact. This package is new and does not exist
in the previous stable releases. To the best of my knowledge,
there is only one tentative reverse dependency pytorch-cuda,
which is not present in testing.
[ Tests ]
(What automated or manual tests cover the affected code?)
The updated package is now able to correctly support the
build of pytorch-cuda. I tested the built package with both
Nvidia MX250 (laptop) and RTX 2060 (laptop) GPUs. It works
correctly.
[ Risks ]
There is a small risk. The additional code is very simple.
It does not have reverse dependency in testing. There
is no alternative to this package. I'm the upstream author
of the script, and I can provide stable updates on my own
even if something goes wrong.
[ 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 ]
(Anything else the release team should know.)
The debdiff contains necessary changes to make the package
correctly support the pytorch-cuda build (with sbuild).
Specifically:
1. A fake library is compiled (from a nearly empty C file cudnn-fake.c)
with the soname of the library to be downloaded. This seems to be
the only way to make apt/dpkg believe that the libcudnn.so.* is
really provided by this binary package.
This solves the libcudnn_* cannot be found in any system package
error from dh_shlibdeps.
2. Added curl as an alternative binary blob downloader.
3. Updated the postinst and prerm script for handling installed files.
In the current testing version, when we want to remove this package,
we use some manually written glob patterns to remove the downloaded
cudnn library. This implementation is not very safe when the user manually
install another instance of cudnn to the system. The glob pattern will also
include them to make them removed during postrm.
In the proposed version (see debdiff), I record a list of files that are
installed
from the tarball to the system. And the postrm process will use the exact
recorded installation paths for removal. I think this is a safer
implementation
than removal by glob pattern match.
4. debconf template default choice is changed to "I Agree".
This package is in non-free section. Only by setting the debconf default
choice
to "I Agree", can we correctly build pytorch-cuda in sbuild without the
cuDNN
libraries not downloaded but the bin:nvidia-cudnn package installed.
5. More code comments (maintainence notes) in the script, and the upgraded
binary blob URL.
unblock nvidia-cudnn/8.7.0.84~cuda11.8+1
Thank you for using reportbug
diff -Nru nvidia-cudnn-8.5.0.96~cuda11.7/cudnn-fake.c nvidia-cudnn-8.7.0.84~cuda11.8/cudnn-fake.c
--- nvidia-cudnn-8.5.0.96~cuda11.7/cudnn-fake.c 1969-12-31 19:00:00.0 -0500
+++ nvidia-cudnn-8.7.0.84~cuda11.8/cudnn-fake.c 2023-03-21 18:49:17.0 -0400
@@ -0,0 +1,8 @@
+/* This is a fake library. We want dpkg-shlibdeps to believe that the
+ * shared object libcudnn.so.8 is provided in this package.
+ */
+int
+__cudnn_fake_library__()
+{
+return 0;
+}
diff -Nru nvidia-cudnn-8.5.0.96~cuda11.7/debian/changelog nvidia-cudnn-8.7.0.84~cuda11.8/debian/changelog
--- nvidia-cudnn-8.5.0.96~cuda11.7/debian/changelog 2023-02-17 23:24:39.0 -0500
+++ nvidia-cudnn-8.7.0.84~cuda11.8/debian/changelog 2023-03-21 18:49:17.0 -0400
@@ -1,3 +1,33 @@
+nvidia-cudnn (8.7.0.84~cuda11.8) experimental; urgency=medium
+
+ * Upgrade to cuDNN v8.7.0.84
+ * Set the debconf template default choice to "I Agree".
+Only in this way can we use the binary
Bug#1033464: unblock: fish/3.6.0-3
On Sun, 2023-03-26 at 20:31 +0200, Luna Jernberg wrote: > Not to whine but is the plan to build 3.6.1 that was released yesterday > aswell? It's the hard freeze stage for Debian. Introducing a massive change, such as the full 3.6.1 upgrade will not likely successfully make it in testing according to the freeze policy. The 3.6.1 upgrade is postponed after the upcoming stable release.
Bug#1033464: unblock: fish/3.6.0-3
Control: tags -1 - moreinfo On Sun, 2023-03-26 at 07:28 +0200, Paul Gevers wrote: > Control: tags -1 confirmed moreinfo > > Hi Mo, > > On 25-03-2023 15:39, M. Zhou wrote: > > Please unblock package fish > > Not yet uploaded. This package does not have a proper > > autopkgtest, manual unblock needed. > > Please go ahead and remove the moreinfo tag once that happened. It has been uploaded to unstable. And turned green on all release archs: https://buildd.debian.org/status/package.php?p=fish
Bug#1033464: unblock: fish/3.6.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package fish
Not yet uploaded. This package does not have a proper
autopkgtest, manual unblock needed.
[ Reason ]
I cherry picked two upstream fixes. One of them fixes
crash, while the other fixes undesired behavior.
https://github.com/fish-shell/fish-shell/commit/e84f588d11a86d38ff708d4c16aab1316ac09b6c
https://github.com/fish-shell/fish-shell/commit/37575c5f7983cb5338a1ba23541bbd86a4fd2a4e
And I also added the missing dependency on procps.
It absence leads to unwanted and unnecessary errors:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029940
[ Impact ]
Fish is an interactive shell. These changes would fix unwanted
behavior of the shell.
[ Tests ]
The patches are cherry-picked from the upstream 3.6.1 release
and has been coverted by their CI. My default shell is fish and
it has been locally tested on both sid and the current stable.
[ Risks ]
The two patches are simple. Adding dependency on procps induces
zero risk.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock fish/3.6.0-3
Thank you for using reportbug
diff -Nru fish-3.6.0/debian/changelog fish-3.6.0/debian/changelog
--- fish-3.6.0/debian/changelog 2023-02-17 20:05:29.0 -0500
+++ fish-3.6.0/debian/changelog 2023-03-25 10:20:50.0 -0400
@@ -1,3 +1,10 @@
+fish (3.6.0-3) unstable; urgency=medium
+
+ * Cherry-pick upstream fixes from the v3.6.1 branch.
+ * Add the missing Depends on procps (Closes: #1029940).
+
+ -- Mo Zhou Sat, 25 Mar 2023 10:20:50 -0400
+
fish (3.6.0-2) unstable; urgency=medium
* Ignore several flaky tests for armel.
diff -Nru fish-3.6.0/debian/control fish-3.6.0/debian/control
--- fish-3.6.0/debian/control 2023-01-07 11:28:46.0 -0500
+++ fish-3.6.0/debian/control 2023-03-25 10:19:55.0 -0400
@@ -26,6 +26,7 @@
bsdextrautils,
groff-base,
man-db,
+ procps,
python3,
${misc:Depends},
${shlibs:Depends}
diff -Nru fish-3.6.0/debian/patches/0001-reader-make-Escape-during-history-search-restore-com.patch fish-3.6.0/debian/patches/0001-reader-make-Escape-during-history-search-restore-com.patch
--- fish-3.6.0/debian/patches/0001-reader-make-Escape-during-history-search-restore-com.patch 1969-12-31 19:00:00.0 -0500
+++ fish-3.6.0/debian/patches/0001-reader-make-Escape-during-history-search-restore-com.patch 2023-03-25 10:18:29.0 -0400
@@ -0,0 +1,58 @@
+From: Johannes Altmanninger
+Date: Tue, 17 Jan 2023 09:14:54 +0100
+Subject: reader: make Escape during history search restore commandline again
+
+Commit 3b30d92b6 (Commit transient edit when closing pager, 2022-08-31)
+inadvertently introduced two regressions to history search:
+
+1. It made Escape keeps the selected history entry,
+ instead of restoring the commandline before history search.
+2. It made history search commands add undo entries.
+
+Fix both of this issues.
+---
+ src/reader.cpp| 3 ++-
+ tests/checks/tmux-history-search.fish | 12
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+diff --git a/src/reader.cpp b/src/reader.cpp
+index c50426f..9fe2d7e 100644
+--- a/src/reader.cpp
b/src/reader.cpp
+@@ -4477,7 +4477,8 @@ maybe_t reader_data_t::readline(int nchars_or_0) {
+
+ // Clear the pager if necessary.
+ bool focused_on_search_field = (active_edit_line() == _field_line);
+-if (command_ends_paging(readline_cmd, focused_on_search_field)) {
++if (!history_search.active() &&
++command_ends_paging(readline_cmd, focused_on_search_field)) {
+ clear_pager();
+ }
+
+diff --git a/tests/checks/tmux-history-search.fish b/tests/checks/tmux-history-search.fish
+index 9dc1b4f..92bab0b 100644
+--- a/tests/checks/tmux-history-search.fish
b/tests/checks/tmux-history-search.fish
+@@ -3,6 +3,9 @@
+ # disable on github actions because it's flakey
+ #REQUIRES: test -z "$CI"
+
++set -g isolated_tmux_fish_extra_args -C '
++set -g fish_autosuggestion_enabled 0
++'
+ isolated-tmux-start
+
+ isolated-tmux send-keys 'true needle' Enter
+@@ -15,3 +18,12 @@ isolated-tmux send-keys C-p C-a M-f M-f M-f M-.
+ # CHECK: prompt 2> true hay needle hay
+ tmux-sleep
+ isolated-tmux capture-pane -p
++
++isolated-tmux send-keys C-e C-u true Up Up Escape
++tmux-sleep
++isolated-tmux capture-pane -p | grep 'prompt 2'
++# CHECK: prompt 2> true
++isolated-tmux send-keys C-z _
++tmux-sleep
++isolated-tmux capture-pane -p | grep 'prompt 2'
++# CHECK: prompt 2> _
diff -Nru fish-3.6.0/debian/patches/0002-reader-Remove-assert-in-history-search.patch fish-3.6.0/debian/patches/0002-reader-Remove-assert-in-history-search.patch
---
Bug#1033345: ITP: nvitop -- An interactive NVIDIA-GPU process viewer and beyond
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: nvitop * URL : https://github.com/XuehaiPan/nvitop * License : Apache-2.0 / GPL-3.0 dual license Programming Lang: Python Description : An interactive NVIDIA-GPU process viewer and beyond We have a couple of nvidia GPU utility monitors. Nvidia's nvidia-smi is standard but far not readable enough for heavy GPU users like me. I packaged gpustat -- it is good, but it does not show the standard top informantion, and as a result I have to open another tmux window for glances or htop, in order to make sure the neural network does not blow up the system memory. This nvitop just combines both gpu monitoring and CPU/ram monitoring. Have used it for a while on GPU servers. It cannot be better. This package will be maintained under the umbrella of the nvidia packaging team. I suppose the package has to enter contrib because it depends on the non-free nvidia driver. Thank you for using reportbug
Bug#1031973: ITP: nvidia-cutlass -- CUDA Templates for Linear Algebra Subroutines
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-nvidia-de...@lists.alioth.debian.org * Package name: nvidia-cutlass * URL : https://github.com/NVIDIA/cutlass * License : BSD-3-Clause (has to enter contrib due to non-free deps) Programming Lang: C++ Description : CUDA Templates for Linear Algebra Subroutines This is needed for the cuda version of pytorch. The package will be maintained by Debian NVIDIA Maintainers
Bug#1031972: ITP: nvidia-cudnn-frontend -- c++ wrapper for the cudnn backend API
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-nvidia-de...@lists.alioth.debian.org * Package name: nvidia-cudnn-frontend * URL : https://github.com/NVIDIA/cudnn-frontend * License : MIT (but will enter contrib due to non-free deps) Programming Lang: C++ Description : c++ wrapper for the cudnn backend API This is needed for the cuda version of pytorch. The package will be maintained by Debian NVIDIA Maintainers
Bug#1031565: ITP: nvidia-nccl -- Optimized primitives for collective multi-GPU communication
On Sun, 2023-02-19 at 20:55 +0100, Andreas Beckmann wrote: > On 18/02/2023 19.33, M. Zhou wrote: > > * License : BSD-3-Clause but has to enter non-free. > > Why not contrib? A B-D: nvidia-cuda-toolkit does not require the package > to be in non-free. BTW, please B-D: nvidia-cuda-toolkit-gcc instead. Good point. I did not think about it twice once recalled that nvidia-cuda-toolkit is in non-free. I have pushed the suggested changes to the git repo g...@salsa.debian.org:nvidia-team/nvidia-nccl.git I think it is ready to enter the NEW queue. Will do it soon.
Bug#1031565: ITP: nvidia-nccl -- Optimized primitives for collective multi-GPU communication
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-nvidia-de...@lists.alioth.debian.org * Package name: nvidia-nccl * URL : https://github.com/NVIDIA/nccl * License : BSD-3-Clause but has to enter non-free. Programming Lang: C/C++ Description : Optimized primitives for collective multi-GPU communication This is needed for some cuda applications like pytorch-cuda. The package will be maintained by Debian NVIDIA Maintainers
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
On Mon, 2023-01-30 at 06:46 +0100, Andreas Tille wrote: > Am Sun, Jan 29, 2023 at 10:22:24AM -0500 schrieb M. Zhou: > > > Since we do not have this module[2] (yet) we should probably exclude all > tests that need this module, right? If you think its a nice thing to > have I would volunteer to package this in DPT. Yes, we can skip these python tests for now. And the fix is already uploaded. We should be ready to wait for the testing migration.
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
On Sun, 2023-01-29 at 09:03 +0100, Andreas Tille wrote: > > > I have no idea about fmtlib but I noticed: > > [2022-09-04] fmtlib 9.1.0+ds1-2 MIGRATED to testing (Debian testing > watch) > [2022-09-04] Accepted fmtlib 9.1.0+ds1-2 (source) into unstable > (Shengjing Zhu) > [2022-08-27] Accepted fmtlib 9.1.0+ds1-1 (source) into experimental > (Shengjing Zhu) > [2022-08-24] fmtlib 9.0.0+ds1-4 MIGRATED to testing (Debian testing > watch) > > Is this failure dating back to August last year and possibly > connected to > the version bump from 9.00 to 9.1.0? I had some similar thoughts during diagnosis. That said, I have already patched the line that FTBFS, and reverted it back to the std::ostringstream implementation, which is merely introducing some overhead. And Aron has uploaded pytorch to NEW.
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
For reference, a 8 core + 16GB RAM configuration should be able to finish the pytorch compilation timely. The build takes roughly an hour. My observation is based on power9 -- on amd64 it should be something similar. On Sun, 2023-01-29 at 11:09 +0800, Aron Xu wrote: > On Fri, Jan 27, 2023 at 9:42 PM Andreas Tille wrote: > > > > Am Fri, Jan 27, 2023 at 08:21:46PM +0800 schrieb Aron Xu: > > > On Fri, Jan 27, 2023 at 7:12 PM Andreas Tille wrote: > > > > make: *** [debian/rules:83: binary] Terminated > > > > ninja: build stopped: interrupted by user. > > > > > > > > could be a sign for this. Was I to naive to assume Salsa CI could > > > > manage a pytorch build and should we possibly switch this off again? > > > > > > > > > > Not sure but by wild guess it could be caused by running for too long? > > > > I do not think so. Since I was aware that it will take long I have > > adjusted the timeout from 1h (default) to 4h. The log stops a bit after > > 3h. To my experience if timeout is the reason the log ends with this > > information. > > > > Then I guess it could be out-of-memory, the build process is hungry > for RAM and a single cc1plus process can take at least up to 2GB > memory during my quick observation. > > Regards, > Aron >
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
Feel free to break the pytorch reverse dependencies without a transition slot -- we do not need the slot in the current status. The rdeps are already not in testing due to RC bugs and needs some new patchworks. Manual upload is needed for its rebuild. On Fri, 2023-01-27 at 20:19 +0800, Aron Xu wrote: > On Fri, Jan 27, 2023 at 3:48 PM Andreas Tille wrote: > > > > Hi Aron, > > > > Am Fri, Jan 27, 2023 at 02:09:05AM +0800 schrieb Aron Xu: > > > > > > The packaging work of 1.13.1[1] has started on salsa. We still have a > > > failure related to fmtlib before making the package build successfully > > > [5/1781]. Both Mo and I have limited bandwidth here and help is always > > > appreciated. > > > > I've just checked the changelog and noticed: > > > >Bump SOVERSION to 1.13 > > > > but we are in transition freeze. So this needs to be coordinated with > > release team. I guess if we argue that 1.13 will support Python3.11 > > this could be some argument after the decision that this should be the > > supported Python3 version for the next release. > > > > Agreed. And it seems the only rdepends of libtorch1.12 is > python3-torchvision which is owned by us, too, so the update would be > fairly easy to handle. > > Regards, > Aron >
Bug#1027686: transition: rakudo
I have uploaded moarvm, nqp, and rakudo to unstable. They turned green on release architectures. The ppc64el buildd lags a little bit but I believe the result will be green as well based on the previous no-change build in experimental. On Sun, 2023-01-15 at 19:09 +0100, Sebastian Ramacher wrote: > Control: tags -1 = confirmed > > On 2023-01-15 18:49:24 +0100, Dominique Dumont wrote: > > On Sunday, 15 January 2023 15:21:55 CET Sebastian Ramacher wrote: > > > > I've found where compiler-id is computed. I'm going patch > > > > rakudo in > > > > experimental so that compiler-id depends only on source files > > > > and nqp > > > > version. This patch will land in experimental. > > > > > > Okay, please let me know once it's available in experimental. > > > > Done with rakudo 2022.12-1~exp3 > > > > I've patched the compiler id to be a sha1 of "Debian- > version>". > > > > I've verified that compiler id is the same for the arch that are > > built. > > > > Is it still time to trigger a transition to fix all raku modules ? > > (there's no > > impact outside of raku modules) > > Thanks, please go ahead. > > Cheers
Bug#1027613: update
Control: severity -1 important I think this FTBFS mostly stems from the toolchain. 1. before the bug is filed, it builds successfully on amd64 2. On the day I recieved this bug report, I reproduced it 3. after some toolchain updates, I cannot reproduce it anymore
Bug#1027215: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Currently, I'd say PyTorch and TensorFlow are the two most popular libraries. And I even worry google is trying to write something new like Jax to replace TensorFlow in some aspects. On Sat, 2023-01-14 at 11:12 +, Rebecca N. Palmer wrote: > theano has been mostly abandoned upstream since 2018. (The Aesara fork > is not abandoned, but includes interface changes including the import > name, so would break reverse dependencies not specifically altered for it.) > > Its reverse dependencies are keras, deepnano and invesalius. > > It is currently broken, probably by numpy 1.24 (#1027215), and the > immediately obvious fixes weren't enough > (https://salsa.debian.org/science-team/theano/-/pipelines). > > Is this worth spending more effort on fixing, or should we just remove it? >
Bug#1027686: transition: rakudo
I missed the detail that the compiler ID even changes for different architecture.. which may not be good. Is it possible for us to slightly modify the postinst script to recompile the cache locally when the compiler id mismatches? The fallback script rakudo-helper.pl can at least make sure a raku-* package is still functional even without a matching compiler ID. In that case we don't have to add the compiler ID to the virtual package name, and every architecture can track the same and consistent virtual package dependency. On Sat, 2023-01-07 at 18:40 +0100, Dominique Dumont wrote: > On Saturday, 7 January 2023 11:58:29 CET you wrote: > > > Unfortunately, the compiler-id also depends on the build > > > directory. Which > > > means that the compiler id changes between arches. > > > > This should be fixed first. Otherwise every rebuild of the compiler > > will > > require all reverse dependencies to be rebuilt too. That does not > > sound > > like a good solution. > > Agreed, but that's a long story with upstream: > > https://github.com/rakudo/rakudo/issues/5099 > > All the best >
Bug#1027686: transition: rakudo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: rak...@packages.debian.org Control: affects -1 + src:rakudo Dear release team, We would like to start the transition for rakudo, updating rakudo to the latest version in unstable. It involves three packages, src:moarvm, src:nqp, and src:rakudo. They are built successfully in experimental. The s390x buildd is super slow this week -- I waited for a week and it has not started a build yet All other architectures look good. This upload also aims to trigger rebuild for all reverse dependencies to mitigate some issues about the compiler ID. Specifically, the pre-compiled cache shipped in reverse dependencies relies on a matching compiler ID. Hence, we added the compiler ID into the virtual package to ensure cache compatibility: raku-api-2022.12+e556a5c0 The compiler ID will change when code is modified. Albeit adding the compiler ID may not sound like an ideal solution, this seems like what we can do before the freeze. Ben file: title = "rakudo"; is_affected = .depends ~ "raku-api-2022.07" | .depends ~ "raku-api-2022.12+e556a5c0"; is_good = .depends ~ "raku-api-2022.12+e556a5c0"; is_bad = .depends ~ "raku-api-2022.07"; Thank you for using reportbug
Bug#1017020:
Control: fixed -1 2022.07+dfsg-1 Control: close -1
Bug#1025779: onetbb: Please add patch to add support for ia64
Control: tag -1 +moreinfo I have tried exactly the same patch half a year ago, which resulted a massive number of segmentation faults. Build log can be found in our buildd. See https://github.com/oneapi-src/oneTBB/issues/777 I'm not sure whether the latest assembly code in https://github.com/oneapi-src/oneTBB/pull/983 would avoid those segfaults, so tagging this bug with moreinfo.
Bug#1024795: python-llvmlite
Control: tags -1 +moreinfo
I'm confused. How did you manage to build the package from source
using c65b3e662b7b08920172b710419d7a06b660be59 on salsa?
I did not upload it because I can never successfully build it
from source.
-
passmanagers.cpp: In function ‘void LLVMPY_SetTimePasses(bool)’:
passmanagers.cpp:36:37: error: ‘TimePassesIsEnabled’ was not declared in this
scope
36 | LLVMPY_SetTimePasses(bool enable) { TimePassesIsEnabled = enable; }
| ^~~
passmanagers.cpp: In function ‘void
LLVMPY_AddDeadCodeEliminationPass(LLVMPassManagerRef)’:
passmanagers.cpp:158:50: error: cannot convert ‘llvm::FunctionPass*’ to
‘llvm::Pass*’
158 | unwrap(PM)->add(createDeadCodeEliminationPass());
| ~^~
| |
| llvm::FunctionPass*
In file included from passmanagers.cpp:10:
/usr/lib/llvm-14/include/llvm/IR/LegacyPassManager.h:48:26: note:
initializing argument 1 of ‘virtual void
llvm::legacy::PassManagerBase::add(llvm::Pass*)’
48 | virtual void add(Pass *P) = 0;
|~~^
passmanagers.cpp: In function ‘void LLVMPY_AddSROAPass(LLVMPassManagerRef)’:
passmanagers.cpp:181:75: error: cannot convert ‘llvm::FunctionPass*’ to
‘llvm::Pass*’
181 | LLVMPY_AddSROAPass(LLVMPassManagerRef PM) {
unwrap(PM)->add(createSROAPass()); }
|
~~^~
|
|
|
llvm::FunctionPass*
/usr/lib/llvm-14/include/llvm/IR/LegacyPassManager.h:48:26: note:
initializing argument 1 of ‘virtual void
llvm::legacy::PassManagerBase::add(llvm::Pass*)’
48 | virtual void add(Pass *P) = 0;
|~~^
make[1]: *** [Makefile.linux:22: passmanagers.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/<>/ffi'
14.0.6
SVML not detected
Traceback (most recent call last):
File "/<>/ffi/build.py", line 227, in
main()
File "/<>/ffi/build.py", line 217, in main
main_posix('linux', '.so')
File "/<>/ffi/build.py", line 209, in main_posix
subprocess.check_call(['make', '-f', makefile] + makeopts)
File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['make', '-f', 'Makefile.linux',
'-j8']' returned non-zero exit status 2.
error: command '/usr/bin/python3' failed with exit code 1
E: pybuild pybuild:386: build: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py build
dh_auto_build: error: pybuild --build -i python{version} -p "3.11 3.10"
returned exit code 13
make: *** [debian/rules:11: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
On Thu, 2022-12-22 at 18:20 -0500, M. Zhou wrote:
> Sure, I think we can ship a snapshot version as long as it works
> fine with llvm-14. Could you please verify the snapshot hash
> again?
>
> https://github.com/numba/llvmlite/commit/c65b3e662b7b08920172b710419d7a06b660be59
>
> The commit seems missing. If it was close to the master branch,
> I can directly pull the master branch and upload the corresponding
> snapshot.
>
> On Wed, 2022-12-21 at 20:05 -0800, Diane Trout wrote:
> > Hi,
> >
> > I was trying to update numba, and need the updated version of llvmlite
> > built against llvm-14
> >
> > The version that's currently in unstable is still built against llvml-
> > 11
> >
> > https://packages.debian.org/sid/python3-llvmlite
> >
> > I've checked out out the llvmlite repository and rebuilt it locally
> > using commit c65b3e662b7b08920172b710419d7a06b660be59 against llvm-14
> >
> > and llvmlite's test cases pass. (And most of numba's passed too. And I
> > think the remaining test failures aren't related to llvmlite)
> >
> > Is there a chance we could get an updated version released soon?
> >
> > Thanks
> > Diane Trout
>
Bug#1024795: python-llvmlite
Sure, I think we can ship a snapshot version as long as it works fine with llvm-14. Could you please verify the snapshot hash again? https://github.com/numba/llvmlite/commit/c65b3e662b7b08920172b710419d7a06b660be59 The commit seems missing. If it was close to the master branch, I can directly pull the master branch and upload the corresponding snapshot. On Wed, 2022-12-21 at 20:05 -0800, Diane Trout wrote: > Hi, > > I was trying to update numba, and need the updated version of llvmlite > built against llvm-14 > > The version that's currently in unstable is still built against llvml- > 11 > > https://packages.debian.org/sid/python3-llvmlite > > I've checked out out the llvmlite repository and rebuilt it locally > using commit c65b3e662b7b08920172b710419d7a06b660be59 against llvm-14 > > and llvmlite's test cases pass. (And most of numba's passed too. And I > think the remaining test failures aren't related to llvmlite) > > Is there a chance we could get an updated version released soon? > > Thanks > Diane Trout
Bug#1013214: O: asmjit -- Complete x86/x64 JIT and AOT Assembler for C++
Sure, just do whatever you see appropriate, since you are the\ future maintainer :-) Thanks for taking it over! On Mon, 2022-12-19 at 20:03 +0200, Andrius Merkys wrote: > Hi, > > On Sat, 18 Jun 2022 20:04:05 -0700 "M. Zhou" > wrote: > > I intend to orphan the asmjit package. > > I would like to adopt the package inside Debian Deep Learning Team. > However, I would drop the artificial shared library as asmjit is > explicitly unstable [1]. Is it OK? > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013214#12 > > Andrius
Bug#1024326: [Pkg-zfsonlinux-devel] Bug#1024326: bullseye to bookworm upgrade failure: Could not locate dkms.conf file
Control: severity -1 important Control: tags -1 +moreinfo I'm still not sure about why the upgrade failed, and I could not reproduce the problem in a clean chroot using the following script: https://salsa.debian.org/zfsonlinux-team/zfs/-/blob/master/debian/tests/sbuild-shell-bullseye-to-bookworm.sh So I'm downgrading the bug's severity to unblock migration. On Thu, 2022-11-17 at 10:31 -0500, Antoine Beaupre wrote: > Package: zfs-dkms > Version: 2.1.6-3 > Severity: serious > > I have tried to upgrade to bookworm today and kernel builds fail on > zfs-dkms. It fails with: > > dkms: running auto installation service for kernel 6.0.0-4- > amd64:Error! Could not locate dkms.conf file. > File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist. > > It's odd because zfs 2.0.3 is gone now... The package has been > upgraded at this point... Yet the /var/lib/dkms/zfs/2.0.3 directory > was still around. Removing it fixes the problem: > > rm -rf /var/lib/dkms/zfs/2.0.3 > > Note that I am doing batch upgrades with a special procedure, with > this command: > > env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none > APT_LISTBUGS_FRONTEND=none UCF_FORCE_CONFFOLD=y \ > apt full-upgrade -y -o Dpkg::Options::='--force-confdef' -o > Dpkg::Options::='--force-confold' && > > ... which might have cause the old directory to not be removed. > > See this for my upgrade procedure: > > https://anarc.at/services/upgrades/bookworm/ > > More of the error log: > > Setting up linux-image-6.0.0-4-amd64 (6.0.8-1) ... > /etc/kernel/postinst.d/dkms: > dkms: running auto installation service for kernel 6.0.0-4- > amd64:Error! Could not locate dkms.conf file. > File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist. > failed! > run-parts: /etc/kernel/postinst.d/dkms exited with return code 4 > dpkg: error processing package linux-image-6.0.0-4-amd64 (-- > configure): > installed linux-image-6.0.0-4-amd64 package post-installation script > subprocess returned error exit status 1 > dpkg: dependency problems prevent configuration of linux-image-amd64: > linux-image-amd64 depends on linux-image-6.0.0-4-amd64 (= 6.0.8-1); > however: > Package linux-image-6.0.0-4-amd64 is not configured yet. > > dpkg: error processing package linux-image-amd64 (--configure): > dependency problems - leaving unconfigured > Setting up linux-headers-6.0.0-4-amd64 (6.0.8-1) ... > /etc/kernel/header_postinst.d/dkms: > dkms: running auto installation service for kernel 6.0.0-4- > amd64:Error! Could not locate dkms.conf file. > File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist. > failed! > run-parts: /etc/kernel/header_postinst.d/dkms exited with return code > 4 > Failed to process /etc/kernel/header_postinst.d at > /var/lib/dpkg/info/linux-headers-6.0.0-4-amd64.postinst line 11. > dpkg: error processing package linux-headers-6.0.0-4-amd64 (-- > configure): > installed linux-headers-6.0.0-4-amd64 package post-installation > script subprocess returned error exit status 1 > dpkg: dependency problems prevent configuration of linux-headers- > amd64: > linux-headers-amd64 depends on linux-headers-6.0.0-4-amd64 (= 6.0.8- > 1); however: > Package linux-headers-6.0.0-4-amd64 is not configured yet. > > dpkg: error processing package linux-headers-amd64 (--configure): > dependency problems - leaving unconfigured > Errors were encountered while processing: > linux-image-6.0.0-4-amd64 > linux-image-amd64 > linux-headers-6.0.0-4-amd64 > linux-headers-amd64
Bug#1025214: was: regression: dkms/3.0.8-2 renders zfs-dkms FTBFS
Control: merge 1025214 1025171 The "MAKEFLAGS="--environment-overrides" also caused zfs-dkms FTBFS. The two bugs above are the same issue, hence the merge.
Bug#1025171: [Pkg-zfsonlinux-devel] Bug#1025171: zfs-dkms FTBFS against 6.0.0-5-amd64
Control: reassign -1 dkms 3.0.8-2 Control: retitle -1 regression: dkms/3.0.8-2 renders zfs-dkms FTBFS Control: severity -1 serious Hi, Thank you for the information! I can confirm that this is the same issue that you have encountered. By commenting out the --environment-overrides, the current zfs-dkms package can be built against 6.0.0-5-amd64 successfully. According to the build log when I filed the bug report, the problem is indeed that the compiler cannot find the header files. I believed it was some -I ... flags missing due to some reason. So it is a regression bug in dkms/3.0.8-2, as -I flags needed for zfs-dkms are accidentally removed. On Wed, 2022-11-30 at 22:56 +, Heikki Kallasjoki wrote: > There isn't enough detail to be sure, but this might be the same issue I > hit on sid yesterday, so adding it here. It might also count as a dkms > bug for all I know. > > In my case, zfs-dkms fails to build against either of my currently > installed kernels (5.19.0-1-amd64, 6.0.0-5-amd64), but only after > updating the package dkms to version 3.0.8-2 (from 3.0.8-1). > > This appears to be the result of the changes to the export-CC.patch: > https://sources.debian.org/patches/dkms/3.0.8-2/export-CC.patch/ > > The 3.0.8-2 version adds the following commands to the prepare_build() > function: > > export CC=$CC > export MAKEFLAGS="--environment-overrides" > > I've verified that zfs-dkms builds fine for me if I temporarily comment > out the second line from /usr/sbin/dkms. > > A build log for a failed attempt (with the flag present) is at: > https://0x0.st/o0fu.txt > > The log also includes a dump of the environment variables at the start > of the build, from a command I added to the dkms script. > > Digging a little deeper, it appears that when `--environment-overrides` > is set, a number of required command-line options (in particular, an -I > option to add /var/lib/dkms/zfs/2.1.6/build/include in the include > search path) fail to be set. I didn't manage to trace why exactly that > is, but you can see both a failing and a working example (for one object > file) at: > https://0x0.st/o0EC.txt > > FWIW, it seems like the build environment dkms uses inherits whatever > was present in the environment when apt was called. If this is the case, > then it feels to me including the `--environment-overrides` flag has > potential to make things brittle. The effect of the flag is to: "Give > variables taken from the environment precedence over variables from > makefiles." Any arbitrary environment variables the user may have set > for their own purposes might be unexpectedly overriding important > variables from the Makefile(s). > > ___ > Pkg-zfsonlinux-devel mailing list > pkg-zfsonlinux-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
Bug#1025171: zfs-dkms FTBFS against 6.0.0-5-amd64
Package: zfs-dkms Version: 2.1.6-3 Severity: serious It was built againt 6.0.0-3-amd64 on my sid machine, but suddenly stopped working with the recent 6.0.0-5-amd64 kernel.
Bug#1024380: transition: simdjson
Uploaded to unstable. Successfully built on all release archs: https://buildd.debian.org/status/package.php?p=simdjson On Sat, 2022-11-19 at 20:19 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2022-11-18 09:42:10 -0500, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > There was some minor API updates in the latest version of simdjson, > > which resulted an SOVERSION bump from 13 to 14. I've tried to build > > its reverse dependencies locally on an amd64 host, and the results > > are all good: > > > > cloudflare-ddns [ok] > > pcm [ok] > > > > I'd like to transit and let the next stable release > > ship the latest version. > > Please go ahead. > > Cheers
Bug#1024380: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, There was some minor API updates in the latest version of simdjson, which resulted an SOVERSION bump from 13 to 14. I've tried to build its reverse dependencies locally on an amd64 host, and the results are all good: cloudflare-ddns [ok] pcm [ok] I'd like to transit and let the next stable release ship the latest version. Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson13" | .depends ~ "libsimdjson14"; is_good = .depends ~ "libsimdjson14"; is_bad = .depends ~ "libsimdjson13"; Thank you for using reportbug
Bug#1023305: ITP: zst -- CLI tool for zstd (and other) compression
Name "zst" for a tool that supports multiple compression formats is ambiguous. If we could use special characters (of course we cannot), I think "*z" (wildcard z) will do. On Wed, 2022-11-02 at 02:38 +0100, Adam Borowski wrote: > Package: wnpp > Severity: wishlist > Owner: Adam Borowski > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name : zst > Version : not released yet > Upstream Author : yours truly > * URL : https://github.com/kilobyte/zst > Programming Lang: C > Description : CLI tool for zstd (and other) compression > > This is an alternate tool for zstd compression, one that takes a lot > less space than the official one. It also behaves in a way > consistent > with other Unix compressors: the level goes only up to 9, the > original > copy of the file is not kept, etc. > . > The executable can also replace gzip xz bzip2. > > > A bunch of features are not yet ready, but I'm filing this ITP now > that > the core functionality is already working but there's still time for > design changes. Stuff that's aimed for important/Essential needs to > be discussed well... > > Existing compressors: > | tool | lib > --+--+- > gzip | Ess | Ess > bzip2 | std | Ess (but it'd be nice to remove it) > xz | std | Ess > zstd | opt | Ess > lz4 | opt | libsystemd0 but not libelogind0 >
Bug#1022855: cron script floods system mail box with "which: this version of which is deprecated, use command -v instead"
Package: zfs-auto-snapshot Version: 1.2.4-2 Severity: important Tags: +patch Dear maintainer, After the deprecation of which, that command now creates lots of noise and floods the system mail box. A simple fix is to replace the command.
Bug#1022712: [Pkg-zfsonlinux-devel] Bug#1022712: zfsutils-linux: new trim code is broken
Control: tags -1 +pending Thanks for the patch. It is pending in git repo. On Mon, 2022-10-24 at 14:44 +0200, наб wrote: > Package: zfsutils-linux > Version: 2.1.6-2 > Severity: normal > Tags: patch > > Dear Maintainer, > > Please apply the attached patch that fixes trim. > > In particular, the breakage is in the use of "local", > but I've fixed up all the other issues I saw there > > See patch message for details. > > Best, > наб > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: x32 (x86_64) > Foreign Architectures: amd64, i386 > > Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages zfsutils-linux depends on: > ii init-system-helpers 1.65.2 > ii libblkid1 2.38.1-1.1+b1 > ii libc6 2.35-3 > ii libnvpair3linux 2.1.6-2 > ii libuuid1 2.38.1-1.1+b1 > ii libuutil3linux 2.1.6-2 > ii libzfs4linux 2.1.6-2 > ii libzpool5linux 2.1.6-2 > ii python3 3.10.6-1 > > Versions of packages zfsutils-linux recommends: > ii lsb-base 11.4 > ii sysvinit-utils [lsb-base] 3.05-6 > ii zfs-dkms [zfs-modules] 2.1.6-2 > ii zfs-zed 2.1.6-2 > > Versions of packages zfsutils-linux suggests: > pn nfs-kernel-server > pn samba-common-bin > pn zfs-initramfs | zfs-dracut > > -- Configuration Files: > /etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs' > > -- no debconf information > ___ > Pkg-zfsonlinux-devel mailing list > pkg-zfsonlinux-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
Bug#1021205: transition: simdjson
Thanks. It has been uploaded to unstable. On Fri, 2022-10-07 at 10:23 +0200, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 03/10/2022 19:22, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi release team, > > > > I'd like to start the transition of simdjson. It has only two > > reverse > > dependencies in testing: > > > > cloudflare-ddns > > pcm > > > > Both of them passed my local test with amd64 host. > > Go ahead. > > Cheers, > Emilio >
Bug#1021205: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, I'd like to start the transition of simdjson. It has only two reverse dependencies in testing: cloudflare-ddns pcm Both of them passed my local test with amd64 host. Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson9" | .depends ~ "libsimdjson13"; is_good = .depends ~ "libsimdjson13"; is_bad = .depends ~ "libsimdjson9"; Thank you for using reportbug
Bug#1020541: transition: rakudo
Thanks. rakudo 2022.07-1 has been uploaded to unstable. On Sun, 2022-09-25 at 15:49 +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2022-09-22 19:23:13 -0400, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > We would like to upload rakudo 2022.07 to unstable (2022.04). > > Hence requesting this transition to rebuild all raku packages. > > Please go ahead > > Cheers > > > > > > > Ben file: > > > > title = "rakudo"; > > is_affected = .depends ~ "raku-api-2022.04" | .depends ~ "raku-api- > > 2022.07"; > > is_good = .depends ~ "raku-api-2022.07"; > > is_bad = .depends ~ "raku-api-2022.04"; > > Thank you for using reportbug > > >
Bug#1020541: transition: rakudo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, We would like to upload rakudo 2022.07 to unstable (2022.04). Hence requesting this transition to rebuild all raku packages. Ben file: title = "rakudo"; is_affected = .depends ~ "raku-api-2022.04" | .depends ~ "raku-api-2022.07"; is_good = .depends ~ "raku-api-2022.07"; is_bad = .depends ~ "raku-api-2022.04"; Thank you for using reportbug
Bug#1013005: onednn: ftbfs with GCC-12
Control: fixed -1 2.6.1-1
Bug#1017772: OneTBB migration to testing stalled
Control: reassign -1 src:binutils 2.38.90.20220713-2 I believe this issue is a binutils regression instead of GCC-12 regression. The default linker ends up with segmentation fault on ppc64el. However, if I change the default linker from bfd to gold, the issue is temporarily bypassed in onetbb 2021.5.0-14. https://salsa.debian.org/science-team/tbb/-/commit/ad1fe7e7021a37b63f8c7a2b4dc0c766828e7758 I have uploaded -14 to experimental and it passed the NEW queue lightning fast. I shall upload -15 to unstable as long as it becomes green on all architectures. On Sun, 2022-09-04 at 10:59 -0400, M. Zhou wrote: > Control: affects -1 src:onetbb > > It's due to a regression bug in GCC-12 that caused linker internal > error on ppc64el: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017772 > Does not look like something I can look into. > > If you need it soon in testing, please go ahead and downgrade > compiler > to gcc-11 for ppc64el only. > > On Sun, 2022-09-04 at 10:50 +0530, Nilesh Patra wrote: > > Hi Mo, > > > > It seems that the migration of oneTBB to testing is stalled (since > > 16 > > days) due > > to FTBFS on ppc64el with some linker errors[1] > > I am not sure what is up there, could you please take a look? > > > > [1]: > > https://buildd.debian.org/status/fetch.php?pkg=onetbb=ppc64el=2021.5.0-13=1662266636=0 > > > >
Bug#1017772: OneTBB migration to testing stalled
Control: affects -1 src:onetbb It's due to a regression bug in GCC-12 that caused linker internal error on ppc64el: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017772 Does not look like something I can look into. If you need it soon in testing, please go ahead and downgrade compiler to gcc-11 for ppc64el only. On Sun, 2022-09-04 at 10:50 +0530, Nilesh Patra wrote: > Hi Mo, > > It seems that the migration of oneTBB to testing is stalled (since 16 > days) due > to FTBFS on ppc64el with some linker errors[1] > I am not sure what is up there, could you please take a look? > > [1]: > https://buildd.debian.org/status/fetch.php?pkg=onetbb=ppc64el=2021.5.0-13=1662266636=0 >
Bug#1019098: src:tbb: do not migrate. this source is deprecated in favor of src:onetbb
Source: tbb Version: 2020.3-2.1 Severity: serious src:tbb: do not migrate. this source is deprecated in favor of src:onetbb. The RM bug of src:tbb is filed at https://bugs.debian.org/1014990
Bug#1009200: pytorch: (autopkgtest) needs update for python3.10: 'float' object cannot be interpreted as an integer
On Sat, 2022-08-27 at 08:55 +0200, Emanuele Rocca wrote: > On 08/04 09:36, Paul Gevers wrote: > > We are in the transition of making python3.10 the default Python > > versions > > [0]. With a recent upload of python3-defaults the autopkgtest of > > pytorch > > fails in testing when that autopkgtest is run with the binary > > packages of > > python3-defaults from unstable. It passes when run with only > > packages from > > testing. FYI, everything is already fixed in git a couple of months ago, and we are just waiting for the package to go through NEW queue.
Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_allo
The bug should have been fixed in the -13 upload of src:onetbb The FTBFS occurred because of GCC-11 -> GCC-12 bump. According to upstream suggestion, we can simply turn off some warnings. Please let me know if this bug persists. On Wed, 2022-08-24 at 13:21 -0700, Diane Trout wrote: > On Fri, 2022-08-12 at 13:57 +0200, Lucas Nussbaum wrote: > > On 08/08/22 at 22:45 +0200, Richard B. Kreckel wrote: > > > I am unable to reproduce the above compile-time error. > > > > Hi, > > > > I can still reproduce it. > > > > Lucas > > > > I saw this bug floating around and thought I'd try building tbb as > well. > > The version in git on salsa built for me without issues. Though I was > wondering if maybe the build process behaves differently depending on > the cpu architecture? > > I've run into a few programs that behave differently at compile time > depending on the build cpu. > > > So here's the end of the sbuild run and the start of cat /proc/cpuinfo > on the machine I used. > > > +-- > + > > Summary > > > +-- > + > > Build Architecture: amd64 > Build Type: full > Build-Space: 2839101 > Build-Time: 1683 > Distribution: unstable > Host Architecture: amd64 > Install-Time: 82 > Job: /woldlab/loxcyc/home/diane/src/debian/onetbb_2021.5.0-13.dsc > Lintian: info > Machine Architecture: amd64 > Package: onetbb > Package-Time: 1775 > Source-Version: 2021.5.0-13 > Space: 2839101 > Status: successful > Version: 2021.5.0-13 > --- > - > Finished at 2022-08-24T18:51:48Z > Build needed 00:29:35, 2839101k disk space > diane@trog:~/src/debian/tbb$ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family: 6 > model : 15 > model name: Intel(R) Xeon(R) CPU E5320 @ 1.86GHz > stepping : 7 > microcode : 0x66 > cpu MHz : 1748.216 > cache size: 4096 KB > physical id : 0 > siblings : 4 > core id : 0 > cpu cores : 4 > apicid: 0 > initial apicid: 0 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp: yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall > nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf > pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm > pti tpr_shadow dtherm > vmx flags : tsc_offset vtpr > bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass > l1tf mds swapgs itlb_multihit > bogomips : 3723.91 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: >
Bug#1017772: GCC-12 internal error when compiling onetbb on ppc64el
Package: gcc-12 Version: 12.1.0-8 Severity: important This bug seems like a regression. GCC-11 has no issue compiling the same source. https://buildd.debian.org/status/fetch.php?pkg=onetbb=ppc64el=2021.5.0-13=1660844413=0 [183/315] : && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now-rdynamic test/CMakeFiles/test_join_node.dir/tbb/test_join_node.cpp.o -o gnu_12.1_cxx11_64_none/test_join_node -Wl,-rpath,/<>/obj-powerpc64le-linux-gnu/gnu_12.1_cxx11_64_none gnu_12.1_cxx11_64_none/libtbb.so.12.5 -ldl && : FAILED: gnu_12.1_cxx11_64_none/test_join_node : && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now-rdynamic test/CMakeFiles/test_join_node.dir/tbb/test_join_node.cpp.o -o gnu_12.1_cxx11_64_none/test_join_node -Wl,-rpath,/<>/obj-powerpc64le-linux-gnu/gnu_12.1_cxx11_64_none gnu_12.1_cxx11_64_none/libtbb.so.12.5 -ldl && : /usr/bin/ld: internal error ../../ld/ldlang.c 6452 collect2: error: ld returned 1 exit status
Bug#976805: Progress?
https://salsa.debian.org/pkg-security-team/imhex I forgot the current status. In my fuzzy memory there are some new dependencies to be packaged. On Sat, 2022-07-30 at 11:07 -0700, Dima Kogan wrote: > Hi. Is this coming along? What needs to happen to get this into the > repos? Do you need help? > > Thanks!
Bug#1003165: scikit-learn testing migration
I have a long-term power 9 VM (not QEMU) as testbed. I'm trying to investigate the issues for release architectures, but this package is too slow to build with QEMU (multiple hours). (abel.debian.org is also extremely slow for scikit-learn) I've not yet given up, but the build speed means I cannot address this issue in timely manner. On Thu, 2022-07-28 at 10:15 +0200, Andreas Tille wrote: > Hi Graham, > > Am Thu, Jul 28, 2022 at 09:15:06AM +0200 schrieb Graham Inggs: > > Hi > > > > On Wed, 27 Jul 2022 at 17:57, M. Zhou wrote: > > > The previous segfault on armel becomes Bus Error on armel and armhf. > > > I can build it on Power9, but it seems that the test fails on power8 (our > > > buildd). > > > > In #1003165, one of the arm porters wrote they are happy to look at > > the bus errors, but the baseline issue should be fixed first. > > ... this was five months ago and silence since then. We've lost lots of > packages in testing and I see no progress here. It seems upstream is not > actually keen on working on this as well. Meanwhile they stepped forward > with new releases and I simply refreshed the issues for the new version > (which are the same and not solved). > > Currently we have bus errors on arm 32 bit architectures and a baseline > violation on power. If there is no solution at the horizon I'd vote for > excluding these three architectures instead of sit and wait (which is all > I can personally do in this topic). > > > > I have skimmed over the build logs and one of the main issues is the use > > > of > > > -march flags to enforce a certain baseline [1]: > > > > > > powerpc64le-linux-gnu-gcc: error: unrecognized command-line option > > > ‘-march=native’; did you mean ‘-mcpu=native’? > > > > This may be the cause of the test failures on power8. > > Could someone give this a try? I know I could use a porter box to do > so but my time is to limited to do it in a sensible time frame. > > Kind regards > > Andreas. >
Bug#1016194: RM: onednn [all] -- ROM; no longer build for arch:all
Package: ftp.debian.org Severity: normal I removed bin:onednn-doc from src:onednn because it feels like a maintenance burden to me, and this doc package has a very low popcon number. Thus, since we no longer build bin:onednn-doc, we need to remove it so that the package can migrate to testing. Thank you for using reportbug
Bug#1008369: scikit-learn testing migration
The previous segfault on armel becomes Bus Error on armel and armhf. I can build it on Power9, but it seems that the test fails on power8 (our buildd). On Wed, 2022-07-27 at 09:56 +0200, Andreas Tille wrote: > Control: tags -1 unreproducible > Control: tags -1 moreinfo > Control: severity -1 important > > Hi, > > BTW, there is another bug in scikit-learn, but I can't reproduce it and > have set tags accordingly. Could someone else please give it a try? > > Kind regards > > Andreas. > > Am Wed, Jul 20, 2022 at 09:23:28PM +0200 schrieb Andreas Tille: > > Hi Nilesh, > > > > Am Wed, Jul 20, 2022 at 06:21:19PM +0530 schrieb Nilesh Patra: > > > On 7/20/22 4:50 PM, Andreas Tille wrote: > > > > Before we stop progress in Debian for many other architectures since we > > > > cant't solve this on our own or otherwise are burning patience of > > > > upstream I'd alternatively consider droping armel as supported > > > > architecture. > > > > > > I am definitely +1 for this, however scikit-learn is a key package and > > > dropping > > > it from armel would mean dropping several revdeps as well. > > > I am a bit unsure if that is fine or not. > > > > Its not fine at all and I would not be happy about it. However, the other > > side of a key package is, that lots of package have testing removal warnings > > on architectures which are widely used and we have real trouble because of > > this. > > > > Kind regards > > > > Andreas. > > > > -- > > http://fam-tille.de > > > > >
Bug#1015805: scikit-learn tries to access network during documentation build
Source: scikit-learn Version: 1.1.1-1 Severity: serious Justification: Policy section 4.9 violation There are loads of similar traceback message saying the documentation build has failed to retrieve some URL, like this: ``` generating gallery for auto_examples/decomposition... [ 30%] plot_faces_decomposition.py WARNING: /<>/examples/decomposition/plot_faces_decomposition.py failed to execute correctly: Traceback (most recent ca ll last): File "/<>/examples/decomposition/plot_faces_decomposition.py", line 36, in faces, _ = fetch_olivetti_faces(return_X_y=True, shuffle=True, random_state=rng) File "/<>/.pybuild/cpython3_3.10/build/sklearn/datasets/_olivetti_faces.py", line 117, in fetch_olivetti_faces mat_path = _fetch_remote(FACES, dirname=data_home) File "/<>/.pybuild/cpython3_3.10/build/sklearn/datasets/_base.py", line 1511, in _fetch_remote urlretrieve(remote.url, file_path) File "/usr/lib/python3.10/urllib/request.py", line 241, in urlretrieve with contextlib.closing(urlopen(url, data)) as fp: File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen return opener.open(url, data, timeout) File "/usr/lib/python3.10/urllib/request.py", line 519, in open response = self._open(req, data) File "/usr/lib/python3.10/urllib/request.py", line 536, in _open result = self._call_chain(self.handle_open, protocol, protocol + File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain result = func(*args) File "/usr/lib/python3.10/urllib/request.py", line 1391, in https_open return self.do_open(http.client.HTTPSConnection, req, File "/usr/lib/python3.10/urllib/request.py", line 1351, in do_open raise URLError(err) urllib.error.URLError: ``` This is clearly policy violation and should be patched. This issue is found during the QEMU build on ppc64el machine for the armel architecture, and it extremly slows down the building process likely due to URL access timeout. As a result, the URL access timeout took the whole night and the doc build is not yet finished by a half. Well, I guess I will have to wait for two or three days to see the discussed armel segfault in qemu with this problem unfixed.
Bug#1015200: [blender] libtbb2 deprecated in favor of src:onetbb
Source: blender Severity: important libtbb2 (src:tbb) has been deprecated (#1014990) in favor of libtbb12 (src:onetbb). And blender is still one of the reverse dependencies of libtbb2. Please migrate to the new library.
Bug#1007222: transition: onetbb
I've filed the RM bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014990 Seems that we still have a bunch of blockers -- so this is not likely happening soon. On Fri, 2022-07-15 at 20:16 +0200, Graham Inggs wrote: > Hi > > libtbb2 is now gone from testing. Please file a RM bug for src:tbb > against ftp.debian.org, but maybe tag it 'moreinfo' until it is clear > what will happen to libtbb2's reverse-dependencies still in unstable. > > Regards > Graham
Bug#1014990: RM: tbb -- ROM; deprecated in favor of src:onetbb
Package: ftp.debian.org Severity: normal Tags: +moreinfo We have (somewhat) done the src:tbb -> src:onetbb transition, and the old codebase src:tbb is now deprecated. Before we really remove src:tbb from unstable, we still have some packages not yet finished the transition. I'll later file bugs (if there isn't) against the reverse dependencies and let the bugs block this one. libtbb2 Reverse Depends: Depends: python3-openvdb (>= 2017~U7) Depends: libopenvdb9.1 (>= 2017~U7) Depends: libopenvdb-tools (>= 2017~U7) Depends: libgazebo11 (>= 2017~U7) Depends: casparcg-server (>= 2017~U7) Breaks: libtbbmalloc2 (<< 2020.3-1ubuntu2) Depends: libyade (>= 2017~U7) Depends: twopaco (>= 2017~U7) Depends: prusa-slicer (>= 2017~U7) Depends: salmon (>= 2017~U7) Depends: r-cran-rstanarm (>= 2017~U7) Depends: python3-openvdb (>= 2017~U7) Depends: libopenvdb8.1 (>= 2017~U7) Depends: libopenvdb-tools (>= 2017~U7) Depends: libosdcpu3.4.4 (>= 2017~U7) Depends: libopenimageio2.3 (>= 2017~U7) Replaces: libtbbmalloc2 (<< 2020.3-1ubuntu2) Depends: embree-tools (>= 2017~U7) Depends: mpqc3 (>= 2017~U7) Depends: libgazebo11 (>= 2017~U7) Depends: flexbar (>= 2017~U7) Depends: libembree3-3 (>= 2018~U6) Depends: blender (>= 2018~U6) Thank you for using reportbug
Bug#1000922: reopen
Control: reopen -1 Control: found -1 0.38.1-3 Simply upgrading llvm deps from 11 to 13 leads to regression for numba. I'm reverting this change back until the upstream source code can really support a newer version.
Bug#1014661: ITP: lodepng -- LodePNG is a PNG image decoder and encoder
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: lodepng Version : git master Upstream Author : Lode Vandevenne * URL : https://lodev.org/lodepng/ * License : Zlib Programming Lang: C Description : LodePNG is a PNG image decoder and encoder More than one package of my insterest has this dependency, including the mujoco physics simulator. Thank you for using reportbug
Bug#1003397: ITP: rapidyaml -- a library to parse and emit YAML, and do it fast.
Control: retitle -1 RFP: rapidyaml -- a library to parse and emit YAML, and do it fast. Control: owner -1 w...@debian.org I'm giving up this ITP bug. Any one who is interested in this ITP can take it over.
Bug#1014570: RM: rocm-device-libs/experimental [all] -- ROM; the binary packages are arch-dependent now
Package: ftp.debian.org Severity: normal The latest rocm-device-libs package is no longer producing arch-indep binary packages. And we will keep working on arch-specific packages. The arch:all package is no longer useful and it was not automatically removed. Thank you for using reportbug
Bug#1014569: transition: flatbuffers
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition PyTorch 1.12 will need flatbuffers 2.X . Specifically I'm going to upload flatbuffers 2.0.6+dfsg1 to unstable. It has three reverse dependencies as per build-rdeps. vast [already ftbfs due to libfmt] #1001527 kodi [already ftbfs due to ffmpeg] #1004612 armnn [ok] 20.08-10 Seems that we can go ahead with this. Ben file: title = "flatbuffers"; is_affected = .depends ~ "libflatbuffers1" | .depends ~ "libflatbuffers2"; is_good = .depends ~ "libflatbuffers2"; is_bad = .depends ~ "libflatbuffers1"; Thank you for using reportbug
Bug#1011033: onnx: flaky autopkgtest on armhf: Arrays are not almost equal to 7 decimals
Control: severity -1 important I've uploaded 1.12 to unstable. Let's see whether the situation has been changed a little bit for armhf. Floating point precision is sometimes flaky indeed, but I think this would not be that fatal. So changing the severity down to important. If the flaky test no longer appears, I'll close it.
Bug#1014491: python3-torch: import fails: undefined symbol
Hi, Thanks for the bug report. I'm aware of the break, and other users have reported this issue some time before: https://lists.debian.org/debian-ai/2022/06/msg00060.html The break is due to onnx 1.12 upgrade. The pytorch version in the new queue works fine with onnx 1.12, as mentioned in the above mailing list post. If you would like to continue using pytorch 1.8 for a while, you may need to pin onnx to the previous version, or rollback using our snapshot archive. When dealing with the pytorch 1.12 upgrade, I lost (to be honest I would like to stick to 1.8 but we have to go through python 3.10 transition) access to build machines due to complicated reasons, and the access will not be recovered. So in order to continue the pytorch upgrade, I have to upload reverse dependencies to unstable early, so that I can build pytorch and upload to the NEW queue. Theoretically this bug can only be resolved when pytorch 1.12 passes the new queue. On Wed, 2022-07-06 at 14:01 -0700, Dima Kogan wrote: > Package: python3-torch > Version: 1.8.1-5+b1 > Severity: grave > X-Debbugs-Cc: none, Dima Kogan > > Hi. Thanks for maintaining pytorch. I can't imagine the pain it took to > get this packaged. Currently it doesn't work, unfortunately: > > $ python3 -mtorch > > Traceback (most recent call last): > File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main > mod_name, mod_spec, code = _get_module_details(mod_name, _Error) > File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details > return _get_module_details(pkg_main_name, error) > File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details > __import__(pkg_name) > File "/usr/lib/python3/dist-packages/torch/__init__.py", line 196, in > > from torch._C import * > ImportError: /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.8: undefined > symbol: > _ZN4onnx12optimization8OptimizeERKNS_10ModelProtoERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISA_EE > > This symbol is missing. I looked around, and I can't figure out which > package was supposed to provide it. Without it the linking fails, and > the package is unusable. Am I missing some dependency? > > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), > (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, armhf > > Kernel: Linux 5.16.0-5-amd64 (SMP w/4 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) (ignored: > LC_ALL set to en_US.utf-8), LANGUAGE=en_US.utf-8 > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages python3-torch depends on: > ii libc6 2.33-7 > ii libdnnl22.6-1 > ii libgcc-s1 12.1.0-4 > ii libgloo00.0~git20220518.5b14351-1 > ii libgoogle-glog0v6 0.6.0-1 > ii libonnx11.12.0-1 > ii libprotobuf23 3.12.4-1+b2 > ii libstdc++6 12.1.0-4 > ii libtorch-test 1.8.1-5+b1 > ii libtorch1.8 1.8.1-5+b1 > ii python3 3.10.4-1+b1 > ii python3-future 0.18.2-5 > ii python3-numpy [python3-numpy-abi9] 1:1.21.5-1 > ii python3-pkg-resources 59.6.0-1 > ii python3-requests2.25.1+dfsg-2 > ii python3-six 1.15.0-2 > ii python3-typing-extensions 3.10.0.2-1 > ii python3-yaml5.4.1-1+b1 > ii python3.10 3.10.5-1 > > Versions of packages python3-torch recommends: > ii build-essential 12.9 > pn libtorch-dev > ii ninja-build 1.10.1-1 > pn pybind11-dev > > Versions of packages python3-torch suggests: > ii python3-hypothesis 5.43.3-1 > ii python3-pytest 6.2.5-1 > > -- no debconf information >
Bug#1012362: transition: luajit
Hi Paul, I did not file the corresponding bugs. According to our workflow, will I or the release team file those bugs? If it is me who should file those bugs, I think the default severity should be serious. When all related bugs are resolved by reverse dependencies, I plan to remove ppc64el architecture from both src:luajit and src:luajit2, so that malfunctional binary packages are no longer built for it. On Mon, 2022-06-20 at 22:10 +0200, Paul Gevers wrote: > Hi Mo, > > On 13-06-2022 05:20, M. Zhou wrote: > > So let's inform the reverse dependencies to remove ppc64el support, > > or switch back to lua. > > Just curious, have you already done so? If yes, care to share the bug > report numbers? Otherwise I assume you expected me to file those bugs? > > Paul > > elbrus@coccia:~$ dak rm --no-action -R --suite testing luajit > --architecture=ppc64elW: -a/--architecture implies -p/--partial. > Will remove the following packages from testing: > > libluajit-5.1-2 | 2.1.0~beta3+dfsg-6 | ppc64el > libluajit-5.1-dev | 2.1.0~beta3+dfsg-6 | ppc64el > luajit | 2.1.0~beta3+dfsg-6 | source, ppc64el > > Maintainer: Enrico Tassi > > --- Reason --- > > -- > > Checking reverse dependencies... > # Broken Depends: > lua-ljsyscall: lua-ljsyscall > > # Broken Build-Depends: > bpfcc: libluajit-5.1-dev > luajit > cantor: libluajit-5.1-dev > dnsjit: libluajit-5.1-dev > luajit > efl: libluajit-5.1-dev > fastnetmon: libluajit-5.1-dev > love: libluajit-5.1-dev > lua-ljsyscall: luajit > nageru: libluajit-5.1-dev > nginx: libluajit-5.1-dev > obs-studio: libluajit-5.1-dev > suricata: libluajit-5.1-dev > uftrace: libluajit-5.1-dev > wrk: libluajit-5.1-dev > luajit > > Dependency problem found.
Bug#1013214: O: asmjit -- Complete x86/x64 JIT and AOT Assembler for C++
Package: wnpp Severity: normal Control: affects -1 src:asmjit I intend to orphan the asmjit package. This package is in good shape. This package is a dependency of some optional pytorch dependencies, but I've forgotten the particular name. Anyway, I'm no longer planning to enable that optional dependency. So I'm no longer interested in maintaining this package. The package description is: AsmJit is a complete JIT and AOT assembler for C++ language. It can generate native code for x86 and x64 architectures and supports the whole x86/x64 instruction set - from legacy MMX to the newest AVX512. It has a type-safe API that allows C++ compiler to do semantic checks at compile-time even before the assembled code is generated and/or executed. . This package contains the header files and the static library. Thank you for using reportbug
Bug#971692: ITP: openzfs-docs -- OpenZFS Documentation
Control: close -1 It is not really necessary to package a volatile documentation project. Looking up through internet is already convenient enough.
Bug#964543: ITP: pymc3 -- Bayesian statistical modeling and Probabilistic Machine Learning
Control: owner -1 w...@debian.org Control: retitle -1 RFP: pymc3 -- Bayesian statistical modeling and Probabilistic Machine Learning I'm no longer interested in packaging this on my own.
Bug#959123: ITP: fbgemm -- Facebook GEneral Matrix Multiplication
Control: close -1 I'm no longer interested in packaging this. This package is only useful for pytorch. And I'm no longer planning to enable this package in pytorch build.
Bug#1013213: gftools: version outdated, blocking build of cascadia code
Source: gftools Version: 0.5.2+dfsg-2 Severity: wishlist Dear maintainer, I believe the gftools version in unstable is seriously outdated. And fonts-cascadia-code 2111.01 requires a newer version to successfully build. Please consider packaging a newer version if possible. make[1]: Entering directory '/<>' python3 build.py Traceback (most recent call last): File "/<>/build.py", line 17, in from gftools.stat import gen_stat_tables_from_config ImportError: cannot import name 'gen_stat_tables_from_config' from 'gftools.stat' (/usr/lib/python3/dist- packages/gftools/stat.py) make[1]: *** [debian/rules:10: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Build finished at 2022-06-19T02:44:43Z
Bug#1013212: O: vim-julia -- Vim support for Julia language
Package: wnpp Severity: normal Control: affects -1 src:vim-julia I intend to orphan the vim-julia package. This package is in good shape. This package is team-maintained, but in fact I'm the only effective maintainer. I'm no longer interested in maintaining this package. The package description is: An overview of some of the features: * Latex-to-Unicode substitutions * Block-wise movements and block text-objects * Changing syntax highlighting depending on the Julia version . The full documentation is available from Vim: after installation, you just need to type :help julia-vim. . To enable this vim addon, simply issue the following command: $ vam install julia Thank you for using reportbug
Bug#1013210: O: nsync -- C library that exports various synchronization primitives
Package: wnpp Severity: normal Control: affects -1 src:nsync I intend to orphan the nsync package. This package is tensorflow dependency. This package is in very good shape. I'm no longer interested in maintaining tensorflow dependencies. The package description is: nsync is a C library that exports various synchronization primitives: . * locks * condition variables * run-once initialization * waitable counter (useful for barriers) * waitable bit (useful for cancellation, or other conditions) . This package ships C++ shared object. Thank you for using reportbug
Bug#1013209: O: farmhash -- FarmHash, a family of hash functions
Package: wnpp Severity: normal Control: affects -1 src:farmhash I intend to orphan the farmhash package. This package is tensorflow dependency. This package is in good shape. I'm no longer interested in maintaining tensorflow dependency. The package description is: FarmHash provides hash functions for strings and other data. The functions mix the input bits thoroughly but are not suitable for cryptography. . This package contains development files and document. Thank you for using reportbug
Bug#1013208: O: highwayhash -- Fast strong hash functions: SipHash/HighwayHash
Package: wnpp Severity: normal Control: affects -1 src:highwayhash I intend to orphan the highwayhash package. It is tensorflow dependency. This package is in good shape. I'm no longer interested in maintaining tensorflow dependencies. The package description is: Highwayhash provides three 'strong' (well-distributed and unpredictable) hash functions: a faster version of SipHash, a data-parallel variant of SipHash using tree hashing, and an even faster algorithm called HighwayHash. . SipHash is a fast but 'cryptographically strong' pseudo-random function by Aumasson and Bernstein [https://www.131002.net/siphash/siphash.pdf]. . SipTreeHash slices inputs into 8-byte packets and computes their SipHash in parallel, which is faster when processing at least 96 bytes. . HighwayHash is a new way of mixing inputs which may inspire new cryptographically strong hashes. Large inputs are processed at a rate of 0.3 cycles per byte, and latency remains low even for small inputs. HighwayHash is faster than SipHash for all input sizes, with about 3.8 times higher throughput at 1 KiB. . This package ships the static library and development files. Thank you for using reportbug
Bug#1013207: RM: nnpack/experimental -- ROM; FTBFS; don't want to maintain anymore
Package: ftp.debian.org Severity: normal This package has been FTBFS for a long period. I have no interest in bringing it back into good shape. Thank you for using reportbug
Bug#1013206: O: python-fire -- automatically generate CLIs from absolutely any Python object
Package: wnpp Severity: normal Control: affects -1 src:python-fire I intend to orphan the python-fire package. This package is in good shape. I'm just not interested in maintaining this anymore. The package description is: Python Fire is a library for automatically generating command line interfaces (CLIs) from absolutely any Python object. . * Python Fire is a simple way to create a CLI in Python. * Python Fire is a helpful tool for developing and debugging Python code. * Python Fire helps with exploring existing code or turning other people's code into a CLI. * Python Fire makes transitioning between Bash and Python easier. * Python Fire makes using a Python REPL easier by setting up the REPL with the modules and variables you'll need already imported and created. Thank you for using reportbug
Bug#1002968: #1002968 tbb build success on riscv now
Control: reassign -1 src:onetbb Control: fixed -1 2021.5.0-8 src:tbb has been renamed into src:onetbb. riscv build was already fixed. On Sat, 2022-06-18 at 09:22 +0800, xiao sheng wen wrote: > Hi, > The tbb package had build successed on riscv now. > libtbb2 is one of it's binary package: > apt show libtbb2 > Package: libtbb2 > Version: 2020.3-2.1 > Priority: optional > Section: libs > Source: tbb > Maintainer: Debian Science Maintainers > > Installed-Size: 224 kB > Depends: libtbbmalloc2, libatomic1 (>= 4.8), libc6 (>= 2.32), libgcc-s1 (>= > 3.4), libstdc++6 (>= 11) > Homepage: https://www.threadingbuildingblocks.org/ > Download-Size: 109 kB > APT-Sources: https://mirrors.tencent.com/debian-ports unstable/main riscv64 > Packages > Description: parallelism library for C++ - runtime files > > The tbb (2020.3-2.1) cmake entry in debian/control still is: > > | Build-Depends: debhelper-compat (= 12), > |libjs-jquery, > |dh-exec, > |gdb, > | cmake [amd64 i386 arm64 armhf mips64el mipsel ppc64el s390x], > > It has not riscv list in, perhaps this cmake arches list is not necessary. >
