Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-dimred
Version : 0.1.0
Upstream Author : Guido Kraemer
* URL : https://cran.r-project.org/package=dimRed
* License : GPL
Programming Lang: GNU R
Description : GNU R framework
Package: wnpp
Severity: wishlist
Owner: =?utf-8?b?T25kxZllaiBOb3bDvQ==?=
* Package name: tldr-py
Version : 0.7.0
Upstream Author : lord63
* URL : https://github.com/lord63/tldr.py
* License : MIT
Programming Lang: Python
Description : python client for
On 2017-11-28 20:22, Russ Allbery wrote:
> My personal pet "I don't have time" project I'd love to see is extending
> systemd units for as many services in Debian as possible to include
> namespace restrictions and seccomp filter rules,
Hear, hear!
Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves
Package name: memleax
Version : 1.0.3
Upstream Author : WuBingzheng
URL : https://github.com/WuBingzheng/memleax
License : GPL-2
Programming Lang: C
Description : debug a running process for memoy leak
On 2017-11-28.19:54, Christoph Hellwig wrote:
> It's just a bad idea of a security model that implements ad-hoc
> and mostly path based restrictions instead of an actually verified
> security model. Using that by default makes it much harder to actually
> use a real MAC based security model, which
On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
Maybe SELinux would be better, but various people have been trying to make
SELinux better-integrated with Debian for quite some time, and those
efforts don't seem to have been particularly successful.
Well, maybe it should just be tu
On Wed, 29 Nov 2017 at 22:10:03 +1100, Scott Leggett wrote:
> > It's just a bad idea of a security model that implements ad-hoc
> > and mostly path based restrictions instead of an actually verified
> > security model. Using that by default makes it much harder to actually
> > use a real MAC based
On 29/11/17 13:04, Michael Stone wrote:
> On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
>> Maybe SELinux would be better, but various people have been trying to make
>> SELinux better-integrated with Debian for quite some time, and those
>> efforts don't seem to have been particular
On Wed, Nov 29, 2017 at 01:17:26PM +0100, Emilio Pozuelo Monfort wrote:
On 29/11/17 13:04, Michael Stone wrote:
On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
Maybe SELinux would be better, but various people have been trying to make
SELinux better-integrated with Debian for quit
Hi,
Michael Stone:
> On Wed, Nov 29, 2017 at 01:17:26PM +0100, Emilio Pozuelo Monfort wrote:
>>Nobody said problems are going to magically go away by enabling apparmor.
>>OTOH,
>>we won't know to what extent problems exists until it gets enabled everywhere.
> Exactly the same argument can be mad
On Wed, Nov 29, 2017 at 07:26:26AM -0500, Michael Stone wrote:
> Exactly the same argument can be made for selinux. But for some reason just
> turning on selinux by default to fix everything wasn't a good solution, but
> turning on apparmor for the same reason is. I'm trying to understand this
> lo
On 11/29/2017 1:08 PM, Simon McVittie wrote:
> I don't see why it isn't a MAC implementation. However, the comment about
> not having a "real" security model seems valid. The way AppArmor is used
> in practice is often more like hardening than a coherent security model:
> when an app was not design
On 11/23/2017 03:01 PM, Christoph Hellwig wrote:
> ... Looks like someone in
> Debian just decided to make apparmor the default, which is horrible
> news :(
This is actually a fantastic news. Hopefully, it will turn out to just
work without too much hassle.
Thanks Ben for doing this, and everyon
On 2017-11-29 09:25, Jonathan Dowland wrote:
On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
My personal pet "I don't have time" project I'd love to see is extending
systemd units for as many services in Debian as possible to include
namespace restrictions and seccomp filter rules,
Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla''
* Package name: proxmoxer
Version : 1.0.0
Upstream Author : Oleg Butovich
* URL : https://github.com/swayf/proxmoxer
* License : MIT
Programming Lang: Python
Description : Python Wrapper for
Michael Stone writes:
> On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
>> Ubuntu has successfully shipped with AppArmor enabled.
> For all the packages in debian? Cool! That will save a lot of work.
Yes? I mean, most of them don't have rules, so it doesn't do anything,
but that'
]] intrigeri
> Regarding RC bugs: I don't think breakage that only happens with
> AppArmor enabled should be RC in the context of the experiment we're
> currently running: in the vast majority of cases, a local workaround
> is available (one can disable the faulty AppArmor profile with the
> aa-d
On Mon, Nov 20, 2017 at 01:20:06PM +, Ian Jackson wrote:
>...
> I would much rather have a minimally maintained package, from Debian,
> in my stable release, than have to roll my own. This is particularly
> true if I don't know yet whether the thing is what I want. Trying
> something out from
Vincas Dargis writes:
> Since mentioned, I would like that these daemons would implement seccomp
> filtering themselves, meaning like within application itself, using
> libeseccomp. Thy can fine-grain what thread what syscalls can make.
Yes, this is potentially even better. But there are cases
Package: general
Severity: wishlist
Dear Maintainers,
I propose to add new package header Upstream-Version: to contain the
version
as of the upstream of the package.
The header should be optional because not every package has a definite
upstream version.
I am writing software which should call
Package: general
Severity: wishlist
Dear Maintainers,
I propose to add new package header Upstream-Version: to contain the version
as of the upstream of the package.
The header should be optional because not every package has a definite
upstream version.
I am writing software which should call
Package: wnpp
Severity: wishlist
Owner: Boyuan Yang <073p...@gmail.com>
X-Debbugs-CC: debian-devel@lists.debian.org
pkg-deepin-de...@lists.alioth.debian.org
* Package name: deepin-shortcut-viewer
Version : 1.3.3
Upstream Author : Deepin Technology Co., Ltd.
* URL : htt
On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> Hi,
>
> Sorry for the rejection but "Copyright: See individual source files"
> unfortunatley does not meet the high standards we strive for within Debian.
That is odd. It has been accepted for over 16 years. What has changed?
Processing commands for cont...@bugs.debian.org:
> merge 883133 883134
Bug #883133 [general] general: Add new package header Upstream-Version:
Bug #883134 [general] general: Add new package header Upstream-Version:
Merged 883133 883134
> thanks
Stopping processing here.
Please contact me if you n
24 matches
Mail list logo
