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

Re: handling util-vserver regression

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.


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

Reply to: