Your message dated Wed, 18 Feb 2015 13:57:47 -0500 (EST) with message-id <alpine.gso.1.10.1502181356210.3...@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 ow...@bugs.debian.org immediately.) -- 778254: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778254 Debian Bug Tracking System Contact ow...@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!~zwie...@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!~nthyk...@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!~nthyk...@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!~nthyk...@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!~nthyk...@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!~nthyk...@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 ---
