Bug#750981: ITP: python-memcached -- Pure python memcached client
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-memcached Version : 1.53+2014.06.08.git.918e88c496 Upstream Author : Sean Reifschneider * URL : https://github.com/linsomniac/python-memcached * License : PSF-2 Programming Lang: Python Description : Pure python memcached client This software is a 100% Python interface to the memcached memory cache daemon. It is the client side software which allows storing values in one or more, possibly remote, memcached servers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609090546.32252.46464.report...@buzig.gplhost.com
Re: Bug#750981: ITP: python-memcached -- Pure python memcached client
On 06/09/2014 05:05 PM, Thomas Goirand wrote: > Package: wnpp > Severity: wishlist > Owner: Thomas Goirand > > * Package name: python-memcached > Version : 1.53+2014.06.08.git.918e88c496 > Upstream Author : Sean Reifschneider > * URL : https://github.com/linsomniac/python-memcached > * License : PSF-2 > Programming Lang: Python > Description : Pure python memcached client > > This software is a 100% Python interface to the memcached memory cache > daemon. > It is the client side software which allows storing values in one or more, > possibly remote, memcached servers. This one is already in Debian. However, I got really confused because: https://pypi.python.org/pypi/python-memcached and https://pypi.python.org/pypi/pymemcache So it wasn't clear. Now it is. python-memcache is in fact the Debian module for python-memcached, as I always thought to begin with. Sorry for the noise. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53957a64.5050...@debian.org
Bug#750984: ITP: libjopendocument-java -- pure Java library for OASIS Open Document files manipulation
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil * Package name: libjopendocument-java Version : 1.3 Upstream Author : ILM Informatique * URL : http://www.jopendocument.org * License : GPL Programming Lang: Java Description : pure Java library for OASIS Open Document files manipulation -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609094431.24588.96339.report...@ravel.debian.org
Re: Bug#750546: ITP: sluice -- rate limiting data piping tool
On Wed, Jun 04, 2014 at 11:39:42AM +0100, Colin Ian King wrote: > Package: wnpp > Severity: wishlist > Owner: Colin Ian King > > * Package name: sluice > Version : 0.01.00 > Upstream Author : Colin King > * URL : http://kernel.ubuntu.com/~cking/sluice > * License : GPL-2+ > Programming Lang: C > Description : rate limiting data piping tool > > Sluice reads from standard input and write to standard ^ writes > output at a specified data rate. This can be useful -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609115925.GI21959@tal
status sandbox support in policycoreutils
Hi, debian does not support the, in my opinion, highly useful
"sandbox" tool from selinux package policycoreutils.
It allows, for example, to run a sandboxed instance of a web-browser
with vulnerable plugins with a single line script.
selinux support is currently disabled with patch 0017-no-sandbox ("Do
not build or install sandbox related software, it requires a module
not in refpolicy")
Better SELinux support is a planned feature for debian jessie. Is
there any new development or declaration of intents on resolving bug
#668954 in order to add selinux sandbox support?
"it turns out sandbox REQUIRES the sandbox policy module to work. For
some reason the sandbox policy module isn't included in this package
or in any dependency"
"I can't get the policy for this written for Wheezy. I've attached a policy
patch for a work in progress so anyone who is interested can work on it for
their own purposes.
I'll get this going post-Wheezy with a new policy tree from upstream. For
Wheezy I think I'll just remove the sandbox program from policycoreutils as
there's no way of making it do anything useful."
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cacvd5v+8eukvs5gj-xwnpuhe8mejqanq14tofwvpvioxttg...@mail.gmail.com
Re: status sandbox support in policycoreutils
Keivan Motavalli wrote:
> Hi, debian does not support the, in my opinion, highly useful
> "sandbox" tool from selinux package policycoreutils.
>
> It allows, for example, to run a sandboxed instance of a web-browser
> with vulnerable plugins with a single line script.
>
> selinux support is currently disabled with patch 0017-no-sandbox ("Do
> not build or install sandbox related software, it requires a module
> not in refpolicy")
>
> Better SELinux support is a planned feature for debian jessie. Is
> there any new development or declaration of intents on resolving bug
> #668954 in order to add selinux sandbox support?
Hi,
If I'm not wrong, the "sandbox" policy module has been written by Red
Hat people but was never merged upstream for some reasons.
We tried really hard in the last months to reduce the number of patches
applied to the policy in debian and to always try get the patches merged
upstream first. I personally don't really want to go back to a
situation where we have to carry 100+ patches in the debian package. If
you are really interested in this, you should probably try to see with
upstream if the situation can be unblocked on their side.
Regarding the sandbox executables in policycoreutils, the current
version we have in debian is affected by CVE-2014-3215, this should
already be fixed in the upstream git repository, but I would prefer see
them make a new release before I would even consider re-enabling the
tool (note that the seunshare tool is setuid).
Cheers,
Laurent Bigonville
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140609210702.12b9b...@fornost.bigon.be
dh_shlibdeps warnings on buildd about undefined OpenMP symbols
Hi, In healpix-cxx, I'm getting warnings from dh_shlibdeps about missing OpenMP symbols. See, for example, this excerpt from https://buildd.debian.org/status/fetch.php?pkg=healpix-cxx&arch=i386&ver=3.11.2-6&stamp=1401836504: > dpkg-shlibdeps: warning: symbol GOMP_critical_end used by > debian/libhealpix-cxx0/usr/lib/i386-linux-gnu/libhealpix_cxx.so.0.0.0 found > in none of the libraries > dpkg-shlibdeps: warning: symbol GOMP_loop_end used by > debian/libhealpix-cxx0/usr/lib/i386-linux-gnu/libhealpix_cxx.so.0.0.0 found > in none of the libraries > dpkg-shlibdeps: warning: symbol omp_get_wtime used by > debian/libhealpix-cxx0/usr/lib/i386-linux-gnu/libhealpix_cxx.so.0.0.0 found > in none of the libraries > ... Furthermore, the package built by the buildd is missing a dependency on libgomp1: https://packages.debian.org/sid/libhealpix-cxx0 However, when I build the package on my own box, I get no such warnings. In fact, if I run dh_shlibdeps verbosely, I see that it is correctly detecting the libgomp.so. It also correctly adds a dependency on libgomp1. > dh_shlibdeps -- --warnings=7 -v > >> Scanning > >> debian/libhealpix-cxx0/usr/lib/x86_64-linux-gnu/libhealpix_cxx.so.0.0.0 > >> (for Depends field) > Library libcfitsio.so.3 found in /usr/lib/x86_64-linux-gnu/libcfitsio.so.3 > Library libpthread.so.0 found in /lib/x86_64-linux-gnu/libpthread.so.0 > Library libstdc++.so.6 found in /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > Library libm.so.6 found in /lib/x86_64-linux-gnu/libm.so.6 > Library libc.so.6 found in /lib/x86_64-linux-gnu/libc.so.6 > Library libgcc_s.so.1 found in /lib/x86_64-linux-gnu/libgcc_s.so.1 > Library libgomp.so.1 found in /usr/lib/x86_64-linux-gnu/libgomp.so.1 > Using symbols file /var/lib/dpkg/info/libc6:amd64.symbols for libpthread.so.0 > Using symbols file /var/lib/dpkg/info/libgomp1:amd64.symbols for libgomp.so.1 > Using symbols file /var/lib/dpkg/info/libstdc++6:amd64.symbols for > libstdc++.so.6 > Using symbols file /var/lib/dpkg/info/libc6:amd64.symbols for libc.so.6 > Using symbols file /var/lib/dpkg/info/libc6:amd64.symbols for libm.so.6 > Using symbols file /var/lib/dpkg/info/libgcc1:amd64.symbols for libgcc_s.so.1 > Using symbols file /var/lib/dpkg/info/libcfitsio3:amd64.symbols for > libcfitsio.so.3 It even works when I build with pbuilder on my own machine. I found an earlier thread that may be related: https://lists.debian.org/debian-devel/2011/03/msg01198.html In the end, it seems like the suggestion there is to make certain that -fopenmp flag is being passed when linking: > You normally don't (need to) link to gomp explicitly. My wild guess is: > Dmitry used -fopenmp while compiling *.o, but not when linking the shared > library. What have I missed? Thanks, Leo Singer Graduate Student @ LIGO-Caltech -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5f61c946-eeb8-4269-adf7-b19106621...@ligo.org
Re: Bug#750817: ITP: x265 -- x265 HEVC Encoder
On Sun, Jun 8, 2014 at 4:25 AM, Andrei POPESCU wrote: > Control: reassign -1 wnpp > > On Sb, 07 iun 14, 08:47:41, Rico Tzschichholz wrote: >> Package: x265 >> Severity: wishlist >> >> Package: wnpp >> Severity: wishlist >> >> >> Package name: x265 >> URL : https://bitbucket.org/multicoreware/x265/wiki/Home >> License : GPL2, BSD >> Description : free library for encoding H265/HEVC video streams. This package is going to be maintained under the pkg-multimedia umbrella. Since this package is probably going to be similar to x264, I guess it's easiest to track the github mirror of the upstream mercurial repo. It seems that there is no upstream mailing list, nor other way to contact the upstream devs at this point. Luca, can you confirm or correct this? I took a first look at the package, and it builds a shared library by default (good). Unfortunately, it doesn't provide a proper SONAME: $ objdump -p libx265.so | grep SONAME SONAME libx265.so This makes me wonder if it's worth building it as shared library in debian as this point, or if we wouldn't be better of with a static library only. I wonder what is upstream's take on this? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0ccea_9c2cp63W5eDvz82XbHGg=-6z2u1j14v1a9qgvoq...@mail.gmail.com
Re: Bug#750817: ITP: x265 -- x265 HEVC Encoder
On 10/06/14 02:06, Reinhard Tartler wrote: > On Sun, Jun 8, 2014 at 4:25 AM, Andrei POPESCU > wrote: >> Control: reassign -1 wnpp >> >> On Sb, 07 iun 14, 08:47:41, Rico Tzschichholz wrote: >>> Package: x265 >>> Severity: wishlist >>> >>> Package: wnpp >>> Severity: wishlist >>> >>> >>> Package name: x265 >>> URL : https://bitbucket.org/multicoreware/x265/wiki/Home >>> License : GPL2, BSD >>> Description : free library for encoding H265/HEVC video streams. > > This package is going to be maintained under the pkg-multimedia umbrella. > > Since this package is probably going to be similar to x264, I guess > it's easiest to track the github mirror of the upstream mercurial > repo. +1 > It seems that there is no upstream mailing list, nor other way to > contact the upstream devs at this point. Luca, can you confirm or > correct this? I'm quite sure there is a mailing list. https://mailman.videolan.org/listinfo/x265-devel > I took a first look at the package, and it builds a shared library by > default (good). Unfortunately, it doesn't provide a proper SONAME: > > $ objdump -p libx265.so | grep SONAME > SONAME libx265.so > > This makes me wonder if it's worth building it as shared library in > debian as this point, or if we wouldn't be better of with a static > library only. I wonder what is upstream's take on this? Upstream should be notified, I'd advise to just provide the static library given the kind of usecase. lu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53965f41.7070...@gentoo.org
Re: Bug#751031: RFP: maxemumtvguide -- Maxemum TV-Guide, a Qt5 based TV-Guide
Control: reassign -1 wnpp Control: severity -1 wishlist On Lu, 09 iun 14, 19:50:27, Robert Maxe wrote: > Package: maxemumtvguide > Severity: /wishlist/ > Download: http://sourceforge.net/projects/mtvg/files/mtvg/14.0.0/ > License: GPLv3 > > Maxemum TV-Guide is a Qt5 based TV-Guide. It is developed in C++ and uses > XMLTV to grab listings. > Some of Maxemum TV-Guide's features are: > * easy-to-use user interface > * quick channel(s)-only selection > * custom channel names and icons > * category filter > * title-, actor- and description search > * hidden in tray while not used > * favourite show highlighting > * realtime progress with colour encoded time > * trigger grabbing of TV-listings > * a popup window alerting the user when favourite show starts > * favourite overview with quick removal > * and more.. > -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
