Re: [SCM] x42-plugins/master: Exclude mipsel from build.
On 06/18/2015 02:50 AM, Jaromír Mikeš wrote: > 2015-06-09 18:20 GMT+02:00 Jaromír Mikeš : >> 2015-06-09 15:01 GMT+02:00 Felipe Sateler : >> >>> Note that you still need to ask for removal on mipsel of the package. >>> I would instead just ask for removal, and let x42 build again when the >>> issue is sorted out. >> >> I asked removal mipsel build >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788231 >> Is it fine just like this or other step is needed? > > x42-plugins didn't entered "testing" what to do now? just wait? #788231 has not been closed yet, so x42-plugins is still listed as supporting mipsel. you also might want to give some more detailed reasoning in the bug-report, as to why you would like to have mipsel builds removed. (if stating "FTBFS" were enough, we could just do automatic removal of archs that fail to bulid, no?) gfmsard IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: Introducing myself - Joël Krähemann
On 06/12/2015 03:27 PM, Joël Krähemann wrote: > > I've already done my first package for sure it needs to improved but this > is it basically: > > http://gsequencer.org/packages/ags_0.4.2-1_amd64.deb > running "lintian" on that packages gives 2 errors and 8 warnings, all of which should be fixed. apart from that: - did you file an ITP (intend-to-package) bug against wnpp, that you want to package ags? related to that: any "(Closes: #XXX)" stanza in debian/changelog should only ever refer to debian bug numbers. while #5 might be alive, it is definitely not the ITP bug number of ags. - debian/copyright only covers the packaging code, not ags itself. - do you have a repository for packaging? does it follow our guidelines [1]? i cannot say much more, without access to the packaging itself. gfmdsr IOhannes [1] https://wiki.debian.org/DebianMultimedia/DevelopPackaging signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
multimedia-blends: policy question(s)
hi, esp ross, i was having a look at the multimedia-blends package, and would like to change the categorization of a few package i (co)maintain. should i just go ahead and commit them, or does this require some discussion? furthermore, i noticed that the various tasks mainly use the *Depends* relationship. now i'm not an expert with blends, but personally i think that 'Depends' should be avoided as much as possible (in general). this is even more important, as i think that most tasks in the multimedia blend are rather aggregative (or whatever the word): chances are high that a person that selects a given task will never ever need *most* of the packages in the task. in general i think there are too many packages in the various tasks (e.g. it might make sense to factor out the entire pd-clan from "soundsynthesis", as most of those packages don't deal with sound synthesis at all; darn - did i just here me volunteer to maintain a "puredata" task?) anyhow: if i want to some record some audio, i would select the "recording" task, which will installs by (among other things): at least (at a first glance) 4 multitrack recorders (3 of them via Depends) - ardour - ardour3 - qtractor - ecasound (though for whatever reasons audicity is missing) and a few tools which i fail to see why they are in "recording" at all (only listing a few select Depends-packages): - jackd - qjackctl - ffmulticonverter if the blend is to give an overview of what is available (so the user can try a few, and then pick their favourite tool), wouldn't it make more sense to "Recommend" most packages, so that they can easily get rid of the tools they dislike (without having to uninstall the entire task, which potentially removes all the (other) automatically-installed dependencies) if most of the above can be explained away by my total ignorance of blends, please excuse (and enlighten) me. gfmsard IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Fwd: Bug#786422: ITP: pd-iemtab -- Pd-objects for table manipulation
anyone interested in becoming an uploader for that one? packaging uses CDBS. i expect upstream to not release very often. fmgadsr IOhannes Forwarded Message Package: wnpp Severity: wishlist Owner: IOhannes m zmoelnig * Package name: pd-iemtab Version : 1.20 Upstream Author : Thomas Musil * URL : http://puredata.info * License : GPL Programming Lang: C Description : Pd-objects for table manipulation This is a collection of high-performance objects to manipulate tables/arrays from within Pd. . It supports: - setting of constant values - copy and reverse arrays - find minimum and maximum values - basic binops: compare, add, subtract multiplication, division - unops: square root, power-to-db, db-to-rms - complex math - FFT, inverse FFT, convolution, cross-correlation I intend to do the packaging under the pkg-multimedia-maintainers team umbrella (if I can interest my team fellows, otherwise I will package it on my own). signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Fwd: RM: flumotion -- ROM; unmaintained upstream; depends on obsolete gstreamer0.10
just to let you know that i requested a package removal for 'flumotion'. gfmsadr IOhannes Forwarded Message Package: ftp.debian.org Severity: normal flumotion uses gstreamer0.10 which is to be removed from Debian. I contacted upstream about their plans to support gstreamer1.0, but they were not interested in it. Furthermore, flumotion depends on gstreamer0.10-ffmpeg, which is not available in Debian either due to libav/ffmpeg incompatibilities. (That's the reason why it was not included in jessie). Finally, the last upstream release has been in 2012, and while their git repository shows some activity in 2014, this has mainly been concerned about cosmetic issues (adding empty lines to conform with PEP8). So development seems to be pretty dead. I thus suggest that this package be removed. signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 05/09/2015 12:21 PM, Andreas Cadhalpun wrote: > But since there seems to be a clear consensus in favor of switching to > FFmpeg in Debian where did you get that impression from? btw, i find your email a bit too suggestive. gmsrd IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
packaging: python-soundfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 hi all, i would like to package python-soundfile [1], a python audio processing library wrapping libsndfile. i would prefer to do this under our team umbrella, so if anybody is interested please speak up. fgmasfrt IOhannes [1] https://github.com/bastibe/PySoundFile -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVPeENAAoJELZQGcR/ejb4M1YP/RBQ81ysffn+81LLQTn/0qZ0 BcYCB5WftDmBHGMVbP+b0AtexUuez5VCepUswJoQSCruq0L10RSoHU6ta9uzLgjS LULVUiq80u1gLXYomAE5JDZr73UcC2JFw8gKxC/eeelGHcLvbqdyShoLCj9x70Dq 1o2nYEFyg9zrk4Fp7kXv/1QWz9ys+BaMeChsMNCLDzVSmRKbenlPT8OuwBVL/50v xt3Gv8CEfTlXfLtKfVbGToypvYK3vsyCPdFkA1lTaya7a9a879/vvVb8hEQVud2n 3KnrTZoeldSeDhVBtm/y87aKU0oyFWj/K2Oz4BMkQHX8SYb3B1dDOu9A+rQfFmU3 O3onKnjZXy4bdBD+VYrawJxZDHf4NSn8LpkXom1/QVuXnnowGd+jWGu5XNj6ixgm S6UrUxfoiXNyVXRfeTPyVt1M+2YsXFUSQG44EKtydZ9TzTKJLnA216WVf6Lro+sQ LZHrztC464qYArxx6Nozd1qLo5ZO5N3Cmt9XxdlU8ylSkmekjibhdAdv5gKZ/3a7 oUrF3Zxs9tl2q50u6xJw74wkzHipxdwr5Xsd/jYd3g7OMF7FhZfJeMlbnFdHd/lM ggE9oTGzSqTw7YRiFhN4iyrxZpSA7KMAEfqMj689OCRXX3lBaP+ITDCTX0QenTI8 4dJ+p4HCQWREOzmjQXuZ =Li4q -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: Granting write access to all DDs to our git area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-04-13 11:08, Jonas Smedegaard wrote: > Quoting Fabian Greffrath (2015-04-13 09:30:54) >> I think it makes a difference if we blindly trust fellow DDs or >> probably random newcomers with unchecked identities. > > That's a valid point. yes. > > We already deal with with non-identified upstreams, so should not > blindly trust newly added git commits anyway. > > How do envision our fellow non-identified team mates might abuse > admin access to our git repos? Does the risk of such potential > abuse outweigh the benefit of the encouragement it provides to > treat our colleagues as equal peers? i quite agree. assuming "admin" still grants the same priviliges as in 2011 (add new members, edit meta data of alioth project), i think that the harm that can *possibly* be done by a malevolent user is rather small, and it might be worth to just try it out (making everybody admin) and wait until a malefactor turns up (which most likely will never happen). the other question is, how big an encouragement the granted unconditional trust really¹ provides. fgmasdr IOhannes ¹ not that i think that this measurable/quantifiable in any way. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVK8rzAAoJELZQGcR/ejb4Cx4P/Rzs2iXq33pk51XgWRY5AYpa 1POEszo4hoV51K5pTyqk657fpfFSHFMuemyW1vWalITOkVsqfBI9yhl1UvozW2TJ FsWFgjz5TbHIh8FkpRq02w86FFOdu4W530CRLCcATgizDAhSIGwUPT88Xaif3FS9 e6TQM4OUmTpOJuxdisXA+EaD0OJaAd4u1WE62Nb59YCJs9DJo9+6b4o3FGyG9yBB rIOYuYKZdbNg1BacYjtwSaG5/D6BYN0cwRzE03QvP+dFU5g+ADEWoBSJD9+9h2pG Jnt+Iu8/VmGYRhIl9j92ueO2fdlLnPTu53DPQnBrUQGzL+ogmImjhsh1ca91IFZu MzDcjDf2MWzRwTsomSzL+8joBo2CAzxQxEdW1nWhjg7+1yvWxhnOc5RGZu/1kaK2 8ssGlb0DiRnB8zE5//AXaK4mZZw8VAonkxdlmc3XNDigLgJz4SAb9bzWPi54mMKl uR1hCfaw4rf5BaflWPURZ1Mrv6Tc8X2yBVuT1Vh7plJhf+RR5CiAuf63AbG9sOGl URnOpIVm+9WCyF2nzfru2pM597UG/Fw+JOmToFSvzeC2IBt9pw7erHhC+1hjwa6e 6ACBZLxiaPmYGV7qseF4hhPiM5rgMb4Z9Zxc/BComZHPHEcah2rvFRvBD1z7pZf1 Bn9MwWiOrc2N++T5uyj8 =Gm7T -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#781095: pd-unauthorized: format list of contents and other small fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: tags -1 confirmed pending thanks On 2015-03-24 13:58, Daniele Forsi wrote: > Package: pd-unauthorized Severity: minor Tags: patch > > Dear Maintainer, > > the list of objects contained in this package is reflown (as per > the policy) and it's not easily readable in places like this > https://packages.debian.org/sid/pd-unauthorized > > The attached patch adds a leading space so that lines aren't > reflown, changes some words to upper case (MP3, Icecast/SHOUTcast), > adds a colon where it was missing, removes full-stops where > present, removes a double space and makes the list more consistent > removing "is" and adding "a". -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVGnGpAAoJELZQGcR/ejb475gP/ihhfBUlQPQsLMen5texMkk/ xsJK2Iw+echPEAFLieSOAryfZk96RV/tzHHZcPgwETS9t39G4lkObHOC7k12XAGy A/D47RcrD7a2xiGwlvNXIb2rR1WTjU5wSkLXlNC7oRXDRlMlsBGXlgMcqYc9lXOL pUEj4X04LTHMENYsRl1m8dc/+PREMoKDaeppIpE/BIHHke207vAXnjxw49rFy1eg NARcoIZb+7omjmiBHXi1hDhdg1pxiaHLPU6AKbsByPJjMtJ555QfpgmGmeC/c1Mh YLsNdYBdNKrdb/wVdyMFNgLsWdcwRvtlTD7NlAnMn4Jb9Sc1Or248sowyxcaxwhJ /H9dIocI9m27rA8Ihd/TCKq9p5sWWnDNGvubGfoYt+BFO/LlJXA/io1C8fDb3ZgQ NnF7xiKK3swdYBvZgGLKhW9g9Gjr5WxDvzGosRdelv/D/64peFqZPhEcVieq0fTI obn0hIjMgNbqQam3qMW566GmNIh1cOWzfmBBYm00yWvP11UgqSRcFwUS05z8WxYs eoexGad290Xs3KD8GGCG1oXvoGlq5I2Qevg4aRvHW2HZVJqxBoqcN8H0qI7SZT0L RAU31iEqu4SJtDooPIbYLIRWtAZX7E8kexEuy5pQc81WWpei/9lGqAE1YEXpQQ3/ uuNlJi2QAA6575dJKdRw =VT+g -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: Seeking for sponsorship for linuxptp (PTP/IEEE1588 implementation)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-02-19 14:46, Felipe Sateler wrote: >> >> I just saw that there is git-pq which seems to work similar. > > I'm not sure how gitpkg does the patch thing, but do note that gbp > pq branches are not meant to be published: the export format are > the patches in debian/patches. isn't that true for whatever you use? in the end (e.g. when it comes to uploading) you must provide a proper debian.tar.gz that patches the the orig sources if needed. how those patches are created and maintained is not so relevant. i don't even have a problem if the chosen workflow differes substantially from mine. however, in this case i need a working README.source that allows to adapt the chosen workflow with minimal knowledge. having said that: any news on the package itself? fgamdsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU7YyaAAoJELZQGcR/ejb44tIP/3fGhk3f4gSE7PbKRFAc8y6K oUXCtLbJUcfIPOBoMP/J5LqGDF3HC8RIlnUD6PP9XEcTJDvIPi6OmvXsx7uzpoYd EC7H3S3Ol7doe2T5bPVbHKAQAzsV8k0Fz5Aj/77+uHXIp5xXd0AfeeZ9NyF8L5/z qQcNlTRlWoxayhC597UJVh9Xp5o0VMRilD1uU5Ge9oZULIXKFsPnNimw1Qf8hUTz qQ/E2UXX+M/Aa1Bt6tDY3Y2rMuZ1YJD6K++OWrdSsfxREcav6lVfiDDexcXgxcdk U/9KDxYbCEFWDH9/D7KMkFrpGc7f2ZFI+vrk1xH4QP3Uhi31Su19Jkb2W8vRmyex fooLgpMLddSQR6zdH/eJkBwfh2n0o/kVzmMtMHGcCPvt7g+klJbIsg2Bae9Zq5ot 6as29syCUHelf3xpiG1WQiGKVDh7yhvthqTSE3sonnEKOiCwohKvw1g54RfrOxV+ RDAQwoaUGBGCVbitiik2QQ4YqHS5Pluf+EDtMmZtNT/HZQt7NhN1Ibv8rWpAJHkz dmS3Y8n7s9Aifiz8j3COVs4AdxM5lk8dtBWPbBrpWEkvfk5z531Zcagr+g78PR7Z r38/SqaH6y2VzR3ShVIAxmuW1DhAWFoDnpWwaLbvcUN2VnT4h9YeLNAUn/gFZtYK coqz7MpG9MUhPnlQJS6f =XOd+ -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: Seeking for sponsorship for linuxptp (PTP/IEEE1588 implementation)
(oops, forgot to include tino, who might not be subscribed to p-m-m; sorry for the noise) On 02/17/2015 07:50 PM, Felipe Sateler wrote: >> As for DDs: ales...@debian.org or umlae...@debian.org, we have even more >> in the multimedia team. > > I am happy to upload, but I cannot commit to reviewing the packaging > on my own. If other members of the team help up reviewing the package, > I am willing to sponsor. > me too (and I am personally interested in ptp packages). however, i would welcome it if the package would be team-maintained under the pkg-multimedia umbrella. anyhow, i'm currently doing a quick review of the package. some notes: - i very much prefer to build the package using git(-buildpackage) to just buliding packages from mentors.d.n, as this is my proven toolchain to build in a chroot environment. i am not a gitpkg user though, so i need some help, which you already provide in the debian/README.source (thanks for that!). unfortunately the information therein is not sufficient (and the pristine-tar line mentioning "syncevolution" is rather suspicious). i cloned http://tikei.de/git/linuxptp-debian.git and setup the quilt-patches hook; but running `gitpkg master` gives me the following error: ~~~ $ gitpkg master git archive exporting master preparing ../deb-packages/linuxptp/linuxptp-1.5 dpkg-source -b linuxptp-1.5 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building linuxptp using existing ./linuxptp_1.5.orig.tar.gz patching file makefile Reversed (or previously applied) patch detected! Skipping patch. 1 out of 1 hunk ignored dpkg-source: info: the patch has fuzz which is not allowed, or is malformed dpkg-source: info: if patch '0001-Adjust-installation-directory-for-Debian.patch' is correctly applied by quilt, use 'quilt refresh' to update it dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/0001-Adjust-installation-directory-for-Debian.patch/ --reject-file=- < linuxptp-1.5.orig.zcTD_d/debian/patches/0001-Adjust-installation-directory-for-Debian.patch gave error exit status 1 ~~~ - as this package has never been in debian before, you can trim the debian/changelog to a bare minimum (that is: a single section for "1.5-1" [sic!]) - there's a typo in README.Debian: "I also uses eth0" should probably read "It also uses eth0". it also might make a bit more sense to use "eth1" in the example (as the example you give does changes the behaviour to the original one :-)) - debian/rules there seems to be some cruft at the beginning of the file. e.g. why don't you just use `dpkg-parsechangelog -S Source` to get the srcpackage name? also you go through some hoops to parse the upstream-version from the debian/changelog, but then you hardcode UPSTREAMTAG to "upstream/1.5". most likely you can delete lines 3..8 - configuration files: any reasons you don't put all configuration files into /etc/ptp4l/ ? this might allow you to replace the override_dh_auto_install cruft by a simple debian/install file (but this might rename the /etc/ptp4l.conf to /etc/ptp4l/default.conf) i still have to do some functionality tests of the package... fgmsard IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#768295: pd-osc-1.0-2 is outdated and buggy
Control: retitle -1 bug with depth > 1 OSC address
Control: tags -1 confirmed
thanks
On 11/06/2014 11:28 AM, Antoine Villeret wrote:
> When parsing OSC path with more than one slash ('/'), the float is not
> understood by a number box.
to be precise, [routeOSC] will output a message with the remaining
OSC-path as the selector followed by the data.
when sending a message [/foo/bar 23( to [routeOSC /foo/bar], the
remaining OSC-path is empty, resulting in an empty symbol '' as the
selector; followed by the data (23).
the expected behaviour (which has been fixed in the upstream repository)
is to output with the selector "list".
signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
multiple uploaders
due to a few recent mails [1], i was wondering how much we (would like to) enforce our ">2 uploaders per package" rule. i know of at least one package i maintain under the hood of pkg-multimedia-maintainers, which has only a single uploader (me, obviously). soundscaperenderer is anybody interested in co-maintaining it (uses CDBS)? or should i remove this package from the team? mgfsadr IOhannes [1] at least http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2014-November/041903.html; but i seem to remember another similar email as well. signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bits from the Debian Multimedia Team [RELOADED]
On 10/07/2014 12:06 PM, Fabian Greffrath wrote: > Am Dienstag, den 07.10.2014, 11:53 +0200 schrieb Jaromír Mikeš: >> even if done after so long time and mean that project has been >> revived? > > IMHO Yes. With packaging the new release, we -- as Debian -- have merely > done what is expected from us. By mentioning even the smallest details > and selling them as news, we take relevance from the really important > changes and steal their spotlight. i agree. i've updated the wiki to separate "new" and merely "updated" applications. i've also had a go and sorted them alphabetically, as this seems the only reasonable sorting criteria i can come up with. fgmdsar IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#672352: gmerlin doesn't start with segfault
On 2014-09-15 12:28, IOhannes m zmölnig (Debian/GNU) wrote: > hi, > > thanks for the additional info. > > >> Versions of packages gmerlin recommends: pn gmerlin-encoders >> pn gmerlin-plugins-avdecoder pn >> gmerlin-plugins-base > > does the problem go away if you install any (or all) of these > recommended packages? and to reply to myself: uninstalling 'gmerlin-plugins-base' will make 'gmerlin' (as found in Debian/sid) segfault as well. i will upload a fixed version asap. fgamsdr IOhannes ___ 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#672352: gmerlin doesn't start with segfault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 hi, thanks for the additional info. > > Versions of packages gmerlin recommends: pn gmerlin-encoders > pn gmerlin-plugins-avdecoder pn > gmerlin-plugins-base does the problem go away if you install any (or all) of these recommended packages? fgasdmr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUFr9EAAoJELZQGcR/ejb4r20P/RpHLMbhkdSLgsLSBjnlmj+L B6c0QvgMIXWjCGoK4R55lWiA9CkFKT210Kj3oYaiySLTQAH7OTv6SbNeUI7q8Vrf JwoDtHQcfiHQgiWYmYV36l6L3B0qaKEoKO4/J7xYl8J76wmruRKnrfm4dHvdnPyd jTvbsCAboWtX2rnvy2R/KvSdB3cwHwUrTh+Oxv9dmfR00Dx48/F0GInQxBE9+EIw X3cKrTj5oVuQtgRrK334/SKxHLAFhuqD96o6rZCFMoClQo0Wi9NqpaJ40ilvGUwK DWBZVaj4R8GOcZ85zh3Rr0EXWsf/eUjOFdv+CfbxV3z7fhz4F1Vkp3TvGqrJhTC0 WvfqnAxcCJBftrK+DYSzwzCA30tpph5ObIFyV/Akir67Eg1AZnkWcrIn95eWE3fm MlbKI7Jp4a1pd3stf0ncsI54Vfn9NwwXtQobpJTNRKCLlWa8xqDxIaZlr8fQxoZg cW2k/tL+uv9co0FZyQBkLNNR/byEiYUSHDl0iyDrHl87FGF2sQhj8ttYJlyEswnN ji8RFkluw8VNMeiCOuv3x4+s81XeF/DQKIUatQ6AlPFyJBpr5SDWHUIGE8Ugn+aT 8Tk6SAfXbsZYL4XT/LGaoUVR/8BsYt9m/Ky1Yw3gtenVlo8Wj8+Bl/2sD3XQEeEn xvHAsa8NFNWHy/pyVVr7 =/rom -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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-07-29 03:20, Marco d'Itri wrote: >> if they are not drop in replacements, and it would also be a >> pain if >>> higher up packages link-in both ffmpeg & libav and some >>> clashing symbols are present... > This is why the new ffmpeg will use different symbols. Again, read > the first message. > according to the first message, this is *not* true. the packages will have different libraries-names / sonames, but this does not mean that they don't have clashing symbols. if both library foo (/usr/lib/libfoo.so.3.21) and library bar (/usr/lib/i386-linux-gnu/libbar.so.4.1) export the symbol "knarzifax", then how do you make sure that an application that is linked against both libraries for different functionality always chooses the korrect "knarzifax"? this becomes a real world issue, as soon as plugins are involved (which i find a common practice to access multimedia frameworks). application "flurp" has a both "flurp-plugin-libav" and "flurp-plugin-ffmpeg" installed. whichever plugin is loaded first, will pull in a library that shadows the symbol "knarzifax" for the *other* plugin. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJT10jZAAoJELZQGcR/ejb4o1AP/3aoHeFNZ3xcOLl/I0Y9g5Fp GsejeqWuE59CTtoo/1jp5byhueA5Uw9LpmFOmfKttKvqG3sEXhIkXBOA9wATXYS1 uDsblHzuhKhKagmkQ42N1Ql0h+d7vkZA8/duaAtcSb+8HOU/peMRUMQx/MQyxF4X z8hrmSHMpd9S2QTFJxjIfFa0kCQ9gtBv+p/2BSCRpLkxQBDyCoZeHwTmNQnpac4S xYT5Qzo2YW7U5JKXjllHoKcvdBJ1+gYJYfByBcn7ZmHVSv2Ittu9pl7kgH+S1KPk kdK9mopt3B0riCnIR+m3467TJ4U/F/UQ5VuZwENZ5GqivyiqvHHyyWnf3T2aa+rC hZM+k7mF06kQzOWcRi9F9Mqa/Tt0myZKYZVqpJY/y4U6LUYeSAcNmr6b0vzUkxh1 9YG3RwXMLNQZz565Dw7NoqO/7BKgoviSwSnd6OpHruGIYfScPQGkh0q9eU8v4q0U wazXWQ9ks1hHmp4Ea5QJuT+S/BQv3I5QEW0QYXn6flUkDeyj+T27djBisugive7g yGWEr4sVGczzwXjo1T5vgYxNGzvxPeBWGUzJqsRtxqVZKYYyMLYdzNA0TUP1B3vK rQQJXi7oXDTt/ta7yp09Pbp3ZHqxkJbjpLibgYoY9g9dIsEab25jahIK5xRBytz1 6BtDVvwo6srTgQEqOjzw =vaCN -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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 personally i would welcome if both libav and ffmpeg could co-exist within Debian¹. as i see it, libav and ffmpeg have diverged, and as such i would like to have the choice which one to use. On 2014-07-28 11:55, Marco d'Itri wrote: > On Jul 28, Alessio Treglia wrote: > >> Personally I don't feel like dropping libav in favor of ffmpeg >> now at this stage. + 1 i don't think that dropping libav is appropriate at all. > Except that, for a lot of the depending packages, there would be an > immediate benefit in the number of bugs fixed. at least in theory. > Personally I feel that we have inflicted libav on our users for way > more time than it was sensible to do. i would appreciate it, if you (and anybody else) used a less flammable &| touchy language. fgmadr IOhannes ¹ but then i'm not a member of the security team :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJT1jAxAAoJELZQGcR/ejb4DtoP/2jEpmxHblY7XX+mGoVT5I+c /Kr/VMwXv8glsbJhrEzgyJS0xaj6PONV0CL+pfoM7BzojK3LJQLza0aPs5u1ipLo +KqMOiK4WMNDk3YSnzZtYcGkM+vKN/bUZ3BF9b5HnBgCs/MI/hxInq52i6Ly6ESv TF6vfS/oUKyM1/PJAf5fiaZ5tegFBBc2QPYnK4ehSuDoT0IOhzxGmft7L5XTQJgU l3dwgYc7aKaDkiFthcXQjFiTuDynOEZtNfSt6CYouulNycNlue3ptMr+DA2exNzY RtpG/GY+lZnklEuHa+0Y/sfM2CBEJwJqSmvPmUXrg4vikDkjGBq0PhAc7D5OO8a0 0Z69wgyrGGCESdZAcTzbWTfKNi02X2kMDkrbDHiq9d605zh6XTYQqBPspVYkY3bW mne+wfu5UN/TK21nIDzV88NQEV9FJ4pQyJpU64Yj8hT2mXNetLps6eMAJJobNby6 xz4Mw3QkNkamy3/vZD+SlYyv1a/K23mY4rkE2JXX0RD6xdMa5RxUuvkWfvJbI1S/ MNAo5eag+RVVHNo1n/p9JliSFYUJFhrkrQy/giyPeBDoNP/yNrmYoxBxmGuMWSu8 Mr/NjfSF9tJ47E1dDmJ+i6YKmyDm0uwqX+oaWo7sS1Ag78RrkVjlP/FOtds9gfQN rwBXUWvmKD3zsCpTcfG0 =kSsp -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: Sponsorship/Review for package "karlyriceditor"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-05-26 17:46, forum::für::umläute wrote: > with that i meant a repository hosted on debian infrastructure. > most packaging repositories are hosted on alioth [1]. many alioth > packaging teams such as pkg-multimedia (and to a lesser extent > collab-maint) mandate the workflow as outlined in [2]. > (collab-maint probably does not mandate that workflow, but i > haven't yet seen a repository in collab-maint that does not use it; > i haven't looked too deeply though). And on 2014-05-26 23:36, Martin Steghöfer replied: > I'm sorry, I think you forgot to include the URL for reference > [2]. as a matter of fact, i forgot both references. [1] http://alioth.debian.org [2] hmm, actually i can't remember which reference i wanted to give, probably just re-iterating https://wiki.debian.org/DebianMultimedia/DevelopPackaging#Packaging_guidelines though it doesn't add any new info. gvbmadsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJThEdFAAoJELZQGcR/ejb4w+wQAIUI40E2qg6uw0CZDZdA9dmi 2a5GmXT25FTBUGFs1lyhxaY8xQeQCOxjFX6JbNwTwnn6okdiqXUmuKW2aQH+CQ2s ue2znG2MLJtKyODYr0LNh9LffwzbSnPq1CCJBffwDf1YwlepGWHTwPwAnmAl5TDV Qs7zTtwTbgfqmWommdTYUF9IdHUDH5elknehDRDFzChgywHXvWiSeBnROU3L9H/j rS38k9oJz3Wc5kiH58FdXq0QW2DljvlodsY3ejmrmVCPT9VHBUKu3n4XxHSnYzfo lCBZfOeT4tmP49Z8gCtXstgdxVn4iZnOgprxUlATlliE9oWbpG03rlkwt6+AVgqR RML12wr/Ia/IwVPm240Eg8XoHAEP5ScAaUNmmdaWewMCcYefoAWJrexV+HLtCBpj McXke27atDTQH0YmrUZdyg6lI99LE//Smi563tjSvDZvM5s1VQfXsgWohZcWcwLM LBjIzz6osYy/NyYOSwcx+4H9SbmbYCVZ+4eNT9a4hgYgN82FVW5wf9CeqRytSuLu As1EnHerybXLWVnIdYxoexOP1jRR5iRxNSxXyJO1Kj201+mJsgfI3kU4kRPshGZW bHJ69+K1zshD0JB7fxm+yZZzhag7nTmrBDuYBqshhuYE3tbI0ntXyAbTo+si+OLe tmdHTgMTKJqfZyFVfSUd =9Ax/ -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#583787: src:frei0r: Some files are LGPL 2.1
Control: tags -1 pending,fixed-in-experimental Control: owner -1 umlae...@debian.org thanks for the report. while packaging frei0r-1.4 we have updated debian/copyright to DEP5 and have now a (hopefully) accurate picture of the various licenses and copyrights used. frei0r_1.4-1 is now in experimental, and will hopefully be uploaded to unstable soon. gfmdsr IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
sharing code between packages
hi,
i'm seeking advice about how to deal with the following situation:
we are currently maintaining an application-package ("puredata" for
those interested), brought to use by upstream1.
now "some people" (upstream2, unrelated to upstream1) have turned the
application into a library ("libpd"), by adding a thin layer on top of
the application code.
the library consists of a C-library (the application code base + about 7
.c-files and some headers) and bindings for various languages (C++, C#,
ObjC, java, python, younameit).
upstream2 is following the application development closely, but so far
the library-layer has not made it back into the application codebase.
thus the library code includes a full copy of the application code
(obviously omitting a few files during build)
now i'm wondering what's the best way to bring both the application and
the library into Debian.
the main obstacle is obviously the code copy.
i see two options:
- do as if there was no code-copy, and simply package the library
- somehow use the application source package to build the library:
-- e.g. patch (as in /debian/patches/) the application package to
include the library-wrapper (that's a total of 15 .c/.h-files) and make
the application source package provide also a libified version; use the
library package to build the various non-C language bindings
-- OR somehow import the application source package when building the
library package and use the application code rather than it's copy. (i'm
sure there are some ways to do so, e.g. using multiple upstream
tarballs; but i don't know yet how)
any ideas?
fmdars
IOhannes
signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Sponsorship/Review for package "karlyriceditor"
On 05/19/2014 07:19 PM, Martin Steghöfer wrote:
> Just to bring this to your attention once more before moving on to other
> places in order to find a reviewer or sponsor. It would be very nice, if
> someone could have a look!
here at least a review:
your Vcs: cool that you are using git.
but your workflow seems to be somewhat non-standard (only tracking
debian/ in git). we usually track the entire package in git, which
includes pristine-tarballs from upstream [1].
this eases integration with gbp a lot.
debian/control:
- Vcs-Stanzas:
seem to be missing (most likely because you would like to move the
packaging to a more "debian" repo?)
- Description:
all those acronyms don't mean anything to me; also "support for foo
and bar specifics" sounds weird to me. should that read "supports
formats foo and bar"?
- Depends:
are all those manual dependencies really needed? why can't they be
calculated from by ${shlibs:Depends}
debian/changelog:
usually debian/changelog for an initial upload will only contain a
single line: "* Initial release (Closes: #692968)"
the purpose of this changelog is to report the changes in the packaging
with regard to the last upload. since there is none, you merge all those
changes into "initial packaging".
also, changelog entries should only document versions uploaded to debian.
since 1.3-1 never made it, there is no use documenting it.
debian/rules:
there's some cruft involved here, to include upstream's changelog.
check out dh_installchangelogs.
debian/copyright:
- Source:
the debian/copyright is supposed to not change between upstream-releases
if there are no changes in the copyrights.
this means that you should provide a version-independent link to the
sources, e.g.: http://sourceforge.net/projects/karlyriceditor/files
- License:
according to `licensecheck` all files (with the exception of
./build-*.sh and ./nsis/create_installer.sh which do not have a license
boilerplate) are really GPL-3+
you claim that all files are copyright "2003-2005 James Klicman
", of whom i cannot find any references in any file
(but debian/copyright). this may indicate that you did some extra research.
however, all files (excluding those mentioned above) have an explicit
copyright notice "2009-2013 George Yunaev". some have an additional
copyright "2009-2010 Daniel Roggen".
i find it easier to read if all the license-texts are collected at the
end of debian/copyright.
something like
Files: *
Copyright: 2000-2001, John Doe
License: foo
Files: debian/*
Copyright: 2042, Mimi Minus
License: foo
License: foo
this is a foo license...
finally:
the package FTBFS in a pristine sid environment (using
pbuilder/git-buildpackage).
most likely the package is needs some work for libav10.
ffmpegvideodecoder.cpp: In member function 'bool
FFMpegVideoDecoder::openFile(const QString&, unsigned int)':
ffmpegvideodecoder.cpp:116:57: error: 'AVStream' has no member named
'r_frame_rate'
d->m_fps_den = d->pFormatCtx->streams[d->videoStream]->r_frame_rate.den;
^
ffmpegvideodecoder.cpp:117:57: error: 'AVStream' has no member named
'r_frame_rate'
d->m_fps_num = d->pFormatCtx->streams[d->videoStream]->r_frame_rate.num;
^
ffmpegvideodecoder.cpp:142:14: warning: 'AVFrame* avcodec_alloc_frame()'
is deprecated (declared at /usr/include/libavcodec/avcodec.h:3114)
[-Wdeprecated-declarations]
d->pFrame = avcodec_alloc_frame();
[...] ^
Makefile:709: recipe for target 'ffmpegvideodecoder.o' failed
make[2]: *** [ffmpegvideodecoder.o] Error 1
make[2]: Leaving directory '/tmp/buildd/karlyriceditor-1.11/src'
Makefile:117: recipe for target 'sub-src-check' failed
make[1]: *** [sub-src-check] Error 2
make[1]: Leaving directory '/tmp/buildd/karlyriceditor-1.11'
dh_auto_test: make -j1 check returned exit code 2
debian/rules:22: recipe for target 'build' failed
make: *** [build] Error 2
fmgadsr
IOhannes
[1] https://wiki.debian.org/DebianMultimedia/DevelopPackaging
signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: soundscaperenderer_0.4.1~dfsg-1_amd64.changes REJECTED
On 05/08/2014 01:57 PM, Thorsten Alteholz wrote: > > > On Mon, 5 May 2014, "IOhannes m zmölnig (Debian/GNU)" wrote: >> if so, i would re-upload the package with the fixed debian/copyright. > > ok, so please go on. ok, thanks; uploaded. fgmards IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: soundscaperenderer_0.4.1~dfsg-1_amd64.changes REJECTED
On 05/02/2014 03:00 PM, Thorsten Alteholz wrote: > > Dear Maintainer, > > unfortunately I have to reject your package. > > Please add the missing BOOST license of > ssr-0.4.1\apf\unit_tests\catch\catch.hpp > to your debian/copyright. > In addition ssr-0.4.1\data\MacOSX\dylibbundler\src\* is GPLv2+ > > You might also want to change the license of src/razor-ahrs/* from GPLv3+ to > GPLv3. > i've fixed these, but: > Can you please explain how I can build ssr-0.4.1\data\MacOSX\run-ssr.scpt? hmm, afaik, apple's native "AppleScript Editor" is able to open and edit (binary) .scpt files natively. imho, this makes the .scpt file the "preferred form for modification", and thus the true source of itself. afaik, Debian currently does not provide any editor that can read or edit such binary scripts, but i think that this does not make the package any less DFSG compliant. do you agree? if so, i would re-upload the package with the fixed debian/copyright. fmrdsa IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: RFS: xvidcore_1.3.3-1
On 04/22/2014 09:55 AM, Fabian Greffrath wrote: > Dear team, > > I have prepared xvidcore (2:1.3.3-1) in GIT, please upload: > http://anonscm.debian.org/gitweb/?p=pkg-multimedia/xvidcore.git > pushed standards version, removed dm-upload-allowed field and uploaded. thanks for the work. gfmdsar IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
real name (was: Re: Looking for "libde265" package review / sponsor)
On 03/31/2014 12:19 PM, forum::für::umläute wrote: > hi, argh, i did it again. sorry to not use my real name in the "From:" header. but i finally found the "Correct Identity" plugin for icedove, which should get my "From" address correctly for debian related emails. fgmards IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
