[Bug 1324288] [NEW] Please backport openafs 1.6.7-1 (universe) from trusty for HWE enabled systems to work correctly.

[Rafael David Tinoco]

*** This bug is a duplicate of bug 1206387 ***
    https://bugs.launchpad.net/bugs/1206387

Public bug reported:

Please backport openafs 1.6.7-1 (universe) from trusty to precise so
dkms module can be built correctly on HWE enabled systems. Cherry-
picking changes from 1.6.5 to precise version, 1.6.1, will result in a
nonviable RSU (like Steve Langasek - vorlon - said in the launchpad
opened bug LP #1206387).

Reason for the backport:
========================

Main reason: Several requests from users/customers for this backport (LP
#1206387).

After fixing some wrongly auto-generated includes, I could see that
there were 2 approaches for bringing 1.6.5 behavior to 1.6.1:

1) Remove "STRUCT_TASK_STRUCT_HAS_CRED" define. Autotools is correctly
checking for the existence of a "credentials" structure inside
task_struct (kernel). Since newer kernels (3.x) have this structure, the
code defines STRUCT_TASK_STRUCT_HAS_CRED variable and starts accessing
all credential variables directly from kernel defined structures
(includes). Removing this would make openafs behave like it used to in
the past (older kernels from 2.6.x) and would imply fixing all
"current_task"->cred structure (changing upstream code on that specific
version). Of course, after this, even more changes would be expected.

-> not a good approach

2) Cherry-pick code from 1.6.5 to 1.6.1. There are 398 commits between
this two versions and, taking in consideration only dkms module, this
could be a reasonable direction. The problem is that since there are a
huge amount of changes in the kernel structures for process, sched,
security (between v3.2 and v3.11) the changes wouldn't be acceptable on
SRU.

Some of needed changes would be: dentry_open new prototype, kmap_atomic
new prototype, vmtruncated deprecated, task_struct cred session_keyring
location, new proc_create function on module, and so on...

-> not a good approach also

IMHO backporting OpenAFS from trusty to precise (-backports) would be
the best in this case and probably meet with customers/users
requirement/expectation (just like Micheal pointed out).

Testing:
========
Mark off items in the checklist [X] as you test them, but please leave the checklist so that backporters can quickly evaluate the state of testing.

You can test-build the backport in your PPA with backportpackage:
$ backportpackage -u ppa:<lp username>/<ppa name> -s trusty -d precise openafs

- ppa:inaddy/lp1206387
- lp #1206387 - pkg source

* precise:
[!] Package builds without modification
[x] openafs-client installs cleanly and runs
[x] libafsauthent1 installs cleanly and runs
[x] openafs-doc installs cleanly and runs
[x] openafs-dbserver installs cleanly and runs
[x] openafs-dbg installs cleanly and runs
[x] openafs-modules-dkms installs cleanly and runs
[x] openafs-fileserver installs cleanly and runs
[x] libpam-openafs-kaserver installs cleanly and runs
[x] libopenafs-dev installs cleanly and runs
[x] openafs-krb5 installs cleanly and runs
[x] libkopenafs1 installs cleanly and runs
[x] openafs-kpasswd installs cleanly and runs
[x] libafsrpc1 installs cleanly and runs
[x] openafs-modules-source installs cleanly and runs
[x] openafs-fuse installs cleanly and runs

!debian/control modification:

- Build-Depends: debhelper (>= 9), autoconf, automake, bison, comerr-dev,
-  cpio, flex, hardening-wrapper, libfuse-dev, libkrb5-dev, libncurses5-dev,
-  libpam0g-dev, libxml2-utils, perl, pkg-config
- Build-Depends-Indep: dblatex, dkms (>= 2.1.1.1), docbook-xsl, doxygen,
-  xsltproc

+ Build-Depends: debhelper (>= 9), autoconf, automake, bison, comerr-dev,
+  cpio, flex, hardening-wrapper, libfuse-dev, libkrb5-dev, libncurses5-dev,
+  libpam0g-dev, libxml2-utils, perl, pkg-config, dblatex, dkms (>= 2.1.1.1),
+  docbook-xsl, doxygen, xsltproc

Reverse dependencies:
=====================
The following reverse-dependencies need to be tested against the new version of openafs. For reverse-build-dependencies (-Indep), please test that the package still builds against the new openafs. For reverse-dependencies, please test that the version of the package currently in the release still works with the new openafs installed. Reverse- Recommends, Suggests, and Enhances don't need to be tested, and are listed for completeness-sake.

openafs-client
--------------
* heimdal-clients
  [ ] precise (Reverse-Conflicts)
* libpam-afs-session
  [ ] precise (Reverse-Recommends)

libafsauthent1
--------------

openafs-doc
-----------

openafs-dbserver
----------------

openafs-dbg
-----------

openafs-modules-dkms
--------------------

openafs-fileserver
------------------

libpam-openafs-kaserver
-----------------------

libopenafs-dev
--------------

openafs-krb5
------------
* libpam-afs-session
  [ ] precise (Reverse-Recommends)

libkopenafs1
------------

openafs-kpasswd
---------------

libafsrpc1
----------

openafs-modules-source
----------------------

openafs-fuse
------------

** Affects: precise-backports
     Importance: Undecided
         Status: New

** This bug has been marked a duplicate of bug 1206387
   openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to Precise Backports.
https://bugs.launchpad.net/bugs/1324288

Title:
  Please backport openafs 1.6.7-1 (universe) from trusty for HWE enabled
  systems to work correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/precise-backports/+bug/1324288/+subscriptions