Hi release team, I have not received a response to my original email on this subject, I suspect because it may not have been sent out properly. I do not see my original message in the lists.debian.org debian-release archive, although I do see it archived in services such as gmane[0]... Anyways, its for the best, because since then new issues have showed up that further support uploading a new upstream release, specifically the critical RC bug #506949[1] which seems to be a result of backporting incomplete pieces, resulting in odd corner cases manifesting. As the work involved with either path is not trivial, I am hoping to get a hint from you about which way I should proceed first. Thanks, micah 0. http://permalink.gmane.org/gmane.linux.debian.devel.release/27027 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506949 * Micah Anderson <micah@riseup.net> [2008-11-14 16:00-0500]: > > Hi release team, > > As I mentioned in #debian-release, and reported by weasel in #505521, > the version of util-vserver that is currently scheduled to be shipped > with Lenny (0.30.216~r2772-4) has an unfortunate regression from the > etch version: namely that it does not support 2.6.27, whereas the > earlier version does. If previous versions worked with 2.6.27, what > broke to make it not work? Turns out that the snapshot I took of > upstream's pre-release SVN happened to pull at the point where upstream > had merged support for the first proposed PID namespace API, not soon > afterwards it was decided that things weren't going to be done that > way, so this was removed and replaced with a better way of doing > things. This means that I pulled the snapshot when it had the first PID > namespace API, but not the second. > > I believe that we froze before the second one was introduced, so the two > possibilities were to ship util-vserver with a version that supports > 2.6.26, but breaks 2.6.27, or not ship a version that supported > 2.6.26. Obviously, if we wanted to support Lenny kernels, we were going > to need to do the former, so thats what I did... > > So, now that 2.6.27 is released, and people are starting to use that, > they are noticing that util-vserver doesn't work with 2.6.27 and are > disappointed to hear that Lenny will not ship with a version that > doesn't have this regression. > > So, I have these options: > > 1. backporting the upstream changes to get support of 2.6.27, there are > a number of patches to get this to work, and I'm not exactly sure I know > which they are. This would result in a backport of software that has not > been tested by anyone. > > 2. bring the package up to HEAD, where it has had some testing by the > vserver community, will definitately support 2.6.27, incorporates the > additional patches that I've picked from upstream to solve various > RC-related things (which are already on their way to Lenny), but also > includes some unrelated commits (such as some python and other > stuff. Most of these I can disable in the ./configure line in > debian/rules by adding --without-python --disable-versioning) > > In my mind, the better path is to do #2, because I know that this > version would absolutely work, however my suspicion is that the delta > would be too large for the release team to accept. The problem is that > the smaller delta that would result from me doing #1 would be more prone > to problems and would be completely untested. > > So, as requested by Luk, I've attached the diff to this email that would > accomplish #2 and I am wondering which would be the better path to > proecede on in order to get this into Lenny. > > As you will see in the patch below, there are some changes in there were > I remove dpatches that are taken care of by upstream, they added various > python and other stuff that would be disabled in the ./configure lines > that I added, there are some redhat/rpm related changes that wouldn't > bother us, and they added their GPL in their COPYING file, which was > previously empty... and finally the patches that are necesary to get the > 2.6.27 support to work again (which aren't trivial themselves). Here it > is: (diff snipped to help get this through the list, see the gmane referenced URL for the full diff[0])
Attachment:
signature.asc
Description: Digital signature