Sync openafs 1.6.21-1 (universe) from Debian unstable (main)

$ syncpackage -b 1705850 -s andersk -f openafs
syncpackage: Source openafs -> artful/Proposed: current version 1.6.20-2ubuntu2, new version 1.6.21-1
syncpackage: New changes:
openafs (1.6.21-1) unstable; urgency=medium

  * New upstream release (1.6.21):
    - Include support for Linx versions through 4.12. (Closes: #859155)
    - Improve support for Linux kernels with backported patches.
      (Closes: #855366)
    - Improve bosserver startup behavior with unexpected arguments or
      configuration symlinks.
    - Re-enable vcache cleanup improvement from 1.6.18, with bugs fixed.
    - Provide the afsd -inumcalc option; this behavior was previously
      only configurable via sysctl.
    - The salvager updates volume "last update" times when modifying volumes.
    - Demand-attach fileserver improvements for reducing log spew and preventing
      thread exhaustion during CPS recalculation.
    - Avoid a potential 100ms transmit delay in RX when the peer's receive
      window advances.
  * Switch openafs-fileserver.service to Type=simple and pass -nofork to
    bosserver. (Closes: #865962)
  * Update for policy version 4.0.0, honor nodoc in DEB_BUILD_OPTIONS
  * Use service(8) instead of /etc/init.d/* directly in documentation and
    helper scripts

 -- Benjamin Kaduk <email address hidden> Mon, 10 Jul 2017 15:27:56 -0500
syncpackage: Sponsoring this sync for Anders Kaseorg (andersk)
Sync this package [y|N]? y
syncpackage: Request succeeded; you should get an e-mail once it is processed.
syncpackage: Launchpad bugs to be closed: 1705850
syncpackage: Please wait for the sync to be successful before closing bugs.

This sync is being held back due to an autopkgtest “regression” on armhf and s390x. The log makes it clear that’s because the test is being run in a chroot, which makes no sense for a test that involves building and loading a kernel module with dkms.

http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#openafs

Thanks for that info, I'll add a restriction to the test suite on Monday
and send it to Debian.

Nish: A restriction to what test suite? The Debian package does not have an autopkgtest suite to restrict. The autopkgtest is made up entirely by Ubuntu somewhere outside of the package itself. It has something to do with /usr/lib/dkms/dkms-autopkgtest, but I don’t know what runs that.

On 22.08.2017 [18:07:43 -0000], Anders Kaseorg wrote:
> Nish: A restriction to what test suite? The Debian package does not
> have an autopkgtest suite to restrict. The autopkgtest is made up
> entirely by Ubuntu somewhere outside of the package itself. It has
> something to do with /usr/lib/dkms/dkms-autopkgtest, but I don’t know
> what runs that.

You're right, sorry -- it would need to be in src:dkms (which is what
generates the dep8 tests for dkms packages). But the problem here is
that the tests did pass in the past on these architectures. I'm going to
see why they are failing now, if I can.

-Nish

On 22.08.2017 [18:07:43 -0000], Anders Kaseorg wrote:
> Nish: A restriction to what test suite? The Debian package does not
> have an autopkgtest suite to restrict. The autopkgtest is made up
> entirely by Ubuntu somewhere outside of the package itself. It has
> something to do with /usr/lib/dkms/dkms-autopkgtest, but I don’t know
> what runs that.

Ah so I think the issue (regression) is that before (1.6.20-2ubuntu2),
openafs-client successfully installed on s390x and armhf, but now it
fails as openafs-client's systemd unit fails to start:

  Process: 1381 ExecStart=/sbin/afsd $AFSD_ARGS (code=exited, status=1/FAILURE)

...

Aug 22 18:29:55 autopkgtest-lxd-oxnaed systemd[1]:
openafs-client.service: Co…=1
Aug 22 18:29:55 autopkgtest-lxd-oxnaed afsd[1381]: afsd: some file
missing or…fs
Aug 22 18:29:55 autopkgtest-lxd-oxnaed rmmod[1382]: kmod version 24
Aug 22 18:29:55 autopkgtest-lxd-oxnaed rmmod[1382]: -XZ -ZLIB
-EXPERIMENTAL

I will see if I can get on a s390x machine to reproduce it.

Aha, I think I’ve stared closely enough at the log this time to figure out the problem: debian/patches/0003-Add-dummy-exit-command-for-afsd-to-do-nothing.patch got broken in the 1.6.21 upload, so -exit no longer works. I’ll get this fixed in Debian.

@Andres, yep, that makes sense. For reference, here's the failure log from s390x:

Aug 22 21:29:04 adt-virt-lxd-jcekjq openafs-client-precheck[4503]: modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0
Aug 22 21:29:04 adt-virt-lxd-jcekjq openafs-client-precheck[4503]: modprobe: FATAL: Module openafs not found in directory /lib/modules/4.4.0-87-generic
Aug 22 21:29:04 adt-virt-lxd-jcekjq openafs-client-precheck[4503]: Failed to load openafs.ko. Does it need to be built?
Aug 22 21:29:04 adt-virt-lxd-jcekjq openafs-client-precheck[4503]: grep: /lib/modules/4.4.0-87-generic/modules.dep: No such file or directory
Aug 22 21:29:04 adt-virt-lxd-jcekjq afsd[4513]: setting rx priority: Permission denied
Aug 22 21:29:04 adt-virt-lxd-jcekjq afsd[4513]: afsd: Error -1 in basic initialization.
Aug 22 21:29:04 adt-virt-lxd-jcekjq afsd[4513]: setting rx priority: Permission denied
Aug 22 21:29:04 adt-virt-lxd-jcekjq systemd[1]: openafs-client.service: Control process exited, code=exited status=1
Aug 22 21:29:04 adt-virt-lxd-jcekjq rmmod[4517]: kmod version 24
Aug 22 21:29:04 adt-virt-lxd-jcekjq rmmod[4517]: -XZ -ZLIB -EXPERIMENTAL
Aug 22 21:29:04 adt-virt-lxd-jcekjq systemd[1]: Failed to start OpenAFS client.
-- Subject: Unit openafs-client.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- Unit openafs-client.service has failed.
--
-- The result is failed.
Aug 22 21:29:04 adt-virt-lxd-jcekjq systemd[1]: openafs-client.service: Unit entered failed state.
Aug 22 21:29:04 adt-virt-lxd-jcekjq systemd[1]: openafs-client.service: Failed with result 'exit-code'.

Err, *@Anders, sorry!

I just uploaded 1.6.21-2 to Debian; I’ll file a sync request as soon as that goes through.

Nish: As long as you have an s390x machine to get unellipsized failure logs from, would you be able take a look at the other ADT failure we’re seeing in openafs-fileserver (bug 1704156)?

On Aug 22, 2017 17:16, "Anders Kaseorg" <email address hidden> wrote:

I just uploaded 1.6.21-2 to Debian; I’ll file a sync request as soon as
that goes through.

Excellent! I think since it is already synced (even if not migrated) it
will automatically sync again until the import freeze on the 24th.

Nish: As long as you have an s390x machine to get unellipsized failure
logs from, would you be able take a look at the other ADT failure we’re
seeing in openafs-fileserver (bug 1704156)?

Sure will do it first thing tomorrow and report back in that bug!

New sync request: bug 1712452.

The sync will not be automatic because of the intervening 1.6.21-1ubuntu1 upload on Friday.