Re: Notice of mailing list closure: pkg-multimedia-maintainers
Excerpts from Reinhard Tartler's message of april 12, 2018 9:44 pm: Hi Dominic, Based on the discussion on this list, please do migrate the pkg-multimedia-maintainers list. Sorry for the short notice. I assume that the list of current subscribers, as well as the rest of the mailman configuration, will be retained, is that right? I'm OK to continue to serve as old and new list owner for the new mailing list. I'd appreciate if other's would step up and help with weeding out the moderation queue. Feel free to add me as moderator. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgpruEKst798O.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#887049: zita-convolver: consider use arch-bits=32/64 fmt in symbol file
Quoting Jaromír Mikeš (2018-01-13 10:55:39) > 2018-01-13 4:42 GMT+01:00 YunQiang Su <wzss...@gmail.com>: > > > Package: src:zita-convolver > > Version: 3.1.0-6 > > > > https://manpages.debian.org/unstable/dpkg-dev/dpkg-gensymbols.1.en.html > > New version of dpkg support a new syntax like: > >(arch-bits=32)32bit_specific_symbol@Base 1.0 > >(arch-bits=64)64bit_specific_symbol@Base 1.0 > > > > Please consider use this. > > I am working on porting Debian to some new architectures. > > This syntax seems great for new ports. > > > Hi, > > I have tried add this to symbols file ... > > (arch-bits=32)(c++)"Convlevel::alloc_aligned(unsigned int)@Base" 3.0.2 > (arch-bits=64)(c++)"Convlevel::alloc_aligned(unsigned long)@Base" 3.0.2 > > but build failed ... > >dh_makeshlibs -O-Smakefile -O-Dlibs > dpkg-gensymbols: error: long)@Base" is not a valid version > dh_makeshlibs: failing due to earlier errors > > No idea what's a wrong ... > Are you more familiar with new syntax? Can you provide a patch? First check if the package uses pkg-kde-tools - if it does then install that package and follow "man pkgkde-symbolshelper". Else try this (i.e. pipe-separated instead of multiple parentheses): (arch-bits=32|c++)"Convlevel::alloc_aligned(unsigned int)@Base" 3.0.2 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: libgig compat 10 vs 11
Quoting Jaromír Mikeš (2018-01-03 19:29:36) > When bumped compat dh to 11 I am getting this errors ... files are > installed same in doc package with dh 10 and 11 > > E: libgig-doc: doc-base-file-references-missing-file libgig-doc:8 > /usr/share/doc/libgig-doc/html/index.html > E: libgig-doc: doc-base-file-references-missing-file libgig-doc:9 > /usr/share/doc/libgig-doc/html/* > > Any idea how to fix this? What did debhelper documentation say about that change in compatibility level? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] gsequencer/master: fix missing build dependencies in debian/tests/control
Quoting James Cowgill (2017-11-24 18:43:20) > On 24/11/17 17:35, Jonas Smedegaard wrote: > > Quoting James Cowgill (2017-11-24 17:18:25) > >> On 24/11/17 16:15, jkraehemann-gu...@users.alioth.debian.org wrote: > >>> The following commit has been merged in the master branch: > >>> commit 99483a11ecdd167d4e87ed74fffd31ca53ff998a > >>> Author: Joël Krähemann <jkraehem...@gmail.com> > >>> Date: Fri Nov 24 17:13:13 2017 +0100 > >>> > >>> fix missing build dependencies in debian/tests/control > >>> > >>> diff --git a/debian/tests/control b/debian/tests/control > >>> index a830078..1dfbb57 100644 > >>> --- a/debian/tests/control > >>> +++ b/debian/tests/control > >>> @@ -16,4 +16,24 @@ Depends: > >>> xvfb, > >>> fakeroot, > >>> libgtk2.0-dev, > >>> + debhelper, > >>> + gettext, > >>> + libcunit1-dev, > >>> + xauth, > >>> + libinstpatch-dev, > >>> + libsndfile1-dev, > >>> + libsamplerate-dev, > >>> + libxml2-dev, > >>> + ladspa-sdk, > >>> + dssi-dev, > >>> + lv2-dev, > >>> + libgmp-dev, > >>> + libasound2-dev, > >>> + libjack-dev, > >>> + libpulse-dev, > >>> + uuid-dev, > >>> + docbook-xsl, > >>> + docbook-xml, > >>> + gtk-doc-tools, > >>> + xsltproc > >> > >> Probably best to get rid of all of those and use '@builddeps@' instead. > > > > Please elborate, I don't know that trick. > > https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst#n115 > > " > ``@builddeps@`` will be replaced by the package's > ``Build-Depends:``, ``Build-Depends-Indep:``, and > ``build-essential``. This is useful if you have many build > dependencies which are only necessary for running the test suite and > you don't want to replicate them in the test ``Depends:``. However, > please use this sparingly, as this can easily lead to missing binary > package dependencies being overlooked if they get pulled in via > build dependencies. > " Thanks! :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: calf package failed build
Quoting James Cowgill (2017-11-27 14:46:08) > On 27/11/17 13:28, Jonas Smedegaard wrote: > > NB! I notice you bumped debhelper compatibility but did not mention why > > - please consider reverting that change unless you know of a concrete > > need for more modern debhelper version that is available in oldstable, > > as tightening makes backporting more complex. > > Isn't debhelper 10 in oldstable-backports? Possibly. Which makes it posible but - as is my point - more complicated to backport, as it then is limited to backporting to environments including oldstable-backports. Please note that I do not talk only about backporting to the semi-official Debian backports.debian.org, but more generally about backports. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: calf package failed build
Quoting IOhannes m zmölnig (Debian/GNU) (2017-11-27 13:55:50) > On 2017-11-27 11:26, Jaromír Mikeš wrote: >> while I started work on calf package it failed to build :( >> Any idea what is wrong? I am not very familiar with cdbs. From a brief look, problem seems to be related to refreshing autotools. Calf packaging deliberately avoids using dh-autoreconf, because that tool does (or did, last I check) cleanup without restoring original files (just removing them) which does not play nice with some styles of git-based package maintenance (with git-buildpackage used with caff you will need to use either --git-ignore-new or --git-export, either of which risk masquerading other packaging problems). > i'm not an uploader of calf, but used CDBS for most of my packages in > the past. > however, these days CDBS provides less and less features compared to > dh - so i think a switch to dh should be considered if it makes > packaging significantly easier for those involved (rumour has it that > even *the* CDBS guy switches to dh (for some packages) - or at least > thinks about it...;-)) > > for the packages i was involved, the main cdbs features have been: > - licensecheck > - build multiple flavours > > the first feature has become obsoleted by the "licensecheck" package > which allows to write a single licensecheck rule in d/rules for any > packaging helper. Licensecheck does not yet fully replace the CDBS wrapper. When it does (or when another wrapper independent from CDBS gts available) then indeed that is one less reason to stick to CDBS. > afaict, the 2nd feature still mandates cdbs (unless you like to do > things manually all the way). > > since calf doesn't build multiple flavours, i see little reason to not > switch. A reason not to switch is familiarity with current packaging style among those involved in maintaining the package. Great with additional maintainers, Jaromír! Good that you bring up the trouble you ran into. NB! I notice you bumped debhelper compatibility but did not mention why - please consider reverting that change unless you know of a concrete need for more modern debhelper version that is available in oldstable, as tightening makes backporting more complex. Thanks for the reflections on CDBS in general, IOhannes! I will try take some time to look at calf packaging, including limiting its use of CDBS. I do not feel ready yet to abandon CDBS, so doing that for Calf means alienating me from the packaging. I am (mildly but) not strongly against that, just mentioning as a different view on the issue compared to IOhannes' view. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] gsequencer/master: fix missing build dependencies in debian/tests/control
Quoting James Cowgill (2017-11-24 17:18:25) > Hi, > > On 24/11/17 16:15, jkraehemann-gu...@users.alioth.debian.org wrote: > > The following commit has been merged in the master branch: > > commit 99483a11ecdd167d4e87ed74fffd31ca53ff998a > > Author: Joël Krähemann <jkraehem...@gmail.com> > > Date: Fri Nov 24 17:13:13 2017 +0100 > > > > fix missing build dependencies in debian/tests/control > > > > diff --git a/debian/tests/control b/debian/tests/control > > index a830078..1dfbb57 100644 > > --- a/debian/tests/control > > +++ b/debian/tests/control > > @@ -16,4 +16,24 @@ Depends: > > xvfb, > > fakeroot, > > libgtk2.0-dev, > > + debhelper, > > + gettext, > > + libcunit1-dev, > > + xauth, > > + libinstpatch-dev, > > + libsndfile1-dev, > > + libsamplerate-dev, > > + libxml2-dev, > > + ladspa-sdk, > > + dssi-dev, > > + lv2-dev, > > + libgmp-dev, > > + libasound2-dev, > > + libjack-dev, > > + libpulse-dev, > > + uuid-dev, > > + docbook-xsl, > > + docbook-xml, > > + gtk-doc-tools, > > + xsltproc > > Probably best to get rid of all of those and use '@builddeps@' instead. Please elborate, I don't know that trick. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: virtual package "video-player"?
Quoting IOhannes m zmölnig (Debian/GNU) (2017-11-13 21:50:32) > thanks jonas for the reply, > > On 11/13/2017 08:59 PM, Jonas Smedegaard wrote: > > Quoting IOhannes m zmölnig (Debian/GNU) (2017-11-13 19:59:28) > >> > >> a good name might be "video-player" or "desktop-video-player" (i'd > >> favour the first). > >> > >> > >> what do you think? > >> if we can come to a consensus, i'd propose this on debian-devel. > > > > To address bug#881326, fallback dependencies should be limited to tools > > not exploding in your face in a non-GUI environment, and tools using > > same syntax to play media. > > hmm, well: > in the specific case of bug#881326, it turned out that the > "Recommends:mpv" was indeed intended to mean "mpv" specifically, rather > than "a generic video player" (as i originally assumed). > so for bug#881326, the "video-player" virtual package is irrelevant anyhow. > > however, i still think being able to install "*a* video player capable > of playing my video collection" is a desirable goal. > > > Simplest approach to address issues like bug#881326 generally would > > probably be to extend package sensible-utils with a "sensible-player", > > knowledgeable about the possible players in Debian fitting the critera.> > > /etc/alternatives could be used (in addition to or instead of > > sensible-utils helper) to provide local sysadmin freedom to prioritize > > among multiple installed players. > > i personally favour a decentralized effort, where any sensible video > player can declare their usability themselves (rather than depending on > a gatekeeper (sensible-utils) to decide which one is part of that group). > (just telling; sensible-utils allows for such a decentralized workflow > anyhow) > i consider "sensible-player" a bad naming (for the thing i was > proposing), as it is too generic. Ok. Then how about doing this, for each video player package: * Package "Provides:" gui-video-player * postinst script register with update-alternatives as providing "/usr/bin/gui-video-player". Done. > in any case, i don't really buy the "not exploding in your face in a > non-GUI environment" argument, in this case. > i'm talking explicitly about an application that displays videos as > pixel data. i see little (useful) ways to not have a GUI (that is: an > X-server or the like) to display a video. Fine - that simply means that you only care about the gui case, not the non-gui-supportive case - which is fine by me - I just recommend to then include "gui" in the virtual name to make that constraint explicit. (alternative keyword is "x11" but I guess in these modern times with Wayland it might be more sensible with the more abstract "gui") > the proposal was modeled after the already existing "pdf-viewer", with > similar uses. > afaict, each "pdf-viewer" will pull in GUI (so you can actually *view* > something). > as a consequence, it is hardly ever "depended" on (mostly recommended or > suggested) - it's perfectly valid to store PDFs on your fileserver that > doesn't have a desktop; otoh, many people who install PDFs via packages > might actually want to look at them. > similarily, i suspect that most people installing software to download > movies will actually want some way to view them (and then there's a few > who don't). If you propose something as vague as "pdf-viewer" then I disagree there is a need for it. Can you elaborate on use cases? It is common in Debian to include a bunch of PDF documents in a package and then declare sloppily "needs a viewer for this stuff" without a need for triggering said viewer - but I am unaware that it is common in Debian to ship a bunch of video files needing similar package hinting. If you want to hint to _users_ that they can pick whatever, then a better approach than virtual package name is to use debtags: axi-cache search video::player interface::graphical (...and then update debtags for e.g. mpv to improve such lookups) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: virtual package "video-player"?
Quoting IOhannes m zmölnig (Debian/GNU) (2017-11-13 19:59:28) > While looking into [881326], i realized that there is no single > (virtual) package to install a desktop video player. > > i'd like to suggest the introduction of such a package that should be > provided by any general purpose standalone desktop video player that is > capable of playing "any" video format (e.g. the thing that your average > desktop user can install and which will play their video collection). > > here's a quick list of potential packages that should provide it: > - bangarang - Multimedia player with a lightweight interface for KDE > - dragonplayer - simple video player > - gmerlin - multiformat media player > - gst123 - GStreamer based command line media player > - kaffeine - versatile media player for KDE > - mplayer - movie player for Unix-like systems > - mpv - video player based on MPlayer/mplayer2 > - parole - media player based on GStreamer framework > - totem - Simple media player for the GNOME desktop based on GStreamer > - vlc - multimedia player and streamer > - gxine - the xine video player, GTK+/Gnome user interface > - xine-console - the xine video player, user interface > - xine-ui - the xine video player, user interface > > the list was assembled via a quick "apt-cache search", rather than > consulting multimedia-tasks. > > i'm mostly using vlc these days, so i don't know much about the quality > of most players in the list; so there might be some false positives; > also, it's not unlikely that i forgot your favourite player. > the list excludes specialized players (ser-player, aview) and expert > systems (xjadeo, melt) on purpose. for now, it also excludes various GUI > frontends to media-players like mplayer (assuming that having mplayer > installed is enough to play a file - either via cmdline or by > file-association) > > a good name might be "video-player" or "desktop-video-player" (i'd > favour the first). > > > what do you think? > if we can come to a consensus, i'd propose this on debian-devel. To address bug#881326, fallback dependencies should be limited to tools not exploding in your face in a non-GUI environment, and tools using same syntax to play media. Simplest approach to address issues like bug#881326 generally would probably be to extend package sensible-utils with a "sensible-player", knowledgeable about the possible players in Debian fitting the critera. /etc/alternatives could be used (in addition to or instead of sensible-utils helper) to provide local sysadmin freedom to prioritize among multiple installed players. A virtual package would not help resolve runtime decision on what tool to invoke, but tools either known by sensible-utils helper or registering themselves with a coordinated /etc/alternatives name could additionally declare themselves as providing that common name - either is-intended-for-GUI-use or should-survive-console-use.. mpv is usable for both, but seems xine-console is sensible only for the latter (but I don't know, just judge from reading its description).. > oh, and while being there i was also thinking about a virtual package > "music-player" (for playing your music collection of OGG, MP3, FLAC, > WAV,... files). (i don't have a special need for that right now; it > just occured to me to be useful). Makes sense - but possibly there is no need for distinction but we can introduce only too new helpers: sensible-gui-player and sensible-console-player. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: kodi with framebuffer on cubox-i
Quoting Rainer Dorsch (2017-10-03 19:33:15) > I experimented with kodi on the cubox-i without proprietary > extensions. So far no luck yet, but I think I have not yet hit the > hard roadblocks... > > First I tried without an X-server directly on framebuffer. How would I > tell kodi not to search for an X11 display? Just a wild guess: Perhaps this related to bug#878324? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: RFC: Enabling http transport of files to mpd within an mpd client?
Quoting Stuart Prescott (2017-10-12 11:14:28) > your opinions on the security implications of enabling an http server > within cantata (an mpd client) to send local files to mpd are desired. > The changes that Jonas describes are now in a new upstream release > that I'd like to upload soon. I believe both the MPD protocol itself and the streaming protocol it supports are unencrypted, and MPD is therefore sensible to use only within a trusted network. I see no need to disable the ability for our users to enable an additional unencrypted side-channel for MPD-related traffic. Instead of disabling the feature, it might make sense to mention the embedded http daemon in long description and README.Debian with a suggestion to install a personal firewall, and have the package suggest firewalld. You might also file a bug upstream to suggest isolating that mechanism as a plugin, so that it could be packaged as a separate binary package, allowing our users to explicitly avoid the feature completely, while still enjoy the rest of the program. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#878000: ardour5 does not start on debian/testing it spins trying to load GTK2 breeze theme
Quoting wzabo...@elektron.elka.pw.edu.pl (2017-10-08 15:02:03) > W dniu 08.10.2017 o 14:53, Jonas Smedegaard pisze: > > Quoting wzabo...@elektron.elka.pw.edu.pl (2017-10-08 14:38:01) > >> W dniu 08.10.2017 o 14:13, Jonas Smedegaard pisze: > >>> Quoting Wojciech Zabołotny (2017-10-08 13:34:16) > >>>> When I start the jack server, and then ardour5, it does not start. > >>>> The "top" shows that ardour5 uses one CPU core in 100%. > >>>> When I start it via "strace", I get the following messages displayed > >>>> repeatedly: > >>> [...] > >>>> It looks, that ardour tries to load the Breeze gtk theme, and when it > >>>> fails, > >>>> it repeats that forever. > >>>> I can see two problems there: > >>>> 1. ardour should depend on the appropriate package providing the required > >>>>GUI theme > >>>> 2. ardour should fail, displaying the reasonable error message without > >>>>looping forever. > >>> Ardour does _not_ depend on a specific GTK+ widget theme. > >>> > >>> Perhaps a bug elsewhere - e.g. in GTK+ or that particular theme - is > >>> triggered? > >>> > >>> Did you configure your environment to use Breeze? Could you please try > >>> switch to a different GTK+ theme instead? > >>> > >>> Perhaps create a temporary new user on your system and start Ardour from > >>> there - to help avoid cruft in your own $HOME environment interfering. > >>> > >> Dear Jonas, > >> > >> Thanks a lot for your suggestions. > >> > >> That's interesting. Of course, I have cleaned up the ~/.config/ardour4 > >> and ~/.config/ardour5 directories before submitting the first report, > >> and it didn't help. > > So you tried cleanup, but only the (too narrow) part you suspected to > > cause the error. > > > > > >> However indeed, when I logged in as another user, ardour started > >> correctly. > > Good to hear! > > > > > > > > > >> So the problem probably indeed is not ardour related (however I don't > >> know why only ardour suffers from that). > > It might very well be that Ardour is particularly vulnerable to being > > fed a broken GTK+ theme. Which seems to be the case here. > > > > > >> PS. Is it possible that > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874598 is caused by > >> the same problem? > > Possibly, yes. But instead of (again) too narrowly draw conclusion best > > to find something that works (e.g. a fresh account) and triangulate from > > there, as you did here. > > > Yes, I do agree. However I think that the important news for other > affected users is that removal of ~/.gtkrc-2.0 (if exists) may help. > Otherwise the user would be forced to wipe his account... If indeed that solves *both* these reported bugs, then true. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#878000: ardour5 does not start on debian/testing it spins trying to load GTK2 breeze theme
Quoting wzabo...@elektron.elka.pw.edu.pl (2017-10-08 14:38:01) > W dniu 08.10.2017 o 14:13, Jonas Smedegaard pisze: > > Quoting Wojciech Zabołotny (2017-10-08 13:34:16) > >> When I start the jack server, and then ardour5, it does not start. > >> The "top" shows that ardour5 uses one CPU core in 100%. > >> When I start it via "strace", I get the following messages displayed > >> repeatedly: > > [...] > >> It looks, that ardour tries to load the Breeze gtk theme, and when it > >> fails, > >> it repeats that forever. > >> I can see two problems there: > >> 1. ardour should depend on the appropriate package providing the required > >>GUI theme > >> 2. ardour should fail, displaying the reasonable error message without > >>looping forever. > > Ardour does _not_ depend on a specific GTK+ widget theme. > > > > Perhaps a bug elsewhere - e.g. in GTK+ or that particular theme - is > > triggered? > > > > Did you configure your environment to use Breeze? Could you please try > > switch to a different GTK+ theme instead? > > > > Perhaps create a temporary new user on your system and start Ardour from > > there - to help avoid cruft in your own $HOME environment interfering. > > > Dear Jonas, > > Thanks a lot for your suggestions. > > That's interesting. Of course, I have cleaned up the ~/.config/ardour4 > and ~/.config/ardour5 directories before submitting the first report, > and it didn't help. So you tried cleanup, but only the (too narrow) part you suspected to cause the error. > However indeed, when I logged in as another user, ardour started > correctly. Good to hear! > So the problem probably indeed is not ardour related (however I don't > know why only ardour suffers from that). It might very well be that Ardour is particularly vulnerable to being fed a broken GTK+ theme. Which seems to be the case here. > PS. Is it possible that > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874598 is caused by > the same problem? Possibly, yes. But instead of (again) too narrowly draw conclusion best to find something that works (e.g. a fresh account) and triangulate from there, as you did here. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#878000: ardour5 does not start on debian/testing it spins trying to load GTK2 breeze theme
Hi Wojciech, First of all, thanks for reporting this! Quoting Wojciech Zabołotny (2017-10-08 13:34:16) > When I start the jack server, and then ardour5, it does not start. > The "top" shows that ardour5 uses one CPU core in 100%. > When I start it via "strace", I get the following messages displayed > repeatedly: [...] > It looks, that ardour tries to load the Breeze gtk theme, and when it fails, > it repeats that forever. > I can see two problems there: > 1. ardour should depend on the appropriate package providing the required >GUI theme > 2. ardour should fail, displaying the reasonable error message without >looping forever. Ardour does _not_ depend on a specific GTK+ widget theme. Perhaps a bug elsewhere - e.g. in GTK+ or that particular theme - is triggered? Did you configure your environment to use Breeze? Could you please try switch to a different GTK+ theme instead? Perhaps create a temporary new user on your system and start Ardour from there - to help avoid cruft in your own $HOME environment interfering. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: kodi with framebuffer on cubox-i
Quoting Rainer Dorsch (2017-10-04 22:38:58) > On Mittwoch, 4. Oktober 2017 10:34:00 CEST Jonas Smedegaard wrote: > [...] > > Correction: Debian Kodi is built with --enable-gles on > > armel/armhf/arm64. > > Good news :-) > >> I have no experience (yet) running Kodi on arm (be it framebuffer or >> X11), but am quite interested in our official package best possible >> covering the needs of our users: In case you (or others following >> along here) figure out some build configuration tuing needed then >> please do not hesitate to file wishlist bugreports :-) > > I am not yet there... > >> Heck, even if you have only vague dreams like "awww, please get Kodi >> to work from framebuffer on Vivante-based armhf devices" you might >> also file a (wishlist!) bugreport about that, to have a well-defined >> place to collect the details until substantial enough act on it. > > Is there any information which is useful for you which should be > appended to the bugreport? Don't think of me as the recipient: Think of it as a way to create an interest group around a narrow, actionable topic. You raised this as a cross-post on two mailinglists somewhat related to your topic. Those are good places to seek help, I just imagine it might be even better if then the detailed discussion happening elsewhere only among those really interested in that detailed topic (myself included) - and I offer a way to do that by use of a wishlist bugreport with the kodi package. What I imagine is useful is your clues for the puzzle. And a link to the wiki page you might have created for tracking facts about the puzzle. Ideally, cross-posts to multiple lists come with an explicit invitation to which *single* place to follow up. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: kodi with framebuffer on cubox-i
Quoting Paul Wise (2017-10-05 06:32:21) > On Thu, Oct 5, 2017 at 4:37 AM, Rainer Dorsch wrote: > > > I checked versions now, I should be good, but the xserver still does not > > start (started with the Xserver now and look to kodi as a second step). > > Please put the full Xorg log on paste.debian.net. > > > rd@xbian:~$ apt-cache policy mesa-va-drivers > > The GPU package is libgl1-mesa-dri, video decoding is a completely > separate matter, no idea about that but I guess the ffmpeg commit you > mentioned would have to reach Debian for that. Seems to me that ffmeg change is only about speeding up processing (by making some data paths shorter) - something else needs to provide the actual codecs. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#877656: kodi: supports insecure download of non-free addons
Quoting IOhannes m zmölnig (2017-10-04 09:31:09) > On Wed, 04 Oct 2017 03:08:17 +0200 Jonas Smedegaard <d...@jones.dk> wrote: > > Quoting Felipe Sateler (2017-10-04 00:32:21) > > > > > > I think your patch mainly addresses issue number 2, doesn't it? Fixing > > > issue 1 would require asking upstream to provide > > > https://mirrors.kodi.tv/addons/krypton/addons.xml.gz.md5 (and upgrade > > > to a better hash algorithm). > > > > Uhm, my patch is the very window to not requiring upstream to solve the > > security issue: > > are you sure you wanted to say this? > > for me it kind of implies that: > - either all users of kodi use it only through the packages provided > (and patched) by Debian. > - or any other users are not affected by the security concerns of using > http:// (e.g because only the http-implementation provided by Debian is > susceptible to mitm-attacks) > - or all non-Debian users simply don't deserve a solution for that > security fix. > > i cannot agree with any of these points, and i do think that any bug > with severity "grave" that is not specific to Debian should be forwarded > to upstream to be solved there (well, actually *any* bug that is non > Debian-sepcific, not just the grave ones) . You read me wrong. My patch allows us to _fix_ this bug without cordinating with upstream. My patch does not, however, relieve us of our duty to _inform_ upstream of the underlying bug that it fixes. Felipe stated that _fixing_ the bug _requires_ us to involve upstream, and I disagree with (only) that. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: kodi with framebuffer on cubox-i
Quoting Jonas Smedegaard (2017-10-03 21:00:36) > Hi Rainer, > > Quoting Rainer Dorsch (2017-10-03 19:33:15) > > I experimented with kodi on the cubox-i without proprietary > > extensions. So far no luck yet, but I think I have not yet hit the > > hard roadblocks... > > Interesting! > > >> First I tried without an X-server directly on framebuffer. How would >> I tell kodi not to search for an X11 display? > [...] >> Any input and ideas are welcome. > > Girst hit I got web-searching for "kodi framebuffer" was a discussion > around "git clone https://aur.archlinux.org/kodi-c2-fb.git;. That git > has at its heart the configure options "--disable-x11 --enable-gles". > > Debian kodi package has those options reversed. > > So it seems you need to recompile the kodi package... Correction: Debian Kodi is built with --enable-gles on armel/armhf/arm64. I have no experience (yet) running Kodi on arm (be it framebuffer or X11), but am quite interested in our official package best possible covering the needs of our users: In case you (or others following along here) figure out some build configuration tuing needed then please do not hesitate to file wishlist bugreports :-) Heck, even if you have only vague dreams like "awww, please get Kodi to work from framebuffer on Vivante-based armhf devices" you might also file a (wishlist!) bugreport about that, to have a well-defined place to collect the details until substantial enough act on it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#877656: kodi: supports insecure download of non-free addons
Quoting Felipe Sateler (2017-10-04 00:32:21) > On Tue, Oct 3, 2017 at 7:04 PM, Jonas Smedegaard <d...@jones.dk> wrote: >> Quoting Felipe Sateler (2017-10-03 23:32:24) >>> On Tue, Oct 3, 2017 at 5:49 PM, Jonas Smedegaard <d...@jones.dk> wrote: >>>> Kodi supports downloading and loading addons at runtime. >>>> >>>> Official addon feed is served only via http and contain non-free >>>> addons. >>>> >>>> Allowing to extend the system with non-free addons at runtime by >>>> default is arguably an anti-feature in itself. Doing so insecurely >>>> poses a risk of malicious code getting into users' home and >>>> executed by Kodi. >>>> >>>> Attached patch relaxes to make addon feed optional. >>> >>> Making plugin feeds optional sounds good though. >> >> Right. >> >> I realize my choice of words might be confusing: feed is optional in >> code with the patch, meaning it won't fail to start if missing. On >> the packaging level I however intend at first to have kodi >> _recommend_ the feed, so it will be pulled in by default - so until >> an alternative exist it is an "opt-out" not an "opt-in". > > BTW, I think there are two issues conflated here: > > 1. Insecure downloading of code > 2. Non-free addons available by default. > > I think your patch mainly addresses issue number 2, doesn't it? Fixing > issue 1 would require asking upstream to provide > https://mirrors.kodi.tv/addons/krypton/addons.xml.gz.md5 (and upgrade > to a better hash algorithm). Uhm, my patch is the very window to not requiring upstream to solve the security issue: When I can setup a curated service with DFSG-free parts, then (because my code will be released as Free software) you can setup a curated service of all parts. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#877656: kodi: supports insecure download of non-free addons
Quoting Felipe Sateler (2017-10-03 23:32:24) > On Tue, Oct 3, 2017 at 5:49 PM, Jonas Smedegaard <d...@jones.dk> wrote: > > Package: kodi > > Version: 2:17.3+dfsg1-2 > > Severity: grave > > This severity feels a bit inflated. After all, you can download and > run non-free programs using a web browser too! When you browse into <https://evil.example.com/>, download scarycode.sh from there and execute it in a shell, then you are to blame if your foot gets blown away. If instead you open your media center, it automatically updates an addon but the http connection gets hijacked and redirected to http://evil.example.com/ where scarycode.sh instead gets loaded and blows off your foot, then I dare say not you but your media center is to blame. > > Tags: security upstream patch > > Justification: user security hole What severity would you use for user security hole? Or do you disagree that using hardcoded http in an _internal_ interface is a user security hole? > > Kodi supports downloading and loading addons at runtime. > > > > Official addon feed is served only via http and contain non-free > > addons. > > > > Allowing to extend the system with non-free addons at runtime by > > default is arguably an anti-feature in itself. Doing so insecurely > > poses a risk of malicious code getting into users' home and executed > > by Kodi. > > > > Attached patch relaxes to make addon feed optional. > > Making plugin feeds optional sounds good though. Right. I realize my choice of words might be confusing: feed is optional in code with the patch, meaning it won't fail to start if missing. On the packaging level I however intend at first to have kodi _recommend_ the feed, so it will be pulled in by default - so until an alternative exist it is an "opt-out" not an "opt-in". > > I intend to move the addons feed configuration file to a separate > > package "kodi-repository-kodi" and, at first, ship that package in > > main recommended by kodi. > > > > Later when an alternate package "kodi-repository-curated" is > > available¹, I intend to favor that over kodi-repository-kodi and > > move the latter to contrib. > > I don't think moving to contrib makes sense. Either the package fits > the requirements for main or it doesn't. > > I don't think this package should go in contrib, as it doesn't *need* > any software not available in main. So it should not be moved there. Whoops, that final part was not meant to be sent: I agree package being insecure is not a reason to move it to contrib (I got distracted by that other political aspect which we are not in consensus about). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#877656: kodi: supports insecure download of non-free addons
Package: kodi Version: 2:17.3+dfsg1-2 Severity: grave Tags: security upstream patch Justification: user security hole -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Kodi supports downloading and loading addons at runtime. Official addon feed is served only via http and contain non-free addons. Allowing to extend the system with non-free addons at runtime by default is arguably an anti-feature in itself. Doing so insecurely poses a risk of malicious code getting into users' home and executed by Kodi. Attached patch relaxes to make addon feed optional. I intend to move the addons feed configuration file to a separate package "kodi-repository-kodi" and, at first, ship that package in main recommended by kodi. Later when an alternate package "kodi-repository-curated" is available¹, I intend to favor that over kodi-repository-kodi and move the latter to contrib. - Jonas ¹ I am setting up a web service "addons.debian.net" which (among other things) will provide a curated feed of Kodi plugins, filtered to list only DFSG-free addons. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlnT98AACgkQLHwxRsGg ASFMZxAAgXo0sDusWtQHM8KIRzEeYClOdpuL+91tzCCjgtQaHK2APUx94LyvDYuL rDdv+Ej26g4paCk5tryCLkdwuJmdtpyfV8JlXwgDbPaaZP//fPqMazct+1jcz9bV ALBG74QqFAjgeidUdZ2DlpIpZaCFB1M2Qaf/ertezTLiHu65jtPrLgx5NIsUYjKf sXOdvQl3b0oXC3BABLhKEWzZEoB1L08DgTxn/H/xwMsKvgQ6UIYvBpiloiLIJ/pz DRYvpF0crM3UD+wN53KM6YfzZuFeVeCbL1bZnlzz7Js9FleyFGMx7m6OTtwMIU4p SgtaRm2atNkYrmjN+sjZjOWwGGmyKag7BUNWUDn/L++NZiTvxZ1Qvl1zk3cH9Pp+ pgN4CW1/6PYuj6Q75WPwnyGEaB0jssotCj6aiNF8nBf4IExPQ/o6tvTy3YEyOCfJ woFiX+s1VymJOd7jvUX+h4VaG3adM4u2Ttj3p3E5qP4CjewiR2PC4nqQZymzaWSh i+nSubGZ4mx70PIlSAKoCMptrC1yfRM9u9getz6q/bSWBLd5pO/gM74+MNNqeYj8 JpGebLdzdlRSny0tv3MPGdEl/iwCkhum3Br5UZCq+L1ZM6NsB3e1YGp/6QsYkNAI ecWQGNN5/QEkPqz+uyiynf8FEhZn7GURJ6FiF49JN/T7Ly0oAeQ= =pgk+ -END PGP SIGNATURE- Description: Support omitting addons repository feed Upstream official addon repository feed contain non-free addons. . Extending the system at runtime is arguably an anti-feature - either for political reasons or due to security risks. . This patch makes it possible to omit the addons repository feed. Author: Jonas Smedegaard <d...@jones.dk> Last-Update: 2017-10-03 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/system/addon-manifest.xml +++ b/system/addon-manifest.xml @@ -21,7 +21,7 @@ metadata.local metadata.themoviedb.org metadata.tvdb.com - repository.xbmc.org + repository.xbmc.org resource.images.weathericons.default resource.language.en_gb resource.uisounds.kodi ___ 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: kodi with framebuffer on cubox-i
Hi Rainer, Quoting Rainer Dorsch (2017-10-03 19:33:15) > I experimented with kodi on the cubox-i without proprietary > extensions. So far no luck yet, but I think I have not yet hit the > hard roadblocks... Interesting! > First I tried without an X-server directly on framebuffer. How would I > tell kodi not to search for an X11 display? [...] > Any input and ideas are welcome. Girst hit I got web-searching for "kodi framebuffer" was a discussion around "git clone https://aur.archlinux.org/kodi-c2-fb.git;. That git has at its heart the configure options "--disable-x11 --enable-gles". Debian kodi package has those options reversed. So it seems you need to recompile the kodi package... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: Repacking of rtmidi
Quoting Jaromír Mikeš (2017-10-02 19:53:58) > 2017-10-02 15:59 GMT+02:00 IOhannes m zmölnig (Debian/GNU) < > umlae...@debian.org>: > > > On 10/02/2017 02:50 PM, Felipe Sateler wrote: > > > Why do we do it? There is no documentation about it :( . In > > > particular, some reasons (windows stuff) does not appear to be > > > relevant anymore. The doc images are also removed, do we think they > > > are non-free ? > > > > no idea. > > however, the same applies to rtaudio. > > > > When I stepped in rtaudio and rtmidi they both has been already stripped > out. > So probably only Alessio knows ... that time only maintainer. From a related patch I would guess it is an issue of non-free embedded ICC profile. Sure would help to have it properly documented, however. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: boost problem while packaging SuperCollider 3.8
Quoting Dan S (2017-09-25 12:37:36) > The SC team actually have patches applied to their own boost: > https://github.com/supercollider/supercollider/blob/develop/external_libraries/boost_sc_changes.patch That patch seems useful to push upstream to Boost developers. > It's possible that using bundled+patched boost would fix these > difficulties, though I'm not sure if this would be acceptable. Best is to identify _all_ deviations from pristine Boost, identify for each case if it can be upstreamed, and for changes that cannot if those can be ignored in Debian, and if not then package a forked Boost library. I.e. *not* sneak in a forked Boost as embedded code copy. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#876096: closing 876096
Quoting IOhannes m zmölnig (Debian/GNU) (2017-09-18 16:16:47) > On 2017-09-18 15:31, Jonas Smedegaard wrote: >> Quoting IOhannes m zmölnig (Debian/GNU) (2017-09-18 14:42:19) >>> what's the difference between the drumkits provided by the >>> "hydrogen-drumkits" package and the ones that can be downloaded via >>> the "free" feed? >> >> The difference is that hydrogen-drumkits package provides our users >> with all the drumkits that Debian has to offer which are packaged, >> whereas the default Hydrogen feed provides our users with access to >> drumkits claimed to be Free licensed. > > so what's the difference? In an ideal World with surplus of disk space and Debian maintainers, none. > which drumkits are included in hydrogen-drumkits that are not "claimed > to be Free licensed" (regardless of RC#869180; even so all of the kits > included in hydrogen-drumkits are *claimed* to be under a free > license)? If the addons.debian.net service provided non-free drumkits due to bogus metadata, that would be a bug in the service. > which drumkits do you get by using the feed URL but not having > hydrogen-drumkits installed? The drumkits listed in the feed. > is this an issue about reducing downloaded data/disk space? No, issue is that upstream mechanism to download addons include nonfree licensed addons. As the title of the bugreport states. You do indeed save disk space by imposing licensing rules, but that is not intended: I would very much appreciate us being able to fill the harddrives of our users with Hydrogen drumkits :-) >>> why is the upstream URL being removed from the source-code? (rather >>> than just *adding* the only-free URL and making it the default?) >> >> URL is replaced (not removed) because it contains non-free items. > > well, yes; my point was that the upstream URL is no longer there. Ok. > i'm with you that we should offer free data as the forst choice. > i don't know why we should hide away the fact that there *is* non-free > data which might. Aim of the bugfix is not to hide, but to address the bug. I realize now that effectively I am also hiding knowledge about the upstream feed. That was unintended! I will add a README.Debian file documenting how Debian package deviates from upstream. Full disclosure: I am hired by laptop maker Purism to help maintain their Debian derivative PureOS, which aims to achieve FSF endorsement and therefore at some places have aims not fully aligned with Debian aims. FSF do arguably want to "hide" information about non-free stuff. I choose to do most possibly of my work for Purism by improving Debian rather than forking from Debian - even though forking would be far easier, in part because I would then not need to defend my actions as I do now. Thanks for being critical to my work here! > all documentation (that i could find) silently assumes that the user > will be able to install the "official Hydrogen drumkits" from within > the application by clicking "Update List" in the "Import Library" > section. Right. Documentation exist (as first hit when I searched for "hydrogen drumkits" without quotation marks in DuckDuckGo) about _other_ feeds, but I failed to notice that the default feed is assumed to be hardwired and therefore not mentioned at those places. Which kinda makes sense. I will improve the fix. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#876096: closing 876096
Quoting IOhannes m zmölnig (Debian/GNU) (2017-09-18 14:42:19) > On 2017-09-18 14:14, Jonas Smedegaard wrote: > > close 876096 0.9.7-3 > > thanks > > > > honestly i think this is a rather pointless exercise. Point is to provide our users with Free licensed software by default. > what's the difference between the drumkits provided by the > "hydrogen-drumkits" package and the ones that can be downloaded via > the "free" feed? The difference is that hydrogen-drumkits package provides our users with all the drumkits that Debian has to offer which are packaged, whereas the default Hydrogen feed provides our users with access to drumkits claimed to be Free licensed. > why is the upstream URL being removed from the source-code? (rather > than just *adding* the only-free URL and making it the default?) URL is replaced (not removed) because it contains non-free items. Sorry, I thought that was obvious: That is the very bug being addressed. > this is actively taking away the freedom-of-choice from our users, and > thus harmful. Our users have the freedom to add additional feed URLs, same as they can add non-free sources to their APT configuration. I fail to see how non-free stuff being opt-in is removal of freedoms. > i would suggest to: > - undo the fix for #876096 > - have hydrogen-drumkits only include non-disputed drumkits (which i > think are *much* more than the 2 kits provided by the current feed) I am currently working on setting up a service addons.debian.net offering a automatically curated feed, subscribing to one or more upstream feeds and stripping non-free and unlicensed items. At first I am implementing for Kodi - when that is in place I will implement for Hydrogen, and update the patch to point to that service instead of the current proper but indeed quite limited feed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#876096: hydrogen: mechanism to download addons include nonfree licensed addons
Package: hydrogen Version: 0.9.7-2 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hydrogen supports downloading additional drumkits. The URL for a feed for such drumkits is configurable, and by default points to a feed curated by the upstream authors of Hydrogen. Unfortunately that feed contains both free and non-free drumkits. This bug was fixed in 0.9.7-3 by patching the code to use an alternative feed curated with the explicit scope of only freely licensed resources. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlm/tz4ACgkQLHwxRsGg ASFsqw/+PTBS8H7hxMpiC77eIjD9qHPJFbaIR9Zk3aKOAT5fi1TeMVzyc/6aF16Y 04Y7rftjc9qjUUHtPS4OJTzYBaJ/hFoLjVSi31+M3mnKtiQ+bVWcGJoxj78YCQ5f v2pT4wcrfxrjmFmXwrNH1CZZMz4BhsPG54sHAci9dEFwTnekdfxmq+ugdooPWuSv kUKvsEjCIsx5ZJ8sQmSnv3013o2LlAJ1HHzven7Wyg1Ct5EjpcdX4oGqCJvNqE8s q5CRWKoZOMm/sxcLwpF5fsPbsxAmXIKMgnjGJGlecdXHVttzWIHPJNdRJdRYv0yO uf/T6The9C1agN5Hy30LZF/NIumjN6g3tGLxlC+YgPQyeNioDLHP2gr3tanGj756 l9vI3lqNMYt9sk+sSt3etjm+89bUrxWu9Aorf1i6z+gF16AMuj3/LNsaGWS6DxdB MwE6CDyu7VEeiYqLEWq/0MszrZxn2QMluKGCe3IIXckRSiY/YSmfNhed6oTPCEMZ 2yEZVO2lfDZdNQS3nlQEPpeMVB5bF1Zn92bIP+PjffL7MI7sbSy9sO+j6VTU40JD 2xGkUOvRZerF6O5PqdJ5+l0CusXLSyKHPnnpDIpanVSGHeuEzdCaAWaOny3Z4TTv YQRbAFuk426vk9PknLjqydVqUcRxlbIaKf8E6iYe6IpGiPUm7Tg= =/kXn -END 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#874799: guitarix: Depends on gvfs-backends
Quoting Andy Irving (2017-09-09 19:30:36) > Package guitarix should have a dependency on gvfs-backends. Needed for > preset download, as it no longer depends on webkit. Sounds better to then recommend gvfs-backends. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#873430: python3-mediagoblin: requires pyexiv2 unavailable for Python 3.x
Package: python3-mediagoblin Version: 0.9.0~dfsg-1~exp2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 mediagoblin.media_types_raw_image imports pyexiv2 which is only available for Python 2.x. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlmi87wACgkQLHwxRsGg ASFd/A//YFF9MmGIsYISpCXVfPpta7+xxXtN1Q+e689+Jg5GKl+zELn53bAYAiLK cZ8xZEr9vEYx6Cc90DbaUpXa79b59VALIPOY6MI6EQypMnKIBAWZijsOaazHnlOt hq7Lkxb8+pPlxnWm3n4Zs4KPQF2Q7gjI0RbAngq3Se8F/sgz8HvaMQzw38E/JoxX Pcdx1Wro1p+yHcw6ye46PvU3O+U1BtG8o4Ch8AzvlKjXAFCsDeUQtUp41vYUYK8/ n0Z2ap2f0rvs2CbvGAoXnBhlpq92byAkAprt0TlZhaQY11pNU1dqkHHVIyNW3nxB AHSKIv5MarSeeBgAS6+8otCasofLIDsximtOr4c8HvOsqE3Ywne9Lp8OeNjhnBuU ir5Gg/26rchetVSDERbGL67KBHHlMBAEAoSLs9ycEhHMeJxvF3VDTkJMS1s+i1O5 p1c6YOWEAgU9e5QJqMwenF8k/QpXDOmuQr8xbse+hRCI40Ei5Ig3YGRPG3TKwj5I vtiqGqYaUTcK3sb/z1jzh5DjimN1d/281SOx7P8iD86XugLyvWaAtBTSw0mg9+RG 3pyCMzJDmlukWehU4qjkU7sMHexDaUGs6nmcGnOtFF0H1jXhwUOg2kEBniPBe90s 5AwagSPiQplIruhBgq9X0NuDQDVHm1Y3zqFdY+TGkpvzbcrBk7E= =zjKr -END 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: [SCM] ardour/master: Modernize cdbs: Do copyright-check in maintainer script (not during build).
Quoting Jaromír Mikeš (2017-08-21 21:25:00) > 2017-08-21 16:56 GMT+02:00 Jonas Smedegaard <d...@jones.dk>: > > > > > So no, this should not be addressed in script nor by hand. It should be > > fixed in lintian: Someone (you, if you agree with above) should file a > > bugreport against lintian requesting that it limits the FIXME check to > > the copyright file (or at least make an explicit excemption for > > debian/copyright_hints). > > > > Ok ... bug reported Great. Thanks! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] ardour/master: Modernize cdbs: Do copyright-check in maintainer script (not during build).
Quoting Jaromír Mikeš (2017-08-21 16:35:39) > 2017-08-21 15:13 GMT+02:00 Jonas Smedegaard <d...@jones.dk>: > > > Quoting Jaromír Mikeš (2017-08-21 14:37:25) > > > 2017-08-21 14:07 GMT+02:00 Jonas Smedegaard <d...@jones.dk>: > > > > The script works for me - just tested again. Could you please tell > > > > exactly which commands you invoked which lead to "Nothing". > > > > > > > > > > Well "nothing" was not precise ... :( > > > > > > $ debian/copyright-check > > > CDBS: parsing Ardour-5.11.0.tar.bz2 ... > > > Parsing Ardour-5.11.0.tar.bz2... > > > > > > bzip2: Compressed file ends unexpectedly; > > > perhaps it is corrupted? *Possible* reason follows. > > > bzip2: Inappropriate ioctl for device > > > Input file = (stdin), output file = (stdout) > > > > > > It is possible that the compressed file(s) have become corrupted. > > > You can use the -tvv option to test integrity of such files. > > > > > > You can use the `bzip2recover' program to attempt to recover > > > data from undamaged sections of corrupted files. > > > > Looks like source should be fixed to not include an empty tarball. > > > > Ohh :( > > > Can't locate Image/ExifTool.pm in @INC (you may need to install the > > > Image::ExifTool module) > > > > apt install libimage-exiftool-perl > > > > (similar for other Perl modules) > > > > Thank you Jonas now it works ... copyright_hints now contains a lot of > "FIXME" entries. > It's giving a lot of lintian errors ... could this be fixed by improving > script or it need to be fixed manually? The very _purpose_ of the copyright_hints file is to _hint_ about copyright and licensing information, and to distinguish hints from facts - i.e. to avoid maintainers blindly trusting the hints by copying over to copyright file without double-checking - I invented the pattern of adding a FIXME. It is therefore a good thing that lintian nowadays check and complain if copyright file has FIXME entries, but it is a bug that it complains about FIXME entries in copyright_hints file. So no, this should not be addressed in script nor by hand. It should be fixed in lintian: Someone (you, if you agree with above) should file a bugreport against lintian requesting that it limits the FIXME check to the copyright file (or at least make an explicit excemption for debian/copyright_hints). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] ardour/master: Modernize cdbs: Do copyright-check in maintainer script (not during build).
Quoting Jaromír Mikeš (2017-08-21 14:37:25) > 2017-08-21 14:07 GMT+02:00 Jonas Smedegaard <d...@jones.dk>: > > The script works for me - just tested again. Could you please tell > > exactly which commands you invoked which lead to "Nothing". > > > > Well "nothing" was not precise ... :( > > $ debian/copyright-check > CDBS: parsing Ardour-5.11.0.tar.bz2 ... > Parsing Ardour-5.11.0.tar.bz2... > > bzip2: Compressed file ends unexpectedly; > perhaps it is corrupted? *Possible* reason follows. > bzip2: Inappropriate ioctl for device > Input file = (stdin), output file = (stdout) > > It is possible that the compressed file(s) have become corrupted. > You can use the -tvv option to test integrity of such files. > > You can use the `bzip2recover' program to attempt to recover > data from undamaged sections of corrupted files. Looks like source should be fixed to not include an empty tarball. > Can't locate Image/ExifTool.pm in @INC (you may need to install the > Image::ExifTool module) apt install libimage-exiftool-perl (similar for other Perl modules) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] ardour/master: Modernize cdbs: Do copyright-check in maintainer script (not during build).
Quoting Jaromír Mikeš (2017-08-21 13:23:55) > 2017-08-21 13:00 GMT+02:00 Jonas Smedegaard <d...@jones.dk>: > > Quoting Jaromír Mikeš (2017-08-21 12:10:35) > > > I might be wrong, but d/copyright-check script doesn't generate > > > copyright_newhints for me :( > > > > What then happens instead? > > > > Nothing That's weird. Just silence? Not even some error message? Just to make sure we are talking about the same thing: What I mean by "not during build" is that the script now needs to be run explicitly. If you only ran (your favorite wrapper for) debuildpackage, then sure it didn't do copyright check - that is intentional. > If your script doesn't work I would keep info how to do it manually in > README.source. The script works for me - just tested again. Could you please tell exactly which commands you invoked which lead to "Nothing". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] ardour/master: Modernize cdbs: Do copyright-check in maintainer script (not during build).
Quoting Jaromír Mikeš (2017-08-21 12:10:35) > 2017-08-21 11:35 GMT+02:00 Jonas Smedegaard <d...@jones.dk>: > > Hi Jonas, > > Quoting Jaromír Mikeš (2017-08-21 08:43:02) > > > 2017-07-31 8:25 GMT+02:00 <j...@users.alioth.debian.org>: > > > > > > > The following commit has been merged in the master branch: > > > > commit c48460d12c633074a6aae6b572d0d805b3433667 > > > > Author: Jonas Smedegaard <d...@jones.dk> > > > > Date: Mon Jul 31 02:10:16 2017 -0400 > > > > > > > > Modernize cdbs: Do copyright-check in maintainer script (not during > > > > build). > > > > > > > > diff --git a/debian/README.source b/debian/README.source > > > > index 684ef50..2146866 100644 > > > > --- a/debian/README.source > > > > +++ b/debian/README.source > > > > @@ -48,6 +48,9 @@ You are of course free to *not* run the script, if > > you > > > > prefer. > > > > > > > > copyright_newhints > > > > -- > > > > -run this command to generade copyright_newhints file: > > > > -licensecheck --check '.*' --recursive --copyright --deb-fmt --ignore > > > > '^(waf|(icons|gtk2_ardour)/icons/.*\.png|tools/osx_ > > > > packaging/.*\.png|gtk_ardour/.*splash\.png|doc/ardour_meter_ > > > > colors\.png|doc/layering/.*\.png|icons/made_with/ardour_ > > > > made\.png|debian/(changelog|copyright(|_hints|_newhints)))' --lines 0 > > * | > > > > /usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints > > > > > > > > > > > This is not right way to generate copyright_newhints now? > > > If not which one? > > > > I won't label them as "right" and "wrong" ways, but the approach I use > > nowadays is the one expressed by the commit you quote: To do > > copyright-check in a maintainer script instead of during build. > > > > Not sure what more you are asking - I believe it is all part of the git > > commit. > > > I might be wrong, but d/copyright-check script doesn't generate > copyright_newhints > for me :( What then happens instead? Does it make coffee? Blue smoke coming out of the fans of your laptop? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] ardour/master: Modernize cdbs: Do copyright-check in maintainer script (not during build).
Hi Jaromír, Quoting Jaromír Mikeš (2017-08-21 08:43:02) > 2017-07-31 8:25 GMT+02:00 <j...@users.alioth.debian.org>: > > > The following commit has been merged in the master branch: > > commit c48460d12c633074a6aae6b572d0d805b3433667 > > Author: Jonas Smedegaard <d...@jones.dk> > > Date: Mon Jul 31 02:10:16 2017 -0400 > > > > Modernize cdbs: Do copyright-check in maintainer script (not during > > build). > > > > diff --git a/debian/README.source b/debian/README.source > > index 684ef50..2146866 100644 > > --- a/debian/README.source > > +++ b/debian/README.source > > @@ -48,6 +48,9 @@ You are of course free to *not* run the script, if you > > prefer. > > > > copyright_newhints > > -- > > -run this command to generade copyright_newhints file: > > -licensecheck --check '.*' --recursive --copyright --deb-fmt --ignore > > '^(waf|(icons|gtk2_ardour)/icons/.*\.png|tools/osx_ > > packaging/.*\.png|gtk_ardour/.*splash\.png|doc/ardour_meter_ > > colors\.png|doc/layering/.*\.png|icons/made_with/ardour_ > > made\.png|debian/(changelog|copyright(|_hints|_newhints)))' --lines 0 * | > > /usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints > > > > > This is not right way to generate copyright_newhints now? > If not which one? I won't label them as "right" and "wrong" ways, but the approach I use nowadays is the one expressed by the commit you quote: To do copyright-check in a maintainer script instead of during build. Not sure what more you are asking - I believe it is all part of the git commit. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#872781: mediagoblin: empty mediagoblin package?
Quoting Rogério Brito (2017-08-21 10:22:49) > I was excited to see that we had mediagoblin accepted in our archive, > since I want to use it for my personal media. > > Unfortunately, right after installing it, I have not found any easy > way of running it and the mediagoblin package apparently only pulls > the dependencies... And it only contains documentation, being, > otherwise, an empty package. > > Is this correct/expected? Yes, it is released to experimental because it is not yet usable. Furthermore I messed up the git sources so was unable to release improved packages until it was approved from ftpmaster. What I have prepared (and hopefully find time to release today) is more complete but still has a lot of loose ends. You are quite welcome to join me in maintaining mediagoblin - but if you want to just work then wait until it gets released to unstable. Thanks for your interest in this, and for asking, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#870233: smplayer: executes javascript code downloaded from insecure URL
Source: smplayer Version: 17.7.0~ds0-1 Severity: grave Tags: security Justification: user security hole -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 smplayer includes code in src/basegui.cpp to download and (I guess) execute javascript code for parsing youtube paths. The download URL is http://updates.smplayer.info/yt.js which is insecure and therefore I suspect easy to replace with evil code. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAll+w9sACgkQLHwxRsGg ASEgTA//QMLa7jZwjXz3F1r+2NkukhdvQ5QQyZsXbk8sfHyOnCpHJmy2fqZhudmx uq3hhOyCD1SVGLTGp0YURWe8ScwhebjqXfvtNIV4Xzz7oGkXGqWeBaYuYuEyvOF+ UtTDmKtg2ZbvbOjyuq4krEr8sKEH37WJn02esrDsrXSGrXmz5I42+pAlau5/vecb NaHmcBs+jDKkLkoziKn3CSauqmmHXIn58ECO/cLD1ziPYGuZDjjgafUKxhQfDcKz v5S/NbleKzWIMbgicpcXoru3FE88iBs8rKW0X8o0rg2AYXlvYjoTKFj3SAv5MYiv Tlo9TgT7iWNXb2yK0FuxDDeG/FaM5g741CAWfAj/j9qTEF1E2Zf3F+YOrReFtMdw szl2q2kw6vkmQzVA+0jBZIIw2VJCuMyDBxV5aDEEyaaw7Mc0l1rAFxHPcdq/Os/Q UkW38xn5M0GMYOZAMOu55ymP6f5StrOTRqURUGCxY3ZcVTBSRMzG57ds8WlkcGa0 Rxb8EK/nCjAkbye7k1g9ajYuYEbYqdknBLZs9ngAEPF/CmadUmv7a+dfwAhfjy99 vXBiyJxNrwHwMZqqbZ7GYkplZOap5cuthJsA127bd9M4935ZmwgGY6hrx3+y4b5J 9FNO/9x1etJ2+skGjY+1t9vDBOuhqtE6VlR0i0N1bMKkxKM7J2w= =ZQlT -END 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#869180: src:hydrogen-drumkits: source contains unlicensed material (bogusly treated as GPL-2)
Quoting umlae...@debian.org (2017-07-29 17:20:53) > Zitat von Jonas Smedegaard <d...@jones.dk>: > >> > > >> > These drumkits are in upstream metadata listed _without_ license: > >> > > >> > ColomboAcousticDrumkit (sf) > >> > EasternHop (sf) > >> > Electric Empire (sf) > >> > HardElectro (sf) > >> > HipHop-1 (sf) > >> > HipHop-2 (sf) > >> > Millo's MultiLayered 2 (sf) > >> > Synthie-1 (sf) > >> > VariBreaks (sf) > >> > > >> > In Debian copyright file those are listed as licensed GPL-2. > >> > >> The fact that the metadata doesn't contain a license, does not imply > >> that these files are not GPL-2. Have you actually checked the license > >> of any of these? > > > > The issue here is that information about licensing is unavailable in the > > source package. Title now rephrased to not avoid assumption. > > > > If licensing is based on external information and/or guesswork, then > > that should be documented in debian/copyright. > > hmm. > > the "orig.tar.gz" contains this information, since it includes > "drumkits.json" which includes the licenses for each drumkit as > specified by (their) upstream(s) (which is mostly a casual short name, > rather than the full license text; however, this doesn't make the > licenses any less valid). > > since "drumkits.json" is generated by a script in debian/ this might > require some additional information, so: > > the licenses are obtained from the same source as the information on > how to obtain the drumkits: > "their drumkit feed" (as it is called in debian/README.source). > with "them" being upstream (hydrogen), and their "drumkit feed" being > http://www.hydrogen-music.org/feeds/drumkit_list.php > it is my understanding that this feed is generated from information > that has been directly entered by the upstreams' of the various > drumkits. i have no reason to distrust this source of information. > > therefore, for me the license information *has* been added by > upstream, albeit on a separate channel, and i don't see any problem > with the licenses as stated in d/copyright) > > i agree, this should probably be added to the d/README.source A week ago I updated debian/copyright in git to elaborate on origin of copyright and licensing as best as I could - which took XML feed into account. In that process, I relicensed some of the drumkits as I found no evidence of the stated licensing but evidence of another. I have failed to identify a source of copyright + licensing for the following, however: EasternHop-1 HipHop-1 HipHop-2 Synthie-1. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#865516: ffmpeg: please compile with --enable-libzmq
Quoting James Cowgill (2017-07-27 11:52:49) > On 22/06/17 10:39, Jonas Smedegaard wrote: > > Package: ffmpeg > > Version: 7:3.2.6-1 > > Severity: wishlist > > > > FFMpeg supports altering states during runtime via ZeroMQ. > > > > Please enable that feature, by build-depending on libzeromq-dev and > > configure with --enable-libzmq option. > > It looks to me like this has already been enabled? It's even enabled in > stretch. Indeed, libavfilter6 is now linked with libzmq5. As I recall I tried to use it and failed, inspected "man ffmpeg-full" which says it required building with --enable-libzmq, and "ffmpeg -L" does not mention that option. I guess this bug can be closed - but I still suggest to enable it explicitly to get it hinted in runtime header output (and to ensure that build fails rathr than this feature silently gets disable in case the autodetection misses it at some point). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] serd/master: Restore .gitignore file.
Quoting Jaromír Mikeš (2017-07-24 08:38:34) > 2017-07-24 8:34 GMT+02:00 <mira-gu...@users.alioth.debian.org>: > > > The following commit has been merged in the master branch: > > commit dc1395d9d974f2b171b2b45e28419ba23ac40a9b > > Author: Jaromír Mikeš <mira.mi...@seznam.cz> > > Date: Mon Jul 24 02:28:43 2017 +0200 > > > > Restore .gitignore file. > > > > diff --git a/.gitignore b/.gitignore > > new file mode 100644 > > index 000..224e7f0 > > --- /dev/null > > +++ b/.gitignore > > @@ -0,0 +1 @@ > > +.pc/ > > > > Hi, > > on importing new release of package .gitignore file get deleted ... I > guess gbp behavior changed ... How to fix this or is new way there how > to ignore .pc/? Yes, git-buildpackage changed. I guess the new behaviour is to to play nicer with dgit. Have a look at README.Source of e.g. hydrogen, where IOhannes documents the use of a gbp hook he recently introduced there. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#869180: src:hydrogen-drumkits: source contains unlicensed material (bogusly treated as GPL-2)
Control: retitle -1 src:hydrogen-drumkits: Some sources lack licensing Quoting James Cowgill (2017-07-21 11:56:15) > On 21/07/17 10:49, Jonas Smedegaard wrote: > > Package: src:hydrogen-drumkits > > Version: 2015.09.28-1 > > Severity: serious > > Justification: Policy 2.2.1 > > > > These drumkits are in upstream metadata listed _without_ license: > > > > ColomboAcousticDrumkit (sf) > > EasternHop (sf) > > Electric Empire (sf) > > HardElectro (sf) > > HipHop-1 (sf) > > HipHop-2 (sf) > > Millo's MultiLayered 2 (sf) > > Synthie-1 (sf) > > VariBreaks (sf) > > > > In Debian copyright file those are listed as licensed GPL-2. > > The fact that the metadata doesn't contain a license, does not imply > that these files are not GPL-2. Have you actually checked the license > of any of these? The issue here is that information about licensing is unavailable in the source package. Title now rephrased to not avoid assumption. If licensing is based on external information and/or guesswork, then that should be documented in debian/copyright. > For instance, a brief google search seems to indicate that the first one > on your list (ColomboAcousticDrumkit) is GPL-2 licensed: > http://freepats.zenvoid.org/Percussion/acoustic-drum-kit.html Thanks for the valuable info - now added to debian/copyright. Do you have similar info for the other sources? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#869180: src:hydrogen-drumkits: source contains unlicensed material (bogusly treated as GPL-2)
Package: src:hydrogen-drumkits Version: 2015.09.28-1 Severity: serious Justification: Policy 2.2.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 These drumkits are in upstream metadata listed _without_ license: ColomboAcousticDrumkit (sf) EasternHop (sf) Electric Empire (sf) HardElectro (sf) HipHop-1 (sf) HipHop-2 (sf) Millo's MultiLayered 2 (sf) Synthie-1 (sf) VariBreaks (sf) In Debian copyright file those are listed as licensed GPL-2. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAllxzkMACgkQLHwxRsGg ASElKBAApwwOF1ii7YQvV3qaTvt6MwfMUkARW4+FII9CEsqf2UQEbNUwm7oN07jL 4faAXhQ94Xdb1NwmTKmq82QmmD9y8MuaEps8EvfLn5cvML21+54Kwr5upt8uEnF+ wKFKD/6nRqab8qGnu0u6cryGKFLE6jyV7dEGYrh4NB0DKcpv6f322c970v9p9wqK tx8hBklGm+cWH9aZ/91avuAQJQ/wLhEESKohWTGfUSWQJn6bw0gEgqw+xI1QCi04 L+6brY7cck5T0ZomebDOfCcm05fshBsi7XuYxL4WnVtDGcwiDWkhEvTIDXcVPUbN WzVyhn78e1aCtZ5wGT73OmaJXMhHzM1N3dRxg9JY+uB2I6uA65bxIj6EAkxXDMge 3lZUgO6ETSQS250AH4k2jcEMC6FPIK/KEEI7iWWa/7jIvT7uhM3cchs2fQZXxFLy EgL2RCn/sGtPHvaefCyMNYFPhZDcGYPeGCONKPzg9y+K35iihc7BM0KmVwHSUQ9r ScaUdOuUWUg9RocpAEKbVTxkn5E0ygrtH7eIb/GBK/qJVoRh1+xKOjp9BqYgHVHe eGsEvSV1WIACzc3XU8uLa0NmInPbSGtKNMGbfT7MCrrtwtSSEFsuoHL4pRcibs1v Z3ooVdnfz9K4Serzd4+o2+2E9ZBrpyQ9L3CDuLlHwEV0Hkn1lSM= =YS/0 -END 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: [SCM] hydrogen/master: Revert to debhelper compatibility level 9: No concrete need, and may complicate backortability.
Quoting James Cowgill (2017-07-19 10:56:03) > On 19/07/17 09:42, Jonas Smedegaard wrote: > > Quoting James Cowgill (2017-07-19 10:08:11) > >> On 19/07/17 08:01, j...@users.alioth.debian.org wrote: > >>> The following commit has been merged in the master branch: > >>> commit 9b06c83ac15dd64d9346a30c87b303b002e8efa3 > >>> Author: Jonas Smedegaard <d...@jones.dk> > >>> Date: Wed Jul 19 08:58:20 2017 +0200 > >>> > >>> Revert to debhelper compatibility level 9: No concrete need, and may > >>> complicate backortability. > >>> > >>> This reverts commit a85a269a206db56fd6b023563463f85fdbae0a6b. > >>> > >> [...]> --- a/debian/control > >>> +++ b/debian/control > >>> @@ -8,7 +8,7 @@ Uploaders: > >>> Build-Depends: > >>> cdbs, > >>> licensecheck, > >>> - debhelper (>= 10~), > >>> + debhelper, > >> > >> You mean debhelper (>= 9) ? > > > > No: Debhelper 9 is availiable even in oldstable so need not be declared > > versioned (despite what debhelper/lintian developers might want to make > > you thing). > > I don't think that's a good reason for actively NOT versioning something > when the right version is clearly known. We disagree, then. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] hydrogen/master: Revert to debhelper compatibility level 9: No concrete need, and may complicate backortability.
Quoting James Cowgill (2017-07-19 10:08:11) > On 19/07/17 08:01, j...@users.alioth.debian.org wrote: > > The following commit has been merged in the master branch: > > commit 9b06c83ac15dd64d9346a30c87b303b002e8efa3 > > Author: Jonas Smedegaard <d...@jones.dk> > > Date: Wed Jul 19 08:58:20 2017 +0200 > > > > Revert to debhelper compatibility level 9: No concrete need, and may > > complicate backortability. > > > > This reverts commit a85a269a206db56fd6b023563463f85fdbae0a6b. > > > [...]> --- a/debian/control > > +++ b/debian/control > > @@ -8,7 +8,7 @@ Uploaders: > > Build-Depends: > > cdbs, > > licensecheck, > > - debhelper (>= 10~), > > + debhelper, > > You mean debhelper (>= 9) ? No: Debhelper 9 is availiable even in oldstable so need not be declared versioned (despite what debhelper/lintian developers might want to make you thing). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: generate copyright_newhints file
Hi Jaromír, Quoting Jaromír Mikeš (2017-06-30 12:42:04) > 2017-06-30 11:36 GMT+02:00 IOhannes m zmölnig (Debian/GNU) < > > On 06/30/2017 11:25 AM, Jaromír Mikeš wrote: > > > sorry for question, but I am still not used to CDBS :( No need to apologize about that. Great that you improve your skills by taking challenging tasks, and excellent that you ask about things you are uncertain about! :-) > > > How I can generate copyright_newhints file without building whole > > > package? > > > > iirc, it should be generated in the clean target as well: > > > > DEB_MAINTAINER_MODE=yes dpkg-buildpackage -rfakeroot -Tclean Right. Generally, special package maintenance should be documented in the file debian/README.Source - and that file exist for ardour package, where you would have found above answer too ;-) The shortest (commandline and code executed) is this: debian/rules pre-build DEB_MAINTAINER_MODE=1 > > note, that you will only get a copyright_newhints file if it differs > > from the copyright_hints file. and if it does generate the file, it > > will stop the build anyhow, so you cannot "generate > > copyright_newhints file WITH building the whole package". More accurately, the file debian/copyright_newhints gets generated when debian/copyright_hints exists. When generated, the result is compared against debian/copyright_hints, and if there are _additions_ then the build fails, but if there are either no difference or only omissions then debian/copyright_newhints is deleted and build continues. > I've added DEB_MAINTAINER_MODE=yes dpkg-buildpackage -rfakeroot -Tclean to > d/rules file That's bad: DEB_MAINTAINER_MODE violates Debian Policy, so must not be set during official build e.g. on build daemons: Only set that variable on the commandline or in your local build environment, and *only* set it for *unofficial* builds, not for builds that you then upload to Debian! > But d/copyright_newhints file was not created ... I just got this and build > continued: If by "build continued" you mean that more happened _after_ the instructive messages at the end of your quoted text, then it sounds like you somehow added it in a way that ignored errors. But since it should _only_ be run by the _maintainer_ - not automated at all builds (see above) I am not really interested in the details of why it continued: Please try execute the command on the commandline instead. Or perhaps read and follow the instructive text: > To fix the situation please do the following: > 1) Examine debian/copyright_* and referenced files > 2) Update debian/copyright as needed > 3) Replace debian/copyright_hints with debian/copyright_newhints :-) Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#866207: inkscape: File Rendering in Inkscape is different when openning w/ software or ft png/pdf
Hi luffah, Quoting luffah (2017-06-28 12:34:27) > Package: inkscape > Version: 0.92.1-1 > Severity: normal > > Dear Maintainer, >Thank you for your work, as i see the bug stack is high. >I had a problem which justify to rollback my version of inkscape. > >* What led up to the situation? > [regression] > I had files working with previous version of Inkscape on Jessie. > Now I open and modify the article like files, > the render is ok in Inkscape, when i export to png the render > still ok. > But if i open the svg with an other file previewer (e.g. Comix > wich is stable) or exporting to pdf, some CSS things are > corrupted like text colors and offset. >* What outcome did you expect instead? > I expect that Inkscape produce PDF output files which conserve > the render. Did opening in those same previewers/renderers produce different result in the past? You describe a bug regardless, but relevant to understand if it is a regression. - Jonas P.S. I am not the maintainer, just chiming in with a helpful followup question. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#865517: mpv: please link with libcaca
Package: mpv Version: 0.25.0-2 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 MPV supports linking with libcaca, but that feature is apparently not enabled in Debian builds. Please enable linking with libcaca. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAllLl/QACgkQLHwxRsGg ASE1tRAAkrnfgHkf9NULLl8wMUhltID1yKtImofKKOMOUi702Ul51wOR+bqh5eIc KzZQ/ug5LywK1DDeY19WU0njEPp24MWgQqOLIKCCdDhd9RiWXaDJDIWMDA/PKbAr XNnq6PjJI2IC91TOBuAO+1nToLyl8WOpC0yZdHMMsQbepc1tREL5ZLc6hY4NKD/Q SSD1PIywidVo9z8n+UnGqefMjfDHeJCq1AMTDaw6YnwfpXdurSkMvrqC1HeUd4GT e9ggXpHB3aUwwBkKxpv6MR0dp/zNGub41+8z7UUT0A8RXLCYPqVwMKa2tTg00eXW 7tDUslqX0EUSQeLP7CxmxfKCO0/RwW4G+kUWdyM/V7BMy4LxGd8ilyFy4a5WqWPH 22VXFPbeQFI6yXDiDFeBxYgJrNQluc6ASkM7rWSQnVJWhtnItyL4MfbM5JV/JIEf tsSBvCl/4lBb9fABZF/cnbnhlpgJ8kmCxZ77XTY/sl1je/MNdO5aMFpYVlT0prfN 9/Wmm8ihSP9odpKOlNUGwN0PcyKJ2+PccpYG1Mh/FLZMFtRPU5Z6KsGsZnyQ8oeI ogqKy3axRWfmwB/xsaibfT9BoC1ZxZSm+cf8REiMb/wyjMu+xHEPEuGmKcgD4S77 8EbrWI8TQfrVhD13rQDFH+cWXYSfYUgNSZ+ejJOC4fwObudv/o0= =q19c -END 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#865516: ffmpeg: please compile with --enable-libzmq
Package: ffmpeg Version: 7:3.2.6-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 FFMpeg supports altering states during runtime via ZeroMQ. Please enable that feature, by build-depending on libzeromq-dev and configure with --enable-libzmq option. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAllLkGMACgkQLHwxRsGg ASG/wxAAiJIwtiDAkEXLTkTM/QrjkTInS/ThOhNwofMrfDU5BrbM4oDnFxuv3zRr j3PEljd4ckh+/1uHagQkwhn+Z+w7WBFWap5Dfy2w0wbdLP2GykY1b9Z3OD4gB5ZN DwyCaQlH0gPTQdqJpV1da5E0Lwf/PwykahIHvD3zZ+k6W+EB5Pp0uzvcb+a3RE9L +BsRBXRWIw0oq21G8ZMXvrx9nUEPnIxuLPxjCR22kUV29CR/ZdB+j79V46EVQ9O7 MNfXR4hRlAGgSl6KEjXS1yVoKBHfxvbrtNLNDSUVK0M4HM+On1aQHX4OKmSoFC8p DZKaJpu2SHpZgIYGv+q650u5Jw46mADvWmKlp4QZkwmU3aTOXnzXmd+ZsvQaDqch PGGb7Oi4fOW5jN1cGTusxorPaHqOfBnIpKL1NXeDbW1o068tk9uvoU25Fm837ZbX u9poFpWg/y6Bat+iM22+PYJgNH7smYIjrxgiPhU7kbAAeVTB1riAK13WyBEG0wpG hzCYGmRw90HY+5HLIXvGbdogpOa4droWiYCxXsGbEzi/tAQUJTEHPs4VOOD5GQKe kiMi0508sOHTCnggo4GUj0ZbRWv7KLy7iNI92ZY1ReFFWkWUcJ4qOrU+XeeceRoj NCopIIYOxQDWH0w4y7iY2GqG4J7rmP0I0SgM14wx30TNjGYz+kw= =OTT7 -END 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: Packaging vid.stab
Quoting Rogério Brito (2017-06-22 01:55:21) > I have a need for video stabilization and I saw that Debian is > currently lacking libvidstab, even though the ffmpeg package that it > has packaged supports the library. You might also consider using libmlt - e.g. via its command-line tool melt. It has an alternative vidstab implementation. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#864908: mpv: man page unfished sentence: In earlier mpv versions
Package: mpv Version: 0.25.0-1 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 the man page contain unfinished sentence in section about --audio-spdif option: "In earlier mpv versions" - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAllERPAACgkQLHwxRsGg ASHF4g/+Pvo+VPwY6hKEQWG/oKvjrWBCV/I1t3SOn1uX6UfjfoaySS0wMVUebJ++ NLyoeoQ0YNvEdGF2Ljkclmylg2WTdv2fIcP4F7+X3ZSamtUM7e4qkkuBF8JkHCkx b4dLUFjyPEcym4dexLi4dfmF4X6ARgj/8Tz1P7+ujtATkCMGUA4wJHL/n+fI+Zt9 OFLyJtMfMi03mjO1pHXhIN7Q/tCnbC5IcjmA6Lcs/0KlU8LHHHLAO5/wDpNZmcEZ JnmaxIY7GQHVVxLBA3OCxY2wXqpAxd8xmty7pfklNxcIEbUWls4Bdrk7umg+5/BE +/tGwQaE7hWhF94cMktXE/tfoiXG/4LQ01Acij3GIO3ly95B2alu0ROqOWZnvzv7 TMl8hIvqBer/ipSjM8nFDxAICb7PooKNoyDnO/3d7UKcylhF9ErbEnywqzwAAzpP YZO3Q4BpaivUW8EV6UoN62kAxhwqC9olhMsY/Ugr4c9fNzmZuMxiMqtHMuTFEg0K VNALyoADt5o9psxuWVTFxLfBnqtDsAjBf1oZIRtuf/v20MuCbv2A0548ReItY+8f iXelFYjOJVQk6mBonlX1D+CXx3krhSoj2v8PpPhWG57jrIUnsphzy8uUl86bHR0p cXPqhxemoZ5un5d1V6mnbb5bwK7u2YV7RX0SXR8EJS0f/BQYNwU= =7LxH -END 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: My Status in Debian
Hi Ross, Quoting Ross Gammon (2017-04-22 12:34:13) > I know I am not a guru like most of you in the team, and that and my > busy life means I am a little slow sometimes, and haven't produced a > lot of work in the team. But I also spend a lot of my time working on > dependencies (javascript & python) for packages in the GIS team, and I > also work on Ubuntu Studio (which is why I am interested in Multimedia > packages). > > Anyway, one of my other sponsors has stated a few times when I have > asked for DM rights for something, that maybe it was time to step up > to DD status. > > I am in no hurry (probably would aim to take the plunge towards the > middle of the year). And I wouldn't do it until there was wider > support for that. So any words of encouragement, or any suggestions of > things that you would like to see from me before you would endorse me > are welcome (here or in private). Do it! Was that enough encouragement? :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#859808: composite: Composite not ready for being qualified package of Debian yet.
Quoting MAROQQO digital media (2017-04-08 12:49:00) > Since I have tested the package I can say that this a 100% copy of an > old Hydrogen version without progression. Quite an interesting claim. > To be honest I really wonder about what qualifies a package to be > added to the repositories of Debian, since I used to tend to the > impression, that Debian is very picky about it (one of the reasons I > choose Debian). Please bring up that question at debian-devel mailinglist - this bugreport is the wrong place for that. > On 04/08/2017 08:52 AM, Jaromír Mikeš wrote: > > I am very sorry that some hydrogen users are confused but I > > personally don't think it is reason strong enough to remove > > composite from debian archive > > Well, this is not the only reason if you read my start post and btw > ... it actually is one of the smaller points actually, Please file separate bugreports for each concrete issue: Discussing "the isssue of this package having too many issues" is far easier to do when each issue is tracked individually. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#853838: crtmpserver: upstream home gone/moved - www.rtmpd.com is dead
Hi Nye, Quoting Nye Liu (2017-02-01 12:52:24) > http://www.rtmpd.com/ is dead and gone, as is svn access. > > The author seems to have mirrored his sources on github: > > https://github.com/shiretu/crtmpserver Thanks for reporting! > What is the procedure for moving to a new upstream? Procedure is that the package maintainer (doublechecks your findings, and) change relevant URLs in debian/control and debian/copyright, and release a new package. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#744815: please compile against openssl
Quoting Jamie McClelland (2017-01-26 22:26:10) > I see that this is an old bug and would really like to see it > resolved. > > I have had mixed success getting apache2 or ngninx to proxy icecast2. > It makes trouble shooting a lot harder. > > And, without be able to access icecast2 over https, we get mixed > content warnings when displaying a stream on an https page. > > From my tests, it compiles fine on amd64/jessie - I just needed to > install the libssl-dev package before building. The problem here is that OpenSSL license is incompatible with GPL-2. license, and the latter is applied (without exception) to Icecast2. That means anyone may compile with OpenSSL for their own use, but it is. not permitted to redistribute linked binaries to others, so Debian. cannot legally distribute with OpenSSL. Other than the current approach of shipping without SSL support,. alternative options are to a) link with another TLS library providing an OpenSSL-compatible shim, b) patch the code to link against another TLS. library natively, or c) convince Icecast2 developers to relicense to a. license compatible with OpenSSL (the most minimal change being "GPL-2. with OpenSSL exception"). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: closed by Julien Cristau <jcris...@debian.org> (Re: Bug#852042: nmu: jackd2_1.9.10+20150825git1ed50c92~dfsg-4)
Quoting James Cowgill (2017-01-23 11:59:10) > Control: notfixed -1 1.9.10+20150825git1ed50c92~dfsg-4+b1 > > Hi, > > On 22/01/17 16:55, Francesco Poli wrote: > > Control: fixed -1 jackd2/1.9.10+20150825git1ed50c92~dfsg-4+b1 > > > > On Sun, 22 Jan 2017 16:27:03 + Debian Bug Tracking System wrote: > > > >> This is an automatic notification regarding your Bug report > >> which was filed against the jackd2 package: > >> > >> #848285: jackd2: spits verbose output and exits immediately when the > >> client stops sending audio > >> > >> It has been closed by Julien Cristau <jcris...@debian.org>. > > > > Many thanks to all people involved in fixing the bug in GCC and in > > fixing the resulting issue in Jackd! > > > > I am looking forward to seeing the binNMU migrate to Debian testing. > > > > In the meanwhile, apt-listbugs users risk seeing the package unpinned > > and upgraded to the buggy version currently in testing, just because > > this bug report has been closed with -done without version info. > > I know that 1.9.10+20150825git1ed50c92~dfsg-4+b1 is not a source > > version, but I guess that adding it as a fixed version should not harm > > the BTS version tracking and would probably make apt-listbugs understand > > that the bug was *not* closed as invalid, just fixed in a binNMU... > > I am adding such a fixed version, I hope nobody will get angry because > > of this. > > Unfortunately I don't think this is going to work. Now that there is a > "fixed" version, the BTS will only regard this bug as fixed in unstable > if it sees a source changelog containing that version. Since this will > never happen (it's a binNMU) the BTS will never regard this bug as fixed. > > Given that binNMUs have no testing migration delay, hopefully this won't > affect people for too long. I think the correct approach is to reassign the bug to gcc and mark it as affecting jackd - i.e. not try track which jackd package is fixed: Purpose of binNMUs is to operate independent of the package. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#851028: composite: FTBFS: lrdf.h:8:20: fatal error: raptor.h: No such file or directory
Quoting Jaromír Mikeš (2017-01-11 23:29:24) > 2017-01-11 19:55 GMT+01:00 Lucas Nussbaum <lu...@debian.org>: > > > > > During a rebuild of all packages in sid, your package failed to build on > > amd64. > > > > Relevant part (hopefully): > > >^~~ > > > In file included from /<>/composite-0.006. > > 2+dfsg0/src/Tritium/src/fx/Effects.cpp:36:0: > > > /usr/include/lrdf.h:8:20: fatal error: raptor.h: No such file or > > directory > > > #include > > > ^ > > > compilation terminated. > > > src/Tritium/CMakeFiles/Tritium.dir/build.make:1025: recipe for target > > 'src/Tritium/CMakeFiles/Tritium.dir/src/fx/Effects.o' failed > > > make[3]: *** [src/Tritium/CMakeFiles/Tritium.dir/src/fx/Effects.o] > > Error 1 > > > > The full build log is available from: > >http://aws-logs.debian.net/2017/01/11/composite_0.006.2+ > > dfsg0-6_unstable.log > > > > <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers> > > > > Hi Jonas, > > isn't it this bug rather bug in ldrf and the line in /usr/include/lrdf.h > file should be: > #include > as ldrf now B-D on libraptor2-dev? Well, that would be one way to solve it, but the more correct one, I believe, is for composite to use pkg-config. Something like this: pkg-config --cflags liblrdf should correctly provide this: -I/usr/include/raptor2 -I/usr/include Seems to me that composite build fails to properly set build flags, but happened to work anyway in the past because back then no custom path was needed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: liblrdf 0.5.0 in experimental
Hi Jaromir, Quoting Jaromír Mikeš (2017-01-06 22:06:49) > 2017-01-06 14:10 GMT+01:00 Jonas Smedegaard <d...@jones.dk>: > > I need your help: Please install liblrdf 0.5.0 from experimental, and > > test that the following packages continue to work: > > > > * ardour > > * composite > > * guitarix > > * rosegarden > > * sonic-visualiser > > * terminatorx > > I tested ardour composite and sonic-visualiser all looks good and > LADSPA plugins behave as expected > with liblrdf 0.5.0 from experimental installed. Thanks for testing! I will try upgrade to more recent snapshot to avoid OpenSSL licensing hell, and release that to unstable... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
liblrdf 0.5.0 in experimental
Hi all, I have just now released new upstream version 0.5.0 of liblrdf, but only to experimental for now - for two reasons: * Links against libssl * _ldrf_md5_* symbols are gone The libssl linking affects licensing, but I might be able to avoid it (by using a later git snapshot which addresses this upstream). The missing symbols start with _ so should ideally not be used anyhwhere - but I would really appreciate if the reverse depdencies could be tested that they properly work as-is (i.e. without recompilation). I need your help: Please install liblrdf 0.5.0 from experimental, and test that the following packages continue to work: * ardour * composite * guitarix * rosegarden * sonic-visualiser * terminatorx Thanks, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: abGate in Debian
Quoting Jaromír Mikeš (2017-01-06 12:25:21) > 2017-01-06 11:46 GMT+01:00 <anta...@hippie.lt>: >> On 2016-12-28 14:55, treb...@tuxfamily.org wrote: >>> The Debian multimedia team is currently thinking of removing abGate >>> from the repositories for the next Debian "stretch" since it's buggy >>> (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824353 ). I >>> just wanted to let aware of this in the hope it could be of a push >>> to you. Stretch is going to happen in a few months, so if you'd like >>> to tell that it's still in active development, please do. > >> This bug should be fixed now. New release is available on github: >> https://github.com/antanasbruzas/abGate/releases/ > > Thank you Anastas! Unfortunately at the moment debian is in "freeze" > state (from yesterday) > and new upstream releases are not accepted :( > Anyway immediately when debian will be released I will update abGate! I believe you are mistaken, Jaromir: According to https://release.debian.org/ we just entered "soft-freeze" where no _new_ packages are allowed, and on February 5th (minus 10 days to migrate!) is the full freeze. So assuming the new release of abGate do not require introduction of new binary packages, I believe there is still time to get this new upstream release included. Regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: Lilv release / stable freeze
Hi David (cc Debian multimedia team list), Quoting David Robillard (2017-01-04 18:14:47) > Just a heads up since the freeze is imminent, we discovered a somewhat > important bug in lilv yesterday, so I fixed that and kicked out a new > lilv release. If this could make it in before the freeze, that'd be > great (but it's not the end of the world if that's not possible). > > Sorry for the terrible timing :) No need for apologies: Assuming the new release does not require a SONAME bump, deadline before deep freeze is still more than a week away. Also, if you discover severe bugs (especially if affecting security) then such are permitted through also during freeze (and after final stable Debian release, even). Since I am not directly involved with maintaining lilv I will leave it to others to actually upgrade the Debian package. If noone picks this up within a few days, feel free to ping us again, and I will act on it! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: libopenmpt <-> libmodplug compataibility layer
Quoting James Cowgill (2017-01-01 16:57:17) > Are there any opinions about all this? My current thinking is that > option 2 is too invasive to be done for stretch (if we want to do it > at all), but option 1 might be possible (if it gets through NEW in > time). Deadline for getting through NEW in time for Stretch was January 4 minus 10 days to settle in unstable, so that ship has already sailed. I see no other option at this point in time than to try convince release managers to get an exception for this. But that requires heavy arguments e.g. tied to security concerns. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#821883: ImportError: When using gi.repository you must not import static modules like "gobject"
Excerpts from Benjamin Barenblat's message of December 17, 2016 2:43 pm: Package: morituri Version: 0.2.3-2 Followup-For: Bug #821883 I can reproduce this as well. Unlike Martin, I was able to get 0.2.3-1 from Jessie installed, and that version seems to work fine. You can only succeed installing morituri 0.2.3-1 if you also install GStreamer 0.10 libraries - which is the very reason for the crude patch introduced in 0.2.3-2. I see no sensible way forward with moritur, due to lack of activity upstream. Best I see is to abandon it and instead package the form of it called Whipper: https://github.com/JoeLametta/whipper - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgpGQPS51WHnj.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: Signing tags
Excerpts from Jaromír Mikeš's message of December 3, 2016 1:38 pm: Is signing tags mandatory? ... According to our wiki page it is, but I saw that some DD removing "sign-tags = True" from gbp.conf file. So I adopted this practice too. https://wiki.debian.org/DebianMultimedia/DevelopPackaging Tags should be created (and signed) by the uploading DD I believe we should always sign tags, and I do not recall anyone disagreeing with that. Where we do not all agree is on how to ensure that tags gets signed. Some is of the opinion that signing should not be enabled by default in packages, but instead be enabled in the build environment. Reason for that is, as I understand it, that it is difficult to disable pre-enabled signing for more complex setups (e.g. building on one host and signing on another). - Jonas ___ 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: libgig - update
Quoting Jaromír Mikeš (2016-11-16 14:54:16) > 2016-11-16 14:47 GMT+01:00 James Cowgill <jcowg...@debian.org>: > > On 16/11/16 13:38, Jaromír Mikeš wrote: > >> 2016-11-16 13:51 GMT+01:00 James Cowgill <jcowg...@debian.org>: > >>> On 16/11/16 08:31, Jaromír Mikeš wrote: > >>>> Hi, > >>>> > >>>> updating libgig is almost ready ... > >>>> There is one unusual issue ... debian dir contain Makefile.in > >>>> Makefile.am files. > >>>> They can't to be just removed as build depend on them. > >>>> They are shipped by upstream's debian dir. > >>>> What about this issue? > >>> > >>> Can you patch the toplevel Makefile.am to not look in debian/ (remove > >>> debian from SUBDIRS)? Hopefully the build will still work. > >> > >> Bingo ... configere.ac file also had to be patched ;) > >> > >> Dependants of libgig are: > >> qsampler version in unstable should build with libgig 4.0.0 > >> gigedit which needs to be updated to version 1.0.0 - I am considering > >> to became uploader of it > >> > >> Is there still chance to get it uploaded if there is transition freeze? > > > > You would have to ask the release team, but I don't think it's likely > > you'd get a freeze exception. Everything can be uploaded to experimental > > in the meantime though. > > ok ... let's go experimental > I have done repacking anyway ;) What is now frozen is major transitions - and a library with 2 reverse dependencies certainly does not sound like a major transistion to me. I recommend to ask release team - not give up without trying! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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: [SCM] hydrogen/master: Exclude .gitignore file from upstream tarball.
Quoting IOhannes m zmölnig (Debian/GNU) (2016-11-10 19:00:40) > On 2016-11-10 18:54, Mattia Rizzolo wrote: >>> Hmm ... What do you suggest? >>>> Just exclude gitignore file without adding repack suffix to upstream >>>> tarball? >> I suggest you don't repackage. >> Rather have upstream not include that file in their tarball, > > this is certainly best. > until then, i don't see any harm in excluding all ".git*" files without > adding a repack suffix (as recently discussed with the xwax package) Not sure what was discussed with xwax package (didn't follow that) but there should be no need to repackage source tarball. Instead, suppress the file in git-buildpackage. Reason for that is that a) non-git-managed builds (e.g. official builds on build daemons) are not affected by git hints, but b) our git-managed builds get confused by upstream-infused git hints but we can suppress that locally in our git management tools. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ 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#842840: libavfilter-extra6: should provide libavfilter6
Package: libavfilter-extra6 Severity: important libavfilter-extra6 is a superset of libavfilter6, and should therefore declare that it "Provides: libavfilter6" to not effectively conflict with all consumers of libavfilter6. - Jonas ___ 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#841525: vlc-plugin-skins2: arch-dependent file in "Multi-Arch: same" package
Quoting Sebastian Ramacher (2016-10-21 13:25:45) > On 2016-10-21 13:16:10, Jonas Smedegaard wrote: > > Quoting Jakub Wilk (2016-10-21 12:52:57) > > > Package: vlc-plugin-skins2 > > > Version: 2.2.4-7 > > > Severity: important > > > User: multiarch-de...@lists.alioth.debian.org > > > Usertags: multiarch > > > > > > vlc-plugin-skins2 is marked as "Multi-Arch: same", but the following file > > > is > > > architecture-dependent: > > > > > > /usr/share/vlc/skins2/default.vlt > > > > > > An example diff between i386 and amd64 (generated by diffoscope) is > > > attached. > > > > The diff seems to reveal the package was not built in a pristine chroot! > > No, it doesn't. It just reveals that it was a upload including > binaries since it had to go through NEW. > > The offending code is in share/Makefile.am which creates default.vlt. Right. Bug is not that content varies (it was created in a shared makefile, and diff attached to original bugreport also shows identical _content_). Bug is also not that it was built in a non-pristine environment - but it is a _hint_ about the underlying bug that the user "sebastian" is the owner and group for the files in the diff. It is a real¹ bug that a non-bunNMU package inherits access rights from the user account where it is built! It seems that every time you build the package as a non-binNMU it has a security hole in that a user named "sebastian" in any target system gets write access to some files intended to be writable only by root! Likely the fix is to change debian/rules and/or patch upstream install routines to use "install" with appropriate arguments, instead of "cp". - Jonas ¹ I suspect that your including the word "just" means that you do not consider this a serious bug. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#841525: vlc-plugin-skins2: arch-dependent file in "Multi-Arch: same" package
Quoting Jakub Wilk (2016-10-21 12:52:57) > Package: vlc-plugin-skins2 > Version: 2.2.4-7 > Severity: important > User: multiarch-de...@lists.alioth.debian.org > Usertags: multiarch > > vlc-plugin-skins2 is marked as "Multi-Arch: same", but the following file is > architecture-dependent: > > /usr/share/vlc/skins2/default.vlt > > An example diff between i386 and amd64 (generated by diffoscope) is attached. The diff seems to reveal the package was not built in a pristine chroot! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#839941: whishlist ffmpeg
Hi Marc, Quoting Struminski, Marc (2016-10-18 14:47:52) > I thought, that you can use it free in ffmpeg, becuse the header files > of SDK says: The software is Provided "AS IS³Š. I believe that expression most likely is intended not to grant you any freedoms, but instead to mean "don't try sue us for implicitly promising you that it would work for a certain use-case, and you lost millions in investment in a now sunken business adventure" - i.e. what we in geek community call "if it breaks, you get to keep both pieces". Copyright laws in most jurisdictions obey the Berne convention, which requires freedoms to be explicitly stated (and that the classic phrase "all rights reserved" is obsolete). Stating that it is provided "as is" does not rxpand to the range of freedoms defined as the Debian Free Software Guidelines (later adopted as the definition for the Open Source movement). NB! I am not a lawyer. My guess above is based on analyzing semantics of a multitude of MIT-like licenses, and then comparing what seems like evolutionary trends in choice of words for various parts. Further questions about whether some code is DFSG-free or not is best addressed to debian-le...@lists.debian.org. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] drumkv1/master: Split package (4)
Quoting IOhannes m zmölnig (Debian/GNU) (2016-09-27 09:33:13)
> On 2016-09-26 22:55, James Cowgill wrote:
> > Hi,
> >> Depends:
> >> ${misc:Depends},
> >> - ${shlibs:Depends}
> >> + ${shlibs:Depends},
> >> + drumkv1-common (>= ${source:Version}), drumkv1-common (<<
> >> ${source:Upstream-Version}+1~),
> >
> > What is the benefit of doing this over 'drumkv1-common (=
> > ${binary:Version})?
>
> it's the usual pattern to cater for binNMUs.
I believe it is the _old_ pattern. And I believe that is the reason for
the question (you didn't answer the comparative part of the question).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: 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: Joining pkg-multimedia team
Quoting Andreas Boll (2016-09-16 16:58:28) > my name is Andreas Boll, I'm a Debian Maintainer and I'd like to > officially become part of the Debian Multimedia Team. > I'm also a member of the Debian X Strike Force where I co-maintain > Mesa and related packages. > > I'm currently working on a backport of a newer version of Mesa and had > to backport some additional packages. One of these packages is > vdpau-video. So I'm maintaining the backport of vdpau-video for > jessie-backports since yesterday (Thanks mapreri for sponsoring!). > > I already have an alioth account and joined the pkg-multimedia group. > I'm subscribed to pkg-multimedia-maintainers and > pkg-multimedia-commits mailing lists. > I'm familiar with handling bugs in Debian and I agree to review other > work to my best knowledge. Welcome aboard, Andreas! Sounds like you are well settled already, but if in doubt, just shout! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: Bug#825186: Please which tasks should be installed at a default installation of the blend
beets | forked-daapd (MPD protocol) * mpdris2 (MPRIS2 protocol) * mpd-sima (MPD auto-dj feature) * mpdscribble | mpdcron (MPD publish feature) The heavier (-gnome and -kde) multimedia-consume-* packages above include and favor lighter tools - i.e. for each group...: a) If no UI-optimized tools exist then the group of the underlying toolkit (-gtk or -qt) is used in full. b) If UI-optimized tools exist but only ones bound to heavier frameworks (vlc or gstreamer) then one non-UI-optimized tool is included and favored. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#836878: amSynth : package improvement
Hi Olivier, Quoting treb...@tuxfamily.org (2016-09-06 20:39:59) > I made a proper man page, starting from the information given by the > "amsynth -h" output. I made a French translation of it as well. Please > find these attached to this email. > > I'd like to enjoy this email to talk about the debian/README.debian > file. Is it still actual ? Should it be kept or dropped ? Thanks for your contribution! NB: I am not the package maintainer - just throwing ideas here...: Hand-written man pages has a high risk of getting out of sync. I can suggest to look at help2man, for automated man page generation. Then there is the translation. Ideally upstream would a) adopt your translation, and b) support localized --help output, and c) we could then extend our help2man routine to also convert translations. Until all that is in place, a way for the packaging to ensure not shipping out-of-sync man pages (translated or not) would be to capture --help output at build time, compute a checksum, and if checksum fails then fail the build with a message explaining to double-check man pages and if ok update checksum. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: .gitignore (was Re: Help offered with xwax package)
Quoting Jaromír Mikeš (2016-08-12 16:29:03) > "Files-Excluded stanza in d/copyright *without* warranting a "~repack" > suffix" seam to be easiest and totally acceptable for me. Purpose of Files-Excluded in debian/copyright is to indicate files that has been removed in our redistribution by repacking upstream source. Therefore I do not follow what you mean by emphasizing not repacking. What would be the point of telling something has been removed without then actually removing? > Of course if git-import-orig would ignore upstream .gitignore file it > would be even better. This content in debian/gbp.conf ignores all .git files anywhere: [DEFAULT] filter = */.git* - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: .gitignore (was Re: Help offered with xwax package)
Quoting IOhannes m zmölnig (Debian/GNU) (2016-08-11 10:43:55) > On 2016-08-10 11:52, James Cowgill wrote: > >> Actually we should repack ( to get rid of upstream .gitignore file and > >> > use our .gitignore file ) and rename. > > You don't actually need to do that (and arguably you should not repack > > orig tarballs unless you need to). For source format "3.0 (quilt)", > > dpkg-source contains a set of regexes for files which are automatically > > ignored when generating the final source package. .gitignore (and .git/) > > are on the list so any changes you make to upstream's .gitignore are > > completely ignored by dpkg-source. > > i was wanting to ask about best practices regarding .gitignore for some > time. > > when packaging, i have two "problems" with .gitignore > > #1 upstream includes a .gitignore > having an upstream .gitignore field usually just creates trouble as it > (mostly) hides stray artefacts lying around until dpkg-source comes and > complains. i really think that gitignore's main purpose is exactly this > hiding of build artefacts, but it mainly causes trouble when it comes to > Debian's build chain. > with my Debian hat on, i would like to get rid of all upstream > .gitignore files, ideally *automatically* (to catch all those gitignores > in subdirectories...) > with my upstream hat on, i desparately need .gitignore though... > > a "solution" which i often find applied (by myself, and others like > mira) is to just strip away the .gitignore file, when repacking the > sources (though afaik this is only done when the sources are repackaged > anyhow) Here's my understanding: .git* files are not really project data but packaging data. When repackaging we should always throw away old packaging (meta)data, and may add new packaging (meta)data. * If upstream includes debian/* files, throw it away. * If upstream includes .git* or .svn* or .cvs* files, throw it away. * For a git containment, add .git* files as needed. * For a .deb package, add debian/* files as needed. If lazy then you can skip cleanup of old containment files when not in the way of your own new containment, but lintian will rightfully warn if you ship a package with VCS files, because ideally you should care not only about your own needs but also downstream needs. > #2 ignoring Debian toolchain artefacts > most packages use "3.0 quilt", which I (unlike many others) have no > problems with. > unfortunately, using quilt results in a .pc/ directory in the project > root, something that gbp will loudly complain about. > > the most common "solution" is to add .pc/ to .gitignore That's no different from any other containment, I believe. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] csound-manual/master: Switch from CDBS to dh sequencer
Quoting Felipe Sateler (2016-07-17 17:55:32) > On 17 July 2016 at 05:42, Jonas Smedegaard <d...@jones.dk> wrote: > > Quoting Felipe Sateler (2016-07-16 23:54:43) > >> On 16 July 2016 at 17:52, <fsate...@users.alioth.debian.org> wrote: > >>> Switch from CDBS to dh sequencer > >> > >> Jonas, I think you only work with packages using CDBS. Is this still > >> the case? If so, would you like me to drop you from Uploaders here? > > > > Please drop me as uploader. Not due to change in packaging style (I am > > - very slowly - moving to short-form dh myself), but because honestly my > > interest in csound for quite some time is that it exists for use by > > Sugar - and you are doing a great job at that without my help. > > OK, so I will drop you from the main csound package as well. > > > > > Same goes for other packages I am involved with: If others would like to > > help maintain some but feel too intimidated by CDBS, please nudge me and > > I will likely - on a case by case basis - either agree to change > > packaging style or hand it over. > > So I take the opportunity to ask here. I was thinking about switching > over liblo as well. What do you think? Please drop me as uploader there too: Same reason as for CSound. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: musescore 2.0.3+dfsg-1
[Re-posting cc Peter, who seem to not be subscribed] Quoting Peter Jonas (2016-07-14 18:18:56) > As Tiago said the policy is a guideline, Agreed. But a strong recommendation: For starters, each inclusion of an embedded code copy is burden on the security team! > but I don't believe it applies here anyway. The policy defines > convenience copies as dependencies included "so that users compiling > from source don't have to download multiple packages". It goes on to > say that the policy does not apply when "the included package is > explicitly intended to be used in this way." > > Freetype is included because not included for convenience. It is > included because MuseScore's code has been tailored towards a specific > version of Freetype and other versions of Freetype have been known to > cause problems in the past. I believe it does apply here: What Policy mentions as reason for not avoiding embedded code copies is if the _library_ is intended to be used that way - not if the consuming project intended to do so (arguably it is always intentional). Freetype has had quite a few bugs in the past, but fixating to a "known working release" is *not* the solution, as that only hides the problems - something we explicitly promise not to do in Debian. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: musescore 2.0.3+dfsg-1
[replying only to list, as per mailingst policy] Quoting Peter Jonas (2016-07-14 18:18:56) > As Tiago said the policy is a guideline, Agreed. But a strong recommendation: For starters, each inclusion of an embedded code copy is burden on the security team! > but I don't believe it applies here anyway. The policy defines > convenience copies as dependencies included "so that users compiling > from source don't have to download multiple packages". It goes on to > say that the policy does not apply when "the included package is > explicitly intended to be used in this way." > > Freetype is included because not included for convenience. It is > included because MuseScore's code has been tailored towards a specific > version of Freetype and other versions of Freetype have been known to > cause problems in the past. I believe it does apply here: What Policy mentions as reason for not avoiding embedded code copies is if the _library_ is intended to be used that way - not if the consuming project intended to do so (arguably it is always intentional). Freetype has had quite a few bugs in the past, but fixating to a "known working release" is *not* the solution, as that only hides the problems - something we explicitly promise not to do in Debian. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer
Quoting Chris Lamb (2016-06-29 23:07:32) > > [...] Sorry, not apt-file but apt-cache. What d-shlibs rely on is an > > up-to-date APT cache > > Ahhh, this was what I needed - for some reason I didn't have > pkgcache.bin & srcpkgcache.bin, so the whole d-shlibs machinery was > refusing to work. > > Closing bug in BCC and apologies for the noise... No need for apologies: Your tests are greatly appreciated, and it is no surprise you run into odd cornercases when doing so many of them. ...and it also helps if I knew how the code works that I maintain, to not confuse the conversation when attempting to enlighten :-P - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer
Quoting Chris Lamb (2016-06-29 18:24:13) >> this failure is most likely because your build environment is buggy > > It's always a fresh, clean container image that I recreate entirely > (not dist-upgrade) at 07:00 UTC on my laptop from the latest sid. I > run build-dep and then build with debuild; nothing special. I believe that you do not expect your environment to be _too_ special, but highly suspect that you have applied some optimizations over, say, running debian-installer from bare metal for each and every build. Can you try add an "apt update" in the build environment before building the package, and see if it still fails? > Other systems -- including the reproducible builds servers -- can > reproduce the FTBFS, so I am not convinced at this point that my > environment is buggy. Where do you see that? The log currently linked from tracker.debian.org was another issue (since fixed in CDBS). >> apt-file initializes its database when installed, and d-shlibs rely >> on that. > > Ah, smells like the bug is there - d-shlibs does not depend on apt-file [...] Sorry, not apt-file but apt-cache. What d-shlibs rely on is an up-to-date APT cache (it calls "apt-cache --no-generate due to bug#630591 - which seems a no-op since ages but shouldn't fail either). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer
Hi Chris, Quoting Chris Lamb (2016-06-29 16:28:30) > liblrdf fails to build from source in unstable/amd64: [...] > d-shlibmove --commit \ > --movedev "debian/tmp/usr/include/*" usr/include/ \ > --movedev "debian/tmp/usr/lib/pkgconfig/*.pc" usr/lib/pkgconfig/ \ > --moveshl debian/tmp/usr/share/ladspa/rdf/ladspa.rdfs > usr/share/ladspa/rdf/ \ > debian/tmp/usr/lib/liblrdf.so > Library package automatic movement utility > devlibs error: There is no package matching [libraptor1-dev] and noone > provides it, please report bug to d-shlibs maintainer > debian/rules:65: recipe for target 'binary-post-install/liblrdf0' failed > make: *** [binary-post-install/liblrdf0] Error 1 Like a previous report from you this failure is most likely because your build environment is buggy: apt-file initializes its database when installed, and d-shlibs rely on that. One way that can happen is if your environment blocks network access not only during build but also during installation of build-dependencies. Another idea is a race condition: Cache filling being slower than running the build. In short: Please check that your environment has a working apt-file, and _after_ that is examined test if the build still fails. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#828056: mpv: problems with osd if costom fonts are installed
Hi treaki, Thanks for the bugreport! Quoting treaki (2016-06-24 13:59:58) > Dear Maintainer, Please note that I am not the package maintainer, just following along and here have a few comments. > after some days at just accepting this bad failaur i [...] i found > that i had installed properitoyr ms fonts to ~/.fonts. > for now i dont need theese fonts but the problem should still be > fixed. I agree that ideally Mpv (or libfreetype, probably) should gracefully handle fonts that it cannot render properly. > the problem is present at the new mouse osd but also at the old one > (like if you press key i or change volume). somehow only the not > capital letter a is shown. My guess is that the font is broken in some subtle way so that it renders fine in some applications (otherwise you would probably have noticed the issue earlier) but for some reason not here. > reportbug saied the attachement of the compressed font tar.xz is to > big to send, please tell me if you still need it where to upload. It is probably best to *not* distribute those fonts to the mailinglist, as you might then violate the licensing terms you were granted for use of those fonts. If you don't mind, then email the fonts to me privately, and I will try examine if/how those fonts are technically broken (and will then delete the fonts again). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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
Co-maintainer needed for AtomicParsley
Hi, I have moved AtomicParsley from collab-maint to multimedia team. Anyone willing to co-maintain it with me? It uses a (quite simple) CDBS setup, and should be quite low maintenance. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: Installing BS1770Gain
Quoting Mustafa EL-HILO (2016-06-08 18:32:20) > I can't seem to find documentation on how to install BS1770Gain with > ffmpeg. I have built my own ffmpeg on Ubuntu Server 16, and BS1770Gain > can't seem to find ffmpeg even if I point ./configure --ffmpeg path to > it. > > Any links or documentation is helpful as I can't seem to find any... That sounds like a question better asked upstream to ffmpeg developers. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#824211: swh-plugins: Package new upstream version
Quoting Jaromír Mikeš (2016-05-19 15:45:28) > 2016-05-13 20:40 GMT+02:00 Javier Serrano Polo <jav...@jasp.net>: > > Package: swh-plugins > > Version: 0.4.15+1-8 > > Severity: wishlist > > > > The upstream project is maintained at https://github.com/swh/ladspa . It > > includes a vocoder plug-in that is shipped with the lmms package. To > > reuse this plug-in, lmms could put it under /usr/lib/ladspa, but that > > would conflict with a new version of swh-plugins. Could you tell if you > > will package a new upstream version, which is preferable, or if lmms can > > publish this plug-in in the meantime? > > I don't see any release here yet :( > https://github.com/swh/ladspa/releases Then perhaps consider release a snapshot of upstream development - to me that feels more sensible (without having looked closer at the code) than us indirectly doing the same via a snapshot created by another upstream (the lmms project). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: Joining pkg-multimedia team
Quoting Lucio Carreras (2016-05-16 16:38:49) > But I don't find a tutorial that mentions how to upload the public key > for the git repository. > https://wiki.debian.org/Alioth/Git only tells that I should use ssh but > I get a public key error. https://wiki.debian.org/Alioth/SSH Welcome aboard! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#823561: zynaddsubfx: License should be GPL-2+
Quoting Javier Serrano Polo (2016-05-06 01:15:11) > According to > https://github.com/LMMS/lmms/issues/2752#issuecomment-217043740 , it > looks like the license should be GPL-2+ despite what individual files > say. I am not a lawyer. That conversation lack any proof of copyright and/or licensing having changed from what is explicitly stated in headers of sourcecode. Only the copyright holder can relicense beyond the scope of a previous license, so stating that the project as a whole is licensed GPL-3+ when some parts of the project is GPL-2 is not possible without the consent of copyright holders. I have posted a comment to the referenced upstream bugreport, to try steer the discussion away from "Debian view on things" an instead look at actual statements in code. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: guitarix_0.34.0-2_amd64.changes REJECTED
Quoting Thorsten Alteholz (2016-04-12 22:04:19) > On Tue, 12 Apr 2016, Jonas Smedegaard wrote: > > Victor asked if there was anything _conclusive_. > > The summary of Evan Prodromou is rather conclusive and finds violations > of DFSG 3 (4a), DFSG 1 (4b) and DFSG 9. Thanks for clarifying your thoughts. It was not clear that you implied "...and if you follow the links then you will find someone that feels it is conclusive even though the place I am pointing to explicitly states that it is not." - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: guitarix_0.34.0-2_amd64.changes REJECTED
Quoting Thorsten Alteholz (2016-04-12 20:02:19) > On Mon, 11 Apr 2016, Víctor Cuadrado Juan wrote: > > I have searched the wiki pages [1][2] and debian-legal m-l [3], and I > > haven't found anything conclusive on CC-By-2.0. > > please have a look at > > https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_License_.28CC-by.29.2C_v1.0 That place seems explicitly _inclonclusive_ about v2.0 of the license. Victor asked if there was anything _conclusive_. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#819310: vlc: rtmp:// URLs for live streaming do not work
Quoting Ralf Jung (2016-03-26 14:06:13) > The reason it does not work on Debian is that ffmpeg is compiled with > "--enable-librtmp". More accurately, the reason is all of the following combined: * librtmp assumes non-"live" (i.e. seek'able?) sources by default * ffmpeg does not force "live" mode by default when using librtmp * ffmpeg favors librtmp over builtin rtmp when both are built * Debian builds ffmpeg with librtmp enabled * VLC does not not force "live" mode to ffmpeg by default * VLC does not specifically request builtin rtmp from ffmpeg I believe changing any one of those places should be enough, from a user POV. I suspect that librtmp quite likely support features which builtin ffmpeg implementation does not (e.g. better certificate handling in its TLS extensions), and that disabling librtmp in Debian ffmpeg builds therefore is a bad place to fix this. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#819266: ffmpeg: rtmp is broken
Quoting Ralf Jung (2016-03-26 13:43:16) > You do not agree that URLs that work on Windows, Mac, SuSE, and Arch, > should also work on Debian...? I believe this bugreport is the wrong place to discuss that topic. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#819266: ffmpeg: rtmp is broken
Quoting Ralf Jung (2016-03-26 12:13:15) > [...] considering that librtmp upstream seems rather dead (last > release was in 2012). Just for the record (unrelated to both this closed issue and a potential UI issue for VLC): librtmp may not release very frequently, but has made commits to its source as late as december 2015 (which is included in the Debian package. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#819266: ffmpeg: rtmp is broken
Quoting Ralf Jung (2016-03-26 12:13:15) > >> However, the RTMP stream that I am testing this on is the live stream of > >> an event that will end Monday at noon ;-) > > > > This fails similar to your experience: > > > > rtmpdump -r rtmp://revision.scenesat.com/live/mainhall > > > > This works: > > > > rtmpdump --live -r rtmp://revision.scenesat.com/live/mainhall > > > > So it seems you need to force live (i.e. disable seek). This works: > > > > mpv "rtmp://revision.scenesat.com/live/mainhall live=1" > > > > That arguably weird syntax is documented here: > > https://ffmpeg.org/ffmpeg-protocols.html#librtmp-rtmp_002c-rtmpe_002c-rtmps_002c-rtmpt_002c-rtmpte > > Cool! I did read about this syntax but when I tried it, it didn't work. > And I *do* still get the following when I try it now > > $ mpv "rtmp://revision.scenesat.com/live/mainhall live=1" > Playing: rtmp://revision.scenesat.com/live/mainhall live=1 > [ffmpeg] HandShake: client signature does not match! > [ffmpeg] rtmp server sent error > > but then, it works. So when I tried this yesterday, it was probably due > to problems on the server side. Right - I also wrongly chased the handshake message, until realising it is only a warning: https://github.com/DDVTECH/mistserver/issues/2 > I would still argue that there is a bug somewhere, e.g. clicking the > rtmp://... link opens VLC and then fails, because nothing is adding that > "live=1". This is pretty much undiscoverable, the end result for most > Debian users will be "rtmp does not work". But I don't know whether the > place to fix this is is VLC or ffmpeg or librtmp... not sure where to > best report it; considering that librtmp upstream seems rather dead > (last release was in 2012). If VLC fails to properly handle the odd URI+space+options ffmpeg syntax, then that is a bug in VLC. Please check if that is the case, or (now that you know what to look for) it perhaps is instead an issue of you needing to feed the "live" option in a different way than you have tried already. If VLC ignores the live option or has no way of being told the live option, then please open a new bug against vlc, pointing to this one for background info. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#819266: ffmpeg: rtmp is broken
Quoting Ralf Jung (2016-03-26 09:26:05) > Hi, > > > Quoting Ralf Jung (2016-03-25 19:19:35) > >> something about rtmp is broken in ffmpeg as shipped in Debian. > >> For example, the Revision RTMP streams > >> <https://2016.revision-party.net/live> do not work in either MPV or VLC. > >> However, after building mpv and ffmpeg using mpv-build > >> <https://github.com/mpv-player/mpv-build>, the streams > >> *do* work -- and since MPV and VLC shows the same error, I suspect ffmpeg > >> is the culprit here. > > > > Seems to be even lower level than ffmpeg, and already reported: > > https://bugs.debian.org/654665 > > mpv-build does not seem to build its own version of librtmp. Instead, as > far as I can tell, it builds ffmpeg without librtmp -- judging from the > object files I see: > > > ./ffmpeg_build/libavformat/rtmpproto.o > > ./ffmpeg_build/libavformat/rtmphttp.o > > ./ffmpeg_build/libavformat/rtmppkt.o > > I don't even have librtmp-dev installed, so it could hardly link against > that library. > > So I don't think this is fixed because of any changes librtmp could > make. It rather seems to be fixed by entirely avoiding librtmp. Interesting. ffmpeg contains a fork of librtmp which seems to be used if not linking against the system shared copy. Debian favors shared code. I believe best would be to try figure out what change in the ffmpeg fork of librtmp makes it work better (or at all?) compared to the canonical project - and port those changes over if possible (and permitted - if ffmpeg changes are incompatibly licensed). That would also benefit other projects using librtmp, e.g. libcURL, lightspark and livestreamer. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#819266: ffmpeg: rtmp is broken
Quoting Carl Eugen Hoyos (2016-03-25 21:37:58) > On Friday 25 March 2016 07:19:35 pm you wrote: > > Package: ffmpeg > > Version: 7:2.8.6-1+b2 > > Severity: normal > > > something about rtmp is broken in ffmpeg as shipped in Debian. > > For example, the Revision RTMP streams > > <https://2016.revision-party.net/live> do not work in either MPV or VLC. > > However, after building mpv and ffmpeg using mpv-build > > <https://github.com/mpv-player/mpv-build>, the streams *do* work -- and > > since MPV and VLC shows the same error, I suspect ffmpeg is the culprit > > here. > > Sorry to say but this does not seem like a useful bug report: Did you test > at all with FFmpeg? > > > $ mpv 'rtmp://revision.scenesat.com/live/mainhall' > > This url works fine here both with current FFmpeg and FFmpeg 2.8 > > Carl Eugen > > $ ffmpeg -i rtmp://revision.scenesat.com/live/mainhall -qscale 2 out.avi > ffmpeg version N-79134-g4d25172 Copyright (c) 2000-2016 the FFmpeg developers > built with gcc 4.7 (SUSE Linux) Please elaborate what "here" is - it seems above is SUSE, not Debian. Same command fails for me, on Debian unstable, AMD64: jonas@auryn:~$ ffmpeg -i rtmp://revision.scenesat.com/live/mainhall -qscale 2 out.avi ffmpeg version 2.8.6-1+b2 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 5.3.1 (Debian 5.3.1-11) 20160307 configuration: --prefix=/usr --extra-version=1+b2 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv WARNING: library configuration mismatch avcodec configuration: --prefix=/usr --extra-version=1+b2 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv --enable-version3 --disable-doc --disable-programs --disable-avdevice --disable-avfilter --disable-avformat --disable-avresample --disable-postproc --disable-swscale --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libvo_aacenc --enable-libvo_amrwbenc libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat56. 40.101 / 56. 40.101 libavdevice56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc53. 3.100 / 53. 3.100 HandShake: client signature does not match! Closing connection: NetStream.Play.StreamNotFound rtmp://revision.scenesat.com/live/mainhall: Unknown error occurred -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: Mudita24 ready for uploading/re-adopting
Quoting IOhannes m zmölnig (Debian/GNU) (2016-03-21 23:01:24) > and of course the standards-version should be updated to the newest > one. ...if and only if you a) actually read the newest revision of Debian Policy, and b) believe the package to obey the rules of that revision! If you are uncertain, then DO NOT change standards-version. It is far better that the version is old (and lintian warns the World about that fact), than being untruthful about it. Standards-version is NOT an indicator that you have chased and silences lintian "noise", but instead that the package is verified to follow a certain revision of Policy. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#810186: kodi: diff for NMU version 15.2+dfsg1-1.1
Quoting Balint Reczey (2016-01-22 22:29:30) > On Fri, 22 Jan 2016 10:21:59 + (UTC) Gianfranco Costamagna > <costamagnagianfra...@yahoo.it> wrote: > ... >> - libpng12-dev | libpng-dev, >> + libpng-dev | libpng12-dev, > I have already prepared the fix in git and I'm waiting for libpng-dev > to become a non-virtual package. > > From Debian Policy 7.5 Virtual packages - Provides: > To specify which of a set of real packages should be the default to > satisfy a particular dependency on a virtual package, list the real > package as an alternative before the virtual one. That section of policy talks about _dependencies_ whereas the change done above is a _build-dependency_. It is a common pattern in Debian to provide a virtual library development package. Purpose of the section above is to ensure deterministic install (non-random install) but that is ensured by the maintainer of the library package only having a single package available in any suite at a time providing the virtual package. Regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#785867: fixed in morituri 0.2.3-2
Quoting Moritz Mühlenhoff (2016-01-07 22:16:33) > On Sun, Nov 29, 2015 at 06:04:42PM +0000, Jonas Smedegaard wrote: > > Format: 1.8 > > Date: Sun, 29 Nov 2015 18:04:59 +0100 > > Source: morituri > > Binary: morituri > > Architecture: source all > > Version: 0.2.3-2 > > Distribution: experimental > > Urgency: medium > > Maintainer: Debian Multimedia Maintainers > > <pkg-multimedia-maintainers@lists.alioth.debian.org> > > Changed-By: Jonas Smedegaard <d...@jones.dk> > > Description: > > morituri - CD ripper aiming for maximum quality > > Closes: 774667 785867 > > Changes: > > morituri (0.2.3-2) experimental; urgency=medium > > Could you upload that to unstable now? Sorry, no: That packaging release is indeed experimental. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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: [SCM] giada/master: Added debian/git-tuneclone.sh script
Quoting IOhannes m zmölnig (Debian/GNU) (2015-11-10 11:55:51) > On 2015-11-09 21:21, Jaromír Mikeš wrote: >> happy to see you working on this package ;) >> Can you explain me please how to use this script in packaging ? > > > just run it once after you've checked out the repo. [details snipped] Please document that in debian/README.source. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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
[no subject]
Hi Ramakrishnan, Welcome onboard the multimedia team! If you haven't already, please familiarize yourself with your wiki pages at https://wiki.debian.org/DebianMultimedia and below, and subscribe to our mailinglist at http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers Regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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
