Bug#928746: unblock: zfs-linux/0.7.13-1

2019-06-03 Thread Sam Hartman
Please start talking to the kernel team now, and let them know your
position.

If you strongly suspect you're going to file an RC bug in the future,
you should be talking now, not just holding back.

I'm available to mediate if that ends up being useful.



Bug#928746: unblock: zfs-linux/0.7.13-1

2019-06-03 Thread Mo Zhou
control: retitle -1 unblock: zfs-linux/0.7.12-6 (or 0.7.13-1)
control: close -1

Hi Release Team,

On 2019-06-03 15:05, Mo Zhou wrote:
> Patching the kernel is impossible because kernel maintainers
> refused to do that. So that's an invalid solution.

After a short discussion with Aron Xu, I realized that I made
a mistake about the kernel SIMD problem.

It's the ***LTS KERNEL UPDATE*** that breaks ZFS 0.7.12-2.
It's not a bug of 0.7.12-2 at all. An LTS KERNEL UPDATE
that BREAKS stuff indicates a grave RC.

> I'll never argue about ZFS unblock again for Buster.

Sorry and I decided to give up the unblock request.
We[2] Debian ZoL maintainers decided to do nothing about
the kernel SIMD issue and we'll file an RC bug against
the kernel immediately after the 10.1 point release
because it breaks stuff.

[1]
https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730
[2] Aron and Me.



Bug#928746: unblock: zfs-linux/0.7.13-1

2019-06-03 Thread Mo Zhou
Hi Paul,

On 2019-05-30 19:51, Paul Gevers wrote:
> or more severe in Debian BTS terms. I may have been wrong, but then
> please point me to the changes so important that you want them in
> buster. Please also be prepared to undo the new upstream release and
> just fix the bugs that are so important to you.

I've already forgotten them and I'm tired to review the diff.
Let's forget all the important stuff and only focus on the grave one:

Due to a stable kernel change (4.19.37->4.19.38) that makes me sad,
we got a grave RC for ZFS 0.7.12-2 (testing) which makes it not suitable
for the Buster release:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929929

We have two solutions for this stable RC:

1. just unblock 0.7.13-1 .
2. revert debdiff(0.7.12-2,0.7.12-5), then cherry-pick
   the commits[1] that fix the build issue, then go
   through t-p-u for 0.7.12-6 .

Patching the kernel is impossible because kernel maintainers
refused to do that. So that's an invalid solution.

> Be aware that requests like this one are draining energy from the
> release team. It isn't nice to turn a maintainer down on a request,
> repeating the process is worse. Your changes are huge (your explanation
> is appreciated), we get several unblock requests per day and we have a
> freeze policy in place to manage it. Please don't push your pet project
> so hard if it doesn't meet the policy that you are driving the
> volunteers in the release team away. Thanks for also considering our time.

Sorry for that. My motivation is just that 0.7.13-1 is really
expected to reduce the number of problems compared to 0.7.12-2...

Please make a choice between the two proposed solution above.
If release team doesn't trust every line of code, please just
choose 2. I'll never argue about ZFS unblock again for Buster.

[1] Patch:
https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730



Bug#928746: unblock: zfs-linux/0.7.13-1

2019-05-31 Thread Christian Marillat
On 30 mai 2019 21:51, Paul Gevers  wrote:

> Control: tags -1 moreinfo
>
> Hi Mo,
>
> On Thu, 09 May 2019 22:09:18 -0700 Mo Zhou  wrote:
>> zfs-linux (= 0.7.13-1) is 66 days in unstable and there is no new bug
>> for it.
>> Compared to (0.7.12-2), the (0.7.13-1) version in unstable only
>> introduces
>> bug fixes. Aron has already applied for an unblock but it was rejected.
>> Here I'm requesting for unblock again.
>
> I checked bug #923770 again (it was filed by you by the way). As I said
> in that bug, I didn't spot anything that was at the level of important
> or more severe in Debian BTS terms. I may have been wrong, but then
> please point me to the changes so important that you want them in
> buster. Please also be prepared to undo the new upstream release and
> just fix the bugs that are so important to you.

I see a problem with longterm kernel is Buster (4.19).
4.19.38 doesn't build with zfs 0.7.12

OK, 4.19.37 will be the Buster kernel, but has we upgrade recent kernel
from longterm branch for stable release the next stable release will
probably break zfs.

So zfs 0.7.13 is probably a good choice for Buster.

This is because kernel 5.0 "drops export of __kernel_fpu_begin/end" has
been back-ported to 4.19.38 (and also 4.14.120) kernel and fixed in zfs 0.7.13

https://github.com/NixOS/nixpkgs/issues/60907
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.38
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.120

Christian



Bug#928746: unblock: zfs-linux/0.7.13-1

2019-05-30 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Mo,

On Thu, 09 May 2019 22:09:18 -0700 Mo Zhou  wrote:
> zfs-linux (= 0.7.13-1) is 66 days in unstable and there is no new bug
> for it.
> Compared to (0.7.12-2), the (0.7.13-1) version in unstable only
> introduces
> bug fixes. Aron has already applied for an unblock but it was rejected.
> Here I'm requesting for unblock again.

I checked bug #923770 again (it was filed by you by the way). As I said
in that bug, I didn't spot anything that was at the level of important
or more severe in Debian BTS terms. I may have been wrong, but then
please point me to the changes so important that you want them in
buster. Please also be prepared to undo the new upstream release and
just fix the bugs that are so important to you.

Be aware that requests like this one are draining energy from the
release team. It isn't nice to turn a maintainer down on a request,
repeating the process is worse. Your changes are huge (your explanation
is appreciated), we get several unblock requests per day and we have a
freeze policy in place to manage it. Please don't push your pet project
so hard if it doesn't meet the policy that you are driving the
volunteers in the release team away. Thanks for also considering our time.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928746: unblock: zfs-linux/0.7.13-1

2019-05-09 Thread Mo Zhou
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: a...@debian.org

Please unblock package zfs-linux

zfs-linux (= 0.7.13-1) is 66 days in unstable and there is no new bug
for it.
Compared to (0.7.12-2), the (0.7.13-1) version in unstable only
introduces
bug fixes. Aron has already applied for an unblock but it was rejected.
Here I'm requesting for unblock again.

The difference between upstream 0.7.12 and 0.7.13 includes
linux 5.0 compat fixes, and a series of bug fixes. I can revert
the linux 5.0 compat fixes if you think that's irrelated to
the Buster release with the 0.7.13-2 upload. I can also revert
some enhancement patches if release team doesn't like them. Even
if we reverted the linux 5.0 compat and some enhancements, it
is still better than letting 0.7.12-2 stay in Buster, because
in that way we still have bug fixes.

On the debian packaging side, the difference between 0.7.12-2
(testing) and 0.7.13-1 (unstable) includes manually cherry-picked
patches (by Colin Ian King(ubuntu diff), Aron Xu, and Me), fixes
for the problematic autopkgtest script I wrote, and a small update
for the Debian+OpenRC support patch. Most of the newly added patches
were already shipped by the ubuntu package more than 3 months ago.

zfs (0.7.12-5) was uploaded to unstable before (hardfreeze - 12 days).
zfs (0.7.13-1) was uploaded to unstable on (hardfreeze - 8 days).
I should have waited for some time for the 0.7.12-5 migration...

Anyway let's see the diffstat and I'll comment every bit of change in
detail.  Please at least accept some bug fixes for Buster. And tell
me which of the enhancements (incl. linux 5.0 compat) are
not acceptible so that I can revert them.

(explain the reason for the unblock here)

```
~/D/z/zfs ❯❯❯ git diff debian/0.7.12-2 debian/0.7.13-1 --stat | cat
 META   |   2 +-
 Makefile.in|   2 +
 aclocal.m4 |   2 +
 cmd/Makefile.in|   2 +
 cmd/arc_summary/Makefile.in|   2 +
 cmd/arcstat/Makefile.in|   2 +
 cmd/dbufstat/Makefile.in   |   2 +
 cmd/fsck_zfs/Makefile.in   |   2 +
 cmd/mount_zfs/Makefile.am  |   2 +
 cmd/mount_zfs/Makefile.in  |   4 +
 cmd/raidz_test/Makefile.in |   2 +
 cmd/vdev_id/Makefile.in|   2 +

[linux 5.0 compat]
*.am and *.in was updated for linux 5.0

 cmd/vdev_id/vdev_id| 209 -

[enhancements]

2b8c3cb0c83681d7425fa5bf567e726b7ba975e9
vdev_id: extension for new scsi topology

41f7723e9cb260f313f99d667142e37617812fca
vdev_id: new slot type ses

c32c2f17d06cea5dc298b404fad7696921e490e0
Add enclosure_symlinks option to vdev_id

 cmd/zdb/Makefile.in|   2 +
 cmd/zed/Makefile.in|   2 +
 cmd/zfs/Makefile.in|   2 +
 cmd/zgenhostid/Makefile.in |   2 +
 cmd/zhack/Makefile.in  |   2 +
 cmd/zinject/Makefile.in|   2 +
 cmd/zpios/Makefile.in  |   2 +
 cmd/zpool/Makefile.in  |   2 +
 cmd/zstreamdump/Makefile.in|   2 +
 cmd/ztest/Makefile.in  |   2 +

[linux 5.0 compat]
all the *.in files above

 cmd/ztest/ztest.c  |   4 +-

[trivial C code change]
-   .zo_pool = { 'z', 't', 'e', 's', 't', '\0' },
-   .zo_dir = { '/', 't', 'm', 'p', '\0' },
+   .zo_pool = "ztest",
+   .zo_dir = "/tmp",

 cmd/zvol_id/Makefile.in|   2 +
 config/kernel-access-ok-type.m4|  21 +
 config/kernel-bio_set_dev.m4   |  35 +-
 config/kernel-fpu.m4   |  41 +-
 config/kernel-misc-minor.m4|  26 +
 config/kernel.m4   |   4 +-

[linux 5.0 compat]
the above several files were changed due to linux compat fix

 configure  | 599
++-

Mostly due to newly added kernel feature checks.
Deleted lines are due to version number bump.

 configure.ac   |   3 +
 contrib/Makefile.in|   2 +
 contrib/bash_completion.d/Makefile.in  |   2 +
 contrib/dracut/02zfsexpandknowledge/Makefile.in|   2 +
 contrib/dracut/90zfs/Makefile.am   |   1 +
 contrib/dracut/90zfs/Makefile.in   |   3 +
 contrib/dracut/90zfs/module-setup.sh.in|   4 +-
 contrib/dracut/Makefile.in