On Tue, 13 Jul 2010 08:40:09 -0400, Reinhard Tartler <siret...@tauware.de>
> So let's check:
> | vlc | 0.8.6.release.e+x264svn20071224+faad2.6.1-0ubuntu3.3 |
> hardy-updates/universe | source
> | vlc | 0.9.9a-2ubuntu1 | jaunty/multiverse | source, amd64, i386
> | vlc | 1.0.2-1ubuntu2 | karmic/universe | source, amd64, i386
> | vlc | 1.0.2-1ubuntu2.1 | karmic-updates/universe | source, amd64, i386
> | vlc | 1.0.6-1ubuntu1 | lucid/universe | source, amd64, i386
> | vlc | 1.0.6-1ubuntu1.1 | lucid-updates/universe | source, amd64, i386
> | vlc | 1.1.0-2ubuntu1 | maverick/universe | source, amd64, i386
> so in hardy we have basically the same situation as in
> debian/stable. We could argue that it is unsupportable and try to get it
> As for karmic, I guess we could and probably should work on preparing an
> upload to either karmic-updates or karmic-security. But this would
> involve following a rather strict process. Rémi, is there a list of bugs
> fixed between 1.0.2 - 1.0.6?
Generally, git gives you that. In -bugfix branches we normally don't do
architectural changes or risky cleanups.
With that in mind, it should be easy to make out bug fixes, from
administrative updates and new features.
>>> The process would be:
>>> 1. Open a bug report in Launchpad stating the security bug
>>> 2. Produce a patch that fixes the bug in the latest trunk version
>>> 3. Backport the patch against trunk to the older versions of vlc
>>> 4. Release the security update
>> Someone needs to dig the security patches out of 1.0-bugfix from 1.0.2
>> to 1.0.6. That's not really difficult; it's just time consuming. The
>> VideoLAN project is already doing that for the latest 1.0.x. We are
>> not going to do that for all of the 1.0.x revisions individually. If
>> distribution FOOBAR decides to fork the maintenance process, then
>> that's FOOBAR's problem. And when FOOBAR does not stand up to its own
>> process, you get pathetic results like VLC in Debian Stable.
> I tend to agree here. This answers my question from above pretty much.
> So if I understand you correctly, there is a 1.0-bugfix branch, from
> which we can try to cherry-pick individial changes to existing
> releases. I guess it is this repository:
> Hm, I see that the amount of work you're doing here is incredible. I
> really think we should get this packaged.
>> We are already sorting Ubuntu VLC bug reports, made 1.0.6 more or less
>> only for Ubuntu LTS, report security issues in your bug tracker. Where
>> does this stop? We're _not_ paid.
>>> Looking at the Ubuntu bugs, there is only one security bug reported:
> and AFAIUI, it doesn't affect the versions of vlc we're talking right
> now. So from a ubuntu bugtracker POV, there are no known security
> issues, and as the commit logs don't reference CVE or similar security
> trackers either, I guess we need to be somewhat more convincing here.
Safe for a major speed up in CVE numbers assignment, this is unlikely to
improve. Besides, I fear I sense a chick-and-egg problem here. I mean,
MITRE won't give me numbers just for my smile, will they?
pkg-multimedia-maintainers mailing list