Bug#757772: RFP: widevineplugin-nonfree: Widevine DRM Plugin - browser plugin
Hi, Arch now has a script to install the plugin correctly for chromium (extract it first from the chrome binaries and then copying it to the correct place): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chromium-widevine Maybe this thing here is also important for the chromium maintainers: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1371274
Bug#774387: ITP: letsencrypt -- Let's Encrypt client that can update Apache configurations
Hi,
it seems your package doesn't build in pbuilder:
fakeroot debian/rules clean
dh clean --with python2,sphinxdoc --buildsystem=pybuild
dh_testdir -O--buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python2.7 setup.py clean
Traceback (most recent call last):
File "setup.py", line 2, in
from setuptools import setup
ImportError: No module named setuptools
E: pybuild pybuild:262: clean: plugin distutils failed with: exit code=1:
python2.7 setup.py clean
dh_auto_clean: pybuild --clean --test-tox -i python{version} -p 2.7 --dir .
returned exit code 13
debian/rules:9: recipe for target 'clean' failed
Adding python-setuptools to the build-depends seems to fix it. Not sure if it
is the correct solution.
The next problem is
/tmp/buildd/letsencrypt-0.20150321/docs/api/client/CONFIG.rst:4: WARNING:
autodoc: failed to import module u'letsencrypt.client.CONFIG'; the following
exception was raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 335, in
import_object
__import__(self.modname)
[...]
find /tmp/buildd/letsencrypt-0.20150321/debian/doc-build/html/ -type f -name
'*.html' \
-exec sed -i -e
's|https://cdnjs.cloudflare.com/ajax/libs/modernizr/.*/modernizr.min.js|../../../javascript/modernizr/modernizr.min.js|'
'{}' +
sed -i -e 's|https://travis-ci.org/letsencrypt/lets-encrypt-preview.svg?branch=master";
/>|Travis CI status|'
/tmp/buildd/letsencrypt-0.20150321/debian/doc-build/html/intro.html
sed: can't read
/tmp/buildd/letsencrypt-0.20150321/debian/doc-build/html/intro.html: No such
file or directory
debian/rules:16: recipe for target 'override_dh_auto_build' failed
I have not tried to fix this.
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/479143243.506801.1438524872501.javamail.ya...@mail.yahoo.com
Bug#757772: RFP: widevineplugin-nonfree: Widevine DRM Plugin - browser plugin
Package: wnpp Severity: wishlist Package name: widevineplugin-nonfree URL: https://tools.google.com/dlpage/widevine License: proprietary non-free The google chrome version 38 now provides libwidevinecdm.so and libwidevinecdmadapter.so which are (pepper?) plugins used to view things like Netflix through their HTML5 player [1]. It may need a package like pepperflashplugin-nonfree which has a script to automatically extract the plugins and installs it to the right place. [1] http://www.phoronix.com/scan.php?page=news_item&px=MTc1ODY -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1407749895.56255.yahoomail...@web133201.mail.ir2.yahoo.com
Bug#729203: libav: Doesn't decode opus while opus support is compiled in?
> $ avprobe -codecs | grep Opus > avprobe version 9.8-6:9.8-2, Copyright (c) >2007-2013 the Libav developers > built on Aug 13 2013 21:50:46 with gcc 4.8 >(Debian 4.8.1-8) > DEA.L. opus Opus (Opus Interactive Audio >Codec) (decoders: libopus ) (encoders: libopus ) > $ avprobe somefile.opus > avprobe version 9.8-6:9.8-2, Copyright (c) 2007-2013 the Libav developers > built on Aug 13 2013 21:50:46 with gcc 4.8 (Debian 4.8.1-8) > [ogg @ 0xc40460] Codec not found > somefile.opus: End of file Really, this libav is a shame. This doesn't happen with the actual libav* from ffmpeg. Now I have a lot of tools in Debian which I need to use to get some work done... and they just fail again, again and again because libav. Can we really drop this buggy fork called 'libav' and go back to ffmpeg.. or at least allow users to switch to a working libav*? See also bug #729203 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1386729198.93055.yahoomail...@web171904.mail.ir2.yahoo.com
Bug#731070: RFP: PySDL2 -- Python wrapper around SDL2 using ctypes
Package: wnpp Severity: wishlist Cc: debian-pyt...@lists.debian.org, debian-devel-ga...@lists.debian.org * Package name : pysdl2 Version : 0.7.0 Upstream Author : Marcus von Appen * URL : https://bitbucket.org/marcusva/py-sdl2/ * License : public domain OR zlib (see doc/copying.rst) Programming Lang: Python Description : SDL2 bindings for Python These are bindings for SDL2 for python with some benefits compared to the old SDL1.2 wrapper by pygame (no c code, license either public domain or zlib). -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385914926.93124.yahoomail...@web171904.mail.ir2.yahoo.com
Bug#637771: RFP: wxmupen64plus -- Mupen64Plus 2.0 GUI frontend written using wxWidgets
The upstream project is already dead. Here a quote from the maintainer
{Saturday, October 26, 2013} [21:14:27] I don't really have
time/interest anymore to properly develop wxMupen64Plus, unfortunately.
It wasn't working since a while with the mupen64plus version in debian and the
author started to to make it incompatible with mupen64plus 2.0 by purpose in
the past by making it mupen64plus 1.99.5 exclusive. It is most likely better to
just close this bug and move on to m64py [1].
I've already saw m64py packages on git.debian.org (server seems to be down
right now) and it only needs pysdl2 packaged in Debian.
[1] http://bugs.debian.org/678947
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1384620828.12249.yahoomail...@web171905.mail.ir2.yahoo.com
Bug#703519: sddm -- QML based login manager
On Tuesday 11 June 2013 16:47:36 you wrote: > This package has been uploaded to mentors and is in need of a mentor You have to create a bug for the pseudo package sponsorship-requests [1] and add a blocked for this bug by the sponsorship-requests bug Btw. I cannot find the sddm package on mentors. I was also not able to find the packaging repo on http://anonscm.debian.org [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=sponsorship-requests -- Franz Schrober -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/39279944.8PxVhZCkuW@bentobox
Bug#697840: RFP: python-pillow -- Python Imaging Library (fork)
> Pillow is the "friendly" PIL fork. PIL is the Python Imaging Library. > Pillow was started for and is currently maintained by the Plone > community. But it is used by many other folks in the Python web > community, and probably elsewhere too. I thought "python-imaging" is just this Pillow fork. At least the changelog says so "Pillow 2.0.0 release". But webp support would be extremely nice. At least the code is there but it seem Matthias Klose decided to disable it for some reason. -- Franz Schrober -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1480979.Na7fRTsIvy@bentobox
Bug#678947: RFP: M64Py -- Mupen64Plus 2.0 GUI frontend written in python
On Sunday 19 August 2012 04:14:28 dancingmad...@gmail.com wrote: > Another Mupen GUI, another failure, why cant anyone just recode the old > GUI and dump these new ones that dont work? These GUIs try to "recode" the old GUI. So what is your problem? And did you report the problems to the upstream projects? Otherwise I will just ignore your complaints because they aren't valid. -- Franz Schrober -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1592950.8N33aA5cR0@bentobox
Bug#587062: Re: exactimage: file format misdetection
On Thursday 28 June 2012 00:16:03 you wrote: > Hi, > > > Can you please coordinate your quest in http://bugs.debian.org/587062 > > Thanks a lot for a note. I have no intention to become the maintainer of > this package. I've just prepared the QA upload. See my RFS: > http://bugs.debian.org/679321 > > (Unfortunately I have no access to collab-maint yet, and I cannot commit to > it directly. So I prepared the package in usual way.) Everyone can get an account by visiting the alioth register page [1] and selecting "request to join" on the collab-maint [2] project. [1] https://alioth.debian.org/account/register.php [2] https://alioth.debian.org/projects/collab-maint/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1577490.dfuqje3...@sven-desktop.home.narfation.org
Bug#587062: Re: RFS: exactimage/0.8.7-1 [QA] -- fast image manipulation programs
On Wednesday 27 June 2012 23:18:14 Schrober wrote: > On Wednesday 27 June 2012 23:51:01 you wrote: > > Package: sponsorship-requests > > Severity: normal > > X-Debbugs-Cc: debian...@lists.debian.org > > > > Hi, > > > > I am looking for a sponsor for the package "exactimage". > > > > It builds those binary packages: > > edisplay - fast image manipulation programs (image viewer) > > exactimage - fast image manipulation programs > > exactimage-dbg - fast image manipulation library (debug symbols) > > libexactimage-perl - fast image manipulation library (Perl bindings) > > php5-exactimage - fast image manipulation library (PHP bindings) > > python-exactimage - fast image manipulation library (Python bindings) > > > > To access further information about this package, please visit the > > following URL: http://mentors.debian.net/package/exactimage > > > > Direct link for download: > > > > http://mentors.debian.net/debian/pool/main/e/exactimage/exactimage_0.8.7-1 > > . > > dsc > > > > Changes in the package: > > > > exactimage (0.8.7-1) unstable; urgency=low > > > > * QA upload. > > * Update to stable release 0.8.7. And why do you update to a new upstream version in an QA upload anyway? It the task of the ITA owner and not yours -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4670416.ripjvge...@sven-desktop.home.narfation.org
Bug#587062: Re: exactimage: file format misdetection
On Wednesday 27 June 2012 23:06:26 you wrote: > Current version of program in Wheeze has no this bug. Thanks. Can you please coordinate your quest in http://bugs.debian.org/587062 The new version is already packaged in the experimental branch of http://anonscm.debian.org/gitweb/?p=collab-maint/exactimage.git -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1353220.0hqdeq3...@sven-desktop.home.narfation.org
Bug#678947: Re: RFP: M64Py -- Mupen64Plus 2.0 GUI frontend written in python
On Monday 25 June 2012 21:34:06 Milan Nikolic wrote: > Well, some of that can surely be fixed. I am not much of an expert when it > comes to licenses but I believe I don't need source for test rom included, > about dialog has author mentioned, links to GPL licenses and link to > mupen64plus site where one can download source. All that info can just be > copied to file. No, you need to provide the sources and don't ship the prebuild binary to make the Debian ftpmasters happy (ok, you can also stop to ship it at all). Otherwise the maintainers have to remove it and create a new dfsg tarball like it was done with mupen64plus 1.5. * http://anonscm.debian.org/gitweb/?p=collab- maint/mupen64plus.git;a=blob;f=debian/README.Debian- source;h=bb3716ed75dc38db74aae6d4be36c15d6014dfca;hb=4e1d40f8087790ab9a393aee5361828bc8fc107a * http://lists.debian.org/debian-legal/2009/06/msg2.html This is also the reason why Richard provides a tarball on bitbucket that has the rom removed. Btw. why do you ship it at all? It should be part of mupen64plus-core when the distribution allows to ship or the user downloaded it manually... otherwise it is just the same crap as before and it has to be removed anyway. > Pygame ctypes code is included because I could not do what I wanted with > pygames (there is no way to call SDL_JoystickUpdate, it does that > automatically) and it has same SDL api, I forgot later to include author. > But this is first release, and there are mistakes, my intention was not to > still anybodies code :) Why don't you just move to the new fork of PySDL and leave it outside of M64Py? It is extreme ugly for distributions to have code inside a project that should be separated. Just imagine that there is a security bug in one of those included libraries that is used by 90% of the distribution and the distribution maintainers have to change each package by hand. > Yes, icons are randomly picked from google images, for many of them I am not > sure where I got them. If someone can replace them with some proper ones > from known icon sets that would be great. Current ones are not that good > anyway and they don't go together. Mupen64Plus logo is also work of > mupen64plus developers. No, the logo is work done by Scott 'Tillin9' Knauert and he licensed it under the CC-BY-SA-3.0. Maybe you should now start to read the license text > As for screenshots, I don't understand who can holds rights for screenshots > and how come they are not free, but as I said, I am not an expert... > Anyway, I can provide tarball with png images for download, deb package can > patch/remove those and offer users to download tarball they can unpack to > UserData dir, M64Py first checks there to see if image exists. No, it is a composition of work done by other people. Therefore, it is a derivated work. I doubt that you got any license aggreement with the original authors that would make it suitable for Debian to ship this stuff. And is really hard for you to proof that you add enough new creativity to make this your work under the big topic "artistic freedom". -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4759491.mrmwepf...@sven-desktop.home.narfation.org
Bug#678947: RFP: M64Py -- Mupen64Plus 2.0 GUI frontend written in python
Package: wnpp Severity: wishlist * Package name: M64Py Version : 0.1.0 Upstream Author : Milan Nikolic * URL : http://m64py.sourceforge.net/ * License : GPL3+, BSD3 Programming Lang: Python Description : Mupen64Plus 2.0 GUI frontend written in python M64Py seems to be the only (good) GUI for mupen64plus 2.0 that can be run on Debian. The other good one (see bug #637771) has dependencies to wxwidgets 2.9. I think it has to be fixed for distribution (files generated by PyQt4, included source from pygames, unfree resources/screenshots, prebuild demo rom, also the source code is missing for rom, logo that was created using two other logos but ignoring their license, all other icons seem to be taken from somewhere else without giving license/copyright information, ...). I think it is also missing the debugger part from wxmupen64plus -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1340618421.51688.yahoomail...@web29401.mail.ird.yahoo.com
