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#1076173: armnn: please rebuild against the latest flatbuffers
Source: armnn Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076174: buildbot: please rebuild against flatbuffers
Source: buildbot Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076175: gnome-keysign: please rebuild against flatbuffers
Source: gnome-keysign Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076176: kodi: please rebuild against flatbuffers
Source: kodi Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076177: libsigmf: please rebuild against flatbuffers
Source: libsigmf Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076178: magic-wormhole: please rebuild against flatbuffers
Source: magic-wormhole Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076179: paraview: please rebuild against flatbuffers
Source: flatbuffers Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076180: python-autobahn: please rebuild against flatbuffers
Source: python-autobahn Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076181: python-daphne
Source: python-daphne Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076182: python-django-channels: please rebuild against flatbuffers
Source: python-django-channels Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076183: pytorch: please rebuild against flatbuffers
Source: pytorch Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076184: starlette: please rebuild against flatbuffers
Source: starlette Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076185: zaqar: please rebuild against flatbuffers
Source: zaqar Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1076186: zlmdb: please rebuild against flatbuffers
Source: zlmdb Severity: normal Control: affects -1 + src:flatbuffers Dear maintainer, Please rebuild the package against the latest flatbuffer package, which is going to be uploaded to from experimental to unstable soon. The package Build-Depends: on flatbuffer packages, but does not link against libflatbuffers2, so the transition tracker may miss some statically linked old binaries. Please refer the transition Bug#1060188 for more details.
Bug#1060188: transition: flatbuffers
On Sun, 2024-01-21 at 16:54 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Should those that are not part of the transition tracker use the > shared > library or not? No. In order to make this simpler, I notified all reverse dependencies to rebuild against the latest flatbuffers, and marked the bugs as affects src:flatbuffers. armnn [OK] Bug#1076173 buildbot [OK] Bug#1076174 facet-analyser [not in testing; FTBFS already] gnome-keysign [OK] Bug#1076175 kodi [OK] Bug#1076176 libsigmf [OK] Bug#1076177 magic-wormhole [OK] Bug#1076178 magic-wormhole-mailbox-server [FTBFS already; irrelevant, #1058173] paraview [OK] Bug#1076179 python-autobahn [OK] Bug#1076180 python-daphne [OK] Bug#1076181 python-django-channels [OK] Bug#1076182 pytorch [OK]Bug#1076183 starlette [OK] Bug#1076184 vast [not in testing; FTBFS already] zaqar [OK] Bug#1076185 zlmdb [OK] Bug#1076186 Shall we proceed and upload to unstable?
Bug#1058657: patch
Control: tags -1 +patch https://salsa.debian.org/apt-team/python-apt/-/merge_requests/90
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(&wc, &in[in_pos], in_len - in_pos, &state);
+ // 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#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#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#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#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#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#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#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#1013005: onednn: ftbfs with GCC-12
Control: fixed -1 2.6.1-1
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#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#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#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#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#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#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#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#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#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#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#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#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#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() == &pager.search_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
--- fish-3.6.0/debian/patches/0002-reader-Remove-assert-in-his
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
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#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#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#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#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#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
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#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#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
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#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#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#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#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#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#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#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 packa
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)
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#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#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#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#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#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#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#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#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&arch=ppc64el&ver=2021.5.0-13&stamp=1662266636&raw=0 >
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&arch=ppc64el&ver=2021.5.0-13&stamp=1662266636&raw=0 > > > >
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#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#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#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#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#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#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#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#989550: suitesparse: enhance 64-bit support in suitesparse
Hi Drew, Thanks for the proposal. Just for your information, there is a WIP branch on suitesparse64: https://salsa.debian.org/science-team/suitesparse/-/commits/lumin I just ... ummm ... need some time to finish it. Of course, any help would be appreciated. On Mon, 2021-06-07 at 12:56 +0200, Drew Parsons wrote: > Package: suitesparse > Severity: normal > Control: block -1 by 961183 > Control: block 961977 by -1 > > We've been introducing a 64 bit-build for the computational stack. > This refers mainly to 64-bit indexing, enabling computation of > extremely large systems (billions of degrees of freedom) > > Some packages are already 64-bit enabled, including BLAS, PETSc. > > SuiteSparse handles the 64-bit question by defining SuiteSparse_long > (and using idx_t with metis). If I understand the SuiteSparse > configuration correctly, this means a specific configuration option > doesn't need to be set for SuiteSparse to compute large systems. > > But as part of the 64-bit computation stack in Debian, we'd need to > provide a separate suitesparse64 build in order to link suitesparse > against blas64 or metis64. (I'm assuming this is a thing we would > want > to do in the context of 64-bit computation). > > This affects cholmod, for instance, in the sense that cholmod uses > idx_t defined in metis.h. IDXTYPEWIDTH is the quantity in metis.h > which we'll need to set to 64, in order to provide 64-bit Metis (this > is requested in Bug#961183). > > Once metis64 is available, we'll be free to provide suitesparse64 > i.e. libsuitesparse64-dev (it might be that header files can be > transferred to a libsuitesparse-common-dev to share with > libsuitesparse-dev), > libcholmod64-3 (or similar), etc. > > Once suitesparse64 is available, we'll be able link it from petsc64, > which is currently linking to the standard build of suitesparse. > > Drew > > > -- System Information: > Debian Release: 11.0 > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'unstable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_OOT_MODULE > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), > LANGUAGE=en_AU:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled >
Bug#990398: unblock: zfs-linux/2.0.3-9 (pre-approval)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package zfs-linux [ Reason ] We want to cherry-pick a three-line fix for an important bug. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989373 diff --git a/module/os/linux/zfs/zpl_file.c b/module/os/linux/zfs/zpl_file.c index 421aebefe46..524c43dcded 100644 --- a/module/os/linux/zfs/zpl_file.c +++ b/module/os/linux/zfs/zpl_file.c @@ -342,9 +342,6 @@ zpl_iter_write(struct kiocb *kiocb, struct iov_iter *from) ssize_t wrote = count - uio.uio_resid; kiocb->ki_pos += wrote; - if (wrote > 0) - iov_iter_advance(from, wrote); - return (wrote); } [ Impact ] Potential memory corruption / data loss. [ Risks ] This has been sufficiently tested by ZFS upstream. And this fix is a part of their new stable release: https://github.com/openzfs/zfs/commit/412b69dfabe223a69159c8579ba808b49f0982e0 unblock zfs-linux/2.0.3-9 Thank you for using reportbug
Bug#993696: RM: qnnpack/experimental -- ROM; Deprecated by Upstream
Package: ftp.debian.org Severity: normal https://github.com/pytorch/QNNPACK The codebase has been archived, and merged into src:pytorch by upstream. Thank you for using reportbug
Bug#932377: ITP: dvc -- Version Control System for Machine Learning Projects
On Fri, 2021-05-07 at 11:33 -0600, Anthony Fok wrote: > > Mo (lumin), I saw that you came pretty far in packaging DVC (dvc.org) > at > > https://salsa.debian.org/deeplearning-team/dvc > > Would you be so kind as to continue your work and upload dvc into > Debian proper? > I'm very interested in this software too, e.g. as a potential > replacement of Git LFS for storing large CSV files generated by > OpenQuake which my fellow team members work with day to day. I stopped working on it due to bulky unpackaged python dependencies (and don't know how it looks recently). BTW, I just granted you the owner access to deep learning team. Please don't hesitate to commit changes if you want.
Bug#990398: unblock: zfs-linux/2.0.3-9 (pre-approval)
Control: tags -1 -moreinfo zfs-linux 2.0.3-9 has been uploaded to unstable. On Tue, 2021-06-29 at 20:59 +0200, Sebastian Ramacher wrote: > Control: tags -1 moreinfo confirmed > > On 2021-06-28 09:01:04 +, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package zfs-linux > > > > [ Reason ] > > > > We want to cherry-pick a three-line fix for an important bug. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989373 > > > > diff --git a/module/os/linux/zfs/zpl_file.c > > b/module/os/linux/zfs/zpl_file.c > > index 421aebefe46..524c43dcded 100644 > > --- a/module/os/linux/zfs/zpl_file.c > > +++ b/module/os/linux/zfs/zpl_file.c > > @@ -342,9 +342,6 @@ zpl_iter_write(struct kiocb *kiocb, struct > > iov_iter > > *from) > > ssize_t wrote = count - uio.uio_resid; > > kiocb->ki_pos += wrote; > > > > - if (wrote > 0) > > - iov_iter_advance(from, wrote); > > - > > return (wrote); > > } > > > > > > [ Impact ] > > > > Potential memory corruption / data loss. > > > > [ Risks ] > > > > This has been sufficiently tested by ZFS upstream. And > > this fix is a part of their new stable release: > > https://github.com/openzfs/zfs/commit/412b69dfabe223a69159c8579ba808b49f0982e0 > > > > > > unblock zfs-linux/2.0.3-9 > > Thank you for using reportbug > > ACK, please go ahead and remove the moreinfo tag once the new version > is > available in unstable. > > Cheers
Bug#990745: better nvme device detection in cron scripts
Source: zfs-linux
Version: 2.0.3-9
Severity: normal
Tags: patch
Credit: Miao Wang
get_transp(){
local dev="$1"
local par_dev="$dev"
local pd
while true; do
pd=$(lsblk -dnr -o PKNAME "$par_dev")
if [ "$?" -ne 0 ]; then
return $?
fi
if [ -z "$pd" ]; then
break
else
par_dev="/dev/$pd"
fi
done
lsblk -dnr -o TRAN "$par_dev"
}
Bug#983398: Unable to boot after upgrading to zfs 2.0
Source: zfs-linux Version: 2.0.2-1~bpo10+1 Severity: important Tags: moreinfo https://lists.debian.org/debian-devel/2021/02/msg00257.html
Bug#983398: ZFS 2.0 update - buster
Hi Daniel, On Tue, 2021-02-23 at 12:23 +0100, Daniel Garcia Sanchez wrote: > Yesterday the backports ZFS package was updated to 2.0. I have a > machine using ZFS as the root filesystem. After the update the > machine was not able to boot. I think it was the ZFS update that > caused the problem. Thanks for the bug report. I've opened a bug against ZFS, and further discussions can be redirected to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983398 Could you please briefly describe the configuration of your ZFS so the others can try to reproduce the problem? And is there any existing bug similar to the one you have encountered? See: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=zfs-linux (Please drop debian-devel in the follow-ups).
Bug#983398: ZFS 2.0 update - buster
Control: close -1 Hi Daniel and Mathias, Thanks for the confirmation. Neither did I manage to reproduce the issue in virtualbox according to that guide. On Wed, 2021-03-03 at 19:45 +0100, Daniel Garcia Sanchez wrote: > Hi Mathias, > > Thanks a lot! > > I tried an older version, 2.0.2. Maybe it didn't work for me because > I > used an old version or something else related to my system. > > Mo, could you close this bug? The update 0.8.6 -> 2.0.3 is working > properly. > > Best, > Daniel > > On Wed, Mar 3, 2021 at 2:52 PM Mathias Gibbens > wrote: > > > > As another data point, I've successfully upgraded four buster > > installs from 0.8.6 -> 2.0.3 as packaged from the buster-backports > > repo. My setups are similar to Daniel's (ZFS as root filesystem, > > following the same install guide); one instance uses native ZFS > > encryption while the other three don't. All four also use ZFS for > > the > > /boot/ partition. One install is on physical hardware with legacy > > BIOS, > > and the other three are virtual machines. > > > > Mathias
Bug#984497: python-cython-blis package
For your information, the upstream holds a very negative attitude towards debian packaging. https://github.com/explosion/cython-blis/issues/32 CC'ed pabs. On Wed, 2021-03-03 at 17:51 +0100, Andreas Tille wrote: > On Wed, Mar 03, 2021 at 05:26:11PM +0100, Gard Spreemann wrote: > > > > Andreas Tille writes: > > > > > [1] https://salsa.debian.org/debian-science/python-cython-blis > > > > Hi, > > > > I think this is a typo. It should be > > > > https://salsa.debian.org/science-team/python-cython-blis > > > > right? > > Sure. Please always watch me closely. ;-) > > Kind regards > > Andreas. > >
Bug#984497: python-cython-blis package
On Thu, 2021-03-04 at 08:09 +0100, Andreas Tille wrote: > > I also intend to negotiate this again. While the copyright holders > are > > 2018 The University of Texas at Austin > 2016 Hewlett Packard Enterprise Development LP > 2018 Advanced Micro Devices, Inc. > 2019 ExplosionAI GmbH Part of the code in cython-blis comes from src:blis https://github.com/flame/blis And the copyright holders are largely inherited from src:blis > the discussion was done with a single developer - well, looking at > the That single developer is a core contributor of the spaCy stack, and a core member of "2019 ExplosionAI GmbH" IIRC
Bug#985589: unblock: jsonnet/0.17.0+ds-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package jsonnet
[ Reason ]
I missed the lib package in the Depends: field of its -dev package,
resulting in dangling symlinks during anbe's tests. Not yet uploaded.
[ 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 jsonnet/0.17.0+ds-2
--- debdiff ---
diff -Nru jsonnet-0.17.0+ds/debian/changelog jsonnet-
0.17.0+ds/debian/changelog
--- jsonnet-0.17.0+ds/debian/changelog 2020-12-01 11:12:06.0
+0800
+++ jsonnet-0.17.0+ds/debian/changelog 2021-03-20 21:44:30.0
+0800
@@ -1,3 +1,9 @@
+jsonnet (0.17.0+ds-2) UNRELEASED; urgency=medium
+
+ * Fix broken symlinks in libjsonnet-dev due to missing deps (Closes:
#985511)
+
+ -- Mo Zhou Sat, 20 Mar 2021 21:44:30 +0800
+
jsonnet (0.17.0+ds-1) unstable; urgency=medium
* New upstream version 0.17.0+ds
diff -Nru jsonnet-0.17.0+ds/debian/control jsonnet-
0.17.0+ds/debian/control
--- jsonnet-0.17.0+ds/debian/control2020-12-01 11:12:06.0
+0800
+++ jsonnet-0.17.0+ds/debian/control2021-03-20 21:27:53.0
+0800
@@ -64,7 +64,7 @@
Package: libjsonnet-dev
Section: libdevel
Architecture: any
-Depends: ${misc:Depends},
+Depends: ${misc:Depends}, libjsonnet0 (= ${binary:Version})
Description: data templating language (devel)
A data templating language for app and tool developers
.
Bug#985589: unblock: jsonnet/0.17.0+ds-2
Control: tags -1 -moreinfo src:jsonnet (=0.17.0+ds-2) has been uploaded onto unstable, and built on all release architectures. On Sun, 2021-03-21 at 14:31 +0100, Sebastian Ramacher wrote: > Control: tags -1 + confirmed moreinfo > > On 2021-03-20 13:49:44 +, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > > > Please unblock package jsonnet > > > > [ Reason ] > > > > I missed the lib package in the Depends: field of its -dev package, > > resulting in dangling symlinks during anbe's tests. Not yet > > uploaded. > > Looks good. Please remove the moreinfo tag once it's available in > unstable. > > Cheers
Bug#986185: closed by Debian FTP Masters (reply to Mo Zhou ) (Bug#986185: fixed in zfs-linux 2.0.3-3)
Hi,
Thanks for the super awesome feedback!
I indeed forgot to write a README.Debian [1] recording this
change and its usage. Let me prepare a revision and upload shortly.
[1] instead of NEWS, in order to avoid being too abruptive.
On Fri, 2021-04-02 at 12:20 +0200, наб wrote:
> This looks great, thanks! You've definitely taken the right approach
> here.
>
> Just a few nitpicks, see diff:
> * no need to call modprobe, just check sysfs directly
> (this is what modprobe does anyway)
> * the proper name for this is "periodic-{scrub,trim}" ‒
> "periodical" really doesn't work here in modern use
> * get_property() was overly complex ‒
> if the pool doesn't exist, zfs-get already exits with 1,
> so just bubble it up through "|| return 1" to appease -e;
> if the property isn't set, it just returns 0 and prints "-",
> which we already check
> * I also touched the comment up and linked to the zpool userprops
> PR
>
> Also, please add note of this to the NEWS file, something like
> -- >8 --
> Starting with this version, the auto-scrub and auto-trim jobs will
> use
> the "org.debian:periodic-{scrub,trim}" user properties on the
> pool's
> root dataset to determine if they should do anything; accepted
> values
> are:
> * "auto" ‒ same as unset, use default checks
> * "enable" ‒ always scrub/trim automatically
> * "disable" ‒ never scrub/trim automatically
> .
> The default for auto-scrub is to scrub, as before,
> but the default for auto-trim has changed: it will now only trim
> if the pool consists of /only/ NVMe drives, since some SATA 2
> and SATA 3.0 SSDs will hang or crash during large TRIMs (#983086) ‒
> if your pools with SATA SSDs had no problems trimming before,
> you will need to run
> zfs set org.debian:periodic-trim=enable sata-pool
> to restore previous behaviour.
> -- >8 --
> would be great, feel free to just steal this.
>
> Best,
> наб
> diff --git a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
> b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
> index 91631cb18..cb4e3c07e 100755
> --- a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
> +++ b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
> @@ -1,27 +1,19 @@
> #!/bin/sh -eu
>
> # directly exit successfully when zfs module is not loaded
> -if modprobe -n -q --first-time zfs; then
> +if ! [ -d /sys/module/zfs ]; then
> exit 0
> fi
>
> # [auto] / enable / disable
> -PROPERTY_NAME="org.debian:periodical-scrub"
> +PROPERTY_NAME="org.debian:periodic-scrub"
>
> get_property () {
> - # Detect the ${PROPERTY_NAME} property from a given zpool
> - # Note, we are abusing user-defined property on zpool root
> dataset
> - # as "zpool user-defined property".
> + # Detect the ${PROPERTY_NAME} property on a given pool
> + # We are abusing user-defined properties on the root dataset,
> + # since they're not available on pools
> https://github.com/openzfs/zfs/pull/11680
> pool=$1
> - if ! zfs list -H -o name "${pool}" 1>/dev/null 2>/dev/null;
> then
> - return 1 # failed to find the root dataset
> - fi
> - if ! zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
> 1>/dev/null 2>/dev/null; then
> - return 1 # no such property
> - else
> - # has such property
> - zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
> - fi
> + zfs get -H -o value "${PROPERTY_NAME}" "${pool}" 2>/dev/null
> || return 1
> }
>
> scrub_if_not_scrub_in_progress () {
> diff --git a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
> b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
> index 585a58baf..5a0216507 100755
> --- a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
> +++ b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
> @@ -1,27 +1,19 @@
> -#!/bin/sh -e
> +#!/bin/sh -eu
>
> # directly exit successfully when zfs module is not loaded
> -if modprobe -n -q --first-time zfs; then
> +if ! [ -d /sys/module/zfs ]; then
> exit 0
> fi
>
> # [auto] / enable / disable
> -PROPERTY_NAME="org.debian:periodical-trim"
> +PROPERTY_NAME="org.debian:periodic-trim"
>
> get_property () {
> - # Detect the ${PROPERTY_NAME} property from a given zpool
> - # Note, we are abusing user-defined property on zpool root
> dataset
> - # as "zpool user-defined property".
> - pool=$1
> - if ! zfs list -H -o name "${pool}" 1>/dev/null 2>/dev/null;
> then
> - return 1 # failed to find the root dataset
> - fi
> - if ! zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
> 1>/dev/null 2>/dev/null; then
> - return 1 # no such property
> - else
> - # has such property
> - zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
> - fi
> + # Detect the ${PROPERTY_NAME} property on a given pool
> + # We are abusing user-defined properties o
Bug#919561: Please display Debian CI status for contrib/non-free packages on DDPO
Control: close -1 Hi Samuel, Yes, it was fixed. On Sun, 2021-01-03 at 02:16 +0100, Samuel Thibault wrote: > Hello, > > M. Zhou, le jeu. 17 janv. 2019 08:28:24 +, a ecrit: > > For example, ci.d.o keeps running autopkgtest for zfs-linux and > > intel-mkl on Debian testing, but the result is not displayed on my > > DDPO > > page[1]. > > > > https://ci.debian.net/packages/z/zfs-linux/testing/amd64/ > > https://ci.debian.net/packages/i/intel-mkl/testing/amd64/ > > > > [1] https://qa.debian.org/developer.php?login=lumin > > This seems to have been fixed? > > Samuel
Bug#980464: zfs-dracut: dracut+ZFS-on-root systems rendered unbootable
Control: severity -1 important Lowering the severity to unblock the migration, as migration is currently the first priority for us due to the huge diff between 0.8.6 and 2.0.1, given the stable freeze schedule. I will fix it and upload 2.0.1-3 immediately after migration. It is easy to apply for freeze exceptions for such important bugfix that does not involve a big diff. In contrast, exception for the 0.8.6 -> 2.0.1 change is impossible to get approved.
Bug#977578: python3-opencv: Incomplete dependency on libcharls2
Control: tags -1 +moreinfo Hi, I'm confused. On Wed, 2020-12-16 at 19:42 -0800, Dima Kogan wrote: > Hi. I just upgraded my python opencv bindings on Debian/sid: > apt install python3-opencv [...] > I had libcharls2=2.0.0+dfsg-1 (the current stable release). It called [...] > libcharls2 to the current Debian/sid version fixed the problem. A package in sid is built against sid, why is it expected to work with a package in stable? And as described, this problem does not exist when libcharls2/sid is correctly installed. What should I fix?
Bug#928392: fzf: zsh integration doesn't work out of the box
Hi Sean, An official Debian package cannot edit your .zshrc file. A quick instruction for zsh integration can be found here: /usr/share/doc/fzf/README.Debian which is a standard location for notes. And the it is already pointed out in fzf's description. $ apt show fzf Package: fzf Version: 0.18.0-1 Built-Using: golang-1.11 (= 1.11.6-1), golang-github-mattn-go-isatty (= 0.0.4-1), golang-github-mattn-go-runewidth (= 0.0.4-1), golang-github-mattn-go-shellwords (= 1.0.3-1), golang-go.crypto (= 1:0.0~git20181203.505ab14-1), golang-golang-x-sys (= 0.0~git20181228.9a3f9b0-1) Priority: optional Section: utils Maintainer: Mo Zhou Installed-Size: 3,031 kB Depends: libc6 (>= 2.3.2) Homepage: https://github.com/junegunn/fzf Download-Size: 928 kB APT-Manual-Installed: yes APT-Sources: https://mirrors.ustc.edu.cn/debian experimental/main amd64 Packages Description: general-purpose command-line fuzzy finder It's an interactive Unix filter for command-line that can be used with any list; files, command history, processes, hostnames, bookmarks, git commits, etc. . Refer /usr/share/doc/fzf/README.Debian for quick instructions on how to add keybindings for Bash, Zsh, Fish to call fzf. On Fri, 3 May 2019 at 15:00, Sean Haugh wrote: > > Package: fzf > Version: 0.17.5-2+b10 > Severity: normal > > Hello, > > I can't seem to get fzf's zsh integration working. Namely, trying to > fuzzily complete path names does not succeed. Are there additional steps > to take to install the zsh integration? > -- Best,
Bug#896295: Tensorflow is missing
Hi, On Mon, Jan 07, 2019 at 12:24:29AM +0100, Petter Reinholdtsen wrote: > Is TensorFlow different from libtensorflow, already in unstable: experimental > libtensorflow-cc1.10 - Computation using data flow graphs for scalable > machine learning (C++) > libtensorflow-dev - Computation using data flow graphs for scalable machine > learning (dev) > libtensorflow-framework1.10 - Computation using data flow graphs for scalable > machine learning > libtensorflow1.10 - Computation using data flow graphs for scalable machine > learning (C) > > If not, perhaps keras should be adjusted to use it, and its No. Please don't build any package that depends on TF 1.X because it is literally an incomplete WIP. You can do that untill TF 2.X landed onto experimental with a (yet anotehr) totally re-written build system. > package description updated? The tensorflow source package > entered unstable 2018-11-22. experimental > As for the problem with running keras in unstable, perhaps it is a > good idea to extend the autopkgtest script to detect such problems early? Without autopkgtest I'm already aware of bunch of issues existing in the present tensorflow package, which renders it inappropriate to enter even unstable.
Bug#918702: ITP: nvtop -- Interactive NVIDIA GPU process monitor
Hi Maxime, This utility looks cool! If you intend to catch up with Buster freeze and get it into Buster in time, please check the release schedule here: https://release.debian.org/ Don't hesitate to ask me or the debian-mentors list if you encountered any problem. > * Package name: nvtop > Version : 0.3.0 > Upstream Author : Maxime Schmitt > * URL : https://github.com/Syllo/nvtop > * License : GPL, MIT > Programming Lang: C > Description : Interactive NVIDIA GPU process monitor > > Nvtop is a ncurses-based GPU monitoring interface which provides > information on the GPU states (GPU and memory utilization, temperature, > etc) and well as information about the processes executing on the GPUs. > > -- > > This package provides a terminal-based monitoring tool for the GPUs when > the NVIDIA proprietary drivers are installed. It provides a convenient > interactive alternative to nvidia-smi. > > I have personally no Debian packaging experience. I am willing to create > the package and maintain it with some help to kick-start if possible.
Bug#918702: ITP: nvtop -- Interactive NVIDIA GPU process monitor
Hi, I've installed this utility on my workstation and I'm glad to sponsor it. Your packaging looks good except for the section field in d/control: -Section: utils +Section: contrib/utils ^ This is due to copyright issue of Nvidia drier or the CUDA toolkit. Any software that depends on non-free package, even if itself is licensed under some kind of free software license, have to enter the contrib section[1]. And please add the Vcs-Browser and Vcs-Git fields to d/control. Look up [2] for example. I'll sponsor this package when the two mentioned problem get fixed. Thank you for your contribution to Debian! [1] https://www.debian.org/doc/debian-policy/ch-archive.html#the-contrib-archive-area [2] https://codesearch.debian.net/search?q=Vcs-Browser On Fri, Jan 11, 2019 at 02:28:12PM +0100, Maxime Schmitt wrote: > Hi, > > Thanks, are you willing to sponsor this package? > Otherwise, should I open a new bug against the sponsorship-request package > (as explained at https://mentors.debian.net/sponsors/rfs-howto) or send a > mail to the mentor mailing list? > > I've published the source at https://mentors.debian.net/package/nvtop > > On 09/01/2019 06:08, M. Zhou wrote: > > Hi Maxime, > > > > This utility looks cool! > > > > If you intend to catch up with Buster freeze and get it into Buster > > in time, please check the release schedule here: > > > >https://release.debian.org/ > > > > Don't hesitate to ask me or the debian-mentors list if you encountered > > any problem. > > > > > * Package name: nvtop > > >Version : 0.3.0 > > >Upstream Author : Maxime Schmitt > > > * URL : https://github.com/Syllo/nvtop > > > * License : GPL, MIT > > >Programming Lang: C > > >Description : Interactive NVIDIA GPU process monitor > > > > > > Nvtop is a ncurses-based GPU monitoring interface which provides > > > information on the GPU states (GPU and memory utilization, temperature, > > > etc) and well as information about the processes executing on the GPUs. > > > > > > -- > > > > > > This package provides a terminal-based monitoring tool for the GPUs when > > > the NVIDIA proprietary drivers are installed. It provides a convenient > > > interactive alternative to nvidia-smi. > > > > > > I have personally no Debian packaging experience. I am willing to create > > > the package and maintain it with some help to kick-start if possible.
Bug#918702: ITP: nvtop -- Interactive NVIDIA GPU process monitor
Hi Maxime, Thanks! I reviewed the code and performed some sanity tests, and found a new problem (in a clean chroot): | CMake Error at /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message): | Could NOT find Curses (missing: CURSES_LIBRARY CURSES_INCLUDE_PATH) | Call Stack (most recent call first): | /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) | cmake/modules/FindCurses.cmake:245 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) | CMakeLists.txt:46 (find_package) the curses dev package is not present in Build-Depends field. I've added libncurses-dev to depends and started a new build test here: http://debomatic-amd64.debian.net/distribution#unstable/nvtop/1.0.0-1/buildlog Or it's recommended to use ncursesw instead of ncurses? No need to upload to mentors again if adding libncurses-dev looks good to you. And I overlooked something when recommending you to add the Vcs-* fields to the control file. They are supposed to point at the packaging repository (which holds the debian directory and tracks changes within it) instead of the upstream source code repo. For example, https://salsa.debian.org/nvidia-team/nvtop could be a good place for holding the packaging repo, which could be filled in to the Vcs-* fields. Anyone could register an account on Debian's Salsa service. If you are interested in this, please create an account there and I'll grant you necessary write permissions. If you don't want to do it now, or think it's not necessary, please feel free to ignore the Vcs-* stuff. On Fri, Jan 11, 2019 at 03:46:57PM +0100, Maxime Schmitt wrote: > I've pushed the last version, with the two fixes, on > https://mentors.debian.net/package/nvtop > Thank you for your sponsorship. > > Best regards, > Maxime > > On 11/01/2019 14:49, M. Zhou wrote: > > Hi, > > > > I've installed this utility on my workstation and I'm glad to sponsor it. > > Your packaging looks good except for the section field in d/control: > > > > -Section: utils > > +Section: contrib/utils > > > > ^ This is due to copyright issue of Nvidia drier or the CUDA toolkit. > > Any software that depends on non-free package, even if itself is > > licensed under some kind of free software license, have to enter the > > contrib section[1]. > > > > And please add the Vcs-Browser and Vcs-Git fields to d/control. > > Look up [2] for example. > > > > I'll sponsor this package when the two mentioned problem get fixed. > > > > Thank you for your contribution to Debian! > > > > [1] > > https://www.debian.org/doc/debian-policy/ch-archive.html#the-contrib-archive-area > > [2] https://codesearch.debian.net/search?q=Vcs-Browser > > > > > > On Fri, Jan 11, 2019 at 02:28:12PM +0100, Maxime Schmitt wrote: > > > Hi, > > > > > > Thanks, are you willing to sponsor this package? > > > Otherwise, should I open a new bug against the sponsorship-request package > > > (as explained at https://mentors.debian.net/sponsors/rfs-howto) or send a > > > mail to the mentor mailing list? > > > > > > I've published the source at https://mentors.debian.net/package/nvtop > > > > > > On 09/01/2019 06:08, M. Zhou wrote: > > > > Hi Maxime, > > > > > > > > This utility looks cool! > > > > > > > > If you intend to catch up with Buster freeze and get it into Buster > > > > in time, please check the release schedule here: > > > > > > > > https://release.debian.org/ > > > > > > > > Don't hesitate to ask me or the debian-mentors list if you encountered > > > > any problem. > > > > > > > > > * Package name: nvtop > > > > > Version : 0.3.0 > > > > > Upstream Author : Maxime Schmitt > > > > > * URL : https://github.com/Syllo/nvtop > > > > > * License : GPL, MIT > > > > > Programming Lang: C > > > > > Description : Interactive NVIDIA GPU process monitor > > > > > > > > > > Nvtop is a ncurses-based GPU monitoring interface which provides > > > > > information on the GPU states (GPU and memory utilization, > > > > > temperature, > > > > > etc) and well as information about the processes executing on the > > > > > GPUs. > > > > > > > > > > -- > > > > > > > > > > This package provides a terminal-based monitoring tool for the GPUs > > > > > when > > > > > the NVIDIA proprietary drivers are installed. It provides a convenient > > > > > interactive alternative to nvidia-smi. > > > > > > > > > > I have personally no Debian packaging experience. I am willing to > > > > > create > > > > > the package and maintain it with some help to kick-start if possible.
Bug#918702: ITP: nvtop -- Interactive NVIDIA GPU process monitor
Hi, Uploaded. And now you should be able to write in the git repo: https://salsa.debian.org/nvidia-team/nvtop As for packaging repository, I'd personally recommend you the git-buildpackage workflow, which is also a recommended practice for Debian Science team: https://science-team.pages.debian.net/policy/#idm297 If you found something else to make you more comfortable, just go ahead. On Fri, Jan 11, 2019 at 04:42:44PM +0100, Maxime Schmitt wrote: > Yes sorry, I did not test in a clean chroot. libncurses-dev should be enough > as it pulls libncursesw as a dependency (needed for the drawing plot > characters and degree sign). > > Vcs-* : Ok, it also seemed weird because there was already the Homepage > field. I've created an account as @mschmitt-guest > I will look at other repositories in salsa and docs to see what to put in > this repository. > > On 11/01/2019 16:11, M. Zhou wrote: > > Hi Maxime, > > > > Thanks! I reviewed the code and performed some sanity tests, and > > found a new problem (in a clean chroot): > > > > | CMake Error at > > /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 > > (message): > > | Could NOT find Curses (missing: CURSES_LIBRARY CURSES_INCLUDE_PATH) > > | Call Stack (most recent call first): > > | /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 > > (_FPHSA_FAILURE_MESSAGE) > > | cmake/modules/FindCurses.cmake:245 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > > | CMakeLists.txt:46 (find_package) > > > > the curses dev package is not present in Build-Depends field. > > I've added libncurses-dev to depends and started a new build test here: > > http://debomatic-amd64.debian.net/distribution#unstable/nvtop/1.0.0-1/buildlog > > > > Or it's recommended to use ncursesw instead of ncurses? No need to > > upload to mentors again if adding libncurses-dev looks good to you. > > > > > > And I overlooked something when recommending you to add the Vcs-* fields > > to the control file. They are supposed to point at the packaging > > repository (which holds the debian directory and tracks changes within > > it) instead of the upstream source code repo. > > > > For example, https://salsa.debian.org/nvidia-team/nvtop could be a good > > place for holding the packaging repo, which could be filled in to the > > Vcs-* fields. Anyone could register an account on Debian's Salsa > > service. If you are interested in this, please create an account there > > and I'll grant you necessary write permissions. If you don't want to > > do it now, or think it's not necessary, please feel free to ignore > > the Vcs-* stuff. > > > > > > On Fri, Jan 11, 2019 at 03:46:57PM +0100, Maxime Schmitt wrote: > > > I've pushed the last version, with the two fixes, on > > > https://mentors.debian.net/package/nvtop > > > Thank you for your sponsorship. > > > > > > Best regards, > > > Maxime > > > > > > On 11/01/2019 14:49, M. Zhou wrote: > > > > Hi, > > > > > > > > I've installed this utility on my workstation and I'm glad to sponsor > > > > it. > > > > Your packaging looks good except for the section field in d/control: > > > > > > > > -Section: utils > > > > +Section: contrib/utils > > > > > > > > ^ This is due to copyright issue of Nvidia drier or the CUDA toolkit. > > > > Any software that depends on non-free package, even if itself is > > > > licensed under some kind of free software license, have to enter the > > > > contrib section[1]. > > > > > > > > And please add the Vcs-Browser and Vcs-Git fields to d/control. > > > > Look up [2] for example. > > > > > > > > I'll sponsor this package when the two mentioned problem get fixed. > > > > > > > > Thank you for your contribution to Debian! > > > > > > > > [1] > > > > https://www.debian.org/doc/debian-policy/ch-archive.html#the-contrib-archive-area > > > > [2] https://codesearch.debian.net/search?q=Vcs-Browser > > > > > > > > > > > > On Fri, Jan 11, 2019 at 02:28:12PM +0100, Maxime Schmitt wrote: > > > > > Hi, > > > > > > > > > > Thanks, are you willing to sponsor this package? > > > > > Otherwise, should I open a new bug against the sponsorship-request > > > > > package > > > > > (as explained at https:
