Bug#1055543: ITP: diff-pdf-wx -- Simple tool for visually comparing two PDF files.
Package: wnpp Severity: wishlist Owner: Shengqi Chen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: diff-pdf-wx Version : 0.5.1 Upstream Contact: Vaclav Slavik * URL : http://vslavik.github.io/diff-pdf * License : GPL-2 mostly with some LGPL-2.1+ files Programming Lang: C++ Description : Simple tool for visually comparing two PDF files. diff-pdf is a tool for visually comparing two PDFs. It takes two PDF files as arguments, and generates an output PDF file that highlights the differences between the two input files. Besides, it can compare the two files visually in a simple GUI. The original package name (and the executable name) is diff-pdf. However there is an existing package called diffpdf, so I rename it to diff-pdf-wx (for using wxwidgets) to avoid confusion. Compare to diffpdf: Both two tools can compare PDF files in a visual way. However this tool is more lightweight (by not depending on Qt) and can generate the diff result in PDF format. Thus it is widely adopted in academia to generate revised versions of submitted manuscripts. Many conferences / journals recommend this tool in their revision process. Also many LaTeX template authors use it to compare LaTeX-rendered PDFs to original Word version. Currently Fedora / CentOS has officially packed this tool. I plan to upload it to Debian and maintain this package as my first-time contribution. My current work is at [1]. A DD as sponsor would be greatly appreciated. [1]: https://salsa.debian.org/harry/diff-pdf-wx
Bug#1063457: zfsutils-linux abuses Conflicts in violation of policy 10.1
Hi, > zfsutils-linux declares Conflicts with nordugrid-arc-client, because > both provide /usr/bin/arcstat. This conflict is in violation of Debian > policy 10.1: > > | Two different packages must not install programs with different > | functionality but with the same filenames. > > The name arcstat is currently owned by nordugrid-arc-client and cannot > be taken over by zfsutils-linux simply by declaring a conflict. > We are aware of this. arcstat is NOT a new binary added in recent versions, but is installed into /usr/sbin for several years and versions. I moved it to /usr/bin because it does not actually require specific permission to use. Is there any suggestion on such situation? Keeping ours in sbin would cause (the long-existing) confusion to user if they install both packages and find that two different arcstat exist in bin and sbin. Renaming either one would also make trouble. Thanks, Shengqi Chen
Bug#1042730: Follow-up on zfs-linux in bookworm-pu
Hi, > Please cherry-pick a fix for this and propose a new debdiff; the upstream > release contains too much else to be accepted. The current version 2.1.11 of zfs-linux in bookworm suffers from CVE-2023-49298, which leads to potential data loss. I believe Aron’s latest proposed patch contains some useful stability fixes including this one. Would there be any follow-up on this bug? Or do we need to further narrow down the patch for it to be accepted? Thanks, Shengqi Chen
Bug#1063497: Update on bug 1063497
Control: fixed -1 2.1.14-1 Control: reassign -1 src:zfs-linux Control: block -1 by 1042730 We are trying to include the fix in bookworm. Meanwhile you can use bookworm-backports for a fixed version. Thanks, Shengqi Chen
Bug#1063457: nordugrid-arc and arcstat
Hi, > 2024年2月12日 16:13，Mattias Ellert 写道： > > NorduGrid ARC has used the name arcstat since release 1.0. It has been > in Debian since January 2010 (source package nordugrid-arc-nox, later > renamed nordugrid-arc in May 2011). Thanks for your background. > > The command is part of a set of commands, all using the arc prefix: > arccat arcget arckillarcproxy arcresume arcsync > arcclean arcls arcrename arcrm arctest > arccp arched arcmkdir arcrenew arcstat > arcctl arcinfoarcplugin arcresub arcsub > > Mattias Ellert > As a (tentative) solution, we discussed and decided to move arcstat back to sbin on the zfs-linux side. That would leave the current situation untouched until maintainers from both sides form a consensus on how to handle this. We will keep working on this and try to ask for more advice from both users and developers. Thanks, Shengqi Chen
Bug#1059939: Merge bug 1059939 with 981212
Control: unblock -1 by 981212 Control: merge -1 981212 Control: tag 981212 + upstream
Bug#1052472: Update bug #1052472
Control: tag -1 + upstream Control: forwarded -1 https://github.com/openzfs/zfs/pull/15344/ Let's hope this would get in an official upstream release soon. Thanks, Shengqi Chen
Bug#983782: Update bug 983782
Control: forwarded -1 https://github.com/openzfs/zfs/issues/11587 Control: tags -1 + upstream Seems it is caused by the same race condition. Thanks, Shengqi Chen
Bug#1014197: Close bug 1014197
Control: notfound -1 2.1.5-1 Feel free to re-open if there are still problems. Thanks, Shengqi Chen
Bug#1023127: Update bug 1023127
Control: tag -1 + wontfix
The package is intended for normal users, for whom installing both dracut
and initramfs-tools seems really rare and weird. Also your patch will even
render
the system not usable because now initramfs no more updates when zfs upgrades.
> Conversely, imagining (and being in) such a situation is very easy to me.
> This is the reason why they are made co-installable, and only the "bare"
> dracut/initramfs-tools packages aren't.
It is possible to further split packages into, e.g., zfs-{initramfs,dracut}-core
that depends on their corresponding underlying -core packages, and make
zfs-{initramfs,dracut} depend on them. However I haven't heard similar
use cases from any other users.
Thanks,
Shengqi Chen
Bug#900656: Update bug 900656
Hi, > How about depending the dkms on kernel versions known to work with it? We can add dependency on linux-libc-dev (which always has the same version as kernel). This prevents: 1. kernel upgrade to versions that zfs does not **explicitly** say it supports in META, even it **might** actually build and work. 2. any user-compiled kernels. Users can create a fake package if needed. > Furthermore, zfs-dkms should require on the same version of spl-dkms to ensure interoperability (rather than specifying a range). Now spl has been merged into zfs-dkms. This is not a problem any more. Thanks, Shengqi Chen
Bug#1025046: Update bug 1025046
Control: fixed -1 2.1.7-1 You may also refer to #900656. Thanks, Shengqi Chen
Bug#926213: Closing bug 926213
Control: tags -1 + upstream Closing this bug as too many days & versions have been passed. There are multiple reports related to l2arc_feed stuck [1][2][3]. But none seems the same. We have to admit that many similar issues exist in zfs. :-( [1]: https://github.com/openzfs/zfs/issues/13435 [2]: https://github.com/openzfs/zfs/issues/14005 [3]: https://github.com/openzfs/zfs/issues/12679 Thanks, Shengqi Chen
Bug#1041857: Update bug 1041857
Control: tag -1 + upstream Control: forwarded -1 https://github.com/openzfs/zfs/issues/11587 Thanks Shengqi Chen
Bug#1012305: Close bug 1012305
Control: tags -1 + unreproducible Closing legacy bugs. Thanks, Shengqi Chen
Bug#1051187: [Pkg-zfsonlinux-devel] Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed
Control: severity -1 wishlist Control: tag -1 + wontfix > zfs-dkms is the failsafe in case the zfs-modules- package is > *not* installed > (for example, because this is the first slow box I'm installing this kernel > or this version of > zfs-dkms on and I don't yet have a corresponding zfs-modules package). Let's imagine you install modules pkg first, then dkms pkg, which skips building because you have "same" modules installed. After some days you accidentally uninstalled the modules pkg, then how would the dkms pkg know and start the building? There is no such mechanism according to my knowledge. Even though such mechanism can be implemented by dkms, let's dig deeper into details: how would dkms know that your prebuilt version and dkms source files are "the exact same" and decide to skip? Designing such a mechanism would be either cumbersome for developers, or confusing for users, I suppose. Thanks, Shengqi Chen
Bug#991373: Close bug 991373
Control: notfound -1 2.0.3-1~bpo10+1 Control: tag -1 + unreproducible Thanks, Shengqi Chen
Bug#859825: Closing bug 859825
Control: tags -1 + upstream fixed Control: forwarded -1 https://github.com/openzfs/zfs/issues/11278 Control: fixed 2.1.1-1 Thanks, Shengqi Chen
Bug#1028613: libpam-zfs: zfs_umount failed on closing ssh session
Control: forwarded -1 https://github.com/openzfs/zfs/issues/12430 Control: tags -1 + upstream Hi Andreas, aron and I did some investigation. The -1 reported by zfs_umount is actually -EPERM. This has been discussed by upstream issue #12430. You may want to try (as workaround): 1. skip pam_zfs_key when pam_systemd is used, as #12430 suggests; or, 2. use `zfs allow` to grant `mount` permission to yourself. Thanks, Shengqi Chen
Bug#941311: Closing bug 941311
Control: tags -1 + wontfix upstream Control: forwarded -1 https://github.com/zfsonlinux/zfs/issues/9367 This is indeed a problem, but only happens once (when upgrade crosses the version 0.8.2). Since these versions were released more than four years ago, it is safe to close the bug now. Thanks, Shengqi Chen
Bug#1027085: Still hapening on 5.10.0-26-amd64
Control: tags -1 + unreproducible > Still hapening on 5.10.0-26-amd64 , but this fixed the system: > update-initramfs -u ; update-grub Did your apt run finish normally? The update of initramfs and grub is commonly done by postinst hooks, which will be triggered when kernel / zfs is upgraded. So if running manually can solve the problem, I suspect some faulty packages might be preventing this process. Thanks, Shengqi Chen
Bug#1059939: [Pkg-zfsonlinux-devel] Processed: reassign 1059939 to zfs-dkms
Control: block 1059939 by 981212 The build of zfs modules on RT kernels is intentionally disabled due to #981212, further caused by upstream issue #11097. > 2024年1月4日 07:39，Debian Bug Tracking System 写道： > > Processing commands for cont...@bugs.debian.org: > >> reassign 1059939 zfs-dkms > Bug #1059939 [dkms] linux-image-6.1.0-17-rt-amd64: dkms will not build zfs > module for rt-amd64 > Bug reassigned from package 'dkms' to 'zfs-dkms'. > Ignoring request to alter found versions of bug #1059939 to the same values > previously set > Ignoring request to alter fixed versions of bug #1059939 to the same values > previously set >> thanks > Stopping processing here. > > Please contact me if you need assistance. > -- > 1059939: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059939 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > ___ > 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#1057018: zfs-dkms: VERIFY3 failed; PANIC at range_tree.c:435; cause all operations to hang until hard reboot
Control: forwarded https://github.com/openzfs/zfs/issues/11893 Control: forwarded https://github.com/openzfs/zfs/pull/14843 Control: fixed 2.2.2-1 aron is actually trying to backport the data corruption bug fix to 2.1.11 (see [1]). After that, we might be able to pull in more bug fixes in the next point release. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042730 Thanks, Shengqi Chen
Bug#1060259: [Pkg-zfsonlinux-devel] Bug#1060259: zfs-dkms: Fails to build after upgrade to linux-image-6.1.0-17-amd64
Control: tags -1 + unreproducible Control: severity -1 normal Hi, > Building DKMS modules for zfs started to fail after upgrading to the latest > (6.1.0-17) kernel available for > Bookworm preventing successful configuration of following packages: > > linux-image-6.1.0-17-amd64 > linux-headers-6.1.0-17-amd64 I tried to install zfs-dkms 2.11-1 on 6.1.0-17-amd64 and no errors were found. I wander whether the source in dkms was somehow altered, and a reinstall may solve the problem. And installing a new version from bpo is, of course, a way of reinstallation. Thanks, Shengqi Chen
Bug#1060460: [Pkg-zfsonlinux-devel] Bug#1060460: reportbug: adduser prompts for current password when adding user, impossible to change passphrase
Control: tags -1 + upstream Hi, Thanks for reporting. > 2024年1月12日 03:44，наб 写道： > > Package: libpam-zfs > Version: 2.2.2-3 > Severity: normal > > Dear Maintainer, > > Given > # adduser testuser > info: Adding user `testuser' ... > info: Selecting UID/GID from range 1000 to 5 ... > info: Adding new group `testuser' (1001) ... > info: Adding new user `testuser' (1001) with group `testuser (1001)' ... > info: Creating home directory `/home/testuser' ... > info: Copying files from `/etc/skel' ... > Current password: I can reproduce all these with `adduser`. But everything works when I use `useradd` and `passwd` (both with root, of course). I suspect there are some differences between how `adduser` and `useradd` use PAM modules. I personally have no experience in debugging PAM, and this seems a upstream bug (?). Maybe you could also report this to upstream? Thanks, Shengqi Chen
Bug#1040183: [Pkg-zfsonlinux-devel] Bug#1040183: zfs-initramfs: snapshots for rootfs mounted in /root/.zfs/snapshot
Control: fixed -1 2.1.12-1 Control: forwarded -1 https://github.com/openzfs/zfs/pull/14908 Hi, > 2024年1月12日 04:25，наб 写道： > > Control: found -1 2.2.2-3 > > The upstream issue referenced in the OP is still open, and you can still > repro this error on 2.2.2-3 and 6.6.9-amd64: Thanks for testing. The fix actually got merged into 2.2.12 and master, but not released with 2.2.0 till now. We will keep tracking it, and (probably) backport the patch in the next debian release. Thanks, Shengqi Chen
Bug#1040183: [Pkg-zfsonlinux-devel] Bug#1040183: zfs-initramfs: snapshots for rootfs mounted in /root/.zfs/snapshot
Control: notfound -1 2.2.2-3 Hi, > Thanks for testing. The fix actually got merged into 2.2.12 and master, > but not released with 2.2.0 till now. We will keep tracking it, and (probably) > backport the patch in the next debian release. > Sorry for the confusion. The fixes has landed in 2.1.12 and remains in all later versions. I tested on my 2.2.2-3 and cannot reproduce your problem. > nabijaczleweli@chrust:~/code/babfig/i3status.rs$ findmnt > TARGET SOURCE > FSTYPE OPTIONS > / chrust-zootzfs > rw,relatime,xattr,posixacl,casesensitive > ├─/home chrust-zoot/home zfs > rw,relatime,xattr,posixacl,casesensitive > │ └─/home/nabijaczlewelichrust-zoot/home/nabijaczlewelizfs > rw,relatime,xattr,posixacl,casesensitive > └─/.zfs/snapshot/pre-keymap chrust-zoot/home/nabijaczleweli@pre-keymap zfs > ro,relatime,xattr,posixacl,casesensitive Seems .zfs/ of you home dataset goes wrongly to /.zfs, which is really weird, since they are mounted in the different stage of booting sequence. I don’t think it is the same problem as this report. You might want to create a new report (and to upstream). Thanks, Shengqi Chen
Bug#1060461: [Pkg-zfsonlinux-devel] Bug#1060461: libpam-zfs: fails to unload and unmount homedir on exit from graphical session
Hi, Thanks for reporting. > 2024年1月12日 04:06，наб 写道： > > Package: libpam-zfs > Version: 2.2.2-3 > Severity: normal > > Dear Maintainer, > > After logging out (as testuser), /home/testuser was still mounted. > Before logging in, it was unloaded and unmounted. > > Journal says > Jan 11 20:59:41 chrust systemd[1]: Started session-33.scope - Session 33 of > User testuser. > Jan 11 20:59:55 chrust lightdm[13290]: pam_unix(lightdm:session): session > closed for user testuser > Jan 11 20:59:55 chrust lightdm[13290]: pam_zfs_key(lightdm:session): > zfs_unmount failed with: -1 > Jan 11 21:00:01 chrust lightdm[13484]: pam_zfs_key(lightdm:auth): pbkdf > failed > Jan 11 21:00:12 chrust (sd-pam)[13299]: pam_unix(systemd-user:session): > session closed for user testuser > -1 is EPERM. So I suspect this is the same problem as #1028613. Maybe you can check that out and, if indeed, merge the two bugs? Thanks, Shengqi Chen
Bug#1060259: [Pkg-zfsonlinux-devel] Bug#1060259: zfs-dkms: Fails to build after upgrade to linux-image-6.1.0-17-amd64
Control: notfound -1 2.1.11-1 Hi, > 2024年1月9日 19:21，Juhamatti Niemelä 写道： > > Hi, > > I downgraded zfsutils-linux, zfs-dksm and their zfs related dependencies to > 2.1.11-1 versions ie. back to stable and the problem didn't reproduce anymore. > > So it probably was something fixed by the reinstallation like you said. Sorry > for the inconvenience. > That’s great to know. Thanks for sharing! > Do you believe dpkg --verify zfs-dkms would have catched it if I would have > been able to run it in time? > If the problem is indeed caused by corruption of source files, running dpkg --verify would surely help. Thanks, Shengqi Chen
Bug#1057018: Processed (with 3 errors): Re: zfs-dkms: VERIFY3 failed; PANIC at range_tree.c:435; cause all operations to hang until hard reboot
Control: forwarded -1 https://github.com/openzfs/zfs/issues/11893 Control: forwarded -1 https://github.com/openzfs/zfs/pull/14843 Control: fixed -1 2.2.2-1 Sorry for the typos in my previous mail. Shengqi Chen > 2024年1月4日 12:39，Debian Bug Tracking System 写道： > > Processing control commands: > >> forwarded https://github.com/openzfs/zfs/issues/11893 > Unknown command or malformed arguments to command. > >> forwarded https://github.com/openzfs/zfs/pull/14843 > Unknown command or malformed arguments to command. > >> fixed 2.2.2-1 > Unknown command or malformed arguments to command. > > > -- > 1057018: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057018 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#867299: Closing bug 867299
Control: tags -1 + upstream fixed Control: fixed -1 0.7.3-1 Thanks, Shengqi Chen
Bug#1040183: Update bug #1040183
Control: forwarded -1 https://github.com/openzfs/zfs/pull/14920 Control: tags -1 + upstream fixed Control: fixed -1 2.1.12-1 Thanks Shengqi Chen
Bug#972132: Closing bug 972132
Control: notfound -1 0.8.4-2~bpo10+1 Control: severity -1 normal Closing due to not a bug. Thanks, Shengqi Chen
Bug#979434: Closing bug #979434
Control: notfound -1 zfs-linux/2.0.3-1 Control: tags -1 = fixed > During install the package tries to start nfs-share.service, which fails > in case the zfs module is not loaded, for whatever reason[1]. Now it will not be started. > Job for zfs-load-module.service failed because the control process exited > with error code. The errors now reported by systemd are expected when no zfs.ko could be found. Just disable / mask the services / targets if you do not (and *intended* not to) have zfs modules installed. Thanks, Shengqi Chen
Bug#1034022: Closing bug 1034022
Control: severity -1 normal Control: notfound -1 2.1.9-1~bpo11+1 Closing due to not a bug. Thanks, Shengqi Chen
Bug#1003528: Closing bug 1003528
Control: tags -1 + wontfix
Hi Louis,
> Should Debian edit /lib/systemd/system/zfs-import.target to include this?
Adding dependency would solve your problem, but it forcibly serialize two
parallel-able tasks.
> I worked around the problem by making sure the zfs-import.target (used by
> zfs-import-{cache,scan}.service) is active before mounts are attempted.
According to systemd.mount [1], you can just write something like:
tank /mnt zfs defaults,x-systemd.requires=zfs-load-modules.service 0 0
I’m closing this report since it is not a bug indeed.
[1]: https://www.freedesktop.org/software/systemd/man/latest/systemd.mount.html
Thanks,
Shengqi Chen
Bug#1057029: ITP: goauthing -- CLI authentication utility for srun4000 systems
Hi, > 2023年11月28日 16:38，陈 晟祺 写道： > > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org > Owner: Shengqi Chen > > * Package name: goauthing > Version : 2.2.1-1 > Upstream Author : Yuxiang Zhang > * URL : https://github.com/z4yx/GoAuthing > * License : GPL-3.0 > Programming Lang: Go > Description : CLI authentication utility for srun4000 systems > > GoAuthing is an authentication utility for srun4000 systems written in Go. > Such systems are widely adopted in universities in China, > e.g., Tsinghua University, thus render the utility useful. > > GoAuthing has been packaged in AUR. I plan to add it in Debian distros. > I have done my initial packaging at [1]. Any advice would be appreciated. I have not uploaded it to mentor site since I am not member of go packing team yet. I would like to request access to the go-team group to put this project in (and potentially more packages). [1]: https://salsa.debian.org/harry/goauthing Cheers, -- Shengqi Chen
Bug#1057043: RFS: goauthing/2.2.1-1 [ITP] -- CLI authentication utility for srun4000 systems
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "goauthing": * Package name : goauthing Version : 2.2.1-1 Upstream contact : Yuxiang Zhang * URL : https://github.com/z4yx/GoAuthing * License : GPL-3.0 * Vcs : https://salsa.debian.org/go-team/packages/goauthing Section : golang The source builds the following binary packages: goauthing - CLI authentication utility for srun4000 systems To access further information about this package, please visit the following URL: https://mentors.debian.net/package/goauthing/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/goauthing/goauthing_2.2.1-1.dsc Changes for the initial release: goauthing (2.2.1-1) UNRELEASED; urgency=medium . * Initial release (Closes: #1057029) Regards, -- Shengqi Chen
Bug#1057029: ITP: goauthing -- CLI authentication utility for srun4000 systems
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org Owner: Shengqi Chen * Package name: goauthing Version : 2.2.1-1 Upstream Author : Yuxiang Zhang * URL : https://github.com/z4yx/GoAuthing * License : GPL-3.0 Programming Lang: Go Description : CLI authentication utility for srun4000 systems GoAuthing is an authentication utility for srun4000 systems written in Go. Such systems are widely adopted in universities in China, e.g., Tsinghua University, thus render the utility useful. GoAuthing has been packaged in AUR. I plan to add it in Debian distros. Cheers, -- Shengqi Chen
Bug#1055556: RFS: diff-pdf-wx/0.5.1-1 [ITP] -- Simple tool for visually comparing two PDF files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "diff-pdf-wx": * Package name : diff-pdf-wx Version : 0.5.1-1 Upstream contact : vac...@slavik.io * URL : https://vslavik.github.io/diff-pdf/ * License : GPL-2, LGPL-2.1+ * Vcs : https://salsa.debian.org/harry/diff-pdf-wx Section : utils The source builds the following binary packages: diff-pdf-wx - Simple tool for visually comparing two PDF files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/diff-pdf-wx/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/diff-pdf-wx/diff-pdf-wx_0.5.1-1.dsc Changes for the initial release: diff-pdf-wx (0.5.1-1) unstable; urgency=medium . * Initial packging for upstream version 0.5.1 (closes: #1055543). You may also find my git repo at: https://salsa.debian.org/harry/diff-pdf-wx Regards, -- Shengqi Chen
Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi Paul, 2024年4月11日 20:59，Paul Gevers 写道： Hi, With the default size of the ramdisk and 2 cpu's the test crashes with: Test: /usr/share/zfs/zfs-tests/tests/functional/large_files/setup (run as root) [00:00] [PASS] Test: /usr/share/zfs/zfs-tests/tests/functional/large_files/large_files_001_pos (run as root) [00:00] [PASS] Test: /usr/share/zfs/zfs-tests/tests/functional/large_files/large_files_002_pos (run as root) [00:00] [PASS] Test: /usr/share/zfs/zfs-tests/tests/functional/large_files/cleanup (run as root) [00:00] [PASS] Killed Killed Killed qemu-system-x86_64: terminating on signal 15 from pid 132251 (/usr/bin/python3) autopkgtest [12:28:46]: ERROR: testbed failure: timed out on command "cat /run/autopkgtest-reboot-mark" (kind: short) root@ci-worker13:~# That at least hints that those tests *might* be generating a bit too large files to be handled in this case. Maybe worth making these tests conditional on free space if they aren't already. Thanks for your detailed diagnosis. I adjusted a test option to limit the maximum file size [1]. Also I fixed numerous test errors caused by missing dependencies [2]. Yet I am concerned that some tests might fail, in turn, due to insufficient disk space. If so I will have to ignore some tests on either side. If possible, could you help to build with latest code on salsa then run autopkgtest again on a normal debci VM? I am also testing that locally. [1]: https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/f6bea9224c4bf734ac381bac36a995dfd33b2078 [2]: https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/177d5b2eab39cf8ca0e7bb66d462b4886f2372e4 Thanks, Shengqi Chen
Bug#1056785: Bug #1056785: RM mpdecimal
Hi, From a user’s perspective, mpdecimal is a really neat FP library to use. I would support it to be remain in the archive and gets updated (4.0.0). If needed, I can help with maintaining the package afterwards. Thanks, Shengqi Chen
Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, > 2024年4月12日 02:39，Paul Gevers 写道： > > Hi > > On 11-04-2024 5:18 p.m., 陈 晟祺 wrote: >> If possible, could you help to build with latest code on salsa then run >> autopkgtest again on a normal debci VM? > > As I'm doing this live on the infrastructure, I don't want to do anything > there except testing what's in the archive, sorry. > Sure, this is reasonable. > My private setup (laptop) is not powerful enough to run this. > > I'm not 100% percent sure how to instruct you to build a ci.d.n like image. I > think it's: > $ autopkgtest-build-qemu debian testing > $ /usr/bin/autopkgtest --no-built-binaries --test-name=zfs-test-suite --user > debci zfs-linux -- qemu > except I don't know where autopkgtest-build-qemu stores the image. > I am indeed using debci images to ensure reproducibility. So the software environment should be the same. Just more observations here: - If I limit the test file size to 1G, quite many tests would fail even with adequate resources. - If I try to skip large_files as you indicated with 2G memory, the tests could proceed for a bit longer, but still got hang on some later tests. Since there are so many tests and I am not familiar with most of them, I have to try it repeatedly to find out which to filter out. Even I could do so, some (other, not seen before) tests would fail unexpectedly. These problems might be hard to workaround. - With my fixes to dependencies, the tests could run to the ending without errors on 2 core + 8 GB. Therefore I think trying to fit zfs-tests into a normal debci VM might be troublesome. -- Thanks, Shengqi Chen
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Control: tags -1 + pending Hi, > 2024年4月13日 01:29，陈 晟祺 写道： > > I am now trying to run tests on 2 core and 4GB memory (and maybe less later). > If the tester itself does not occupy too much RAM, the real requirement for > resources > is now probably several gigabytes of disk space (currently it’s ~10GB). > > I will give more feedback once new results come out. > When using non-ramdisk tmpdir (/var/tmp) and some large tests skipped [1], the tests would run with 2 core + 4GB memory + ~10GB disk space. I also tried 2GB / 3GB, and both will be interrupted by OOM killer. I would have aron to review & upload a new version, then we can test on debci infra and see whether it solves the problem. [1]: https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/cf8e8afe69a0a8f21768415a08b131f8aa9fdc6a Thanks, -- Shengqi Chen
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, > 2024年4月12日 12:48，Paul Gevers 写道： > > Hi, > > On 12-04-2024 4:42 a.m., 陈 晟祺 wrote: >> - If I limit the test file size to 1G, quite many tests would fail even with >> adequate resources > > Ack. To be fair, I was more thinking to make current test conditional on the > available free disk space. But yeah, that might also lead to issues as the > test might be randomly skipped. > You got the point. I previously thought that testifies are on disk, but actually they are in tmpfs and consuming huge memory. That’s why OOM killer would kick in when writing large files in tests. > Good, so 2GB memory is not enough for zfs-linux (I assume you ran this test > with 2 cores like I did) Yes, I always use 2 cores. > > I agree we shouldn't spend too much time on squeezing it into the *current* > defaults. I'm still somewhat hoping that we could squeeze out a somewhat > smaller memory defaults than 8 GB: does 4 GB work (and if so, how long does > it take)? > I am now trying to run tests on 2 core and 4GB memory (and maybe less later). If the tester itself does not occupy too much RAM, the real requirement for resources is now probably several gigabytes of disk space (currently it’s ~10GB). I will give more feedback once new results come out. Thanks, -- Shengqi Chen
Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, Some additional information and errata here. I have split the tests into four stanzas as upstream does [1]. The resources of one GitHub Action runner is actually 4 cores + 16GB memory, not 2 cores + 8GB as I mentioned before. The test could finish within reasonable time (3hrs) with such configuration (although with a few unexpected failures, but I think it could be solved). I am still trying with fewer resources, especially shrinking the memory. [1]: https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/7afeda495fa5b8129dfac45aef6340f46fbaf3a6 -- Thanks, Shengqi Chen.
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, > 2024年4月7日 17:23，Paul Gevers 写道： > > Dear maintainer(s), > > Your package has an autopkgtest, great. I recently added support for > isolation-machine tests on ci.debian.net for amd64 and added your package to > the list to use that. However, it fails because the zfs-test-suite test times > out after 2:47h (it seems to hang by the looks of the log). Can you please > investigate the situation and fix it? I copied some of the output at the > bottom of this report. > Thanks for your work! I have long waited for the isolation-machine tag to be available. > The release team has announced [1] that failing autopkgtest on amd64 and > arm64 are considered RC in testing, but because machine-isolation support by > ci.debian.net is new I have not marked this bug as serious (yet). > > Because the test doesn't fail, but tmpfails (might be a bug in autopkgtest), > I've reverted the preferred backend for zfs-linux back to lxc until this bug > is closed. > I am not yet able to reproduce the hang on my local testing environment. Could you please provide more detailed information on the test settings on ci.d.o.? E.g., CPU type, #cores, memory size, etc. Thanks, Shengqi Chen
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi Paul, > 2024年4月7日 21:10，Paul Gevers 写道： > > Hi, > > The host that runs this is an m3-large instance at equinix [1]. > > We create the qemu image with autopkgtest-build-qemu (default settings as far > as I know). > > From within the testbed: > root@host:~# lscpu > lscpu > Architecture:x86_64 > CPU op-mode(s):32-bit, 64-bit > Address sizes: 48 bits physical, 48 bits virtual > Byte Order:Little Endian > CPU(s): 1 > On-line CPU(s) list: 0 > Vendor ID: AuthenticAMD > BIOS Vendor ID:QEMU > Model name:AMD EPYC 7502P 32-Core Processor >BIOS Model name: pc-i440fx-7.2 CPU @ 2.0GHz >BIOS CPU family: 1 >CPU family: 23 >Model: 49 >Thread(s) per core: 1 >Core(s) per socket: 1 >Socket(s): 1 > > root@host:~# lsmem > lsmem > RANGE SIZE STATE REMOVABLE BLOCK > 0x-0x7fff 2G online yes 0-15 > > Memory block size: 128M > Total online memory: 2G > Total offline memory: 0B > With resources limited to one CPU (AMD EPYC 7551) and 2G memory, my local test could now reproduce the test hang and following time out error. I think it is caused by insufficient resources (e.g. OOM killer, but I am not sure). Even we can work it around, the test process would be still be too slow to finish. Is it possible to allocate more resources for the test? For reference, openzfs uses GitHub-hosted workflow runners [1] for test. Each runner has 2 CPU cores and 7 GB memory, under which configuration the whole test still takes ~4hrs. If not, is there any way to mark the test as optional (thus not causing RC bug)? Otherwise our worst choice would be disable the test completely. [1]: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-private-repositories [2]: https://github.com/openzfs/zfs/blob/master/.github/workflows/scripts/setup-functional.sh Thanks, Shengqi Chen
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, > 2024年4月9日 02:51，Paul Gevers 写道： > > Our timeout is 1 seconds, so 2.47 hours, per autopkgtest stanza (overall > it's 8 hours). If the test is going to take longer, it will fail anyways. So > maybe it was just still running? I'm a bit hesitant, particularly about the > memory to make much bigger VM's, because most tests don't need it and it > limits the amount of VM's we can make. We need to strike a nice balance (or > fix https://salsa.debian.org/ci-team/debci/-/issues/166#note_451831 and add > zfs-linux to a "huge" list) > I totally understand your consideration. I think it would be great if we could specify more detailed resource requirements on test metadata (thus not wasting resources on small tests). > > Well, if we can't run the test on our infra, we could disable it, but what's > the point of having the autopkgtest then? (If you split the tests over > multiple stanza, you get the 2.47 hour per set. Does that help?) > It might help. For upstream test on GitHub Actions, it is actually split into four parts [1], each taking ~1hr. I can (and plan to) integrate that into debt tests. > Let me try to see if I can have debci create larger VM's for us and let me > try your package again. What are the resources you use yourself for the test > and how long does it take in that case? > My testing resources are maybe not that representative (20 cores + 32GB memory), it takes about the same time (3hr40min) as upstream configuration (4 cores + 7GB). I will try with fewer resources recently and give you more information. [1]: https://github.com/openzfs/zfs/blob/master/.github/workflows/scripts/setup-functional.sh -- Thanks, Shengqi Chen
Bug#1001802: Update on bug 1001802
control: forwarded -1 https://github.com/openzfs/openzfs-docs/issues/237 control: notfound -1 2.0.3-9 > - while the script indeed waits for user input, snapshots list and prompt are not displayed to the user Please disable "quiet" in your kernel cmdline, or you won't get stderr from initramfs. > - the script does not check that the value given by the user is valid Yes. You can submit an PR to openzfs/zfs, it is located at contrib/initramfs-tools. Thanks, Shengqi Chen
Bug#1038434: Update on bug 1038434
Control: notfound -1 2.1.11-1 Control: tags -1 + wontfix > There is a zfs-load-key service that is masked, and as such never > starts, and the script in init.d doesn't do anything either because of > that. This service is intentionally masked. This functionality is now provided by zfs-mount-generator(8). Please refer to its man pages for usage. Thanks, Shengqi Chen
Bug#1012805: Update on bug 1012805
control: tag -1 + moreinfo unreproducible > At first vdev_id is not in the search path but in /lib/udev/vdev_id. > Next, it doesn't find the config file /etc/zfs/vdev_id.conf when started > without options. It does find it however when this very path is given > explicitly like so: > # /lib/udev/vdev_id -c /etc/zfs/vdev_id.conf This is expected. This script should only be used by udev, not users. > The instructions in the FAQ section of the openzfs docs state that the > command > # udevadm trigger > should create the /dev/disk/by-vdev directory and some symlinks in it. I tried some config with zfs 2.1.4 on bullseye. It worked as expected. Run 'udevadm monitor' when you trigger the udevadm update might help. Thanks, Shengqi Chen
Bug#985299: Update on bug 985299
control: -1 notfound 2.0.3-1 control: -1 tags + wontfix Hi, > After an upgrade, some kind of system services appeared to automatically mount > some FreeBSD partitions on my Debian system directories. As zfs cannot tell which pools / datasets are from FreeBSD, zfs-mount.service will try to mount everything. > Disabling zfs-mount.service and zfs-share.service made my machine work > normally > again, possibly with the modification of /etc/defaults/zfs below: This would work on your case, but might cause trouble when somebody has their root / home on zfs. You can do "zfs set canmount=noauto bsdpool" to prevent auto-mounting of foreign datasets. Thanks, Shengqi Chen
Bug#1064835: zfsutils-linux: installs same filename to both bin and sbin
Hi, > your package installs the filenames `arc_summary` and `arcstat` and `zfs` and > `zilstat` and `zpool` and `zvol_wait` to both bin and sbin as opposed to just > one of those locations. Yes, this is intended. These files were first installed to sbin, later moved to bin. Symlinks are thus created to provide compatibility to user scripts. > This causes a problem on a filesystem layout where bin and sbin are merged > into a single real directory, typically by sbin being a symlink to bin. Such > a filesystem layout has become standard on some distributions now, and others > are moving onto in their next releases. UsrMerge [1] says Debian has no plan to merge bin and sbin. Nonetheless we do plan to remove the symlinks at certain version after the move. [1]: https://wiki.debian.org/UsrMerge Thanks, Shengqi Chen
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, > 2024年5月19日 13:51，Paul Gevers 写道： > > I already noticed yesterday and had it run; it failed. (Currently) top one > here: https://ci.debian.net/packages/z/zfs-linux/testing/amd64/ > My concern now is that the results do not seem to be stable or reproducible. Seven tests have been run since yesterday, of which two failed on zfs-test-suite-foo. Most of these failures may be false positive, and a re-run typically makes them pass. Almost every single test in the failed list can pass independently, but the whole test sequence is failure-prone. I have also observed similar behavior when testing locally (and also in upstream CI). Is there any convention in handling such situation? E.g., should I mark all zfs-test-suite-x as flaky and treat them as reference only? Thanks, Shengqi Chen
Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, > > The test ran. Unfortunately zfs-test-suite-1 failed. > I have made more adjustments, basically skipping some flaky tests in VM. Now new version 2.2.4-1 is in the archive, please try that again when available. Thanks, Shengqi Chen
