Package: wnpp
Severity: wishlist
Owner: Diego Sarzi
* Package name: tubedown
Version : 1.0-1
Upstream Author : Diego Sarzi
* URL : https://github.com/gnewlinux/python/tree/master/tubedown
* License : GPL3
Programming Lang: Python
Description : Download
Ritesh Raj Sarraf writes:
> To quote upstream:
> It embeds libfuse because:
>
> I support many old platforms which use old and buggy versions of
> libfuse. Embedding it keeps many of my users who don't know and don't
> care to know how to update their systems from having to learn to build
> libfu
mergerfs is a fuse based file system, similar in functionality to aufs
and overlayfs.
Since version 2.22.0, mergerfs is embedding the libfuse2 library in its
source repo. Details can be seen in this bug report upstream at Github:
https://github.com/trapexit/mergerfs/issues/431
So far upstream has
Howdy all,
I have released version 1.0.0 to Debian Experimental, and it now needs
plenty of testing to find regressions from earlier behaviour.
This release represents a culmination of carefully preserving the
existing behavior while porting the code base to Python 3, ahead of the
deprecation of
The "old" methods for changing the default umask no longer work in Debian
Stretch.
It appears systemd now manages umask. Can someone please describe how I can
change the default umask setting in Stretch?
On Thu, Aug 03, 2017 at 05:57:01PM -0400, Matthias Klose wrote:
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be
> done
> to deprecate Python2 usage within the distribution. It might not be possible
> to
> drop Python2 for the next release, but there are still too ma
Hi Matthias,
On 08/03/2017 11:57 PM, Matthias Klose wrote:
> It might not be possible to drop Python2 for the next release,
Even if all Python-related packages in Debian were compatible with
Python3, I don't think it's a good idea to drop Python2 support in
Buster, there are still far too many th
On 08/05/2017 07:34 AM, Josh Triplett wrote:
> Scott Kitterman wrote:
>> Reintroducing /usr/bin/python as a python3 version risks their systems
>> for no benefit (since all python3 stuff points to /usr/bin/python3 and
>> works fine). Just let it go and don't bring it back.
>
> Agreed completely.
On Thu, Aug 03, 2017 at 05:57:01PM -0400, Matthias Klose wrote:
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be
> done
> to deprecate Python2 usage within the distribution. It might not be possible
> to
> drop Python2 for the next release, but there are still too ma
On Sun, 06 Aug 2017 12:04:19 -0700, Josh Triplett wrote:
> Anyone interested in helping with continued support for classic window
> managers should consider working on packaging for
> https://wiki.archlinux.org/index.php/Xdg-menu , and perhaps forming a
> maintenance team for it. And if it doesn't
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: lightdm-autologin-greeter
Version : 1.0
Upstream Author : Enrico Zini
* URL : https://github.com/spanezz/lightdm-autologin-greeter
* License : Expat
Programming Lang: Python
Description
On Sat, Aug 05, 2017 at 04:22:03PM -0400, gregor herrmann wrote:
> > So, if you want to count votes: I am working in teams (mainly Debian
> > Astro), and I would favour keeping it --
>
> Perfectly fine, thanks for adding your point of view.
>
> (And just to be sure: The proposal is not to forbid
Anyone interested in helping with continued support for classic window
managers should consider working on packaging for
https://wiki.archlinux.org/index.php/Xdg-menu , and perhaps forming a
maintenance team for it. And if it doesn't support your window manager
or desktop of choice, consider adding
Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze
* Package name: libjs-jquery-blockui
Version : 2.70
Upstream Author : Mike Alsup
* URL : http://malsup.com/jquery/block/
* License : GPL-2 or Expat
Programming Lang: Javascript
Description : simulat
Excerpts from intrigeri's message of 2017-08-04 19:31:36 -0400:
> - Apparently Ubuntu users have been coping with AppArmor enforced
>by default for 9 years. I see no reason why Debian users would not.
>
This is really important. A few packages in Ubuntu largely differ from
Debian because the
Hi,
I am looking into switching apache2/libapr/libaprutil from explicit -dbg
packages to the automatic dbgsym packages. And since I have included a
README.backtrace in apache2, I wonder how one describes to a sysadmin that
has no clue about software development which dbgsym packages they need t
On 08/06/2017 05:32 PM, intrigeri wrote:
> Moritz Mühlenhoff:
>> If one of those profiles relies on features which are not upstreamed
>> on the kernel end, how's that handled?
>
> Rules that are not supported by the running kernel are silently
> ignored, i.e. the operation is allowed.
Is there at
On Sun, 2017-08-06 at 17:27 +0200, Adam Borowski wrote:
> On Sun, Aug 06, 2017 at 09:16:48AM +0100, Ian Campbell wrote:
> > What is the expected interaction with the hwcaps based library
> > installed paths? (/usr/lib/i386-linux-gnu/i686/{sse2,cmov}).
> > Presumably
> > libraries would still be exp
On Sat, Aug 05, 2017 at 06:38:15PM +, Holger Levsen wrote:
> > It is the official place to list co-maintainers.
>
> you keep repeating this but its still broken by design.
>
> > > ;tl;dr: I think we need a better system to manage team membership in
> > > Debian.
> > > (Ab)using the uploaders
Hi,
Moritz Mühlenhoff:
> I'd expect that a lot of the AppArmor profiles currently in use are
> coming from Ubuntu or OpenSUSE.
Yes, historically (most of them are now maintained via a cross-distro
collaborative effort that a few Debian people participate in).
> If one of those profiles relies on
On Sun, Aug 06, 2017 at 09:16:48AM +0100, Ian Campbell wrote:
> What is the expected interaction with the hwcaps based library
> installed paths? (/usr/lib/i386-linux-gnu/i686/{sse2,cmov}). Presumably
> libraries would still be expected to use those as appropriate?
hwcaps implies runtime detection
Dr. Bas Wijnen:
> Enabling it by default doesn't mean it can't be switched off, right?
Yes, passing apparmor=0 on the kernel command line will turn it off.
Cheers,
--
intrigeri
Your message dated Sun, 06 Aug 2017 15:19:37 +0100
with message-id <1502029177.2701.51.ca...@decadent.org.uk>
and subject line Re: Bug#870913: general: IPv6 tunnel on host machine and
container
has caused the Debian Bug report #870913,
regarding general: IPv6 tunnel on host machine and container
t
Control: tag -1 moreinfo
On Sun, 2017-08-06 at 14:12 +0200, ThYjp1b6mLxb2551TYsc wrote:
> Package: general
> Severity: normal
>
> Hi, if I setup a IPv6 tunnel over IPv4 on my machine and after setup
> IPv6 tunnel on a systemd-nspawn container, I can use IPv6 on my machine
> but not in container.
Processing control commands:
> tag -1 moreinfo
Bug #870913 [general] general: IPv6 tunnel on host machine and container
Added tag(s) moreinfo.
--
870913: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870913
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
On Sun, Aug 06, 2017 at 09:54:01AM -0400, Didier 'OdyX' Raboud wrote:
> The next step is that this policy change is likely to find its way as a
> Lintian
> warning (or error).
The same lintian tag that has been around since Oct 2015?
https://lintian.debian.org/tags/command-in-menu-file-and-deskt
For further reference, the full TC decision text is at:
[0] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html
Le dimanche, 6 août 2017, 11.40:26 h EDT Guillem Jover a écrit :
> At this point I guess the decision to cope fairly with such subpar and
> imposed policy that a maintai
Package: wnpp
Severity: wishlist
Owner: =?utf-8?b?T25kxZllaiBLb2JsacW+ZWs=?=
* Package name: python-etcd3
Version : 0.6.2
Upstream Author : Louis Taylor
* URL : https://github.com/kragniz/python-etcd3
* License : Apache-2.0
Programming Lang: Python
Descrip
Package: general
Severity: normal
Hi, if I setup a IPv6 tunnel over IPv4 on my machine and after setup
IPv6 tunnel on a systemd-nspawn container, I can use IPv6 on my machine
but not in container.
Host: /etc/network/interfaces: http://paste.debian.net/plain/980083
Container: /ect/network/interfac
Package: wnpp
Severity: wishlist
Owner: Akihito Nakano
X-Debbugs-CC: debian-devel@lists.debian.org, debian-de...@lists.debian.or.jp
Package name: php7.0-memcached
Version: 3.0.3
Upstream Author: Andrei Zmievski , David Terei
, Ilia Alshanetsky , Mikko
Koppanen , Teddy Grenman
Hi,
On Sat, 2017-08-05 at 18:58:13 -0700, Sean Whitton wrote:
> A.2. Version 4.0.1
>
>Released August, 2017.
[…]
>9.6
>
>Packages installing a Free Desktop entry must not also install a
>Debian menu system entry.
Well this is still such terrible policy, and even
intrigeri schrieb:
> Still, even with the set of features available in mainline Linux
> *today*, IMO enabling AppArmor already has a good cost/benefit ratio
> for Debian and our users. I'm not proposing we apply out-of-tree
> AppArmor kernel patches.
I'd expect that a lot of the AppArmor profiles
On Sun, Aug 06, 2017 at 07:28:08AM +, Dr. Bas Wijnen wrote:
> I can't think of a situation where you would not want it
The "I don't want yet another thing that can cause subtle breakages and
doesn't give me anything" situation (see disabling selinux after install
on RH systems).
--
WBR, wRAR
On Sun, 2017-08-06 at 01:13 +0200, Adam Borowski wrote:
>
> As for a foreign machine:
> * ISA_IGNORE=y apt install »package«
How about:
ASSUME_ISAS=sse2 apt install »package«
i.e. with the ability to specify the set you expect/know that the
target machine will have. It could support "all" as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Aug 05, 2017 at 06:28:20PM +0200, Christoph Biedl wrote:
> intrigeri wrote...
>
> > tl;dr: I hereby propose we enable AppArmor by default in testing/sid,
> > and decide one year later if we want to keep it this way in the
> > Buster release.
>
35 matches
Mail list logo
