Bug#681187: supercollider-emacs: unowned files after purge (policy 6.8, 10.8)
Package: supercollider-emacs Version: 1:3.5.3~repack-1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. From the attached log (scroll to the bottom...): 1m24.2s ERROR: FAIL: Package purging left files on system: /usr/share/emacs23/site-lisp/ owned by: emacs23-common /usr/share/emacs23/site-lisp/SuperCollider/not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-browser.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-dev.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-document.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-help.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-interp.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-keys.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-language.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-menu.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-minor-mode.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-mode.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-server.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-util.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-vars.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang-widgets.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/sclang.elc not owned /usr/share/emacs23/site-lisp/SuperCollider/tree-widget.elc not owned cheers, Andreas supercollider-emacs_1:3.5.3~repack-1.log.gz Description: GNU Zip compressed data ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#681136: libavcodec-extra-53: Cannot install libavcodec-extra-53 without losing kde
Am 10.07.2012 22:47, schrieb Graham Cobb: I speculate that some kde package has a dependency on libavcodec53. Should libavcodec-extra-53 provide libavcodec53? Packages in Debian should always have alternative dependdencied on both, i.e. libavcodec53| libavcodec-extra-53. Do you have packages from other repositories installed? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Fixing #654506 and #674386 in Wheezy
Hi, We would like to fix #654506 and #674386 in Wheezy. Unfortunately, we are not able to accept supercollider/1:3.5.2-1 from Unstable since the changes are quite large. Usually, we ask the maintainer to prepare an upload based on testing's source package and targeting testing-proposed-updates. But for this specific case, I'm not sure what would the best step forward as you seem not interested in fixing #674386 (cf. [1]). Since the package has not been part of any previous stable release, one solution could be to remove this package from testing. What do you think? Regards, [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674386#10 -- Mehdi Dogguy مهدي الدڤي ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Fixing #654506 and #674386 in Wheezy
Am 11.07.2012 14:20, schrieb Mehdi Dogguy: We would like to fix #654506 and #674386 in Wheezy. Unfortunately, we are not able to accept supercollider/1:3.5.2-1 from Unstable since the changes are quite large. Usually, we ask the maintainer to prepare an upload based on testing's source package and targeting testing-proposed-updates. But for this specific case, I'm not sure what would the best step forward as you seem not interested in fixing #674386 (cf. [1]). From a quick glance it looks like fixing #674386 would be as easy as doing 's/DEB_BUILDDIR/DEB_SRCDIR/' in debian/rules. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-10 18:06, wbrana wrote: On 7/9/12, wbrana wbr...@gmail.com wrote: I managed temporary to change limits from command line, but I/O priority can't be increased x@debian:~$ mplayer_nice cant set I/O priority MPlayer svn r34540 (Debian), built with gcc-4.7 (C) 2000-2012 MPlayer Team I submitted kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=44371 It seems limits can't be used. I have got reply: CAP_SYS_ADMIN is required to set rt classes btw, why do you need mplayer_nice in the first place? afaiu, qemplayer is an qt frontend to mplayer, and does not need realtime I/O priorities any more than mplayer itself. looking at the code of qemplayer, i also see that the program will indeed work without mplayer_nice installed. so one possibility would be to drop the qemplayer_nice binary from the qemplayer binary package. mplayer_nice could be provided by a separate binary package (hopefully with some non-suid solution) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/9ds8ACgkQkX2Xpv6ydvS0dgCfd/V8bt9ZA0jXMMLbEoYQltHE 3UUAoMqmXPhjhKuUNn85fqbWNPt8xrUM =fBWm -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Fixing #654506 and #674386 in Wheezy
Hi - It's easy to fix #654506 because supercollider never used waf so the file can simply be deleted in repacking a ~dfsg version, and build will still work fine. I don't want to work on #674386 because working on the scons build is a waste of time when we've junked it long ago, and the bug is apparently caused by a limitation in dh's handling of scons, i.e. not code I have any expertise in. Does anyone have a patch that might fix it? If so then maybe we can go for it. Dan 2012/7/11 Mehdi Dogguy me...@dogguy.org: Hi, We would like to fix #654506 and #674386 in Wheezy. Unfortunately, we are not able to accept supercollider/1:3.5.2-1 from Unstable since the changes are quite large. Usually, we ask the maintainer to prepare an upload based on testing's source package and targeting testing-proposed-updates. But for this specific case, I'm not sure what would the best step forward as you seem not interested in fixing #674386 (cf. [1]). Since the package has not been part of any previous stable release, one solution could be to remove this package from testing. What do you think? Regards, [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674386#10 -- Mehdi Dogguy مهدي الدڤي ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Fixing #654506 and #674386 in Wheezy
2012/7/11 Fabian Greffrath fab...@greffrath.com: Am 11.07.2012 14:20, schrieb Mehdi Dogguy: We would like to fix #654506 and #674386 in Wheezy. Unfortunately, we are not able to accept supercollider/1:3.5.2-1 from Unstable since the changes are quite large. Usually, we ask the maintainer to prepare an upload based on testing's source package and targeting testing-proposed-updates. But for this specific case, I'm not sure what would the best step forward as you seem not interested in fixing #674386 (cf. [1]). From a quick glance it looks like fixing #674386 would be as easy as doing 's/DEB_BUILDDIR/DEB_SRCDIR/' in debian/rules. Aha thanks - will try this later. Dan ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Fixing #654506 and #674386 in Wheezy
On Wed, Jul 11, 2012 at 8:20 AM, Mehdi Dogguy me...@dogguy.org wrote: Hi, We would like to fix #654506 and #674386 in Wheezy. Unfortunately, we are not able to accept supercollider/1:3.5.2-1 from Unstable since the changes are quite large. I think you mean 1:3.5.3~repack-1? That is what's currently in unstable, and 1:3.5.2-1 was uploaded before the freeze. Unfortunately, it couldn't migrate because it failed to build on non-x86 archs. We are currently working on fixing that. So, in a way, the changes are not that large ;). I had planned to mail d-r after we got the last round of fixes ready. Is there a chance we can convince you to let 3.5.3 migrate to testing? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Supercollider fails to build
2012/7/11 Felipe Sateler fsate...@debian.org: On Wed, Jul 11, 2012 at 3:21 AM, Dan S danstowell+de...@gmail.com wrote: A fix for issue 2 will be along in a week or two, after the developer has integrated an updated source file. Any temporary fix we can apply? The longer we take to fix this, the less likely the release managers are going to give sc an exception. For issue 3, we don't have an ia64 to test on, but it looks to me like the attached patch might fix it. Shall I push it? Maybe it is better to do it the other way around. Special case the cases that are known to work and enable it? True BTW, any reason you replied to me personally instead of the list? I was convinced you'd emailed offlist - but I was wrong. I'm on-listing this now. Dan ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Fixing #654506 and #674386 in Wheezy
On 11/07/12 16:01, Felipe Sateler wrote: On Wed, Jul 11, 2012 at 8:20 AM, Mehdi Dogguyme...@dogguy.org wrote: Hi, We would like to fix #654506 and #674386 in Wheezy. Unfortunately, we are not able to accept supercollider/1:3.5.2-1 from Unstable since the changes are quite large. I think you mean 1:3.5.3~repack-1? Yes, sorry. It was a bad copy/paste :/ That is what's currently in unstable, and 1:3.5.2-1 was uploaded before the freeze. Unfortunately, it couldn't migrate because it failed to build on non-x86 archs. We are currently working on fixing that. So, in a way, the changes are not that large ;). We don't seem to have the same definition of large. For this specific case, the changes between the unblocked version and sid's current version look like: $ debdiff supercollider_3.5.2-1.dsc supercollider_3.5.3~repack-1.dsc \ | diffstat | tail -n1 3040 files changed, 5266 insertions(+), 581639 deletions(-) This pretty looks as large. Ignoring the bits that were deleted when repacking, the debian/ directory, etc… this leads us to: 53 files changed, 746 insertions(+), 701 deletions(-) which is nicer indeed but still qualifies as large. Why did you import 3.5.3 instead of working on fixing 3.5.2? (I'm not sure it is relevant now but that might help us to understand the situation better). I had planned to mail d-r after we got the last round of fixes ready. Is there a chance we can convince you to let 3.5.3 migrate to testing? We would prefer targeted fixes based on the version of testing. Kind Regards, -- Mehdi Dogguy مهدي الدڤي ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
hiii
___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
btw, why do you need mplayer_nice in the first place? afaiu, qemplayer is an qt frontend to mplayer, and does not need realtime I/O priorities any more than mplayer itself. mplayer_nice is key feature of qemplayer. Realtime I/O priority for MPlayer is needed when some other application is fully loading hard drive. It prevents empty buffer in MPlayer. Nice -20 ensures that MPlayer always gets needed CPU time if some other application fully loading CPU. mplayer_nice could be provided by a separate binary package I will consider it. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Fixing #654506 and #674386 in Wheezy
On Wed, Jul 11, 2012 at 10:30 AM, Mehdi Dogguy me...@dogguy.org wrote: On 11/07/12 16:01, Felipe Sateler wrote: On Wed, Jul 11, 2012 at 8:20 AM, Mehdi Dogguyme...@dogguy.org wrote: Hi, We would like to fix #654506 and #674386 in Wheezy. Unfortunately, we are not able to accept supercollider/1:3.5.2-1 from Unstable since the changes are quite large. I think you mean 1:3.5.3~repack-1? Yes, sorry. It was a bad copy/paste :/ That is what's currently in unstable, and 1:3.5.2-1 was uploaded before the freeze. Unfortunately, it couldn't migrate because it failed to build on non-x86 archs. We are currently working on fixing that. So, in a way, the changes are not that large ;). We don't seem to have the same definition of large. For this specific case, the changes between the unblocked version and sid's current version look like: $ debdiff supercollider_3.5.2-1.dsc supercollider_3.5.3~repack-1.dsc \ | diffstat | tail -n1 3040 files changed, 5266 insertions(+), 581639 deletions(-) This pretty looks as large. Ignoring the bits that were deleted when repacking, the debian/ directory, etc… this leads us to: 53 files changed, 746 insertions(+), 701 deletions(-) which is nicer indeed but still qualifies as large. I made some local git branches with the upstream source of 3.5.2 and 3.5.3, with patches applied. Updating to 3.5.3 allowed us to drop all the 3.5.2 patches: $ git show --stat 3.5.2-withpatches'^' | tail -1 7 files changed, 135 insertions(+), 100 deletions(-) So, taking into account this, the stat becomes: $ git diff 3.5.2-withpatches..3.5.3-withpatches --stat \ | tail -1 52 files changed, 631 insertions(+), 198 deletions(-) However, a big chunk of that is documentation updates: $ git diff 3.5.2-withpatches..3.5.3-withpatches --stat \ -- HelpSource/| tail -1 18 files changed, 439 insertions(+), 131 deletions(-) That leaves as with a diff of: 34 files changed, 192 insertions(+), 67 deletions(-) Of that, most of it is bugfixes, and an un-deprecation of a few methods. Why did you import 3.5.3 instead of working on fixing 3.5.2? (I'm not sure it is relevant now but that might help us to understand the situation better). Mostly because it allowed us to drop the patches we had. Also, upstreams release management seems sane enough, commits on the 3.5 branch are mostly cherry-picked from the master branch plus documentation fixes. I had planned to mail d-r after we got the last round of fixes ready. Is there a chance we can convince you to let 3.5.3 migrate to testing? We would prefer targeted fixes based on the version of testing. I understand. But on the other hand, we would prefer shipping upstreams latest version, which is why I asked if there was a chance we could convince you. In particular, since 3.5 sc has a new Qt based widget system, and debian does not have any other sc widget system (AFAICT, they were all third party), wheezy users would not be able to build SC GUIs. Dan can probably tell of more advantages of 3.5 over 3.4. That's why I asked if there was a chance that we could convince you. I wasn't asking if we had clearance yet. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
On Wed, Jul 11, 2012 at 6:11 PM, wbrana wbr...@gmail.com wrote: btw, why do you need mplayer_nice in the first place? afaiu, qemplayer is an qt frontend to mplayer, and does not need realtime I/O priorities any more than mplayer itself. mplayer_nice is key feature of qemplayer. Realtime I/O priority for MPlayer is needed when some other application is fully loading hard drive. It prevents empty buffer in MPlayer. Why can't this be properly solved in mplayer2/mplayer instead of in some frontend? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
On 7/11/12, Reinhard Tartler siret...@gmail.com wrote: On Wed, Jul 11, 2012 at 6:11 PM, wbrana wbr...@gmail.com wrote: mplayer_nice is key feature of qemplayer. Realtime I/O priority for MPlayer is needed when some other application is fully loading hard drive. It prevents empty buffer in MPlayer. Why can't this be properly solved in mplayer2/mplayer instead of in some frontend? Try to ask MPlayer developers. I'm not one of them. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
ITA: freej frei0r
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, i followed some discussion on the frei0r (minimalist api for free video effects) mailinglist [1], that indicated that the current frei0r packages in debian are horribly out of date. given that the current maintainer is willing to hand over the package (and another-one freej, a cmdline VC application) (see below), i would like to maintain those packages under the umbrella of the pkg-multimedia-team. it seems that jonas already contacted luca a while ago about frei0r, so i think there is already a team :-) what do you think? fgamsdr IOhannes [1] http://lists.dyne.org/lurker/thread/20120710.171208.0fef7c01.en.html On 2012-07-11 18:57, forum::für::umläute wrote: On 2012-07-11 18:48, Luca Bigliardi wrote: Hi Iohannes, thanks for the quick response I'll be happy if frei0r and freej packages will get a new maintainer. Please note that around Februrary Jonas Smedegaard d...@jones.dk asked to jump in and work on frei0r packages. You might want to get in contact with him to avoid duplicating efforts. ah that's cool. i'm working together with jonas on a number of pkg-multimedia packages, so bundling our efforts rather than duplicating them should be natural. i imported the history of the two packages using git-import-dscs (we are using git for packaging), but if you have a vcs for the packaging on which to build, that would be even better. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/9scUACgkQkX2Xpv6ydvR8HwCgwV27EHeUOnEhkyKgl0ExrTee 3TcAoNedw09zYyCUV05waCQU0jDd/Csp =H9PJ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: ITA: freej frei0r
On 12-07-11 at 07:03pm, IOhannes m zmoelnig wrote: i followed some discussion on the frei0r (minimalist api for free video effects) mailinglist [1], that indicated that the current frei0r packages in debian are horribly out of date. given that the current maintainer is willing to hand over the package (and another-one freej, a cmdline VC application) (see below), i would like to maintain those packages under the umbrella of the pkg-multimedia-team. it seems that jonas already contacted luca a while ago about frei0r, so i think there is already a team :-) what do you think? Yesss! I have a git for frei0r (from my NMU in february). I'll dust it off and push it! I also look at freej a while back (if I recall correctly I even looked at it before it was put into Debian). I'd be happy to work with you on those, IOhannes. - 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#681136: libavcodec-extra-53: Cannot install libavcodec-extra-53 without losing kde
On Wednesday 11 July 2012 10:20:37 Fabian Greffrath wrote: Packages in Debian should always have alternative dependdencied on both, i.e. libavcodec53| libavcodec-extra-53. Do you have packages from other repositories installed? The problem appears to have been that I had not succeeded in removing all Marillat's packages, despite trying to make sure I had before reporting the bug. In particular, I still had vlc packages installed which were preventing phonon-backend-vlc from upgrading. After reinstalling all the vlc (and xine) related packages I was able to install libavcodec-extra-53. I still think it would have been easier if libavcodec-extra-53 had either Provides: libavcodec53 or, even better, really was just extras without replacing libavcodec53 at all. However, I am sure you have good reasons for this packaging. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#681136: Should libavcodec-extra-53 Provides: libavcodec53? [Was: Re: Bug#681136: libavcodec-extra-53: Cannot install libavcodec-extra-53 without losing kde]
The problem appears to have been that I had not succeeded in removing all Marillat's packages, despite trying to make sure I had before reporting I suspected this. :) After reinstalling all the vlc (and xine) related packages I was able to install libavcodec-extra-53. At least. I still think it would have been easier if libavcodec-extra-53 had either Provides: libavcodec53 or, even better, really was just extras without I don't see any reason against this approach but leave it up for discussion with the other team members (then this big should get closed). replacing libavcodec53 at all. However, I am sure you have good reasons for this packaging. Unfortunately, it is not possible to package the extra parts alone, so both libraries need to replace each other. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Newcomer to vlc
Hi Guys, I am Hor Jiun Shyong here. I just joined the vlc package mailing list. I would like to offer my assistance for any help needed for the package. Many thanks. -- Regards, Hor Jiun Shyong 何俊雄 Blog: jiunshyong.dyndns.org twitter.com/jiunshyong facebook.com/jiunshyong I'm an FSF member -- Help us support software freedom! http://www.fsf.org/jf?referrer=2442 Knowing is not enough, we must apply. Willing is not enough, we must do - Bruce Lee. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
