Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Reinhard, On 28.07.2014 02:05, Reinhard Tartler wrote: On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun wrote: * Does it make sense for me to switch my package? The rule of thumb is, if your upstream uses FFmpeg for development you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. I discussed this with Moritz in the ITP bug. Moritz ended this discussion [a], and as I wasn't convinced by his arguments, I continued my work. If in the end really only one copy is allowed in the next stable release, I think it should be FFmpeg. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. I think it would be best if ftp-master left the ffmpeg package in NEW until an answer to this problem has been found. I fail to see how this would help anyone, it only makes testing the package more difficult. Whether or not the package is acceptable for the next stable release is not to be decided by the ftp-masters, but rather by the release team. [1] https://lists.debian.org/debian-devel/2014/02/msg00668.html The FFmpeg version currently in NEW has been there for more than 2 months and is thus outdated. If you want to test the current packages, you can build them from the repository on Alioth [17] (e.g. using git-buildpackage). Furthermore, we'd like to move the FFmpeg packaging under the umbrella of the pkg-multimedia team, because this would facilitate future FFmpeg transitions. I am curious why this is your first email about this matter to pkg-multimedia, and why do you write this email only now? In the last discussion on debian-devel it was suggested to get the FFmpeg packages into experimental first [b], before further discussion, so I tried to achieve that. As the package has been in NEW for a rather long time and the freeze is getting closer, sending this mail now seemed appropriate. Moreover, I am curious why I haven't seen you working on libavcodec bugs in Debian before, It would be great if I could fix every bug in Debian, but unfortunately my time is limited. Therefore, when I encounter a problem that cannot immediately be fixed, I try to work around it. The workaround for practically all problems I had with the Libav packages in Debian could be solved by installing FFmpeg binaries from third parties. Therefore I finally decided to work on a more sustainable solution, i.e. a FFmpeg package in Debian. and why do you believe you can do a better job with the ffmpeg package currently on NEW? It is a lot more likely that I work on fixing a bug that affects me, if there is no easy workaround. Best regards, Andreas a: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#568 b: https://lists.debian.org/debian-devel/2014/02/msg00714.html ___ 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: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On Sun, 27 Jul 2014, Reinhard Tartler wrote: > In [1], Moritz from the security team clearly stated that he is more > than uncomfortable with having more than one copy of libavcodec in > debian/testing. In consequence this means that any package that builds > against the ffmpeg packages currently in NEW won't make it into > testing either. I am therefore surprised about the given answer to the "More than uncomfortable" does not mean "will not be included" > I think it would be best if ftp-master left the ffmpeg package in NEW > until an answer to this problem has been found. Why, only because libav gets a more powerful and efficient competition? > I am curious why this is your first email about this matter to > pkg-multimedia, and why do you write this email only now? > > Moreover, I am curious why I haven't seen you working on libavcodec > bugs in Debian before, and why do you believe you can do a better job > with the ffmpeg package currently on NEW? As Marco said, why should he fix bugs in av which have been fixed since ages in ffmeg in many (most?) cases? I am all for having a good ffmpeg set of cmd line progs and libs in Debian. It is too long that this sad and useless split was made. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 ___ 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: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Jul 28, Reinhard Tartler wrote: > Moreover, I am curious why I haven't seen you working on libavcodec > bugs in Debian before, and why do you believe you can do a better job > with the ffmpeg package currently on NEW? Why should he work on libavcodec when he (along with many other people) wants ffmpeg instead? -- ciao, Marco signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun wrote: > * Does it make sense for me to switch my package? >The rule of thumb is, if your upstream uses FFmpeg for development >you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. I think it would be best if ftp-master left the ffmpeg package in NEW until an answer to this problem has been found. [1] https://lists.debian.org/debian-devel/2014/02/msg00668.html > The FFmpeg version currently in NEW has been there for more than > 2 months and is thus outdated. If you want to test the current > packages, you can build them from the repository on Alioth [17] > (e.g. using git-buildpackage). > > Furthermore, we'd like to move the FFmpeg packaging under the umbrella > of the pkg-multimedia team, because this would facilitate future FFmpeg > transitions. I am curious why this is your first email about this matter to pkg-multimedia, and why do you write this email only now? Moreover, I am curious why I haven't seen you working on libavcodec bugs in Debian before, and why do you believe you can do a better job with the ffmpeg package currently on NEW? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Reintroducing FFmpeg to Debian
Hi all,
some of you may have noticed a weird ffmpeg package in the NEW queue[1].
Let me explain:
In 2011 Libav[2] was forked from FFmpeg[3]. It was a time of great
uncertainty, the fork happened with much drama that didn't help making a
technical cut, and at that peculiar time Debian switched to Libav.
Since then the two projects evolved differently, and we have now a
clearer view.
Some short answers to questions you might have now:
* Why is FFmpeg needed in Debian?
- It has features our users are asking for (mostly support for more
codecs, formats and filters)[4-6].
- Some applications break when built against Libav on Debian,
because they are developed using FFmpeg[7-10].
- There are issues[11-12] in Libav's command line tools, that can't
be reproduced with FFmpeg's tools.
- It has a big and active user and developer community. Those of
them who want to use Debian currently need to install FFmpeg from
third parties or compile their own version from source.
* Do you intend to replace Libav by FFmpeg in Debian?
No, there is no need to replace anything as long as it is maintained.
Currently the main goal is to give multimedia maintainers a choice
between the two sets of libraries to link against, and our users the
choice to use the 'ffmpeg' utility. That is possible, because the
packages are co-installable. (Only the *-dev packages conflict.)
* But I thought they were forks, why don't you just create conflicting
packages?
- Because it can't really work! If we do that, packages built with
FFmpeg won't be installable next to packages built with Libav
unless we have full binary compatibility.
- Binary compatibility can only be achieved with some tradeoffs:
a) Not all soversions of the libraries match, so we would have
to patch that away.
b) FFmpeg would have to be compiled with the configure option
--enable-incompatible-libav-abi, resulting in less tested
code paths.
c) FFmpeg and Libav would need to be updated at the same time.
d) The biggest problem is that this would allow applications only
to use the minimal set of the ABI supported by both.
* I do not believe you, explain that voodoo to me: How is it that it
won't break all of Debian and make kittens cry?
(aka: How is FFmpeg packaged for Debian?)
- We built the packages in a way that avoids filename conflicts.
The sonames of the FFmpeg libraries are suffixed with '-ffmpeg',
e.g. libavcodec-ffmpeg.so.55 instead of libavcodec.so.55.
This also means that only if a package uses pkg-config to detect
the correct linker flags, you can simply install e.g. the
libavcodec-ffmpeg-dev package and it will work transparently.
(About half the packages build with no further change, see
stats below.)
- From a user point of view, the tools have different names anyway,
e.g. ffmpeg and avconv, except for qt-faststart, which is
therefore packaged in a separate binary package that diverts
the Libav version to qt-faststart.libav.
Yes, you can have /usr/bin/ffmpeg and /usr/bin/avconv at the same
time without conflicts.
- The development packages have to conflict, because they provide
header files (and pkg-config files) with identical names in
identical locations.
- To avoid potential problems when a program is linked against
FFmpeg libraries and other libraries, which in turn are linked
against Libav, the symbol versions are changed to e.g.
LIBAVCODEC_FFMPEG_55 instead of LIBAVCODEC_55.
* Ok, let's say I'm a multimedia maintainer and want to try out
building my package against your ffmpeg, what should I do?
- If your package uses pkg-config, which is commonly the case, all
you have to do is to replace all lib{av,swscale,postproc}*-dev
build-dependencies by lib{av,swscale,postproc}*-ffmpeg-dev.
You can keep the Libav build-dependencies as alternatives.
- In the (odd) case your upstream doesn't use pkg-config
(52 packages), it's probably a good idea to start using it, so
that the program can be easily built with both.
The patches are usually quite simple as you can see in this
example:
--- squeezelite-1.6.orig/Makefile
+++ squeezelite-1.6/Makefile
@@ -26,7 +26,7 @@ LINK_ALSA= -lasound
LINK_PORTAUDIO = -lportaudio
LINKALL = -lFLAC -lmad -lvorbisfile -lfaad -lmpg123
-LINKALL_FF = -lavcodec -lavformat -lavutil
+LINKALL_FF = $(shell pkg-config --libs libavcodec libavformat
libavutil)
LINKALL_RESAMPLE = -lsoxr
DEPS = squeezelite.h slimproto.h
Patches for packages using Autoconf or Cmake are similarly
straight-forward.
- Sometimes other minor adjustments are needed. (13 packages)
- There are only 2 packages (opencv and ffms2) that would trigger a
needed transition, but that woul
Bug#750199: xbmc: No Video but audio and subtitiles
Package: xbmc Version: 2:13.1~rc1+dfsg1-1 Hello, I can confirm this problem. The package vdpau-va-driver is installed by default with xbmc now, but the problem is not fixed. Sound and subtitles are good, but video is just black when output is anything ff-*-vdpau, the output ff-h264-vaapi does work fine for most videos but it creates weird screen artifacts for at least one of my older videos. Software rendering works too. This problem is visible in my desktop PC (NVIDIA GTX560) and my HTPC (NVIDIA GT630). Both running and up to date Jessie. I have attached the relevant log files while playing a dvd-rip of one of my daughter's cartoons. I tried the same file with 'mpv -hwdec=vdpau' from github using a similar build configuration as http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpv.git;a=blob;f=debian/rules;h=17b08f2bf4bd323620e41383123b47ab8368b44c;hb=refs/heads/experimental and it worked fine. PS: I think this is a duplicate of #742896. --- System information. --- Architecture: amd64 Kernel: Linux 3.14-1-amd64 Debian Release: jessie/sid 500 testing-updates mirrors.kernel.org 500 testing security.debian.org 500 testing mirrors.kernel.org 500 stable dl.google.com --- Package information. --- Depends(Version) | Installed -+-=== xbmc-bin (>= 2:13.1~rc1+dfsg1-1) | 2:13.1~rc1+dfsg1-1 xbmc-bin (<< 2:13.1~rc1+dfsg1-1.1~) | 2:13.1~rc1+dfsg1-1 mesa-utils | 8.2.0-1 x11-utils| 7.7+2 fonts-dejavu-core| 2.34-1 OR ttf-dejavu-core | 2.34-1 fonts-roboto | 1:4.3-3 libjs-jquery | 1.7.2+dfsg-3 libjs-iscroll| 5.1.1+dfsg1-2 python-imaging | 2.5.1-1 python:any (>= 2.7.5-5~) | Package's Recommends field is empty. Package's Suggests field is empty. ./mpv -hwdec=vdpau ~/Videos/The\ Backyardigans\ -\ Robin\ Hood\ the\ Clean/title00.mkv Playing: /home/cramos/Videos/The Backyardigans - Robin Hood the Clean/title00.mkv [stream] Video (+) --vid=1 (mpeg2video) [stream] Audio (+) --aid=1 --alang=spa (*) '2/0' (ac3) [stream] Audio --aid=2 --alang=eng '2/0' (ac3) Using software decoding. AO: [pulse] 48000Hz stereo 2ch float AV: 00:00:00 / 00:24:22 (0%) A-V: 0.000 [libav/video] mpeg2video: warning: first frame is no keyframe AV: 00:00:00 / 00:24:22 (0%) A-V: 0.000 VO: [vdpau] 720x480 => 720x540 yuv420p [vo/vdpau] Compositing window manager detected. Assuming timing info is inaccurate. AV: 00:00:06 / 00:24:22 (0%) A-V: 0.001 Exiting... (Quit) display: :0 screen: 0 API version: 1 Information string: NVIDIA VDPAU Driver Shared Library 340.24 Wed Jul 2 15:07:37 PDT 2014 Video surface: name width height types --- 420 4096 4096 NV12 YV12 422 4096 4096 UYVY YUYV Decoder capabilities: name level macbs width height --- MPEG1 0 8192 2048 2048 MPEG2_SIMPLE 3 8192 2048 2048 MPEG2_MAIN3 8192 2048 2048 H264_MAIN41 8192 2048 2048 H264_HIGH41 8192 2048 2048 VC1_SIMPLE1 8190 2048 2048 VC1_MAIN 2 8190 2048 2048 VC1_ADVANCED 4 8190 2048 2048 MPEG4_PART2_SP3 8192 2048 2048 MPEG4_PART2_ASP 5 8192 2048 2048 DIVX4_QMOBILE 0 8192 2048 2048 DIVX4_MOBILE 0 8192 2048 2048 DIVX4_HOME_THEATER0 8192 2048 2048 DIVX4_HD_1080P0 8192 2048 2048 DIVX5_QMOBILE 0 8192 2048 2048 DIVX5_MOBILE 0 8192 2048 2048 DIVX5_HOME_THEATER0 8192 2048 2048 DIVX5_HD_1080P0 8192 2048 2048 Output surface: name width height nat types B8G8R8A8 16384 16384y Y8U8V8A8 V8U8Y8A8 R10G10B10A2 16384 16384y Y8U8V8A8 V8U8Y8A8 Bitmap surface: name width height -- B8G8R8A8 16384 16384 R8G8B8A8 16384 16384 R10G10B10A2 16384 16384 B10G10R10A2 16384 16384 A8 16384 16384 Video mixer: feature namesup DEINTERLACE_TEMPORAL y DEINTERLACE_TEMPORAL_SPATIAL y INVERSE_TELECINE y NOISE_REDUCTION y SHARPNESSy LUMA_KEY y HIGH QUALITY SCALING - L1y HIGH QUALITY SCALING - L2- HIGH QUALITY SCALING - L3- HIGH QUALITY SCALING - L4- HIGH QUALITY SCALING - L5- HIGH QUALITY SCALING - L6- HIGH QUALITY SCALING
Bug#756174: jackd2 building without any of the required build flags
On Sun, Jul 27, 2014 at 2:08 PM, Jonas Smedegaard wrote: > Quoting Reinhard Tartler (2014-07-27 16:24:11) >> Given that this support is not in place, I wonder if CDBS is the best >> helper infrastructure for this package. > > I don't follow your logic here, Reinhard. CDBS _does_ have support for > waf (this package just doesn't make use of that) and (from a brief look) > it seems to me that short-form dh does _not_ have support for waf, so I > fail to understand how CDBS should be ditched for this reason. > > Did you perhaps simply misread Steve's email? Quite likely that's the case. I was not aware of waf.mk, and I wouldn't have suggested the above if I had known. I have to apologize. Maybe you could perhaps help with revising the jackd2 packaging to use wak.mk? Again, sorry for any confusion I might have caused. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#756174: jackd2 building without any of the required build flags
Quoting Reinhard Tartler (2014-07-27 16:24:11) > On Sun, Jul 27, 2014 at 1:54 AM, Steve Langasek > wrote: >> Package: jackd2 >> Version: 1.9.10+20140610git97e0e80b~dfsg-1 >> Severity: important >> Tags: patch >> User: ubuntu-de...@lists.ubuntu.com >> Usertags: origin-ubuntu utopic ubuntu-patch >> >> The jackd2 package in Debian unstable does not properly pass >> dpkg-buildflags values to waf. As a result, the package is built >> without optimizations (-O2), has no debugging symbols available at >> build time (-g), and doesn't use any of the hardening flags that are >> exported by dpkg-buildflags by default on Debian. >> >> The first two of these are violation of a policy "should" (10.1), the >> last is bad for the security of the package. >> >> The attached patch is a minimally-invasive fix for this, which uses >> DEB_MAKE_EXTRA_ARGS to pass the variables to waf. However, waf is >> not make, so this isn't strictly correct. There is a waf class in >> cdbs (available since cdbs 0.4.90); I don't know why you're not using >> it, perhaps you want to switch to using that instead. > > Jonas, can you take a look at this patch, please? Patch looks fine to me. I agree with Steve that using the CDBS waf.mk snippet might be better. >> I would offer a patch to convert the package to dh(1), but >> considering the contents of the Uploaders field I suspect it would >> not be accepted. > > I'm inclined to agree. I guess the "right CDBS philosophy" would be to > have waf support in CDBS, so that debian/rules could be significantly > shortened. > > Given that this support is not in place, I wonder if CDBS is the best > helper infrastructure for this package. I don't follow your logic here, Reinhard. CDBS _does_ have support for waf (this package just doesn't make use of that) and (from a brief look) it seems to me that short-form dh does _not_ have support for waf, so I fail to understand how CDBS should be ditched for this reason. Did you perhaps simply misread Steve's email? If you are looking for an excuse to ditch CDBS, then obviously it is _not_ better to improve the use of CDBS - that would be a waste of time. - 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
camorama 0.19-3 MIGRATED to testing
FYI: The status of the camorama source package in Debian's testing distribution has changed. Previous version: 0.19-2.3 Current version: 0.19-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#756174: jackd2 building without any of the required build flags
On Sun, Jul 27, 2014 at 1:54 AM, Steve Langasek wrote: > Package: jackd2 > Version: 1.9.10+20140610git97e0e80b~dfsg-1 > Severity: important > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu utopic ubuntu-patch > > The jackd2 package in Debian unstable does not properly pass dpkg-buildflags > values to waf. As a result, the package is built without optimizations > (-O2), has no debugging symbols available at build time (-g), and doesn't > use any of the hardening flags that are exported by dpkg-buildflags by > default on Debian. > > The first two of these are violation of a policy "should" (10.1), the last > is bad for the security of the package. > > The attached patch is a minimally-invasive fix for this, which uses > DEB_MAKE_EXTRA_ARGS to pass the variables to waf. However, waf is not make, > so this isn't strictly correct. There is a waf class in cdbs (available > since cdbs 0.4.90); I don't know why you're not using it, perhaps you want > to switch to using that instead. Jonas, can you take a look at this patch, please? > > I would offer a patch to convert the package to dh(1), but considering the > contents of the Uploaders field I suspect it would not be accepted. I'm inclined to agree. I guess the "right CDBS philosophy" would be to have waf support in CDBS, so that debian/rules could be significantly shortened. Given that this support is not in place, I wonder if CDBS is the best helper infrastructure for this package. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Help needed packing new Version of QasTools
Am 27.07.2014 07:33, schrieb Alessio Treglia: > On Sat, Jul 26, 2014 at 3:04 PM, Sebastian Holtermann wrote: >> Hello, >> >> I'd like to upload a new version of QasTools but it has >> been a while since I built the last package and I'm >> pretty much out of the package building workflow >> and could need some help. > > Please go ahead releasing the tarball. > I'll take care of the packaging. > Hi Alessio, thanks for your support, The 0.18.0 tarballs are out, see http://sourceforge.net/projects/qastools/files/0.18.0/ Regards, Sebastian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
tap-plugins-doc_20140526-2_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 27 Jul 2014 13:30:58 +0200 Source: tap-plugins-doc Binary: tap-plugins-doc Architecture: source all Version: 20140526-2 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers Changed-By: Jaromír Mikeš Description: tap-plugins-doc - TAP-plugins documentation Changes: tap-plugins-doc (20140526-2) unstable; urgency=medium . * Fix privacy-breach patch. Thanks to Sebastian Ramacher Checksums-Sha1: 648f8d08cb9014b3bb52224015e0801edaa04bbd 2064 tap-plugins-doc_20140526-2.dsc a279f1a20f99dc4771e0b8f90a95e7400366a41f 2824 tap-plugins-doc_20140526-2.debian.tar.xz 2a7828c37f6961415b83d76c227026fc4d73c3a4 490150 tap-plugins-doc_20140526-2_all.deb Checksums-Sha256: 12b402c38cde85e389c4fcfb45b9c129dfc6f7c6c0c4d7317fa38870a63c4365 2064 tap-plugins-doc_20140526-2.dsc 982bfce2b22f2be6056b82d7f99725347d0b6f6995a94579bd6131dbff4df6d1 2824 tap-plugins-doc_20140526-2.debian.tar.xz 499d68a89b3813a3b423cdee581d7bdac0a969f20b716ac5524d5e7f1c2737d9 490150 tap-plugins-doc_20140526-2_all.deb Files: fcfab86e8d7ff8b68e52d2b21fa08e5f 490150 doc optional tap-plugins-doc_20140526-2_all.deb d3ac955ad0e03997fa218855bdc7d483 2064 doc optional tap-plugins-doc_20140526-2.dsc 7f43005dbff283db78b0c4383a64ff33 2824 doc optional tap-plugins-doc_20140526-2.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJT1OOBAAoJEFsBlFXiuE+lpSoP/33Tf6cEMgsi+D9s7FztFrbC +CdreEs0qwJ5diwPjm8Vf0vVUlTrkdSy+h0FNas/BbV+HlGR1ZJzd7GR1oNP23bM A+FcozT3RY1WpWJVcWFQnqvcaw8JQRlQ/aXx1hwKfrFwOcuCb6ROzJEAEhBVbm0T QCHZt376dmeQ3e7xVjKYtag2dERn/IrMJdg5T9Y6nnRlZJgozpGWmuLS1/kbbJBQ PulWHO5QA+eHuLqR+7rNMVkc3lyvN7RnSegc539BHvXQjgCjRWBFIuynqM5wSKuO Bxz9OwWSRgOaX/RG4xvyFeGOct7kfKD6W/lMSyH+BHDdbZJyHvqtgJSQ6RqAoAqQ /xck9WAm6AvqMcuumWe65eUlvOceQFyVWhS2O62JNPrb1kStiTAWLy4CiNo0P37O 9Aumig8NYdLBIoqeC0pV1x/LnWF9R+w+CUf37H8Jdk4rWVv8fzSPkv+DdUcMZCyJ tXt4XH1kMSYA1VVrlF9aycEJDL8HU/hs+szSkaz9rQXFKnX5kWJcON5yyYtK0J4T B9ieftSdRxX2EI2CCHDB+qhW7UpCLMwm6uZY47HcGTZGS5DVx50y5YOYn4lQlzAS Mry1qUR4QAC6iI8Yws5N9KEV5Te6fBRKllxf/JYHg4l0dVqZICnL7iJFUTUsHJj4 QHunIPVVT8Yki4LGe1fX =8P1F -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ 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] tap-plugins-doc/master: Patch patch fixing privacy-breach.
2014-07-27 13:12 GMT+02:00 Sebastian Ramacher : > > Simply removing all of it is not the intention of the lintian tag. > Please replace the tags which cause the privacy-breach-* tags to > be emitted with plain text. Something like the attached patch should do > it. > Fixed. Thank you! best regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of tap-plugins-doc_20140526-2_amd64.changes
tap-plugins-doc_20140526-2_amd64.changes uploaded successfully to localhost along with the files: tap-plugins-doc_20140526-2_all.deb tap-plugins-doc_20140526-2.dsc tap-plugins-doc_20140526-2.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] tap-plugins-doc/master: Patch patch fixing privacy-breach.
On 2014-07-25 10:04:33, mira-gu...@users.alioth.debian.org wrote: > The following commit has been merged in the master branch: > commit 08f0a58667b5af74373e7cb2ee155edf23e20957 > Author: Jaromír Mikeš > Date: Fri Jul 25 12:04:23 2014 +0200 > > Patch patch fixing privacy-breach. > > diff --git a/debian/patches/01-fix_privacy_breach.patch > b/debian/patches/01-fix_privacy_breach.patch > new file mode 100644 > index 000..cac26f0 > --- /dev/null > +++ b/debian/patches/01-fix_privacy_breach.patch > @@ -0,0 +1,25 @@ > +Description: Fix privacy-breach problem. > +Author: Jaromír Mikeš > +Forwarded: no > + > +Index: tap-plugins-doc/index.html > +=== > +--- tap-plugins-doc.orig/index.html > tap-plugins-doc/index.html > +@@ -117,16 +117,3 @@ warranties of MERCHANTABILITY and FITNES > + PURPOSE. Again, see the file COPYING for details. > + > + > +- > +-http://sourceforge.net/donate/index.php?group_id=100722";> > +-http://sourceforge.net/images/project-support.jpg"; > +-border="0" alt="Donate to TAP-plugins."> > +-or href="http://www.amazon.co.uk/wishlist/8KRTCLLQMIP7";>buy me a gift! > +-(or at least send fan mail) > +- > +- > +- > +-http://sourceforge.net";> +-src="http://sourceforge.net/sflogo.php?group_id=100722&type=5"; > +-width="210" height="62" border="0" alt="SourceForge.net Logo" /> > +- Please read the tag description carefully. In particular: E: tap-plugins-doc: privacy-breach-donation usr/share/doc/tap-plugins/html/index.html ... N:Please replace any scripts, images, or other remote resources with N:non-remote resources. It is preferable to replace them with text and N:links but local copies of the remote resources are also acceptable as N:long as they don't also make calls to remote services. ... E: tap-plugins-doc: privacy-breach-logo usr/share/doc/tap-plugins/html/index.html ... N:Please replace any scripts, images, or other remote resources with N:non-remote resources. It is preferable to replace them with text and N:links but local copies of the remote resources are also acceptable as N:long as they don't also make calls to remote services. ... Simply removing all of it is not the intention of the lintian tag. Please replace the tags which cause the privacy-breach-* tags to be emitted with plain text. Something like the attached patch should do it. Cheers -- Sebastian Ramacher --- tap-plugins-doc-20140526.orig/index.html +++ tap-plugins-doc-20140526/index.html @@ -119,14 +119,11 @@ PURPOSE. Again, see the file COPYING for http://sourceforge.net/donate/index.php?group_id=100722";> -http://sourceforge.net/images/project-support.jpg"; -border="0" alt="Donate to TAP-plugins."> +Donate to TAP-plugins. or http://www.amazon.co.uk/wishlist/8KRTCLLQMIP7";>buy me a gift! (or at least send fan mail) -http://sourceforge.net";>http://sourceforge.net/sflogo.php?group_id=100722&type=5"; -width="210" height="62" border="0" alt="SourceForge.net Logo" /> +http://sourceforge.net";>SourceForge signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
