Processed: merging 883133 883134

[Debian Bug Tracking System]

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 need assistance.
-- 
883133: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883133
883134: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883134
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

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?   

It is useful to me that the debian/copyright file contain the distribution 
license.  For a one-author package, it could even be convenient to describe 
the author and copyright.

But for a massive multi-author, multi-year work like Boost, there seems very 
little value in summarizing copyrights.  Boost has nearly 55000 files in the 
source distribution.  What could one possibly achieve by summarizing this?  
How would anyone even read and make sense of it?

Has copyright summarizing outlived its usefulness for large sources?  Why 
shouldn't we have some way to say "Copyright by the Boost authors"?

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#883135: ITP: deepin-shortcut-viewer -- Pop-up shortcut viewer for Deepin applications

[Boyuan Yang]

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 : https://github.com/linuxdeepin/deepin-shortcut-viewer
* License : GPL-3+
  Programming Lang: C++/Qt
  Description : Pop-up shortcut viewer for Deepin applications

Deepin-shortcut-viewer is a standalone binary that helps Deepin applications
pop up their shortcut information on screen in a unified appearance.

It is part of Deepin software and DDE (Deepin Desktop Environment).

I intend to co-maintain it in pkg-deepin group.

Regards,
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Bug#883134: general: Add new package header Upstream-Version:

[Victor Porton]

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 a program in specific version range
(or fail to call it if the program in this version range is not installed).
It should work for Debian and other systems (so I can use only the upstream
version, not Debian version as is, to be compatible with other systems).

Adding this header would ease the task to extract the upstream version of a
specific package.

It is possible now, but the algorithm of extracting the version of upstream
may be different for every package. This is no good.

My software should work not only on Debian. So writing a special algorithm
to extract Debian version numbers (instead of simply looking into
Upstream-Version:) is not a good way to do this task.

Somebody, please report a similar idea for Fedora, SUSE and others. (I don't
have it installed and don't know the proper way to report to them.)

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#883133: general: Add new package header Upstream-Version:

[Victor Porton]

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 a program in specific version
range
(or fail to call it if the program in this version range is not
installed).
It should work for Debian and other systems (so I can use only the
upstream
version, not Debian version as is, to be compatible with other
systems).

Adding this header would ease the task to extract the upstream version
of a
specific package.

It is possible now, but the algorithm of extracting the version of
upstream
may be different for every package. This is no good.

My software should work not only on Debian. So writing a special
algorithm
to extract Debian version numbers (instead of simply looking into
Upstream-Version:) is not a good way to do this task.

Somebody, please report a similar idea for Fedora, SUSE and others. (I
don't
have it installed and don't know the proper way to report to them.)

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (500, 'unstable'), (500,
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Russ Allbery]

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 where we can
apply filters that upstream may not be able to assume for various reasons,
and a lot of upstreams who won't be willing to take Linux-specific code
inside the daemon itself.

But this would be fantastic for things like ImageMagick, which are
otherwise a notorious source of RCEs.

Does libeseccomp now have maintained system call classes similar to
systemd?  If we could build a tool that could apply namespace and filter
rules using system call classes like that, it would make it easy to
support similar hardening in sysvinit as well.  Last time I looked at the
various stand-alone jailing utilities like firejail, they seemed to be
missing the nice system call groupings that let you not have to know
exactly what system calls result from standard IO operations, but
hopefully someone has since tackled this.

-- 
Russ Allbery (r...@debian.org)   

Re: Auto-update for sid? Auto-backport?

[Adrian Bunk]

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 "apt-get" in stretch is a lot less work and a lot
> less risky than git cloning some random url and then blundering about
> trying to get the thing going.

20 years ago these discussions were about packaging all of CPAN.
Today the prime example would be the packaging of Node.js modules.

There are more than half a million Node.js modules available.
These could be automatically packaged into half a million
Debian packages.

> I prefer this so much that in some cases I have considered packaging
> the thing myself and becoming one of these "disgrace" maintainers that
> Adrian is complaining about.

You are the kind of maintainer who would at least once per release cycle 
package the latest upstream version and check the bugs.
That's not disgrace, that's average.

There is a problem due to the combination of throwing stuff into
Debian and the tendency of many people in Debian who want to get
rid of everything with low popcon quickly.

And while not always avoidable, the revolving door situation of 
packages in one stable release but not in the next is causing
problems for users.

The lifecycle of such a package is often:
1. package gets ITPed
2. package is part of a stable release
3. package gets orphaned
4. package is removed from unstable

Many people are eager to remove unmaintained low-popcon buggy packages 
from unstable, but often the root of the problem is actually what gets
ITPed into Debian - most of the time the package was not in a better
shape when it entered Debian.

> If I find some undermaintained package in Debian, it nearly always
> works well enough to solve my problem.  And if it doesn't I have a
> uniform way to find the source, somewhere to send my packaging bug
> report, and the opportunity to NMU it if I discover something
> sufficiently bad.

This works nicely for the 0.01% of our users who are DDs.

For the whole range from "typo in the manpage" to "half the 
functionality of the package is broken" one can find plenty
of > 5 year old bugs with patches and zero maintainer reaction
in the BTS.

Sometimes I see bug reports in the BTS where it is evident that a user 
has spent hours or days on debugging an issue and writing a marvelous 
bug report. I read the bug 10 years later with no other message ever
in the bug.

That's sad to read, and a disservice to our users.

I am aware that it is nearly impossible to prevent these from ever
happening[1], but it should be clear that maintaining a package in
general also includes things like handling bugs that get reported.

> Ian.

cu
Adrian

[1] there's real life, and teams with far too few people,
and many other reasons

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: recommends for apparmor in newest linux-image-4.13

[Tollef Fog Heen]

]] 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-disable command).

I think they (in general) should be RC for whatever is shipping the
buggy apparmor profile.

Having packages that are broken out of the box is not the kind of distro
we should be shipping.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: recommends for apparmor in newest linux-image-4.13

[Russ Allbery]

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's how we start.  But indeed, Ubuntu has already done a ton of
work here, so it *does* save us quite a bit of work.

-- 
Russ Allbery (r...@debian.org)   

Bug#883103: ITP: proxmoxer -- Python Wrapper for the Proxmox 2.x API

[Elena ``of Valhalla'']

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 the Proxmox 2.x API

Proxmoxer is a wrapper around the `Proxmox REST API v2
`_
which allows to programmatically create / delete / manage instances of
proxmox managed virtual machines and containers.

It is also used by the proxmox module for ansible 
http://docs.ansible.com/ansible/latest/proxmox_module.html
(and thus a python2 version will be needed, together with the py3 one).

I plan to maintain this package inside the Python Modules Team.

Re: recommends for apparmor in newest linux-image-4.13

[Vincas Dargis]

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, which I think has good
parallel potential alongside an LSM for raising the default security
posture of Debian.  LSMs deal with per-file restrictions much more easily
than systemd's seccomp and namespace support, but the seccomp and
namespace support does a lot of other nice things that LSMs aren't as good
at.


Yes this would be excellent; a necessary prerequisite would be getting
more daemons (and cron-scheduled processes) shipping systemd units too.



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.


For example, some networking, parsing thread might not need execve() at all. Meanwhile, it might be needed for main or 
other thread to call some external application, but that can be later mediated with MAC, is it AppArmor, SELinux or 
whatever.

Re: recommends for apparmor in newest linux-image-4.13

[Thomas Goirand]

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 everyone else involved in apparmor.
Thanks to intri for pushing this too.

Cheers,

Thomas Goirand (zigo)

Re: recommends for apparmor in newest linux-image-4.13

[Philipp Kern]

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 designed to be sandboxed, and an AppArmor profile
> was added later without modifying app code, the profile rules that are
> necessary to make it work are often loose enough to allow privilege
> escalation, particularly for desktop apps that are typically written to
> assume they have full desktop privileges.

Yup. That's a little frustrating. But I don't think people solved this
particular problem for SELinux either, did they? It's a question of
which transitions to allow and how the permission set changes then.

I will point out that seccomp filters have the same problem: You need to
know pretty much exactly what all of the libraries you include do. If
you then happen to be a daemon that loads, say, PAM modules (or other
kinds of modules) you suddenly end up with more calls that you need to
allow and stuff crashes. I think at least debugging might have been
facilitated recently rather than just killing off the program without an
indication of what's wrong. That doesn't preclude daemon maintainers
from writing such a policy but they have to be pretty careful not to
break stuff. People always rant at Chromium because it bundles
everything but such control also allows to write tight filters.

Kind regards
Philipp Kern

Re: recommends for apparmor in newest linux-image-4.13

[Holger Levsen]

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
> logic.
 
oh, that is very simple to answer: noone has proposed doing this for
SELinux, while people have proposed this for AppArmor.

SELinux is *missing people* *activly advancing* it's usability in Debian.

(And as others have explained in this thread, technically AppArmor looks
promising too.)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: recommends for apparmor in newest linux-image-4.13

[intrigeri]

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 made for selinux.

In theory, sure. In practice, well, apparently nobody made that same
argument for SELinux; I suspect there's a reason for it.

One problem with the decision making process we've gone through is
that so far, we lack information about the current state of SELinux in
Debian to be able to do a fair comparison: as far as I can tell, most
of the SELinux info that was contributed to this discussion came from
a (very nice and informative) Fedora developer and was not applying
directly to Debian. So we discussed "what would it take to enable
AppArmor by default in Buster" instead of "which LSM can/should we
enable by default in Buster?".

I'm happy to participate in the latter discussion but I won't be the
one starting and facilitating it. I think basically all the info we
need wrt. AppArmor is already on the corresponding discussion thread
and the missing bits are being gathered with the current
experimentation; if something is missing, just ask; then someone
should sum this info somewhere (I can do this but perhaps someone less
biases than me would be better). We'll need similar information about
SELinux in Debian; and if the SELinux maintainers say it's OK to try
it, let's do the same experiment for SELinux (say in 3 months, we
switch the default, enforced by default LSM from AppArmor to 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 logic.

I was familiar enough with the state of AppArmor in Debian to be
confident we could turn it on without breaking lots of critical
functionality on the vast majority of Debian testing/sid systems (the
Ubuntu experience helps a lot). I think what happened in the last two
weeks proved this point.

I'm not familiar enough with the state of SELinux in Debian to know
precisely why the SELinux maintainers did not propose enabling it by
default (it might be due to the current state being far from good
enough, it might be due to lack of resources to handle bug reports, it
might be that I was too pushy with AppArmor so they did not dare,
really I don't know). I would be very interested to get data points
about this, either from the SELinux maintainers, or from enthusiastic
users willing to enforce SELinux today on their Debian testing/sid
desktop system and report how it goes.

Cheers,
-- 
intrigeri

Re: recommends for apparmor in newest linux-image-4.13

[Michael Stone]

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 quite some time, and those
efforts don't seem to have been particularly successful.


Well, maybe it should just be turned on by default, then all the remaining
issues will magically go away just like they will for apparmor!


If there are issues, file bugs and mention them. So far your attitude is not
helpful at all.

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 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 logic.


Mike Stone

Re: recommends for apparmor in newest linux-image-4.13

[Emilio Pozuelo Monfort]

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 particularly successful.
> 
> Well, maybe it should just be turned on by default, then all the remaining
> issues will magically go away just like they will for apparmor!

If there are issues, file bugs and mention them. So far your attitude is not
helpful at all.

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.
It is one thing to enable something for your particular setup, and it's a very
different thing to have it enabled across all the distribution. So don't blame
the maintainers if it worked for them but doesn't work for you. Once we know
what specific problems exist, we can work on fixing those and/or we can revert
the situation, if that turns out to be the best option. In my experience, I have
only encountered one problem so far and it's already been worked on.

Emilio

Re: recommends for apparmor in newest linux-image-4.13

[Simon McVittie]

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 security model
> 
> I am not an expert, but I thought that AppArmor was also considered a
> MAC implementation.

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 designed to be sandboxed, and an AppArmor profile
was added later without modifying app code, the profile rules that are
necessary to make it work are often loose enough to allow privilege
escalation, particularly for desktop apps that are typically written to
assume they have full desktop privileges.

One rebuttal to that is that hardening is better than nothing, and what
most Debian users have in this department at the moment is nothing.

One very likely route for privilege escalation is that when a desktop app
has been written with the expectation that it can run other programs as
subprocesses, if those programs have higher privilege than the desktop app
itself, the desktop app can probably subvert them - the security issues
around setuid are well-known, but switching to a more-privileged AppArmor
profile is basically a weaker form of setuid, and we can't really expect
the author of every program that might be used as a subprocess to write
in the same defensive/paranoid style that we expect for setuid programs.
I think we have to assume that if any descendant of an app (in terms of
the process tree) can do something, then so can that app.

Controlled privilege escalation without the pitfalls of executing a
subprocess is often done via D-Bus or similar. However, until the kernel
support necessary for finer-grained D-Bus AppArmor mediation lands
upstream (which it hopefully will soon), another route for privilege
escalation is that if you can get access to the session bus at all,
then you can interact with services that expect that everything on the
session bus is equally-privileged, and in particular ask dbus-daemon,
gnome-session, systemd --user, etc. to run arbitrary code on your behalf.
If you have a patched kernel that adds this feature (like Ubuntu has for
many years), Debian's dbus-daemon is already set up to make use of it.

Flatpak's "portals" concept is an attempt to avoid those privilege
escalation opportunities. In some ways, the portal work is more important
than Flatpak itself.

Outside desktops, in the more limited scope (but higher privilege level)
of system services, is probably where AppArmor is most useful in the
short term. In that space it overlaps fairly heavily with what you can
do with the various "hardening" options available in systemd units.

smcv

Re: recommends for apparmor in newest linux-image-4.13

[Michael Stone]

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 turned on by default, then all the 
remaining issues will magically go away just like they will for apparmor!



Ubuntu has
successfully shipped with AppArmor enabled.


For all the packages in debian? Cool! That will save a lot of work.

Mike Stone

Re: recommends for apparmor in newest linux-image-4.13

[Scott Leggett]

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 not only is required for
> various security sensitive deployments but also a good idea in general.

I am not an expert, but I thought that AppArmor was also considered a
MAC implementation.

Can you provide more information on the verification of SELinux?

-- 
Regards,
Scott.


signature.asc
Description: PGP signature

Bug#883075: ITP: memleax -- debug a running process for memoy leaks without recompiling or restarting

[Nicholas D Steeves]

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 leaks without recompiling 
or restarting

 Memleax debugs a program for memory leaks by attaching to a running process,
 similarly to how gdb's does. It then hooks into the target process's
 invocation of memory allocation and free, and reports in real time the
 memory blocks that it identifies as memory leaks. The default expiration
 threshold is 10 seconds; however, you should always set this with the -e
 option according to your scenarios.
 .
 It is very convenient to use, and is suitable for production
 environments. There is no need to recompile the program that is being
 debugged and no need to restart the target process. Attach memleax to the
 target process, wait for the real-time memory leak report while it monitors
 the target program's memory allocation, and then kill memleax (e.g. sent it
 a SIGINT with Ctrl-C) to stop monitoring.
 .
 Memleax follows new threads, but not forked processes. If you want to
 debug multiple processes, just run multiple instances of memleax!
 .
 Differences from Valgrind:
 .
 * Valgrind starts the target process, while memleax attaches to on that is
   already running.
 * Valgrind reports memory leaks after target process ends, while memleax
   reports in real time.
 * Valgrind reports all unfreed memory, including program initialisation, while
   memleax reports only after attaching, skipping the init phase.
 * Valgrind runs the target process on its virtual CPU, which makes it slow.
 * Memleax hooks memory APIs, which may be less slow if the target process does
   not make use of many calls to memory APIs.
 * Valgrind debugs many kinds of memory bugs, while memleax is lightweight and
   only detects memory leaks.

I discovered memleax because I needed to find something that could
attach to a running process to debug memleaks.  This ITP is contingent
on memleax usefulness (yet to be established).  If it proves to be
useful to debug unanticipated memory leaks, then I believe it will be
an asset to many Debian developers and bug reporters--particularly for
hard to reproduce bugs.

I'm 90% done the packaging (I just need to go over my work with my
checklist), and I will need a sponsor.  I plan to put the package into
collab-maint, and I would welcome a co-maintainer who would like to work with 
upstream, if necessary, to make this program even better.

Sincerely,
Nicholas

Re: recommends for apparmor in newest linux-image-4.13

[W. Martin Borgert]

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!

Bug#883065: ITP: tldr-py -- python client for tldr: simplified and community-driven man pages

[Ondřej Nový]

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 tldr: simplified and community-driven man 
pages

Yet another python client for tldr. tldr is a collection of simplified and
community-driven man pages.

Bug#883054: ITP: r-cran-dimred -- GNU R framework for dimensionality reduction

[Andreas Tille]

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 for dimensionality reduction
 A collection of dimensionality reduction
 techniques from R packages and provides a common
 interface for calling the methods.


Remark: This package belongs to a pyramid of dependencies to upgrade
r-cran-caret to its latest upstream version.  It will be maintained by
the Debian Science team at
https://anonscm.debian.org/git/debian-science/packages/r-cran-dimred.git
Any takers for other new dependencies of r-cran-caret would be
really appreciated.  Also other Uploaders who volunteer to keep on
maintaining the packages are really welcome.