Bug#1051678: RFP: ublksrv -- Daemon and library for user-space block devices

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: ublksrv
  Version : 1.1-rc1
  Upstream Contact: Ming Lei < tom.leim...@gmail.com>
* URL : https://github.com/ming1/ubdsrv
* License : GPL-2, LGPL-2.1, MIT
  Programming Lang: C++, C
  Description : Support for Linux user-space block devices

This is the user-space code that works with the ublk driver introduced
in Linux 6.0.  There is a daemon to handle requests and a library for
writing individual user-space block drivers.  It includes drivers for
loop, nbd, and qcow2 block devices.

Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers

[Ben Hutchings]

I've prepared a package in the Git repository
<https://salsa.debian.org/kernel-team/ktls-utils>.

As of Linux 6.4, the only in-kernel user of TLS is the NFS server. 
Linux 6.5 adds support in the NFS client.  With just the NFS server
supporting TLS, I can't do an end-to-end test.

Once we have Linux 6.5 packaged, I can test and hopefully upload this
package.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.



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

Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ker...@lists.debian.org, 
Steve Dickson , Chuck Lever III 

* Package name: ktls-utils
  Version : 0.9
  Upstream Contact: kernel-tls-handsh...@lists.linux.dev
* URL : https://github.com/oracle/ktls-utils
* License : GPLv2
  Programming Lang: C
  Description : TLS handshake utilities for in-kernel TLS consumers

In-kernel TLS consumers need a mechanism to perform TLS handshakes on
a connected socket to negotiate TLS session parameters that can then
be programmed into the kernel's TLS record protocol engine.

This package of software provides a TLS handshake user agent that
listens for kernel requests and then materializes a user space socket
endpoint on which to perform these handshakes. The resulting
negotiated session parameters are passed back to the kernel via
standard kTLS socket options.

This will be maintained by the kernel team.

Bug#882640: ITP: dm-zoned-tools -- utilities for the dm-zoned device mapper

[Ben Hutchings]

Control: retitle -1 RFP: dm-zoned-tools -- utilities for the dm-zoned device 
mapper
Control: noowner -1

I'm moving this back to RFP status, because this package didn't get
sponsored and seems to have disappeared now.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


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

Bug#1014898: ITP: gcompat -- The GNU C library compatibility layer for musl

[Ben Hutchings]

On Thu, 2022-07-14 at 14:15 +0900, Nobuhiro Iwamatsu wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nobuhiro Iwamatsu 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: gcompat
>   Version : 1.0.0
>   Upstream Author : A. Wilcox
> * URL : https://git.adelielinux.org/adelie/gcompat
> * License : Expat
>   Programming Lang: C
>   Description : The GNU C library compatibility layer for musl
> 
>   The gcompat provides glibc-compatible APIs for use on musl libc systems.
>   .
>   This library is designed to be used for binaries that are already
>   compiled against glibc. It does not contain any headers, and cannot be
>   used to build software that requires glibc. It is instead recommended
>   that any software that requires glibc APIs be modified to become more
>   portable.
>   .
>   This library can optionally be compiled with other libraries to make a
>   single, unfied solution. This can include fts, libucontext, obstack,
>   and others.
>   .
>   gcompat additionally provides a loader stub. This is a small library
>   that has the same name as the glibc dynamic linker on glibc platforms;
>   when a binary is run that uses glibc as its dynamic linker, the stub
>   will run, redirecting it to use musl and automatically preloading the
>   gcompat library.
> 

How would this be used in Debian, when all our ports already use glibc?

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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

Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Ben Hutchings]

On Thu, 2022-07-14 at 10:20 +0100, Edward Betts wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Edward Betts 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
> 
> * Package name: gender-guesser
>   Version : 0.4.0
>   Upstream Author : Israel Saeta Pérez 
> * URL : https://github.com/lead-ratings/gender-guesser
> * License : GPL-3 & GFDL-1.2+
>   Programming Lang: Python
>   Description : Guess the gender from first name
[...]

This is a horribly bad idea, what do you need it for?

Ben.


-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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

Bug#974015: ITP: gn -- gn is a meta-build system that generates build files for Ninja

[Ben Hutchings]

On Mon, 2020-11-09 at 14:41 +0800, Xialei Qin wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: gn
[...]

Please consider using a longer package name, like generate-ninja.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.

[Ben Hutchings]

On Fri, 2020-11-06 at 17:55 +0100, David Heidelberg wrote:
> Hello Ben,
> 
> I asked about possibility of changing name and the final reply is [1].
> 
> Quoting dreamer:
> Right now, we are fighting to convince users (and developers) to move 
> on from using a myriad of tiny DOSBox forks (link - very incomplete, 
> there are ~50 other dead forks I know of) or maintain their own 
> patchsets based on 10-year old 0.74. We have already certain (hard 
> thought for) recognition and community formed up - changing name at 
> this point will only cause confusion and hurt the project's prospects 
> for future.

Oh well, thanks for asking anyway.  I suggest you make the long
description clearly state that this is independent of the original
DOSBox project.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.




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

Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.

[Ben Hutchings]

On Thu, 2020-11-05 at 17:41 +0100, David Heidelberg wrote:
[...]
> Q: why is this package useful/relevant?
> A: Sucessor of DOSBox, which is already inside Debian
[...]

DOSBox seems to be under active development even though it hasn't had a
release for a while.  So this is an independent fork, not a successor
to a dead project.  (If DOSBox had become dead upstream, I would have
recommended rebasing the existing dosbox source package on DOSBox
Staging instead.)

I think this name is also misleading.  "DOSBox Staging" sounds like a
development branch of the original DOSBox project, not an independent
project.  Are the upstream developers set on using this name or do you
think they could be persuaded to use something more distinctive?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.



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

Bug#968654: ITA: scons -- replacement for make

[Ben Hutchings]

On Sun, 23 Aug 2020 14:51:49 +0200 =?UTF-
8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:
> retitle 968654 ITA: scons -- replacement for make
> owner 968654 !
> thanks
> 
> I was not too active with SCons, but would like to continue its maintenance.

I have just converted my recent NMU into a series of git commits and
pushed it to the repository on Salsa.  Hopefully that will be a useful
basis for you to continue work from.  It might make sense to start
merging from the upstream git repository in future.

Bug ##966515 still affects stretch and buster.  For buster, I've pushed
changes to fix it to a new 'buster' branch.  For stretch I think it can
be ignored.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth



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

Bug#968655: ITA: scons-doc -- Documentation for SCons, a replacement for Make

[Ben Hutchings]

On Sun, 23 Aug 2020 14:51:59 +0200 =?UTF-
8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:
> retitle 968655 ITA: scons-doc -- Documentation for SCons, a replacement for 
> Make
> owner 968655 !
> thanks
> 
> This goes for SCons which I would like to continue maintaining.

I haven't checked, but I strongly suspect that scons-doc does not have
complete source.  The scons-doc binary package should probably be built
from the scons source package in future.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth




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

Bug#966537: ITP: tomboy-ng -- Cross Platform Notes

[Ben Hutchings]

On Mon, 2020-08-03 at 10:34 +1000, David Bannon wrote:
> Ben, I am not sure if I am allowed to answer here, don't want Bart to
> slap me down again.
> 
> If I have it wrong again, very sorry, will withdraw
> 
> 
> On 3/8/20 4:34 am, Ben Hutchings wrote:
> > Gtk+ 2 is deprecated, and we should not add new applications using it.
> > So it sounds like the best option for now would be to build it with Qt
> > support only.  Why is that limited to 64-bit architectures?
> 
> Ben, most distros are still shipping GTK2 and most don't ship Qt5. So,
> at present, it sort of makes sense to use GTK2 from the point of view of
> the average user.

I am only talking about what should be done in an official Debian
package here.  It you build a generic binary for Linux then Gtk+ 2 may
well be the better option.

> The point is that with Lazarus, its trivial to switch
> from GTK2 to QT5 at compile time so, in a way, tomboy-ng is not really a
> GTK2 app, it can be what ever is decided at compile time.
> 
> The Qt5 version is dependent of a shim library, libqt5pas that is
> available in most newer distributions but 64bit only.  Thats apparently
> because the upstream libraries that are needed to link to it are not
> available.

Debian has it for 32-bit and 64-bit Arm and x86 architectures, plus
32-bit MIPS.

[...]
> That all sounds great. I am starting to understand the Debian process,
> but just starting !

You should probably join the debian-mentors mailing list and send any
questions there.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.



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

Bug#966537: ITP: tomboy-ng -- Cross Platform Notes

[Ben Hutchings]

On Thu, 2020-07-30 at 20:51 +1000, David Bannon wrote:
[...]
>  tomboy-ng is built, from the same source, to work with 32 or 64 bit
>  GTK2, Qt5 (64bit only) and a list including Windows, MacOS, Raspbian.
>  It can be built for GTK3 but not to a satisfactory standard as yet.

Gtk+ 2 is deprecated, and we should not add new applications using it.
So it sounds like the best option for now would be to build it with Qt
support only.  Why is that limited to 64-bit architectures?

>  A script exists that will convert the zip file downloaded from github
>  to a 'kit' ready for debuild.

Depending on what your script does, the 'kit' might not include what we
would consider the full source code.  The script itself would also need
to be made public, usually as part of the source package.

It is generally preferable for Debian source packages to start from a
tarball that exactly matches an upstream release.

>  A tomboy-ng binary install uses about 5Meg, in most systems little or
>  no additional packages are required.
>  Some issues remain about building in a manner appropriate for Debian.
>  Its not clear, at present, if tomboy-ng will build satisfactory using
>  the version of Lazarus in Buster.  Bullseye is fine.

In any case this will have to go into unstable first, and then (if all
goes well) it can go into bullseye and maybe buster-backports.  It
won't be added to buster as we don't add new applications to stable
releases.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Bug#966229: ITP: protocol -- a simple command line tool for displaying standard network protocol headers

[Ben Hutchings]

On Sat, 2020-07-25 at 08:36 +0530, Vasudev Kamath wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Vasudev Kamath 
> 
> * Package name: protocol

I think this name is too generic.

>   Version : 0.1
>   Upstream Author : Luis MartinGarcia 
> * URL : http://www.luismg.com/protocol/
> * License : GPL-3.0
>   Programming Lang: Python
>   Description : a simple command line tool for displaying standard 
> network protocol headers
> 
>  Protocol is a simple command-line tool that serves two purposes:
>- Provide a simple way for engineers to have a look at standard network 
> protocol headers, directly
>  from the command-line, without having to google for the relevant RFC or 
> for ugly header image
>  diagrams.
>- Provide a way for researchers and engineers to quickly generate ASCII 
> RFC-like header diagrams for
>  their own custom protocols.

It sounds quite useful though.

Ben.

>  - why is this package useful/relevant?
>It is useful for observing headers of Standard Network protocol without 
> going to need to go through
>wiki page for protocol or from RFC documents.
>It is also helpful to generate RFC like ASCII header diagram for custom 
> protocol.
> 
>  - how do you plan to maintain it?
>For now myself, might consider later to move it to Python application team.
> 
-- 
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine




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

Bug#912677: ITP: oci-systemd-hook - OCI systemd hook enables users to run systemd in OCI compatible runtimes

[Ben Hutchings]

On Fri, 2 Nov 2018 14:48:53 -0400 (EDT) Qian Cai  wrote:
> package: wnpp
> Severity: wishlist
> Owner: 'Qian Cai' 
> 
> *Package Name : oci-systemd-hook
>  Version : 0.1.18
> *URL :  https://github.com/projectatomic/oci-systemd-hook
> *License : GPLv3
> *Description :  OCI systemd hook enables users to run systemd in docker
>  and OCI compatible runtimes such as runc without requiring --privileged
>  flag.
[...]

I'm interested in having this in Debian.  However, it looks like runc
requires a non-upstream patch to implement that hook mechanism.  Is
there any plan to apply that in Debian?

Ben.

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#963225: ITP: prince-of-persia -- SDL port of the classic Prince of Persia game

[Ben Hutchings]

On Sat, 2020-06-20 at 16:38 -0700, Kees Cook wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Kees Cook 
> 
> * Package name: prince-of-persia
>   Version : 1.20
>   Upstream Author : Dávid Nagy
> * URL : https://github.com/NagyD/SDLPoP
> * License : GPL-3+

I don't see how this is possible.

>   Programming Lang: C
>   Description : SDL port of the classic Prince of Persia game
[...]

So this is a derivative work of Prince of Persia (the DOS version
apparently), isn't it?

Only the Apple II version seems to have been re-released under a
vaguely free licence, and even that doesn't explicitly allow
redistribution.

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.



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

Bug#958812: ITP: jinja-vanish -- Jinja2 environment for non-HTML auto-escaping

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings 

* Package name: jinja-vanish
  Version : 0.2~gitXXX
  Upstream Author : Marc Brinkmann
* URL : https://github.com/mbr/jinja-vanish
* License : Expat
  Programming Lang: Python
  Description : Jinja2 environment for non-HTML auto-escaping

Jinja2 supports auto-escaping values substituted into templates,
using HTML syntax.

The jinja_vanish module provides an environment class that allows a
custom auto-escape function to be provided, supporting other output
formats.

I'm working on a project that will depend on this.

Bug#953175: ITP: phoenix-firmware -- firmware necessary for boxes issued by project PHOENIX

[Ben Hutchings]

On Thu, 2020-03-05 at 16:14 +0100, Georges Khaznadar wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Georges Khaznadar 
> 
> * Package name: phoenix-firmware
>   Version : 4.6.1
>   Upstream Author : Ajith Kumar B.P. 
> * URL : http://expeyes.in
> * License : GPL-3.0+
>   Programming Lang: C for AVR
>   Description : firmware necessary for boxes issued by project PHOENIX

I think this is a poor choice of name, considering that Phoenix
Technologies previously objected to Mozilla Phoenix (original name of
Firefox) and that "firmware" is very much their core competency.

Ben.

>  The project PHOENIX, created by Ajith Kumar, from Inter-University
>  Accelerator Centre (IUAC) in New Delhi, is aimed at creating
>  “Physics with Home-made Equipment and Innovative Experiments” (Phoenix).
>  The popular boxes distributed by this projet are named expeyes, kuttypy,
>  microhope. Each of them is based on a microcontroller, and provide their
>  unique features thanks to the microcode burnt into those microcontrollers.
>  More information is available at https://expeyes.wordpress.com/phoenix/
>  This package provides the source and the binary formats for that firmware.
> 
> I shall keep on maintaining packages expeyes and phoenix-firmware as
> parts of my daily job (I do use this hardware to teach students).
> 
> Source package can be found at https://salsa.debian.org/georgesk/phoenix-
> firmware
-- 
Ben Hutchings
Knowledge is power.  France is bacon.




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

Bug#950832: ITP: ospd -- Open Scanner Protocol daemon (OSPd)

[Ben Hutchings]

On Fri, 2020-02-07 at 09:46 +0100, Sophie Brun wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sophie Brun 
> 
> * Package name: ospd
>   Version : 2.0.0
>   Upstream Author : Greenbone Networks GmbH
> * URL : https://github.com/greenbone/ospd
> * License : GPL-2+
>   Programming Lang: Python3
>   Description : Open Scanner Protocol daemon (OSPd)
> 
> OSPD is a base class for scanner wrappers which share the same
> communication protocol: OSP (Open Scanner Protocol). OSP creates a unified
> interface for different security scanners and makes their control flow and
> scan results consistently available under the central Greenbone
> Vulnerability Manager service.

I would suggest using "security scanners" instead of just "scanners" at
the *first* mention in the long description.  That way, the reader can
tell whether it is the right kind of scanning software a few seconds
earlier. :-)

Ben.

> This package is required for ospd-openvas, an openvas/greenbone
> tool.
> 
> I plan to maintain this package within the pkg-security team with the
> other openvas/ greenbone packages.
> 
-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.




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

Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust

[Ben Hutchings]

On Tue, 2019-12-31 at 20:01 +, Ximin Luo wrote:
> Ben Hutchings:
> > On Tue, 2019-12-31 at 16:39 +, Ximin Luo wrote:
> > > Ben Hutchings:
> > > > On Tue, 2019-12-31 at 04:31 +, Ximin Luo wrote:
> > > > > Package: wnpp
> > > > > Severity: wishlist
> > > > > Owner: Ximin Luo 
> > > > > 
> > > > > * Package name: rust-spotify-tui
> > > > >   Version : 0.11.0
> > > > >   Upstream Author : Alexander Keliris 
> > > > > * URL : https://github.com/Rigellute/spotify-tui
> > > > > * License : MIT or Apache-2.0
> > > > >   Programming Lang: Rust
> > > > >   Description : Spotify for the terminal written in Rust
> > > > 
> > > > Why is the implementation language relevant for an application
> > > > package?
> > > > 
> > > 
> > > I just copied upstream's github repo description.
> > 
> > You also added "rust-" to the package name.
> > 
> 
> This is just the convention we have for source-package names that are
> automatically packaged by our "debcargo" packaging tool. The binary-
> package name does not have the "rust-" prefix, so users would just
> type "apt install spotify-tui".

I still don't think it makes sense to include a language prefix/suffix
in an application package name, but if it's only in the source package
that doesn't matter.

> I was under the impression that we should use source-package names in
> wnpp bugs.

That's correct.

> > > > Also, including Spotify in the name might be a trademark
> > > > violation.
> > > > 
> > > 
> > > IANAL but there's lots of other similar examples of a tool that
> > > interfaces with a service S being called "something-S-something",
> > > e.g. "calendar-google-provider". The description is pretty clear
> > > that
> > > this is not an official spotify product. If the law actually has
> > > a
> > > problem with this, I'd be at a loss to think of how we could
> > > possibly
> > > name such a tool *without* referring to "S" verbatim in the name.
> > > Prefix everything with "unofficial"? I've never seen that in any
> > > other FOSS project.
> > 
> > I am also NAL, but have seen a lot of trademark complaints in the
> > software world.  It is generally OK to use other companies'
> > trademarks
> > for "nominative use", e.g. to say that my product X works with Y. 
> > However, using another company's trademark at the beginning of a
> > product name risks confusion and is more likely to result in, at
> > least,
> > legal threats.
> > 
> > In this case, Spotify should definitely be mentioned in the package
> > description, and maybe at the end of its name, but the package
> > probably
> > needs some distinct name.
> > 
> 
> Well, this is more a matter for upstream - I can't just unilaterally
> rename someone else's program.

Yes, I realise that.

> If you or others have some reasonable and detailed arguments on why
> they should change their name, I would be happy to forward that or
> you could do so yourself...

You are welcome to send my previous comments upstream.

> Then there is the question of all of the existing packages in Debian
> that have this similar issue.

That's not a good reason to add to a potential problem.

> Also I'd expect that if Spotify were to complain, they would complain
> to upstream rather than Debian, since we cannot reasonably be
> expected to unilaterally rename someone else's tool.

Adding the package to Debian increases its prominence and the
likelihood that it will come to their attention.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.




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

Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust

[Ben Hutchings]

On Tue, 2019-12-31 at 16:39 +, Ximin Luo wrote:
> Ben Hutchings:
> > On Tue, 2019-12-31 at 04:31 +, Ximin Luo wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Ximin Luo 
> > > 
> > > * Package name: rust-spotify-tui
> > >   Version : 0.11.0
> > >   Upstream Author : Alexander Keliris 
> > > * URL : https://github.com/Rigellute/spotify-tui
> > > * License : MIT or Apache-2.0
> > >   Programming Lang: Rust
> > >   Description : Spotify for the terminal written in Rust
> > 
> > Why is the implementation language relevant for an application package?
> > 
> 
> I just copied upstream's github repo description.

You also added "rust-" to the package name.

> > Also, including Spotify in the name might be a trademark violation.
> > 
> 
> IANAL but there's lots of other similar examples of a tool that
> interfaces with a service S being called "something-S-something",
> e.g. "calendar-google-provider". The description is pretty clear that
> this is not an official spotify product. If the law actually has a
> problem with this, I'd be at a loss to think of how we could possibly
> name such a tool *without* referring to "S" verbatim in the name.
> Prefix everything with "unofficial"? I've never seen that in any
> other FOSS project.

I am also NAL, but have seen a lot of trademark complaints in the
software world.  It is generally OK to use other companies' trademarks
for "nominative use", e.g. to say that my product X works with Y. 
However, using another company's trademark at the beginning of a
product name risks confusion and is more likely to result in, at least,
legal threats.

In this case, Spotify should definitely be mentioned in the package
description, and maybe at the end of its name, but the package probably
needs some distinct name.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.




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

Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust

[Ben Hutchings]

On Tue, 2019-12-31 at 04:31 +, Ximin Luo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ximin Luo 
> 
> * Package name: rust-spotify-tui
>   Version : 0.11.0
>   Upstream Author : Alexander Keliris 
> * URL : https://github.com/Rigellute/spotify-tui
> * License : MIT or Apache-2.0
>   Programming Lang: Rust
>   Description : Spotify for the terminal written in Rust

Why is the implementation language relevant for an application package?

Also, including Spotify in the name might be a trademark violation.

Ben.

> spotify-tui needs to connect to Spotify’s API in order to find music by name,
> play tracks etc. Instructions on how to set this up will be shown when you
> first run the app.
> 
> This app uses the Web API from Spotify, which doesn't handle streaming itself.
> So you'll need either an official Spotify client open or a lighter weight
> alternative such as spotifyd.
> 
> If you want to play tracks, Spotify requires that you have a Premium account.
-- 
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.




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

Bug#944704: ITP: org-html-themes -- export Emacs Org mode files into awesome HTML in 2 minutes or less

[Ben Hutchings]

On Wed, 2019-11-13 at 23:41 -0500, Nicholas D Steeves wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nicholas D Steeves 
> 
> * Package name: org-html-themes
>   Version : 1.0.0
>   Upstream Author : 
> * URL : https://github.com/fniessen/org-html-themes
> * License : GPL-3+
>   Programming Lang: Org_style_markdown, HTML, CSS, js vs Debian's libjs-foos
>   Description : export Emacs Org mode files into awesome HTML in 2 minutes
> 
>  Org-HMTL themes is an open source framework that enables the
[...]

Typo: "HMTL".

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.




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

Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

[Ben Hutchings]

On Mon, 2019-11-11 at 21:37 +, Sudip Mukherjee wrote:
> Hi Ben,
> 
> On Sun, Nov 10, 2019 at 10:01 PM Ben Hutchings  wrote:
> > On Sun, 2019-11-10 at 21:29 +, Sudip Mukherjee wrote:
> > > On Fri, Nov 08, 2019 at 07:56:55PM +, Ben Hutchings wrote:
> > > > On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote:
> > > > [...]
> > > > > The code for libtracevent lives in the kernel tree at
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
> > > > > tools/lib/traceevent folder.
> > > > > And so, it will be great if kernel team will like to package and 
> > > > > maintain it, if not, then I will
> > > > > be happy to do it. But, if I am doing it then I will need a sponsor 
> > > > > to upload it.
> > > > 
> > > > If kernel.org's kernel source repository is the canonical location for
> > > > this code, not just a convenience copy, then the binary package should
> > > > be built from src:linux and not a separate source package.
> > > > 
> > > > I think src:linux already builds the library, but only as a static
> > > > library that's linked into perf.
> > > > 
> > > > I don't know exactly what changes you would need to make, but they
> > > > should be roughly along these lines:
> > > > 
> > > 
> > > > 4. Generate the debian/libtraceevent.symbols file recording
> > > >the shared library's exported symbols.
> > > 
> > > Thanks for your reply Ben.
> > > I will try these steps and see how it goes.
> > > 
> > > > 5. (Not sure if this is needed.)  Modify
> > > >debian/rules.d/tools/perf/Makefile to make perf use the shared
> > > >library.  Add libtraceevent to the dependencies of
> > > >linux-perf- in debian/templates/control.tools-versioned.in.
> > > 
> > > This should not be needed as perf does not yet depend on libtraceevent.
> > > The libtraceevent that perf is creating is only having the plugins.
> > 
> > I'm pretty sure it does; look for "libtraceevent.a" in
> > <https://buildd.debian.org/status/fetch.php?pkg=linux=amd64=5.3.9-1=1573349194=1>;.
> 
> iiuc, perf used tools/lib/traceevent to generate "libtraceevent.a"
> which is a static library and perf is building against that. It is
> also using the plugins generated by traceevent. But it is not using
> "libtraceevent.so" which is generated.
[...]

Yes, exactly.  And it is usual practice in Debian to link with shared
libraries where possible.  (I thought that was actually in policy, but
it doesn't seem to be.)

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.




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

Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

[Ben Hutchings]

On Sun, 2019-11-10 at 21:29 +, Sudip Mukherjee wrote:
> On Fri, Nov 08, 2019 at 07:56:55PM +0000, Ben Hutchings wrote:
> > On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote:
> > [...]
> > > The code for libtracevent lives in the kernel tree at
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
> > > tools/lib/traceevent folder.
> > > And so, it will be great if kernel team will like to package and maintain 
> > > it, if not, then I will
> > > be happy to do it. But, if I am doing it then I will need a sponsor to 
> > > upload it.
> > 
> > If kernel.org's kernel source repository is the canonical location for
> > this code, not just a convenience copy, then the binary package should
> > be built from src:linux and not a separate source package.
> > 
> > I think src:linux already builds the library, but only as a static
> > library that's linked into perf.
> > 
> > I don't know exactly what changes you would need to make, but they
> > should be roughly along these lines:
> > 
> 
> > 4. Generate the debian/libtraceevent.symbols file recording
> >the shared library's exported symbols.
> 
> Thanks for your reply Ben.
> I will try these steps and see how it goes.
> 
> > 5. (Not sure if this is needed.)  Modify
> >debian/rules.d/tools/perf/Makefile to make perf use the shared
> >library.  Add libtraceevent to the dependencies of
> >linux-perf- in debian/templates/control.tools-versioned.in.
> 
> This should not be needed as perf does not yet depend on libtraceevent.
> The libtraceevent that perf is creating is only having the plugins.

I'm pretty sure it does; look for "libtraceevent.a" in
<https://buildd.debian.org/status/fetch.php?pkg=linux=amd64=5.3.9-1=1573349194=1>.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.



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

Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

[Ben Hutchings]

On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote:
[...]
> The code for libtracevent lives in the kernel tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
> tools/lib/traceevent folder.
> And so, it will be great if kernel team will like to package and maintain it, 
> if not, then I will
> be happy to do it. But, if I am doing it then I will need a sponsor to upload 
> it.

If kernel.org's kernel source repository is the canonical location for
this code, not just a convenience copy, then the binary package should
be built from src:linux and not a separate source package.

I think src:linux already builds the library, but only as a static
library that's linked into perf.

I don't know exactly what changes you would need to make, but they
should be roughly along these lines:

1. Add debian/rules.d/tools/lib/traceevent/Makefile with a default
   target that calls the upstream build system.  This must build in
   the current directory (somewhere under debian/build) and not the
   source directory.  It must enable printing of all build comamnds
   by default.

2. Define the new binary packages and their build-dependencies in
   debian/templates/control.tools-unversioned.in.  These packages
   must have "Build-Profiles: ".

3. Define build-libtraceevent and install-libtraceevent targets in 
   debian/rules.real, similarly to those for libcpupower.
   Add those to the dependencies of the build-arch-arch and
   binary-arch-arch targets, using the if_package macro to check
   whether the packages should be built.

4. Generate the debian/libtraceevent.symbols file recording
   the shared library's exported symbols.

5. (Not sure if this is needed.)  Modify
   debian/rules.d/tools/perf/Makefile to make perf use the shared
   library.  Add libtraceevent to the dependencies of
   linux-perf- in debian/templates/control.tools-versioned.in.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



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

Bug#941568: ITP: multiprocess -- better multiprocessing and multithreading in Python

[Ben Hutchings]

On Wed, 2019-10-02 at 19:14 +0200, Andreas Tille wrote:
> On Wed, Oct 02, 2019 at 04:00:49PM +0100, Ben Hutchings wrote:
> > On Wed, 2019-10-02 at 05:26 +0200, Andreas Tille wrote:
> > >  Multiprocess is a fork of multiprocessing, and is developed as part of
> > >  pathos.
> > >  .
> > >  Multiprocessing is a package for the Python language which supports the
> > >  spawning of processes using the API of the standard library's threading
> > >  module. multiprocessing has been distributed in the Python standard 
> > > library.
> > [...]
> > 
> > The package description needs to make a much clearer distinction
> > between the original multiprocessing module and this fork.
> 
> Hmmm, I wonder whether you could make some suggestion how to make it
> much clearer.  I've thought the first sentence would be clear enought -
> but any patch is welcome.

No, that's not my job.  You could ask on debian-l10n-english.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.




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

Bug#941568: ITP: multiprocess -- better multiprocessing and multithreading in Python

[Ben Hutchings]

On Wed, 2019-10-02 at 05:26 +0200, Andreas Tille wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andreas Tille 
> 
> * Package name: multiprocess
>   Version : 0.70.9
>   Upstream Author : California Institute of Technology.
> * URL : https://github.com/uqfoundation/multiprocess
> * License : BSD-3-clause
>   Programming Lang: C
>   Description : better multiprocessing and multithreading in Python
>  Multiprocess is a fork of multiprocessing, and is developed as part of
>  pathos.
>  .
>  Multiprocessing is a package for the Python language which supports the
>  spawning of processes using the API of the standard library's threading
>  module. multiprocessing has been distributed in the Python standard library.
[...]

The package description needs to make a much clearer distinction
between the original multiprocessing module and this fork.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.




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

Bug#936043: ITP: gitbatch -- Manage git repositories in one place

[Ben Hutchings]

On Thu, 2019-08-29 at 13:28 +0200, Dawid Dziurla wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Dawid Dziurla 
> 
> * Package name: gitbatch
>   Version : 0.5.0-1
>   Upstream Author : Ibrahim Serdar Acikgoz
> * URL : https://github.com/isacikgoz/gitbatch
> * License : Expat
>   Programming Lang: Go
>   Description : Manage git repositories in one place
> 
>  Managing multiple git repositories is easier than ever. Often one would end
>  up working on many directories and manually pulling updates etc. To make
>  this routine faster, gitbatch was created, a simple tool to handle this job.
>  Although the focus is batch jobs, one can still do de facto micro management 
> of
>  git repositories (e.g add/reset, stash, commit etc.)
> 
> Useful tool for managing multiple git repositiories at once.
> Does not need additional dependencies, only those already in archive.

We already have "mr", which can do this for git and several other
version control systems.  Does gitbatch offer anything new?

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.



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

Bug#930500: ITP: intel-undervolt -- tool for undervolting Intel CPUs

[Ben Hutchings]

On Fri, 14 Jun 2019 01:33:02 +0200 Stephan Lachnit 
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stephan Lachnit 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: intel-undervolt
>   Version : 1.6
>   Upstream Author : kitsunyan <https://github.com/kitsunyan>
> * URL : https://github.com/kitsunyan/intel-undervolt
> * License : GPL-3
>   Programming Lang: C
>   Description : tool for undervolting Intel CPUs
> 
>  intel-undervolt is a tool for undervolting CPUs,
>  working with Intel CPUs since Generation Haswell.
>  It can also change power and temperature limits.
>  Note: undervolting can cause stability issues
[...]

Please don't do this.  It will probably cause crashes and bug reports
against other packages, which waste the time of other maintainers.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.




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

Bug#922628: ITP: dt -- DNS tool - display information about your domain

[Ben Hutchings]

On Mon, 2019-02-18 at 10:52 -0500, Antoine Beaupré wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Antoine Beaupré 
> 
> * Package name: dt
>   Version : 0.0.9
>   Upstream Author : Wim
> * URL : https://github.com/42wim/dt
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : DNS tool - display information about your domain
> 
>  dt a DNS tool that displays information about your domain.
>  .
>  Features
>  • common records scanning (use -scan)
>  • validate DNSSEC chain (use -debug to see more info)
>  • change query speed for scanning (default 10 queries per second)
>  * diagnostic of your domain (similar to intodns.com, dnsspy.io)
>  
> 
> 
> This is a great tool. I worked on packaging a similar tool (dnsdiag,
> #824670) for Debian, but it stopped where dt begun:
> 
> https://github.com/farrokhi/dnsdiag/issues/16
> 
> So I would love to see this in Debian. As usual, I would co-maintain
> this in the golang team.

This command name is very short, and in fact we already have a dt
command (in the ditrack package).  I suggest you try to convince
upstream to pick a unique command name.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Bug#920919: ITP: xoreos-tools -- collection of tools around BioWare's Aurora engine games

[Ben Hutchings]

On Wed, 2019-01-30 at 16:22 +0100, Eike wrote:
[...]
> I'm unsure about the section this should go in. While it is
> all free software, in the greater scheme of things the tools
> only make sense when used with BioWare's non-free data.
> So we might put it into contrib.

I think "contrib" is right.

> The section itself is also not clear to me. It's all about games,
> lintian tells me though that packages in the section games must
> provide binaries under /usr/games/...

I think reverse-engineering would fall under "devel".

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.




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

Bug#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices

[Ben Hutchings]

On Fri, 2019-01-25 at 14:21 -0500, Hanno Stock wrote:
> Am Fr, 25. Jan 2019, um 17:03, schrieb Ben Hutchings:
> > Please consider choosing a more specific package name.  Since we
> > have
> > free drivers for some DisplayLink devices, we should encourage
> > users to
> > use those where possible.
> 
> Ok, I see. What about displaylink-nonfree ? One could also append to
> the long description a hint which package to
> use for devices supported by the free drivers.

That seems sensible.

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.




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

Bug#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices

[Ben Hutchings]

On Fri, 2019-01-25 at 14:22 +0100, Hanno Stock wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Hanno Stock 
> 
> * Package name: displaylink
>   Version : 4.4
>   Upstream Author : DisplayLink (UK) Ltd.
> * URL : https://www.displaylink.com/downloads
> * License : proprietary
>   Programming Lang: binary
>   Description : Proprietary driver for DisplayLink devices
> 
> This is the proprietary binary component of the driver for DisplayLink
> devices. It communicates via libusb with the DisplayLink device and uses
> the opensource evdi kernel module for presenting a virtual graphics
> device to the system.
[...]

Please consider choosing a more specific package name.  Since we have
free drivers for some DisplayLink devices, we should encourage users to
use those where possible.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.




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

Bug#913880: ITP: overlay-userns -- Overlay mounting in user namespaces (DKMS)

[Ben Hutchings]

Control: reassign -1 src:linux
Control: retitle -1 ovl: Add option to permit mounting in user namespaces

On Wed, 2018-11-21 at 06:52 +0100, Nicolas Schier wrote:
> Dear Ben,
> 
> > Why don't you talk to the kernel team about adding a module parameter
> > enable this, rather than packaging a fragile hack?
> 
> thanks for the pointer.  Do you think about something like the attached 
> patch?  Would you recommend a post in debian-kernel@l.d.o about it or 
> better a salsa merge request?

I'd prefer a merge request.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.



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

Bug#913880: ITP: overlay-userns -- Overlay mounting in user namespaces (DKMS)

[Ben Hutchings]

Why don't you talk to the kernel team about adding a module parameter
enable this, rather than packaging a fragile hack?

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.



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

Bug#911802: Re: Bug#911802: ITP: kovri -- C++ I2P router

[Ben Hutchings]

On Fri, 2018-11-02 at 00:10 +, oneiric wrote:
> [...]
> 
> > You will need to have a very good reason to do this. It is recommended
> > to use shared libraries in Debian packages where possible.
> [...]
> 
> Hi Ben,
> 
> I would prefer shared libraries as well.
> 
> The current alpha point release does not require static
> compilation/linking, but we are planning to incorporate Boost.Beast into
> the next release, which requires Boost 1.66+.
> 
> Currently on Debian 9, the system package for Boost is 1.62.

That is irrelevant because this new package won't go into Debian 9.

Ben.

> I checked the different repositories, and 1.62 looks like the latest
> version.
> 
> Thanks for your quick reply, sorry about the delay on my end.
> 
> - oneiric
> 
-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.




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

Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)

[Ben Hutchings]

On Fri, 2018-10-26 at 20:55 +, Dmitry Bogatov wrote:
> [2018-10-26 13:58] Ben Hutchings 
> > part 1 text/plain1014
> > On Fri, 2018-10-26 at 10:39 +, Debian Bug Tracking System wrote:
> > > This is an automatic notification regarding your Bug report
> > > which was filed against the wnpp package:
> > > 
> > > #811377: RFA: sysvinit -- System-V-like init utilities - transitional 
> > > package
> > > 
> > > It has been closed by Dmitry Bogatov .
> > Benda created a git repository at 
> > <https://salsa.debian.org/debian/sysvinit>;.
> 
> My repository is fork of 'debian/sysvinit'. As far as I can tell, the
> following work was done on debian/sysvinit:
> 
>  * import history from alioth up to 2.89-59.10
>  * create (very) incomplete upgrade to 2.90 in branch dgit/experimental

I also committed a bug fix on the dgit/sid branch.

> What I done:
> 
>  * incorporated NMU 2.89-59.11
>  * modernized package a bit
> 
> > You seem to have missed that Ian and Benda already started to adopt
> > sysvinit.  (While they missed closing this bug.)
> 
> Sysvinit have undecided maintainance status for years, which prevented
> me from taking actions previously. But now danger is grave and immediate
> (see recent discussions about removal of sysvinit on debian-devel@), so
> I took libery to take action right now.

I don't believe that sysvinit is or was in *immediate* danger of being
removed.

> I am sorry, if I stepped on someone's toes. I would greatly appericate
> any help in maintaining sysvinit.

Then you should probably use the common (debian group) repository...

Ben.

> Oh, and surely, while I did my best to not introduce any functional
> changes in 2.89-60, brave souls to test upload are more then welcome.
-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Bug#911802: ITP: kovri -- C++ I2P router

[Ben Hutchings]

On Wed, 2018-10-24 at 17:54 -0700, oneiric wrote:
[...]
> I plan to create a Kovri package for Debian. Building Kovri on Debian
> will involve statically building and linking against the most recent
> Boost and OpenSSL libraries.
[...]

You will need to have a very good reason to do this.  It is recommended
to use shared libraries in Debian packages where possible.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Bug#911245: ITP: libvma -- libvma is a LD_PRELOAD-able library that boosts performance

[Ben Hutchings]

On Wed, 2018-10-17 at 18:22 +0300, Talat Batheesh wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Talat Batheesh 
> 
> * Package name: libvma
>   Version : 8.7.1
>   Upstream Author : Liran Oz 
> * URL : https://github.com/Mellanox/libvma
> * License : GPLv2 and BSD
>   Programming Lang: C, C++
>   Description : libvma is a LD_PRELOAD-able library that boosts 
> performance

For the actual binary packages, the short description should not
include "libvma is" but should make it clear what this depends on
ib_verbs.

Ben.

> libvma is a LD_PRELOAD-able library that boosts performance of TCP and UDP 
> traffic.
> It allows application written over standard socket API to handle fast path 
> data
> traffic from user space over Ethernet and/or Infiniband with full network 
> stack
> bypass and get better throughput, latency and packets/sec rate.
> 
> No application binary change is required for that.
> libvma is supported by RDMA capable devices that support "verbs" 
> IBV_QPT_RAW_PACKET QP for Ethernet and/or IBV_QPT_UD QP for IPoIB.
> 
-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.




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

Bug#906250: ITP: execline -- small and non-interactive scripting language

[Ben Hutchings]

On Sun, 2018-09-02 at 14:42 +0800, Shengjing Zhu wrote:
> Dear -devel,
> 
> When I try to package execline(a non-interactive shell script)[1], it
> installs following binaries in default PATH,
> 
> cd, if, exec, wait, 
> 
> Some facts:
> * These names are other shells built-in, but in execline these are binaries.
> * There's no conflict binary name in archive currently.
> * If I install them in path like /usr/lib/execline/bin, then I need to
> ensure this path are in everyone's PATH.

Why can't execlineb add this to its PATH automatically?

> I find this package has option like `--enable-absolute-paths`, but as
> a result it doesn't work as I expect. When I contact upstream[2],
> upstream thinks these binaries should be in default PATH.
> 
> Any advice with packaging, can I install these binaries in default
> PATH(like /usr/bin)?

They should not be installed in the default PATH.  They don't appear to
be generally useful, and they are likely to be actively confusing. 
(Especially if you install manual pages for them all, which policy says
you should.)

Ben.

> [1] https://skarnet.org/software/execline/
> [2] https://www.mail-archive.com/skaware@list.skarnet.org/msg01225.html
> 
-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.




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

Bug#904309: RFP: tilda -- [SHORT DESCRIPTION]

[Ben Hutchings]

Control: reassign -1 tilda 1.4.1-2
Control: tag -1 moreinfo

Don't use "wnpp" for actual bugs.

You need to explain how to reproduce this bug.

Ben.

On Mon, 2018-07-23 at 14:45 +0800, Valessio Brito wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> --- Please fill out the fields below. ---
> 
>Package name: tilda
> Version: 1.4.1-2
> Upstream Author: Sebastian Geiger 
> URL: http://github.com/lanoxx/tilda
> 
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-
> gnu/libthread_db.so.1".
> [New Thread 0x7fffedc0d700 (LWP 10935)]
> [New Thread 0x7fffed40c700 (LWP 10936)]
> [New Thread 0x7fffecc02700 (LWP 10937)]
> [New Thread 0x7fffdf85c700 (LWP 10938)]
> [New Thread 0x7fffdf05b700 (LWP 10939)]
> [New Thread 0x7fffde5e8700 (LWP 10940)]
> [New Thread 0x7fffddde7700 (LWP 10941)]
> [New Thread 0x7fffdd5e6700 (LWP 10942)]
> [New Thread 0x7fffdcde5700 (LWP 10943)]
> 
> Thread 1 "tilda" received signal SIGSEGV, Segmentation fault.
> 0x75ea4339 in XGetModifierMapping () from /usr/lib/x86_64-
> linux-gnu/libX11.so.6
> 
-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.



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

Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

[Ben Hutchings]

On Fri, 2018-07-20 at 15:12 +0200, Marco d'Itri wrote:
> On Jul 20, Guillem Jover  wrote:
> 
> > > And this means that perl (a libcrypt dependency) would be broken between 
> > > 1 and 5 (or maybe 1 and 3): is this ever going to work?
> > 
> > Given that this new package is going to replace a part of glibc, it
> > will need to behave as if it was part of the pseudo-Essential package
> > set. When it comes to the diversion that means it needs to be added
> > *without* the rename, so that we always have the libcrypt.so.1 present.
> 
> I am not sure about how this would work: can you point me to an example 
> package?
> 
> > But otherwise why would it be broken?
> 
> Because indeed when using dpkg-divert --rename the file would be missing 
> for some time.
[...]

I think you can do something like:

# build time: install libraries in a subdirectory to avoid conflict
make install libdir=/lib/$DEB_HOST_MULTIARCH/libxcrypt1

# postinst time: use link & rename to replace working version atomically.
# $DEB_HOST_MULTIARCH actually needs to be substituted at build time.
for src in /lib/$DEB_HOST_MULTIARCH/libxcrypto/libcrypt.so.*; do
dst=/lib/$DEB_HOST_MULTIARCH/$(basename $src)
dpkg-divert --package libxcrypt1 --add --divert $dst $dst.glibc
ln $dst $dst.glibc
ln $src $dst.xcrypto
mv $dst.xcrypto $dst
done

# prerm time: just rename
for src in /lib/$DEB_HOST_MULTIARCH/libxcrypto/libcrypt.so.*; do
dst=/lib/$DEB_HOST_MULTIARCH/$(basename $src)
dpkg-divert --package libxcrypt1 --remove --divert $dst $dst.glibc
mv $dst.glibc $dst
done

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.



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

Bug#884641: ITP: lwip -- small implementation of the TCP/IP protocol suite

[Ben Hutchings]

On Tue, 2017-12-19 at 12:11 +0100, Samuel Thibault wrote:
> Ben Hutchings, on mar. 19 déc. 2017 03:37:03 +, wrote:
> > On Mon, 2017-12-18 at 01:44 +0100, Samuel Thibault wrote:
> > > Ben Hutchings, on lun. 18 déc. 2017 00:37:48 +, wrote:
> > > > On Mon, 2017-12-18 at 00:12 +0100, Samuel Thibault wrote:
> > > > > It can be used as a maintained user-land TCP/IP stack.
> > > > 
> > > > Why would this be useful for Debian systems, which already have a much
> > > > better performing TCP/IP stack?
> > > 
> > > But the kernel-provided stack can't be manipulated by userland for
> > > e.g. VPNs, ppp, etc. without having to be root.
> > 
> > [...]
> > 
> > Not quite.  On Linux you need CAP_NET_ADMIN in some user namespace.
> 
> Which is not so much more available.
> 
> > (In Debian this feature is guarded by a sysctl that's off by default,
> > as a security mitigation.)
> 
> And thus is not generally available in installed systems.
> 
> > Even if that's disabled, a privileged container manager can create a
> > new user namespace and start a container within that namespace with the
> > CAP_NET_ADMIN capability.
> 
> Which doesn't usually happen on installed systems.  I won't event try,
> I'm sure admins of my work clusters will refuse to enable this, for fear
> of the security consequences.

But they would be happy to let you run an alternate TCP/IP stack that
is invisible to standard administrative tools?

> > To use lwip you would presumably need raw access to a network device,
> > which also requires a privileged capability.
> 
> Not if it's a vpn or ppp over USB, etc., precisely.

Direct access to USB serial devices is privileged, but you're right
that anyone can run a VPN on top of TCP or UDP.

> It is exactly the kind of reason why qemu's user-land TCP/IP stack is
> the default.

But it doesn't work very well (slow, and only forwards TCP and UDP).

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.



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

Bug#884641: ITP: lwip -- small implementation of the TCP/IP protocol suite

[Ben Hutchings]

On Mon, 2017-12-18 at 01:44 +0100, Samuel Thibault wrote:
> Ben Hutchings, on lun. 18 déc. 2017 00:37:48 +, wrote:
> > On Mon, 2017-12-18 at 00:12 +0100, Samuel Thibault wrote:
> > > It can be used as a maintained user-land TCP/IP stack.
> > 
> > Why would this be useful for Debian systems, which already have a much
> > better performing TCP/IP stack?
> 
> But the kernel-provided stack can't be manipulated by userland for
> e.g. VPNs, ppp, etc. without having to be root.
[...]

Not quite.  On Linux you need CAP_NET_ADMIN in some user namespace.  To
use lwip you would presumably need raw access to a network device,
which also requires a privileged capability.

If you enable unprivileged user namespaces in Linux then any user is
allowed to create a new user namespace, and a net namespace owned by
it, and then to create and configure various kinds of virtual device
within that net namespace.  (In Debian this feature is guarded by a
sysctl that's off by default, as a security mitigation.)

Even if that's disabled, a privileged container manager can create a
new user namespace and start a container within that namespace with the
CAP_NET_ADMIN capability.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.



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

Bug#884641: ITP: lwip -- small implementation of the TCP/IP protocol suite

[Ben Hutchings]

On Mon, 2017-12-18 at 00:12 +0100, Samuel Thibault wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Samuel Thibault <sthiba...@debian.org>
> 
> * Package name: lwip
>   Version : 2.0.3
>   Upstream Author : Adam Dunkels <a...@sics.se>
> Leon Woestenberg <leon.woestenb...@gmx.net>
> * URL : http://savannah.nongnu.org/projects/lwip/
> * License : BSD
>   Programming Lang: C
>   Description : small independent implementation of the TCP/IP protocol 
> suite
> 
> lwIP is a small independent implementation of the TCP/IP protocol
> suite that has been developed by Adam Dunkels at the Computer and
> Networks Architectures (CNA) lab at the Swedish Institute of Computer
> Science (SICS).
> 
> The focus of the lwIP TCP/IP implementation is to reduce the RAM usage
> while still having a full scale TCP. This making lwIP suitable for use
> in embedded systems with tens of kilobytes of free RAM and room for
> around 40 kilobytes of code ROM.
> 
> It can be used as a maintained user-land TCP/IP stack.

Why would this be useful for Debian systems, which already have a much
better performing TCP/IP stack?  (At least Linux and FreeBSD do; I
don't know about Hurd.)

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.



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

Bug#882640: RFP: dm-zoned-tools -- utilities for the dm-zoned device mapper

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: dm-zoned-tools
  Version : 1.0.0 (?)
  Upstream Author : Western Digital
* URL : https://github.com/hgst/dm-zoned-tools
* License : GPL-3
  Programming Lang: C
  Description : Utilities for the dm-zoned device mapper

The dm-zoned device mapper provides transparent write access to zoned block
devices (ZBC and ZAC compliant devices). It hides to the device user (a file
system or an application doing raw block device accesses) any sequential write
constraint on host-managed devices and can mitigate potential device-side
performance degradation with host-aware zoned devices.

The dmzadm utility is needed to set up a device with dm-zoned.

Bug#881513: O: rfkill -- tool for enabling and disabling wireless devices

[Ben Hutchings]

Control: retitle -1  ITA: rfkill -- tool for enabling and disabling wireless 
devices
Control: owner -1 !

I think I can adopt this, possibly under the umbrella of the kernel
team.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.



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

Bug#881513: O: rfkill -- tool for enabling and disabling wireless devices

[Ben Hutchings]

retitle -1  ITA: rfkill -- tool for enabling and disabling wireless devices
owner -1 !

I think I can adopt this, possibly under the umbrella of the kernel team.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.


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

Bug#879714: ITP: libusbauth-configparser1 -- Library for USB Firewall including flex/bison parser

[Ben Hutchings]

On Wed, 2017-10-25 at 00:44 +0200, Stefan Koch wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stefan Koch <stefan.koc...@gmail.com>
> 
> * Package name: libusbauth-configparser1
>   Version : 1.0
>   Upstream Author : Stefan Koch <stefan.koc...@gmail.com>
> * URL : https://github.com/kochstefan/usbauth-all/libusba
> uth-configparser
> * License : LGPL-2.1
>   Programming Lang: C
>   Description : Library for USB Firewall including flex/bison
> parser
> 
> The library is used to read the usbauth config file into data
> structures and is used by usbauth and YaST.
> 
> This work was initially created for SUSE in 2015. Part of it was the
> USB interface authorization for the Linux kernel. It's contained in
> Linux since kernel version 4.4.
> Please add the packages libusbauth-configparser, usbauth, usbauth-
> notifier to debian unstable.

You titled this as an ITP (Intent To Package) but this sentence makes
it sound like an RFP (Request For Package).  Which is it?

Ben.

> See also: openSUSE package request
> (https://build.opensuse.org/request/show/533512)
> 
-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg



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

Bug#874339: ITP: rpy2-2.8 -- Python interface to the GNU R language and environment

[Ben Hutchings]

On Tue, 2017-09-05 at 08:39 +0100, Tobias Hansen wrote:
> Package: wnpp
> Severity: wishlist
> > Owner: Tobias Hansen <than...@debian.org>
> 
> * Package name: rpy2-2.8
>   Version : 2.8.6
>   Upstream Author : Laurent Gautier <lgaut...@gmail.com>
> * URL : https://rpy2.bitbucket.io/
> * License : GPL-2+
>   Programming Lang: C, Python
>   Description : Python interface to the GNU R language and environment
> 
>  This Debian package provides RPy2, a very simple yet robust Python interface
> to the GNU R Programming Language. It can manage different types of R objects,
> and can execute arbitrary R functions, including graphic functions. Rpy2 is a
> rewrite and extension of the older RPy interface.
> 
>  Rpy2 is already in Debian, however Rpy2 2.9 no longer supports Python 2, so
> the Python 2 package was recently removed from Debian. Since sagemath depends
> on rpy2 while using Python 2, this package reintroduces the Python 2 version 
> of
> Rpy2, based on the 2.8 series.

We're aiming to remove Python 2 from Debian, so it doesn't make sense
to introduce another reverse dependency on it.  sagemath should be
changed to work with Python 3 only.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.



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

Bug#872795: ITP: adv-17v35x-dkms -- DKMS source for Advantech PCIe Multiport device driver

[Ben Hutchings]

On Mon, 2017-08-21 at 13:36 +0300, Andrey Drobyshev wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andrey Drobyshev <immortalguard...@redlab-i.ru>
> 
> * Package name: adv-17v35x-dkms
>   Version : 5.0.3.0
>   Upstream Author : Advantech Co., Ltd
> * URL : 
> http://support.advantech.com/support/DownloadSRDetail_New.aspx?Doc_Source=Download_ID=1-1W8FZ5
> * License : GPL-2+
>   Programming Lang: C
>   Description : DKMS source for Advantech PCIe Multiport device driver
> 
> This serial driver provides kernel support for various multiport Advantech
> boards. Driver sources are taken from support.advantech.com (search for
> "Linux Driver for ACOM").
> 
> This package is aimed to provide DKMS sources for the driver.

These devices ought to be supported by the in-tree 8250_exar driver,
though it doesn't appear to match the Advantech device IDs yet.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an
expert.



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

Bug#862698: ITP: minecraft -- blocks to build anything you can imagine

[Ben Hutchings]

On Mon, 2017-05-15 at 18:40 -0300, Carlos Donizete Froes wrote:
> Package: wnpp
> Severity: wishlist
> > Owner: Carlos Donizete Froes <corin...@riseup.net>
> 
> * Package name: minecraft
>   Version : 0.1
>   Upstream Author : Carlos Donizete Froes <corin...@riseup.net>
> * URL : https://minecraft.net

You are not the author of that Minecraft.

> * License : BSD-2-Clause
>   Programming Lang: Shell
>   Description : blocks to build anything you can imagine
> 
>  A fantastic game that mixes creativity, survival, and exploration.
>  .
>  Survive alone in a blockys, pìxelated world where monsters come out at night.
>  .
>  Create fantastical buildings and structures, or collaborate with other
>  players online.

What are you proposing to package here?  Is this a downloader for
Microsoft's Minecraft game, or is it a clone?  In either case I think
the package needs to be changed to avoid trademark infringement.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.



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

Bug#862311: ITP: hfi1-firmware -- non-free firmware for Intel Omni-Path hfi1 fabric interface

[Ben Hutchings]

On Wed, 2017-05-10 at 22:31 -0500, Brian T. Smith wrote:
[...]
> Debian stretch, kernel 4.9.0-2-amd64 includes the hfi1 module that provides
> kernel-space ibverbs access to Omni-Path hardware for network communications.
> However, the hfi1 module requires non-free firmware in order for the module to
> properly initialize.
> 
> This package will provide the required firmware for hfi1 hardware. The 
> upstream
> URL contains many firmware images. The only binaries that will be installed by
> this package are:
> 
>   * hfi1_dc8051.fw
>   * hfi1_fabric.fw
>   * hfi1_pcie.fw
>   * hfi1_platform.dat
>   * hfi1_sbus.fw
> 
> I have been maintaining the Intel Fabric Suite for Omni-Path on Debian for
> the past year as an employee of System Fabric Works (SFW). SFW has adequate
> hardware and resources to test and maintain this package.

These are already part of linux-firmware.git so they could (and I think
should) be packaged through firmware-nonfree, not in a separate source
package.

Despite the freeze, it's still OK to add new hardware support and so
you could get this firmware into stretch.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be
sure.



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

Bug#855074: RFP: installer -- [SHORT DESCRIPTION]

[Ben Hutchings]

Control: reassign -1 installation-reports
Control: retitle -1 installation-reports: Debian 7.9 - wrong keymap active in 
initramfs
Control: tag -1 moreinfo

On Mon, 2017-02-13 at 21:58 +0100, Rolf Heinrichs wrote:
> Package: wnpp

This is a bug category for planning new Debian packages or transferring
maintainership of package, not for bugs in existing packages.

In future, try to work out which package the bug is in, or use
'installation-reports' for bugs that appear on installation.

> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> --- Please fill out the fields below. ---
> 
>    Package name: installer
> Version: Wheezy
> Upstream Author: [NAME <n...@example.com>]
> URL: [http://example.com]
> License: [GPL, LGPL, BSD, MIT/X, etc.]
> Description: [DESCRIPTION]
> 
> 
> Wheezy amd64 7.9.0 DVD, setup with graphical installer, using Germany as
> country, a German keyboard and setup of an encrypted drive: after boot
> the complex key for decrypting the drive is not accepted by the
> initramfs. The key contains special characters like capital letters and
> characters like ~{[| that require a key combination with ALT GR on the
> German keyboard. 
> 
> Also in the maintenance console, you cannot enter caps or special
> characters.  

This sounds similar to <https://bugs.debian.org/689851>, which affects
use with console-tools.

In the rescue shell, please check whether these files exist:
- /bin/loadkeys
- /etc/boottime.kmap.gz

Also please try using the installer's rescue mode to start a shell in
the installed system, and report the output of these commands:
- grep KEYMAP= /etc/initramfs-tools/initramfs.conf
- dpkg-query -W console-tools
- dpkg-query -W kbd

> Crosscheck was done with graphical installer and a simple key that did
> not require caps or ALT GR: key is accepted. The complex key worked fine
> when using the default CLI installer.
> 
> Looks like the graphical installer does not set the correct keymap.  

There is only one installer, with these two different interface modes. 
So it's hard to imagine why the behaviour of the installed system would
 differ.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.


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

Bug#854606: ITP: libnfc-nci -- NFC stack for NCI based NFC Controllers by NXP

[Ben Hutchings]

On Wed, 2017-02-08 at 11:28 -0500, Josua Mayer wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Josua Mayer <josua.maye...@gmail.com>
> 
> * Package name: libnfc-nci
>   Version : 2.1
>   Upstream Author : NXP Semiconductors
> * URL : https://github.com/NXPNFCLinux/linux_libnfc-nci
> * License : Apache-2.0
>   Programming Lang: C
>   Description : NFC stack for NCI based NFC Controllers by NXP
>
> This library provides an abstracted interface to NFC controllers in order 
> to build applications that make use of nfc technology.
> Description to be revised!
> 
> This library is provided by NFC to facilitate development of nfc enabled 
> applications.
> It currently has support for the pn7120 and pn7150 chips.

This doesn't look suitable for Debian.  Although it can be used with
GNU/Linux, it is clearly designed for Android.  Debian already
provides:

- Linux kernel NFC stack and drivers, providing a socket interface
- libnfc, providing a generic interface to many (mostly USB-attached)
  NFC controllers

I don't see a lot of value in adding a third, vendor-specific stack
that's incompatible with anything else packaged in Debian.

[...]
> However this library can be used with devices and nfc addon boards by other 
> vendors providing they feature a supported nfc chip.
> Such it could benefit a much broader audience than just SR customers.
[...]

Really?  The documentation says it's specific to NXP PN5xx.

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
Inside every large problem is a small problem struggling to get
out.



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

Bug#854181: RFH: busybox -- Tiny utilities for small and embedded systems

[Ben Hutchings]

On Sat, 2017-02-04 at 19:16 +0100, Cyril Brulebois wrote:
[...]
> The busybox-udeb package is one of the basic building blocks of the
> Debian Installer, which means that busybox maintenance includes making
> sure any regressions spotted there can be fixed in a timely manner.

Plus it's used by initramfs-tools (by default).

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai
Stevenson



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

Bug#850222: ITP: node-plur -- Pluralize a word

[Ben Hutchings]

On Thu, 2017-01-05 at 13:05 +0530, Abhishek Lolage wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Abhishek Lolage <abhisheklol...@gmail.com>
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-plur
>   Version : 2.1.2
>   Upstream Author : Sindre Sorhus <sindresor...@gmail.com> (sindresorhus.com)
> 
> * URL : https://github.com/sindresorhus/plur
> * License : Expat
>   Programming Lang: JavaScript
>   Description : Pluralize a word

(as long as it's English)

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



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

Bug#850220: ITP: node-get-port -- Get an available port

[Ben Hutchings]

On Thu, 2017-01-05 at 12:23 +0530, Nupur Malpani wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nupur Malpani <malpaninupur...@gmail.com>
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-get-port
>   Version : 2.1.0
>   Upstream Author : Sindre Sorhus <sindresor...@gmail.com> (sindresorhus.com
> )
> * URL : https://github.com/sindresorhus/get-port
> * License : Expat
>   Programming Lang: JavaScript
>   Description : Get an available port

Isn't this inherently racy?  It looks like it creates a listening
socket, closes it, then returns the port that was used.  But the port
could immediately be allocated by another process, before the caller
tries to use it.

If I understood correctly, this should not be packaged and whatever
depends on it should be fixed to avoid the race condition.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



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

Bug#849338: ITP: hxtools -- Collection of tools and scripts

[Ben Hutchings]

On Sun, 2016-12-25 at 23:59 +0100, Guus Sliepen wrote:
[...]
> >   * declone(1) - break hardlinks
> 
> Maybe something for coreutils?

Or moreutils.

[...]
> >   * newns(8) - clone current filesystem namespace and start a process
> 
> Sounds like something for util-linux,
[...]

util-linux already has unshare(1), but if newns does something extra
then maybe unshare should be extended.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.



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

Bug#849338: ITP: hxtools -- Collection of tools and scripts

[Ben Hutchings]

On Mon, 2016-12-26 at 10:20 +0100, Jochen Sprickerhof wrote:
> Hi,
> 
> thanks for commenting on my ITP. I dropped debian-devel@ for now, feel
> free to include it again, if it makes sense.
> 
> > * Guus Sliepen <g...@debian.org> [2016-12-25 23:59]:
> > > This package is used by the libpam-mount package (currently patched in).
> > 
> > What exactly of hxtools is used in libpam-mount?
> 
> ofl and fd0ssh (packaged in /usr/bin/pmt-*).
> 
> > * Ben Hutchings <b...@decadent.org.uk> [2016-12-25 23:00]:
> > These look mostly very esoteric; could you consider packaging just the
> > most general and polished ones?
> 
> Good question, I only started packaging it because libpam-mount depend
> on those two tools. Based on your comments, I stripped it down already.
> Comments welcome!
> 
> Also, I guess it make sense to move all of them into /usr/bin instead of
> /usr/lib/.. (libexec by upstream). What do you think?

That makes more sense for a Debian package.

> Cheers Jochen
> 
> -- proposed included content --
> 
> /usr/bin/bin2c

nvidia-cuda-toolkit (!) has /usr/bin/bin2c.

> /usr/bin/checkbrack
> /usr/bin/clock_info
> /usr/bin/clt2bdf
> /usr/bin/declone
> /usr/bin/googtts
> /usr/bin/gpsh
> /usr/bin/hcdplay
> /usr/bin/move_moov
> /usr/bin/ofl
> /usr/bin/pesubst
> /usr/bin/pmap_dirty
> /usr/bin/qtar
> /usr/bin/rot13

bsd-games has /usr/games/rot13, which this would effectively conflict
with.

> /usr/bin/spec-beautifier
> /usr/bin/ssa2srt
> /usr/bin/su1
> /usr/bin/wktimer
>
> /usr/lib/x86_64-linux-gnu/hxtools/bsvplay
> /usr/lib/x86_64-linux-gnu/hxtools/cctypeinfo
> /usr/lib/x86_64-linux-gnu/hxtools/clt2pbm
> /usr/lib/x86_64-linux-gnu/hxtools/diff2php
> /usr/lib/x86_64-linux-gnu/hxtools/fd0ssh
> /usr/lib/x86_64-linux-gnu/hxtools/fnt2bdf
> /usr/lib/x86_64-linux-gnu/hxtools/logontime
> /usr/lib/x86_64-linux-gnu/hxtools/mailsplit
> /usr/lib/x86_64-linux-gnu/hxtools/mod2ogg
> /usr/lib/x86_64-linux-gnu/hxtools/paddrspacesize
> /usr/lib/x86_64-linux-gnu/hxtools/pcmdiff
> /usr/lib/x86_64-linux-gnu/hxtools/peicon
> /usr/lib/x86_64-linux-gnu/hxtools/proc_iomem_count
> /usr/lib/x86_64-linux-gnu/hxtools/proc_stat_parse
> /usr/lib/x86_64-linux-gnu/hxtools/proc_stat_signal_decode
> /usr/lib/x86_64-linux-gnu/hxtools/psthreads
> /usr/lib/x86_64-linux-gnu/hxtools/qplay
> /usr/lib/x86_64-linux-gnu/hxtools/recursive_lower
> /usr/lib/x86_64-linux-gnu/hxtools/rezip
> /usr/lib/x86_64-linux-gnu/hxtools/shared.pm

That one stays in /usr/lib!

> /usr/lib/x86_64-linux-gnu/hxtools/sourcefuncsize
> /usr/lib/x86_64-linux-gnu/hxtools/stxdb
> /usr/lib/x86_64-linux-gnu/hxtools/utmp_register
> /usr/lib/x86_64-linux-gnu/hxtools/vcsaview
> /usr/lib/x86_64-linux-gnu/hxtools/vfontas
[...]

I didn't look at what these all do; I trust that you've done a
sufficient review.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.


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

Bug#849338: ITP: hxtools -- Collection of tools and scripts

[Ben Hutchings]

On Sun, 2016-12-25 at 19:50 +0100, Jochen Sprickerhof wrote:
> Package: wnpp
> Severity: wishlist
> > Owner: Jochen Sprickerhof <jspri...@debian.org>
> 
> * Package name: hxtools
>   Version : 20150304
>   Upstream Author : Jan Engelhardt <jeng...@inai.de>
> * URL : http://inai.de/projects/hxtools/
> * License : GPL, LGPL, WTFPL
>   Programming Lang: C, Perl, Bash
>   Description : Collection of tools and scripts
> 
>  A collection of tools and scripts that have accumulated over the years, and
>  each of which seems to be too small to warrants its own project.

These look mostly very esoteric; could you consider packaging just the
most general and polished ones?

[...]
>   * git-author-stat(1) - show commit author statistics of a git repository
>   * git-blame-stat(1) - show per-line author statistics of a git repository
>   * git-export-patch(1) - produce perfect patch from git commits for mail 
> submission
>   * git-forest(1) - display the commit history forest
>   * git-lemon(1) - don't just pick cherries, but take it all (cherry-pick a 
> commit range)
>   * git-new-root(1) - start a new root in the git history
>   * git-revert-stats(1) - show reverting statistics of a git repository
>   * git-track(1) - set up branch for tracking a remote

Perhaps (some of) these belong in the contrib directory of git
upstream?

[...]
>   * png2wx.pl(1) - transform arbitrary files into C++ files for wxWidgets
[...]
>   * rpmdep.pl(1) - read RPM dependencies and output a graph
[...]

Extensions like .pl in command names are forbidden by policy.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be
sure.



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

Bug#845488: ITP: linux-firmware-raspi3 -- Raspberry Pi 3 GPU firmware and bootloaders

[Ben Hutchings]

On Sun, 2016-11-27 at 22:31 +0100, Michael Stapelberg wrote:
> Given that the package has cleared the NEW queue by now, I’ve just done the
> rename and uploaded the new package. Will file a request for removal for
> the old one once the new one is in.

Thanks.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice
versa.



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

Bug#846366: ITP: bcc -- Command line tools for BPF Compiler Collection (BCC)

[Ben Hutchings]

On Thu, 2016-12-01 at 00:56 +0530, Ritesh Raj Sarraf wrote:
> Hello Karsten,
> 
> On Wed, 2016-11-30 at 20:05 +0100, Karsten Merker wrote:
> > Hello,
> > 
> > bcc is a package (and executable) name that is already in use for
> > another program in Debian. From https://packages.debian.org/sid/bcc:
> 
> I'm aware of it. bcc is an already packaged binary package. It build from 
> source package: linux86
> 
> For this package, I've tried to be close to what upstream has already named.
> So, for Debian, only the source package name is: bcc.
[...]

Please don't do this.  When the same name is used for a binary package
and for a source package that doesn't build that binary, it tends to
result in mis-assigned bugs as BTS users don't consistently specify
which they mean.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai
Stevenson



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

Bug#845488: ITP: linux-firmware-raspi3 -- Raspberry Pi 3 GPU firmware and bootloaders

[Ben Hutchings]

On Wed, 2016-11-23 at 22:37 +0100, Michael Stapelberg wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Michael Stapelberg <stapelb...@debian.org>
> 
> * Package name: linux-firmware-raspi3

Is this really Linux-specific?  If not, please consider dropping the
'linux-' part.

Ben.

>   Version : 1.20161123
>   Upstream Author : Raspberry Pi Foundation
> * URL : https://github.com/raspberrypi/firmware
> * License : Proprietary
>   Description : Raspberry Pi 3 GPU firmware and bootloaders
> 
>  This package contains all the proprietary files necessary to boot a
>  Raspberry Pi 3 board.
>  .
>  Raspberry Pi is a trademark of the Raspberry Pi Foundation.
> 
> This package will be maintained by the newly created pkg-raspi team, and
> is one of the last few pieces of the puzzle to create Debian images for
> the Raspberry Pi 3. The package is based on the linux-firmware-raspi2
> package from Ubuntu.
> 
-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought.
... I realized that a large part of my life from then on was going to
be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949



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

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Ben Hutchings]

You've already commented the silent failure mode, so it's not that hard
to find.

As for 'is it problem?', why do you think I pointed these things out?
Perhaps you have good reasons to do things in an unusual way, but in
the absence of comments to explain them I infer that you either don't
know or have arbitrarily rejected conventional approaches.  Which you
seem to confirm by saying:

> I will NEVER use str* functions from libc in my code.

I'm ending this conversation here; ultimately it's for prospective
sponsors to decide whether it is a good idea to introduce this program
into Debian in its current shape.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



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

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Ben Hutchings]

Jan Mojzis  wrote:
[...]
> I'm going to maintain the package using collab-maint.
> I need sponsor.
>
> Debian package:
>  - has autotest
>  - is using debhelper
>  - is using git-dpm https://anonscm.debian.org/cgit/collab-maint/extr
emetools.git
>  - lintian clean (no warnings)

However, the code:

- Has a silent failure mode
- Reinvents common C library functions like strtol(), getopt(),
strerror()
- Defines many similar functions differing only in number of arguments,
where a varargs function would be appropriate
- Doesn't have a 'make install' rule
- Has manually maintained dependencies on headers

I really think you should get a little more experience with C and
makefiles, and a full code review, before packaging something that aims
to be a security-critical tool.

Ben.


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

Bug#839210: Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals

[Ben Hutchings]

On Mon, 2016-10-03 at 17:51 +0200, Pascal Grange wrote:
> Description is taken from the upstream. I would rather talk about
> sarcastic marketing, but sure, can remove it. 

I suspected it might be, but Debian package descriptions are supposed
to be straightforward and boring. :-)

> That would leed to the following description :
> Description : bash unit testing framework
[...]

Yes, that is more appropriate.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special
case.


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

Bug#839279: ITP: gocryptfs -- Encrypted overlay filesystem written in Go

[Ben Hutchings]

On Sat, 2016-10-01 at 09:03 -0400, David Steele wrote:
> On Sat, Oct 1, 2016 at 7:58 AM, Ben Hutchings <b...@decadent.org.uk>
> wrote:
> > 
> > On Sat, 2016-10-01 at 02:35 +, David Steele wrote:
> > > 
> > > Package: wnpp
> > > Severity: wishlist
> > > > 
> > > > Owner: David Steele <ste...@debian.org>
> > > 
> > > * Package name: gocryptfs
> > 
> > What benefits does it provide over ecryptfs, which is already
> > supported
> > in Debian?
> > 
> 
> https://nuetzlich.net/gocryptfs/comparison/

OK, but it would be helpful to summarise the main advantages, like:

- Includes integrity checking
- Doesn't leak information about names of encrypted files

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


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

Bug#839279: ITP: gocryptfs -- Encrypted overlay filesystem written in Go

[Ben Hutchings]

On Sat, 2016-10-01 at 02:35 +, David Steele wrote:
> Package: wnpp
> Severity: wishlist
> > Owner: David Steele <ste...@debian.org>
> 
> * Package name: gocryptfs
>   Version : 1.0
> >   Upstream Author : Jakob Unterwurzacher <jakob...@gmail.com>
> * URL : https://nuetzlich.net/gocryptfs/
> * License : Expat
>   Programming Lang: Go
>   Description : Encrypted overlay filesystem written in Go
> 
> gocryptfs is built on top the excellent go-fuse
> > (https://github.com/hanwen/go-fuse) FUSE library and its
> LoopbackFileSystem API.
> 
> This project was inspired by EncFS and strives to fix its
> security issues while providing good performance (benchmarks
> > (https://nuetzlich.net/gocryptfs/comparison/#performance)).
> 
> For details on the security of gocryptfs see the Security
> > (https://nuetzlich.net/gocryptfs/security/) design document.
[...]

What benefits does it provide over ecryptfs, which is already supported
in Debian?

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


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

Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals

[Ben Hutchings]

On Fri, 2016-09-30 at 08:53 +0200, Pascal Grange wrote:
> Package: wnpp
> Severity: wishlist
> > Owner: Pascal Grange <pas...@grange.nom.fr>
> 
> * Package name: bash-unit
>   Version : 1.0.2
> >   Upstream Author : Pascal Grange <pas...@grange.nom.fr>
> * URL : https://github.com/pgrange/bash-unit
> * License : GPL
>   Programming Lang: Bash
>   Description : bash unit testing enterprise edition framework for 
> professionals
[...]

Please leave vague marketing terms ('enterprise', 'for professionals')
out of the package description.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


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

Bug#832451: ITP: aufs4 -- advanced multi layered unification filesystem version 4.x

[Ben Hutchings]

On Mon, 2016-07-25 at 21:05 +0200, Thomas Goirand wrote:
> On 07/25/2016 06:12 PM, Jan Luca Naumann wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Jan Luca Naumann <j.naum...@fu-berlin.de>
> > 
> > * Package name: aufs4
> >   Version : 4.6+20160523
> >   Upstream Author : Junjiro R. Okajima <hooanon...@gmail.com>
> > * URL : http://aufs.sourceforge.net/
> > * License : GPL2+
> >   Programming Lang: C
> >   Description : advanced multi layered unification filesystem
> > version 4.x
> > 
> > Aufs is a stackable unification filesystem such as Unionfs, which
> > unifies
> > several directories and provides a merged single directory.
> > In the early days, aufs was entirely re-designed and re-implemented
> > Unionfs Version 1.x series. After
> > many original ideas, approaches and improvements, it
> > becomes totally different from Unionfs while keeping the basic
> > features.
> > See Unionfs Version 1.x series for the basic features.
> > Recently, Unionfs Version 2.x series begin taking some of same
> > approaches to aufs's.
> > 
> > I'm intending to package the version 4.x for Debian. The module
> > should use dkms to be build as kernel module.
> > 
> > I hope to do the work as part of the filesystems project on Alioth:
> > https://alioth.debian.org/projects/filesystems/
> > 
> > I need a sponsor for the package.
> 
> We have already overlayfs in modern kernels. Could you explain why we
> need aufs4 as well?

I believe aufs stil has these advantages over overlayfs:

- Can be exported via NFS
- White-outs share an inode rather than
requiring an inode each
- Sparse files remain sparse when copied-up
-
Multiple writeable branches
- Creating a hard link does not require a
copy-up

Ben.

-- 

Ben Hutchings
Knowledge is power.  France is bacon.


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

Bug#829257: RFP: ndctl -- NVDIMM management utility

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: ndctl
  Version : 53.1
  Upstream Author : Dan Williams 
* URL : https://github.com/pmem/ndctl
* License : LGPL 2.1
  Programming Lang: C
  Description : NVDIMM management utility

ndctl is a utility for managing the "libnvdimm" kernel subsystem.
This includes provisioning capacity (namespaces) and enumerating,
enabling and disabling the devices associated with an NVDIMM bus.

Bug#825785: ITP: tab -- Typesetter for lute tablature

[Ben Hutchings]

On Sun, 2016-05-29 at 22:47 +0100, Chris Lamb wrote:
> > 
> > Should be lute-tab or something like that.
> 
> That just seems to be the GitHub repo name, upstream seems to call it
> "Tab":
> 
>  http://www.cs.dartmouth.edu/~wbc/lute/AboutTab.html
> 
> .. and the binary is called "tab".
> 
> Would you still suggest the "lute" prefix?

I would - 'tab' is a very generic name and is also used to refer to
other kinds of tablature notation, a control character, a user
interface element, etc.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#825785: ITP: tab -- Typesetter for lute tablature

[Ben Hutchings]

On Sun, 2016-05-29 at 21:36 +0100, Chris Lamb wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Chris Lamb <la...@debian.org>
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: tab

Should be lute-tab or something like that.

Ben.

>   Upstream Author : Wayne Cripps
> * URL : https://github.com/mandovinnie/Lute-Tab
> * License : BSD
>   Programming Lang: C
>   Description : Typesetter for lute tablature
> 
> Tab is a typesetter for lute tablature for renaissance and baroque
> lutes and theorboes, in both French and Italian notation. You edit a
> plain text file with special commands to enter the lute tablature,
> then you run tab to convert that input into PostScript output that
> you can print or display with the right program.
> 
> 
> Regards,
> 
-- 
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding
stump
of a severed limb. - me, 29 June 1999


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

Bug#702255: efitools: changing back from ITP to RFP

[Ben Hutchings]

On Wed, 23 Sep 2015 13:43:24 +0200 Pierre Chifflier <pol...@debian.org> wrote:
> retitle 702255 ITP: efitools -- Tools to manipulate EFI secure boot keys and 
> signatures
> owner 702255 !
> block 702255 by 702254
> thanks
> 
> Hi,
> 
> I've finally managed to get some time to work again on this ITP.
> 
> I've uploaded the sbsigntool package to NEW (See #702254), which is
> required to build efitools. If/when sbsigntool is accepted, upload for
> efitools will follow.

Go on then!

Ben.
 
-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'

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

Bug#820614: ITP: vuls -- package inventory scanner for CVE vulnerabilities

[Ben Hutchings]

On Sun, 2016-04-10 at 16:45 +0200, Daniel Stender wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Stender <sten...@debian.org>
> 
> * Package name: vuls
>   Version : 0.1.1
>   Upstream Author : Kota Kanbe <kotaka...@gmail.com>
> * URL : https://github.com/future-architect/vuls
> * License : GPL-3
>   Programming Lang: Google Go
>   Description : package inventory scanner for CVE vulnerabilities
> 
> This is scanner which checks the package inventory against a local copy of
> the National Vunerabilities Database (NVD) of vulnerabilities according to
> their CVE (Common Vulnerabilities and Exposures) indentifiers. The backends
> supports a couple of OSs (Debian, RHEL, CentOS, Amazon Linux). Scanning 
> servers
> over the network is possible.
[...]

Presumably this uses the secure-testing data for Debian?

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

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

Bug#820052: RFP: uefi-shim -- UEFI shim boot loader to support Secure Boot

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: uefi-shim
  Version : 0.9
  Upstream Author : Red Hat, Inc
* URL : https://github.com/rhinstaller/shim
* License : OpenSSL license (I think)
  Programming Lang: C
  Description : UEFI shim boot loader to support Secure Boot

Bug#820050: RFP: grub2-signed -- Signed versions of GRUB for UEFI Secure Boot

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: grub2-signed
  Version : 1.65
  Upstream Author : Colin Watson 
* URL : https://launchpad.net/ubuntu/+source/grub2-signed
* License : GPL-3+
  Programming Lang: Python
  Description : Signed versions of GRUB for UEFI Secure Boot

Bug#820006: ITP: linux-signed -- Signatures for Linux kernel and modules

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings <b...@decadent.org.uk>

* Package name: linux-signed
  Version : 1
  Upstream Author : Ben Hutchings
* URL : https://anonscm.debian.org/cgit/kernel/linux-signed.git/
* License : GPL-2+
  Programming Lang: Python
  Description : Signatures for Linux kernel image and modules

This package will contain detached signatures for Linux kernel
modules, and for the kernel image on architectures that use an
EFI stub.  It is needed to support Secure Boot on amd64, and in
general to harden the kernel against attack.

Bug#811377: Adopting Sysvinit

[Ben Hutchings]

On Tue, 2016-03-01 at 21:49 +0900, Benda Xu wrote:
> Dear Ben,
> 
> I am Benda Xu, one of the maintainers of OpenRC, which uses sysvinit by
> default.
> 
> I would like to adopt sysvinit, as I have been and will be an active
> user.
> 
> Could you please grant me the upload permission?  I am in the Debian
> maintainer database with key 8E192076 and fingerprint:
> 
>   C3A5 0484 0B67 8260 DA12  766A D25D 611C 8E19 2076

I'm not a maintainer for sysvinit, so I leave the decision to the
previous maintainers.

Ben.

-- 
Ben Hutchings - Debian developer, member of Linux kernel and LTS teams



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

Bug#812533: ITP: plugn -- hook system for shell programs

[Ben Hutchings]

On Sun, 2016-01-24 at 18:49 +, Alessio Treglia wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Alessio Treglia <ales...@debian.org>
> 
> * Package name: plugn
>   Version : 0.2.1
>   Upstream Author : Jeff Lindsay
> * URL : http://github.com/dokku/plugn
> * License : BSD
>   Programming Lang: Go
>   Description : hook system for shell programs
> 
> The plugn command loops through all enabled plugins'
> directories found in the path defined by the environment
> variable PLUGIN_PATH and passes the same arguments to
> any hook scripts by that name.
> 
> plugn provides a mechanism for arguments broadcasting,
> it could accept streams and pass them through each plugin
> as well.

What does this do that run-parts can't?

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.

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

Bug#812373: ITP: odhcp6c -- IPv6 DHCP and RA client from OpenWRT

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings <b...@decadent.org.uk>

* Package name: odhcp6c
  Version : 1.1
  Upstream Author : Steven Barth <ste...@midlink.org>
* URL : https://github.com/sbyx/odhcp6c
* License : GPLv2
  Programming Lang: C
  Description : IPv6 DHCP and RA client from OpenWRT

odhcp6c is a minimal DHCPv6 and RA-client for use in embedded Linux
systems especially routers.  It is intended to comply with RFC7084.
Unlike isc-dhcp-client, it can be used with PPP links.

[I have yet to verify that it does actually work over PPP, but the
OpenWRT documentation implies that it does.]

Bug#811377: RFA: sysvinit -- System-V-like init utilities - transitional package

[Ben Hutchings]

An additional point from Petter Reinholdtsen:

09:39 < pere> bwh: note, the insserv and startpar packages are part of the 
  sysvinit group of packages, and should probably be handled by the 
  same group of people.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special case.

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

Bug#811377: RFA: sysvinit -- System-V-like init utilities - transitional package

[Ben Hutchings]

Package: wnpp
Severity: normal

I request an adopter for the sysvinit package.

Although it is team-maintained, I have found that none of the listed
uploaders are still active:

- Petter Reinholdtsen says he has retired from maintenance
- Henrique de Moraes Holschuh has not committed for over 6 years
- Kel Modderman has not committed for over 3 years
- Roger Leigh is retired from Debian
- Thomas Goirand says he 'never really was' a maintainer

Ben.

The package description is:
 This package contains programs required for booting
 a Debian system and doing basic process management.
 .
 The most important program in the package is /sbin/init.
 It is the first process started on boot and continues
 to run as process number 1 until the system halts. All
 other processes are descended from it.

Bug#808373: ITP: libwaive -- Allow processes to waive their rights

[Ben Hutchings]

On Sat, 2015-12-19 at 20:33 +1100, Riley Baird wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Riley Baird 
> 
> * Package name: libwaive
>   Version : 1.0.0+git20151218.a0e8c1
>   Upstream Author : Dima Krasner <d...@dimakrasner.com>
> * URL : https://github.com/dimkr/libwaive
> * License : MIT
>   Programming Lang: C
>   Description : Allow processes to waive their rights
> 
> libwaive is a tiny library that provides waive(), a function that allows a
> process to waive its right to perform certain actions (e.g. open a file).
> 
> It is inspired by Theo de Raadt's tame() system call
> (http://article.gmane.org/gmane.os.openbsd.tech/43085)

libwaive takes a blacklisting approach, which is fundamentally
insecure.  For example, WAIVE_EXEC is supposed to prevent loading an
executing new code, but it doesn't block the new execveat() system
call.  At any time, Linux may be extended with new variants of old
system calls, and those new unknown system calls need to be blocked as
well.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.

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

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Ben Hutchings]

On Sat, 2015-12-19 at 17:03 +, Jacob Appelbaum wrote:
> On 12/19/15, Jacob Appelbaum <ja...@appelbaum.net> wrote:
[...]
> > To boot Debian Jessie (with some testing pacakes too) to X - I had to set:
> > 
> > kernel.grsecurity.disable_priv_io=0
> > kernel.pax.softmode=1
> > kernel.grsecirity.grsec_lock=0
> > 
> 
> With that stuff set - I also see the following:
> 
> Dec 19 17:44:32 vula kernel: [ 4047.508272] WARNING: CPU: 5 PID: 2109
> at /build/linux-grsec-4.3.3/debian/build/s
> ource_grsec/include/drm/drm_crtc.h:1577
> drm_helper_choose_crtc_dpms+0x8e/0x90 [drm_kms_helper]()
[...]
> Lots of things like that in my kernel log...

Almost certainly an upstream bug.  See
<https://wiki.freedesktop.org/nouveau/Bugs/> for bug reporting.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.

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

Bug#806516: ITP: booleanoperations -- Boolean operations on paths

[Ben Hutchings]

On Sat, 2015-11-28 at 18:51 +0900, Hideki Yamane wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Hideki Yamane <henr...@debian.org>
> 
> * Package name: booleanoperations

That seems an overly generic name for something that's specific to
fonts(?).  (And adding the customary 'python-' prefix to the binary
package won't change that.)

Ben.

>   Version : 0.1
>   Upstream Author : Frederik Berlaen <frede...@typemytype.com>
> * URL : https://github.com/typemytype/booleanOperations
> * License : MIT
>   Programming Lang: python, C++
>   Description : Boolean operations on paths
> 
>  Boolean operations on paths based on a super fast polygon clipper
> library.
> 
-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy 1981-1987


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

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Ben Hutchings]

On Tue, 2015-11-10 at 10:42 +0100, Yves-Alexis Perez wrote:
> On sam., 2015-11-07 at 14:54 +0000, Ben Hutchings wrote:
> > I've given this a quick review and found a few issues:
> 
> Thanks!
> > 
> > 1. linux-grsec-{source,support} are included in debian/control but not
> > built by debian/rules.real.  I think these should be built; the latter
> > will be needed to build metapackages as in linux-latest.
> 
> Done. Right now the package name is hardcoded in debian/rules.real, I'll see
> if there's a way to get it from the configuration somehow (after I get more
> info from the #3 and #4 replies).

This seems to work:

--- a/debian/rules.real
+++ b/debian/rules.real
@@ -13,6 +13,7 @@ DEB_HOST_MULTIARCH:= $(shell dpkg-architecture -a'$(ARCH)' 
-qDEB_HOST_MULTIARCH)
 DEB_BUILD_ARCH:= $(shell dpkg-architecture -a'$(ARCH)' -qDEB_BUILD_ARCH)
 endif
 MAINTAINER := $(shell sed -ne 's,^Maintainer: .[^<]*<\([^>]*\)>,\1,p' 
debian/control)
+SOURCE_PACKAGE_NAME := $(shell dpkg-parsechangelog -SSource)
 DISTRIBUTION := $(shell dpkg-parsechangelog -SDistribution)
 SOURCE_DATE := $(shell dpkg-parsechangelog -SDate)
 SOURCE_DATE_UTC_ISO := $(shell date -u -d '$(SOURCE_DATE)' +%Y-%m-%d)
@@ -191,7 +192,7 @@ install-dummy:
    dh_prep
    +$(MAKE_SELF) install-base
 
-install-doc: PACKAGE_NAME = linux-doc-$(VERSION)
+install-doc: PACKAGE_NAME = $(SOURCE_PACKAGE_NAME)-doc-$(VERSION)
 install-doc: DIR = $(BUILD_DIR)/build-doc
 install-doc: PACKAGE_DIR = debian/$(PACKAGE_NAME)
 install-doc: OUT_DIR = $(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)
@@ -210,7 +211,7 @@ install-doc: $(STAMPS_DIR)/build-doc
    gzip -9nqfr $(OUT_DIR)/Documentation
    +$(MAKE_SELF) install-base
 
-install-manual: PACKAGE_NAME = linux-manual-$(VERSION)
+install-manual: PACKAGE_NAME = $(SOURCE_PACKAGE_NAME)-manual-$(VERSION)
 install-manual: DIR=$(BUILD_DIR)/build-doc
 install-manual: DH_OPTIONS = -p$(PACKAGE_NAME)
 install-manual: $(STAMPS_DIR)/build-doc
@@ -329,7 +330,7 @@ install-libc-dev_$(ARCH):
 
    +$(MAKE_SELF) install-base
 
-install-support: PACKAGE_NAME = linux-support-$(ABINAME)
+install-support: PACKAGE_NAME = $(SOURCE_PACKAGE_NAME)-support-$(ABINAME)
 install-support: DH_OPTIONS = -p$(PACKAGE_NAME)
 install-support: PACKAGE_DIR = debian/$(PACKAGE_NAME)
 install-support: PACKAGE_ROOT = /usr/share/$(PACKAGE_NAME)
@@ -440,7 +441,7 @@ install-udeb_$(ARCH):
    dh_gencontrol
    dh_builddeb
 
-install-source: PACKAGE_NAME = linux-source-$(VERSION)
+install-source: PACKAGE_NAME = $(SOURCE_PACKAGE_NAME)-source-$(VERSION)
 install-source: DH_OPTIONS = -p$(PACKAGE_NAME)
 install-source: $(BUILD_DIR)/linux-source-$(UPSTREAMVERSION).tar.xz $(foreach 
FEATURESET,$(filter-out 
none,$(ALL_FEATURESETS)),$(BUILD_DIR)/linux-patch-$(UPSTREAMVERSION)-$(FEATURESET).patch.xz)
    dh_testdir
--- a/debian/templates/control.main.in
+++ b/debian/templates/control.main.in
@@ -1,4 +1,4 @@
-Package: linux-source-@version@
+Package: @source_package@-source-@version@
 Build-Profiles: 
 Architecture: all
 Section: kernel
@@ -13,7 +13,7 @@ Description: Linux kernel source for version @version@ with 
Debian patches
  features that have already been (or are believed to be) accepted by the
  upstream maintainers.
 
-Package: linux-doc-@version@
+Package: @source_package@-doc-@version@
 Build-Profiles: 
 Architecture: all
 Depends: ${misc:Depends}
@@ -27,7 +27,7 @@ Description: Linux kernel specific documentation for version 
@version@
  /usr/share/doc/linux-doc-@version@/Documentation/00-INDEX
  for the detailed description of the contents.
 
-Package: linux-manual-@version@
+Package: @source_package@-manual-@version@
 Build-Profiles: 
 Architecture: all
 Depends: ${misc:Depends}
@@ -46,7 +46,7 @@ Description: Linux kernel API manual pages for version 
@version@
  may be installed at a time.  The linux-doc package containing the
  documentation in other formats is free from such restriction.
 
-Package: linux-support-@abiname@
+Package: @source_package@-support-@abiname@
 Build-Profiles: 
 Architecture: all
 Section: devel
--- END ---

[...]
> > 3. The changes to gencontrol.py and rules.real to disable most arch:all
> > packages should depend on configuration, not the source package name.
> > They would then be acceptable for inclusion on the master branch.
> 
> By “configuration”, I guess you mean stuff in debian/config/featureset-
> grsec/defines? Unfortunately some of the stuff I touch in gencontrol.py and
> rules.real is not run when featureset is defined, but is more generic than
> that.
> 
> Or do you mean I would then modify debian/config/defines (and not the one
> under the featureset-grsec folder) in src;linux-grsec?

You would modify debian/config/defines.

> > 4. There's no need to remove the templates for packages you don't
> > build.  However, if you leave them in place, you'll need to override
> > 

Bug#804350: ITP: vizzini -- Kernel driver for Exar XR21V1414 USB UART

[Ben Hutchings]

On Sat, 2015-11-07 at 19:52 +0200, Stefano Rivera wrote:
> Hi Ben (2015.11.07_19:33:52_+0200)
> > What's blocking this from going into mainline?
> 
> Apparently:
> 17:49 <@mithro> tumbleweed: but what happened is that the exar guys 
> effectively forked an in 
> tree kernel driver and made it work with their crappy device
> 17:50 <@mithro> tumbleweed: shenki then fixed it to work with modern kernels
> 17:51 <@mithro> tumbleweed: It needs to be rewritten as something that can be 
> merged into the 
> upstream driver.
> 17:51 <@mithro> (The CDC-ACM driver)
> 17:52 <@mithro> That is never going to happen as nobody has the time or will 
> power to do it
> 
> Less than ideal for the archive, but useful if you want to muck around with
> this hardware.

I compared this with the current cdc-acm driver, reverted what I
suspect are unnecessary changes, and ended up with this:
https://git.decadent.org.uk/gitweb/?p=exar-uart-driver.git

Perhaps you could check whether that works (with Linux 4.3)?

However, as this device doesn't really seem to follow the CDC-ACM class
at all, I suspect that the way to support it upstream is with a custom
USB serial driver.  I've attached a patch against Linux 4.3 which
implements that.  This involved a certain amount of guesswork as I have
no experience with serial drivers, but I think it's worth trying.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.From 18baceea7099045f111a79cb2f01b9e5c94c63aa Mon Sep 17 00:00:00 2001
From: Ben Hutchings <b...@decadent.org.uk>
Date: Tue, 10 Nov 2015 21:40:43 +
Subject: [PATCH] usb-serial: Add vizzini driver for Exar USB 2 serial adapters

Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
 drivers/usb/serial/Kconfig   |   9 ++
 drivers/usb/serial/Makefile  |   1 +
 drivers/usb/serial/vizzini.c | 356 +++
 3 files changed, 366 insertions(+)
 create mode 100644 drivers/usb/serial/vizzini.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..6911677 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -713,4 +713,13 @@ config USB_SERIAL_DEBUG
 	  To compile this driver as a module, choose M here: the
 	  module will be called usb-debug.
 
+config USB_SERIAL_VIZZINI
+	tristate "USB Exar XR21V141x 'Vizzini' Serial Driver"
+	help
+	  Say Y here if you want to use the Exar XR21V1410/1412/141
+	  USB 2 serial dapters.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called vizzini.
+
 endif # USB_SERIAL
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 349d9df..371efa3 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_USB_SERIAL_SYMBOL)			+= symbolserial.o
 obj-$(CONFIG_USB_SERIAL_WWAN)			+= usb_wwan.o
 obj-$(CONFIG_USB_SERIAL_TI)			+= ti_usb_3410_5052.o
 obj-$(CONFIG_USB_SERIAL_VISOR)			+= visor.o
+obj-$(CONFIG_USB_SERIAL_VIZZINI)		+= vizzini.o
 obj-$(CONFIG_USB_SERIAL_WISHBONE)		+= wishbone-serial.o
 obj-$(CONFIG_USB_SERIAL_WHITEHEAT)		+= whiteheat.o
 obj-$(CONFIG_USB_SERIAL_XIRCOM)			+= keyspan_pda.o
diff --git a/drivers/usb/serial/vizzini.c b/drivers/usb/serial/vizzini.c
new file mode 100644
index 000..b462cb6
--- /dev/null
+++ b/drivers/usb/serial/vizzini.c
@@ -0,0 +1,356 @@
+/*
+ * Based on vizzini driver:
+ *
+ * Copyright (c) 2013 Exar Corporation, Inc.
+ *
+ * Based on USB Serial "Simple" driver
+ *
+ * Copyright (C) 2001-2006,2008,2013 Greg Kroah-Hartman <g...@kroah.com>
+ * Copyright (C) 2005 Arthur Huillet (ahuil...@users.sf.net)
+ * Copyright (C) 2005 Thomas Hergenhahn <thomas.hergenh...@suse.de>
+ * Copyright (C) 2009 Outpost Embedded, LLC
+ * Copyright (C) 2010 Zilogic Systems <c...@zilogic.com>
+ * Copyright (C) 2013 Wei Shuai <cpuw...@gmail.com>
+ * Copyright (C) 2013 Linux Foundation
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License version
+ *	2 as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define XR_SET_REG			0
+
+#define URM_REG_BLOCK			4
+#define EPLOCALS_REG_BLOCK		0x66
+
+#define MEM_EP_LOCALS_SIZE_S		3
+#define MEM_EP_LOCALS_SIZE		(1 << MEM_EP_LOCALS_SIZE_S)
+
+#define EP_WIDE_MODE			0x03
+
+#define UART_GPIO_MODE			0x01a
+
+#define UART_GPIO_MODE_SEL_M		0x7
+#define UART_GPIO_MODE_SEL_S		0
+#define UART_GPIO_MODE_SEL		0x007
+
+#define UART_GPIO_MODE_SEL_GPIO		(0x0 << UART_GPIO_MODE_SEL_S)
+#define UART_GPIO_MODE_SEL_RTS_CTS	(0x1 << UART_GPIO_MODE_SEL_S)
+#define UART_GPIO_MODE_SEL_DTR_DSR	(0x2 << UART_GPIO_MODE_SEL_S)
+
+#define UART_ENABLE			0x003
+#define UART_ENABLE_TX_M		0x1
+#define UART_ENABLE_TX_S		0
+#defin

Bug#804258: ITP: igb -- dkms source for the igb network driver

[Ben Hutchings]

On Sat, 2015-11-07 at 09:52 +0100, Clement Hermann wrote:
> Le 07/11/2015 02:20, Ben Hutchings a écrit :
> > On Fri, 2015-11-06 at 18:35 +0100, Clément Hermann wrote:
> > > 
> > >  igb is the Linux device driver released for Intel 82575/6, 82580, I350, 
> > > and
> > >  I210/211-based network interfaces. 
> > >  .
> > >  This driver uses the same base as the igb module included in the Linux 
> > > kernel,
> > >  with added features such as advanced multiqueue control (RSS), interrupts
> > >  throttle management, Large Receive Offload (LRO) and Low Latency 
> > > Interrupts
> > >  (LLI).
> > >  .
> > >  Only use this driver if you need these specific features.
> > [...]
> > 
> > This description is inaccurate; two of the four features mentioned
> > actually are included in the in-tree driver.  And I don't think there'a
> > anything stopping Intel's maintainers from adding the remaining
> > features to the in-tree driver.
> > 
> > The justification for adding an alternate version of the driver seems
> > quite weak.
> > 
> You're right, this is poorly worded.
> 
> Most features are actually in mainline, you're right, but there is often
> no way to control them: only default values are usable.
> 
> For instance, RSS: in mainline, you don't have the option to choose
> (reduce) the number of queues in order avoid using both thread of a
> HT-enabled CPU core, or keeping some cpu free of network interrupts. You
> can free a CPU using affinity, but you'll end up with several queues on
> another. As stated in my description, this is not intended to replace
> the mainline kernel which should work fine for most uses.

You can use ethtool -X to do this.

[...]
> So here is an updated description:
> 
>  igb is the Linux device driver released for Intel 82575/6, 82580, I350, and
>  I210/211-based network interfaces. 
>  .
>  This driver uses the same code base as the igb module included in the Linux 
> kernel,
>  and allows control over advanced features via modules parameters :
>  - InterruptThrottleRate:Maximum interrupts per second, per vector

ethtool -C ?

>  - IntMode:Change Interrupt Mode
>  - Node:set the starting node to allocate memory on
>  - LLIPort:Low Latency Interrupt TCP Port
>  - LLIPush:Low Latency Interrupt on TCP Push flag
>  - LLISize:Low Latency Interrupt on Packet Size
>  - RSS:Number of Receive-Side Scaling Descriptor Queues
>  - VMDQ:Number of Virtual Machine Device Queues
>  - MDD:Malicious Driver Detection
>  - QueuePairs:Enable Tx/Rx queue pairs for interrupt handling
>  - EEE:Enable/disable on parts that support the feature

ethtool --set-eee

>  - DMAC:Disable or set latency for DMA Coalescing

I've told them this should be done through ethtool but they never sent
patches for this.

>  - LRO:Large Receive Offload

Usually oesn't offer much advantage over GRO, and it doesn't work with
 bridging.

Ben.

>  Only use this driver if you need fine control over these specific features, 
> otherwise, 
> 
>  you should stick to the driver included in mainline kernel.
> 
> Including the full list of parameter was actually my first move, but I 
> thought it would maybe be too long.
> Seeing your reaction, though, I understand it needs clarification.
> 
> Cheers,
> 
-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Ben Hutchings]

On Thu, 2015-11-05 at 22:08 +0100, Yves-Alexis Perez wrote:
> On sam., 2015-10-10 at 21:55 +0200, Yves-Alexis Perez wrote:
> > This is really a work in progress and this mail a request for comment.
> > Especially missing is:
> 
> So, did any of you have the chance to test it? I'm currently running the 4.2.5
> kernel with grsecurity-3.1-4.2.5-201511021814 (just uploaded to my repository
> and to git.d.o) and it works just fine.
> 
> I'm really interested by any feedback you would have on this.

I've given this a quick review and found a few issues:

1. linux-grsec-{source,support} are included in debian/control but not
built by debian/rules.real.  I think these should be built; the latter
will be needed to build metapackages as in linux-latest.

2. udebs are included in debian/control but not built, and they should
not be built.   You can fix this by deleting or commenting-out
debian/installer/{amd64,i386}/kernel-versions

3. The changes to gencontrol.py and rules.real to disable most arch:all
packages should depend on configuration, not the source package name.
They would then be acceptable for inclusion on the master branch.

4. There's no need to remove the templates for packages you don't
build.  However, if you leave them in place, you'll need to override
do_extra() in gencontrol.py to omit the extra packages dependent on the
configuration (as for (3)).

5. CONFIG_X86_X32 should be disabled, since you've disabled the patch
to make x32 support dependent on a kernel parameter.

6. In debian/patches/features/all/grsec/gen-patch you can use the
filterdiff -p1 to avoid assuming the path prefix will be 'b/'.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

Bug#804258: ITP: igb -- dkms source for the igb network driver

[Ben Hutchings]

On Sat, 2015-11-07 at 11:31 +0100, Clement Hermann wrote:
[...]
> Still, VMDQ and LLI are useful and not provided the mainline driver or
> with ethtool at all AFAICS.
> 
> How about listing in the description the features that cannot be changed
> by ethtool ?
[...]

That makes sense to me.

Still, I can't say I'm happy with 'enhanced' drivers in the archive for
hardware that we already support well with in-tree drivers.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

Bug#804350: ITP: vizzini -- Kernel driver for Exar XR21V1414 USB UART

[Ben Hutchings]

On Sat, 2015-11-07 at 17:05 +, Stefano Rivera wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stefano Rivera <stefa...@debian.org>
> 
> * Package name: vizzini
>   Version : 1.0.0
>   Upstream Author : Exar Corporation, Inc.
> * URL : https://github.com/mithro/exar-uart-driver
> * License : GPL-2+
>   Programming Lang: C
>   Description : Kernel driver for Exar XR21V1414 USB UART
> 
> The debconf-video team is using a board with this UART on it for HDMI
> capture.

What's blocking this from going into mainline?

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


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

Bug#804258: ITP: igb -- dkms source for the igb network driver

[Ben Hutchings]

On Fri, 2015-11-06 at 18:35 +0100, Clément Hermann wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Clément Hermann" <nod...@nodens.org>
> 
> * Package name: igb
>   Version : 5.3.3.2
>   Upstream Author : Intel Corporation
> * URL : http://sourceforge.net/projects/e1000/
> * License : GPL-2
>   Programming Lang: C
>   Description : dkms source for the igb network driver
> 
>  igb is the Linux device driver released for Intel 82575/6, 82580, I350, and
>  I210/211-based network interfaces. 
>  .
>  This driver uses the same base as the igb module included in the Linux 
> kernel,
>  with added features such as advanced multiqueue control (RSS), interrupts
>  throttle management, Large Receive Offload (LRO) and Low Latency Interrupts
>  (LLI).
>  .
>  Only use this driver if you need these specific features.
[...]

This description is inaccurate; two of the four features mentioned
actually are included in the in-tree driver.  And I don't think there'a
anything stopping Intel's maintainers from adding the remaining
features to the in-tree driver.

The justification for adding an alternate version of the driver seems
quite weak.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

Bug#798529: ITP: python-xkcd

[Ben Hutchings]

On Thu, 2015-09-10 at 10:05 +, Gianfranco Costamagna wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name : xkcd
> * Version : 2.3.1
> * Upstream Author : Ben Rosser
> * URL : https://pythonhosted.org/xkcd/
> * License : MIT
> Description : Python2 library for accessing xkcd.com.
> 
> This is a Python library for accessing and retrieving links to comics from the
> xkcd webcomic by Randall Munroe.

Why is this useful to do programmatically?

> It is NOT endorsed or made by him, it’s an entirely independent project.

[...]

Then, isn't its name a trademark infringement?

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg



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

Bug#798529: ITP: python-xkcd

[Ben Hutchings]

On Thu, 2015-09-10 at 13:32 +, Gianfranco Costamagna wrote:
> Hi Ben!
> 
> 
> > Why is this useful to do programmatically?
> 
> 
> having access to the website by code is useful to know when some new images 
> are available, moreover
> is nice to have for the "alt" stuff, not visible from Android (e.g.) and from 
> some older browsers.

Any feed reader can do that for you.

> the API has some *nice* additions, I thought it was worth a packaging
>
> > Then, isn't its name a trademark infringement?
> 
> 
> well, IANAL, but on the xkcd website there is no trademark mentioning, and 
> all the work is CC licensed.
> (not that we should care about the images, since they are not packaged in any 
> way)

You're confusing copyright with trademarks.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg



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

Bug#796920: Subject: ITP: ripper -- scrape licenses out of files

[Ben Hutchings]

On Wed, 2015-08-26 at 18:27 -0300, Fernando Ike wrote:
 On Wed, 2015-08-26 at 00:03 +0100, Ben Hutchings wrote:
  On Tue, 2015-08-25 at 17:00 -0300, Fernando Ike wrote:
   Package: wnpp
   Severity: wishlist
   X-Debbugs-CC: debian-de...@lists.debian.org
   Owner: Fernando Ike f...@midstorm.org
   
   * Package name: ripper
  
  It's a strange name for such a package.
   
   Yeah, I know. 
 
   If for considering pkg-go name package convention, which use as name
 package golang-github-odeke-em-ripper. Well, it has a problem with
 executable program that name. 
  
   Do you think is good keep ripper as executable binary or it's better
 change?

It seems to be quite a new project, so maybe upstream would be open to
choosing a more descriptive name.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.



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

Bug#796920: Subject: ITP: ripper -- scrape licenses out of files

[Ben Hutchings]

On Tue, 2015-08-25 at 17:00 -0300, Fernando Ike wrote:
 Package: wnpp
 Severity: wishlist
 X-Debbugs-CC: debian-de...@lists.debian.org
 Owner: Fernando Ike f...@midstorm.org
 
 * Package name: ripper

It's a strange name for such a package.

   Version : 0.0~git20150415.0.bd1a682-1
   Upstream Author : Emmanuel Odeke emm.od...@gmail.com
 * URL : https://github.com/odeke-em/ripper
 * License : Apache-2.0
   Programming Lang: Go
   Description : scrape licenses out of files
  Ripper inspect source files and show the license if it found. It
  support directories, files or URI repositories as argument.
  .
  This package provides command-line to use alone or embbed in others
  programs.

What does it offer over licensecheck (in devscripts)?

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.



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

Bug#792760: RFP: icedove-thunderlink -- Link to email by Message-ID

[Ben Hutchings]

On Sat, 2015-07-18 at 03:12 -0500, Nathaniel Beaver wrote:
 Package: wnpp
 Severity: wishlist
 X-Debbugs-CC: debian-de...@lists.debian.org
 
 --- Please fill out the fields below. ---
 
 Package name: icedove-thunderlink
  Version: 1.2.1
 Upstream Author: Christoph Zwirello n...@example.com
  URL: https://github.com/poohsen/thunderlink
  License: Mozilla Public License, version 2.0
  Description: Link to email by Message-ID
 
 This needs a Debian package because it requires registration of a new 
 mimetype for the URI scheme, which is a bit of a hassle to do by hand. 
 Here's an example of an actual Thunderlink:
 
 thunderlink://messageid=handler.719011.d719011.143167491026690.ackd...@bugs.debian.org
[...]

There is a standard mid: scheme https://tools.ietf.org/html/rfc2392;
why not support that?

Ben.


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