Bug#883731: audacious: Debian packaging has incorrect license
On Tue, 12 Dec 2017 16:39:28 -0500 Nicholas D Steeves wrote: [...] > This is one of the reasons the FSF demands copyright > assignment for their projects...they want to be able to relicense at > any point in the future without having to contact and document consent > from all contributors. Yeah, right: they want to do what they like, without asking whether the contributors are fine with their decisions... Personally, I consider this FSF copyright assignment policy a very bad practice! But I am digressing... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpsad7ZO_2Fo.pgp Description: PGP 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#883731: audacious: Debian packaging has incorrect license
On Sun, 10 Dec 2017 18:12:39 -0500 Nicholas D Steeves wrote: [...] > GPL-incompatible 2-clause BSD [...] A nitpick: the 2-clause BSD license is not GPL-incompatible (it's indeed compatible with the GNU GPL). It's just a distinct license with different (and much simpler) wording... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpVH4jDYqOqr.pgp Description: PGP 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#883731: audacious: Debian packaging has incorrect license
On Thu, 7 Dec 2017 22:39:41 -0500 Nicholas D Steeves wrote: > Dear Debian Legal Team, Hello Nicholas, John, and everybody else reading this. I would like to send some comments of mine, here. Please note that: not only I am not a lawyer, but, even more importantly, I am not your lawyer, nor a lawyer of the Debian Project. Also, I am not a member of the Debian Project: I am just a Debian external contributor, who happens to be a regular on the debian-legal mailing list... > > I've CCed you for my reply to this bug, because I don't have the > experience to be able to tell if Debian implicitly relicensed > Audacious as GPL-3 from 2012-2016, As far as I can tell, *maybe* the implicit re-licensing was done by distributing the audacious Debian package with the incorrect debian/copyright file. > how potentially falling out of > BSD-2-clause license compliance might have affected this, Failing to retain the license text in the package distribution is in fact lack of compliance with the 2-clause BSD license, I would say... > and also how > this should be resolved. The Debian packaging is GPL-2+, so it's > possible to move to copyright-format/1.0 if that would simplify > things. I personally think that the first thing to do is an accurate copyright and licensing status review of the audacious package, so that the debian/copyright file may be fixed to reflect the actual current state of affairs. The Audacious upstream developers may be willing to help, by clarifying any doubts upon request. This may be a perfect opportunity to switch to the [machine readable] format. [machine readable]: <https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/> After a fixed audacious package is uploaded to Debian unstable and migrates to Debian testing, the most offending issue should be solved, I suppose. At that point, the Audacious upstream developers may be willing to forgive the Debian Project for the past incorrect copyright information. If that is deemed to be needed or useful, it could be feasible to also fix the debian/copyright file for audacious version 3.7.2 in a Debian stable update (and possibly also address the same issue for oldstable)... On the other hand, this extra effort could perhaps be considered not worth doing. > Also, please reply to point 2. OTTO "ancient plugins...under > different licenses. I assume audacious-plugins will also need a > copyright review. Probably. > Please CC John and I, Bug #883731, and > debian-legal as appropriate. Done. I hope my comments may help. Bye and thanks to the Debian Multimedia Maintainers for the time they spend in maintaining a number of great Debian packages, and to the Audacious upstream developers for the time they spend in developing/maintaining that very nice audio player (that I personally use everyday!). Thank you! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpB9wo_6cnM8.pgp Description: PGP 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#848285: jackd2: spits verbose output and exits immediately when the client stops sending audio
On Sun, 18 Dec 2016 22:56:00 + James Cowgill wrote: [...] > On 15/12/16 23:18, Francesco Poli (wintermute) wrote: [...] > > I experienced a grave bug: as soon as the client (audacious, firefox through > > ALSA redirection in ~/.asoundrc, ...) stops sending audio to the jackd > > sound server, the latter spits a bunch of output messages and exits > > immediately (as if the --temporary option were passed, no!, even worse!). > > Firstly, apologies for not testing this fully before uploading the most > recent version :/ It may happen. It's weird that nobody noticed in unstable, before the package managed to migrate to testing, but anyway... > > This appears this is a toolchain bug. Simply recompiling the latest > version of jackd2 with gcc-6_6.2.0-6 (the version the -3 revision was > compiled with) makes it work again. The toolchain bug will probably need > reducing before anyone can look at it however. Good that you are able to reproduce the bug and managed to pinpoint the cause. I hope this can be fixed soon. Thanks for your helpfulness! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpLMVIIWfL_x.pgp Description: PGP 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#848285: jackd2: spits verbose output and exits immediately when the client stops sending audio
Package: jackd2 Version: 1.9.10+20150825git1ed50c92~dfsg-4 Severity: grave Justification: renders package unusable Hello and thanks for maintaining jackd2! After the upgrade [UPGRADE] jackd2:amd64 1.9.10+20150825git1ed50c92~dfsg-3 -> 1.9.10+20150825git1ed50c92~dfsg-4 [UPGRADE] jackd2-firewire:amd64 1.9.10+20150825git1ed50c92~dfsg-3 -> 1.9.10+20150825git1ed50c92~dfsg-4 [UPGRADE] libjack-jackd2-0:amd64 1.9.10+20150825git1ed50c92~dfsg-3 -> 1.9.10+20150825git1ed50c92~dfsg-4 I experienced a grave bug: as soon as the client (audacious, firefox through ALSA redirection in ~/.asoundrc, ...) stops sending audio to the jackd sound server, the latter spits a bunch of output messages and exits immediately (as if the --temporary option were passed, no!, even worse!). Steps to reproduce: 0) run jackd with the following command line: $ jackd --realtime -d alsa --device hw:1 --softmode --hwmeter --rate 44100 & 1) run, e.g., audacious (configured to use the Jack output plugin) 2) play some audio: everything seems to work, even though jackd seems to have become more verbose than ever, with a long sequence of output lines similar to: [...] Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10 [...] 3) click on the stop button in the audacious interface: jackd spits the following output and exits immediately: Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10 Jack: JackRequest::DeactivateClient Jack: JackEngine::ClientDeactivate ref = 2 name = audacious Jack: JackEngine::PortDisconnect ref = -1 src = 9 dst = 65535 Jack: JackEngine::PortDisconnect ref = -1 src = 9 dst = 3 Jack: JackGraphManager::Disconnect port_src = 9 port_dst = 3 Jack: JackConnectionManager::Disconnect port_src = 9 port_dst = 3 Jack: JackConnectionManager::Disconnect port_src = 3 port_dst = 9 Jack: JackConnectionManager::DecConnectionRef: ref1 = 2 ref2 = 0 Jack: JackEngine::ClientNotify: no callback for notification = 12 Jack: JackEngine::ClientNotify: no callback for notification = 12 Jack: JackEngine::ClientNotify: no callback for notification = 12 Jack: JackEngine::PortDisconnect ref = -1 src = 10 dst = 65535 Jack: JackEngine::PortDisconnect ref = -1 src = 10 dst = 4 Jack: JackGraphManager::Disconnect port_src = 10 port_dst = 4 Jack: JackConnectionManager::Disconnect port_src = 10 port_dst = 4 Jack: JackConnectionManager::Disconnect port_src = 4 port_dst = 10 Jack: JackConnectionManager::DirectDisconnect last: ref1 = 2 ref2 = 0 Jack: JackConnectionManager::DecConnectionRef: ref1 = 2 ref2 = 0 Jack: JackEngine::ClientNotify: no callback for notification = 12 Jack: JackEngine::ClientNotify: no callback for notification = 12 Jack: JackEngine::ClientNotify: no callback for notification = 12 Jack: JackEngine::ClientNotify: no callback for notification = 10 Jack: JackEngine::ClientNotify: no callback for notification = 10 Jack: JackEngine::ClientNotify: no callback for notification = 10 Jack: JackEngine::ClientNotify: no callback for notification = 10 Jack: JackEngine::ClientNotify: no callback for notification = 10 Jack: JackEngine::ClientNotify: no callback for notification = 10 Jack: JackConnectionManager::DirectDisconnect last: ref1 = 2 ref2 = 1 Jack: JackGraphManager::DisconnectRefNum cur_index = 3 ref1 = 2 ref2 = 1 Jack: JackConnectionManager::DirectDisconnect last: ref1 = 1 ref2 = 2 Jack: JackGraphManager::DisconnectRefNum cur_index = 3 ref1 = 1 ref2 = 2 Jack: JackPosixProcessSync::TimedWait time out = 464380 Jack: JackPosixProcessSync::TimedWait finished delta = 16446.0 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9 Jack: JackRequest::Notification Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel notify = 18 Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel notify = 18 Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel notify = 18 Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel notify = 18 Jack: JackEngine::ClientNotify: no callback for notification = 4 Jack: JackEngine::ClientNotify: no callback for notification = 4 Jack: JackEngine::ClientNotify: no callback for notification = 4 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd =
Bug#822579: inkscape: may mess up with hatches, when importing DXF files
Package: inkscape Version: 0.91-7+b2 Severity: normal Hello and thanks for maintaining Inkscape in Debian! I noticed an issue with the DXF import function. It may mess up badly with the hatches, when importing DXF files. Please take a look at the attached minimal test case. File section.dxf has been created with package librecad: it includes a polyline (that consists of a segment and two circular arcs) and a hatch. File section.pdf has been created with the PDF export function of librecad. The hatch looks OK. Now, if I try to import the DXF with inkscape: $ inkscape section.dxf I see the polyline rendered fine, but the hatch is totally messed up! The hatch pattern is not the right one and the hatched area is absolutely different from the original one! Please see file section_asseenbyinkscape.pdf, obtained from inkscape. Please investigate and/or forward my bug report upstream, as appropriate. Thanks for your time. Bye! P.S.: I think the attached test case is so trivial that it cannot be considered copyrighted; hence, no license from me should be required, in order for anyone to do anything he/she wishes with it. Anyway, should this turn out to not be true, I hereby release my minimal test case in the public domain with the CC0 declaration: https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages inkscape depends on: ii gconf-service 3.2.6-3 ii libaspell150.60.7~20110707-3+b1 ii libatk1.0-02.20.0-1 ii libatkmm-1.6-1v5 2.24.2-1 ii libc6 2.22-7 ii libcairo2 1.14.6-1+b1 ii libcairomm-1.0-1v5 1.12.0-1+b1 ii libcdr-0.1-1 0.1.2-2 ii libexif12 0.6.21-2 ii libfontconfig1 2.11.0-6.4 ii libfreetype6 2.6.3-3+b1 ii libgc1c2 1:7.4.2-7.4 ii libgcc11:5.3.1-14 ii libgconf-2-4 3.2.6-3 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libglib2.0-0 2.48.0-1 ii libglibmm-2.4-1v5 2.48.1-1 ii libgnomevfs2-0 1:2.24.4-6.1+b1 ii libgomp1 5.3.1-14 ii libgsl22.1+dfsg-2 ii libgtk2.0-02.24.30-1.1 ii libgtkmm-2.4-1v5 1:2.24.4-2+b1 ii libgtkspell0 2.0.16-1.1 ii libjpeg62-turbo1:1.4.2-2 ii liblcms2-2 2.7-1 ii libmagick++-6.q16-5v5 8:6.8.9.9-7+b2 ii libmagickcore-6.q16-2 8:6.8.9.9-7+b2 ii libmagickwand-6.q16-2 8:6.8.9.9-7+b2 ii libpango-1.0-0 1.40.1-1 ii libpangocairo-1.0-01.40.1-1 ii libpangoft2-1.0-0 1.40.1-1 ii libpangomm-1.4-1v5 2.40.0-1 ii libpng16-161.6.21-2 ii libpoppler-glib8 0.38.0-2+b1 ii libpoppler57 0.38.0-2+b1 ii libpopt0 1.16-10 ii librevenge-0.0-0 0.0.4-4 ii libsigc++-2.0-0v5 2.8.0-1 ii libstdc++6 5.3.1-14 ii libvisio-0.1-1 0.1.5-1 ii libwpg-0.3-3 0.3.1-1 ii libx11-6 2:1.6.3-1 ii libxml22.9.3+dfsg1-1 ii libxslt1.1 1.1.28-2.1 pn python:any ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages inkscape recommends: ii aspell0.60.7~20110707-3+b1 ii imagemagick 8:6.8.9.9-7+b2 ii libgnomevfs2-extra1:2.24.4-6.1+b1 ii libimage-magick-perl 8:6.8.9.9-7 ii libwmf-bin0.2.8.4-10.5+b1 ii pstoedit 3.70-1 ii python-lxml 3.6.0-1 ii python-numpy 1:1.11.0-1 ii transfig 1:3.2.5.e-6 Versions of packages inkscape suggests: ii dia 0.97.3-1+b1 pn libsvg-perl pn libxml-xql-perl pn python-uniconvertor ii ruby 1:2.3.0+4 -- no debconf information section.pdf Description: Adobe PDF document 999 dxfrw 0.6.3 0 SECTION 2 HEADER 9 $ACADVER 1 AC1021 9 $DWGCODEPAGE 3 ANSI_1252 9 $INSBASE 10 0 20 0 30 0 9 $EXTMIN 10 0 20 0 30 0 9 $EXTMAX 10 168.1851145038168 20 99.5 30 0 9 $LIMMIN 10 0 20 0 9 $LIMMAX 10 420 20 297 9 $ORTHOMODE 70 0 9 $REGENMODE 70 1 9 $FILLMODE 70 1 9 $QTEXTMODE 70 0 9 $MIRRTEXT 70 0 9 $LTSCALE 40 1 9 $ATTMODE 70 0 9 $TEXTSIZE 40 2.5 9 $TRACEWID 40 15.68 9 $TEXTSTYLE 7 STANDARD 9 $CLAYER 8 0 9 $CELTYPE 6 BYLAYER 9 $CECOLOR 62 256 9 $CELTSCALE 40 1 9 $DISPSILH 70 0 9 $DIMSCALE 40 2.5 9 $DIMASZ 40 2.5 9 $DIMEXO 40 0.625 9 $DIMDLI 40 3.75 9 $DIMRND 40 0 9 $DIMDLE 40 0 9 $DIMEXE 40 1.25 9 $DIMTP 40 0 9 $DIMTM 40 0 9 $DIMTXT 40 2.5 9 $DIMCEN 40 2.5 9 $DIMTSZ 40 0 9 $DIMTOL 70 0 9 $DIMLIM 70 0 9 $DIMTIH
Re: inquery about "GPL with commercial exception"
On Thu, 8 Oct 2015 17:06:22 +0200 IOhannes m zmölnig (Debian/GNU) wrote: [...] > which throws us back to the question whether software under that > license is distributable (in non-free) at or not. Just to be clear, my own personal opinion is that "GPLv2 + restrictions" is self-contradictory and thus possibly void: I would not consider software released under such terms as safely distributable. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp_BZSCYmczg.pgp Description: PGP 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: inquery about "GPL with commercial exception"
On Wed, 30 Sep 2015 09:45:26 +0200 IOhannes m zmölnig (Debian/GNU) wrote: > On 2015-09-30 02:18, Ben Finney wrote: > > Yes, that is clearly what the GPL calls an “additional restriction” > > on the recipient's exercise of their freedoms guaranteed by the > > GPL. > > > > GPLv2 §6: > > > > Each time you redistribute the Program (or any work based on the > > Program), the recipient automatically receives a license from the > > original licensor to copy, distribute or modify the Program > > subject to these terms and conditions. You may not impose any > > further restrictions on the recipients' exercise of the rights > > granted herein. You are not responsible for enforcing compliance by > > third parties to this License. > > hmm, frankly i don't see how this is very relevant here. > the original licensor (the linuxsampler devs) grants a license to all > recipients. this license includes the "restriction". > the "YOU" in the license only refers to the recipients who would like > to pass on the software to other recipients. they may not add any > "additional" restriction to the license as given by the original licenso > r. > so if "we" (Debian) don't add further restrictions, that should be fine. I personally think it is indeed relevant. Let me try to explain. The term "further restrictions" is meant "with respect to the GPL terms", not "with respect to GPL terms + any terms added by the copyright holder". Hence releasing software under "GPL + further restrictions" creates a self-contradictory license, where anyone willing to redistribute has to comply with the following conditions: • redistribute under the GPL terms • do not impose any further restriction (with respect to the GPL) • do not drop the restrictions which are already present (copyright laws do not allow distributors to drop restrictions) One cannot comply with all these conditions at the same time. The "GPL + further restrictions" license is therefore self-contradictory. Please also see this old reply by RMS: https://lists.debian.org/debian-legal/2006/05/msg00303.html I hope this clarifies. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpfqUcgM0hPd.pgp Description: PGP 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#663468: audacious-plugins: [regression] jack output plugin fails to start jack server
Control: found -1 audacious-plugins/3.5-1 On Sat, 18 May 2013 00:17:21 +0200 Francesco Poli wrote: On Sun, 11 Mar 2012 16:00:18 +0100 Francesco Poli (wintermute) wrote: [...] the jack output plugin is no longer able to start the jack server and spits out errors [...] Is there any progress on this issue? Has it been investigated? Has my bug report been forwarded upstream? I've just checked with audacious-plugins/3.3.4-2 and I am still able to reproduce the bug. Please let me know. Thanks for your time! Hello again. I am still able to reproduce the bug with audacious-plugins/3.5-1 ... I haven't received any reply at all for more than 3 years. Having to manually start the jack server is really annoying. Could this bug be addressed somehow, please? Thanks for any help you may provide. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpoXoOlh75GY.pgp Description: PGP 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#705374: gnome-mplayer: takes screenshots twice with mplayer2
On Thu, 12 Jun 2014 18:49:16 +0200 Sebastian Ramacher wrote: [...] Before I close the bug report again, could you check if the issue is fixed in 1.0.9-1? Hello Sebastian, thanks for following up on this bug report. I've just tested gnome-mplayer/1.0.9-1 (with vo=xv and vf=screenshot in my ~/.mplayer/config) and, yes!, the bug really seems to be fixed now. I think you may safely close the bug report as fixed in version 1.0.9-1. Thanks a lot for all you are doing! Bye. -- http://www.inventati.org/frx/ fsck is a four letter word... . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpQMPuJBmDL8.pgp Description: PGP 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#705374: gnome-mplayer: takes screenshots twice with mplayer2
Control: notfixed -1 1.0.8-1 Control: found -1 gnome-mplayer/1.0.8-1 Control: found -1 gnome-mplayer/1.0.8-2 On Sun, 3 Nov 2013 20:35:52 +0100 Sebastian Ramacher wrote: Version: 1.0.8-1 On 2013-05-26 15:54:47, Francesco Poli wrote: On Sun, 26 May 2013 15:39:19 +0200 Sebastian Ramacher wrote: Control: reassign -1 gnome-mplayer 1.0.7-4 Control: tags -1 + fixed-upstream [...] Upstream thinks that this is a bug in gnome-mplayer instead and it's fixed in gnome-mplayer's svn repo. Good, I'll test the fixed code, once it has appeared in Debian unstable or testing. Bye and thanks again for the time you are dedicating to this package! This should be fixed in 1.0.8. If it's still a problem please reopen the bug. Hello Sebastian, thanks for following up on this bug. Unfortunately, the issue is still present in version 1.0.8-2, I've just reproduced it... (In case this is relevant, I am currently using libgmtk1/1.0.8-3) And anyway, if you re-read the original report, you may see that I had found the bug in both gnome-mplayer/1.0.7-4 and gnome-mplayer/1.0.8-1: hence, I would have been very surprised, if I had been unable to reproduce it now with gnome-mplayer/1.0.8-2, which seems to be the upload to unstable of gnome-mplayer/1.0.8-1 (previously targeted to experimental)! I am therefore reopening the bug report. Thanks for anything you may do, in order to have this bug fixed. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpAfhSi3wIvE.pgp Description: PGP 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#705374: gnome-mplayer: takes screenshots twice with mplayer2
On Sun, 3 Nov 2013 21:51:06 +0100 Sebastian Ramacher wrote: On 2013-11-03 21:32:05, Francesco Poli wrote: [...] I had found the bug in both gnome-mplayer/1.0.7-4 and gnome-mplayer/1.0.8-1: [...] Sorry about that. I must have missed that while going through old bug reports and thought this would only affect 1.0.7. No problem! I really appreciate all you do to deal with the bugs in gnome-mplayer. Looking forward to see this issue fixed. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpzD9Th78_Fz.pgp Description: PGP 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: CC-BY-ND license in debian
On Wed, 21 Aug 2013 15:18:43 +0200 Jaromír Mikeš wrote: 2013/8/21 Felyza Wishbringer fel...@gmail.com [...] Obviously that ND (rather than SA) excludes it from Deb, directly. If upstream decides to go with CC-BY-SA v3, then that is compatible. ND is explicitly not. Hope that helps. IANAL Thank you! It is clear now. I would like to add some further considerations. First of all, I agree that CC-by-nd is utterly against the spirit and the letter of the DFSG. Specifically, works solely licensed under the terms of CC-by-nd (any version) clearly fail to comply with DFSG#3. Secondly, it's true that FTP-masters currently accept works licensed under CC-by-sa-v3.0 and under CC-by-v3.0 into Debian main. I personally disagree with them, as I am convinced that those two licenses are *not* OK, but that's another story ([1], and, for more details, [2][3]) [1] https://lists.debian.org/debian-legal/2010/01/msg00084.html [2] https://lists.debian.org/debian-legal/2007/03/msg00105.html [3] https://lists.debian.org/debian-legal/2007/07/msg00124.html I hope this helps. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpNczu3Zij96.pgp Description: PGP 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#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
On Sun, 28 Jul 2013 20:25:25 +0200 Sebastian Ramacher wrote: Control: forwarded -1 https://code.google.com/p/gnome-mplayer/issues/detail?id=694 Hi Francesco, Hello Sebastian! I'm sorry for the delay. I've forwarded the bug report to Kevin in the hope that he might know anything about it. I'm still unable to reproduce it. Thanks a lot for doing that! It's really appreciated, indeed. However... well... oh my... I am really embarrassed... :-( OK, truth has to be told! I've just re-tried and it seems that I am *no longer* able to reproduce the bug! It looks like the issue vanished without me noticing... :-( I am sorry I haven't realized earlier and thus I haven't told you. On the other hand, I am happy that the bug seems to no longer affect current Debian testing. I don't know which upgrade solved the issue (it's hard to say, after several weeks of daily Debian testing upgrading!), but it seems to no longer be here. I think you may close the bug report (and inform upstream). I will reopen it, in case the issue shows up again. Thank you for all the time you dedicate to this package. As always, rest assured that I appreciate it very much. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpiRhTagFuw9.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Sun, 23 Jun 2013 18:11:48 +0200 Sebastian Ramacher wrote: On 2013-06-15 23:28:27, Francesco Poli wrote: [...] I've just tried out the 1.0.8-3 package you prepared for me. Great job! It seems to work flawlessly (just like version 1.0.8-1)! Whatever you did to this package should definitely end up in an official upload to unstable! [...] Sorry for the delay. I've just uploaded the fixed version. What's the state of the original problem of the bugreport now? Still present? The original issue pointed out in this bug report (#706154) seems to be fixed in gecko-mediaplayer/1.0.8-3 !! I think you may close the bug report. Thanks a lot for all the time you dedicated to it and for your kind assistance. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpv4uhzmYf5U.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Mon, 10 Jun 2013 22:07:59 +0200 Sebastian Ramacher wrote:
On 2013-06-07 23:46:16, Francesco Poli wrote:
[...]
Any idea of what's going on?
Thank you very much for any help you may provide.
Two things changed in that upload:
- the obsolete gconf file got dropped (sigh, I forgot to document that
in the changelog). This change shouldn't make a difference, though.
- gecko-mediaplayer now built against xulrunner-dev 17.0.6ers-1. Maybe
that lead to an incompatibility with iceweasel 10. I think I found
the culprit and a fixed package is available at [1]. If you can
confirm that this brings us back to the 1.0.8-1 behavior, I'll
prepare an upload with that fix.
I've just tried out the 1.0.8-3 package you prepared for me.
Great job! It seems to work flawlessly (just like version 1.0.8-1)!
Whatever you did to this package should definitely end up in an
official upload to unstable!
[...]
[1]
http://people.debian.org/~sramacher/gecko-mediaplayer_1.0.8-3_amd64.deb{,.asc}
Thank you so much for your kind assistance.
It's really appreciated, indeed!
--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpZWmwFWx6Rb.pgp
Description: PGP 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#711118: gnome-mplayer: messes up with dconf settings even when the user didn't change anything
On Wed, 5 Jun 2013 00:07:53 +0200 Sebastian Ramacher wrote: [...] As I've already said in the in the other bug report, please report this issue upstream yourself. I don't inted to spent any time on this. You can find upstream's bug tracker at https://code.google.com/p/gnome-mplayer/issues/list Unfortunately, it seems to require registration of an account, in order to report bugs. If I register an account on the upstream bug tracker of each Debian package I use, I will quickly go crazy... :-( That's why I kindly asked you to forward my bug report upstream. Pretty please? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpDIiSR7VT5w.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Wed, 5 Jun 2013 00:26:19 +0200 Sebastian Ramacher wrote: [...] Then I really don't know what's going on, sorry. The situation is getting even more mysterious. Today I upgraded to the new versions that were uploaded to unstable: [...] [UPGRADE] gecko-mediaplayer:amd64 1.0.8-1 - 1.0.8-2 [UPGRADE] gnome-mplayer:amd64 1.0.8-1 - 1.0.8-2 [...] [UPGRADE] libgmlib1:amd64 1.0.7-1 - 1.0.8-2 [UPGRADE] libgmtk1:amd64 1.0.7-1 - 1.0.8-2 [UPGRADE] libgmtk1-data:amd64 1.0.7-1 - 1.0.8-2 [...] The result was that gecko-mediaplayer stopped working for *any* video. After restarting iceweasel, loading http://content.funny-base.com/videos2/trunkmonkey01.wmv led to a blank (white) page (after enabling javascript): nothing happened, no video playing, no video download dialog window, ... Loading http://www.funny-base.com/videos/792-trunkmonkey01.html led to a page that lacked the area supposed to embed the video (again, after enabling javascript), and no video was played. Even other video formats (such as .mp4 ones, which used to work, without ever claiming to require additional plugins) stopped working (blank page). I was really puzzled. I tried to downgrade gnome-mplayer and gecko-mediaplayer: # dpkg -i /var/cache/apt/archives/gecko-mediaplayer_1.0.8-1_amd64.deb \ /var/cache/apt/archives/gnome-mplayer_1.0.8-1_amd64.deb After restarting iceweasel, I checked the video formats which used to work (.mp4) and they worked correctly again. More and more puzzled, I tried to upgrade gnome-mplayer again (while keeping back gecko-mediaplayer/1.0.8-1): # dpkg -i /var/cache/apt/archives/gnome-mplayer_1.0.8-2_amd64.deb After restarting iceweasel, all videos seem to work correctly: .mp4, .mov (for instance in http://www.mediacollege.com/video/format/mpeg4/streaming/example.html), .mpg, .avi, even .wmv (http://content.funny-base.com/videos2/trunkmonkey01.wmv and http://www.funny-base.com/videos/792-trunkmonkey01.html). If I also upgrade gecko-mediaplayer again # dpkg -i /var/cache/apt/archives/gecko-mediaplayer_1.0.8-2_amd64.deb and I restart iceweasel, every video stops working again (blank pages for .mp4, .wmv, ...). Downgrading gecko-mediaplayer again fixes the issue: # dpkg -i /var/cache/apt/archives/gecko-mediaplayer_1.0.8-1_amd64.deb Any idea of what's going on? Thank you very much for any help you may provide. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpMiN4EBDFBB.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Sun, 2 Jun 2013 19:27:54 +0200 Sebastian Ramacher wrote:
On 2013-06-02 18:27:11, Francesco Poli wrote:
[...]
Could you check with stat or similar if the
files from /usr/lib/mozilla/plugins are loaded and by setting the
appropriate LD_DEBUG flags (check ld-linux.so(8) for details) if they
are loaded without problems?
$ LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/ld_debug_iceweasel.out iceweasel
(process:4712): GLib-CRITICAL **: g_slice_set_config: assertion
`sys_page_size == 0' failed
$ grep -i --color plugins /tmp/ld_debug_iceweasel.out*
$ ls -lg /tmp/ld_debug_iceweasel.out*
-rw-rw 1 $USER 63888 Jun 2 18:17 /tmp/ld_debug_iceweasel.out.4712
-rw-rw 1 $USER 1218 Jun 2 18:13 /tmp/ld_debug_iceweasel.out.4713
-rw-rw 1 $USER 526 Jun 2 18:13 /tmp/ld_debug_iceweasel.out.4714
-rw-rw 1 $USER 529 Jun 2 18:13 /tmp/ld_debug_iceweasel.out.4716
-rw-rw 1 $USER 37440 Jun 2 18:17 /tmp/ld_debug_iceweasel.out.4923
Awkward, it mentions nothing about plugins.
Did I do anything the wrong way?
That shouldn't be empty. Looks like there is something broken on your
side. Do you have any weird extensions installed
Only packaged extensions:
$ aptitude search '~i xul-ext'
i xul-ext-cookie-monster - makes it very easy to manage cookies in a
i xul-ext-debianbuttons - Buttons for querying Debian-related pages
i xul-ext-https-everywhere- extension to force the use of HTTPS on man
i xul-ext-noscript- Javascript/plugins permissions manager for
i xul-ext-uppity - toolbar button to go up on the web
i xul-ext-useragentswitcher - Iceweasel/Firefox addon that allows the us
or modified iceweasel
in another way to not load plugins?
I haven't modified iceweasel with respect to the official Debian
package and I don't think I changed the configuration in a way that
prevents the loading of plugins.
After all, I am still able to play some video formats (such as mp4
videos, for instance) with gecko-mediaplayer.
Anyway, you can review a complete description of my iceweasel user
configuration on my website:
http://www.inventati.org/frx/doc/nanodocs/testing_workstation_browsers.html#iceweasel
It's somewhat long and detailed, but, if you have the patience to read
it through, you may get a precise idea of how I configured the browser.
Is
$ strace -o /tmp/strace.log -f iceweasel
$ grep /usr/lib/mozilla/ /tmp/strace.log
also empty?
It should be something like:
| $pid access(/usr/lib/mozilla/plugins, F_OK) = 0
| ...
| $pid stat(/usr/lib/mozilla/plugins/gecko-mediaplayer-qt.so, ...) = 0
| ...
As soon as I visit a page that includes a video (such as the well known
http://www.funny-base.com/videos/792-trunkmonkey01.html , or maybe
infamous, at this point?), I get:
$ strace -o /tmp/strace.log -f iceweasel
$ grep /usr/lib/mozilla/ /tmp/strace.log
8065
access(/usr/lib/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384},
F_OK) = 0
8065
stat(/usr/lib/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384},
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
8065 openat(AT_FDCWD,
/usr/lib/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384},
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 22
8065 access(/usr/lib/mozilla/plugins, F_OK) = 0
8065 openat(AT_FDCWD, /usr/lib/mozilla/plugins,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 53
8065 lstat(/usr/lib/mozilla/plugins, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
8065 lstat(/usr/lib/mozilla/plugins/gecko-mediaplayer-wmp.so,
{st_mode=S_IFREG|0644, st_size=110824, ...}) = 0
8065 lstat(/usr/lib/mozilla/plugins, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
8065 lstat(/usr/lib/mozilla/plugins/gecko-mediaplayer-rm.so,
{st_mode=S_IFREG|0644, st_size=110824, ...}) = 0
8065 lstat(/usr/lib/mozilla/plugins, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
8065 lstat(/usr/lib/mozilla/plugins/gecko-mediaplayer.so,
{st_mode=S_IFREG|0644, st_size=110824, ...}) = 0
8065 lstat(/usr/lib/mozilla/plugins, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
8065 lstat(/usr/lib/mozilla/plugins/gecko-mediaplayer-dvx.so,
{st_mode=S_IFREG|0644, st_size=110824, ...}) = 0
8065 lstat(/usr/lib/mozilla/plugins, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
8065 lstat(/usr/lib/mozilla/plugins/flash-mozilla.so, {st_mode=S_IFLNK|0777,
st_size=34, ...}) = 0
8065 readlink(/usr/lib/mozilla/plugins/flash-mozilla.so,
/etc/alternatives/flash-mozilla.so, 4095) = 34
8065 lstat(/usr/lib/mozilla/plugins, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
8065 lstat(/usr/lib/mozilla/plugins/gecko-mediaplayer-qt.so,
{st_mode=S_IFREG|0644, st_size=110824, ...}) = 0
8065 stat(/usr/lib/mozilla/plugins/gecko-mediaplayer-wmp.so,
{st_mode=S_IFREG|0644, st_size=110824, ...}) = 0
8065 stat(/usr/lib/mozilla/plugins/gecko-mediaplayer-rm.so,
{st_mode=S_IFREG|0644, st_size=110824, ...}) = 0
8065 stat(/usr/lib/mozilla/plugins/gecko
Bug#711118: gnome-mplayer: messes up with dconf settings even when the user didn't change anything
Package: gnome-mplayer Version: 1.0.8-1 Severity: normal Hello, I noticed a misbehavior of gnome-mplayer with respect to the dconf configuration management. After the following steps: 0) start dconf-editor 1) reset all gnome-mplayer/gecko-mediaplayer preferences to their defaults 2) quit dconf-editor 3) start gnome-mplayer 4) enter its preferences dialog window and just take a look around (without changing anything) 5) exit from the dialog window 6) quit gnome-mplayer 7) start dconf-editor many settings are again marked as manually-changed (in boldface font), even though almost all of these are actually equal to their default value; some values are indeed non-default (such as audio-lang, for instance). I do not experience this awkward behavior, if I skip steps 4 and 5. It seems to me that the gnome-mplayer internal configuration dialog window does something strange to ~/.config/dconf/user ... I don't think it should save anything to the configuration file, if I haven't changed any setting at all! In other words, the configuration file should stay absolutely untouched, unless I actually changed something. And anyway, it should not mark settings as manually-changed, if I haven't changed them manually. Finally, it should not set some options to non-default values (such as audio-lang, for instance), if I haven't done anything to them. I think that the configuration dialog is not working as expected. Please forward this bug report upstream. Thanks for your time. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-mplayer depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii libasound2 1.0.25-4 ii libc62.17-3 ii libcairo21.12.14-4 ii libcurl3-gnutls 7.30.0-2 ii libdbus-1-3 1.6.10-1 ii libdbus-glib-1-2 0.100.2-1 ii libgda-5.0-4 5.0.3-2 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libglib2.0-0 2.36.1-2build1 ii libgmlib11.0.7-1 ii libgmtk1 1.0.7-1 ii libgpod4 0.8.2-7 ii libgtk-3-0 3.4.2-6 ii libmusicbrainz3-63.0.2-2.1 ii libnautilus-extension1a 3.4.2-1+build1 ii libnotify4 0.7.5-2 ii libx11-6 2:1.5.0-1+deb7u1 ii libxss1 1:1.2.2-1 ii mplayer2 [mplayer] 2.0-554-gf63dbad-1+b1 gnome-mplayer recommends no packages. Versions of packages gnome-mplayer suggests: ii gecko-mediaplayer 1.0.8-1 -- no debconf information ___ 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Sun, 2 Jun 2013 13:19:07 +0200 Sebastian Ramacher wrote: Sorry for the late replay. No problem, it may happen, even in the best of families! ;-) On 2013-05-08 23:53:02, Francesco Poli wrote: [...] OK, I am now looking at the settings with both dconf-editor and with gsettings. $ gsettings get apps.gecko-mediaplayer.preferences disable-wmp true which seems to match with what I see with dconf-editor, under apps gecko-mediaplayer preferences where disable-wmp is checked, despite having a default value == false. I am trying to set every gecko-mediaplayer and gnome-mplayer preference to its default value and see what happens. Mmmh, first thing I noticed: after the following steps 0) start dconf-editor 1) reset all gnome-mplayer/gecko-mediaplayer preferences to their defaults 2) quit dconf-editor 3) start gnome-mplayer 4) enter its preferences dialog window and just take a look (around without changing anything) 5) exit from the dialog window 6) quit gnome-mplayer 7) start dconf-editor many settings are again marked as manually-changed (in boldface font), even though almost all of these are actually equal to their default value; some values are indeed non-default (such as audio-lang, for instance). I do not experience this awkward behavior, if I skip steps 4 and 5. It seems to me that the gnome-mplayer internal configuration dialog window does something strange to ~/.config/dconf/user ... Nothing awkward happening there. Just if you hit ok there, it saves the values in the config. That's what it's supposed to do. I don't think it should save anything to the configuration file, if I haven't changed any setting at all! In other words, the configuration file should stay absolutely untouched, unless I actually changed something. And anyway, it should not mark settings as manually-changed, if I haven't changed them manually. I thought this was obvious... Moreover, it should not set some options to non-default values (such as audio-lang, for instance), if I haven't done anything to them. Finally, I didn't hit OK, as there is no OK button. There is only a Close button, which is another thing that I strongly dislike in some modern-looking configuration dialog windows: there's no OK/Cancel choice, only a Close button that's supposed to be used to exit and it doesn't allow me to change my mind and avoid saving the configuration! So, no, sorry, I disagree: I think that the configuration dialog is *not* working as expected. However, even after resetting the preferences with dconf-editor, and restarting iceweasel, I still experience the issue I originally reported: the browser still claims that an additional plugin is needed for WMV videos... Maybe we should have checked the obvious first. Which version of iceweasel are you using? $ dpkg -l iceweasel Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii iceweasel 10.0.12esr-1 amd64Web browser based on Firefox And if you start iceweasel, are there any spurious warnings/messages? $ iceweasel (process:4146): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed Could you check with stat or similar if the files from /usr/lib/mozilla/plugins are loaded and by setting the appropriate LD_DEBUG flags (check ld-linux.so(8) for details) if they are loaded without problems? $ LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/ld_debug_iceweasel.out iceweasel (process:4712): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed $ grep -i --color plugins /tmp/ld_debug_iceweasel.out* $ ls -lg /tmp/ld_debug_iceweasel.out* -rw-rw 1 $USER 63888 Jun 2 18:17 /tmp/ld_debug_iceweasel.out.4712 -rw-rw 1 $USER 1218 Jun 2 18:13 /tmp/ld_debug_iceweasel.out.4713 -rw-rw 1 $USER 526 Jun 2 18:13 /tmp/ld_debug_iceweasel.out.4714 -rw-rw 1 $USER 529 Jun 2 18:13 /tmp/ld_debug_iceweasel.out.4716 -rw-rw 1 $USER 37440 Jun 2 18:17 /tmp/ld_debug_iceweasel.out.4923 Awkward, it mentions nothing about plugins. Did I do anything the wrong way? Maybe we just hit an incompatible combination of iceweasel/gecko-mediaplayer and the config stuff is just a red herring. I honestly do not know... Thanks again for all the time you are spending on this issue. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpa74ujSpYnh.pgp Description: PGP signature ___ pkg-multimedia
Bug#705374: gnome-mplayer: takes screenshots twice with mplayer2
On Sun, 26 May 2013 15:39:19 +0200 Sebastian Ramacher wrote: Control: reassign -1 gnome-mplayer 1.0.7-4 Control: tags -1 + fixed-upstream [...] Upstream thinks that this is a bug in gnome-mplayer instead and it's fixed in gnome-mplayer's svn repo. Good, I'll test the fixed code, once it has appeared in Debian unstable or testing. Bye and thanks again for the time you are dedicating to this package! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpO1Q6MsSM92.pgp Description: PGP 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#708693: audacious: needs stricter versioned dependency on audacious-plugins (fails to start)
Package: audacious Version: 3.3.4-2 Severity: grave Justification: renders package unusable Hello, I've just upgraded a Debian testing (jessie) box with audacious and audacious-plugins installed. Since audacious-plugins has not yet migrated into testing, while audacious did, only audacious was upgraded. The result was: $ audacious *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Transport/neon.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Transport/mms.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Transport/unix-io.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/modplug.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/tonegen.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/wavpack.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/madplug.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/sndfile.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/aac.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/vorbis.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/console.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/flacng.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/ffaudio.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/xsf.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/metronom.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/cdaudio-ng.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Input/sid.so is not compatible with this version of Audacious. [...] *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Container/cue.so is not compatible with this version of Audacious. *** ERROR: /usr/lib/x86_64-linux-gnu/audacious/Container/m3u.so is not compatible with this version of Audacious. FATAL: No output plugin found. The program fails to start. Upgrading to audacious-plugins/3.3.4-2 from unstable fixes the issue. I think that audacious should not have migrated into testing before the corresponding audacious-plugins. This scenario should be prevented, probably with a stricter versioned dependency. Please fix this bug (and please do not downgrade the severity of this report, or, at least, not until audacious-plugins has migrated into testing). Thanks for your time! Bye. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages audacious depends on: ii audacious-plugins3.2.4-1 ii dbus 1.6.8-1 ii dbus-x11 1.6.8-1 ii gtk2-engines-pixbuf 2.24.10-2 ii libaudclient23.3.4-2 ii libaudcore1 3.3.4-2 ii libc62.13-38 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100.2-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk-3-0 3.4.2-6 ii libguess11.1-1 Versions of packages audacious recommends: ii unzip 6.0-9 audacious suggests no packages. -- no debconf information ___ 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#663468: audacious-plugins: [regression] jack output plugin fails to start jack server
Control: found -1 audacious-plugins/3.3.4-2 On Sun, 11 Mar 2012 16:00:18 +0100 Francesco Poli (wintermute) wrote: [...] the jack output plugin is no longer able to start the jack server and spits out errors [...] Is there any progress on this issue? Has it been investigated? Has my bug report been forwarded upstream? I've just checked with audacious-plugins/3.3.4-2 and I am still able to reproduce the bug. Please let me know. Thanks for your time! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpR_fYB7pP77.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Mon, 6 May 2013 11:00:17 +0200 Sebastian Ramacher wrote: On 2013-05-05 19:08:50, Francesco Poli wrote: On Sun, 5 May 2013 18:21:50 +0200 Sebastian Ramacher wrote: [...] What does $ gsettings get apps.gecko-mediaplayer.preferences disable-wmp produce and does it match the settings set with dconf(-editor)? Wait, wait!;-) gsettings? I don't have this command... let me see... Should I install the libglib2.0-bin package? Yes, please. OK, I am now looking at the settings with both dconf-editor and with gsettings. $ gsettings get apps.gecko-mediaplayer.preferences disable-wmp true which seems to match with what I see with dconf-editor, under apps gecko-mediaplayer preferences where disable-wmp is checked, despite having a default value == false. I am trying to set every gecko-mediaplayer and gnome-mplayer preference to its default value and see what happens. Mmmh, first thing I noticed: after the following steps 0) start dconf-editor 1) reset all gnome-mplayer/gecko-mediaplayer preferences to their defaults 2) quit dconf-editor 3) start gnome-mplayer 4) enter its preferences dialog window and just take a look (around without changing anything) 5) exit from the dialog window 6) quit gnome-mplayer 7) start dconf-editor many settings are again marked as manually-changed (in boldface font), even though almost all of these are actually equal to their default value; some values are indeed non-default (such as audio-lang, for instance). I do not experience this awkward behavior, if I skip steps 4 and 5. It seems to me that the gnome-mplayer internal configuration dialog window does something strange to ~/.config/dconf/user ... However, even after resetting the preferences with dconf-editor, and restarting iceweasel, I still experience the issue I originally reported: the browser still claims that an additional plugin is needed for WMV videos... Does anything I said help in pinpointing the problem? Please let me know (as always, thanks for your time!). -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpVk6VqYws6q.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Fri, 3 May 2013 14:29:23 +0200 Sebastian Ramacher wrote: On 2013-04-26 17:40:46, Francesco Poli wrote: It might be that there are some issues with the gconf to dconf switch. I will need to investigate that a bit further. I tried the following: $ mv -i ~/.config/dconf/user ~/tmp/ $ gnome-mplayer and I checked the preferences: I found the emulation options *enabled* by default, as you said. Other options seemed to be different as well... However, the issue with Windows Media Player videos seems to persist, even after this trick. :-( As far as my settings are concerned, there seems to be some gconf→dconf migration issue or something else that made me get non-default option values. Looks like it. There should be a folder named ~/.gconf/apps/gecko-mediaplayer containing %gconf.xml and preferences/%gconf.xml. Is there anything suspicious in there, e.g. is the WMP support disabled in one of these two files? Mmmmh: $ cd $ ls .gconf/apps/gecko-mediaplayer* ls: cannot access .gconf/apps/gecko-mediaplayer*: No such file or directory There seems to be no directory named like this... And nothing else in ~/.gconf/apps/ seems to be related to gecko-mediaplayer, to gnome-mplayer, or to mplayer. Thanks to the bug report I've discovered that gecko-mediaplayer still ships the gconf schema. That's fixed in the git repository but I'm not sure if that fixes this bug [1]. I am glad that my bug report has been useful for at least something. Now let's hope we manage to figure out how to fix the core issue... Is there a way to merge this newly generated ~/.config/dconf/user file into the previous one? I really don't know. I see. Or should I *manually* annotate each gnome-mplayer configuration option and the corresponding default value and then *manually* set each option to the annotated value?!? I guess dconf reset /apps/gecko-mediaplayer/ should reset everything to the default values but haven't tried it myself. Are you referring to the dconf program from the dconf-tools package? Maybe I should install that package: it may turn out to be useful in other cases, as well... Please let me know whether I correctly interpreted what you suggested. Thanks for your time! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpEXzgIyus3P.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Sun, 5 May 2013 17:06:15 +0200 Sebastian Ramacher wrote:
On 2013-05-05 16:28:54, Francesco Poli wrote:
[...]
Are you referring to the dconf program from the dconf-tools package?
Maybe I should install that package: it may turn out to be useful in
other cases, as well...
Yes, dconf from the dconf-tools package.
OK, I'll try and let you know.
At this point I don't know what's wrong here. Is dconf-service running?
$ ps aux | grep dconf | grep -v grep
generates an empty output.
However the dconf-service package is installed and
$ ls -lF /usr/lib/dconf/dconf-service
-rwxr-xr-x 1 root root 36136 Nov 26 12:42 /usr/lib/dconf/dconf-service*
Is dbus running?
I think it is indeed running.
This is the (slightly edited, for clarity) output:
$ ps aux | grep dbus | grep -v grep
102 2464 0.0 0.0 29924 1216 ?Ss 10:36 0:00
/usr/bin/dbus-daemon --system
$USER 2936 0.0 0.0 40768 1456 ?S10:36 0:00
/usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session /bin/bash
${HOME}/.xsession
$USER 2976 0.0 0.0 12384 1032 ?Ss 10:36 0:00
/usr/bin/ssh-agent /usr/bin/ck-launch-session /usr/bin/dbus-launch
--exit-with-session /bin/bash ${HOME}/.xsession
$USER 2984 0.0 0.0 24188 572 ?S10:36 0:00
/usr/bin/dbus-launch --exit-with-session /bin/bash ${HOME}/.xsession
$USER 2985 0.0 0.0 30076 1016 ?Ss 10:36 0:00
/usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
Is iceweasel/gecko-mediaplayer able to access dbus?
I think it is: is there an easy way to check, anyway?
(I'm just guessing here. But dbus and dconf-service look like possibly
points of failure as they are required to get the settings, AFAICT.)
I don't know whether dconf-service is really required.
It does not seem to be running on my system, but gnome-mplayer seems to
be able to remember the settings, if I change them... Moreover, when I
change those settings, the ~/.config/dconf/user file is updated.
P.S.: as usual, I would like to thank you for your prompt and kind
assistance; I wish all Debian package maintainers were so responsive!
--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpu_wMdqK5by.pgp
Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Sun, 5 May 2013 18:21:50 +0200 Sebastian Ramacher wrote: On 2013-05-05 17:39:03, Francesco Poli wrote: Is iceweasel/gecko-mediaplayer able to access dbus? I think it is: is there an easy way to check, anyway? You could check if DBUS_SESSION_BUS_ADDRESS is set for iceweasel, i.e check if /proc/$(pidof icewasel)/environ contains DBUS_SESSION_BUS_ADDRESS and is correct. It seems to be correct: $ strings /proc/$(pidof firefox-bin)/environ | grep DBUS_SESSION_BUS_ADDRESS DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-EWlTl35qa5,guid=e8bafb95e95f867331347ee751861a08 $ env | grep DBUS_SESSION_BUS_ADDRESS DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-EWlTl35qa5,guid=e8bafb95e95f867331347ee751861a08 (I'm just guessing here. But dbus and dconf-service look like possibly points of failure as they are required to get the settings, AFAICT.) I don't know whether dconf-service is really required. It does not seem to be running on my system, but gnome-mplayer seems to be able to remember the settings, if I change them... Moreover, when I change those settings, the ~/.config/dconf/user file is updated. What does $ gsettings get apps.gecko-mediaplayer.preferences disable-wmp produce and does it match the settings set with dconf(-editor)? Wait, wait!;-) gsettings? I don't have this command... let me see... Should I install the libglib2.0-bin package? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgplN9vgtH2D2.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
On Fri, 26 Apr 2013 15:17:36 +0200 Sebastian Ramacher wrote: On 2013-04-25 22:03:44, Francesco Poli wrote: On 2013-04-25 16:54:00, Francesco Poli (wintermute) wrote: [...] I am pretty sure I haven't changed anything regarding this. However, I see that I have all those emulation options (QuickTime Emulation, RealPlayer Emulation, Windows Media Player Emulation, DiVX Player Emulation) disabled! I tried to enable all of those emulation options, but the result is not different, even after restarting iceweasel... That's weird. What does about:plugins say? gecko-mediaplayer should be listed for plenty of Windows Media mimetypes there. It's not! It's listed for many MPEG, Ogg, FLAC, WEBM formats (plus other less known ones), but there's no mention of Windows Media Player, QuickTime or RealPlayer MIME types... Even after quitting iceweasel, checking that no plugin instance was incorrectly left running (ps aux | grep 'plugin\|player'), starting gnome-mplayer, enabling the emulation options, quitting gnome-mplayer, and starting iceweasel again. It defaults to being enabled and I just checked that it indeed is enabled by default for a new user and I'm able to watch the videos with gecko-mediaplayer in a new profile. Where is the user configuration file for gnome-mplayer? I mean: which file(s) should I move out of the way, in order to start with a new gnome-mplayer profile (without creating a new user on my box)? dconf should store the settings in ~/.config/dconf/user … but that's a binary file containing all settings for any application using dconf. But you can probably manipulate the settings with dconf-editor. Ouch, I strongly dislike configuration settings packed into an opaque binary file for many different programs! This seems to be even uglier than gconf... :-( It might be that there are some issues with the gconf to dconf switch. I will need to investigate that a bit further. I tried the following: $ mv -i ~/.config/dconf/user ~/tmp/ $ gnome-mplayer and I checked the preferences: I found the emulation options *enabled* by default, as you said. Other options seemed to be different as well... However, the issue with Windows Media Player videos seems to persist, even after this trick. :-( As far as my settings are concerned, there seems to be some gconf→dconf migration issue or something else that made me get non-default option values. I cannot keep the newly generated ~/.config/dconf/user file, since I do not want to lose the configuration for other programs (and it would not solve my issue anyway). Arrgh! I don't even know *which* other programs would lose their customizations in that case! That's exactly why I dislike multiple program configuration settings packed into a single opaque binary file!:-( Is there a way to merge this newly generated ~/.config/dconf/user file into the previous one? Or should I *manually* annotate each gnome-mplayer configuration option and the corresponding default value and then *manually* set each option to the annotated value?!? Thanks for the assistance you are providing, I really appreciate it. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgprXkHV5skzs.pgp Description: PGP 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
Package: gecko-mediaplayer Version: 1.0.8-1 Severity: normal Hello, I wanted to check that bug #689862 is still fixed in gnome-mplayer/1.0.8-1 + gecko-mediaplayer/1.0.8-1 To my great surprise, the following happened: 0) I started iceweasel 1) I opened a video in a new tab, for instance: http://content.funny-base.com/videos2/trunkmonkey01.wmv 2) iceweasel behaves exactly as if none of the installed plugins were able to deal with this file type: it popped up a dialog window, offering me to download the video or to open it with GNOME MPlayer 3) I chose to open the video with GNOME MPlayer and a standalone instance of gnome-mplayer appeared, playing the video correctly 4) I then tried the web page that embeds the same video: http://www.funny-base.com/videos/792-trunkmonkey01.html 5) the NoScript extension blocked the JavaScript code; I right-clicked on the page and selected Temporarily allow funny-base.com from the NoScript submenu 6) an iceweasel warning appeared inside a yellow bar at the top of the web page, claiming that Additional plugins are required to display all the media on this page; the area that should embed the video showed a similar warning (A plugin is needed to display this content) 7) I don't want to install plugins for my regular user, I strongly prefer to install Debian packages (as root), so that plugins and extensions are installed system-wide (for all the users); but, still, I wanted to see what would have have been installed: I tried to click on the Install plugin link 8) a dialog window appeared running the Plugin Finder Service and saying that No suitable plugins were found, Unknown Plugin (video/x-ms-wmv)... N.B.: with other videos, the MIME type claimed to be associated to an unknown plugin may be different (for instance video/x-msvideo) Why does gecko-mediaplayer claim that additional plugins are needed to play the above-mentioned videos, while gnome-mplayer is able to play them, when running in a standalone window? Is this a bug or did I misunderstand something? The same web pages used to work correctly with gnome-mplayer/1.0.7-2 + gecko-mediaplayer/1.0.6-1, hence this looks like a regression... Please fix this issue and/or forward my report upstream. Thanks for your time! -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gecko-mediaplayer depends on: ii gconf23.2.5-1+build1 ii gnome-mplayer 1.0.8-1 ii libc6 2.13-38 ii libcurl3 7.26.0-1+wheezy2 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100.2-1 ii libgcc1 1:4.7.2-5 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgmlib1 1.0.7-1 ii libstdc++64.7.2-5 gecko-mediaplayer recommends no packages. gecko-mediaplayer suggests no packages. -- no debconf information ___ 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#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video
Control: tags -1 - moreinfo On Thu, 25 Apr 2013 19:37:39 +0200 Sebastian Ramacher wrote: Control: tags -1 + moreinfo Hi, As always, thanks a lot for the commendable promptness of your reactions to bug reports! Rest assured that it is really appreciated. On 2013-04-25 16:54:00, Francesco Poli (wintermute) wrote: [...] 2) iceweasel behaves exactly as if none of the installed plugins were able to deal with this file type: it popped up a dialog window, offering me to download the video or to open it with GNOME MPlayer [...] Why does gecko-mediaplayer claim that additional plugins are needed to play the above-mentioned videos, while gnome-mplayer is able to play them, when running in a standalone window? [...] Did you change the settings regarding Windows Media Player emulation (Settings / Plugin)? Do you mean in the gnome-mplayer preferences? I am pretty sure I haven't changed anything regarding this. However, I see that I have all those emulation options (QuickTime Emulation, RealPlayer Emulation, Windows Media Player Emulation, DiVX Player Emulation) disabled! I tried to enable all of those emulation options, but the result is not different, even after restarting iceweasel... It defaults to being enabled and I just checked that it indeed is enabled by default for a new user and I'm able to watch the videos with gecko-mediaplayer in a new profile. Where is the user configuration file for gnome-mplayer? I mean: which file(s) should I move out of the way, in order to start with a new gnome-mplayer profile (without creating a new user on my box)? P.S.: I dropped the moreinfo tag, as I think I replied to your questions; of course, should you further need additional information, feel free to re-add the tag... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp9jusGOfO0r.pgp Description: PGP 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#705374: gnome-mplayer: takes screenshots twice with mplayer2
On Sun, 14 Apr 2013 12:44:11 +0200 Sebastian Ramacher wrote: [...] On 2013-04-13 21:41:27, Francesco Poli (wintermute) wrote: [...] as mentioned in #699394 [1], when using gnome-mplayer with mplayer2 and some VOs, hitting [Ctrl+T] generates a pair of identical PNG images, rather than one (as I would expect). [1] http://bugs.debian.org/699394#54 [...] I'm able to reproduce the issue with vo=xv and mplayer2. It works fine with vo=vdpau. Thank you so much for checking! Please investigate and fix this bug and/or forward my report upstream. As usual, thanks a lot for your time and dedication! I've forwarded the issue upstream. Good, thanks a lot. Let's wait and see how the issue gets solved by the upstream developers. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpc9JWghORfO.pgp Description: PGP 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#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
On Sat, 9 Feb 2013 21:56:32 +0100 Sebastian Ramacher wrote: On 2013-02-09 12:29:58, Francesco Poli wrote: [...] By the way, can you reproduce the bug, or am I the only one with this awkward issue?!? No, I've tried in multiple environments (default xfce, xfce + xmonad, gnome) and was unable to reproduce the problem. Hi Sebastian, sorry for the late reply. I've just tried gnome-mplayer/1.0.8-1 (with mplayer2/2.0-554-gf63dbad-1 +b1) and I am still able to reproduce the issue with seemingly all the videos at hand: when I start gnome-mplayer the canvas is initially zero-height until I press [Ctrl+1]. Could you try it with another desktop environment? This is not going to be easy: I am afraid it won't happen soon, unfortunately... :-( I've seen a commit [1] related to the widget layout code. It talks about layout issues when playing audio files, but maybe there are some more problems with that code. It'd be great if you can also test if the problem persists with this patch applied. [2] If I understand correctly, upstream version 1.0.8 includes this patch; if this is actually the case, then I am already testing a gnome-mplayer with the patch applied. As I said, the problem persists... :-( Regards [1] https://code.google.com/p/gnome-mplayer/source/detail?r=2390 [2] Please let me know if I should prepare a package for testing. I hope you manage to find a way to reproduce the issue and fix it. Many thanks for all the time you are spending dealing with gnome-mplayer bugs! Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpFefxGQVR75.pgp Description: PGP 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#705374: gnome-mplayer: takes screenshots twice with mplayer2
Package: gnome-mplayer Version: 1.0.8-1 Severity: normal Control: found -1 gnome-mplayer/1.0.7-4 Hello, as mentioned in #699394 [1], when using gnome-mplayer with mplayer2 and some VOs, hitting [Ctrl+T] generates a pair of identical PNG images, rather than one (as I would expect). [1] http://bugs.debian.org/699394#54 I am still able to reproduce the issue with gnome-mplayer/1.0.8-1 (at least with vo=xv: I haven't re-tested the other possible VOs). Please investigate and fix this bug and/or forward my report upstream. As usual, thanks a lot for your time and dedication! Bye. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-mplayer depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii libasound2 1.0.25-4 ii libc62.13-38 ii libcairo21.12.2-3 ii libcurl3-gnutls 7.26.0-1+wheezy1 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100.2-1 ii libgda-5.0-4 5.0.3-2 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgmlib11.0.7-1 ii libgmtk1 1.0.7-1 ii libgpod4 0.8.2-7 ii libgtk-3-0 3.4.2-6 ii libmusicbrainz3-63.0.2-2.1 ii libnautilus-extension1a 3.4.2-1+build1 ii libnotify4 0.7.5-1 ii libx11-6 2:1.5.0-1 ii libxss1 1:1.2.2-1 ii mplayer2 [mplayer] 2.0-554-gf63dbad-1+b1 gnome-mplayer recommends no packages. Versions of packages gnome-mplayer suggests: ii gecko-mediaplayer 1.0.6-1 -- no debconf information ___ 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#699695: gnome-mplayer: should read and use any mplayer configuration file
On Thu, 21 Feb 2013 17:28:06 +0100 Sebastian Ramacher wrote: [...] On 2013-02-20 23:04:06, Francesco Poli wrote: Hello again, since I am not satisfied with the workaround suggested by upstream and mentioned in http://bugs.debian.org/700189#64, I am trying to see whether I can come up with a patch that makes gnome-mplayer avoid passing the -volume option to mplayer in certain situations. When I saw the use_volume_option variable in src/main.c:1309, I thought I found the way to do it: it seemed that setting that variable to FALSE could disable the use of the -volume option in the mplayer command line. I tried to modify the src/main.c accordingly, but it seems to me that the use_volume_option variable has no effect at all. It is indeed 0 (checked with gdb), but the mplayer command line still includes the -volume option... Before this issue drives me completely crazy, could you please clarify what's wrong in my reasoning? Is the use_volume_option variable actually used for anything? Is there an easy way to disable the passing of the -volume option to mplayer (without a major code overhaul)? The options passed to mplayer are assembled in gmtk. Yes, I found that out. Thanks anyway for kindly explaining this to me. The function you're looking for is launch_mplayer in src/gmtk_media_player.c. Just grep for -volume in that file. Sure, but I would like to decide *inside gnome-mplayer* whether gmtk should or should not pass the -volume option to mplayer. The use_volume_option identifier seemed to suggest that this variable was used exactly for that purpose. Otherwise, why assigning to it a boolean value returned by the detect_volume_option() function?!? What is the actual purpose of the use_volume_option variable? I cannot find it referenced anywhere else than in gnome-mplayer/src/main.c ... It does not seem to be in any way accessible from gmtk ... (I'm not sure if it's enough to just patch out -volume. There is some interaction between the volume control widget and mplayer too.) That's a reasonable concern. I have the same concern myself. I was trying to test what would happen, but, as I said, it seems that the use_volume_option variable has no effect at all. Hope that helps A little, thanks a lot for your fast reply. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpW3y9qgZO1G.pgp Description: PGP 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#700189: Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
On Sat, 9 Feb 2013 20:55:10 +0100 Sebastian Ramacher wrote: On 2013-02-09 19:31:28, Francesco Poli wrote: [...] Please let me know how the discussion with upstream develops, since I am having a hard time in understanding their replies (this is not the first time, it seems). There won't be an option for that. That's really disappointing. But there is an easy workaround for the problem: Create a shell script containing something like #!/bin/bash /usr/bin/gnome-mplayer --volume 20 $@ called gnome-mplayer somewhere in your $PATH before /usr/bin. Also make sure that software volume control is enabled. This workaround is a kludge! I know how to create launch scripts, but seeing upstream developers of a graphical front-end for a video player recommending that *each* user (with a need to easily configure the initial volume) create his/her own launch script with a hard-coded configuration value is really discouraging... :-( [...] Since there is a workaround and there won't be any other fix for this, I'm closing this bug. I hope this helps. Frankly speaking, I am not happy with the way the upstream developers deal with bug reports coming from users. :-( -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgptLxYAbGGHj.pgp Description: PGP 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#699695: gnome-mplayer: should read and use any mplayer configuration file
On Sat, 9 Feb 2013 19:31:28 +0100 Francesco Poli wrote: On Sat, 9 Feb 2013 18:34:53 +0100 Sebastian Ramacher wrote: [...] Let's create a new bug for this. Cloned and forwarded. Thanks! Please let me know how the discussion with upstream develops, since I am having a hard time in understanding their replies (this is not the first time, it seems). Hello again, since I am not satisfied with the workaround suggested by upstream and mentioned in http://bugs.debian.org/700189#64, I am trying to see whether I can come up with a patch that makes gnome-mplayer avoid passing the -volume option to mplayer in certain situations. When I saw the use_volume_option variable in src/main.c:1309, I thought I found the way to do it: it seemed that setting that variable to FALSE could disable the use of the -volume option in the mplayer command line. I tried to modify the src/main.c accordingly, but it seems to me that the use_volume_option variable has no effect at all. It is indeed 0 (checked with gdb), but the mplayer command line still includes the -volume option... Before this issue drives me completely crazy, could you please clarify what's wrong in my reasoning? Is the use_volume_option variable actually used for anything? Is there an easy way to disable the passing of the -volume option to mplayer (without a major code overhaul)? Any help would be much appreciated. Thanks for your time! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpCquJZNTZkD.pgp Description: PGP 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#699695: gnome-mplayer: should read and use any mplayer configuration file
On Sat, 9 Feb 2013 01:03:13 +0100 Sebastian Ramacher wrote: On 2013-02-08 23:44:59, Francesco Poli wrote: [...] I haven't found any option for the initial volume, so I couldn't leave its value blank... Well, there is no option for the intial volume and there is nothing to leave blank. He was talking about the video output. The volume is controlled with the volume control right to the timeline. I must admit that gnome-mplayer should at least save the volume setting since it's always 100% on start. There seems to be a Remember last software volume level option, but: A) it can only be enabled if MPlayer Software Volume Control Enabled is checked (and I have no idea what this other option means... could you please clarify? the man page does explain much) B) what I would like to have is not an initial volume equal to the value I adjusted last time I quit the program; I instead would like to have a fixed initial volume level (like, for instance, 20 %) and then adjust it depending on the video I am watching There is a --volume command-line option that lets me set an initial volume level (in percentage). Hence, if I issue the following command: $ gnome-mplayer --volume 20 some-video.ogv I get whatever initial volume I want, but: A) I have to type this command-line option each time B) I do not know how to pass this command-line option to gnome-mplayer when it is used inside my web browser (gecko-mediaplayer plug-in) There is a --softvol command-line option that lets me enable MPlayer Software Volume Control for just one session (without checking the checkbox in the preferences), but the initial volume is again not read from ~/.mplayer/config :-( -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpoS4fFt5NoJ.pgp Description: PGP 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#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
On Sat, 9 Feb 2013 01:08:33 +0100 Sebastian Ramacher wrote: On 2013-02-08 23:20:12, Francesco Poli wrote: Please note that I have the Remember Window Size and Position setting unchecked in gnome-mplayer preferences. What about Resize window when new video is loaded? It is unchecked. I've just tried to check it, but the result is exactly the same: gnome-mplayer often starts with zero-height canvas, as if it were genuinely convinced that the video had a zero (or maybe 1) pixel height. Nonetheless, it says: [...] GMLIB-Message: VO: [xv] 400x304 = 400x304 Planar YV12 GMLIB-Message: media_loaded: position=0.000 length=772.160 start_time=0.000 run_time=0.000 volume=1.00 player=running media=play uri=file:///.../voyage.ogv GMLIB-Message: in media state change with state = play dontplaynext = 0 GMLIB-Message: trying to disable screensaver GMLIB-Message: ERROR: Failed to get value of property 'sub_source'. GMLIB-Message: current size = 416 x 1 GMLIB-Message: Changing window size to 400 x 304 visible = true which is not true, since the canvas is still zero-height. As soon as I hit [Ctrl+1], the canvas is correctly re-sized and I get: GMLIB-Message: trying to disable screensaver GMLIB-Message: current size = 0 x 0 GMLIB-Message: Changing window size to 400 x 304 visible = true This time gnome-mplayer is telling me the truth, as the video is really 400 x 304 (confirmed by taking screenshots) and the canvas seems to be correctly sized. By the way, can you reproduce the bug, or am I the only one with this awkward issue?!? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpmckwptM3iX.pgp Description: PGP 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#699695: gnome-mplayer: should read and use any mplayer configuration file
On Sat, 9 Feb 2013 18:34:53 +0100 Sebastian Ramacher wrote: [...] On 2013-02-09 12:11:45, Francesco Poli wrote: [...] A) it can only be enabled if MPlayer Software Volume Control Enabled is checked (and I have no idea what this other option means... could you please clarify? the man page does explain much) This option corresponds to mplayer's --softvol flag: --softvol Force the use of the software mixer, instead of using the sound card mixer Thanks for the explanation: it's a little bit clearer now, even though I am not sure I fully understand its implications. For instance: I use the jack AO, hence I think that everything gets mixed by jackd before being sent to the sound card, and I don't know how mplayer or gnome-mplayer can interfere with this... Oh well, I am probably too ignorant about audio processing! :-( I even failed to configure my system so that I could capture an external audio input (see #523925, #536705, #578309, if you're curious...) [...] There is a --volume command-line option that lets me set an initial volume level (in percentage). Hence, if I issue the following command: $ gnome-mplayer --volume 20 some-video.ogv I get whatever initial volume I want, but: A) I have to type this command-line option each time B) I do not know how to pass this command-line option to gnome-mplayer when it is used inside my web browser (gecko-mediaplayer plug-in) Let's create a new bug for this. Cloned and forwarded. Thanks! Please let me know how the discussion with upstream develops, since I am having a hard time in understanding their replies (this is not the first time, it seems). -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpxbdDkgOWnh.pgp Description: PGP 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#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
Control: tags -1 - moreinfo On Mon, 4 Feb 2013 01:08:49 +0100 Sebastian Ramacher wrote: On 2013-02-03 21:43:10, Sebastian Ramacher wrote: So let me ask you some questions: does this also happen with mplayer2? Yes, it does. I've just reproduced the issue with mplayer2. Is there anything special about your windows manager and/or desktop environment? It's a fairly simple FluxBox desktop, described here: http://www.inventati.org/frx/doc/nanodocs/testing_workstation_desktopconf.html I haven't set any fixed dimensions for gnome-mplayer windows through the FluxBox apps configuration settings: $ grep -i player ~/.fluxbox/apps returns no output. And while we're at it: could you also check if you're affacted by [1]? Regards [1] https://code.google.com/p/gnome-mplayer/issues/detail?id=657 This issue seems to be similar, but not identical. The user who reported it says that the initial window size is completely random. On the other hand, I see either a zero-height initial canvas, or a correctly-sized one, depending on the video I choose to play, it seems. Mmmh, I've just rechecked four different videos: it seems to me that, with mplayer2, the initial canvas is basically always a zero-height one. Please note that I have the Remember Window Size and Position setting unchecked in gnome-mplayer preferences. I hope this additional information may help to pinpoint the problem. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp3ykXqP8Ccn.pgp Description: PGP 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#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
On Fri, 8 Feb 2013 23:20:12 +0100 Francesco Poli wrote: [...] On the other hand, I see either a zero-height initial canvas, or a correctly-sized one, depending on the video I choose to play, it seems. Mmmh, I've just rechecked four different videos: it seems to me that, with mplayer2, the initial canvas is basically always a zero-height one. A little update: the issue seems to come up in some cases, but not always, when testing a given video multiple times. Hence, it seems that the bug does not depend on the video I choose to play, but on something else (something less obvious, I would say...). -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpIHi1YYCZ7K.pgp Description: PGP 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#699695: gnome-mplayer: should read and use any mplayer configuration file
On Tue, 5 Feb 2013 10:43:08 +0100 Sebastian Ramacher wrote: Control: tags + -1 wontfix On 2013-02-04 21:25:50, Sebastian Ramacher wrote: Control: forwarded -1 https://code.google.com/p/gnome-mplayer/issues/detail?id=670 According to upstream's answer, this is not going to happen. Since I'm not going to work on this either, let's tag the bug wontfix. I am not sure I understand the answer from upstream. It seems to be claimed that what I would like to get is simply obtained by leaving blank settings in gnome-mplayer preferences. But this does not seem to work for all mplayer settings: for instance, how can I convince gnome-mplayer to use whatever initial volume is configured in ~/.mplayer/config (20 % in my case)? $ cat .mplayer/config [default] ao=jack,alsa volume=20 vo=xv vf=screenshot I haven't found any option for the initial volume, so I couldn't leave its value blank... Could you please clarify? Thanks for your time. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpW6HyOANobr.pgp Description: PGP 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#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
On Tue, 5 Feb 2013 01:14:03 +0100 Sebastian Ramacher wrote: On 2013-02-04 23:34:51, Francesco Poli wrote: On Sun, 3 Feb 2013 21:27:06 +0100 Sebastian Ramacher wrote: [...] If the setting is blank, the default output is used. Since you have manually set it to xv in your mplayer config, it's using xv here. OK, but why did gnome-mplayer fail to pass the correct flags to enable screenshots in mplayer? By looking at the mplayer man page, I seem to understand that the correct flag is just: -vf screenshot Well, it's not true for all vos. To the best of my knowledge, the screenshot video filter and vdpau don't work well together, since mplayer never sees the final image. If this is the case, then I begin to understand why the -vf screenshot flag is not passed to mplayer unconditionally... (That information might be outdated, so please correct me if I'm wrong.) I cannot actually use the vdpau VO, hence I cannot verify. [...] I guess this is one of the vos upstream mentioned, that don't support screenshots. This does not seem to be the case: when I explicitly ask for gl, I am able to take screenshots (without the vf=screenshot setting in ~/.mplayer/config). Let's put it this way: since vdpau is selected -vf screenshot is not passed to mplayer. Your hardware doesn't support vdpau, so the fallback gl is used. However, with gl you need -vf screenshot. Ah, that seems to make sense, yes. Thanks for clarifying. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpgiivuwepOg.pgp Description: PGP 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#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
On Sun, 3 Feb 2013 21:27:06 +0100 Sebastian Ramacher wrote: On 2013-02-03 18:38:17, Francesco Poli wrote: I tried to test all the available options for the video output in gnome-mplayer (with mplayer) and found the following awkward results. Leaving the setting blank seems to automatically select xv, according to the verbose output: GMLIB-Message: VO: [xv] 400x304 = 400x304 Planar YV12 but screenshots do not work: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: failed (forgot -vf screenshot?) If the setting is blank, the default output is used. Since you have manually set it to xv in your mplayer config, it's using xv here. OK, but why did gnome-mplayer fail to pass the correct flags to enable screenshots in mplayer? By looking at the mplayer man page, I seem to understand that the correct flag is just: -vf screenshot Indeed, if I modify my ~/.mplayer/config so that $ cat ~/.mplayer/config [default] ao=jack,alsa volume=20 vo=xv vf=screenshot and I leave the video output option blank for gnome-mplayer, then the xv VO seems to be correctly selected and taking screenshots seems to work fine (apart from the annoying double-screenshot issue with mplayer2). Explicitly selecting xv works: GMLIB-Message: VO: [xv] 400x304 = 400x304 Planar YV12 and screenshots may be taken: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: *** screenshot 'shot0001.png' *** So in this case gnome-mplayer launched mplayer with the correct flags to take screenshots since it knew that xv is used. If the correct flags are just -vf screenshot, then I cannot see why it has to know which video output is being used... Selecting gl works: GMLIB-Message: VO: [gl] 400x304 = 400x304 Planar YV12 and screenshots may be taken: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: *** screenshot 'shot0002.png' *** [...] Selecting vdpau seems to lead to gl being used: GMLIB-Message: VO: [gl] 400x304 = 400x304 Planar YV12 That's expected if your hardware doesn't support vdpau or you're missing the necessary libraries to actually use vdpau. but screenshots do not work: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: failed (forgot -vf screenshot?) I guess this is one of the vos upstream mentioned, that don't support screenshots. This does not seem to be the case: when I explicitly ask for gl, I am able to take screenshots (without the vf=screenshot setting in ~/.mplayer/config). Selecting xvmc or vaapi fails to work (high CPU load, endless stream of error messages and no visible video...). If the issues are reproducable with mplayer alone, I'd report bugs against those packages. Maybe you're just missing the proper hardware support. [...] Maybe later, I am already accumulating too many bugs to investigate... :-| -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp6qFAo63EYH.pgp Description: PGP 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#699695: gnome-mplayer: should read and use any mplayer configuration file
Package: gnome-mplayer Version: 1.0.7-4 Severity: wishlist Hello, as clarified in http://bugs.debian.org/699394#39 , gnome-mplayer ignores any user-defined setting found in ~/.mplayer/config . I don't think this is a good idea: I would like to avoid configuring the same program (mplayer) over and over again, just because I use it through different interfaces! I would like to suggest that gnome-mplayer should read and use (or let mplayer read and use) the settings found in ~/.mplayer/config , so that my preferences for mplayer are enforced within gnome-mplayer too. I hope my reasoning makes sense to you. Please implement this new feature and/or forward my wishlist bug report upstream. Thanks for your time! -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-mplayer depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii libasound2 1.0.25-4 ii libc62.13-37 ii libcairo21.12.2-2 ii libcurl3-gnutls 7.26.0-1 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-3 ii libgmlib11.0.7-1 ii libgmtk1 1.0.7-1 ii libgpod4 0.8.2-7 ii libgtk-3-0 3.4.2-5 ii libmusicbrainz3-63.0.2-2.1 ii libnautilus-extension1a 3.4.2-1+build1 ii libnotify4 0.7.5-1 ii libx11-6 2:1.5.0-1 ii libxss1 1:1.2.2-1 ii mplayer2 [mplayer] 2.0-554-gf63dbad-1+b1 gnome-mplayer recommends no packages. Versions of packages gnome-mplayer suggests: ii gecko-mediaplayer 1.0.6-1 -- no debconf information ___ 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#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
On Sun, 3 Feb 2013 14:37:58 +0100 Sebastian Ramacher wrote: [...] The code to take the screenshots is in gtmk, hence I'm reassigning it to gmtk. OK, thanks! The patch to display an error message if mplayer failed to take a screenshot is attached. This patch has been applied upstream. Very good, thanks for preparing it! On 2013-02-01 19:25:03, Francesco Poli wrote: I've installed mplayer (instead of mplayer2) to check if that might be a problem and in fact it is. With mplayer I can see the same error message in the log. Woah! I hadn't noticed the mplayer2 package in Debian! Shame on me: I see that it's in testing since 2011... Is it mature enough to replace mplayer? I haven't had any problems with it so far. Thanks for replying: I am giving it a try right now. Let's see... My analysis is wrong. It also depends on the video output used. In any case, an error message would be appropriate. In this case, maybe my mplayer configuration can help to pinpoint the issue: $ cat ~/.mplayer/config [default] ao=jack,alsa volume=20 vo=xv There is some special casing based on the selected vo, but the vo selected in ~/.mplayer/config is ignored in gnome-mplayer. This is not good at all, in my own personal opinion. I would rather avoid configuring the same program (mplayer) over and over again, just because I use it through different interfaces! So there are some things left I want you to try: explicitly select the vo in gnome-mplayer's preferences, try to take a screenshot with both mplayer and mplayer2 and maybe also try another vo. I'm not familiar enough with all the quirks of the different video outputs, so I need to rely on upstream's understanding of them. I tried to test all the available options for the video output in gnome-mplayer (with mplayer) and found the following awkward results. Leaving the setting blank seems to automatically select xv, according to the verbose output: GMLIB-Message: VO: [xv] 400x304 = 400x304 Planar YV12 but screenshots do not work: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: failed (forgot -vf screenshot?) Explicitly selecting xv works: GMLIB-Message: VO: [xv] 400x304 = 400x304 Planar YV12 and screenshots may be taken: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: *** screenshot 'shot0001.png' *** Selecting gl works: GMLIB-Message: VO: [gl] 400x304 = 400x304 Planar YV12 and screenshots may be taken: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: *** screenshot 'shot0002.png' *** Selecting gl2 works: GMLIB-Message: VO: [gl2] 400x304 = 400x304 Planar YV12 and screenshots may be taken: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: *** screenshot 'shot0003.png' *** Selecting x11 works: GMLIB-Message: VO: [x11] 400x304 = 400x304 Planar YV12 [zoom] and screenshots may be taken: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: *** screenshot 'shot0004.png' *** Selecting vdpau seems to lead to gl being used: GMLIB-Message: VO: [gl] 400x304 = 400x304 Planar YV12 but screenshots do not work: GMLIB-Message: sending VFCTRL_SCREENSHOT! GMLIB-Message: failed (forgot -vf screenshot?) Selecting xvmc or vaapi fails to work (high CPU load, endless stream of error messages and no visible video...). Then I installed mplayer2, thus removing the conflicting mplayer. Explicitly selecting xv works: GMLIB-Message: VO: [xv] 400x304 = 400x304 Planar YV12 and screenshots may be taken, but a single [Ctrl+T] produces two identical files: GMLIB-Message: *** screenshot 'shot0005.png' *** GMLIB-Message: *** screenshot 'shot0006.png' *** Please note that $ diff -sq shot000[56].png Files shot0005.png and shot0006.png are identical Leaving the setting blank seems to automatically select xv, according to the verbose output: GMLIB-Message: VO: [xv] 400x304 = 400x304 Planar YV12 and again screenshots may be taken, but a single [Ctrl+T] produces two identical files: GMLIB-Message: *** screenshot 'shot0007.png' *** GMLIB-Message: *** screenshot 'shot0008.png' *** Selecting gl works: GMLIB-Message: VO: [gl] 400x304 = 400x304 Planar YV12 and (double identical) screenshots may be taken: GMLIB-Message: *** screenshot 'shot0009.png' *** GMLIB-Message: *** screenshot 'shot0010.png' *** Selecting x11 works: GMLIB-Message: VO: [x11] 400x304 = 400x304 Planar YV12 [zoom] and single screenshots may be taken: GMLIB-Message: No VO support for taking screenshots, trying VFCTRL_SCREENSHOT! GMLIB-Message: No VO support for taking screenshots, trying VFCTRL_SCREENSHOT! GMLIB-Message: *** screenshot 'shot0011.png' *** Selecting vdpau seems to lead to gl being used: GMLIB-Message: VO: [gl] 400x304 = 400x304 Planar YV12 and single screenshots may be taken: GMLIB-Message: *** screenshot 'shot0012.png' *** Selecting xvmc seems to lead to xv being used: GMLIB-Message: VO: [xv] 400x304 = 400x304 Planar YV12
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
On Sun, 3 Feb 2013 19:19:22 +0100 Sebastian Ramacher wrote: [...] On 2013-02-03 18:48:48, Francesco Poli (wintermute) wrote: [...] I would like to suggest that gnome-mplayer should read and use (or let mplayer read and use) the settings found in ~/.mplayer/config , so that my preferences for mplayer are enforced within gnome-mplayer too. I think ignore is the wrong word here. gnome-mplayer just overwrites some settings and takes no special care of settings in ~/.mplayer/config when special casing some stuff. Looking at the source, the video output is the only thing that is overwritten. The audio output has a Default setting, for example. My preferred initial volume level (20 %) seems to also be ignored or overwritten. When I use gnome-mplayer, I always get an initial 100 % volume, which is usually annoyingly high. It might make sense to add a Default to the video output settings, though. Maybe. At any rate, I think gnome-mplayer should use the settings found in ~/.mplayer/config , unless the user overrules them by configuring gnome-mplayer's preferences... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgppdhjqtBRWo.pgp Description: PGP 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#699695: gnome-mplayer: should read and use any mplayer configuration file
On Sun, 3 Feb 2013 21:09:26 +0100 Sebastian Ramacher wrote: [...] Just to let you know: this issue has already been reported upstream almost two years ago. There is no progress so far. Mmmmh, it does not look like the same feature request. That upstream issue seems to request a specific command-line option to ignore gnome-mplayer preferences and only use the settings found in ~/.mplayer/config . On the other hand, what I am suggesting here is that gnome-mplayer should read and use (or let mplayer read and use) the settings found in ~/.mplayer/config , only overruling those settings that the user has explicitly configured in gnome-mplayer's preferences. I think it's a different strategy and I am still convinced that my suggestion makes more sense... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpjYqRopgV2m.pgp Description: PGP 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#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
On Fri, 1 Feb 2013 18:52:07 +0100 Sebastian Ramacher wrote: On 2013-02-01 18:23:23, Sebastian Ramacher wrote: Unfortunately I can't reproduce the bug. Could you please attach the output of 'gnome-mplayer -v $thevideo'? Sure! [...] It actually shows an error message about the inability to take screenshots, but I fail to understand what's the problem. It seems to talk about some command-line option (forgot -vf screenshot?), but I haven't found this option in the man page... [...] Thanks for the log. You're welcome, thanks to you for your kind assistance! I've installed mplayer (instead of mplayer2) to check if that might be a problem and in fact it is. With mplayer I can see the same error message in the log. Woah! I hadn't noticed the mplayer2 package in Debian! Shame on me: I see that it's in testing since 2011... Is it mature enough to replace mplayer? My analysis is wrong. It also depends on the video output used. In any case, an error message would be appropriate. In this case, maybe my mplayer configuration can help to pinpoint the issue: $ cat ~/.mplayer/config [default] ao=jack,alsa volume=20 vo=xv Thanks again for taking care of this bug report. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpDATSMHm7wW.pgp Description: PGP 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#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
Control: tags -1 - moreinfo On Thu, 31 Jan 2013 00:33:10 +0100 Sebastian Ramacher wrote: [...] Hi Francesco, Hi Sebastian and thanks a lot for your very fast response! On 2013-01-30 23:41:02, Francesco Poli (wintermute) wrote: I seem to be unable to use the built-in feature to take screenshots. After starting to play a video: $ gnome-mplayer one-video.ogv I tried to hit [Ctrl+T], while the video was being played, but nothing seemed to happen. [...] Unfortunately I can't reproduce the bug. Could you please attach the output of 'gnome-mplayer -v $thevideo'? Sure! I tried the following: $ gnome-mplayer -v voyage.ogv /tmp/gnome-mplayer.out 21 where voyage.ogv is the short film already cited in bugs #699393 and #696714. As soon as the video began to play, I pressed [Ctrl+1], then [Ctrl+T], and finally [Q]. The resulting file is attached (slightly edited). It actually shows an error message about the inability to take screenshots, but I fail to understand what's the problem. It seems to talk about some command-line option (forgot -vf screenshot?), but I haven't found this option in the man page... Anything useful to debug my issue? Please let me know. Thanks for your time! P.S.: by the way, the same output may perhaps be useful to investigate bug #699393 ... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE gnome-mplayer.out.gz Description: Binary data pgpiuxTvajJtt.pgp Description: PGP 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#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
Package: gnome-mplayer Version: 1.0.7-4 Severity: normal Hello, I noticed that gnome-mplayer often starts playing a video with an awkward zero-height canvas (== the area where the video is played, I am not sure of the correct name for this part of the GUI window...). As soon as I start the program: $ gnome-mplayer some-video.ogv the canvas seems to have the correct width, but zero height. Hence the video is played, but is not visible. If I press [Ctrl+1], the canvas is resized to the video original width and height and everything works fine. Other resize commands are also able to fix this problem. However, I think that gnome-mplayer should start with a canvas having the correct width and height for the video being played, without waiting for the user to hit [Ctrl+1]. I experience this issue with some videos, but not with all the ones I tested. One example video where I can reproduce this issue is http://archive.org/download/LeVoyageDansLaLune_218/voyage.ogv (which is the Ogg Video version of the 1902 silent film by Georges Méliès, currently in the public domain: http://archive.org/details/LeVoyageDansLaLune_218 ) Please fix this issue and/or forward my bug report upstream. Thanks for your time. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-mplayer depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii libasound2 1.0.25-4 ii libc62.13-37 ii libcairo21.12.2-2 ii libcurl3-gnutls 7.26.0-1 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-3 ii libgmlib11.0.7-1 ii libgmtk1 1.0.7-1 ii libgpod4 0.8.2-7 ii libgtk-3-0 3.4.2-5 ii libmusicbrainz3-63.0.2-2.1 ii libnautilus-extension1a 3.4.2-1+build1 ii libnotify4 0.7.5-1 ii libx11-6 2:1.5.0-1 ii libxss1 1:1.2.2-1 ii mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 gnome-mplayer recommends no packages. Versions of packages gnome-mplayer suggests: ii gecko-mediaplayer 1.0.6-1 -- no debconf information ___ 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#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
Package: gnome-mplayer Version: 1.0.7-4 Severity: normal Hello again, I seem to be unable to use the built-in feature to take screenshots. After starting to play a video: $ gnome-mplayer one-video.ogv I tried to hit [Ctrl+T], while the video was being played, but nothing seemed to happen. No file was created (at least, not in the current working directory, where I would expect it, or even in /tmp ...) I also tried to choose Take Screenshot from the Edit menu, but again nothing happened. What's wrong? What did I fail to understand? If this is confirmed to be a bug, please fix it and/or forward my bug report upstream. Thanks again for your time. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-mplayer depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii libasound2 1.0.25-4 ii libc62.13-37 ii libcairo21.12.2-2 ii libcurl3-gnutls 7.26.0-1 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-3 ii libgmlib11.0.7-1 ii libgmtk1 1.0.7-1 ii libgpod4 0.8.2-7 ii libgtk-3-0 3.4.2-5 ii libmusicbrainz3-63.0.2-2.1 ii libnautilus-extension1a 3.4.2-1+build1 ii libnotify4 0.7.5-1 ii libx11-6 2:1.5.0-1 ii libxss1 1:1.2.2-1 ii mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 gnome-mplayer recommends no packages. Versions of packages gnome-mplayer suggests: ii gecko-mediaplayer 1.0.6-1 -- no debconf information ___ 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#697538: gnome-mplayer: shows the wrong image for the play/pause button after going full screen
On Sun, 27 Jan 2013 01:00:29 +0100 Sebastian Ramacher wrote: [...] I've mistyped the bug number. Let's close the correct one instead: gnome-mplayer (1.0.7-4) experimental; urgency=3Dlow [...] * debian/patches/fallback-to-nonsymbolic.patch: Update upstream's fix once again and fix an incorrect icon. (Closes: #687538) That's great! I confirm that the bug seems to be indeed fixed. Thanks a lot for this upload, your maintaining job is really appreciated. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpbYRuVAKCNH.pgp Description: PGP 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#698019: libav: the effective GPL-licensed status of the binary packages should be clearly documented
On Mon, 14 Jan 2013 11:13:48 +0100 Jonas Smedegaard wrote: Quoting Charles Plessy (2013-01-14 02:55:38) On Sat, Jan 12, 2013 at 11:43 PM, Francesco Poli (wintermute) I think that the effective licensing status of the binary packages (GPL-2+ or GPL-3+) should be explicitly and clearly documented in the comment at the beginning of the debian/copyright file and, probably, in the binary package long descriptions, as well. Le Sun, Jan 13, 2013 at 09:50:58AM +0100, Reinhard Tartler a écrit : I am not happy at all with cluttering the binary package description with license blabla. I would do so only as last resort Dear Reinhard, Francesco and everybody, I think that the Debian copyright file of libav 6:9.1-1 is clear enough with its comment in the header, and that it is best to keep the license information out of the description of the package. Newest progress(?) on this is commit e3731d with this commit message: Document all licensing of binary packages in README.Debian (not partly as comment in copyright file), to avoid confusing source That change has not yet released but sits in our VCS. Could you please comment on that? Sorry, I can't figure out how to reference it at our public anoncms URL, but it is commit e3731d at git.debian.org:/git/pkg-multimedia/libav . I think it is: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=debian/README.Debian;h=3d1180db2a75a61cd7cd29914c1dc48d8bdd0ba2;hb=e3731d1b854c04e119853d13d0d16293d9bc201e And the commit diff is: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=e3731d1b854c04e119853d13d0d16293d9bc201e I am not too convinced this is a progress: it's true that it consolidates all the considerations about the effective licenses of the binary packages in one place. This is indeed good. But I think it chooses an unfortunate place: not where I would look at, when searching for licensing information... I am afraid that those useful considerations would be read by very few interested people, as long as they are buried deep in a README.Debian file. Note that the machine-readable format also allows License fields in the header paragraph to give the license information for the package as a whole. I am aware of that. But I am not convinced that *any* of the licensing formally covered by the copyright file format 1.0 are about the licensing of _binary_ packages. It is my understanding that they all are about sources only, not effective reasoned licenses. This is generally true, as far as I know, in the sense that only the licenses for the source files are _required_ to be documented in a debian/copyright file. But I think that some additional considerations about the effective licenses of binary packages are not forbidden, if placed in a Comment field. Since currently there is no better place (at least, not one I am aware of) to carry these considerations and since I am convinced that such considerations are important, I still think that the comment should be kept in the debian/copyright file and clarified. Something along the lines of | The effective license for all the binary packages is the GPL, not the | LGPL, because GPL-licensed parts of ffmpeg were enabled and some binary | packages link against GPL-licensed libraries. | Additionally, some binary packages directly or indirectly link against | libraries that are licensed under the Apache License v2.0: these binary | packages are effectively distributed under the GPL v3 or later (rather | than GPL v2 or later). | | Binary packages under GPL-2+ : | libav-doc (apart from one stylesheet under Apache-2.0), | libav-source, libavcodec-dev, libavutil-dev, libavutil*, libavcodec*, | libavresample*, libavresample-dev, libswscale*, libswscale-dev | | Binary packages under GPL-3+ : | libav-tools, libavcodec-extra-*, libavdevice*, libavdevice-dev, | libavformat*, libavformat-dev, libavfilter*, libavfilter-dev | | Transitional packages : | ffmpeg-doc, libavdevice-extra-*, libavfilter-extra-*, | libavformat-extra-*, libavutil-extra-*, libswscale-extra-* | | The libav-dbg package includes debug symbols from all the other | packages. Please fix any inaccurate part, of course. In http://bugs.debian.org/694657#120 you say: [to determine effective licensing of binary packages] One needs to examine the combined licensing of all parts of the chain - which is a huge job, I agree. First step in imporving that job is to make _source_ licensing machine readable *without* changing anything else, and a later step is to hopefully make a tool that traverses all build-dependencies to warn about potential incompatibilities. This future scenario is really interesting and desirable, but, although I am a perfectionist myself, I think we should acknowledge that we have nothing of the kind right now. Hence, while striving to achieve that great goal, we should implement an admittedly
Bug#694657: closed by Reinhard Tartler siret...@tauware.de (Bug#694657: fixed in libav 6:9.1-1)
On Sun, 13 Jan 2013 08:25:29 +0100 Reinhard Tartler wrote: On Sat, Jan 12, 2013 at 11:26 PM, Francesco Poli invernom...@paranoici.org wrote: [...] Without intimate knowledge of the libav package build process, I just thought that those GPL-licensed files only ended up into the binary packages named after the directories where they live... Without digging into all the dependencies, I hadn't noticed all the cross linking among the binary packages built from libav... In other words, I thought that only libavdevice and libavfilter were under GPL-2+ and all the other libraries were separated enough to be under LGPL-2.1+ ! Sorry, that's wrong, it's GPL. I thought that the old debian/copyright http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=debian/copyright;h=9ce50341783655e90ddd3f340cc3fa324c6d4386;hb=HEAD was pretty clear on that. Well, actually it didn't say so explicitly, either... It listed some GPL-licensed files and then it stated that the rest was LGPL-licensed. At the end there was that comment about libavcodec-extra-53, which however seemed to only warn readers about that particular binary package... Also, this is really something upstream should be concerned about. The upstream homepage points out this situation *very* prominently: http://libav.org/ (see the 2nd light-green box at the top) It's good that the upstream project web site points out this situation, but, of course, it does not (and should not) say anything about the packages in Debian. Now I even notice that a number of binary packages built from libav depend on libavcodec-extra-54, and are therefore effectively under GPL-3+ ! I think that this should be explicitly and clearly documented in the comment at the beginning of the debian/copyright file and, probably, in the binary package long descriptions, as well. Well, maybe you can suggest new changes to the new debian/copyright file? I'm really unsure how to express the situation less ambigously. I think that the comment at the beginning of the debian/copyright file should clearly explain the effective licensing status for each binary package and the corresponding reasons. If I find the time, I'll try to propose some precise phrasing, but I am not sure when I'll be able to do so... Sorry about that. Especially as Jonas (and others) keep telling me that debian/copyright is only about the source package. They are indeed right, generally speaking. But when the effective license of binary package(s) is more restrictive than it would seem to be by just looking at the debian/copyright file, I think that a big warning should be put in a prominent place in order to point out the situation. What better place than the debian/copyright file to warn users about some surprising licensing of binary packages? Suppose I am the maintainer of another Debian package and I have to assess whether it is legally possible to distribute that package linked with some libav libraries. The first things to check would be the libav library binary package descriptions and the libav debian/copyright file. Most people would stop there, without studying the libav build process in detail and without recursively checking the debian/copyright files and build processes of all the direct and indirect dependencies of the libav libraries! I'm not a big fan of adding licence terms to the binary package description. I can understand, but in some surprising cases it maybe makes sense. Especially when multiple binary packages built from the same source package end up having different effective licenses... [...] Make no mistake, I am perfectly fine with a GPL-licensed library. But: A) I am definitely less fine with a GPL-2-incompatible library (as you know, GPL-3+ is not compatible with GPL-2) that's why the GPL-3+ stuff is in -extra. The non-extra variants stay with GPL-2. Unless they depend on libavcodec-extra-* in their turn! In that case they are also (indirectly) linked with Apache-2.0-licensed stuff, and they also end up being effectively under GPL-3+ ... [...] B) it looks like a bit specious, when the library is under the GPL, just because of a few files Maybe it would be clearer if we didn't talk about LGPL at all? But that would be a false statement. No, no, I think that the source licensing should be clearly documented (Debian Policy also mandates it). These few files do contain some important optimization and functionality. We really do not want to miss them in high-profile applications sich as vlc or mplayer. So it's important to keep them enabled for those packages that do not have any (licensing) problem in using them. Hence, whenever the GPL-licensed files may be excluded and the linking with other GPL-licensed libraries may be avoided, it looks like a good idea to also provide an LGPL-licensed (reduced functionality) variant of the library. Sometimes you have a program
Bug#694657: closed by Reinhard Tartler siret...@tauware.de (Bug#694657: fixed in libav 6:9.1-1)
[Thanks for your fast reply, and sorry for my late reply...] On Thu, 10 Jan 2013 18:44:11 +0100 Reinhard Tartler wrote: On Thu, Jan 10, 2013 at 6:30 PM, Francesco Poli invernom...@paranoici.org wrote: On Thu, 10 Jan 2013 09:55:12 +0100 Reinhard Tartler wrote: [...] Oh I'm sorry, I mixed that up. There is no clear answer on that because it depends. Most of the files are LGPL, but some hand-written assembler optimizations are GPL-2+. The configure script offers an --enable-gpl switch that includes those GPL-2+ sources. We do enable this switch for all packages we produce in Debian. In theory, we could probably also provide an LGPL build of libavcodec. Fortunately, nobody has requested that so far. Wait, are you saying that those few GPL-licensed files: [...] | Files: libavdevice/x11grab.c | libavfilter/yadif.h | libavfilter/vf_blackframe.c | libavfilter/vf_boxblur.c | libavfilter/vf_cropdetect.c | libavfilter/vf_delogo.c | libavfilter/vf_hqdn3d.c | libavfilter/vf_yadif.c | libavfilter/x86/yadif.c | libavfilter/x86/yadif_template.c [...] | License: GPL-2+~Libav [...] are compiled into, or linked with, each shared object (*.so) shipped in all Debian binary packages built from the libav source package? yes. In other words, are you saying that all binary packages built from the libav Debian source package are effectively under GPL-2+ (except for libavcodec-extra-* and libav-dbg, which are effectively under GPL-3+)? yes. Ouch! This is not clear at all, by reading the debian/copyright file and/or by looking at the binary package long descriptions! Without intimate knowledge of the libav package build process, I just thought that those GPL-licensed files only ended up into the binary packages named after the directories where they live... Without digging into all the dependencies, I hadn't noticed all the cross linking among the binary packages built from libav... In other words, I thought that only libavdevice and libavfilter were under GPL-2+ and all the other libraries were separated enough to be under LGPL-2.1+ ! Now I even notice that a number of binary packages built from libav depend on libavcodec-extra-54, and are therefore effectively under GPL-3+ ! I think that this should be explicitly and clearly documented in the comment at the beginning of the debian/copyright file and, probably, in the binary package long descriptions, as well. Isn't there any binary package effectively under LGPL-2.1+? Exactly, we currently do not produce any LGPL'ed binary packages in Debian. In fact, we never did. Technically we could, but that would require significant additional complexity that I would prefer to avoid unless absolutely necessary. I understand that the additional complexity is not welcome, but I expect that a good number of people would have probably already requested these LGPL-licensed binary packages, if the current situation were more apparent. Make no mistake, I am perfectly fine with a GPL-licensed library. But: A) I am definitely less fine with a GPL-2-incompatible library (as you know, GPL-3+ is not compatible with GPL-2) B) it looks like a bit specious, when the library is under the GPL, just because of a few files Hence, whenever the GPL-licensed files may be excluded and the linking with other GPL-licensed libraries may be avoided, it looks like a good idea to also provide an LGPL-licensed (reduced functionality) variant of the library. Sometimes you have a program under LGPL-2.1+ which links with libav* and with a DFSG-free, but GPL-incompatible, library. While you are trying hard to persuade the copyright holders of the latter library to re-license under GPL-compatible terms, it would be useful to link the program with the LGPL-licensed (reduced functionality) variant of libav* packages, if at all possible... Please note that this is _not_ a theoretical example: see bug #618968. Please clarify, since this may heavily affect the resolution of licensing issues for other packages! I imagine. I hope this mail clarifies the situation! It does clarify, but I think the clarification should be visible to all the interested users, not just those who happen to read this bug log. I am therefore going to file a bug report suggesting you to clearly document this situation. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpfFE6qDIjqB.pgp Description: PGP 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#698019: libav: the effective GPL-licensed status of the binary packages should be clearly documented
Source: libav Version: 6:9.1-1 Severity: important Hello again, while trying to improve [1] a comment at the beginning of the debian/copyright file, it became apparent [2] that all the binary packages built from libav are effectively under GPL-2+ or even under GPL-3+ (as for libavcodec-extra-*, but also for the ones that link with it). [1] http://bugs.debian.org/694657#85 [2] http://bugs.debian.org/694657#100 As explained in my reply [3], I think that this situation is not clear at all, for people who just read the debian/copyright file and/or look at the binary package long descriptions! [3] http://bugs.debian.org/694657#105 Without intimate knowledge of the libav package build process, one may wrongly think that those GPL-licensed files only end up into the binary packages named after the directories where they live... Without digging into all the dependencies, one may fail to notice all the cross linking among the binary packages built from libav... I think that the effective licensing status of the binary packages (GPL-2+ or GPL-3+) should be explicitly and clearly documented in the comment at the beginning of the debian/copyright file and, probably, in the binary package long descriptions, as well. I really hope you are going to clarify this situation. Thanks for your time! Bye. ___ 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#694657: closed by Reinhard Tartler siret...@tauware.de (Bug#694657: fixed in libav 6:9.1-1)
On Thu, 10 Jan 2013 09:55:12 +0100 Reinhard Tartler wrote: [...] Oh I'm sorry, I mixed that up. There is no clear answer on that because it depends. Most of the files are LGPL, but some hand-written assembler optimizations are GPL-2+. The configure script offers an --enable-gpl switch that includes those GPL-2+ sources. We do enable this switch for all packages we produce in Debian. In theory, we could probably also provide an LGPL build of libavcodec. Fortunately, nobody has requested that so far. Wait, are you saying that those few GPL-licensed files: [...] | Files: libavdevice/x11grab.c | libavfilter/yadif.h | libavfilter/vf_blackframe.c | libavfilter/vf_boxblur.c | libavfilter/vf_cropdetect.c | libavfilter/vf_delogo.c | libavfilter/vf_hqdn3d.c | libavfilter/vf_yadif.c | libavfilter/x86/yadif.c | libavfilter/x86/yadif_template.c [...] | License: GPL-2+~Libav [...] are compiled into, or linked with, each shared object (*.so) shipped in all Debian binary packages built from the libav source package? In other words, are you saying that all binary packages built from the libav Debian source package are effectively under GPL-2+ (except for libavcodec-extra-* and libav-dbg, which are effectively under GPL-3+)? Isn't there any binary package effectively under LGPL-2.1+? Please clarify, since this may heavily affect the resolution of licensing issues for other packages! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpDf735romGo.pgp Description: PGP 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#694657: closed by Reinhard Tartler siret...@tauware.de (Bug#694657: fixed in libav 6:9.1-1)
On Wed, 09 Jan 2013 06:51:10 + Debian Bug Tracking System wrote: [...] [ Jonas Smedegaard ] * Rewrite copyright file using copyright format 1.0. Closes: bug#694657. Thanks to Francesco Poli. You're welcome, Jonas! Thanks to you, indeed. I have a question, though. At the beginning of the new debian/copyright file, I read the following comment: | Comment: | Because the libavcodec-extra-* package (since libavcodec-extra-54) | links against libraries licensed under Apache-2.0 (not compatible with | LGPL), effective license of that package and libav-dbg is GPL-3+. This does not look too clear to me. Which license is the libavcodec-extra-* package released under? LGPL-2.1+ or GPL-2+ ? By looking at the rest of the debian/copyright file, it seems to me that the answer is LGPL-2.1+ : can you confirm, please? If this is really the case, then, although it's true that Apache-2.0 is not compatible with GPL-2, I don't think it's accurate to say that Apache-2.0 is not compatible with LGPL... Moreover, why should the effective license of the libavcodec-extra-* package be considered GPL-3+ ? This seems to imply that I cannot distribute a program under a GPL-3-incompatible license (for instance, BSD-4-clause) linked with libavcodec-extra-*: I don't see any reason why such a program should be considered as legally undistributable... Please clarify the situation, and let's see whether we can find a clearer formulation for the above-quoted comment. Thanks for your time! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpue4_CUku32.pgp Description: PGP 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#694657: closed by Reinhard Tartler siret...@tauware.de (Bug#694657: fixed in libav 6:9.1-1)
On Wed, 9 Jan 2013 21:11:38 +0100 Reinhard Tartler wrote: On Wed, Jan 9, 2013 at 7:18 PM, Francesco Poli [...] Which license is the libavcodec-extra-* package released under? LGPL-2.1+ or GPL-2+ ? GPL-3+ GPL-3+ is the effective license of the binary package. My question was which is the license for the source files which are compiled in order to generate that binary package?. By looking at the rest of the debian/copyright file, it seems to me that the answer is LGPL-2.1+ : can you confirm, please? If this is really the case, then, although it's true that Apache-2.0 is not compatible with GPL-2, I don't think it's accurate to say that Apache-2.0 is not compatible with LGPL... Moreover, why should the effective license of the libavcodec-extra-* package be considered GPL-3+ ? It is not possible to downgrade the license from GPL-2+ to LGPL-2. This only leaves GPL-3(+) as possible option AFAIUI. This is true, as long as I have to start from GPL-2+, rather than from LGPL-2.1+. The unclear part is why I have to start from GPL-2+ (see my reply to Jonas for more details). I hope we can come up a suitable clarification for that comment. Thanks for your patience (both to you and to Jonas!). -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpFZP5vpYF8F.pgp Description: PGP 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#694657: closed by Reinhard Tartler siret...@tauware.de (Bug#694657: fixed in libav 6:9.1-1)
On Wed, 09 Jan 2013 21:10:06 +0100 Jonas Smedegaard wrote: Hi Francesco, Hi, thanks a lot for your very fast reply! Quoting Francesco Poli (2013-01-09 19:18:02) On Wed, 09 Jan 2013 06:51:10 + Debian Bug Tracking System wrote: [...] [ Jonas Smedegaard ] * Rewrite copyright file using copyright format 1.0. Closes: bug#694657. Thanks to Francesco Poli. You're welcome, Jonas! Thanks to you, indeed. I have a question, though. At the beginning of the new debian/copyright file, I read the following comment: | Comment: | Because the libavcodec-extra-* package (since libavcodec-extra-54) | links against libraries licensed under Apache-2.0 (not compatible with | LGPL), effective license of that package and libav-dbg is GPL-3+. This does not look too clear to me. Which license is the libavcodec-extra-* package released under? LGPL-2.1+ or GPL-2+ ? GPL-2+. I fail to understand how that can be misunderstood from that comment. Well, I think it _can_ be misunderstood because... it's not what it is written there! :-/ By looking at the debian/copyright file, it seems to me that the _source files_ that are compiled to produce the _binary_ package libavcodec-extra-* are under LGPL-2.1+ So this (and GPL-2+, thanks to the explicit conversion-to-GPL clause included in LGPL-2.1) seems to be the set of licenses we start with. Then, we have to look at the linked works, in order to determine the effective license for the _binary_ package. The comment only talks about libraries under Apache-2.0, which is not compatible with GPL-2. This seems to drop GPL-2, leaving the choice among GPL-3+ and LGPL-2.1+. Hence, by reading the comment (and the rest of the debian/copyright file), it really looks like the effective license is GPL-3+ or LGPL-2.1+ (excluding GPL-2). Moreover, the comment states that Apache-2.0 is incompatible with LGPL: I think this is incorrect and misleading. By looking at the rest of the debian/copyright file, it seems to me that the answer is LGPL-2.1+ : can you confirm, please? What a debian/copyright file covers is _source_ licensing. That's why it is merely a comment. Indeed: I looked at the debian/copyright file in order to figure out the license for the _source_ files that end up compiled into the _binary_ files shipped by the _binary_ package libavcodec-extra-* The effective license of a binary package is that license among the many many licenses involved in that binary work which is compatible with all the other ones. This not only involves the source parts of that same project, but also the parts linking in during build. Fully agreed. So even if you cannot find a single GPL-3+ licensed piece anywhere in this project, the very purpose of libavcodec-extra-* (as compared to libavcodec-*) is to link against GPL-licensed parts. This is the part that's not clear. Where is this stated? The comment does clarifies this subtlety. And I cannot see it documented in the binary package description, either: http://packages.debian.org/experimental/libavcodec-extra-54 Unless I start digging into the debian/copyright files of all the dependencies, and find out that * libx264-123 is under GPL-2+ * libxvidcore4 is also under GPL-2+ * a small part of libmp3lame0 is under GPL-1+ Is this (together with the linking with Apache-2.0 libraries) the reason why the _binary_ package libavcodec-extra-* is effectively under GPL-3+, rather than GPL-3+ or LGPL-2.1+ (excluding GPL-2) ? If this is the case, then I think the comment should be clarified (and also the binary package description). ...and even if none of those _other_ GPL-licensed parts are explicitly GPL-3+, ome parts are Apache-2.0 which is incompatible with GPL-2, rendering GPL-2+ licensed parts essentially equal to GPL-3+. Whew. Hope that whole pile made sense. :-) Maybe (assuming I understood you correctly...). But the comment is far too short to explain all this! If this is really the case, then, although it's true that Apache-2.0 is not compatible with GPL-2, I don't think it's accurate to say that Apache-2.0 is not compatible with LGPL... Correct. One need to check the long description and build-dependencies of libavcodec-extra-* to get an epiphany here. If one has to dig into all the dependencies anyway, then the comment does not seem to be too useful... [...] This seems to imply that I cannot distribute a program under a GPL-3-incompatible license (for instance, BSD-4-clause) linked with libavcodec-extra-*: I don't see any reason why such a program should be considered as legally undistributable... Not sure what you are trying to say here. It is legal to distribute libavcodec-extra-* and it is legal to distribute GPL-3-incompatible code. Not if one wants to distribute the two together, linked with each other, though. At least, this is what is said by the FSF legal theory
Bug#694657: closed by Reinhard Tartler siret...@tauware.de (Bug#694657: fixed in libav 6:9.1-1)
On Wed, 09 Jan 2013 22:53:48 +0100 Jonas Smedegaard wrote: [...] Maybe that is what you _now_ ask or what you _intended_ to ask earlier on, but what you have inside quotation marks here right above is not what you quote yourself as having said slightly further up. Yeah, I should have been clearer and more explicit. Sorry about that. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpolKUYupR9g.pgp Description: PGP 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#694657: closed by Reinhard Tartler siret...@tauware.de (Bug#694657: fixed in libav 6:9.1-1)
On Wed, 09 Jan 2013 23:27:44 +0100 Jonas Smedegaard wrote: Quoting Francesco Poli (2013-01-09 22:07:30) [...] Moreover, the comment states that Apache-2.0 is incompatible with LGPL: I think this is incorrect and misleading. Ah, yes - I agree there is a typo in the comment: s/LGPL/GPL-2/ Good, this is one of the most misleading parts of the comment. So even if you cannot find a single GPL-3+ licensed piece anywhere in this project, the very purpose of libavcodec-extra-* (as compared to libavcodec-*) is to link against GPL-licensed parts. This is the part that's not clear. Where is this stated? As I wrote earlier as well: In the long description of that binary package. I read: | Because this package links against libraries that are licensed under | Apache License 2.0, the resulting binaries are distributed under the | GPL version 3 or later. If I am not missing anything else, this seems to be very similar to the comment we are talking about. It does _not_ point out that the package also links with libraries under GPL-2+. So, once again: if one is not aware of the GPL-2+ libraries (maybe because he/she has not reviewed the debian/copyright files of _all_ the dependencies!), he/she may look at the debian/copyright file of the package and see that the corresponding source files are under LGPL-2.1+. At that point, it would _not_ be clear how linking with libraries under Apache-2.0 causes the binary package to be effectively under GPL-3+. I really think that the libraries under GPL-2+ should be mentioned, or otherwise very few people will understand what's going on... The comment does clarifies this subtlety. Apparently that comment confuses more than it helps. I suspect that is because that comment relates to licensing of _binary_ package which is not really the purpose of debian/copyright file. I think it is confusing because it does not mention that the binary package also links with libraries under GPL-2+. And I cannot see it documented in the binary package description, either: http://packages.debian.org/experimental/libavcodec-extra-54 Uhm, look for the keywords Apache and GPL on that page. As I said, I cannot see where the long description points out that the binary package also links with libraries under GPL-2+. Unless I start digging into the debian/copyright files of all the dependencies, and find out that * libx264-123 is under GPL-2+ * libxvidcore4 is also under GPL-2+ * a small part of libmp3lame0 is under GPL-1+ Is this (together with the linking with Apache-2.0 libraries) the reason why the _binary_ package libavcodec-extra-* is effectively under GPL-3+, rather than GPL-3+ or LGPL-2.1+ (excluding GPL-2) ? Yes. Perfect! As I said, I think that this should be explicitly documented. If this is the case, then I think the comment should be clarified (and also the binary package description). Instead of trying to improve it, I suggest we *remove* that comment! I disagree: it is a useful warning for people who look at the debian/copyright file in order to determine the license compatibility status of the package. It basically says: watch out! source is mostly LGPL-2.1+, but one binary package is effectively GPL-3+ It just should be clearer when it explains the reasons why! If this is really the case, then, although it's true that Apache-2.0 is not compatible with GPL-2, I don't think it's accurate to say that Apache-2.0 is not compatible with LGPL... Correct. One need to check the long description and build-dependencies of libavcodec-extra-* to get an epiphany here. If one has to dig into all the dependencies anyway, then the comment does not seem to be too useful... What is wrong with check the long description? The long description is not really clearer. As I said, it does not mention the GPL-2+ libraries, either. [...] Anyway, let's see whether you think that the following re-formulation is accurate: | Comment: | Because the libavcodec-extra-* package links against libraries | licensed under GPL-2+ and (since libavcodec-extra-54) against libraries | under Apache-2.0 (compatible with GPL-3, but not with GPL-2), effective | license of that package and libav-dbg is GPL-3+ (rather than LGPL-2.1+). Your rewrite introduce new confusions. I would prefer we drop the comment instead. Why?!? I think that my rewrite explains the actual reasons why the binary package is effectively under GPL-3+ (rather than LGPL-2.1+). A similar clarification may be applied to the description of the libavcodec-extra-* binary package. I fail to see what is wrong with current wording in long description of libavcodec-extra-* binary package. See above: it fails to mention the GPL-2+ libraries. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document
Bug#697538: gnome-mplayer: shows the wrong image for the play/pause button after going full screen
On Sun, 6 Jan 2013 18:15:25 +0100 Sebastian Ramacher wrote: Wow! I wish all maintainers of packages in Debian were so responsive! :-) Thanks a lot for your super-fast reply. [...] On 2013-01-06 18:02:45, Francesco Poli (wintermute) wrote: [...] I think this is caused by some sort of bug: please fix it and/or forward my report upstream. Thanks for your time! This is fixed in d51a4d0b (and upstream's r2381). Very good, I am looking forward to seeing the new Debian revision uploaded to experimental! Thanks again! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpgdNlISaHIH.pgp Description: PGP 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#697540: Bug#697538: gnome-mplayer: shows the wrong image for the play/pause button after going full screen
On Sun, 6 Jan 2013 18:15:25 +0100 Sebastian Ramacher wrote: Control: tags -1 + pending Control: clone -1 -2 Control: retitle -2 gnome-mplayer: Ctrl+F doesn't enable fullscreen [...] P.S.: by the way, pressing [F] enables and disables full screen mode, as documented in the man page, but it seems to me that [Ctrl+F] only disables full screen mode, and cannot be used to enable it [...] Indeed. Cloned as new bug. Very good! Mmmmh, I see that you cloned the bug report *after* tagging it as pending: is the cloned bug report ready to be fixed in the next upload, as well? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp9L_81DnAhD.pgp Description: PGP 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#696714: closed by Sebastian Ramacher sramac...@debian.org (Bug#696714: fixed in gnome-mplayer 1.0.7-3)
On Wed, 26 Dec 2012 13:03:07 + Debian Bug Tracking System wrote: [...] - fallback-to-nonsymbolic.patch: Update upstream's fix. (Closes: #696714) [...] Many many thanks for this super-quick upload! I confirm that the bug is indeed fixed. Bye and thanks again! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpHeWnxkABbO.pgp Description: PGP 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#689862: gnome-mplayer: often segfaults inside iceweasel with MPEG, WMV, and AVI videos
On Wed, 26 Dec 2012 12:47:16 +0100 Sebastian Ramacher wrote: [...] On 2012-12-26 11:25:57, Francesco Poli wrote: [...] It really seems that the bug has been fixed by the upstream developers, as you said. I think you can mark this bug as fixed in version gnome-mplayer/1.0.7-2 ... Great, thanks for testing. You're welcome. Thanks a lot for taking care of this bug report! Now I am looking forward to seeing this new upstream version uploaded to unstable (to the extent that this does not interfere with your plans for the remaining part of the wheezy freeze...). Since this would involve a library transition, it has to wait until after the wheezy release. Well, I was thinking about an upload to unstable performed now, but not intended for migration into testing before the wheezy release. Obviously, if you want to keep unstable for possible last second fixes intended for wheezy (rather than using testing-proposed-updates), I can understand that you are not willing to upload any new upstream versions to sid... Thanks for your time, whatever you decide. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpmnn6ICXHA1.pgp Description: PGP 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#694657: libav-source: debian/copyright file no longer seems to be accurate
On Fri, 30 Nov 2012 14:21:27 +0100 Jonas Smedegaard wrote: Quoting Fabian Greffrath (2012-11-30 08:57:22) [...] Jonas, could you please help me and reveal how I have to modify the licensecheck2dep5 script to combine all Files and Copyright holders for which the same License applies into one single stanza? I have wanted to make that very improvement for some time - thanks for pushing me: CDBS 0.4.119 now released to support this. :-) Hi Jonas, thanks a lot for this improvement in licensecheck2dep5! I see that it is enabled by setting an environment variable before running licensecheck2dep5, like this: merge_same_license=yes export merge_same_license Is there any other way to enable this feature? I haven't spotted any command-line option, for instance... By the way, I would like to inform Fabian about the existence of bug #472199: the plan is to integrate licensecheck2dep5 into licensecheck itself... Jonas, I really hope there's some progress on that front! ;-) -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpolDSWfH5W8.pgp Description: PGP 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#694657: libav-source: debian/copyright file no longer seems to be accurate
Source: libav Version: 6:0.8.4-1 Severity: important Hello, it seems to me that the debian/copyright file [1] is no longer consistent with the actual content of the upstream source archive (libav_0.8.4.orig.tar.gz). For instance, file libavcodec/dtsdec.c no longer exists (there is a libavformat/dtsdec.c , but it's licensed under the terms of the GNU LGPL v2.1 or later, not under the GNU GPL...). File libswscale/swscale.c is now licensed under the terms of the GNU LGPL v2.1 or later (and no longer under the GNU GPL...). And so forth... Please perform a new licensing audit and update the debian/copyright file. Maybe this could be the opportunity to switch to the new machine-readable debian/copyright file format [2]... Thanks for your time! Bye. [1] http://packages.debian.org/changelogs/pool/main/liba/libav/libav_0.8.4-1/copyright [2] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ ___ 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#689862: gnome-mplayer: often segfaults inside iceweasel with MPEG, WMV, and AVI videos
On Sun, 18 Nov 2012 11:48:18 +0100 Sebastian Ramacher wrote: [...] Hi Francesco, Hello Sebastian, On 2012-10-07 18:58:05, Francesco Poli wrote: Seriously, I hope that the issue may be fixed soon by the upstream developers. according to the upstream developer this issue has been fixed in 1.0.7. I've uploaded gmtk/gnome-mplayer/gecko-mediaplayer 1.0.7 to experimental, Thanks for doing so. so I'd be great if you could check that the issues is fixed in 1.0.7-1. They should appear on a mirror near you soon. Indeed it would be great if I could... Unfortunately, I am currently experiencing some personal issues and hence I don't know when this can actually happen. :-( Make no mistake: I really appreciate what you've done for this bug so far, but, please do not count on a quick feedback from me. Sorry. :-( -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp6ZOUJDzqIJ.pgp Description: PGP 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#689862: gnome-mplayer: often segfaults inside iceweasel with MPEG, WMV, and AVI videos
Package: gnome-mplayer Version: 1.0.6-1 Severity: normal Hello Debian Multimedia Maintainers, since long ago, I have experienced frequent segmentation faults by gnome-mplayer, when using it inside iceweasel (with gecko-mediaplayer and xul-ext-noscript installed). Steps to reproduce the bug: 0) start iceweasel 1) open an MPEG, WMV or AVI video in a new tab, for instance: http://content.funny-base.com/videos2/trunkmonkey01.wmv 2) the NoScript extension blocks the video; right-click on the page and select Temporarily allow content.funny-base.com from the NoScript submenu 3) the control buttons of the gecko-mediaplayer interface appear, but the video is not shown; /var/log/kern.log shows that gnome-mplayer segfaulted: gnome-mplayer[6593]: segfault at 4 ip 7f78e8bc863f sp 7fffd6a7f5b0 error 4 in libglib-2.0.so.0.3200.3[7f78e8b62000+f5000] 4) reload the iceweasel tab ([Ctrl+R]) 5) the video is shown, without any further segfault 6) select Revoke Temporary Permissions from the NoScript submenu This issue seems to happen with most MPEG, WMV, and AVI videos, both when the video is opened in a dedicated tab (as described above) and when the video is embedded in a web page area (as in http://www.funny-base.com/videos/792-trunkmonkey01.html ) Please note that using mplayer directly does not seem to cause any segfault: $ mplayer http://content.funny-base.com/videos2/trunkmonkey01.wmv The video is shown without any glitch. Please try to reproduce the bug and investigate its cause. Please fix the issue and/or forward this bug report upstream, as appropriate. Thanks for your time! -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-mplayer depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-2 ii libasound2 1.0.25-4 ii libc62.13-35 ii libcairo21.12.2-2 ii libcurl3-gnutls 7.26.0-1 ii libdbus-1-3 1.6.0-1 ii libdbus-glib-1-2 0.100-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libgmlib01.0.6-1 ii libgmtk0 1.0.6-1 ii libgpod4 0.8.2-6 ii libgtk-3-0 3.4.2-3 ii libmusicbrainz3-63.0.2-2.1 ii libnautilus-extension1a 3.4.2-1+build1 ii libnotify4 0.7.5-1 ii libx11-6 2:1.5.0-1 ii libxss1 1:1.2.2-1 ii mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 gnome-mplayer recommends no packages. Versions of packages gnome-mplayer suggests: ii gecko-mediaplayer 1.0.6-1 -- no debconf information ___ 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#689862: gnome-mplayer: often segfaults inside iceweasel with MPEG, WMV, and AVI videos
On Sun, 7 Oct 2012 14:10:17 +0200 Sebastian Ramacher wrote: [...] I can't reproduce the segfault with or without noscript installed. First of all, thanks a lot for your prompt reply! It's really appreciated, believe me. So it'd be great if you could provide as with a backtrace. Otherwise I don't think there is much we can do. Please help me: how can I obtain a backtrace? I suppose I should install gnome-mplayer-dbg and libglib2.0-0-dbg. Then I should have gnome-mplayer run inside gdb, but how? Should I run the entire iceweasel within gdb? Or what else? I have just (re-)read the HowToGetABacktrace wiki page [1], but it does not seem to talk about getting backtraces for programs invoked by browser plugins... [1] http://wiki.debian.org/HowToGetABacktrace -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpS4Sy16pLAu.pgp Description: PGP 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#689862: gnome-mplayer: often segfaults inside iceweasel with MPEG, WMV, and AVI videos
Control: tags -1 - moreinfo On Sun, 7 Oct 2012 15:41:15 +0200 Sebastian Ramacher wrote: On 2012-10-07 15:04:26, Francesco Poli wrote: Please help me: how can I obtain a backtrace? The best way to obtain a core dump from iceweasel plugins I came across so far is to do the following: Run: $ ulimit -c unlimited $ iceweasel and reproduce the crash. You should end up with a core dump in $(pwd). Run $ gdb /usr/bin/gnome-mplayer core to inspect it and get a back trace. Good, I've just done so (after installing gnome-mplayer-dbg and libglib2.0-0-dbg). The attached file is the log of the thread apply all bt full gdb command. I hope it may help to pinpoint the issue. Feel free to ask, in case you need additional information. Thanks a lot for your kind assistance! Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE gdb.txt.gz Description: Binary data pgpxbFZJp9N1q.pgp Description: PGP 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#689862: gnome-mplayer: often segfaults inside iceweasel with MPEG, WMV, and AVI videos
On Sun, 7 Oct 2012 18:08:56 +0200 Sebastian Ramacher wrote: [...] On 2012-10-07 16:17:57, Francesco Poli wrote: Good, I've just done so (after installing gnome-mplayer-dbg and libglib2.0-0-dbg). The attached file is the log of the thread apply all bt full gdb command. Thanks for the backtrace. Thanks to you for your kind assistance and for forwarding the bug upstream. Once again, this is really appreciated. According to the traceback this looks a lot like LP#929168. Since multiple persons are experiencing similar crashes, I'd say it's reproducible and I just happen to be lucky. You lucky boy! ;-) Seriously, I hope that the issue may be fixed soon by the upstream developers. Thanks for your time. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpYY0gVg2lKS.pgp Description: PGP 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#684928: volti: volume level numerical values differ from the ones shown by alsamixer
Package: volti Version: 0.2.3-4 Severity: normal Hello and thanks for maintaining Volti in Debian! I've just installed this package and I'm giving it a try. I noticed that the internal mixer shows volume level numerical values that differ from the ones shown by alsamixer. I think that this is very confusing, especially if one plans to use alsamixer in some circumstances and volti in other ones. I found out that there's a configuration option to disable the internal mixer and use an external one: I chose to use alsamixer as external mixer and thought I could be happy with this setting. Unfortunately the channel that is controlled by the slider that is obtained by left-clicking on the volti icon in the systray is affected by the same issue! :-( Hence, if this slider controls the master channel, I may see that volti claims its volume level is 95, while alsamixer says that the Master level is 88. Changing this level from either volti or alsamixer modifies both numbers, but they are never equal to each other! Again, I think this is very confusing. Please fix this bug and/or forward my bug report upstream, as appropriate. Thanks for your time. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages volti depends on: ii python2.7.3~rc2-1 ii python-alsaaudio 0.5+svn36-1+b2 ii python-dbus 1.1.1-1 ii python-gobject3.2.2-1 ii python-gtk2 2.24.0-3 ii python-xlib 0.14+20091101-1 volti recommends no packages. volti suggests no packages. -- no debconf information ___ 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#673695: Mouse wheel up and down no longer
On Sun, 20 May 2012 20:29:44 +0100 Chris Lamb wrote: [...] Since upgrading from 2.4.4-1+b2, scrolling the mousewheel up and down on the Winamp Classic Interface no longer modifies the volume. Hi! I am too experiencing this same bug. I seem to rely on this quite a lot; I've tried clicking and draging the little volume control but it's a bit too fiddly for quick uses. I used to rely on this feature a lot, as well. Especially taking into account that I usually keep the interface rolled up. I hope this issue may be fixed soon. P.S.: I am under the impression that a forcemerge 672498 673695 should be sent to control@b.d.o: do the Debian Multimedia Maintainers agree that these two bugs should be merged? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpnfuCO1BZYE.pgp Description: PGP 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#640747: audacious: Put on all workspaces (Ctrl-S) option is not honored after a while
reassign 640747 libgtk-3-0 affects 640747 audacious forwarded 640747 https://bugzilla.gnome.org/show_bug.cgi?id=666842 fixed 640747 gtk+3.0/3.3.16-1 thanks On Mon, 12 Mar 2012 18:53:00 -0400 John Lindgren wrote: On 03/12/2012 04:57 PM, Francesco Poli wrote: Maybe this bug should be reassigned to the appropriate package (binary package libgtk-3-0, I would say), marked as forwarded to https://bugzilla.gnome.org/show_bug.cgi?id=666842 and marked as fixed in version 3.3.16-1 . I can do this by myself, but, first, I would like to check whether you agree. Sounds good to me. Thanks, here we go! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp5sdGFkkY5J.pgp Description: PGP 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#640747: audacious: Put on all workspaces (Ctrl-S) option is not honored after a while
On Mon, 12 Mar 2012 14:53:28 -0400 John Lindgren wrote: Hi, Hello, thanks a lot for your prompt reply! This has already been reported upstream [1] and is a bug in GDK, not Audacious. I sent the GDK maintainers a patch, which they have applied. [2] Great job! :-) Could you please help me to understand which versions of GDK Debian packages include the fix? I tried to figure it out by looking at the upstream git repository via gitweb, but I probably do not know the correct way to extract this piece of information. I would rather avoid cloning the entire git repository just for this... Thanks for your much appreciated help! -- John 1. http://redmine.audacious-media-player.org/issues/16 2. http://git.gnome.org/browse/gtk+/commit/?id=01320e5773768827b5754470d3ed52392151f67a -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpKne6VNM2kf.pgp Description: PGP 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#640747: audacious: Put on all workspaces (Ctrl-S) option is not honored after a while
On Mon, 12 Mar 2012 15:59:25 -0400 John Lindgren wrote: On 03/12/2012 03:47 PM, Francesco Poli wrote: Great job! :-) Could you please help me to understand which versions of GDK Debian packages include the fix? That I can't tell you, sorry. Mmmmh, by looking at (Debian) source package gtk+3.0 [1], it seems to me that file gdk/x11/gdkdisplay-x11.c * does _not_ include your fix in version 3.2.3-1 (currently in testing and unstable) * _does_ include your fix in version 3.3.16-1 (currently in experimental) [1] http://packages.debian.org/source/gtk+3.0 Maybe this bug should be reassigned to the appropriate package (binary package libgtk-3-0, I would say), marked as forwarded to https://bugzilla.gnome.org/show_bug.cgi?id=666842 and marked as fixed in version 3.3.16-1 . I can do this by myself, but, first, I would like to check whether you agree. Please let me know. Thanks for your time! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpJGsY2kkNAL.pgp Description: PGP 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#663468: audacious-plugins: [regression] jack output plugin fails to start jack server
Package: audacious-plugins Version: 3.2.1-3 Severity: normal Hello, I've just upgraded audacious on my Debian testing boxes: [REMOVE, NOT USED] libmcs1 [INSTALL, DEPENDENCIES] audacious-plugins-data [INSTALL, DEPENDENCIES] libbs2b0 [INSTALL, DEPENDENCIES] libguess1 [INSTALL, DEPENDENCIES] libmpg123-0 [UPGRADE] audacious 2.4.4-1 - 3.2.1-2 [UPGRADE] audacious-plugins 2.4.4-1+b2 - 3.2.1-3 [UPGRADE] libaudclient2 2.4.4-1 - 3.2.1-2 [UPGRADE] libaudcore1 2.4.4-1 - 3.2.1-2 I think I found a regression: the jack output plugin is no longer able to start the jack server and spits out errors like the following ones, as soon as I try to play something: ERR: bio2jack.c::JACK_Error(967) Cannot connect to server socket err = No such file or directory ERR: bio2jack.c::JACK_Error(967) Cannot connect to server socket ERR: bio2jack.c::JACK_Error(967) jack server is not running or cannot be started ERR: bio2jack.c::JACK_Error(967) Cannot connect to server socket err = No such file or directory ERR: bio2jack.c::JACK_Error(967) Cannot connect to server socket ERR: bio2jack.c::JACK_Error(967) jack server is not running or cannot be started ERR: bio2jack.c::JACK_OpenDevice(1019) jack server not running? My setup used to work perfectly with audacious/2.4.4-1 and previous versions. I still have the environment variable set: $ env | grep JACK JACK_START_SERVER= and the following configuration file: $ cat ~/.jackdrc /usr/bin/jackd --temporary --realtime -d alsa --softmode --hwmeter --rate 44100 If I manually start jackd with the above-quoted command-line, after starting audacious and before attempting to play something, the jack outplug plugin works flawlessly and I can listen to music and everything is back to normal. But apparently, the jack output plugin fails to start the jack server, when it does not find it already running. Please fix this annoying bug. Thanks for your time! -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages audacious-plugins depends on: ii audacious-plugins-data3.2.1-3 ii libasound21.0.25-2 ii libatk1.0-0 2.2.0-2 ii libaudcore1 3.2.1-2 ii libavcodec53 4:0.8-1+b1 ii libavformat53 4:0.8-1+b1 ii libavutil51 4:0.8-1+b1 ii libbinio1ldbl 1.4-14 ii libbs2b0 3.1.0+dfsg-2 ii libc6 2.13-27 ii libcairo-gobject2 1.10.2-6.2 ii libcairo2 1.10.2-6.2 ii libcddb2 1.3.2-3 ii libcdio-cdda0 0.81-5 ii libcdio10 0.81-5 ii libcue1 1.4.0-1 ii libcurl3-gnutls 7.24.0-1 ii libdbus-1-3 1.4.18-1 ii libdbus-glib-1-2 0.98-1 ii libfaad2 2.7-7 ii libflac8 1.2.1-6 ii libfluidsynth11.1.5-2 ii libfontconfig12.8.0-3.1 ii libfreetype6 2.4.8-1 ii libgcc1 1:4.6.3-1 ii libgdk-pixbuf2.0-02.24.1-1 ii libglib2.0-0 2.30.2-6 ii libgtk-3-03.2.3-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.8~dfsg.1-1 ii libmms0 0.6.2-3 ii libmodplug1 1:0.8.8.4-1 ii libmp3lame0 3.99.4+repack1-1 ii libmpg123-0 1.12.1-3.2 ii libmtp9 1.1.2-2 ii libneon27-gnutls 0.29.6-1 ii libnotify40.7.4-1 ii libogg0 1.2.2~dfsg-1 ii libpango1.0-0 1.29.4-2 ii libpulse0 1.1-3 ii libresid-builder0c2a 2.1.1-13 ii libsamplerate00.1.8-3 ii libsdl1.2debian 1.2.15-2 ii libsidplay2 2.1.1-13 ii libsndfile1 1.0.25-4 ii libstdc++64.6.3-1 ii libusb-0.1-4 2:0.1.12-20 ii libvorbis0a 1.3.2-1.1 ii libvorbisenc2 1.3.2-1.1 ii libvorbisfile31.3.2-1.1 ii libwavpack1 4.60.1-2 ii libx11-6 2:1.4.4-4 ii libxcomposite11:0.4.3-2 ii libxml2 2.7.8.dfsg-7 ii libxrender1 1:0.9.6-2 ii multiarch-support 2.13-27 ii zlib1g1:1.2.6.dfsg-2 Versions of packages audacious-plugins
Bug#640747: audacious: Put on all workspaces (Ctrl-S) option is not honored after a while
severity 640747 normal found 640747 3.2.1-2 thanks On Tue, 06 Sep 2011 17:26:26 -0700 Stefano Forli wrote: Package: audacious Version: 2.3-2 Severity: minor The option to show the GUI on all workspaces stops working after some time of usage, and requires to be re-set. Awkward, I started experiencing this bug today, as soon as I upgraded from audacious/2.4.4-1 to audacious/3.2.1-2 , but I am convinced that I am experiencing the same bug as originally reported by Stefano. Or, at least, the current incarnation of this bug... Here's what happens: 0) I start audacious 1) audacious appears on the workspace where I started it from 2) I set Put on All Workspaces from the View menu 3) audacious becomes visible on all workspaces, as desired 4) I listen to music: good! \m/ 5) I quit audacious The problem is: next time I start audacious, it has apparently forgotten this option and again appears in one workspace only. That is to say, the loop repeats from step 0. Possibly useful information: I configure audacious to use the Winamp Classic Interface, and my desktop is Fluxbox. Please do not hesitate to ask for more information, if needed. Dear audacious maintainers, I hope you are able to reproduce the bug, and that you may fix it soon. Thanks for your time! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpi0z6NmYfMv.pgp Description: PGP 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#645347: audacious-plugins: [regression] is no longer able to play audio CDs
Package: audacious-plugins Version: 2.4.4-1+b2 Severity: normal Hello, I noticed what seems to be a regression in Audacious or in the Audio CD Plugin. I seem to be no longer able to play audio CDs with Audacious. I remember that it used to work long ago (but I don't exactly know in which version I last tested this feature). Please note that I can play local audio files and Internet audio streams. Here's what happens. I insert an audio CD in the CD/DVD drive, I click on the eject button in Audacious's interface, and select Audio Disc from the pane on the left (titled Places). An error dialog window appears, saying: Could not mount Audio Disc Location is not mountable This puzzles me a lot, since I don't expect audio CDs to be mounted at all, in order to play them! Anyway: $ grep cdrom /etc/fstab /dev/cdrom1/media/cdrom0 udf,iso9660 user,noauto 0 0 $ ls -lF /dev/cdrom1 /dev/sr0 lrwxrwxrwx 1 root root 3 Oct 14 18:43 /dev/cdrom1 - sr0 brw-rw+ 1 root cdrom 11, 0 Oct 14 18:43 /dev/sr0 and my user belongs to the cdrom group. I can mount data CDROMs without any problem. What's wrong? Has the way to play audio CDs with Audacious changed since the last time I successfully listened to one? Do I recall incorrectly? Could you please help me? Thanks for your time. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages audacious-plugins depends on: ii libasound21.0.24.1-4 ii libatk1.0-0 2.2.0-1 ii libaudcore1 2.4.4-1 ii libbinio1ldbl 1.4-14 ii libc6 2.13-21 ii libcairo2 1.10.2-6.1 ii libcddb2 1.3.2-3 ii libcdio-cdda0 0.81-4 ii libcdio10 0.81-4 ii libcue1 1.4.0-1 ii libcurl3-gnutls 7.21.7-3 ii libdbus-1-3 1.4.16-1 ii libdbus-glib-1-2 0.98-1 ii libfaad2 2.7-7 ii libflac8 1.2.1-6 ii libfluidsynth11.1.5-1 ii libfontconfig12.8.0-3 ii libfreetype6 2.4.6-2 ii libgcc1 1:4.6.1-4 ii libgdk-pixbuf2.0-02.24.0-1 ii libglib2.0-0 2.28.6-1 ii libgtk2.0-0 2.24.4-3 ii libjack-jackd2-0 [libjack-0.116] 1.9.7~dfsg-1 ii liblircclient00.9.0~pre1-1 ii libmcs1 0.7.2-2 ii libmms0 0.6.2-2 ii libmowgli20.7.1-1 ii libmtp9 1.1.0-4 ii libneon27-gnutls 0.29.6-1 ii libogg0 1.2.2~dfsg-1 ii libpango1.0-0 1.28.4-3 ii libpulse0 1.0-4 ii libresid-builder0c2a 2.1.1-8 ii libsamplerate00.1.8-1 ii libsdl1.2debian 1.2.14-6.4 ii libsidplay2 2.1.1-8 ii libsndfile1 1.0.25-3 ii libstdc++64.6.1-4 ii libusb-0.1-4 2:0.1.12-19 ii libvorbis0a 1.3.2-1 ii libvorbisenc2 1.3.2-1 ii libvorbisfile31.3.2-1 ii libwavpack1 4.60.1-1 ii libx11-6 2:1.4.4-2 ii libxcomposite11:0.4.3-2 ii libxml2 2.7.8.dfsg-4 ii libxrender1 1:0.9.6-2 ii zlib1g1:1.2.3.4.dfsg-3 Versions of packages audacious-plugins recommends: ii audacious 2.4.4-1 audacious-plugins suggests no packages. -- no debconf information ___ 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#536705: creox works
notfixed 536705 creox/0.2.2rc2-4 found 536705 creox/0.2.2rc2really0.2.2rc2-1 reopen 536705 ! thanks On Mon, 26 Jul 2010 23:22:17 +0200 Francesco Poli wrote: On Thu, 22 Jul 2010 16:01:48 +0200 Adrian Knoth wrote: [...] creox is working fine, I've just tried it. I have been unable to get creox, fmit (see bug #523925), or rakarrack (see bug #578309) to work correctly with my setup. [...] You're clearly using it in a wrong way. Quite possible, but I would like to find out why! ;-) I've just tried for the n-th time: it does not work for me. Please help me in pinpointing the problem! It helps to fire up qjackctl and manually rewire the signal flow. I've done so many times: even in the simplest case (fmit has only one input port and no output ports), connecting the two system capture ports to fmit input port does not help: fmit seems to be unable to capture sounds. I checked the wiring with qjackctl and the connections seem to be in order. Also make sure to disable hardware monitoring on your soundcard, otherwise you'd always hear the clean sound (it's looped back to the speakers in the hardware mixer) I now run jackd without the --hwmon option. Is it enough to disable hardware monitoring or have I to do something with ALSA configuration? I am now unable to hear any sound from the speaker when I pluck guitar strings. Once again: do I need to do anything else to disable hardware monitoring? -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgps0yjWUV8T5.pgp Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#536705: creox works
On Thu, 22 Jul 2010 16:01:48 +0200 Adrian Knoth wrote: Hi! Hello! creox is working fine, I've just tried it. I have been unable to get creox, fmit (see bug #523925), or rakarrack (see bug #578309) to work correctly with my setup. [...] You're clearly using it in a wrong way. Quite possible, but I would like to find out why! ;-) It helps to fire up qjackctl and manually rewire the signal flow. I've done so many times: even in the simplest case (fmit has only one input port and no output ports), connecting the two system capture ports to fmit input port does not help: fmit seems to be unable to capture sounds. Also make sure to disable hardware monitoring on your soundcard, otherwise you'd always hear the clean sound (it's looped back to the speakers in the hardware mixer) I now run jackd without the --hwmon option. Is it enough to disable hardware monitoring or have I to do something with ALSA configuration? I am now unable to hear any sound from the speaker when I pluck guitar strings. -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpjsypEeZ72v.pgp Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
