Bug#1034624: 2.1.11 tagged

[Chris Zubrzycki]

Sorry, poor timing. Looks like 2.1.11 was just tagged with this commit reversed 
and 2 more minor other fixes.

https://github.com/openzfs/zfs/releases/tag/zfs-2.1.11

Bug#993048: mosquitto init script broken with bullseye update

[Chris Zubrzycki]

Package: mosquitto
Version: 2.0.11-1
Severity: important
Tags: patch

Dear Maintainer,

With the 2.0 upgrade, mosquitto now writes a pid file on it's own as the
mosquitto user. This breaks the init script as the run directory is root
writable, and on top of that the init script uses s-s-d to also write a
root-owned pid file. The attached patch should match the behavior of the
systemd file, which is let the daemon write it's own pid file in
/var/run/mosquitto/ and chowns the dir to allow it. I have disabled
s-s-d from making a root owned file, and also added a match to the
mosquitto user for stopping/reloading as the new policy says non-root
pid files are insecure unless additional matches are present.


Oh, and listener 1883 needs to be added ito the config otherwise mosquitto
only listens on loopback which will break most existing installs.

references:
https://issues.apache.org/jira/secure/attachment/13001569/0001-Fix-init-script-for-debian-Buster.patch
https://github.com/eclipse/mosquitto/issues/1950

-- System Information:
Debian Release: 11.0
 APT prefers stable
 APT policy: (700, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages mosquitto depends on:
ii  adduser3.118
ii  libc6  2.31-13
ii  libcjson1  1.7.14-1
ii  libdlt22.18.6-1
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libmosquitto1  2.0.11-1
ii  libssl1.1  1.1.1k-1
ii  libwebsockets164.0.20-2
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0

mosquitto recommends no packages.

Versions of packages mosquitto suggests:
ii  apparmor  2.13.6-10

-- Configuration Files:
/etc/init.d/mosquitto changed:
set -e
PIDFILE=/run/mosquitto/mosquitto.pid
DAEMON=/usr/sbin/mosquitto
USER=mosquitto
test -x ${DAEMON} || exit 0
umask 022
. /lib/lsb/init-functions
run_by_init() {
   ([ "$previous" ] && [ "$runlevel" ]) || [ "$runlevel" = S ]
}
export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
case "$1" in
 start)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Starting network daemon:" "mosquitto"
/bin/mkdir -m 740 -p /var/log/mosquitto
/bin/chown mosquitto /var/log/mosquitto
/bin/mkdir -m 740 -p /run/mosquitto
/bin/chown mosquitto /run/mosquitto
if start-stop-daemon --start --quiet --oknodo --background  --user 
${USER} --pidfile ${PIDFILE} --exec ${DAEMON} -- -c 
/etc/mosquitto/mosquitto.conf ; then
log_end_msg 0
else
log_end_msg 1
fi
;;
 stop)
if init_is_upstart; then
exit 0
fi
log_daemon_msg "Stopping network daemon:" "mosquitto"
if start-stop-daemon --stop --quiet --oknodo --user ${USER} --pidfile 
${PIDFILE}; then
log_end_msg 0
rm -f ${PIDFILE}
else
log_end_msg 1
fi
;;
 reload|force-reload)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Reloading network daemon configuration:" "mosquitto"
   if start-stop-daemon --stop --signal HUP --quiet --oknodo --user ${USER} 
--pidfile $PIDFILE; then
   log_end_msg 0
   else
   log_end_msg 1
   fi   
;;
 restart)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Restarting network daemon:" "mosquitto"
if start-stop-daemon --stop --quiet --oknodo --retry 30 --user ${USER} 
--pidfile ${PIDFILE}; then
rm -f ${PIDFILE}
fi

/bin/mkdir -m 740 -p /var/log/mosquitto
/bin/chown mosquitto /var/log/mosquitto
/bin/mkdir -m 740 -p /run/mosquitto
/bin/chown mosquitto /run/mosquitto
if start-stop-daemon --start --quiet --oknodo --background --pidfile 
${PIDFILE} --user ${USER} --exec ${DAEMON} -- -c /etc/mosquitto/mosquitto.conf 
; then
log_end_msg 0
else
log_end_msg 1
fi
;;
 try-restart)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Restarting Mosquitto message broker" "mosquitto"
set +e
start-stop-daemon --stop --quiet --retry 30 --pidfile ${PIDFILE}
RET="$?"
set -e
case $RET in
0)
# old daemon stopped
rm -f ${PIDFILE}
if start-stop-daemon --start --quiet --oknodo --background 
--pidfile ${PIDFILE} --user ${USER} --exec ${DAEMON} -- -c 
/etc/mosquitto/mosquitto.conf ; then
log_end_msg 0
else
log_end_msg 1
fi
;;
1)
   

Bug#940115: fail2ban: missing depend on ipset

[Chris Zubrzycki]

Package: fail2ban
Version: 0.9.6-2
Severity: important

I was wondering why fail2ban didn't seem to be working, and I saw a bunch of 
errors in the log file about the ipset command failing. Seems that's now how 
the package sets bans, but there is no depends on the ipset package.

-- System Information:
Debian Release: 9.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-0.bpo.9-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages fail2ban depends on:
ii  init-system-helpers  1.48
ii  lsb-base 9.20161125
ii  python3  3.5.3-1

Versions of packages fail2ban recommends:
ii  iptables   1.6.0+snapshot20161117-6
ii  python 2.7.13-2
ii  python3-pyinotify  0.9.6-1
ii  python3-systemd233-1
ii  whois  5.4.2~bpo9+1

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  monit1:5.20.0-6
ii  rsyslog [system-log-daemon]  8.1901.0-1~bpo9+1

-- no debconf information

Bug#923240: me too.

[Chris Zubrzycki]

Please get this working somehow. I do not wish to finally have to switch to 
devuan, but if I can not use virt-manager anymore (which requires policykit-1) 
I will have to do it. 

Thanks!

Bug#931515: zfs-linux: update depends for stretch

[Chris Zubrzycki]

Source: zfs-linux
Version: 0.8.1-1
Severity: important

Dear Maintainer,

I am building the experimental version on Stretch and there are a couple
of depends that need updating. The conflict on ols insserv is not
needed, nor is a newer version available on stretch. The circular
depends has been fixed upstream and is included in the debian 0.8
package.

The second is there is a depend on python3-distutils, but those files
are part of the python3 standard library package in stetch. This is also
not available as a backport, but can be easiy fixed with changing the
depends to python3-distutils | libpython3-stdlib (<3.6.4)

I know that Buster's release is today but there are still
systems that are using stretch for one reason or another, and these 2
changes do not affect building on buster or sid.

Thank you! I look forward to not needing to patching locally :-)



-- System Information:
Debian Release: 9.9
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#867299: upstream

[Chris Zubrzycki]

This is/was an upstream bug it should likely be closed. It’s also from code 
many years out of date now.

Bug#929557: Some Thoughts

[Chris Zubrzycki]

On Thu, 06 Jun 2019 12:19:03 -0400 Sam Hartman  wrote:
> 
> The linux Kernel introduced an upstream commit designed to remove an
> interface that was being misused.

No, it was removed as part of code cleanup. There was no “misuse”. It was added 
for KVM and existed for 7 years. KVM hasn’t needed it for a while, so patch was 
submitted to remove the exported function *only* leaving the GPL exported 
version. GKH went ahead and violated the kernel procedures and removed the 
symbols from LTS kernels as well. LTS is not where code cleanup should be done 
and symbols removed.


> That does not meet the kind of requirements for changes that we (Debian)
> make in stable releases.
> If I filed an unblock for krb5 to remove an interface at this point in
> the release process it would be outright refused.

Except this is to *not* remove an interface from LTS kernels. See above.

 
> We are more permissive in what changes we accept from the kernel team.

And yet you are trying to stick to the rules unlike the kernel team…


> That is, if we had the resources to review the changes adequately and do
> adequate testing, I actually suspect we would hold the kernel to the
> same standards we hold other packages to.

The symbol was exported without issue for 7 years. It’s been tested.
 
> I do not think this particular change would meet those standards for
> buster.

I thought LTS was supposed to be stable and not have symbols removed?

> I'm not saying the kernel team should revert the commit.
> I'm saying that the issue is far more complex than has been outlined in
> this bug so far.
> 
> I think that the kernel team and the ZOL maintainers should work with
> the stable release team for buster to figure out which changes are
> permissible.
> Ultimately I'd expect that the stable release team will get to decide
> which changes they want in buster and I hope that the kernel team and
> the ZOL maintainers will work with that.

Unfortunately GKH has put his foot down with this change and insists the 
symbols be exported GPL only for 5.x and above. He doesn’t care much about 
other open source projects:
"My tolerance for ZFS is pretty non-existant. “ 
https://marc.info/?l=linux-kernel=154714516832389 except he is doing extra 
work to cause problems with ZFS by removing exported symbols from LTS kernels 
against policy.

See the pattern? No ZFS on linux user is happy about the 5.x change, but there 
is no valid reason to remove it from 4.x.

Also. there is no copyright violation reversing a commit, as it’s still 
released GPL code. GPL code is still GPL code even if it’s not in a current 
release. That would be interesting if code lost it’s copyright once it wasn’t 
being shipped.


-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


"Twice blessed is help unlooked for." --Tolkien

Bug#929929: zfs smid

[Chris Zubrzycki]

Is there any chance to keep the removed exported symbol? Could you guys 
convince the kernel team? There’s no copyright issue since it’s released code, 
it’s just keeping a symbol that has been in exported in the kernel for the past 
7 years. On top of that, Greg is violating the kernel release rules by removing 
exports/doing code cleanup in stable kernels.

Bug#929557: linux: restore __kernel_fpu needed for zfs for AES-NI/AVX support [mainline not in debian yet]

[Chris Zubrzycki]

Source: linux
Severity: wishlist
Tags: upstream patch

Dear Maintainer,

GKH has been purging __kernel_fpu_{begin,end}() from all kernels
including LTS (4.19/5) and it's needed for AES-NI/AVX support in the zfs
package. If this commit makes it to debian it will break all older zfs
releases and will cause very high cpu and terrible speed with encrypted
zfs pools. Arch Linux has already reverted the offending commit in their
distro. Patch available at
https://raw.githubusercontent.com/Mic92/nixpkgs/7b77c27caa8617c82df5c5af6b9ce6ae010d7f9a/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions.patch

Thank you!

-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)




-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot

Bug#924286: netatalk: Netatalk 3 in Buster

[Chris Zubrzycki]

Package: netatalk
Version: 3.1.10-1
Severity: normal

Dear Maintainer,

Please push netatalk 3 to buster before the freeze. It doesn't really
help people if it's forever in sid. Push netatalk v2 to it's own package
if needed, or 3 in it's own. I am glad to see it in sid, at least though.

Thank you.

-- System Information:
Debian Release: 9.8
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages netatalk depends on:
ii  libacl1   2.2.52-3+b1
ii  libatalk183.1.10-1
ii  libattr1  1:2.4.47-2+b2
ii  libavahi-client3  0.6.32-2
ii  libavahi-common3  0.6.32-2
ii  libc6 2.24-11+deb9u4
ii  libcomerr21.43.4-2
ii  libcrack2 2.9.2-5
ii  libdb5.3  5.3.28-12+deb9u1
ii  libdbus-1-3   1.10.24-0+deb9u1.0nosystemd1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libgcrypt20   1.7.6-2+deb9u3
ii  libglib2.0-0  2.50.3-2
ii  libgssapi-krb5-2  1.15-1+deb9u1
ii  libk5crypto3  1.15-1+deb9u1
ii  libkrb5-3 1.15-1+deb9u1
ii  libldap-2.4-2 2.4.44+dfsg-5+deb9u2
ii  libmysqlclient18  5.5.57-0+deb8u1
ii  libpam-modules1.1.8-3.6
ii  libpam0g  1.1.8-3.6
ii  libwrap0  7.6.q-26
ii  netbase   5.4
ii  perl  5.24.1-3+deb9u5
ii  python2.7.13-2
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages netatalk recommends:
ii  avahi-daemon  0.6.32-2
ii  cracklib-runtime  2.9.2-5
ii  db-util   5.3.1
pn  libpam-cracklib   
ii  lsof  4.89+dfsg-0.1
ii  procps2:3.3.12-3.0nosystemd1
pn  rc

Versions of packages netatalk suggests:
pn  db4.2-util
pn  groff 
pn  quota 
pn  texlive-base-bin  

-- Configuration Files:
/etc/netatalk/afp.conf changed [not included]

-- debconf-show failed

Bug#923946: samba: backport to stretch before freeze please

[Chris Zubrzycki]

Package: samba
Version: 2:4.5.16+dfsg-1
Severity: wishlist

Dear Maintainer,

Please provide backport packages for samba so we have the option of
using the newer features like timemachine support before the stretch
freeze. It would really help systems that aren't quite ready to switch
to testing/new stable yet. 

Thank you!

-- System Information:
Debian Release: 9.8
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages samba depends on:
ii  adduser  3.115
ii  dpkg 1.18.25
ii  init-system-helpers  1.48
ii  libbsd0  0.8.3-1
ii  libc62.24-11+deb9u4
ii  libldb1  2:1.1.27-1+b1
ii  libpam-modules   1.1.8-3.6
ii  libpam-runtime   1.1.8-3.6
ii  libpopt0 1.16-10+b2
ii  libpython2.7 2.7.13-2+deb9u3
ii  libtalloc2   2.1.8-1
ii  libtdb1  1.3.11-2
ii  libtevent0   0.9.31-1
ii  libwbclient0 2:4.5.16+dfsg-1
ii  lsb-base 9.20161125
ii  python   2.7.13-2
ii  python-dnspython 1.15.0-1+deb9u1
ii  python-samba 2:4.5.16+dfsg-1
ii  python2.72.7.13-2+deb9u3
ii  samba-common 2:4.5.16+dfsg-1
ii  samba-common-bin 2:4.5.16+dfsg-1
ii  samba-libs   2:4.5.16+dfsg-1
ii  tdb-tools1.3.11-2
ii  update-inetd 4.44

Versions of packages samba recommends:
ii  attr1:2.4.47-2+b2
ii  logrotate   3.11.0-0.1
ii  samba-dsdb-modules  2:4.5.16+dfsg-1
ii  samba-vfs-modules   2:4.5.16+dfsg-1

Versions of packages samba suggests:
pn  bind9  
ii  bind9utils 1:9.10.3.dfsg.P4-12.3+deb9u4
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p10+dfsg-3+deb9u2
pn  smbldap-tools  
pn  ufw
ii  winbind2:4.5.16+dfsg-1

-- debconf-show failed

Bug#915831: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure

[Chris Zubrzycki]

> Tried upgrading from stretch-backports 0.7.11 to testing 0.7.12, because
> the package hadn't landed in backports yet, and discovered it broke on
> dpkg --configure :
> Setting up zfsutils-linux (0.7.12-1) ...
> insserv: Service zfs-zed has to be enabled to start service zfs-share
> insserv: exiting now!
> update-rc.d: error: insserv rejected the script header
> dpkg: error processing package zfsutils-linux (--configure):
> subprocess installed post-installation script returned error exit status 1
> dpkg: dependency problems prevent configuration of zfs-zed:
> zfs-zed depends on zfsutils-linux (>= 0.7.12-1); however:
>  Package zfsutils-linux is not configured yet.
> 
> Someone else had reported a similar problem upstream to ZoL from Ubuntu's
> packages, at:
> https://github.com/zfsonlinux/zfs/issues/8127

Sorry! I messed up the order of packages and thought I fixed it, but I didn’t.

You have a circular dependency and that’s why it is failing. You have zfs-zed 
set to depend on zfsutils-linux, but there is a hard dependency in the 
zfs-share init file on zfs-zed. 
There is no need for zed to be running before sharing is started, however it 
does provide helpful status logging. It is not necessarily an upstream bug, 
because debian decided to split zed out as it’s own package and it’s debian’s 
tools that are having trouble with the circular dependency caused. It is safe 
to remove it from Required-Start, as shown by the systemd files not requiring 
zed to be started first.


Here is the fix, or you can move zfs-share to zfs-zed for some reason:

--- zfs-share.orig  2019-01-04 11:26:09.076322596 -0500
+++ zfs-share   2019-01-04 11:26:32.643426954 -0500
@@ -9,8 +9,8 @@
 #
 ### BEGIN INIT INFO
 # Provides:  zfs-share
-# Required-Start:$local_fs $network $remote_fs zfs-mount zfs-zed
-# Required-Stop: $local_fs $network $remote_fs zfs-mount zfs-zed
+# Required-Start:$local_fs $network $remote_fs zfs-mount
+# Required-Stop: $local_fs $network $remote_fs zfs-mount
 # Default-Start: 2 3 4 5
 # Default-Stop:  0 1 6
 # Should-Start:  iscsi iscsitarget istgt scst nfs-kernel-server samba 
samba4 zfs-mount zfs-zed




-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


Unix  _IS_  user friendly... It's just selective about who its friends are.

Bug#915831: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure

[Chris Zubrzycki]

> Tried upgrading from stretch-backports 0.7.11 to testing 0.7.12, because
> the package hadn't landed in backports yet, and discovered it broke on
> dpkg --configure :
> Setting up zfsutils-linux (0.7.12-1) ...
> insserv: Service zfs-zed has to be enabled to start service zfs-share
> insserv: exiting now!
> update-rc.d: error: insserv rejected the script header
> dpkg: error processing package zfsutils-linux (--configure):
>  subprocess installed post-installation script returned error exit status 1
> dpkg: dependency problems prevent configuration of zfs-zed:
>  zfs-zed depends on zfsutils-linux (>= 0.7.12-1); however:
>   Package zfsutils-linux is not configured yet.
> 
> Someone else had reported a similar problem upstream to ZoL from Ubuntu's
> packages, at:
> https://github.com/zfsonlinux/zfs/issues/8127

Has anyone else reproduced this? I just made a new VM to test and I could not 
get it to trigger. I installed systemd-sysv, initscripts and insserv, then I 
installed zfs, installed 0.11 with the init scripts, then the 0.12 packages 
from unstable which also have init scripts, and there was no error. Maybe I’m 
missing something?

Processing triggers for initramfs-tools (0.130) ...
update-initramfs: Generating /boot/initrd.img-4.9.0-4-amd64
Setting up zfsutils-linux (0.7.12-1) ...
Installing new version of config file /etc/zfs/zfs-functions ...
zfs-import-scan.service is a disabled or a static unit, not starting it.
Processing triggers for systemd (232-25+deb9u6) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up zfs-dkms (0.7.12-1) ...

 




If there is a conflict, what about trying to move zfs-share to the zfs-zed 
package if it really depends on it to start? If not, remove the hard depends 
and maybe it’ll start? Seems zfs had a similar bug 3 years ago and they said 
the service start order was important… 

https://github.com/zfsonlinux/zfs/issues/2680

I mean, that’s what it looks like is going wrong from the error. There’s an 
init file(1) that depends on another init file(2) in a package(2) that depends 
on package(1). Circular dep. Am I understanding it right?

Bug#837049: arc max

[Chris Zubrzycki]

From what I’ve seen, this change should not really be needed anymore. ZFS is 
much better at release arc memory (disk cache) with 0.7.x and later. As soon as 
there’s memory pressure zfs will give up that ram. The only issues are when 
there’s a single large chunk requested like a VM, zfs can’t release the ram 
fast enough.

Bug#915831: zfs init file upgrade

[Chris Zubrzycki]

I would like to amend my reply. The files are no longer in the deb, however 
they are still listed by dpkg -L zfsutils-linux. I do not understand how the 
solution to an ordering issue is to remove needed init files that have been 
fought to be included for literally years.

Bug#915831: zfs upgrade

[Chris Zubrzycki]

I was able to upgrade from 0.7.11 to 0.7.12 without any issues, using 
stretch-backports. Thankfully, the init.d scripts are still there, contrary to 
Aron’s changelog entry.



-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


"Sadly, text alone cannot convey the depths of my sarcasm."

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Devuan Compatibility

[Chris Zubrzycki]

On Wed, 17 Oct 2018 17:03:34 +0200 Petter Reinholdtsen  wrote:
> 
> [Chris Dos]
> > If this patch gets applied,
> 
> I believe the point Aron is trying to get through to those of you who
> care about init.d scripts, is that you should work with the upstream
> project to get the scripts included there, to avoid having the Debian
> packages deviate from upstream any more.
> 
> In other words, you are barking up the wrong tree.  Try the upstream
> tree, it might work better.

I think you may be confused here. The scripts have been upstream for years. In 
fact for many years they were the *only* upstream init scripts. 
https://github.com/zfsonlinux/zfs/tree/master/etc/init.d has them, last 
modified 2 years - 3 months ago. That is upstream. They were successfully 
shipped in the upstream debian packages until debian finally accepted a native 
package. We have been trying to get the sysv scripts added back in since then. 
The patch from Chris Dos does not add any init scripts, it only has them 
installed to the debian package and changes the location of 2 binaries to where 
debian put them. His patch only adds 30 lines to the debian build scripts 
almost all in debian/rules. How exactly do we bark this up upstream's tree?


-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


Unix  _IS_  user friendly... It's just selective about who its friends are.

Bug#826994: new release

[Chris Zubrzycki]

ZFS 0.7.10 was just released. Could we please get sysvinit scripts into this 
one?

https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.7.10

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Bug#826994: Missing init-script(s)?

[Chris Zubrzycki]

So can we get the nfs order straight and get it merged? There are people who 
are very willing to give a hand maintaining LSB support, as this bug report and 
patches demonstrate.



On Tue, 5 Jul 2016 01:21:12 +1000 Craig Sanders  wrote:


> When I asked Aron Xu about this back in Feb, he said:
> 
>  > The only stopper for adding LSB (sysvinit) support is manpower, I
>  > dropped the support to make things easier for doing an initial upload
>  > for the archive. systemd support is tested and used in production by
>  > myself on Jessie systems without problem, though. If there is people
>  > willing to give a hand on maintaining LSB support I'm happy to carry
>  > it.
> 
> I guess that means "patches welcome”.

Bug#826994: [zfsutils-linux]

[Chris Zubrzycki]

That's a workaround at best, not a solution. The scripts aren't configured with 
the Debian package so the macros are not expanded. The update-defaults command 
doesn't get run on new systems, nor do we get any upstream modifications or 
fixes.  It seems to be a well-done patch for an officially supported init 
system, I haven't heard any reason yet to not merge it.


Sent from my iPhone

> On Jun 25, 2018, at 17:23, Antonio Russo  wrote:
> 
> [snip]
>> I shouldn’t have to keep building custom versions so my pools import on 
>> boot...
> 
> If you just install the regular Debian zfs packaging, and then make sure the 
> init
> scripts are installed an enabled, they will stay enabled. (upgrading the zfs
> packaging won't disable init scripts it knows nothing about).
> 
> As frustrating as this all is, you do not need to rebuild the package just to
> install a few init scripts once per machine. If you're provisioning a large 
> number
> of machines regularly, I also sympathize, but it's still just a couple more 
> lines
> in Ansible.

Bug#826994: ini scripts

[Chris Zubrzycki]

I don’t understand the reluctance in merging this. I shouldn’t have to keep 
building custom versions so my pools import on boot...

Bug#826994: init scripts

[Chris Zubrzycki]

I tested this patch and it works great on jessie and stretch with systemd 
uninstalled.

Bug#897568: 4.16 breakage

[Chris Zubrzycki]

ZoL only breaks on kernel updates when the kernel changes the API/structures 
that it uses. ZFS 0.7.9 is released and fully supports all current kernels, and 
has some good bug fixes and feature upgrades. 

Bug#893578: 0.7.7 Regression

[Chris Zubrzycki]

On Tue, 10 Apr 2018 07:17:53 -0600 Chris Dos  wrote:
> 0.7.7 had a critical regression.  0.7.8 is out now.
> 
>   Chris
> 
> 

If possible please also include this small off-by-1 patch that was accepted 
into upstream: https://github.com/zfsonlinux/zfs/pull/7417

Bug#826994: Updated Patch for 0.7.6-1

[Chris Zubrzycki]

Please, lets get this fixed and merged. sysvinit is still officially supported 
in debian, although it’s not required. Some of us still like our init systems 
to be just that, and of course zfs fully supports it as well. It’s a bit insane 
that we have to manually install the init files on every system ourselves, they 
could have at least been hidden in docs/ or something


-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


"Sadly, text alone cannot convey the depths of my sarcasm."

Bug#864074: I agree

[Chris Zubrzycki]

I agree with most of this bug report. The config system is backwards, broken, 
and confusing. There needs to be the equivalent of the solution pasted here 
adopted as the default configuration.

" Explicitly source defaults.vim so you can override its settings
source $VIMRUNTIME/defaults.vim
" Prevent it from being loaded again later if the user doesn't have
" a vimrc
let skip_defaults_vim = 1
" Disable the settings you don't like
“ set mouse=

should be there as a default. Either fixed inthe code, or as the debian default 
config file. Just because upstream does a boneheaded thing, doesn’t mean it’s a 
package manager’s responsibility to blindly follow it. Debian changes defaults 
and packages all the time to fit the way Debian does things, and the way Debian 
uses expect. I try to limit my terminal use to Debian and OS X. I couldn’t care 
less what RedHat does with it’s vim settings.

Please change it so people don’t have to reconfigure every box they use to a 
sane default.


-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


Unix  _IS_  user friendly... It's just selective about who its friends are.

Bug#755158: After dist-upgrade logcheck cannot open logoutput

[Chris Zubrzycki]

This is caused by something making /var/log/syslog root:root 600 on 
dist-upgrade on my system.

Bug#863520: cyrus-imapd version 2.5.10-3 Fatal error with SSL

[Chris Zubrzycki]

Any update on when this fix can get into an update? It’s causing annoying 
problems

Aug 12 22:35:11 lorien cyrus/imaps[21146]: inittls: Loading hard-coded DH 
parameters
Aug 12 22:35:11 lorien cyrus/imaps[21146]: Fatal error: Internal error: 
assertion failed: lib/cyrusdb_twoskip.c: 1727: key && keylen
Aug 12 22:35:11 lorien cyrus/master[20243]: process type:SERVICE name:imaps 
path:/usr/lib/cyrus/bin/imapd age:0.091s pid:21146 exited, status 75

Bug#848945: grub-common: Empty rpool leaves ZFS systems unbootable

[Chris Zubrzycki]

Good patch, except my root dataset has a - in it’s name, it’s called debian-2 
and each major upgrade gets a new version… Please change the grep line to use 
grep -P -v '\s-‘


zfsbootfs=`zpool get bootfs | sed '2,100!d' |  grep -P -v ‘\s-' | awk {'print 
$3'} 2>/dev/null || true`

Nothing in that command should have whitespace then a - as far as I can tell, 
unless it’s a pool without bootfs set.


-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


"Twice blessed is help unlooked for." --Tolkien

Bug#559109: #559109 - snmpd: Lots of errors in syslog : error on subcontainer 'ia_addr' insert (-1) - Debian Bug report logs

[Chris Zubrzycki]

This is fixed in the latest snmpd. The problem is, snmpd reports *all* errors 
to syslog, because of /etc/defaults/snmpd. To log only up to info level, and 
not debug, change these to lines as follows:

SNMPDOPTS='-LS6d -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid'
TRAPDOPTS='-LS6d -p /var/run/snmptrapd.pid'

going from -Lsd to -LS6d lowers the debug level sent to syslog. Refer to 
Logging Options section in snmpcmd manpage for more information.

-chris zubrzycki
- --
PGP public key: http://homepage.mac.com/beren/publickey.txt
ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070
_
This message is encoded using the Rot-26 encoding method.  Unauthorized 
decoding of this message may result in extreme penalties under the DMCA.  These 
penalties include, but are not limited to: US$100,000 fine, life imprisonment, 
castration, death, limp hair, terminal halitosis, and amputation of the 
extremities.





PGP.sig
Description: This is a digitally signed message part

Bug#392778: dvd+rw-tools: fails to fluch cache on sony drive

[Chris Zubrzycki]

Package: dvd+rw-tools
Version: 7.0-1
Severity: grave
Justification: renders package unusable


My Sony DVD-700a fails to write to DVD-R discs with the latest
growisofs. It works fine with 6.1 still, so I've had to downgrade.

here is the transcript:

Executing 'mkisofs -dvd-video -V MYDVD MYDVD |
builtin_dd of=/dev/hdc obs=32k seek=0'
/dev/hdc: Current Write Speed is 4.9x1352KBps.
:-? resuming track#1 from LBA#17872
  0.22% done, estimate finish Fri Oct 13 13:58:45 2006
  0.44% done, estimate finish Fri Oct 13 11:30:48 2006
  0.66% done, estimate finish Fri Oct 13 10:38:56 2006
  0.88% done, estimate finish Fri Oct 13 10:13:05 2006
  1.10% done, estimate finish Fri Oct 13 10:15:43 2006
  1.32% done, estimate finish Fri Oct 13 10:09:56 2006
:-( unable to [EMAIL PROTECTED]: Input/output error
:-( write failed: Input/output error
/dev/hdc: flushing cache
:-( unable to FLUSH CACHE: Input/output error
:-[ SYNCHRONOUS FLUSH CACHE failed with SK=2h/ASC=04h/ACQ=01h]: Resource
temporarily unavailable

and dmesg:
hdc: irq timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hdc: DMA disabled
hdc: ATAPI reset complete
hdc: write_intr: bad interrupt reason 1
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.4-k7-evms
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages dvd+rw-tools depends on:
ii  libc6 2.3.6.ds1-5GNU C Library: Shared libraries
ii  libgcc1   1:4.1.1-15 GCC support library
ii  libstdc++64.1.1-15   The GNU Standard C++ Library v3
ii  mkisofs   4:2.01+01a03-5 Creates ISO-9660 CD-ROM filesystem

dvd+rw-tools recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#320081: xfsprogs: superblock offset overflows in verify_set_primary_sb

[Chris Zubrzycki]

Package: xfsprogs
Version: 2.6.28-1
Severity: important

line 813 of repair/sb.c needs a cast in order to prevent an overflow.

--- sb.c~   2005-07-26 17:21:33.0 -0400
+++ sb.c2004-02-05 17:46:32.0 -0500
@@ -810,7 +810,7 @@

if (current-index != sb_index)  {
*sb_modified = 1;
-   off = current-index * current-geo.sb_agblocks
+   off = (xfs_off_t)current-index * current-geo.sb_agblocks
* current-geo.sb_blocksize;
if (get_sb(sb, off, current-geo.sb_sectsize,
current-index) != XR_OK)

A bug was also filed with the xfs developers and should be fixed in cvs
promptly. This bug causes xfs_repair to fail on certain configurations.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.30-k7-evms
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages xfsprogs depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libreadline55.0-10   GNU readline and history libraries
ii  libuuid11.38-1   universally unique id library

xfsprogs recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#308107: blootbot: debconf can't connect after latest unstable update

[Chris Zubrzycki]

Package: blootbot
Version: 1.1.0-6
Severity: important

from blootbot.log

14:09.47 Loaded ircServers ircII.servers (1 servers)
14:09.47 Connecting to port 6667 of server irc.freenode.net ...
14:09.47   resolved to 217.172.187.182.
14:09.47 !WARN! PERL: Can't connect to irc.freenode.net:6667! at
/usr/share/perl5/Net/IRC.pm line 195
14:09.47 !ERROR! irc: conn was not created!defined!!!
14:09.47 IRC: ok, done one cycle of IRC servers; trying again.

Blootbot was able to connect fine before the last dist-upgrade.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.30-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages blootbot depends on:
ii  debconf   1.4.48 Debian configuration management sy
ii  libdbd-mysql-perl 2.9006-1   A Perl5 database interface to the 
ii  libdbi-perl   1.46-6 Perl5 database interface by Tim Bu
ii  libnet-irc-perl   0.75-4 IRC (Internet Relay Chat) interfac
ii  perl  5.8.4-8Larry Wall's Practical Extraction 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]