[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#778254: marked as done (release.debian.org: jessie's new kernel breaks openafs-modules-dkms)

Your message dated Wed, 18 Feb 2015 13:57:47 -0500 (EST)
with message-id <alpine.GSO.1.10.1502181356210.3953@multics.mit.edu>
and subject line Re: release.debian.org: jessie's new kernel breaks openafs-modules-dkms
has caused the Debian Bug report #778254,
regarding release.debian.org: jessie's new kernel breaks openafs-modules-dkms
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
778254: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778254
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal

Bug #778196 was filed against openafs-modules-dkms to note that the
latest kernel to hit jessie (which was the unblock request in #776899)
causes the DKMS module to fail to build.  The new kernel introduced a
KPI change for accesses to the d_alias field of struct dentry, which must
now be made through the d_u union.

I updated openafs in sid to include upstream's patches for new linux support
(including the d_u change) when the new kernel hit sid, but that update
also included a new translation and several bugfixes of various severity.
Additionally, openafs in sid has a newer upstream version than openafs
in jessie, due to excessive optimism on my part in the lead up to freeze.
(It is also the case that nearly every upstream update for openafs includes
support for new linux versions, since the KPI is a moving target, so
I am used to having to pull in new upstream versions regularly.)

The version in jessie also does not have native systemd support, and it
remains unclear whether the systemd sysv compat is causing problems for
jessie users that native unit files could resolve (#760063) -- for at
least some users, the issue seems to have mysteriously gone away but
there is no openafs or systemd change which obviously should have resolved
things.

The question is, how should we resolve the situation for jessie?  It
seems like the most likely answer is a minimal patch uploaded to
testing-proposed-updates, but I wanted to ask the release team whether
there were other options, such as unblocking the openafs currently in
sid (even though it is a new upstream version).

It is probably worth noting that openafs is a leaf package.

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

--- End Message ---
--- Begin Message --- 
>From IRC:

   oftc / #debian-release / kaduk_  14:28  ()
       Did I provide sufficient information in #778254 for the release-team to be able
       to give me guidance for what to do?
   oftc / #debian-release / zwiebelbot  14:28  (zwiebelbot!~zwiebel@zwiebel.bot.oftc.net
       Debian#778254: release.debian.org: jessie's new kernel breaks
       openafs-modules-dkms - https://bugs.debian.org/778254
   oftc / #debian-release / nthykier  14:29  (nthykier!~nthykier@cheddar.halon.org.uk)
       kaduk_: probably it is "TL;DR" - sadly that is a common problem for us these days
   oftc / #debian-release / kaduk_  14:30  ()
       Ah.  There's always too many things to do, I suppose.
   oftc / #debian-release / nthykier  14:34  (nthykier!~nthykier@cheddar.halon.org.uk)
       kaduk_: ok, the changes in the sid version are definitely "TL;DR" - I would be
       uncomfortable with unblocking that blob
   oftc / #debian-release / kaduk_  14:35  ()
       nthykier: okay, so I must to t-p-u as I suspected, then.
   oftc / #debian-release / kaduk_  14:36  ()
       And hope that there are no more KPI-breaking kernel security updates in the
       future.
   oftc / #debian-release / nthykier  14:36  (nthykier!~nthykier@cheddar.halon.org.uk)
       kaduk_: yes, I would strongly recommend going that route - though, there is a
       limit to what we accept via tpu.  If it is a sufficiently large changeset, we
       may request it being via sid (reverting the previous upload)
   oftc / #debian-release / kaduk_  14:37  ()
       nthykier: I think the smallest-scoped fix to just cope with the KPI change would
       be quite small, but would leave things in a more fragile state if there are
       further kernel updates in the future.
   oftc / #debian-release / nthykier  14:42  (nthykier!~nthykier@cheddar.halon.org.uk)
       kaduk_: and a "slightly" larger variant might be more robust?
   oftc / #debian-release / kaduk_  14:43  ()
       nthykier: I think so, but I would have to double-check.
   oftc / #debian-release / nthykier  14:44  (nthykier!~nthykier@cheddar.halon.org.uk)
       kaduk_: ok, feel free to propose both if the second one makes sense.  A t-p-u
       upload requires a review before upload anyway
   oftc / #debian-release / kaduk_  14:45  ()
       nthykier: *nods*.  Thanks!

--- End Message ---
Reply to: