Re: Unsupported packages for Wheezy LTS
Hi,
On Fri, May 13, 2016 at 09:54:21AM +0200, Raphael Hertzog wrote:
> Hi,
>
> On Thu, 12 May 2016, Guido Günther wrote:
> > I have maintained icedove a while ago and know the codebase a bit. I'm
> > also sure we might get support from the current maintainers as long as
> > we're able to build the ESR releases for wheezy - which is Debian's
> > standard way to deal with Firefox/Thundergbird security updates. I can
> > look into building icedove 31.8 for wheezy. I could also check if we can
> > build 45.x which would keep us covered for at least another year:
> >
> > https://www.mozilla.org/en-US/firefox/organizations/faq/
> >
> > So should we try to support ice{dove,weasel} at least for th3 45.x series?
>
> +1 from my side, even though we don't have any explicit support request
> from companies, it would really useful for end users and desktop
> deployments.
Icedove 45 went pretty well[1] so this looks doable. I'll put out packages
for testing as soon as we have a non beta in sid - Christoph and Carsten
(cc:ed) are looking into this).
We have firefox 45 in testing already so this will be next in case Mike
doesn't want to do it himself (see other mail).
Cheers,
-- Guido
[1] https://github.com/agx/icedove/tree/wheezy-lts
Re: Unsupported packages for Wheezy LTS
On Tue, May 17, 2016 at 12:13:29PM -0400, Antoine Beaupré wrote: > On 2016-05-13 09:00:59, Antoine Beaupré wrote: > > So if we're going to do this painful work, might as well maintain some > > qemu interface in wheezy as well. I am not sure I see what additional > > cost this would bring: although the attack surface is larger on qemu and > > Xen uses only some parts of the Qemu codebase, disclosed vulnerabilities > > concern mostly HVM support in Xen, and not the "unused from Xen" qemu > > codebase... > > > > But yeah, this seems exactly stuff that our sponsored Xen support team > > should look into. ;) > > Did anyone contact the sponsored xen support team yet? How *do* we > contact those folks anyways? > > An almost textbook example of the problems we're talking about here: > > http://xenbits.xen.org/xsa/advisory-179.html > > Was marked as EOL in wheezy, but completely ignored the fact that it is > a Xen advisory, and that Xen *is* vulnerable! I think this should not be marked EOL. Should we decide to not support QEMU (standalong) in Wheezy this does not mean we also won't support the embedded QEMU in XEN (since it's only a subset). These are separate things. > https://security-tracker.debian.org/CVE-2016-3712 > https://security-tracker.debian.org/CVE-2016-3710 > > I would be tempted to mark this as no-dsa in wheezy because in this > case, the default video mode is not vulnerable, but what should we do in > a case like this? If we do not support Qemu standalone, we probably > can't support Qemu in Xen either, which means parts of the Xen > functionality is not supported (HVM, for example). I read no-dsa as "does not warrant a dsa on its own but might be fixed in an upcoming upload" - so this would likely be the right status. > How do we inform our users that Xen is supported but HVM is not? Is that > a thing we do? We do support HVM XEN via the support we got on board for XEN - at least I've not heard/read anything that would support otherwise. Cheers, -- Guido
Re: Unsupported packages for Wheezy LTS
On Sat, May 14, 2016 at 09:11:17PM +0200, Moritz Mühlenhoff wrote: > On Fri, May 13, 2016 at 02:10:48PM +0200, Guido Günther wrote: > > > No, I recommend to EOL src:qemu/qemu-kvm in wheezy (the bits relevant to > > > src:xen are > > > somewhat isolated and can be backported from the Xen Security > > > announcements) > > > Backporting jessie's qemu will end up in a similar situation as the > > > experiments > > > with libav. > > > > I don't think so. We already have the version of Jessie in Wheezy > > backports and I've looked into the dependency list. See > > > > https://lists.debian.org/debian-lts/2016/04/msg2.html > > > > so this should be doable… > > But what would be the point of that? Upgrading a virtualisation server to > a new qemu effectively requires the same amount of testing/downtime of the > operation side as upgrading that system to jessie. The server might not be a dedicated virtualization server but be running services that aren't easily upgraded as well. > > Except that you would now run your system on a mostly untested combination of > vintage > 2.6.32 Linux, old libvirt and modern qemu compared to the jessie stack which > is > extensively tested through a full freeze. And you'd still need to upgrade to > jessie later. The above proposal would update libvirt as well (and I've tested this setup quiet a bit - not comparable to a freeze though). That said I wrote earlier that I do agree that it would be better to drop QEMU/KVM if nobody is in favour up updating and supporting it. Cheers, -- Guido
Re: Unsupported packages for Wheezy LTS
On Fri, May 13, 2016 at 02:10:48PM +0200, Guido Günther wrote: > > No, I recommend to EOL src:qemu/qemu-kvm in wheezy (the bits relevant to > > src:xen are > > somewhat isolated and can be backported from the Xen Security announcements) > > Backporting jessie's qemu will end up in a similar situation as the > > experiments > > with libav. > > I don't think so. We already have the version of Jessie in Wheezy > backports and I've looked into the dependency list. See > > https://lists.debian.org/debian-lts/2016/04/msg2.html > > so this should be doable… But what would be the point of that? Upgrading a virtualisation server to a new qemu effectively requires the same amount of testing/downtime of the operation side as upgrading that system to jessie. Except that you would now run your system on a mostly untested combination of vintage 2.6.32 Linux, old libvirt and modern qemu compared to the jessie stack which is extensively tested through a full freeze. And you'd still need to upgrade to jessie later. There are some cornercases where it makes sense to upgrade a central system component to a more recent version. The upgrade of Java makes sense to me e.g., but in the general case it's just papering over issues which should rather be communicated clearly to the user base. Cheers, Moritz
Re: Unsupported packages for Wheezy LTS
>>> AFAIK Xen in Wheezy is using the version shipped with Xen itself and we Yes, and this is used to support HVM mode guests, where the security of qemu matters. Seemingly (from qemu/VERSION) this is a very old "0.10.2" version of qemu!!! I do wonder to what extent updating _that_ qemu used to build xen-4.1 is practicable or desirable. Upsteam qemu have only just announced a version that no longer supports xen 4.1 and earlier... One way or another that xen qemu needs security-fixes . > AFAIK Xen uses only parts of the QEMU codebase. I'm not convinced > that supporting the current Wheezy versions of QEMU for two more > years is of much use (in contrast to the version currently in > Jessie) compared to the effort of backporting security fixes. Looking at it initially, I suspect many wheezy users of 'qemu' (1.2) would be happily updated to the 'wheezy-backports' qemu 2.1 version (though it needs a symlink from qemu to qemu-system-i386), but we should ask that question more widely... Seemingly the functionality is very similar/compatible, but no doubt subtle differences would break SOMETHING for SOMEBODY e.g. certain configs of pci/chipset updates have changed somewhat Those with heavily customized qemu config would need to pay attention to them, etc, but I very much suspect many typical use-cases would not have a problem with largely backwards compatible command line arguments. I had noticed more substantive qemu changes between 0.9.x and 1.x myself that had led to keeping a "qemu-old" variant for some old virtual-machines not to change their apparent ''identity'' so far as the virtualized-devices were concerned. > …or update QEMU? As above, consider, including for the variant _inside_ xen, could that (if helpful) actually be changed from 0.10.2 'ancient' version, maybe backporting is not a problem. But, qemu users may well be able to update host distribution, as that is still supported across all architectures, whereas xen-hypervisor-i386 is only available in wheezy so can't just 'upgrade' on 32bit machines. Hope that helps, --Simon signature.asc Description: OpenPGP digital signature
Re: Unsupported packages for Wheezy LTS
On 2016-05-13 06:30:35, Moritz Muehlenhoff wrote: > On Fri, May 13, 2016 at 12:21:13PM +0200, Raphael Hertzog wrote: >> On Fri, 13 May 2016, Moritz Muehlenhoff wrote: >> > > I'm not convinced that >> > > supporting the current Wheezy versions of QEMU for two more years is of >> > > much use (in contrast to the version currently in Jessie) compared to >> > > the effort of backporting security fixes. >> > >> > Ack. >> >> I'm not sure that I follow what you say here. You suggest to update qemu >> in wheezy to the version currently in jessie? Is that correct? > > No, I recommend to EOL src:qemu/qemu-kvm in wheezy (the bits relevant to > src:xen are > somewhat isolated and can be backported from the Xen Security announcements) > Backporting jessie's qemu will end up in a similar situation as the > experiments > with libav. See, this is what I think will be difficult in itself: some parts of qemu were more or less completely rewritten between the two releases. Specifically, the pnet.c driver I worked on to play catchup with even only 4.1.6 was significantly changed between point releases. I can't even begin to fathom how much has changed between xen/qemu wheezy and jessie. So if we're going to do this painful work, might as well maintain some qemu interface in wheezy as well. I am not sure I see what additional cost this would bring: although the attack surface is larger on qemu and Xen uses only some parts of the Qemu codebase, disclosed vulnerabilities concern mostly HVM support in Xen, and not the "unused from Xen" qemu codebase... But yeah, this seems exactly stuff that our sponsored Xen support team should look into. ;) > Anyone running a virtualisation server based on KVM/qemu is much better off > with upgrading to jessie. That is a tautology: anyone is better off upgrading to jessie if they can afford it. :) A. -- We have no friends but the mountains. - Kurdish saying
Re: Unsupported packages for Wheezy LTS
Hi, On Fri, May 13, 2016 at 12:30:35PM +0200, Moritz Muehlenhoff wrote: > On Fri, May 13, 2016 at 12:21:13PM +0200, Raphael Hertzog wrote: > > On Fri, 13 May 2016, Moritz Muehlenhoff wrote: > > > > I'm not convinced that > > > > supporting the current Wheezy versions of QEMU for two more years is of > > > > much use (in contrast to the version currently in Jessie) compared to > > > > the effort of backporting security fixes. > > > > > > Ack. > > > > I'm not sure that I follow what you say here. You suggest to update qemu > > in wheezy to the version currently in jessie? Is that correct? > > No, I recommend to EOL src:qemu/qemu-kvm in wheezy (the bits relevant to > src:xen are > somewhat isolated and can be backported from the Xen Security announcements) > Backporting jessie's qemu will end up in a similar situation as the > experiments > with libav. I don't think so. We already have the version of Jessie in Wheezy backports and I've looked into the dependency list. See https://lists.debian.org/debian-lts/2016/04/msg2.html so this should be doable… > Anyone running a virtualisation server based on KVM/qemu is much better off > with upgrading to jessie. …although I agree here too. One exception would be people relying on it on the desktop for e.g. sandboxing or running proprietary OSes but then QEMU in Wheezy is not really fit for this either. So supporting Xen and targetting QEMU/KVM for Jessie LTS makes most sense to me. Cheers, -- Guido
Re: Bug#824015: Unsupported packages for Wheezy LTS
On Fri, 13 May 2016, Santiago Ruano Rincón wrote: > > And announce those changes at the same time ideally. > > Through DLAs maybe? Yes, a DLA is fine for this. > I have a pending upload to close #824015, but now I'd prefer to wait > until May 23, for giving time to decide on this, and to wait for more > translations for the updated debconf template. Sure. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
On Fri, 13 May 2016, Moritz Muehlenhoff wrote: > > I'm not convinced that > > supporting the current Wheezy versions of QEMU for two more years is of > > much use (in contrast to the version currently in Jessie) compared to > > the effort of backporting security fixes. > > Ack. I'm not sure that I follow what you say here. You suggest to update qemu in wheezy to the version currently in jessie? Is that correct? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
On Fri, May 13, 2016 at 12:09:08PM +0200, Guido Günther wrote: > On Fri, May 13, 2016 at 09:40:42AM +0200, Raphael Hertzog wrote: > > On Thu, 12 May 2016, Guido Günther wrote: > > > > I would rather see qemu supported, in other words. But the version in > > > > wheezy is really old, and in xen/wheezy even more so. > > > > > > AFAIK Xen in Wheezy is using the version shipped with Xen itself and we > > > have gathered extra support for this so dropping QEMU/KVM in Wheezy > > > shouldn't have any negative effects on Xen. > > > > Or maybe we should see it the other way around... if the Xen suppport > > contract means that qemu has to be maintained as part of it, maybe that > > support contract could be extended to qemu/kvm for little cost? > > AFAIK Xen uses only parts of the QEMU codebase. Indeed. > I'm not convinced that > supporting the current Wheezy versions of QEMU for two more years is of > much use (in contrast to the version currently in Jessie) compared to > the effort of backporting security fixes. Ack. Cheers, Moritz
Re: Unsupported packages for Wheezy LTS
On Fri, May 13, 2016 at 09:40:42AM +0200, Raphael Hertzog wrote: > On Thu, 12 May 2016, Guido Günther wrote: > > > I would rather see qemu supported, in other words. But the version in > > > wheezy is really old, and in xen/wheezy even more so. > > > > AFAIK Xen in Wheezy is using the version shipped with Xen itself and we > > have gathered extra support for this so dropping QEMU/KVM in Wheezy > > shouldn't have any negative effects on Xen. > > Or maybe we should see it the other way around... if the Xen suppport > contract means that qemu has to be maintained as part of it, maybe that > support contract could be extended to qemu/kvm for little cost? AFAIK Xen uses only parts of the QEMU codebase. I'm not convinced that supporting the current Wheezy versions of QEMU for two more years is of much use (in contrast to the version currently in Jessie) compared to the effort of backporting security fixes. > Maybe we should ask credativ. …or update QEMU? -- Guido > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: http://www.freexian.com/services/debian-lts.html > Learn to master Debian: http://debian-handbook.info/get/ >
Re: Unsupported packages for Wheezy LTS
Hi, El 13/05/16 a las 09:51, Raphael Hertzog escribió: > Hello, > > On Thu, 12 May 2016, Markus Koschany wrote: > > I saw those commits too yesterday. I would suggest that we discuss EOLed > > packages on debian-lts before we mark CVEs as unsupported in Wheezy LTS. > > Definitely, we should not mark CVE as "end-of-life" before we agreed to > mark it as such in debian-security-support... > > That said for vlc I think no customers expressed any need for that > package. > > So I think we can stick to this decision and actually put it into > debian-security-support, even if we are going to support libav... > because vlc has many security issues of its own and contrary to libav > it's not a reverse dependency for many packages AFAIK. > > > findings. The same goes for vlc and Brian May's investigation into the > > maintainability of libav and related apps. In any case we should always > > update debian-security-support as well when we decide to end support for > > packages. > > And announce those changes at the same time ideally. Through DLAs maybe? I have a pending upload to close #824015, but now I'd prefer to wait until May 23, for giving time to decide on this, and to wait for more translations for the updated debconf template. Cheers, Santiago signature.asc Description: PGP signature
Re: Unsupported packages for Wheezy LTS
Hi,
On Thu, 12 May 2016, Guido Günther wrote:
> I have maintained icedove a while ago and know the codebase a bit. I'm
> also sure we might get support from the current maintainers as long as
> we're able to build the ESR releases for wheezy - which is Debian's
> standard way to deal with Firefox/Thundergbird security updates. I can
> look into building icedove 31.8 for wheezy. I could also check if we can
> build 45.x which would keep us covered for at least another year:
>
> https://www.mozilla.org/en-US/firefox/organizations/faq/
>
> So should we try to support ice{dove,weasel} at least for th3 45.x series?
+1 from my side, even though we don't have any explicit support request
from companies, it would really useful for end users and desktop
deployments.
> > qemu and qemu-kvm were triaged as unsupported for CVE-2016-3712, but I
> > think Guido is studying how to support virtualisation related packages,
> > and maybe we should wait for his evaluation.
>
> I had zero feedback on supporting qemu so I'd propose to drop it. We can
> keep libvirt in the current version if we don't update qemu and it seems
> to be in use in Wheezy quiet a bit (and dropping it would kill of quiet
> some programs due to the dependency chain) so I'd propose to keep it.
I would like us to look for other ways to support qemu before deciding to
drop it, cf my other mail, maybe we should look for external support as
well.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
Hello, On Thu, 12 May 2016, Markus Koschany wrote: > I saw those commits too yesterday. I would suggest that we discuss EOLed > packages on debian-lts before we mark CVEs as unsupported in Wheezy LTS. Definitely, we should not mark CVE as "end-of-life" before we agreed to mark it as such in debian-security-support... That said for vlc I think no customers expressed any need for that package. So I think we can stick to this decision and actually put it into debian-security-support, even if we are going to support libav... because vlc has many security issues of its own and contrary to libav it's not a reverse dependency for many packages AFAIK. > findings. The same goes for vlc and Brian May's investigation into the > maintainability of libav and related apps. In any case we should always > update debian-security-support as well when we decide to end support for > packages. And announce those changes at the same time ideally. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
On Thu, 12 May 2016, Antoine Beaupré wrote: > On 2016-05-12 09:16:15, Santiago Ruano Rincón wrote: > > Also, Antoine has filled a bug [1] regarding libmatroska and libebml, > > but DLA-420-1 and DLA-438-1 addressed those packages. Antoine, why they > > should be tagged as not-supported? > > Uh! I didn't see those go through, I'm surprised... My rationale was > exposed here: > > https://lists.debian.org/debian-lts/2016/02/msg00014.html That rationale applied to squeeze, not to wheezy. Let's close #814557 for now. > So I would say that matroska/libebml is dependent on libav support. But > I'm no multimedia team expert, others may have more competent advice. It should not be too hard to look up packages depending on libmatroska and see what they depend on... they are also not packages with a bad security track record so we have no reason to drop them from support in general. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
On Thu, 12 May 2016, Guido Günther wrote: > > I would rather see qemu supported, in other words. But the version in > > wheezy is really old, and in xen/wheezy even more so. > > AFAIK Xen in Wheezy is using the version shipped with Xen itself and we > have gathered extra support for this so dropping QEMU/KVM in Wheezy > shouldn't have any negative effects on Xen. Or maybe we should see it the other way around... if the Xen suppport contract means that qemu has to be maintained as part of it, maybe that support contract could be extended to qemu/kvm for little cost? Maybe we should ask credativ. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
On Thu, May 12, 2016 at 10:07:17AM -0400, Antoine Beaupré wrote: > On 2016-05-12 10:00:24, Guido Günther wrote: > >> qemu and qemu-kvm were triaged as unsupported for CVE-2016-3712, but I > >> think Guido is studying how to support virtualisation related packages, > >> and maybe we should wait for his evaluation. > > > > I had zero feedback on supporting qemu so I'd propose to drop it. We can > > keep libvirt in the current version if we don't update qemu and it seems > > to be in use in Wheezy quiet a bit (and dropping it would kill of quiet > > some programs due to the dependency chain) so I'd propose to keep it. > > Regarding qemu, keep in mind it's an integral part of Xen, specifically > the HVM bits, if i'm not mistaken. > > So dropping qemu support there means dropping *parts* of the Xen support > as well. > > I must say I'd be glad to do that because backporting those bits in xen > was specially painful, but it might give users a false sense of security > to say that Xen is supported, but only partially. The frontier there is > not always clear to me. > > I would rather see qemu supported, in other words. But the version in > wheezy is really old, and in xen/wheezy even more so. AFAIK Xen in Wheezy is using the version shipped with Xen itself and we have gathered extra support for this so dropping QEMU/KVM in Wheezy shouldn't have any negative effects on Xen. Cheers, -- Guido
Re: Unsupported packages for Wheezy LTS
On 2016-05-12 10:14:26, Moritz Muehlenhoff wrote: > On Thu, May 12, 2016 at 10:07:17AM -0400, Antoine Beaupré wrote: >> On 2016-05-12 10:00:24, Guido Günther wrote: >> >> qemu and qemu-kvm were triaged as unsupported for CVE-2016-3712, but I >> >> think Guido is studying how to support virtualisation related packages, >> >> and maybe we should wait for his evaluation. >> > >> > I had zero feedback on supporting qemu so I'd propose to drop it. We can >> > keep libvirt in the current version if we don't update qemu and it seems >> > to be in use in Wheezy quiet a bit (and dropping it would kill of quiet >> > some programs due to the dependency chain) so I'd propose to keep it. >> >> Regarding qemu, keep in mind it's an integral part of Xen, specifically >> the HVM bits, if i'm not mistaken. > > Not in wheezy, xen only uses the src:qemu starting with jessie. Well, that's great for jessie, but it does mean that wheezy ships with an embedded copy of the qemu code, which *has* to be maintained somehow, or we need to explicitly say we don't... a. -- Man really attains the state of complete humanity when he produces, without being forced by physical need to sell himself as a commodity. - Ernesto "Che" Guevara
Re: Unsupported packages for Wheezy LTS
On Thu, May 12, 2016 at 10:07:17AM -0400, Antoine Beaupré wrote: > On 2016-05-12 10:00:24, Guido Günther wrote: > >> qemu and qemu-kvm were triaged as unsupported for CVE-2016-3712, but I > >> think Guido is studying how to support virtualisation related packages, > >> and maybe we should wait for his evaluation. > > > > I had zero feedback on supporting qemu so I'd propose to drop it. We can > > keep libvirt in the current version if we don't update qemu and it seems > > to be in use in Wheezy quiet a bit (and dropping it would kill of quiet > > some programs due to the dependency chain) so I'd propose to keep it. > > Regarding qemu, keep in mind it's an integral part of Xen, specifically > the HVM bits, if i'm not mistaken. Not in wheezy, xen only uses the src:qemu starting with jessie. Cheers, Moritz
Re: Unsupported packages for Wheezy LTS
On 2016-05-12 10:00:24, Guido Günther wrote: >> qemu and qemu-kvm were triaged as unsupported for CVE-2016-3712, but I >> think Guido is studying how to support virtualisation related packages, >> and maybe we should wait for his evaluation. > > I had zero feedback on supporting qemu so I'd propose to drop it. We can > keep libvirt in the current version if we don't update qemu and it seems > to be in use in Wheezy quiet a bit (and dropping it would kill of quiet > some programs due to the dependency chain) so I'd propose to keep it. Regarding qemu, keep in mind it's an integral part of Xen, specifically the HVM bits, if i'm not mistaken. So dropping qemu support there means dropping *parts* of the Xen support as well. I must say I'd be glad to do that because backporting those bits in xen was specially painful, but it might give users a false sense of security to say that Xen is supported, but only partially. The frontier there is not always clear to me. I would rather see qemu supported, in other words. But the version in wheezy is really old, and in xen/wheezy even more so. a. -- I'm sorry if any of you are catholic. I'm not sorry if you're offended, I'm actually just sorry by the fact that you're catholic - Bill Hicks
Re: Unsupported packages for Wheezy LTS
Am 12.05.2016 um 15:16 schrieb Santiago Ruano Rincón: [...] qemu qemu-kvm xen > xen will be supported. libvirt > > qemu and qemu-kvm were triaged as unsupported for CVE-2016-3712, but I > think Guido is studying how to support virtualisation related packages, > and maybe we should wait for his evaluation. ffmpeg -> libav > waiting for input. > vlc rails -> several split packages (only the 3.2 packages are supported in wheezy) > ... >> >> The versions of libav and vlc in wheezy are all EOLed upstream. vlc is also >> behind some upstream releases in the 2.0.x series. If anyone intends to keep >> vlc >> alive for wheezy LTS, I'd recommend to upgrade to latest release there first. > > For CVE-2016-3941, vlc has been triaged as unsupported in wheezy, so I > updated security-support-ended.deb7 accordingly in git. [...] Hello, I saw those commits too yesterday. I would suggest that we discuss EOLed packages on debian-lts before we mark CVEs as unsupported in Wheezy LTS. We should defer the decision about quemu until Guido has concluded his findings. The same goes for vlc and Brian May's investigation into the maintainability of libav and related apps. In any case we should always update debian-security-support as well when we decide to end support for packages. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Unsupported packages for Wheezy LTS
Hi Santiago,
On Thu, May 12, 2016 at 03:16:15PM +0200, Santiago Ruano Rincón wrote:
> Hi,
>
> Given the recent bug triaging, security-support-ended.deb7 needs more
> updating. I'm taking Mortiz's mail as reference, and I hope I are not
> missing other info:
>
> El 11/11/15 a las 21:59, Sebastian Ramacher escribió:
> > Hi
> >
> > On 2015-11-04 17:44:36, Raphael Hertzog wrote:
> > > [ Many people are on copy, please trim the list as appropriate when you
> > > reply ]
> > >
> > > On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote:
> > > > These need to be discussed, since they will be a significant
> > > > time drain (e.g. are they in the sponsors's interests?). They
> > > > are supportable, but it will take a lot of work and sometimes
> > > > special domain knowledge:
> > > >
> > > > icedove
> > > > iceweasel
>
> Any decision yet?
> I could take a look to iceweasel/firefox next week, although I'm not
> familiar enough with it.
I have maintained icedove a while ago and know the codebase a bit. I'm
also sure we might get support from the current maintainers as long as
we're able to build the ESR releases for wheezy - which is Debian's
standard way to deal with Firefox/Thundergbird security updates. I can
look into building icedove 31.8 for wheezy. I could also check if we can
build 45.x which would keep us covered for at least another year:
https://www.mozilla.org/en-US/firefox/organizations/faq/
So should we try to support ice{dove,weasel} at least for th3 45.x series?
> > > > qemu
> > > > qemu-kvm
> > > > xen
> xen will be supported.
> > > > libvirt
>
> qemu and qemu-kvm were triaged as unsupported for CVE-2016-3712, but I
> think Guido is studying how to support virtualisation related packages,
> and maybe we should wait for his evaluation.
I had zero feedback on supporting qemu so I'd propose to drop it. We can
keep libvirt in the current version if we don't update qemu and it seems
to be in use in Wheezy quiet a bit (and dropping it would kill of quiet
some programs due to the dependency chain) so I'd propose to keep it.
Cheers,
-- Guido
Re: Unsupported packages for Wheezy LTS
Hi, Given the recent bug triaging, security-support-ended.deb7 needs more updating. I'm taking Mortiz's mail as reference, and I hope I are not missing other info: El 11/11/15 a las 21:59, Sebastian Ramacher escribió: > Hi > > On 2015-11-04 17:44:36, Raphael Hertzog wrote: > > [ Many people are on copy, please trim the list as appropriate when you > > reply ] > > > > On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote: > > > These need to be discussed, since they will be a significant > > > time drain (e.g. are they in the sponsors's interests?). They > > > are supportable, but it will take a lot of work and sometimes > > > special domain knowledge: > > > > > > icedove > > > iceweasel Any decision yet? I could take a look to iceweasel/firefox next week, although I'm not familiar enough with it. > > > qemu > > > qemu-kvm > > > xen xen will be supported. > > > libvirt qemu and qemu-kvm were triaged as unsupported for CVE-2016-3712, but I think Guido is studying how to support virtualisation related packages, and maybe we should wait for his evaluation. > > > ffmpeg -> libav waiting for input. > > > vlc > > > rails -> several split packages (only the 3.2 packages are supported in > > > wheezy) ... > > The versions of libav and vlc in wheezy are all EOLed upstream. vlc is also > behind some upstream releases in the 2.0.x series. If anyone intends to keep > vlc > alive for wheezy LTS, I'd recommend to upgrade to latest release there first. For CVE-2016-3941, vlc has been triaged as unsupported in wheezy, so I updated security-support-ended.deb7 accordingly in git. What about rails? Also, Antoine has filled a bug [1] regarding libmatroska and libebml, but DLA-420-1 and DLA-438-1 addressed those packages. Antoine, why they should be tagged as not-supported? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814557 Cheers, Santiago signature.asc Description: PGP signature
Re: Unsupported packages for Wheezy LTS
Am 29.02.2016 um 18:04 schrieb Raphael Hertzog: > On Mon, 29 Feb 2016, Markus Koschany wrote: >> Matthias Klose, the OpenJDK maintainer, stated that he intends to >> support OpenJDK 6 until Ubuntu 12.04 reaches EOL in April 2017 [1] and I >> think it should be feasible to mirror this approach for Wheezy LTS >> provided everyone agrees to keep OpenJDK 6 supported until then. > > I have no objection but I also don't see the point of supporting > something only half of the LTS period. Fair enough. Then let's focus on the switch to make OpenJDK 7 the default in Wheezy LTS. >> We discussed the switch to OpenJDK 7 last month [2] and I think the >> problematic packages are only those that strictly depend on >> openjdk-6-jre like tunnelx and rcran-r-java. Everything else that >> declares an alternative dependency on java6-runtime or default-jre >> should be fine because OpenJDK 7 provides these dependencies. > > I suggest that we can already fix those, possibly via > wheezy-proposed-updates so that they are fixed before the last > wheezy point release. I will handle the switch to OpenJDK 7 and coordinate this with the Debian Release Team. I have updated https://wiki.debian.org/LTS/TODO accordingly. >> In addition I would also suggest to add Tomcat 6 to the list of >> unsupported packages when it is declared EOL on December 31, 2016 [3] >> and recommend the switch to Tomcat 7. > > OK. Then we should probably have some "Wheezy LTS release notes" where we > can add some recommendations like "Use Tomcat 7 if you want security > support until the end of Wheezy LTS because Tomcat 6 will be EOL on > 2016-12-31." > > We could then also document the situation of OpenJDK 6. > > And we should also fix debian-security-support to be able to document well > in advance that some packages won't be supported past a given date... > right now I don't think that the software takes the EOL date into account. I transformed these suggestions into TODO items on https://wiki.debian.org/LTS/TODO. Everyone feel free to work on this and don't forget to claim the task by adding your names behind it. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Unsupported packages for Wheezy LTS
Am 29.02.2016 um 15:17 schrieb Raphael Hertzog: > On Thu, 19 Nov 2015, Moritz Mühlenhoff wrote: >> Another package which needs to be sorted out is the support for >> Java. wheezy has both openjdk-6 and openjdk-7 (jessie has only >> -7 and stretch will also only have one version). > > I asked our current sponsors about OpenJDK 6 and none asked > us to keep supporting it. They are satisfied with having only > OpenJDK 7 supported in wheezy. > >> sense to only support openjdk-7 in Debian LTS. Some rdeps in >> wheezy will not allow that, but I think most people use openjdk >> to run external java apps and not the Java apps packaged in >> Debian (with maybe Tomcat as the exception). > > Yes, we need to investigate that. I just stumbled on a few packages > with "openjdk-6-jre | java6-runtime" in their dependencies (like > "entagged" or "389-console"). > > A complete list should be made to see the impact and decide what should > happen to those packages... Matthias Klose, the OpenJDK maintainer, stated that he intends to support OpenJDK 6 until Ubuntu 12.04 reaches EOL in April 2017 [1] and I think it should be feasible to mirror this approach for Wheezy LTS provided everyone agrees to keep OpenJDK 6 supported until then. We discussed the switch to OpenJDK 7 last month [2] and I think the problematic packages are only those that strictly depend on openjdk-6-jre like tunnelx and rcran-r-java. Everything else that declares an alternative dependency on java6-runtime or default-jre should be fine because OpenJDK 7 provides these dependencies. In addition I would also suggest to add Tomcat 6 to the list of unsupported packages when it is declared EOL on December 31, 2016 [3] and recommend the switch to Tomcat 7. Regards, Markus [1] https://lists.debian.org/debian-java/2016/01/msg00069.html [2] https://lists.debian.org/debian-lts/2016/01/msg00112.html [3] https://tomcat.apache.org/tomcat-60-eol.html signature.asc Description: OpenPGP digital signature
Re: Unsupported packages for Wheezy LTS
On Thu, 19 Nov 2015, Moritz Mühlenhoff wrote: > Another package which needs to be sorted out is the support for > Java. wheezy has both openjdk-6 and openjdk-7 (jessie has only > -7 and stretch will also only have one version). I asked our current sponsors about OpenJDK 6 and none asked us to keep supporting it. They are satisfied with having only OpenJDK 7 supported in wheezy. > sense to only support openjdk-7 in Debian LTS. Some rdeps in > wheezy will not allow that, but I think most people use openjdk > to run external java apps and not the Java apps packaged in > Debian (with maybe Tomcat as the exception). Yes, we need to investigate that. I just stumbled on a few packages with "openjdk-6-jre | java6-runtime" in their dependencies (like "entagged" or "389-console"). A complete list should be made to see the impact and decide what should happen to those packages... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
On Wed, Aug 19, 2015 at 01:02:59PM +0200, Moritz Muehlenhoff wrote: > Hi, > as a followup to yesterday's BoF I compared the list of unsupported > packages in Squeeze LTS against the current status quo: > > (We try to split the LTS work from the normal security work, but I'm > adding t...@security.debian.org to CC to let people comment who > are not on debian-lts.) > > > > This leaves the following for further investigation/discussion: Another package which needs to be sorted out is the support for Java. wheezy has both openjdk-6 and openjdk-7 (jessie has only -7 and stretch will also only have one version). Currently the maintenance heavily relies on the gruntwork done by Matthias Klose (and recently indirectly Tiago St�rmer Daitx): The unstable releases are backported. It needs to be sorted with them out how long these openjdk-6 uploads will be available in experimental (and how long upstream support in icedtea will happen). Otherwise it might make more sense to only support openjdk-7 in Debian LTS. Some rdeps in wheezy will not allow that, but I think most people use openjdk to run external java apps and not the Java apps packaged in Debian (with maybe Tomcat as the exception). Cheers, Moritz
Re: Unsupported packages for Wheezy LTS
Am 19.11.2015 um 21:45 schrieb Moritz Mühlenhoff: [...] > Another package which needs to be sorted out is the support for > Java. wheezy has both openjdk-6 and openjdk-7 (jessie has only > -7 and stretch will also only have one version). > > Currently the maintenance heavily relies on the gruntwork done > by Matthias Klose (and recently indirectly Tiago St�rmer Daitx): > The unstable releases are backported. > > It needs to be sorted with them out how long these openjdk-6 > uploads will be available in experimental (and how long upstream > support in icedtea will happen). Otherwise it might make more > sense to only support openjdk-7 in Debian LTS. Some rdeps in > wheezy will not allow that, but I think most people use openjdk > to run external java apps and not the Java apps packaged in > Debian (with maybe Tomcat as the exception). > Hi, I believe Debian Java is more than just OpenJDK and Tomcat and it is rather discouraging to read that "most people use openjdk to run external java apps and not the Java apps packaged in Debian". The Debian Java team alone maintains about 900 source packages and according to popcon there are several packages besides Tomcat with a significant user base. I suggest to keep the Java team involved when it comes to security support in LTS releases, so that we can help to identify important packages and sort things out. There are some Java packages which have no security implications at all (API packages) and others that deserve more attention and where we gladly accept help from the (LTS-) security team. I think I am not the only one who is interested in improving the security support for Java packages but we should really discuss this together. For what it's worth security support for OpenJDK 6 can be dropped at some time during Wheezy LTS. It is sensible to advise users to switch to OpenJDK 7 then. Most packages should continue to work because they were compiled against version 5 anyway. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Unsupported packages for Wheezy LTS
Hi On 2015-11-04 17:44:36, Raphael Hertzog wrote: > [ Many people are on copy, please trim the list as appropriate when you reply > ] > > On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote: > > These need to be discussed, since they will be a significant > > time drain (e.g. are they in the sponsors's interests?). They > > are supportable, but it will take a lot of work and sometimes > > special domain knowledge: > > > > icedove > > iceweasel > > qemu > > qemu-kvm > > xen > > libvirt > > ffmpeg -> libav > > vlc > > rails -> several split packages (only the 3.2 packages are supported in > > wheezy) ... > Thus putting the respective maintainers/maintainance team in copy (Mike > Hommey for iceweasel, Guido Günther for multiple package, Christop Göhre for > Icedove, > Aurelien Jarno, Riku Voipio, Vagrant Cascadian for qemu, Michael Tokarev > for qemu-kvm, Guido Trotter and Bastian Blank for Xen, Laurent Léonard > for libvirt, Sebastian Ramacher and pkg-multimedia for libav/vlc). The versions of libav and vlc in wheezy are all EOLed upstream. vlc is also behind some upstream releases in the 2.0.x series. If anyone intends to keep vlc alive for wheezy LTS, I'd recommend to upgrade to latest release there first. I don't plan to spend any time on the wheezy versions of libav and vlc once the normal wheezy support has ended. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Re: Unsupported packages for Wheezy LTS
Hello, [just talking about Icedove] Am 05.11.2015 um 08:47 schrieb Guido Günther: >> Do you know someone from the Debian maintenance team or from the upstream >> project which could be hired a few hours from time to time to provide the >> required security updates on the above source packages when it gets too >> complicated for the LTS contributors? Feel free to pass around this email >> if you think of someone and want to inform him/her... > > If we do iceweasel then icedove wouldn't be hard on top but I'll let > Christoph and Carsten (added to cc:) comment on this since I've not > done any real Icedove work since ages. as Guido already stated Icedove won't be a big problem if Iceweasel can be built. So it's more a problem on the points Mike was talking about in one of the previous mails. Based on the experience made on the Squeeze release and the targeted start for Wheezy LTS in February next year I wouldn't count much on a long possible LTS support for Icedove. Currently the version 38.x can be built and used in Wheezy (not yet uploaded by Christoph). But I can't say much about the next ESR version 45 for Wheezy, I haven't tried out a build of recent Beta versions of Icedove for Wheezy. Maybe Mike can say something about this scenario. It may be possibly if the needed tools and binaries are reachable via backports if not available in the normal LTS workflow. -- Regards Carsten Schoenert signature.asc Description: OpenPGP digital signature
Re: Unsupported packages for Wheezy LTS
On Thu, Nov 05, 2015 at 08:43:38AM +0100, Moritz Muehlenhoff wrote: > On Thu, Nov 05, 2015 at 06:47:03AM +0900, Mike Hommey wrote: > > First and foremost, while GCC 4.7 is the current > > minimum version supported, it's likely to become GCC 4.8 in the near > > future, because of some wanted C++11/C++14 features. > > That problem also bit us with chromium in wheezy. Introducing an updated > g++ isn't simple since libstdc++ is also built from the source package. Note that Firefox /can/ build with GCC > 4.7 but still depend on libstdc++ from GCC 4.3, thanks to nasty tricks. https://dxr.mozilla.org/mozilla-central/source/build/unix/stdc++compat/stdc++compat.cpp Mike
Re: Unsupported packages for Wheezy LTS
Hi, On Thu, Nov 05, 2015 at 09:10:26AM +0100, David Ayers wrote: > Yet we could in theory live with backports of newer versions, as I > assume the problem is that these are packages that are not supported > upstream. But I'm not sure how much that would buy, since the versions > of libvirt in sid and experimental are still rather old compared to > current versions upstream. I'm confused. We usually have the current libvirt releases in unstable and the RCs in experimental so I don't see what you are missing. Currently we have 1.2.21rc1 in experimental which is almost identical to the final 1.2.21 release. We're usually keeping up quiet well with the 4 week release schedule. Cheers, -- Guido
Re: Unsupported packages for Wheezy LTS
Hi, On Thu, 05 Nov 2015, Mike Hommey wrote: > Speaking for iceweasel, backports to wheezy are not a significant > overhead compared to packaging for unstable and stable-security. > > With that being said, the fact that we're backporting new upstream > ESR releases is going to have its own problems sooner or later, related > to the toolchains. First and foremost, while GCC 4.7 is the current > minimum version supported, it's likely to become GCC 4.8 in the near > future, because of some wanted C++11/C++14 features. Second, Firefox is > soon going to require the rust compiler, which we have no package for > except in unstable. > > So there should be a discussion about what we do about those toolchains > first (and that's a broader discussion to have than LTS). Yes, the lack of python 2.7 in squeeze was already what blocked iceweasel backport in squeeze... the problem will come again and again with other dependencies. In general, we must accomodate those requirements and each case needs to be considered on its own merit, we can either update the main repository or create a specific bikeshed that we would enable in the buildd (assuming they come into existence). For rust, since it's entirely new, we should just introduce it into wheezy. But when the new upstream version may introduce backwards compatibility problems, then they are best handled in a bikeshed. That should probably be the case of new gcc versions as long as we can avoid having the built packages depend on the specific version available in the bikeshed (which iceweasel is capable of since it depends only on libstdc++ from gcc 4.3). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
On Wed, Nov 04, 2015 at 05:44:36PM +0100, Raphael Hertzog wrote: > [ Many people are on copy, please trim the list as appropriate when you reply > ] > > On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote: > > These need to be discussed, since they will be a significant > > time drain (e.g. are they in the sponsors's interests?). They > > are supportable, but it will take a lot of work and sometimes > > special domain knowledge: > > > > icedove > > iceweasel > > qemu > > qemu-kvm > > xen > > libvirt > > ffmpeg -> libav > > vlc > > rails -> several split packages (only the 3.2 packages are supported in > > wheezy) > > Nobody commented here but I believe that we should aim to support them. > Except vlc, they are all used by some of the current sponsors (even though > they are not currently supported in squeeze). > > It would be good to identify Debian maintainers with the required "special > domain knowledge" for all those packages so that they can be paid to > take care of those packages when the need arises (cf > https://www.freexian.com/services/debian-lts-details.html#join for > details about requirement for paid contributors). Speaking for iceweasel, backports to wheezy are not a significant overhead compared to packaging for unstable and stable-security. With that being said, the fact that we're backporting new upstream ESR releases is going to have its own problems sooner or later, related to the toolchains. First and foremost, while GCC 4.7 is the current minimum version supported, it's likely to become GCC 4.8 in the near future, because of some wanted C++11/C++14 features. Second, Firefox is soon going to require the rust compiler, which we have no package for except in unstable. So there should be a discussion about what we do about those toolchains first (and that's a broader discussion to have than LTS). Mike
Re: Unsupported packages for Wheezy LTS
Hi, On Wed, Nov 04, 2015 at 05:44:36PM +0100, Raphael Hertzog wrote: > [ Many people are on copy, please trim the list as appropriate when you reply > ] > > On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote: > > These need to be discussed, since they will be a significant > > time drain (e.g. are they in the sponsors's interests?). They > > are supportable, but it will take a lot of work and sometimes > > special domain knowledge: > > > > icedove > > iceweasel > > qemu > > qemu-kvm > > xen > > libvirt > > ffmpeg -> libav > > vlc > > rails -> several split packages (only the 3.2 packages are supported in > > wheezy) > For wheezy I think it would be possible to maintain libvirt. Especially if we don't support all hypervisors in Wheezy. I could probably set aside the extra time given enough advanced notice when the LTS team takes over Wheezy. Should we decide to support e.g. KVM via backports this would change the picture since there are usually always changes needed for e.g. newer qemu-kvm versions, some of them being very intrusive. For qemu/qemu-kvm I'm not so sure given the large amount of dependencies and code changes between versions. It would be great to hear what Michael things about this. Cheers, -- Guido
Re: Unsupported packages for Wheezy LTS
On Thu, Nov 05, 2015 at 06:47:03AM +0900, Mike Hommey wrote: > First and foremost, while GCC 4.7 is the current > minimum version supported, it's likely to become GCC 4.8 in the near > future, because of some wanted C++11/C++14 features. That problem also bit us with chromium in wheezy. Introducing an updated g++ isn't simple since libstdc++ is also built from the source package. > Second, Firefox is > soon going to require the rust compiler, which we have no package for > except in unstable. I'd say lets ask the maintainers (and stable release managers) to introduce it in the next jessie point release. Cheers, Moritz
Re: Unsupported packages for Wheezy LTS
Hi, On Wed, Nov 04, 2015 at 05:44:36PM +0100, Raphael Hertzog wrote: > [ Many people are on copy, please trim the list as appropriate when you reply > ] > > On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote: > > These need to be discussed, since they will be a significant > > time drain (e.g. are they in the sponsors's interests?). They > > are supportable, but it will take a lot of work and sometimes > > special domain knowledge: > > > > icedove > > iceweasel > > qemu > > qemu-kvm > > xen > > libvirt > > ffmpeg -> libav > > vlc > > rails -> several split packages (only the 3.2 packages are supported in > > wheezy) > > Nobody commented here but I believe that we should aim to support them. > Except vlc, they are all used by some of the current sponsors (even though > they are not currently supported in squeeze). > > It would be good to identify Debian maintainers with the required "special > domain knowledge" for all those packages so that they can be paid to > take care of those packages when the need arises (cf > https://www.freexian.com/services/debian-lts-details.html#join for > details about requirement for paid contributors). > > Thus putting the respective maintainers/maintainance team in copy (Mike > Hommey for iceweasel, Guido Günther for multiple package, Christop Göhre for > Icedove, > Aurelien Jarno, Riku Voipio, Vagrant Cascadian for qemu, Michael Tokarev > for qemu-kvm, Guido Trotter and Bastian Blank for Xen, Laurent Léonard > for libvirt, Sebastian Ramacher and pkg-multimedia for libav/vlc). > > Do you know someone from the Debian maintenance team or from the upstream > project which could be hired a few hours from time to time to provide the > required security updates on the above source packages when it gets too > complicated for the LTS contributors? Feel free to pass around this email > if you think of someone and want to inform him/her... If we do iceweasel then icedove wouldn't be hard on top but I'll let Christoph and Carsten (added to cc:) comment on this since I've not done any real Icedove work since ages. Cheers, -- Guido
Re: Unsupported packages for Wheezy LTS
On Wed, Nov 04, 2015 at 05:42:43PM +0100, Raphael Hertzog wrote: > > movabletype-opensource > > -> Upstream went closed source, Dominic kept in on life support, > > should be checked with him > > Dominic, do you think movabletype-opensource can be supported in wheezy > until May 2018? No, I would rather not do this: the last open source version went out of support at the end of September as far as I can tell from this: https://movabletype.org/product-life-cycle-policy.html so there is nothing to backport upstream fixes from any more. We should send out an EOL notice for wheezy-security too. Thanks for checking! Cheers, Dominic.
Re: Unsupported packages for Wheezy LTS
[ Many people are on copy, please trim the list as appropriate when you reply ] On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote: > as a followup to yesterday's BoF I compared the list of unsupported > packages in Squeeze LTS against the current status quo: > Support for these ended in Wheezy already, so unsupported in LTS as well: > chromium-browser > typo3-src > mediawiki (support will cease in April 2016) For mediawiki, might it not make sense to update to a new upstream version when upstream supports ends? I know there's an ecosystem of plugins and stuff like that but having to deal with an upgrade is probably better than having a Mediawiki with security holes... > Not covered by security support in normal security support, did > someone actually check whether this still works in LTS? IMHO > LTS should be limited to main. We shouldn't endorse the Flash plugin > in LTS: > flashplugin-nonfree I agree that non-free should not be covered. > Should probably be dropped: > > mantis > -> No active maintainer for years, has been kept on life support >via security updates, frequent issues Ack. > asterisk > -> Complicated to update/test, lack of effort by maintainers Pinging the Asterisk maintainers. Do you think it is realistic to support asterisk 1.8.13.1 in wheezy until May 2018? Shall it be excluded from LTS support? Do you think you can support it through backports? (I see you have troubles supporting it in unstable/testing already...) > openswan > -> Dead upstream, strongswan exists as a supported alternative Ack. > movabletype-opensource > -> Upstream went closed source, Dominic kept in on life support, > should be checked with him Dominic, do you think movabletype-opensource can be supported in wheezy until May 2018? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
Hello, On Wed, 16 Sep 2015, Raphael Hertzog wrote: > On Tue, 25 Aug 2015, Holger Levsen wrote: > > > In addition it would make sense to exclude the OpenStack packages > > > in wheezy, they are fully unsupported upstream und very unlikely > > > to be used since OpenStack is evolving so fast. You should discuss > > > that with Thomas Goirand. > > > > Thomas, what's your stance on this? While Thomas did not reply directly, I discussed with him on IRC and he confirmed me that he already has troubles supporting OpenStack in the current stable releases, so expecting to support OpenStack for 5 years is not realistic. I thus suggest to exclude OpenStack packages from LTS support. Thomas, can you provide us the list of the corresponding source packages? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
[ Many people are on copy, please trim the list as appropriate when you reply ] On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote: > These need to be discussed, since they will be a significant > time drain (e.g. are they in the sponsors's interests?). They > are supportable, but it will take a lot of work and sometimes > special domain knowledge: > > icedove > iceweasel > qemu > qemu-kvm > xen > libvirt > ffmpeg -> libav > vlc > rails -> several split packages (only the 3.2 packages are supported in > wheezy) Nobody commented here but I believe that we should aim to support them. Except vlc, they are all used by some of the current sponsors (even though they are not currently supported in squeeze). It would be good to identify Debian maintainers with the required "special domain knowledge" for all those packages so that they can be paid to take care of those packages when the need arises (cf https://www.freexian.com/services/debian-lts-details.html#join for details about requirement for paid contributors). Thus putting the respective maintainers/maintainance team in copy (Mike Hommey for iceweasel, Guido Günther for multiple package, Christop Göhre for Icedove, Aurelien Jarno, Riku Voipio, Vagrant Cascadian for qemu, Michael Tokarev for qemu-kvm, Guido Trotter and Bastian Blank for Xen, Laurent Léonard for libvirt, Sebastian Ramacher and pkg-multimedia for libav/vlc). Do you know someone from the Debian maintenance team or from the upstream project which could be hired a few hours from time to time to provide the required security updates on the above source packages when it gets too complicated for the LTS contributors? Feel free to pass around this email if you think of someone and want to inform him/her... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Unsupported packages for Wheezy LTS
Hi Thomas, I'd like to have your opinion on the question below. Thank you! On Tue, 25 Aug 2015, Holger Levsen wrote: > > In addition it would make sense to exclude the OpenStack packages > > in wheezy, they are fully unsupported upstream und very unlikely > > to be used since OpenStack is evolving so fast. You should discuss > > that with Thomas Goirand. > > Thomas, what's your stance on this? -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
