Hi,
> 2024年10月7日 19:12，Petter Reinholdtsen 写道：
>
> Why does it not have a symbol control file? Is there any hope to reach
> upstream proper shared library practice?
>
Mo Zhou packaged it solely as dependency of pytorch at first. I believe symbol
control file was not crucial that time, since x
control: block 1084103 by -1
control: block -1 by 1080510
control: block 1081664 by 1080510
> Such ABI changes require an updated SONAME to avoid breaking programs in
> Debian, for example with a rename from libxnnpack0 to libxnnpack1.
Certainly true. But let me explain the situation more:
xnnpac
Hi,
I have finished packaging of onnxruntime 1.19.2, which should fix the breakage.
Currently it is on my personal salsa fork [1]. I have push access to
deeplearning-team
org on salsa. So I can push to team repo, or you can review before pull my
changes.
[1]: https://salsa.debian.org/harry/onn
> How many packages are broken by this update? Without an autopkgtest in
> onnxruntime this would have been silently broken.
Sorry for the breakage. Previously xnnpack only had one rdep, pytorch.
Currently we are doing an upgrading on pytorch, so I uploaded without
requesting a transition.
After
Final update: 3.5.3-2 now compiles on riscv64 (after 10.5 hours).
Thanks for your fix!
Actually dh_auto_test takes huge portion of the time, not build:
3/163 Test #3: cpu-cnn-inference-f32-cpp ...
Passed 618.30 sec
47/163 Test #47: test_convolution_backward_data_f3
control: severity -1 important
control: fixed -1 2.2.5-1
I’m resetting the severity since this bug is (superficially) fixed by 2.2.5-1,
which is compatible with linux 6.10. Also upcoming but not-released zfs
2.2.6 will support linux 6.11. So we might keep up the pace with kernel.
But the problem
control: forwarded -1 https://github.com/oneapi-src/oneDNN/pull/1923
Seems upstream is processing the relative PR.
Maybe we can just a bit longer and use the reviewed upstream version.
Thanks,
Shengqi Chen
Hi,
> Please consider enabling Arm Compute Library integration on arm64
Now I have uploaded latest release of onednn (3.5.3) to unstable.
Seems it requires new libarm-compute (>> 24.05) to use on aarch64.
Would you mind uploading new version and when available,
and update your patch to enable it
Hi
>
> In the end it's your decision. All I can say is that tests that are flaky
> enough (my level is roughly worse than 1/8) and not marked as such are
> considered RC buggy.
>
Seems test stanza tagged with ‘isolated-machine’ are still not run by default.
I have enabled only minimal & essen
Hi,
> Currently this regression is blocking the migration of
> linux-signed-amd64 to testing [1].
zfs 2.2.5 is compatible with Linux 6.10. We will upload 2.2.5-1 soon.
> Is it possible to make the autopkgtest skip the
> test (restriction skipable with exit code 77) if a too new kernel is
> in
Control: tags -1 + upstream
Hi,
> I noticed that the zpool completion does not properly work until after
> one has already run zfs .
> This seems to be due to the fact that
> /usr/share/bash-completion/completions/zpool does not exist but
> /usr/share/bash-completion/completions/zfs does.
> A
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 sin
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
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 dis
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 con
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
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
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
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 con
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
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:
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
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 c
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-gener
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.
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
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
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 so
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
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 co
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 arc
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
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 ...
> i
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:
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 testin
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 rei
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
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-imp
Control: severity -1 normal
Control: notfound -1 2.1.9-1~bpo11+1
Closing due to not a bug.
Thanks,
Shengqi Chen
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 pro
Control: notfound -1 0.8.4-2~bpo10+1
Control: severity -1 normal
Closing due to not a bug.
Thanks,
Shengqi Chen
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
Control: tags -1 + upstream fixed
Control: fixed -1 0.7.3-1
Thanks,
Shengqi Chen
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 i
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
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_
Control: tags -1 + upstream fixed
Control: forwarded -1 https://github.com/openzfs/zfs/issues/11278
Control: fixed 2.1.1-1
Thanks,
Shengqi Chen
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]:
Control: tags -1 + unreproducible
Closing legacy bugs.
Thanks,
Shengqi Chen
Control: tag -1 + upstream
Control: forwarded -1 https://github.com/openzfs/zfs/issues/11587
Thanks
Shengqi Chen
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-modul
Control: notfound -1 2.0.3-1~bpo10+1
Control: tag -1 + unreproducible
Thanks,
Shengqi Chen
Control: notfound -1 2.1.5-1
Feel free to re-open if there are still problems.
Thanks,
Shengqi Chen
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
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
Control: fixed -1 2.1.7-1
You may also refer to #900656.
Thanks,
Shengqi Chen
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** actuall
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
Control: unblock -1 by 981212
Control: merge -1 981212
Control: tag 981212 + upstream
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:
>
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 nex
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
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-
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 Zha
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
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://sals
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+
67 matches
Mail list logo
