Re: sid on openvz
On Fri, Dec 04, 2015 at 10:06:11AM +0100, Aurelien Jarno wrote: > The minimum required version in the glibc is something configurable at > build time (to some extents, the absolute minimum is 2.6.32 for glibc > 2.21). This configure how much compatibility glue is used to workaround > the missing syscalls. This compatibility glue is bloating the libc, and > usually also have bugs which triggers for old kernels, but also > sometimes for new kernels. For example recently someone wanted to push > the minimum version to 3.15 to fix an issue with pthread_cond_broadcast > on ARM. > > That's the reason why historically we have always required for a glibc > from release N, at least the kernel from release N-2. This means for > stretch, the kernel from wheezy, ie 3.2. Supporting bleeding edge > software with an archaic kernel is not something easy to do, and other > parts of the distribution simply don't, especially since the switch to > systemd. I haven't tested this myself, but apparently Arch works fine[1] on OpenVZ if the host kernel is up-to-date. The installation instructions don't seem to contain any OpenVZ specific steps, so probably they're already compiling their glibc using the broadest compatibility settings. Moreover, the OpenVZ developers seem to be keen to backporting features[2] required to run modern distributions, which makes sense when you consider that their 3.10 based product is still not ready. Maybe we can make this work after all? [1] https://wiki.archlinux.org/index.php/Virtual_Private_Server [2] https://bugs.openvz.org/browse/OVZ-6384 -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Re: sid on openvz
>>>>> "AJ" == Aurelien Jarno writes: AJ> If you consider Debian "stable" as too archaic, I am missing words to AJ> qualify a 2.6.32 kernel released in 2009. Prehistoric maybe? Indeed, but we don't have any choice there. And it isn't Linus' 2.6.32, its openvz's port of rh's port of 2.6.32. So it isn't as out of date as the main version number suggests. >> There should be a way to continue to use sid on these platforms. AJ> One solution is to use jessie plus backports. This will be supported up AJ> to at least May 2018, probably May 2020. I'm (slowly) switching my openvzs to that, but not being able ever to upgrade from jessie (and trusty for the U users, given that they've pulled 2.21 into xenial) is a problem, even with backports. AJ> The minimum required version in the glibc is something configurable at AJ> build time (to some extents, the absolute minimum is 2.6.32 for glibc AJ> 2.21). The ideal solution, then, would be a separate libc package compiled to work with openvz's kernel. Maybe called libc-openvz. And it would be great if apt could install it by default whenever it sees /proc/vz. This would be similar to the libc6-i686:i386, libc-xen and libc-pic packages (and any others that I missed). Given that it is already done for xen guests, it shouldn't be an issue also to do so for openvz guests. [Appologies for being slow to respond; 4.4-rc4 proved much less stable than rc3 on my workstation.] -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: sid on openvz
On 7 December 2015 at 14:50, Marco d'Itri wrote: > On Dec 07, Aurelien Jarno wrote: > >> Have there also backported recent glibc or systemd to these systems and >> do they support such a configuration? This is what we are talking about >> here. > The *hosts* still use Centos 6, but so far more recent guests releases, > even using systemd, are working fine. > Well, for some value of work... Systemd doesn't get cgroups empty notifications in such containers and doesn't clean up cgroups for exited processes. I wonder, if uncleaned up cgroups in systemd tree can cause problems or not. -- Regards, Dimitri.
Re: sid on openvz
On Dec 07, Aurelien Jarno wrote: > Have there also backported recent glibc or systemd to these systems and > do they support such a configuration? This is what we are talking about > here. The *hosts* still use Centos 6, but so far more recent guests releases, even using systemd, are working fine. -- ciao, Marco signature.asc Description: PGP signature
Re: sid on openvz
On 2015-12-05 08:33, Marco d'Itri wrote: > On Dec 03, James Cloos wrote: > > > Most openvz run on kernels based on 2.6.32, often with significant > > updates. These platforms are an important segment, given how affordable > > they are. And Debian "stable" is often too archaic for many needs which > > fit nicely on a small inexpensive server. > > > > There should be a way to continue to use sid on these platforms. > I agree. > > On Dec 04, Paul Wise wrote: > > > > The latest glibc update breaks most sid installs on (typically leased) > > > openvz platforms because it requires a newer kernel version that most > > > openvz vendors advertize. > > Is it possible for these vendors to switch to a newer version of Linux? > Not at this time, there is just no viable replacement: I expect that > it will take a few years for the replacement to mature to the level of > the current 2.6.32 OpenVZ/Virtuozzo kernel. > (The problem is not just implementing the virtualization features with > namespaces but also replacing the resources accounting system.) > > On Dec 04, Vincent Danjean wrote: > > > Perhaps they will be more willing to do it when consumers wont be able > > to install the distribution they want on their VM. > As an hosting provider I can say with some authority that this is not > how it works: nobody is going to replace their OpenVZ/Virtuozzo > infrastructure just because newer Debian releases will not work: they > will just stop supporting newer Debian releases until they will switch > to namespaces-based virtualization (2-5 years?). > > On Dec 04, Aurelien Jarno wrote: > > > If you consider Debian "stable" as too archaic, I am missing words to > > qualify a 2.6.32 kernel released in 2009. Prehistoric maybe? > Unlike Debian, Red Hat keeps backporting new features in the kernels > used by their stable distributions and then will support security fixes > for a very long time. So these kernels are not in any way comparable to > the Debian 2.6.32 ones. Have there also backported recent glibc or systemd to these systems and do they support such a configuration? This is what we are talking about here. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: sid on openvz
On Dec 03, James Cloos wrote: > Most openvz run on kernels based on 2.6.32, often with significant > updates. These platforms are an important segment, given how affordable > they are. And Debian "stable" is often too archaic for many needs which > fit nicely on a small inexpensive server. > > There should be a way to continue to use sid on these platforms. I agree. On Dec 04, Paul Wise wrote: > > The latest glibc update breaks most sid installs on (typically leased) > > openvz platforms because it requires a newer kernel version that most > > openvz vendors advertize. > Is it possible for these vendors to switch to a newer version of Linux? Not at this time, there is just no viable replacement: I expect that it will take a few years for the replacement to mature to the level of the current 2.6.32 OpenVZ/Virtuozzo kernel. (The problem is not just implementing the virtualization features with namespaces but also replacing the resources accounting system.) On Dec 04, Vincent Danjean wrote: > Perhaps they will be more willing to do it when consumers wont be able > to install the distribution they want on their VM. As an hosting provider I can say with some authority that this is not how it works: nobody is going to replace their OpenVZ/Virtuozzo infrastructure just because newer Debian releases will not work: they will just stop supporting newer Debian releases until they will switch to namespaces-based virtualization (2-5 years?). On Dec 04, Aurelien Jarno wrote: > If you consider Debian "stable" as too archaic, I am missing words to > qualify a 2.6.32 kernel released in 2009. Prehistoric maybe? Unlike Debian, Red Hat keeps backporting new features in the kernels used by their stable distributions and then will support security fixes for a very long time. So these kernels are not in any way comparable to the Debian 2.6.32 ones. -- ciao, Marco signature.asc Description: PGP signature
Re: sid on openvz
On Fri, 2015-12-04 at 14:04 -0800, Steve Langasek wrote: > Hi Aurélien, > > On Fri, Dec 04, 2015 at 10:06:11AM +0100, Aurelien Jarno wrote: > > On 2015-12-03 17:33, James Cloos wrote: > > > The latest glibc update breaks most sid installs on (typically leased) > > > openvz platforms because it requires a newer kernel version that most > > > openvz vendors advertize. > > > > Most openvz run on kernels based on 2.6.32, often with significant > > > updates. These platforms are an important segment, given how affordable > > > they are. And Debian "stable" is often too archaic for many needs which > > > fit nicely on a small inexpensive server. > > > If you consider Debian "stable" as too archaic, I am missing words to > > qualify a 2.6.32 kernel released in 2009. Prehistoric maybe? > > I was going to write something similar, with references to what other > distributions are shipping; but in the course of investigating, I found that > RHEL7 and SLES11 both shipped 2.6.32 kernels that are supported until 2020 > and 2019 respectively. [...] RHEL 6 has 2.6.32 (with about 10,000 patches on top); RHEL 7 has 3.10 (although I've heard that it's closer to 3.12). SLES11 SP1 had 2.6.32, but later service packs updated the kernel to 3.0 and I don't believe SP1 is really supported any more. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: sid on openvz
Hi Aurélien, On Fri, Dec 04, 2015 at 10:06:11AM +0100, Aurelien Jarno wrote: > On 2015-12-03 17:33, James Cloos wrote: > > The latest glibc update breaks most sid installs on (typically leased) > > openvz platforms because it requires a newer kernel version that most > > openvz vendors advertize. > > Most openvz run on kernels based on 2.6.32, often with significant > > updates. These platforms are an important segment, given how affordable > > they are. And Debian "stable" is often too archaic for many needs which > > fit nicely on a small inexpensive server. > If you consider Debian "stable" as too archaic, I am missing words to > qualify a 2.6.32 kernel released in 2009. Prehistoric maybe? I was going to write something similar, with references to what other distributions are shipping; but in the course of investigating, I found that RHEL7 and SLES11 both shipped 2.6.32 kernels that are supported until 2020 and 2019 respectively. I don't think you have any obligation to support sid chroots on top of these OSes - it still runs on the oldest supported Ubuntu LTS release, so that's fine with me ;) - but I thought it was a fact worth mentioning. Yes, these kernels are archaic, but they're (unfortunately) not obsolete in all contexts. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: sid on openvz
Le 04/12/2015 07:06, Paul Wise a écrit : > On Fri, Dec 4, 2015 at 6:33 AM, James Cloos wrote: > >> The latest glibc update breaks most sid installs on (typically leased) >> openvz platforms because it requires a newer kernel version that most >> openvz vendors advertize. > > Is it possible for these vendors to switch to a newer version of Linux? Perhaps they will be more willing to do it when consumers wont be able to install the distribution they want on their VM. In France, a big hosting entreprise (OVH) offers virtual hosts for 2€ / month. These are VM on an old linux OpenVZ: $ uname -r 2.6.32-042stab111.12 I'm not sure when/if this offer will be upgraded. Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: sid on openvz
On 2015-12-03 17:33, James Cloos wrote: > The latest glibc update breaks most sid installs on (typically leased) > openvz platforms because it requires a newer kernel version that most > openvz vendors advertize. > > Most openvz run on kernels based on 2.6.32, often with significant > updates. These platforms are an important segment, given how affordable > they are. And Debian "stable" is often too archaic for many needs which > fit nicely on a small inexpensive server. If you consider Debian "stable" as too archaic, I am missing words to qualify a 2.6.32 kernel released in 2009. Prehistoric maybe? > There should be a way to continue to use sid on these platforms. > > Adding a hold on libc6 only causes other problems, since so much now > depends on 2.21 and apt will drop them if libc6 is held on 2.19. > > Is there another option to avoid the breakage? One solution is to use jessie plus backports. This will be supported up to at least May 2018, probably May 2020. The minimum required version in the glibc is something configurable at build time (to some extents, the absolute minimum is 2.6.32 for glibc 2.21). This configure how much compatibility glue is used to workaround the missing syscalls. This compatibility glue is bloating the libc, and usually also have bugs which triggers for old kernels, but also sometimes for new kernels. For example recently someone wanted to push the minimum version to 3.15 to fix an issue with pthread_cond_broadcast on ARM. That's the reason why historically we have always required for a glibc from release N, at least the kernel from release N-2. This means for stretch, the kernel from wheezy, ie 3.2. Supporting bleeding edge software with an archaic kernel is not something easy to do, and other parts of the distribution simply don't, especially since the switch to systemd. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: sid on openvz
> Is it possible for these vendors to switch to a newer version of Linux? A new version of OpenVZ based on the RHEL 7 kernel (3.10) is being developed but isn't expected soon unfortunately. This led the Proxmox team to replace OpenVZ with LXC for its containers. Emmanuel Bourg
Re: sid on openvz
On Fri, Dec 4, 2015 at 6:33 AM, James Cloos wrote: > The latest glibc update breaks most sid installs on (typically leased) > openvz platforms because it requires a newer kernel version that most > openvz vendors advertize. Is it possible for these vendors to switch to a newer version of Linux? -- bye, pabs https://wiki.debian.org/PaulWise
sid on openvz
The latest glibc update breaks most sid installs on (typically leased) openvz platforms because it requires a newer kernel version that most openvz vendors advertize. Most openvz run on kernels based on 2.6.32, often with significant updates. These platforms are an important segment, given how affordable they are. And Debian "stable" is often too archaic for many needs which fit nicely on a small inexpensive server. There should be a way to continue to use sid on these platforms. Adding a hold on libc6 only causes other problems, since so much now depends on 2.21 and apt will drop them if libc6 is held on 2.19. Is there another option to avoid the breakage? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: OpenVZ
On 10/25/2013 12:30 AM, Ben Hutchings wrote: > On Thu, 2013-10-24 at 22:16 +0800, Thomas Goirand wrote: >> On 10/24/2013 06:46 PM, Ben Hutchings wrote: >>> On Thu, 2013-10-24 at 11:59 +0200, Adam Borowski wrote: >>>> On Thu, Oct 24, 2013 at 09:11:30AM +0100, Jonathan Dowland wrote: >>>>> On Thu, Oct 24, 2013 at 02:09:46AM +0200, Adam Borowski wrote: >>>>>> And I for one heavily use vservers >>>>> >>>>> It's a professional shame of mine that we are still trying to get rid of >>>>> some old vserver instances at $WORK. >>>> >>>> lxc is still nowhere close to vserver (or openvz) functionality. >>> [...] >>> >>> I'm not sure whether that's still true, but anyway: OpenVZ is in >>> mainline Linux now. >> >> Oh, I'm surprised! I thought it would never get in, since we had LXC. > > The mainline implementation of containers, which is made up of multiple > types of control groups and namespaces, supports both LXC and OpenVZ > (and Google's resource control, and systemd-nspawn, and yet other > tools). > >> Thanks for sharing this info. How much of it is in? All of it? Or just a >> subset? > > James Bottomley of Parallels talked about this in Edinburgh and said > everything was in by 3.9. > >>> You'll need to wait for Linux 3.12 in Debian, as we >>> can't enable CONFIG_USER_NS before then >> >> What's that for? > > User namespaces, i.e. user IDs and capabilities (the privileges that > root normally has) in a container are distinguished from those in the > outer system. This is essential for virtual private servers. > > Every filesystem implementation needs to make this distinction and not > all of them were converted to do so before 3.12. > > Ben. I would very much welcome the return of OpenVZ in Debian via backports, when it's ready! Hoping that this may happen before the EOL of Squeeze, to assure continuity of production, for those using it. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526a0327.9020...@debian.org
Re: lxc / vserver / openvz (was: systemd flamage)
Quoting Adam Borowski (kilob...@angband.pl): > On Thu, Oct 24, 2013 at 03:40:04PM +0200, Marco d'Itri wrote: > > On Oct 24, Dmitrijs Ledkovs wrote: > > > > > What do you mean by "holding hostile root." ? > > http://blog.bofh.it/debian/id_413 > > > > The missing parts (UID virtualization IIRC) are upstream now, and should > > be ready for jessie. > > If I read Ubuntu documentation correctly, you also need a large complex > apparmor policy to block sensitive /proc and /sys files from being messed > with by guest systems. vserver does this internally based on its system > of capability bits. It also censors misc syscalls; I can't seem to find > this part being done by lxc. > > > Until then if you do not trust containers then the best choice is to > > use openvz with Parallel's 2.6.32 kernel. > > As Ben Hutchings just told us, openvz has been merged upstream in 3.12. The openvz and container communities worked together on the kernel features. vzctl has been updated to use the kernel features that were upstream-acceptable. So 'openvz has been merged upstream' is technically false, as it implies that the patches as they stood were merged. But openvz developers played a huge part in what made it upstream. -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131024165316.GB2226@ac100
Re: OpenVZ (was: systemd effectively mandatory now due to GNOME)
On Thu, 2013-10-24 at 22:16 +0800, Thomas Goirand wrote: > On 10/24/2013 06:46 PM, Ben Hutchings wrote: > > On Thu, 2013-10-24 at 11:59 +0200, Adam Borowski wrote: > >> On Thu, Oct 24, 2013 at 09:11:30AM +0100, Jonathan Dowland wrote: > >>> On Thu, Oct 24, 2013 at 02:09:46AM +0200, Adam Borowski wrote: > >>>> And I for one heavily use vservers > >>> > >>> It's a professional shame of mine that we are still trying to get rid of > >>> some old vserver instances at $WORK. > >> > >> lxc is still nowhere close to vserver (or openvz) functionality. > > [...] > > > > I'm not sure whether that's still true, but anyway: OpenVZ is in > > mainline Linux now. > > Oh, I'm surprised! I thought it would never get in, since we had LXC. The mainline implementation of containers, which is made up of multiple types of control groups and namespaces, supports both LXC and OpenVZ (and Google's resource control, and systemd-nspawn, and yet other tools). > Thanks for sharing this info. How much of it is in? All of it? Or just a > subset? James Bottomley of Parallels talked about this in Edinburgh and said everything was in by 3.9. > > You'll need to wait for Linux 3.12 in Debian, as we > > can't enable CONFIG_USER_NS before then > > What's that for? User namespaces, i.e. user IDs and capabilities (the privileges that root normally has) in a container are distinguished from those in the outer system. This is essential for virtual private servers. Every filesystem implementation needs to make this distinction and not all of them were converted to do so before 3.12. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part
Re: lxc / vserver / openvz (was: systemd flamage)
On Thu, Oct 24, 2013 at 03:40:04PM +0200, Marco d'Itri wrote: > On Oct 24, Dmitrijs Ledkovs wrote: > > > What do you mean by "holding hostile root." ? > http://blog.bofh.it/debian/id_413 > > The missing parts (UID virtualization IIRC) are upstream now, and should > be ready for jessie. If I read Ubuntu documentation correctly, you also need a large complex apparmor policy to block sensitive /proc and /sys files from being messed with by guest systems. vserver does this internally based on its system of capability bits. It also censors misc syscalls; I can't seem to find this part being done by lxc. > Until then if you do not trust containers then the best choice is to > use openvz with Parallel's 2.6.32 kernel. As Ben Hutchings just told us, openvz has been merged upstream in 3.12. Interestingly, that bit (CONFIG_USER_NS) just happens to be the same thing the blog post you pointed to described as the main problem that needs to be solved for lxc. Let's see how complete this is in practice. So far, vserver works for me but upstreamed stuff has obvious upsides. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131024144435.ga19...@angband.pl
Re: OpenVZ (was: systemd effectively mandatory now due to GNOME)
On 10/24/2013 06:46 PM, Ben Hutchings wrote: > On Thu, 2013-10-24 at 11:59 +0200, Adam Borowski wrote: >> On Thu, Oct 24, 2013 at 09:11:30AM +0100, Jonathan Dowland wrote: >>> On Thu, Oct 24, 2013 at 02:09:46AM +0200, Adam Borowski wrote: >>>> And I for one heavily use vservers >>> >>> It's a professional shame of mine that we are still trying to get rid of >>> some old vserver instances at $WORK. >> >> lxc is still nowhere close to vserver (or openvz) functionality. > [...] > > I'm not sure whether that's still true, but anyway: OpenVZ is in > mainline Linux now. Oh, I'm surprised! I thought it would never get in, since we had LXC. Thanks for sharing this info. How much of it is in? All of it? Or just a subset? > You'll need to wait for Linux 3.12 in Debian, as we > can't enable CONFIG_USER_NS before then What's that for? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52692bcc.1080...@debian.org
Re: openvz, was: Re: Bug#672695: wordpress: no sane way for security updates in stable releases
On Mon, May 14, 2012 at 04:37:23PM +0200, Toni Mueller wrote: > > This reminds me: is anyone going to bring back vserver or openvz in some > > I'm for having openvz back, then. Are you ready to do the required work? > Can we have this in a separate thread, please? Do we have any practical results to discuss there? -- WBR, wRAR signature.asc Description: Digital signature
openvz, was: Re: Bug#672695: wordpress: no sane way for security updates in stable releases
On Mon, May 14, 2012 at 04:23:27PM +0200, Adam Borowski wrote: > This reminds me: is anyone going to bring back vserver or openvz in some I'm for having openvz back, then. Can we have this in a separate thread, please? Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514143723.gb8...@spruce.wiehl.oeko.net
Re: OpenVZ - deb-packages
On Wed, 14 Oct 2009, maximilian attems wrote: > I'm taking care of openvz, please file a bug report with severity > important including the patch or link to patch, so that it can be added. Will do. > if it does not break ABI it is easiest to add to next stable release, > if it does i'll add it to the queued ABI breaking patches. > did you test that? No, I had to change the abiname anyway as I wanted different package names for the target derivative distribution to avoid unwanted cross-upgrades. How can I test that ? Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: OpenVZ - deb-packages
On Wed, Oct 14, 2009 at 02:00:28PM +0200, Raphael Hertzog wrote: > Hi, > > On Wed, 14 Oct 2009, Dmitry E. Oboukhov wrote: > > I need OpenVZ 2.6.27 with ppp-features available. I was on the > > point of building the package, but I am not very good in building > > of kernels and the current openvz is built somehow strange: > > apt-get source linux-image-2.6.26-2-openvz-686 gets an src-package > > with no mentions of openvz in debian/control in it. > > Kernel packages are special: > http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage > > > 1. Have I understood correctly that openvz doesn't have its own Source > > in Debian now and it is simply added/removed from linux-source as the > > need arises? How should I act and with whom should I communicate if I > > want to add something to the package? > > The main source is the linux-2.6 source package. You should talk to its > maintainers (people reachable on debian-ker...@lists.debian.org). > > > 2. May be somebody has already built openvz 2.6.27 (with ppp-features). > > Could You share the link on repository? > > I have built a 2.6.26 openvz kernel with the ppp support (a single > supplementary patch): > > The patch on the source package: > https://svn.ac-grenoble.fr/svn/slis/slis/sources/trunk/backports/patches/linux-2.6_2.6.26-15~slis41+1.patch > > The source package: > http://ftp.slis.fr/slis/pool/main/l/linux-2.6/linux-2.6_2.6.26-15~slis41+1.dsc > > The binary package: > http://ftp.slis.fr/slis/pool/main/l/linux-2.6/linux-image-2.6.26-slis.1-openvz-686_2.6.26-15~slis41+1_i386.deb > > I would like this patch to be added in a point release update given it's > only a supplementary feature in the -openvz kernel and should not disturb > anything else. But it's not in line with the traditional stable update > policy so I did not bother to propose it up to now. > > Dann, what's your stance on this ? I'm taking care of openvz, please file a bug report with severity important including the patch or link to patch, so that it can be added. if it does not break ABI it is easiest to add to next stable release, if it does i'll add it to the queued ABI breaking patches. did you test that? thanks + kind regards -- maks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: OpenVZ - deb-packages
Hi, On Wed, 14 Oct 2009, Dmitry E. Oboukhov wrote: > I need OpenVZ 2.6.27 with ppp-features available. I was on the > point of building the package, but I am not very good in building > of kernels and the current openvz is built somehow strange: > apt-get source linux-image-2.6.26-2-openvz-686 gets an src-package > with no mentions of openvz in debian/control in it. Kernel packages are special: http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage > 1. Have I understood correctly that openvz doesn't have its own Source > in Debian now and it is simply added/removed from linux-source as the > need arises? How should I act and with whom should I communicate if I > want to add something to the package? The main source is the linux-2.6 source package. You should talk to its maintainers (people reachable on debian-ker...@lists.debian.org). > 2. May be somebody has already built openvz 2.6.27 (with ppp-features). > Could You share the link on repository? I have built a 2.6.26 openvz kernel with the ppp support (a single supplementary patch): The patch on the source package: https://svn.ac-grenoble.fr/svn/slis/slis/sources/trunk/backports/patches/linux-2.6_2.6.26-15~slis41+1.patch The source package: http://ftp.slis.fr/slis/pool/main/l/linux-2.6/linux-2.6_2.6.26-15~slis41+1.dsc The binary package: http://ftp.slis.fr/slis/pool/main/l/linux-2.6/linux-image-2.6.26-slis.1-openvz-686_2.6.26-15~slis41+1_i386.deb I would like this patch to be added in a point release update given it's only a supplementary feature in the -openvz kernel and should not disturb anything else. But it's not in line with the traditional stable update policy so I did not bother to propose it up to now. Dann, what's your stance on this ? Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
OpenVZ - deb-packages
Hi all! I need OpenVZ 2.6.27 with ppp-features available. I was on the point of building the package, but I am not very good in building of kernels and the current openvz is built somehow strange: apt-get source linux-image-2.6.26-2-openvz-686 gets an src-package with no mentions of openvz in debian/control in it. I've also planned to finish the zsh-completions for vzctl for openVZ and to write a script using debootstrap for creating a guest system. However I haven't understood yet how the -openvz packages get into Debian. 1. Have I understood correctly that openvz doesn't have its own Source in Debian now and it is simply added/removed from linux-source as the need arises? How should I act and with whom should I communicate if I want to add something to the package? 2. May be somebody has already built openvz 2.6.27 (with ppp-features). Could You share the link on repository? -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
