Re: [vlc-devel] Debian/Ubuntu VLC
Hello, On Mon, 12 Jul 2010 22:28:59 +0200, Benjamin Drung bdr...@ubuntu.com wrote: I doubt that we can pull a new upstream version into a stable Ubuntu release (e.g. vlc 1.1.0 in Ubuntu 10.04), because the new version breaks the ABI of the older version and therefore break applications that uses libvlc. Not true for 9.10 which ships 1.0.2, while 1.0.6 has no known security issues. The normal way for stable releases is to cherry-pick security fixes and apply them to the older version. How much manpower do you have to support this model? English is ambiguous here. *I* definitely won't spend time on 0.8 or 0.9, and I very much doubt anyone else will. As for 1.0, it all depends how hard specific fixes will be, which is undecidable until shit happens. 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. 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: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/295464 -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of das-watchdog_0.9.0-2_i386.changes
das-watchdog_0.9.0-2_i386.changes uploaded successfully to localhost along with the files: das-watchdog_0.9.0-2.dsc das-watchdog_0.9.0-2.debian.tar.gz das-watchdog_0.9.0-2_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
das-watchdog_0.9.0-2_i386.changes ACCEPTED
Accepted: das-watchdog_0.9.0-2.debian.tar.gz to main/d/das-watchdog/das-watchdog_0.9.0-2.debian.tar.gz das-watchdog_0.9.0-2.dsc to main/d/das-watchdog/das-watchdog_0.9.0-2.dsc das-watchdog_0.9.0-2_i386.deb to main/d/das-watchdog/das-watchdog_0.9.0-2_i386.deb Override entries for your package: das-watchdog_0.9.0-2.dsc - source admin das-watchdog_0.9.0-2_i386.deb - extra admin Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: -dbg packages... policy?
On Mon, Jul 12, 2010 at 13:26:17 (EDT), Gabriel M. Beddingfield wrote: Does Debian have any sort of policy about when there should and should not be a -dbg package? As an upstream author, I personally prefer having -dbg packages for all packages. I think this question deserves a more general audience. AFAIUI, adding -dbg packages is at the maintainers descretion and added on a case by case basis. The issue is that espc. large packages produce increadibly huge dbg package, so it has to be decided on a case by case basis. Libraries and applications for which stacktraces are useful are good candidates to add -dbg packages. Maybe one day debian will gain a similar retrace infrastructure like ubuntu has with apport: https://wiki.ubuntu.com/Apport -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Tue, Jul 13, 2010 at 02:49:15 (EDT), Rémi Denis-Courmont wrote: Hello, On Mon, 12 Jul 2010 22:28:59 +0200, Benjamin Drung bdr...@ubuntu.com wrote: I doubt that we can pull a new upstream version into a stable Ubuntu release (e.g. vlc 1.1.0 in Ubuntu 10.04), because the new version breaks the ABI of the older version and therefore break applications that uses libvlc. Not true for 9.10 which ships 1.0.2, while 1.0.6 has no known security issues. 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 removed. 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? the SRU team will most likely require some kind of risk analysis and some proof that it's really worth. I of course believe you because I know vlc and what incredible work you are doing, but having something more solid like in CVE references would be really beneficial here. Moreover, it seems that there has been at least one update to vlc in karmic-updates. The normal way for stable releases is to cherry-pick security fixes and apply them to the older version. How much manpower do you have to support this model? English is ambiguous here. *I* definitely won't spend time on 0.8 or 0.9, and I very much doubt anyone else will. As for 1.0, it all depends how hard specific fixes will be, which is undecidable until shit happens. 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: http://git.videolan.org/?p=vlc/vlc-1.0.git;a=summary correct? 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: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/295464 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. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
xjadeo_0.4.10-1_i386.changes ACCEPTED
Accepted: xjadeo_0.4.10-1.debian.tar.gz to main/x/xjadeo/xjadeo_0.4.10-1.debian.tar.gz xjadeo_0.4.10-1.dsc to main/x/xjadeo/xjadeo_0.4.10-1.dsc xjadeo_0.4.10-1_i386.deb to main/x/xjadeo/xjadeo_0.4.10-1_i386.deb xjadeo_0.4.10.orig.tar.gz to main/x/xjadeo/xjadeo_0.4.10.orig.tar.gz Override entries for your package: xjadeo_0.4.10-1.dsc - optional sound xjadeo_0.4.10-1_i386.deb - optional sound Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 521768 Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#521768: marked as done (ITP: xjadeo -- Video player with jack sync)
Your message dated Tue, 13 Jul 2010 13:18:16 + with message-id e1oyfni-00057o...@franck.debian.org and subject line Bug#521768: fixed in xjadeo 0.4.10-1 has caused the Debian Bug report #521768, regarding ITP: xjadeo -- Video player with jack sync to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 521768: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521768 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: wnpp Severity: wishlist Please package xjadeo with qjadeo * Package name: xjadeo Version : 0.4.6 Upstream Author : dunno * URL : http://xjadeo.sourceforge.net/ * License : GPL Programming Lang: C, C++, C#, Perl, Python Description : xjadeo is a simple video player that is synchronized to jack transport simple video player that is synchronized to jack transport -- System Information: Debian Release: squeeze/sid Architecture: i386 (i686) ---End Message--- ---BeginMessage--- Source: xjadeo Source-Version: 0.4.10-1 We believe that the bug you reported is fixed in the latest version of xjadeo, which is due to be installed in the Debian FTP archive: xjadeo_0.4.10-1.debian.tar.gz to main/x/xjadeo/xjadeo_0.4.10-1.debian.tar.gz xjadeo_0.4.10-1.dsc to main/x/xjadeo/xjadeo_0.4.10-1.dsc xjadeo_0.4.10-1_i386.deb to main/x/xjadeo/xjadeo_0.4.10-1_i386.deb xjadeo_0.4.10.orig.tar.gz to main/x/xjadeo/xjadeo_0.4.10.orig.tar.gz A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 521...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jaromír Mikeš mira.mi...@seznam.cz (supplier of updated xjadeo package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 10 Jul 2010 12:01:22 +0200 Source: xjadeo Binary: xjadeo Architecture: source i386 Version: 0.4.10-1 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Changed-By: Jaromír Mikeš mira.mi...@seznam.cz Description: xjadeo - Video player with jack sync Closes: 521768 Changes: xjadeo (0.4.10-1) unstable; urgency=low . * Initial release (Closes: #521768) Checksums-Sha1: 4087697961c606593c2d3aca9027cd280a6ed130 1568 xjadeo_0.4.10-1.dsc ce5f7550bf41dabba8ac3654fbe9f8608263212b 326525 xjadeo_0.4.10.orig.tar.gz 4672e7aefb2c3675b49fb1e90b647638e309af95 2289 xjadeo_0.4.10-1.debian.tar.gz 44bb0007d23f5a6dddfc2a75f076c8ad00a05f0d 148554 xjadeo_0.4.10-1_i386.deb Checksums-Sha256: 9e002c4d39abf5d9b016a0b3b8ff864d8b7a658c90f81b67a25bab0e8395cbe0 1568 xjadeo_0.4.10-1.dsc 7bd30886c043f96656a052c6b087476532a173cbaab8fbfe8056d401fcdf2aae 326525 xjadeo_0.4.10.orig.tar.gz 05bb765232e8d40ffa4a55b6044e4df06b892b4012b3f882e61ac5137adefeda 2289 xjadeo_0.4.10-1.debian.tar.gz e47e7ff8a4ce9627fbc7e7e429d3ca4d2eaa4e49d64cc8f430171a692350632a 148554 xjadeo_0.4.10-1_i386.deb Files: f5b3a9f169871b94ce524f94425d1ccb 1568 sound optional xjadeo_0.4.10-1.dsc 9dfa7c09b62fff64ade775d09d3d8d4b 326525 sound optional xjadeo_0.4.10.orig.tar.gz 4a5f073eae903fce02d187a63ae8fb24 2289 sound optional xjadeo_0.4.10-1.debian.tar.gz 2ee36065c2c0f9f65c5a566bbd60cc4d 148554 sound optional xjadeo_0.4.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkw65N0ACgkQRdSMfNz8P9D4mwCfT2sDS4A8HlHYKq2KTDhMkCOz G4YAn3zrGkTbIffLqmBoLUsBjzHwZDRJ =Z05b -END PGP SIGNATURE- ---End Message--- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
[sorry for the resent, it seems the CC line was wrong in the previous mail] On Mon, Jul 12, 2010 at 14:54:53 (EDT), Rémi Denis-Courmont wrote: Hello, I think it is fair to say that there is increasing frustration from users and developers w.r.t. the state of VLC in Debian Ubuntu. I am left wondering what is the best way forward... Thanks for bringing this up. This has also bugged me for quite some time. 1) Debian stable Some time ago, one of the Debian Security (testing or stable, I honestly don't remember) complained that the VideoLAN project security update process was less than optimal. Guess what? It's been almost 3 months since we released VLC 1.0.6, and still Debian Stable ships the same security holes. If we are doing less than optimal, Debian Stable is doing outright PATHETIC. Well, small focused bugfixes would be ok for a security upload, and I guess even for a point release, but something like updating from 0.8.6 to the 1.1 series would cause an unacceptable risk for regressions. What we could do however is to ask the release team what they prefer: either (of possible, lenny's ffmpeg is pretty dated) updating vlc in stable to 1.0 or 1.1, or have it removed from stable. I guess the release team has done that in a couple of cases so far. 2) Ubuntu current version Sooner or later, someone will find a security hole in VLC 1.0.6. If not for security, there are known critical bugs already. For a start, the Mozilla plugin just crashes. Always. If I understand right, Reinhard considered making a PPA, whereas Benjamin suggested VideoLAN make a PPA. Either way, I am concerned that this will cause a flood of untraceable Apport crash reports. How are we supposed to fix that? Is there some 1.0 release branch that has these security fixes in? In that case, we could (and should!) prepare uploads to the security pockets ASAP! 3) Ubuntu LTS At this point in the spacetime continuum, LTS is the current version. But what should be done in a few months when it's not the case anymore? Apply focused bug and security patches on a best efford basis. 4) Ubuntu older versions Ubuntu happily ships VLC with known security holes. WTH? I think the answer is the same here: If there was some focused release branch, there is no problem in uploading to the either -security or -proposed. If not, we can always provide some PPA and point people at it. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Mon, 12 Jul 2010 23:22:11 +0100, Dmitrijs Ledkovs dmitrij.led...@ubuntu.com wrote: 2010/7/12 Rémi Denis-Courmont r...@remlab.net: Hello, I think it is fair to say that there is increasing frustration from users and developers w.r.t. the state of VLC in Debian Ubuntu. I am left wondering what is the best way forward... 1) Debian stable Some time ago, one of the Debian Security (testing or stable, I honestly don't remember) complained that the VideoLAN project security update process was less than optimal. Guess what? It's been almost 3 months since we released VLC 1.0.6, and still Debian Stable ships the same security holes. If we are doing less than optimal, Debian Stable is doing outright PATHETIC. Ping maintainers and debian security team. Indicate the security issue, the patch and or new tarball. It's not like it's not known: http://security-tracker.debian.org/tracker/status/release/stable It's more like nobody cares. Depending on severity it can either go to -security pocket or later as an update. To effectivly track the issue either a CVE number or DSA report should be filled. 2) Ubuntu current version Sooner or later, someone will find a security hole in VLC 1.0.6. If not for security, there are known critical bugs already. For a start, the Mozilla plugin just crashes. Always. Similar workflow. File a bug in launchpad against vlc package, mark it as security issue provide as much detail as you can. Ubuntu/Canonical security teams will review it and push to -security or -proposed updates - -updates. That solution straight from the text book does simply not work. I don't buy the Debian/Ubuntu PR, at least not anymore. 4) Ubuntu older versions Ubuntu happily ships VLC with known security holes. WTH? In the same security bug add affects multiple ubuntu series. You can see the currently supported releases here https://wiki.ubuntu.com/Releases and you should target the security bug against all currently supported releases on the desktop. All of these still qualify for security updates. Some of those bugs have been open just for many months. Nobody cares. Look at this old example: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/295464 -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Tue, 13 Jul 2010 08:40:09 -0400, Reinhard Tartler siret...@tauware.de wrote: 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 removed. 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. Security-wise: http://www.videolan.org/security/sa1003.html 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: http://git.videolan.org/?p=vlc/vlc-1.0.git;a=summary correct? Yes. 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: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/295464 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? -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of create-resources_0.1.3-3_i386.changes
create-resources_0.1.3-3_i386.changes uploaded successfully to localhost along with the files: create-resources_0.1.3-3.dsc create-resources_0.1.3-3.debian.tar.gz create-resources_0.1.3-3_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
create-resources_0.1.3-3_i386.changes ACCEPTED
Accepted: create-resources_0.1.3-3.debian.tar.gz to main/c/create-resources/create-resources_0.1.3-3.debian.tar.gz create-resources_0.1.3-3.dsc to main/c/create-resources/create-resources_0.1.3-3.dsc create-resources_0.1.3-3_all.deb to main/c/create-resources/create-resources_0.1.3-3_all.deb Override entries for your package: create-resources_0.1.3-3.dsc - source graphics create-resources_0.1.3-3_all.deb - extra graphics Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processed: your mail
Processing commands for cont...@bugs.debian.org: tags 577527 pending Bug #577527 [libzita-convolver-dev] [libzita-convolver-dev] package should depend on libfftw3-dev Ignoring request to alter tags of bug #577527 to the same tags previously set thanks Stopping processing here. Please contact me if you need assistance. -- 577527: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577527 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processed: your mail
Processing commands for cont...@bugs.debian.org: tags 577527 pending Bug #577527 [libzita-convolver-dev] [libzita-convolver-dev] package should depend on libfftw3-dev Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 577527: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577527 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: VLC in debian squeeze
On Tue, Jul 13, 10 at 16:19 +0200, HacKurx wrote: We meet a lot of problems with mkv files in VLC 1.0.6. Can you pass to vlc 1.1 before the freeze Sqeeze packages for debian? It needs to follow the proper process i.e. being old enough and having no rc bugs and having all it depedencies in squeeze This version uses fewer resources and has a support vdpau. Not in sid. It will in experimental soonish. -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
% apt-cache rdepends libvlc2 libvlc2 Reverse Depends: vlc-nox mozilla-plugin-vlc libvlc-dev % apt-cache showsrc vlc-nox libvlc-dev mozilla-plugin-vlc| \ grep Package: | uniq Package: vlc So the ABI issue is a non-issue, since nobody uses libvlc outside of vlc itself. It's no longer true if we consider experimental which has phonon-backend-vlc But upstream is very strict on not breacking ABI between minor release -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Java build-dependency
In csound, we build depend on default-jdk-builddep, which is wrong (as per /usr/share/doc/java-common/README.gcj-native-transition). The correct build dependency is default-jdk (since we are not using gcj to compile java to native code). However, I noticed we resolve the java-enabled archs by parsing rmadison output. However, we match against default-jre-headless. I'm not quite sure this is right... If I understand java correctly, a jre is needed to have a jdk, which means that jre archs might potentially be a superset of jdk archs (perhaps by some timing accident). So I'm thinking we should be resolving against default-jdk, which is what we do actually build-depend on. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processed: your mail
Processing commands for cont...@bugs.debian.org: forcemerge 521768 588747 Bug#521768: ITP: xjadeo -- Video player with jack sync Bug#588747: ITP: xjadeo - Simple video player that receives sync from jackd or MTC Forcibly Merged 521768 588747. thanks Stopping processing here. Please contact me if you need assistance. -- 588747: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588747 521768: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521768 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] zita-convolver2 packaging branch, upstream, updated. debian/2.0.0-3-1-g2d050ec
Hello guys, both zita-convolver and zita-convolver2 repositories are a mess, and the contents of the orig.tar.gz of the current package is not the same of the tar.bz2 available from upstream's homepage. Probably we need to repack the tarball and play a bit with the versioning (I thought to release next package with something like 2.0.0+really2.0.0-1). Any suggestions? -- Alessio Treglia ales...@alessiotreglia.com Debian Ubuntu Developer | Homepage: http://www.alessiotreglia.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] zita-convolver2 packaging branch, upstream, updated. debian/2.0.0-3-1-g2d050ec
On 13/07/10 18:06, Alessio Treglia wrote: Hello guys, both zita-convolver and zita-convolver2 repositories are a mess, and the contents of the orig.tar.gz of the current package is not the same of the tar.bz2 available from upstream's homepage. Probably we need to repack the tarball and play a bit with the versioning (I thought to release next package with something like 2.0.0+really2.0.0-1). Any suggestions? Neither of those packages has been uploaded, so I'd say just trash them and start afresh. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] zita-convolver2 packaging branch, upstream, updated. debian/2.0.0-3-1-g2d050ec
On 13/07/10 18:14, Alessio Treglia wrote: On Wed, Jul 14, 2010 at 12:09 AM, Felipe Sateler fsate...@debian.org wrote: Neither of those packages has been uploaded, so I'd say just trash them and start afresh. Felipe, zita-convolver is available in testing [1], or did you mean trashing old repositories? Hmm, I skipped it. Yes, I meant trashing the repositories. Since the packages are out there already, I don't think it would be nice to break the history for those repositories. Your earlier approach (2.0.0+really2.0.0) is ok, I think. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Java build-dependency
On Tue, Jul 13, 2010 at 04:27:09PM -0400, Felipe Sateler wrote: In csound, we build depend on default-jdk-builddep, which is wrong (as per /usr/share/doc/java-common/README.gcj-native-transition). The correct build dependency is default-jdk (since we are not using gcj to compile java to native code). However, I noticed we resolve the java-enabled archs by parsing rmadison output. However, we match against default-jre-headless. I'm not quite sure this is right... If I understand java correctly, a jre is needed to have a jdk, which means that jre archs might potentially be a superset of jdk archs (perhaps by some timing accident). So I'm thinking we should be resolving against default-jdk, which is what we do actually build-depend on. If I recall correctly (I am busy in Real Life atm and not checking the actual packaging code) we use that same rmadison lookup at two places, only one of them being against the same package as the one looked up but (I believe) both from same source and assumed to be released for same set of arches (ideally that assumption should be mentioned as a comment in debian/rules). It might be, however, that we do not need that lookup any longer: If it is possible to build against GCJ (even if not preferred) then I was told recently that it is available for all arches now so we should be able to ship our code for all arches too. As mentioned in the beginning I am quite busy at the moment, so please just ignore my comments here if it complicates more than it simplifies. Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of zita-convolver_2.0.0really2.0.0-1_i386.changes
zita-convolver_2.0.0really2.0.0-1_i386.changes uploaded successfully to localhost along with the files: zita-convolver_2.0.0really2.0.0-1.dsc zita-convolver_2.0.0really2.0.0.orig.tar.bz2 zita-convolver_2.0.0really2.0.0-1.debian.tar.gz libzita-convolver-dev_2.0.0really2.0.0-1_i386.deb libzita-convolver2_2.0.0really2.0.0-1_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
zita-convolver_2.0.0really2.0.0-1_i386.changes ACCEPTED
Accepted: libzita-convolver-dev_2.0.0really2.0.0-1_i386.deb to main/z/zita-convolver/libzita-convolver-dev_2.0.0really2.0.0-1_i386.deb libzita-convolver2_2.0.0really2.0.0-1_i386.deb to main/z/zita-convolver/libzita-convolver2_2.0.0really2.0.0-1_i386.deb zita-convolver_2.0.0really2.0.0-1.debian.tar.gz to main/z/zita-convolver/zita-convolver_2.0.0really2.0.0-1.debian.tar.gz zita-convolver_2.0.0really2.0.0-1.dsc to main/z/zita-convolver/zita-convolver_2.0.0really2.0.0-1.dsc zita-convolver_2.0.0really2.0.0.orig.tar.bz2 to main/z/zita-convolver/zita-convolver_2.0.0really2.0.0.orig.tar.bz2 Override entries for your package: libzita-convolver-dev_2.0.0really2.0.0-1_i386.deb - optional libdevel libzita-convolver2_2.0.0really2.0.0-1_i386.deb - optional libs zita-convolver_2.0.0really2.0.0-1.dsc - source sound Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 577527 Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#577527: marked as done ([libzita-convolver-dev] package should depend on libfftw3-dev)
Your message dated Tue, 13 Jul 2010 23:32:42 +
with message-id e1oyoxu-0007sl...@franck.debian.org
and subject line Bug#577527: fixed in zita-convolver 2.0.0really2.0.0-1
has caused the Debian Bug report #577527,
regarding [libzita-convolver-dev] package should depend on libfftw3-dev
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
577527: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577527
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: libzita-convolver-dev
Version: 2.0.0-2.1
Severity: normal
--- Please enter the report below this line. ---
package should depend on libfftw3-dev because it is included in
zita-convolver.h.
thanks
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.34-rc3
Debian Release: squeeze/sid
500 unstablemi.mirror.garr.it
500 unstableftp.de.debian.org
500 stable www.emdebian.org
1 experimentalftp.de.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-==
libzita-convolver2 (= 2.0.0-2.1) | 2.0.0-2.1
Package's Recommends field is empty.
Package's Suggests field is empty.
---End Message---
---BeginMessage---
Source: zita-convolver
Source-Version: 2.0.0really2.0.0-1
We believe that the bug you reported is fixed in the latest version of
zita-convolver, which is due to be installed in the Debian FTP archive:
libzita-convolver-dev_2.0.0really2.0.0-1_i386.deb
to main/z/zita-convolver/libzita-convolver-dev_2.0.0really2.0.0-1_i386.deb
libzita-convolver2_2.0.0really2.0.0-1_i386.deb
to main/z/zita-convolver/libzita-convolver2_2.0.0really2.0.0-1_i386.deb
zita-convolver_2.0.0really2.0.0-1.debian.tar.gz
to main/z/zita-convolver/zita-convolver_2.0.0really2.0.0-1.debian.tar.gz
zita-convolver_2.0.0really2.0.0-1.dsc
to main/z/zita-convolver/zita-convolver_2.0.0really2.0.0-1.dsc
zita-convolver_2.0.0really2.0.0.orig.tar.bz2
to main/z/zita-convolver/zita-convolver_2.0.0really2.0.0.orig.tar.bz2
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 577...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Alessio Treglia ales...@debian.org (supplier of updated zita-convolver
package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 14 Jul 2010 01:10:16 +0200
Source: zita-convolver
Binary: libzita-convolver-dev libzita-convolver2
Architecture: source i386
Version: 2.0.0really2.0.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Multimedia Maintainers
pkg-multimedia-maintainers@lists.alioth.debian.org
Changed-By: Alessio Treglia ales...@debian.org
Description:
libzita-convolver-dev - Development files (headers) for libzita-convolver
library
libzita-convolver2 - C++ library implementing a real-time convolution matrix
Closes: 577527
Changes:
zita-convolver (2.0.0really2.0.0-1) unstable; urgency=low
.
[ Jaromír Mikeš ]
* libzita-convolver-dev depends on libfftw3-dev (Closes: #577527)
.
[ Alessio Treglia ]
* ACK NMU.
* Switch to debhelper 7.
* Add ${misc:Depends} macro to libzita-convolver-dev's Depends field.
* Bump Standards.
* Add myself as Uploader.
* Switch to format 3.0 (quilt).
* Add git-buildpackage config file.
* Add git ignore file.
* Add DEP-3-style tags to makefile.patch patch.
* Update watch file.
Checksums-Sha1:
6f9e0454c5d9a610eac0ed4f925d935676f9040f 1577
zita-convolver_2.0.0really2.0.0-1.dsc
0b6c6bee9bfc4c69ce572a01b84163fa4ac5d318 12858
zita-convolver_2.0.0really2.0.0.orig.tar.bz2
a3194bf6f711b86e1f1d179fd7f11c86127e7eed 3657
zita-convolver_2.0.0really2.0.0-1.debian.tar.gz
b3230abe8c68b33d0e80183d80604fb6fce3e156 4732
libzita-convolver-dev_2.0.0really2.0.0-1_i386.deb
449ddad6cd007fdc437a3eaa9deef51484b06e5b 13860
libzita-convolver2_2.0.0really2.0.0-1_i386.deb
Checksums-Sha256:
06836ca39adb3089dd8b459dc8a54eadfe9cd2d3a99d376122128dbb5eb1288b 1577
zita-convolver_2.0.0really2.0.0-1.dsc
a2c9b3a19f24522819ab2ff852915da27cef93b5e32b1a339ece5627ac3c63e4 12858
zita-convolver_2.0.0really2.0.0.orig.tar.bz2
40eaa2fb929a7c1aaad280f41d06b6eec0ce406a7668ab52ef8d1b90e584a15d 3657
Re: [vlc-devel] Debian/Ubuntu VLC
On Tue, Jul 13, 2010 at 10:01:13 (EDT), Rémi Denis-Courmont wrote: Ping maintainers and debian security team. Indicate the security issue, the patch and or new tarball. It's not like it's not known: http://security-tracker.debian.org/tracker/status/release/stable it lists 4 CVEs: CVE-2010-1441 - 1445, all of them only affecting the 0.8 series and without any details. So this piece of information is pretty useless for identifying missing changes in 0.8.x. A tad more insightful is http://www.videolan.org/security/sa1003.html, which at least mentions: - Heap buffer overflow vulnerability in A/52, DTS and MPEG Audio decoders - Invalid memory access in AVI, ASF, Matroska (MKV) demuxers - Invalid memory access in XSPF playlist parser - Invalid memory access in ZIP archive decompressor - Heap buffer overflow in RTMP access I guess each of them match to the respective CVE number. BTW, this is only half the story you mentioned in the beginning of this thread. It's more like nobody cares. I dont't think that's accurate. I'd rather guess that there is no one in the distro camp that knows how to match these 5 issues to patches that fix them. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Tue, Jul 13, 2010 at 10:13:22 (EDT), Rémi Denis-Courmont wrote: On Tue, 13 Jul 2010 08:40:09 -0400, Reinhard Tartler siret...@tauware.de wrote: 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 removed. 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. Security-wise: http://www.videolan.org/security/sa1003.html as indicated in my other mail, still seems rather non-trivial to me. 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: http://git.videolan.org/?p=vlc/vlc-1.0.git;a=summary correct? Yes. 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: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/295464 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. That's sad to hear. 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? Well, I don't know what went wrong with the CVE numbers in VLC SA 1003, but AFAIUI they handed out the number reservations fairly quickly. I'm not sure what the exact process is for getting proper CVE reports but me it looks like this process somehow got stalled. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: VLC in debian squeeze
On Tue, Jul 13, 2010 at 10:19:54 (EDT), HacKurx wrote: Hi, We meet a lot of problems with mkv files in VLC 1.0.6. Can you pass to vlc 1.1 before the freeze Sqeeze packages for debian? This version uses fewer resources and has a support vdpau. Thank you for your work. http://release.debian.org/migration/testing.pl?package=vlc -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] snd packaging branch, master, updated. debian/11.7-1-2-g96ae8f5
On Tue, Jul 13, 2010 at 12:25:24 (EDT), mira-gu...@users.alioth.debian.org wrote: +Files: ./DotEmacs +Copyright: 2001 Fernando Lopez Lezcano na...@ccrma.stanford.edu +License: no licence mentioned pedantic uh, does no license mean all rights reserved and are we actually allowed to redistribute it? /pedantic more seriously, are files in that directory installed in the binary package? asking because this package was just rejected for missing copyright statements. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
