Re: openafs in etchnhalf
On Tue, Jun 17, 2008 at 12:47:38PM -0700, Russ Allbery wrote: dann frazier [EMAIL PROTECTED] writes: If I understand this correctly, that would mean that etch users would be forced to move to the new module code, right?. I don't doubt that it would work just fine, but objective #1 is to minimize risk to existing etch users. Yes, that's true. Alternately, we could provide an openafs-modules-source-etchnhalf package that conflicts and replaces openafs-modules-source, although that seems a little weird to me. Why would it need to conflict replace? Could they install into separate locations? All that's in the package is a tarball in /usr/src (it's the standard module build pattern). If it were called something other than openafs.tar.gz or expanded into a different directory, wouldn't that confuse tools like module-assistant? True. I tried to come up with some clever ways of manipulating m-a to do the right thing, but didn't come up with anything great. One option might be to populate a subdirectory of /usr/src - e.g. /usr/src/etchnhalf and ask users to set the MODULE_LOC variable? Not ideal, but it might work (haven't tested it). I should also note that the stable release team is aiming for a 4.0r4 real soon, and that is the planned vehicle for etch and a half so there's not much time left to get new packages in - maybe already too late. If there's enough interest, it might be worth looking into doing a set in a future point release. Either way, it would be good to know how to do it. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openafs in etchnhalf
dann frazier [EMAIL PROTECTED] writes: True. I tried to come up with some clever ways of manipulating m-a to do the right thing, but didn't come up with anything great. One option might be to populate a subdirectory of /usr/src - e.g. /usr/src/etchnhalf and ask users to set the MODULE_LOC variable? Not ideal, but it might work (haven't tested it). I should also note that the stable release team is aiming for a 4.0r4 real soon, and that is the planned vehicle for etch and a half so there's not much time left to get new packages in - maybe already too late. If there's enough interest, it might be worth looking into doing a set in a future point release. Either way, it would be good to know how to do it. I'm certainly happy to follow whatever standard that people arrive at that works, but unfortunately I don't have a lot of time to try to help propose and develop the standard and test the implications. It may end up being somewhat moot anyway since we have at least one report that a new kernel module does indeed require a new openafs-client -- I'm going to check with upstream about that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openafs in etchnhalf
Russ, Am Dienstag, 17. Juni 2008 schrieb Russ Allbery: The only relevant part of the openafs package affected is the openafs-modules-source arch: all package. I'm fairly sure (although would need to test) that installing a new kernel module built from the lenny openafs-modules-source package will work fine with an openafs-client package from the current etch. (Sometimes there are mismatches between afsd and the kernel, but I don't think any have happened since etch.) So we could add to etchnhalf a new openafs-modules-source source package that supersedes the binary package built from the openafs source package, although I don't know how confused that would make dak (particularly if we have to do a security update of openafs). This is worthwile double checking. I recently run with a backports kernel, openafs-client from etch and openafs-modules-source from backports and I got many kernel Oops. Switching to the etchnhalf kernel and the openafs modules and openafs-client from backports solved the problem for me. Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openafs in etchnhalf
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Rainer Dorsch [EMAIL PROTECTED] writes: is anybody taking care of the openafs modules which do not compile any more with the etchnhalf kernel? The openafs modules in backports.org do compile though with the etchnhalf kernel. Russ I'm quite happy to upload new packages for etchnhalf, but Russ I'm afraid they'd have to be just that -- packages of a Russ newer upstream. The upstream changes to support newer Russ kernels are far too comprehensive for me to be able to Russ isolate them and apply them separately, and the result would Russ be poorly-tested and less stable than going to the current Russ packages from Debian testing. What about uploading an openafs-kernel source package that only produced openafs-modules-source? That would at least isolate the change to the kernel module. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openafs in etchnhalf
Rainer Dorsch [EMAIL PROTECTED] writes: is anybody taking care of the openafs modules which do not compile any more with the etchnhalf kernel? The openafs modules in backports.org do compile though with the etchnhalf kernel. I'm quite happy to upload new packages for etchnhalf, but I'm afraid they'd have to be just that -- packages of a newer upstream. The upstream changes to support newer kernels are far too comprehensive for me to be able to isolate them and apply them separately, and the result would be poorly-tested and less stable than going to the current packages from Debian testing. So... I guess my question is, what is the policy for etchnhalf for packages that involve kernel modules? Is it fair game to upload a new upstream version, unlike the normal stable release policies? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openafs in etchnhalf
dann frazier [EMAIL PROTECTED] writes: On Tue, Jun 17, 2008 at 10:48:45AM -0700, Russ Allbery wrote: I'm quite happy to upload new packages for etchnhalf, but I'm afraid they'd have to be just that -- packages of a newer upstream. The upstream changes to support newer kernels are far too comprehensive for me to be able to isolate them and apply them separately, and the result would be poorly-tested and less stable than going to the current packages from Debian testing. So... I guess my question is, what is the policy for etchnhalf for packages that involve kernel modules? Is it fair game to upload a new upstream version, unlike the normal stable release policies? I think the answer would have to be creating a *new* package (e.g., openafs-source-etchnhalf) that can be installed next to the existing etch package. Otherwise we risk introducing regressions w/ the 2.6.18 kernel. True, although upstream does continue to test with older kernels, so I'm not *too* worried. But the risk is there. The only relevant part of the openafs package affected is the openafs-modules-source arch: all package. I'm fairly sure (although would need to test) that installing a new kernel module built from the lenny openafs-modules-source package will work fine with an openafs-client package from the current etch. (Sometimes there are mismatches between afsd and the kernel, but I don't think any have happened since etch.) So we could add to etchnhalf a new openafs-modules-source source package that supersedes the binary package built from the openafs source package, although I don't know how confused that would make dak (particularly if we have to do a security update of openafs). Alternately, we could provide an openafs-modules-source-etchnhalf package that conflicts and replaces openafs-modules-source, although that seems a little weird to me. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openafs in etchnhalf
On Tue, Jun 17, 2008 at 10:48:45AM -0700, Russ Allbery wrote: Rainer Dorsch [EMAIL PROTECTED] writes: is anybody taking care of the openafs modules which do not compile any more with the etchnhalf kernel? The openafs modules in backports.org do compile though with the etchnhalf kernel. I'm quite happy to upload new packages for etchnhalf, but I'm afraid they'd have to be just that -- packages of a newer upstream. The upstream changes to support newer kernels are far too comprehensive for me to be able to isolate them and apply them separately, and the result would be poorly-tested and less stable than going to the current packages from Debian testing. So... I guess my question is, what is the policy for etchnhalf for packages that involve kernel modules? Is it fair game to upload a new upstream version, unlike the normal stable release policies? I think the answer would have to be creating a *new* package (e.g., openafs-source-etchnhalf) that can be installed next to the existing etch package. Otherwise we risk introducing regressions w/ the 2.6.18 kernel. I also would think that we'd want to provide an upgrade path in lenny that upgrades the etchnhalf specific package to the openafs-source (or whatever) in lenny - but there maybe reasons not to do this. I believe Daniel was working on a plan for this at one point, maybe he has a suggestion? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openafs in etchnhalf
On Tue, Jun 17, 2008 at 11:11:25AM -0700, Russ Allbery wrote: dann frazier [EMAIL PROTECTED] writes: On Tue, Jun 17, 2008 at 10:48:45AM -0700, Russ Allbery wrote: I'm quite happy to upload new packages for etchnhalf, but I'm afraid they'd have to be just that -- packages of a newer upstream. The upstream changes to support newer kernels are far too comprehensive for me to be able to isolate them and apply them separately, and the result would be poorly-tested and less stable than going to the current packages from Debian testing. So... I guess my question is, what is the policy for etchnhalf for packages that involve kernel modules? Is it fair game to upload a new upstream version, unlike the normal stable release policies? I think the answer would have to be creating a *new* package (e.g., openafs-source-etchnhalf) that can be installed next to the existing etch package. Otherwise we risk introducing regressions w/ the 2.6.18 kernel. True, although upstream does continue to test with older kernels, so I'm not *too* worried. But the risk is there. The only relevant part of the openafs package affected is the openafs-modules-source arch: all package. I'm fairly sure (although would need to test) that installing a new kernel module built from the lenny openafs-modules-source package will work fine with an openafs-client package from the current etch. (Sometimes there are mismatches between afsd and the kernel, but I don't think any have happened since etch.) So we could add to etchnhalf a new openafs-modules-source source package that supersedes the binary package built from the openafs source package, although I don't know how confused that would make dak (particularly if we have to do a security update of openafs). If I understand this correctly, that would mean that etch users would be forced to move to the new module code, right?. I don't doubt that it would work just fine, but objective #1 is to minimize risk to existing etch users. Alternately, we could provide an openafs-modules-source-etchnhalf package that conflicts and replaces openafs-modules-source, although that seems a little weird to me. Why would it need to conflict replace? Could they install into separate locations? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openafs in etchnhalf
dann frazier [EMAIL PROTECTED] writes: If I understand this correctly, that would mean that etch users would be forced to move to the new module code, right?. I don't doubt that it would work just fine, but objective #1 is to minimize risk to existing etch users. Yes, that's true. Alternately, we could provide an openafs-modules-source-etchnhalf package that conflicts and replaces openafs-modules-source, although that seems a little weird to me. Why would it need to conflict replace? Could they install into separate locations? All that's in the package is a tarball in /usr/src (it's the standard module build pattern). If it were called something other than openafs.tar.gz or expanded into a different directory, wouldn't that confuse tools like module-assistant? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
