Bug#861639: ITP: node-elliptic -- fast elliptic curve cryptography in pure javascript

[Christian Seiler]

On 05/02/2017 10:13 PM, Bastien ROUCARIES wrote:
> On Tue, May 2, 2017 at 8:44 PM, Chris Lamb <la...@debian.org> wrote:
>> Christian Seiler wrote:
>>
>>> As with the other pure JS crypto package ITP here recently [1]: has
>>> this library been designed with timing attacks in mind?
>>
>> JFTR I filed #860939 to track (and prevent a testing migration of) the
>> parallel issue in node-diffie-hellman.
> 
> I will prefer this king of aproach let package the stuff and do not
> try to diverge from upstream.
> 
> Fill RC bug and try to solve this before next debian version

Sure. When I voiced my concerns I wasn't trying to hinder anyone's
progress, I just wanted to make sure that people are aware of
these concerns. If my responses to the ITPs came across differently,
I apologize.

Regards,
Christian

Bug#861639: ITP: node-elliptic -- fast elliptic curve cryptography in pure javascript

[Christian Seiler]

Hi there,

On 05/02/2017 07:49 AM, Pirate Praveen wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pirate Praveen 
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-elliptic
>   Version : 6.4.0
>   Upstream Author : Fedor Indutny 
> * URL : https://github.com/indutny/elliptic
> * License : Expat
>   Programming Lang: JavaScript
>   Description : faster elliptic curve cryptography in pure javascript
> 
>  Fast elliptic-curve cryptography in a plain javascript implementation.
>  Incentive for Elliptic: ECC (another library with comparable features) is
>  much slower than regular RSA cryptography, the JS implementations are even
>  more slower.

As with the other pure JS crypto package ITP here recently [1]: has
this library been designed with timing attacks in mind? In contrast
to the first example, where upstream says that it's so slow that
nobody is probably going to use it in real life anyway [2], this
library claims to be quite fast - in which case the chance of the
library being used in actual real-life applications is higher. And
it uses the same bignum library that the other package is also
using, which doesn't appear to have been designed with timing
considerations in mind. (Which is fine for a bignum library not
intended for crypto purposes.)

As with the previous package, the README of the project and the
other documentation does not discuss timing attacks at all, which
doesn't give me confidence that the author of the library has
thought about these issues.

A couple of pointers:

 - For curves that are not Edwards curves there is a very trivial
   timing attack, which is really hard to mitigate, where it is
   trivially possible to extract the private key through a side
   channel near-instantaneously.

   The library supports all sorts of types of curves, and while I
   haven't tested it, I'd be extremely surprised if it wasn't
   susceptible to this type of attack for non-Edwards curves.

 - For curves that are Edwards curves, the trivial timing attacks
   described above are mitigated. However, I don't have any
   confidence (especially since this is pure Javascript, where
   I imagine mitigating this to be extremely difficult) that the
   code doesn't contain any other side channels. Again, I didn't
   test that, but there is no documentation even mentioning side
   channels, and no comment in the code either. (If you grep
   through e.g. OpenSSL's source code, you'll see lots of
   comments discussing side channels and timing attacks. And even
   OpenSSL has advisories on side channel attacks every now and
   then, because someone comes up with something very clever that
   they didn't think of. [3])

I understand you're probably packaging this because it's a
dependency of something else, but I'm seriously concerned about
any package that uses this library for real-world applications
other than generating key pairs.

Regards,
Christian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860771#10
[2] 
https://github.com/crypto-browserify/diffie-hellman/issues/22#issuecomment-296645560
[3] Look at CVE-2013-4576 to see how creative these side channel
attacks can become.

Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman

[Christian Seiler]

On 04/20/2017 11:09 AM, Bastien ROUCARIES wrote:
> I have planned to add a big fat warning about safety of
> browserify-crypto. I am myself unease to use it but it is needed for
> browserify.
> 
> Do you prefer a README.debian per pure js crypto package ?

Maybe also add something along the lines of

| For security considerations of this package please consult
| README.Debian.

to the package's extended description? (Or is that against
policy?)

> I plan to patch browserify and add a flag in order to use the crypto API.

Isn't browserify a JS minifier? Why would that need DH key
exchange anyway? I'm a bit confused here...

Regards,
Christian

Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman

[Christian Seiler]

On 04/19/2017 11:36 PM, Bastien ROUCARIES wrote:
> Package: wnpp
> Severity: wishlist
> Owner: ro...@debian.org
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-diffie-hellman
>   Version : 5.0.2
>   Upstream Author : Calvin Metcalf
> * URL : https://github.com/crypto-browserify/diffie-hellman
> * License : Expat
>   Programming Lang: JavaScript
>   Description : pure js diffie-hellman key exchange
> 
>  Diffie–Hellman key exchange (D–H)  is a specific method of securely
>  exchanging cryptographic keys over a public channel. The
> Diffie–Hellman key exchange method allows two parties that have no
> prior knowledge of each other to jointly establish a shared secret key
> over an insecure channel. This key can then be used to encrypt
> subsequent communications using a symmetric key cipher.
>  .
>  Node.js is an event-based server-side JavaScript engine.

Is this timing safe? From the github page it uses a pure-JS
BigNum implementation (bn.js) for the complicated stuff, but
the README of that code doesn't mention timing at all. And
from perusing the source code of bn.js, it doesn't appear to
be the case that their implementation of exponentiation in
a prime field is geared towards constant-time execution (when
the sizes are the same).

If you look at e.g. OpenSSL's source code (bn_exp.c), there's
a specific function (bn_mod_exp_mont_consttime) in there that
takes great care of making sure that the operation runs in
constant time - down to how the memory layout is organized. I
wouldn't know how you'd even do that in an interpreted
language such as JavaScript, but even if that's possible, I'd
suspect that a lot of brain power would need to go into
designing that [1], while bn.js's implementation of the
Red.pow function seems rather straight-forward. (Which is
fine, bn.js appears to have the goal to be a generic bignum
library, and not targeted at crypto.)

What I'm saying is: while not having tested that, I believe
that this implementation of DH is going to be susceptible to
timing attacks. (And if it isn't, the author should really
provide some rationale why not, with some test results. The
README is rather sparse, though.) Which would be fine if you
just wanted to use this library to generate the DH prime
itself (that is not timing critical), or just use it in an
academic context (to let people play around with DH), but
I'd not want to use this for real-world applications of the
actual key exchange protocol.

Regards,
Christian

[1] Especially if this is to be run in browsers, with
different JITs etc. Designing algorithms in pure JS
for these environments that are timing-safe looks rather
daunting to me.

Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.

[Christian Seiler]

Hi again,

On 03/20/2017 07:43 AM, Christian Seiler wrote:
> And while that shouldn't be part of the package description later on,
> a short comment in the ITP why a fork was required would also be nice.
> Did the original project just not want to merge this? What's the use
> case for these changes that can't be supported by the original?

I've done some digging in the mailing list for the original upstream
project and found this thread:

https://lists.zx2c4.com/pipermail/password-store/2017-February/thread.html#2728

Specifically take a look at this message from the author of the original
tool:
https://lists.zx2c4.com/pipermail/password-store/2017-February/002799.html

The fork appears to have happened after that, but wasn't mentioned at
all on the upstream mailing list.

I haven't looked at the changes specifically, so I can't comment on the
issue of code quality at all, but that a relatively new user [1] forks
the entire project immediately after being shot down a bit for a patch
series (where the response was maybe a bit harsh, but not entirely
negative) doesn't instill me with a lot of confidence in the fork,
especially since the author of the fork hasn't mentioned any specific
use case why the changed functionality is needed at all, as far as I
can tell. (And making --help show extensions was something that devs of
the original project were interested in including regardless.)

Just my 2¢.

Regards,
Christian

[1] https://lists.zx2c4.com/pipermail/password-store/2017-January/002664.html

Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.

[Christian Seiler]

On 03/20/2017 06:18 AM, Adrian Alves wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Adrian Alves 
> 
> * Package name: passh
>   Version : 1.7.1
>   Upstream Author : Ivan Ariel Barrera Oro 
> * URL : https://github.com/HacKanCuBa/passh
> * License : GPL-3
>   Programming Lang: bash
>   Description : passh: a pass fork - stores, retrieves, generates, and 
> synchronizes passwords securely.
> 
> Pass is a simple password store. This fork changes a few
> things while trying to maintain most of it intact,
> specially the core idea. I will keep pulling pass commits,
> and also pushing my modifications to them.

It would be great if you could go into a bit more detail why this
fork is needed? "changes a few things" is _very_ unspecific.

I've had a look at the upstream website, and found this:
https://github.com/HacKanCuBa/passh#user-content-changes-from-pass-master
So apparently the only real difference (apart from branding) is
extension handling. This should definitely go in the package
description to allow people to decide which one they'd want to
install.

And while that shouldn't be part of the package description later on,
a short comment in the ITP why a fork was required would also be nice.
Did the original project just not want to merge this? What's the use
case for these changes that can't be supported by the original?

Also, a minor note, unrelated to Debian packaging: the fork claims in
https://github.com/HacKanCuBa/passh#license 
that the original is GPL-2 and that the fork is GPL-3+. If that were
actually true, the fork would be a license violation. Luckily for the
fork from reading the COPYING file of the original, that is is actually
licensed under GPL-2+ (not just GPL-2), so forking as GPL-3+ is fine.
(That said, while I generally like the GPL-3, forking a GPL-2+ project
under GPL-3+ does not allow the original project to easily merge back
changes made in the fork, they'd first have to get explicit
permission.)

Regards,
Christian

Bug#852451: ITP: rname -- invoke a program under a different name

[Christian Seiler]

On 01/24/2017 04:19 PM, Peter Pentchev wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Peter Pentchev 
> 
> * Package name: rname
>   Version : 1.0.2
>   Upstream Author : Peter Pentchev 
> * URL : https://devel.ringlet.net/sysutils/rname/
> * License : BSD-2-clause
>   Programming Lang: C
>   Description : invoke a program under a different name
> 
> The rname utility invokes a specified program, passing a different name
> instead of the name of the program executable.  This could be useful in
> a number of cases, both during software development, testing, and in
> production use.  There are many programs that do different things based
> on what name they have been invoked under; the rname utility avoids
> the need to e.g. create ephemeral symlinks to run these programs in
> some conditions when they have not been completely installed.
> 
> I originally wrote this tool in 2000 and I'm resurrecting it now for
> the purpose of writing unit and integration tests for just such
> a multifaceted program.

This is definitely useful (I've needed this myself at multiple times),
but wouldn't it be better if this were part of coreutils or util-linux
or something similar?

Because say if I wanted to use that functionality in a package of mine
(for unit tests or similar), I'd probably not want to depend on a tiny
package just for this, especially since there are ways of doing the
very same thing with packages that are installed on most systems:

/bin/bash -c "exec -a $argv0 $progname $args"
perl -e 'exec {shift} @ARGV' $progname $argv0 $args
python3 -c 'import os, sys; os.execvp(sys.argv[1], sys.argv[2:])' \
$progname $argv0 $args

(The shell needs to be bash, mksh, zsh or similar to work; dash and
others don't support -a for exec.)

I would prefer a standalone program for this of course, but the pain
of the other solutions is not large enough for me that the trade-off
in depending on something non-standard makes sense to me.

Of course that's just my personal assessment, YMMV, and I'm not
opposed to you packaging this (what you provide is definitely useful),
but maybe this email gives you some food for thought about how to
best provide this functionality.

Regards,
Christian

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Christian Seiler]

On 01/05/2017 01:18 PM, Martin Bagge / brother wrote:
> On 2017-01-05 13:04, Christian Seiler wrote:
>> The official package description appears to be:
> 
>> "Is retry allowed for Error?"
> 
>> And while that is still a bit vague, it does at least give an 
>> indication what the module does, while I have no idea what "my
>> prime module" is supposed to mean?
> 
>> I would urge you to use upstream's description when packaging this
>> module.
> 
> Well. They did.
> 
> https://github.com/floatdrop/is-retry-allowed/blob/8ca0d01b/package.json
> #L4
> reads
> 
> "description": "My prime module",

Yikes. My apologies, then at least now I get where that comes
from.

Still, the description on the github link appears to be the
one that's preferable to "my prime module". So thanks for
intending to fix this.

Regards,
Christian

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Christian Seiler]

Hi there,

Let me nitpick a bit: ;-)

On 01/05/2017 12:52 PM, saurabhagra...@disroot.org wrote:
> * URL : https://github.com/floatdrop/is-retry-allowed#readme
>   Description : My prime module

The official package description appears to be:

"Is retry allowed for Error?"

And while that is still a bit vague, it does at least give an
indication what the module does, while I have no idea what
"my prime module" is supposed to mean?

I would urge you to use upstream's description when packaging
this module.

Regards,
Christian

Bug#847749: ITP: node-user-home -- Get the path to the user home directory

[Christian Seiler]

On 12/11/2016 07:57 PM, Sruthi Chandran wrote:
> On 12/12/2016 12:20 AM, Sruthi Chandran wrote:
>> On 12/11/2016 11:30 PM, Christian Seiler wrote:
>>>> I've attached an updated use-os-homedir.patch that does this (including
>>>> the removal of the require.resolve() line above),
>> Thanks a lot!!! That fixed it.
> It was fixed in local build, but fails in sbuild. Can you check?

I see you enabled the tests during build; the problem here is that
the tests write to the home directory, which is not allowed during
package build (see a recent thread on debian-devel about that),
and sbuild enforces that by setting the home directory of the
sbuild user to something like /non-existent.

You can manually set the HOME environment variable during testing
to override that with a temporarily created directory.

I've attached a git patch against your current packaging (you can
use git am to apply it) that does just this. I've tried building
it in sbuild -d unstable and it works - and the tests pass.

Hope that helps.

Regards,
Christian
From 20e34e4f7ab4ed42574460ce771dc6d76d8395b2 Mon Sep 17 00:00:00 2001
From: Christian Seiler <christ...@iwakd.de>
Date: Sun, 11 Dec 2016 20:01:59 +0100
Subject: [PATCH] debian/rules: use fake HOME for tests

Use a fake home directory for tests to ensure that no data in the real
home directory is replaced during package build.
---
 debian/rules | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/rules b/debian/rules
index eaa101b..d6b3496 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,6 @@
 #override_dh_auto_build:
 
 override_dh_auto_test:
-	mocha -R spec test.js
-
-
+	mkdir -p test-home
+	HOME=$(shell pwd)/test-home mocha -R spec test.js
+	rm -rf $(shell pwd)/test-home
-- 
2.10.2

Bug#847749: ITP: node-user-home -- Get the path to the user home directory

[Christian Seiler]

On 12/11/2016 06:52 PM, Christian Seiler wrote:
> I've attached an updated use-os-homedir.patch that does this (including
> the removal of the require.resolve() line above),

And I just noticed that I forgot a semicolon after a line (not
critical, because javascript doesn't require it, but stylistically
it's not nice) and had some trailing whitespace. I've updated the
patch and attached it.

Regards,
Christian
use os.homedir instead of user-home

--- a/index.js
+++ b/index.js
@@ -26,7 +26,7 @@ function fail (err) {
 }
 
 function openConfig (cb) {
-  var userHome = require('user-home');
+  var userHome = os.homedir();
   if (!userHome) {
 return tryOpenConfig(path.join(os.tmpdir(), configfile), cb);
   }
--- a/test.js
+++ b/test.js
@@ -7,6 +7,8 @@ const expect = require('chai').expect;
 
 const env = process.env;
 
+const old_os_homedir = os.homedir;
+
 function eraseHome() {
   delete env.HOME;
   delete env.USERPROFILE;
@@ -16,6 +18,8 @@ function eraseHome() {
   delete env.USER;
   delete env.LNAME;
   delete env.USERNAME;
+
+  os.homedir = function() { return null; };
 }
 
 function setTemp(dir) {
@@ -24,7 +28,7 @@ function setTemp(dir) {
 
 function cleanup () {
   var v8flags = require('./');
-  var userHome = require('user-home');
+  var userHome = os.homedir();
   if (userHome === null) userHome = __dirname;
 
   var files = [
@@ -37,7 +41,7 @@ function cleanup () {
 } catch (e) {}
   });
 
-  delete require.cache[require.resolve('user-home')];
+  os.homedir = old_os_homedir;
   delete process.versions.electron;
 }
 
@@ -47,7 +51,7 @@ describe('v8flags', function () {
 
   it('should cache and call back with the v8 flags for the running process', function (done) {
 var v8flags = require('./');
-var configfile = path.resolve(require('user-home'), v8flags.configfile);
+var configfile = path.resolve(os.homedir(), v8flags.configfile);
 v8flags(function (err, flags) {
   expect(flags).to.be.a('array');
   expect(fs.existsSync(configfile)).to.be.true;
@@ -62,7 +66,7 @@ describe('v8flags', function () {
 
   it('should not append the file when multiple calls happen concurrently and the config file does not yet exist', function (done) {
 var v8flags = require('./');
-var configfile = path.resolve(require('user-home'), v8flags.configfile);
+var configfile = path.resolve(os.homedir(), v8flags.configfile);
 async.parallel([v8flags, v8flags, v8flags], function (err, result) {
   v8flags(function (err2, res) {
 done();

Bug#847749: ITP: node-user-home -- Get the path to the user home directory

[Christian Seiler]

On 12/11/2016 06:29 PM, Sruthi Chandran wrote:
> On 12/11/2016 06:18 PM, Guus Sliepen wrote:
>> Isn't s/user-home/os-homedir/ not enough? In any case, maybe you should
>> try to get upstream to switch to os-homedir instead.
> os-homedir is not packaged, we have been patching that with os.homedir.
> In this case, the patching is partially working, 4 tests are passing and
> 2 are failing.
> 
> I have pushed v8flags to alioth [1]. Please have a look. Test is "mocha
> -R spec test.js".

Side-note 1: there appears to be a dependency problem here when running
tests: for mocha to work (at least in this case), you also need the
package chai to be installed (otherwise it will fail with an error).
I think this is because test.js requires chai, but I'm not sure.
(I suspect the dependencies of mocha and node-v8flags themselves are
OK because it's not required for the package directly. OTOH you could
add the test suite to the package's autopkgtests and then add chai and
mocha to the Depends there.)

Problem 1:

 - cleanup hook is missing some patching out:

   delete require.cache[require.resolve('user-home')];

   If that line is not removed, then the cleanup hook will fail with
   require.resolve('user-home'), because that module is not installed.

Problem 2:

 - after patching that out I get the following test results:

  v8flags
✓ should cache and call back with the v8 flags for the running process 
✓ should not append the file when multiple calls happen concurrently and 
the config file does not yet exist 
1) should fall back to writing to a temp dir if user home can't be found
✓ should fall back to writing to a temp dir if user home is unwriteable 
2) should return flags even if an error is thrown
✓ should back with an empty array if the runtime is electron 

The following errors occur:

  1) v8flags should fall back to writing to a temp dir if user home can't be 
found:
 Uncaught AssertionError: expected false to be true
  at 
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/test.js:77:46
  at 
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:108:14
  at 
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:36:12
  at 
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:47:7
  at nextTickCallbackWith0Args (node.js:420:9)
  at process._tickCallback (node.js:349:13)

  2) v8flags should return flags even if an error is thrown:
 Uncaught AssertionError: expected null not to be null
  at 
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/test.js:98:28
  at 
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:108:14
  at 
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:36:12
  at 
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:47:7
  at nextTickCallbackWith0Args (node.js:420:9)
  at process._tickCallback (node.js:349:13)

In test.js there is a routine eraseHome() which unsets a lot of environment
variables. This is to trick the user-home module (which we rejected from
Debian, if you remember) to think it can't fetch the user's home directory,
and therefore trigger the fallback.

This is problematic because os.homedir() falls back to reading /etc/passwd
(as it should, that's a feature, not a bug), so it won't fail. That means
that the fallback to a temporary directory won't happen. This means that
in the first case the fallback won't be triggered, and the expectation of
the test is wrong.

The second failure is related: since it tries to trigger the "home dir
doesn't exist" error to see if the module will succeed anyway without
throwing an exception, it does expect the error in the callback passed
to the module to be non-null - since it expects an error to have occurred.
However, in this case there was no error.

This is not a failure in the module itself, this is only a problem with
the test suite.

There's an easy fix though: monkey-patch os.homedir to a function that
just returns null in eraseHome(), and restore it in cleanup().

I've attached an updated use-os-homedir.patch that does this (including
the removal of the require.resolve() line above), and the test suite
now passes for all 6 tests:

  v8flags
✓ should cache and call back with the v8 flags for the running process 
✓ should not append the file when multiple calls happen concurrently and 
the config file does not yet exist 
✓ should fall back to writing to a temp dir if user home can't be found 
✓ should fall back to writing to a temp dir if user home is unwriteable 
✓ should return flags even if an error is thrown 
✓ should back with an empty array if the runtime is electron 

  6 passing (61ms)

Hope that helps.

Regards,
Christian
use os.homedir instead of user-home

--- a/index.js
+++ b/index.js
@@ -26,7 +26,7 @@ function fail 

Bug#847066: ITP: node-stream-shift -- Returns the next buffer/object in a stream's readable queue

[Christian Seiler]

Control: merge 847066 847053

On 12/05/2016 02:03 PM, Pirate Praveen wrote:
> On 2016, ഡിസംബർ 5 5:50:41 PM IST, Christian Seiler <christ...@iwakd.de> wrote:
>> This appears to be a duplicate of https://bugs.debian.org/847053
> 
> I tried resending from a different address as I did not receive a
> response after a long time (usually its just 2 minutes).

Sometimes it can take longer for the BTS to reply, up to two hours
(but very rarely so) was my experience.

Anyway, I've merged the bug reports.

Regards,
Christian

Bug#847066: ITP: node-stream-shift -- Returns the next buffer/object in a stream's readable queue

[Christian Seiler]

On 12/05/2016 11:08 AM, Pirate Praveen wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pirate Praveen 
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-stream-shift
>   Version : 1.0.0
>   Upstream Author : Mathias Buus (@mafintosh)
> * URL : https://github.com/mafintosh/stream-shift
> * License : Expat
>   Programming Lang: JavaScript
>   Description : Returns the next buffer/object in a stream's
> readable queue

This appears to be a duplicate of https://bugs.debian.org/847053

Regards,
Christian

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

[Christian Seiler]

On 11/30/2016 10:32 PM, Karsten Merker wrote:
> On Thu, Dec 01, 2016 at 12:56:14AM +0530, Ritesh Raj Sarraf wrote:
>> On Wed, 2016-11-30 at 20:05 +0100, Karsten Merker wrote:
>>> 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.
>> The binary packages are:
>>
>> rrs@learner:~/rrs-home/Community/Packaging/bcc (master)$ grep Package: 
>> debian/control 
>> Package: libbcc
>> Package: libbcc-dev
>> Package: python-bcc
>> Package: bcc-tools
>> Package: bcc-lua
>> 2016-12-01 / 00:52:49 ♒♒♒  ☺  
>>
>> Does it make sense ?
>>
>> If you have suggestions, please mention them, because it'll be
>> easier to make the name changes now.
> 
> many thanks for the explanation, so from a technical point of
> view there is no package naming conflict, although it is somewhat
> counter-intuitive to end up with a source-package "bcc" and a
> binary-package "bcc" where the latter isn't built from the former
> but instead contains a completely different application.

Maybe the new source package could be named bpf-bcc? That way there
would be no confusion with respect to bin:bcc vs. src:bcc, and the
source package name is still quite short, yet descriptive. Just a
suggestion.

Regards,
Christian

Bug#846237: ITP: ondir -- Automate tasks specific to certain directories in the shell

[Christian Seiler]

On 11/29/2016 06:01 PM, Christian Seiler wrote:
> On 11/29/2016 05:25 PM, Guus Sliepen wrote:
>> On Tue, Nov 29, 2016 at 03:41:29PM +0100, Christian Seiler wrote:
>>
>>> * Package name: ondir
>>>   Version : 0.2.3+git [*]
>>>   Upstream Author : Alec Thomas
>>> * URL : http://swapoff.org/ondir.html
>>> * License : GPL-2
>>>   Programming Lang: C
>>>   Description : Automate tasks specific to certain directories in the 
>>> shell
>>
>> Which shells are supported by ondir?
> 
> Out of the box: bash, zsh, tcsh and fish.

Well, that turned out to not be true. bash, zsh and fish work
as I said, but tcsh doesn't. (I found that while testing the
package, I'm not a user of tcsh.) An earlier version used to
support tcsh, but the software was rewritten in C at some point
and tcsh support doesn't work anymore, even if the docs still
claims it does. Just mentioning this here in case someone finds
this thread later on.

Regards,
Christian

Bug#846237: ITP: ondir -- Automate tasks specific to certain directories in the shell

[Christian Seiler]

On 11/29/2016 05:25 PM, Guus Sliepen wrote:
> On Tue, Nov 29, 2016 at 03:41:29PM +0100, Christian Seiler wrote:
> 
>> * Package name: ondir
>>   Version : 0.2.3+git [*]
>>   Upstream Author : Alec Thomas
>> * URL : http://swapoff.org/ondir.html
>> * License : GPL-2
>>   Programming Lang: C
>>   Description : Automate tasks specific to certain directories in the 
>> shell
> 
> Which shells are supported by ondir?

Out of the box: bash, zsh, tcsh and fish.

The only thing to consider is that the commands in  ~/.ondirrc
have to be in the language of your shell, so if you switch
your shell, you'll also have to update that file, unless you
are doing the most trivial of things.

Regards,
Christian

Bug#846237: ITP: ondir -- Automate tasks specific to certain directories in the shell

[Christian Seiler]

On 11/29/2016 04:23 PM, Julian Taylor wrote:
> On 11/29/2016 03:41 PM, Christian Seiler wrote:
>> (Forwarding because I forgot to Cc debian-devel@.)
>>
>> ondir is a small program to automate tasks specific to certain
>> directories. It works by executing scripts in directories when
>> you enter and leave them. It may be used to set environment
>> variables or change the umask depending on the current working
>> directory.
> 
> Seems very similar to the direnv package 

Oh, I didn't know that one, thanks for pointing me to it.

> except that direnv does not have an unload hook by design (e.g.
> what is done when the terminal is closed? I guess its up to the
> users script to handle that?)

The leave function is not executed with ondir when the shell
exits while in a given directory - only when cd'ing out. In
that sense I don't see any differences between direnv and
ondir.

> Are there any other notable differences?

direnv requires you to modify the directories themselves, ondir
has it's configuration in the home directory. That means that for
publicly shared directories ondir allows different configurations
per-user, while that is not easily possible with direnv.

Also, ondir can match arbitrary directories by pattern, the
README.md on github  an example configuration for the use with
virtual python environments:

enter ~/Projects/([^/]+)
  if [ -r .venv ]; then
. ./.venv/bin/activate
  fi

leave ~/Projects/([^/]+)
  deactivate > /dev/null 2>&1

With direnv you'd need .envrc files in each of those directories.

ondir always includes the configuration for any parent directories,
while with you can decide that for yourself with direnv (according
to the documentation anyway).

direnv has a standard library for modifying environment variables
(such as PATH) already available, while you'd have to do that
yourself with ondir.

direnv appears to be quite verbose (without an apparent way to
turn it off), while ondir isn't, but you can be verbose yourself
there if you so wish.

They both support the same shells (bash, zsh, tcsh and fish).

As for further differences: I plan on enabling ondir by default
in the Debian package, but only if either a system wide or user
specific configuration exists (so users that don't care about
ondir won't see any change, but it works out of the box once the
user creates the configuration file for it); this is not possible
for direnv, as you can only know if that is used by the user if
they cd into a directory with a .envrc file.

> From the descriptions it seems that direnv might be the better choice
> is what you need is only environment setup and teardown and not
> execution of arbitrary commands, possibly that should be noted in the
> description so the user can decide.

I will add a reference to direnv to the description so users are
able to make up their mind as to what solution is the better one
for them. (There are both advantages and disadvantages to either
approach.)

Thanks again for pointing the alternative out.

Regards,
Christian

Bug#846237: ITP: ondir -- Automate tasks specific to certain directories in the shell

[Christian Seiler]

Package: wnpp
Owner: Christian Seiler <christ...@iwakd.de>
Severity: wishlist

* Package name: ondir
  Version : 0.2.3+git [*]
  Upstream Author : Alec Thomas
* URL : http://swapoff.org/ondir.html
* License : GPL-2
  Programming Lang: C
  Description : Automate tasks specific to certain directories in the shell

ondir is a small program to automate tasks specific to certain
directories. It works by executing scripts in directories when
you enter and leave them. It may be used to set environment
variables or change the umask depending on the current working
directory.

[*] There is a newer release on github as compared to the
website; see https://github.com/alecthomas/ondir
I also intend to include patches upstream has merged
since 0.2.3.

I plan to maintain this package on collab-maint.

Bug#805268: Adoption of syslinux

[Christian Seiler]

Hi,

On 11/11/2016 02:48 PM, Iain R. Learmonth wrote:
> I notice you're planning to adopt syslinux. We were planning to adopt this
> package under the Debian Live/Debian CD teams as we use this for the
> official CD image builds.

Oh, I didn't know you were also planning to adopt it - the package
had been orphaned for quite a while now, and I just assumed there
were no other takers.

I'd be very happy to co-maintain the package though - I just didn't
mention that in the ITA mail because I thought that if someone else
was interested in the package, they'd have already adopted it by
that time.

> This is not a trivial package to maintain

Yes, I'm aware of that. :)

> and updates really *need* to be
> coordinated with the CD team, especially when coming up to release time.

Yes - the reason I became interested in maintaining the package
is because of previous changes leading to previous use cases not
working anymore. And I do think the package is in need of some
love.

> I notice also that you're currently a DM, and I'll be happy to sponsor
> uploads of this package and also perform testing of the Debian Live
> toolchain with those updates before the new package is introduced into the
> archives.

Great, thanks.

My plans for the package were to update to a newer upstream
version (there's a -pre1 from the beginning of this year of
6.04 IIRC, but I wanted to go through upstream git to see if
a git snapshot might not be better suited), and improve the
packaging were needed. (Though the last QA upload already did
quite a bit there.) I then wanted to ask for sponsorship for
an upload to experimental first and let it stew there for a
while before going on to sid.

I hope you agree with that basic plan. And as I said above:
if you're interested in co-maintaining the package, it
welcome that as well.

Regards,
Christian

Bug#805268: Bug #805268: ITA: syslinux -- collection of bootloaders (DOS FAT and NTFS bootloader)

[Christian Seiler]

X-Debbugs-Cc: debian-de...@lists.debian.org
Control: owner -1 !
Control: retitle -1 ITA: syslinux -- collection of bootloaders (DOS FAT and 
NTFS bootloader)

On Mon, 16 Nov 2015 08:29:30 + Mattia Rizzolo  wrote:
> Some information about this package:
> 
> Homepage: http://www.syslinux.org/
> Package: syslinux
> Architecture: amd64 i386 x32
> Description: collection of bootloaders (DOS FAT and NTFS bootloader)
>  syslinux is a suite of bootloaders, currently supporting DOS FAT and NTFS
>  filesystems (SYSLINUX), Linux ext2/ext3/ext4, btrfs, and xfs filesystems
>  (EXTLINUX), PXE network boots (PXELINUX), or ISO 9660 CD-ROMs (ISOLINUX).
>  .
>  This package contains the bootloader for DOS FAT and NTFS filesystems
>  (SYSLINUX).

I intend to adopt this package in the near future.

Regards,
Christian

Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis

[Christian Seiler]

On 08/03/2016 09:00 PM, Andreas Tille wrote:
>  2b) Do the conversion of the format in postinst at the expense
>  of users time which is acceptable since the package usually
>  unpacks on high performance machines and not so many
>  installations which means bandwidth and disk space on Debian
>  mirrors should be saved here instead of users machine
> 
>  Source tarball 256MB + binary package ~250MB (estimated)

Personally, I think that'd probably be the best solution, at least
as long as there are not too many updates to the package. I'm
thinking that if the data changes once or twice a year, that'd be
OK. If it's twice a week, then I think the only realistic solution
would be 3b).

There are some large data packages in sid already though, even
reaching the sizes you describe, but if you can avoid this,
especially for low-popcon packages, I think having the user's
computer do a little more work in postinst is a reasonable trade-
off here.

For reference, the top 5 sorted by deb size:

Package   deb Size (GiB)  Installed Size (GiB)
-
flightgear-data-base  1.06257 1.50826
freefoam-dev-doc  0.84636 1.49562
redeclipse-data   0.72715 0.832576
0ad-data  0.5403661.4238
libpcl1.7-dbg 0.5306590.578442

Top 5 sorted by installed size:

Packagedeb Size (GiB) Installed Size (GiB)
--
linux-image-4.6.0-1-rt-amd64-dbg   0.409186   3.09527
linux-image-4.6.0-1-amd64-dbg  0.410594   3.09287
linux-image-4.5.0-2-amd64-dbg  0.393085   2.87757
flightgear-data-base   1.062571.50826
freefoam-dev-doc   0.846361.49562

Shell snipped I used to get this data:
awk '/^Package:/ { pkg = $2; }
 /^Installed-Size:/ { is = $2; }
 /^Size:/ { print pkg, $2, is }' \
 < /var/lib/apt/lists/*_debian_dists_sid_main_binary-amd64_Packages \
  | sort -k3 -n \
  | awk '{ print $1, $2 / 1024.0 / 1024.0 / 1024.0, $3 / 1024.0 / 1024.0 }' \
  | tail -n 5 \
  | tac

Using a similar snippet, I could determine that there are 34
packages with deb size larger than 200 MiB in the archive at
the moment; 51 larger than 150 MiB and 88 larger than 100 MiB.
(This does not include -dbgsym packages in the debug section.)

>  (possibly be upstream can be convinced
>  to provide a *.bz2 tarball for maximum compression).

Please don't use bz2 anymore. It's really slow and doesn't do any
better than e.g. xz. (There's a reason why Debian migrated away
from it.) If you convince upstream to provide a better tarball,
please suggest a better algorithm. (The compression level with xz
does play a role when it comes to speed, but there you can choose
a reasonable trade-off. The memory requirements of xz should be
irrelevant here, because I can't see the software you're
describing being used on an extermely low-memory system.)

>  3a) Use postinst [to download stuff]

I don't think that's a good idea, simply because of the amount of
data. Downloading things in postinst is OK if it's a couple of
megabytes (see e.g. ttf-mscorefonts-installer in contrib), but
250 Megs?

Also, I could imagine that in a Lab setup where this might be
useful, you'd maybe want to have an air-gapped computer and use
apt-offline to update it. And this would definitely break that
kind of thing.

>  3b) Inform user to call a download script manually to do not
>  block apt for a longer time dealing with potential download
>  problems.

That would be the only option if you don't bundle the data with
the package. In that case, maybe patch the binary to detect that
situation and inform the user they should still do this?

But as I said: if your package doesn't change that often, I don't
think that adding 2x 250 MiB (source and arch=all, right?) is
necessarily excessive.

Regards,
Christian

Bug#829627: ITP: fatx -- Complete FATX filesystem support

[Christian Seiler]

On 07/04/2016 09:38 PM, Christophe DUVERGER wrote:
>   Description : Complete FATX filesystem support
> 
>  Includes:
>  fusefatx: filesystem mounting using fuse,
>  mkfs.fatx: make filesystem,
>  fsck.fatx: check and correct filesystem,
>  label.fatx: change or display volume name,
>  unrm.fatx: undelete files

Could you please mention in the package description (maybe even
in the short description) that this is the filesystem used by
the XBOX console? I think "FATX" is quite confusing if you have
never heard the term before, so adding "XBOX" will likely make
more sense to people looking at the description.

Thanks!

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#828686: ITP: no-new-privs -- Set PR_NO_NEW_PRIVS before executing another program

[Christian Seiler]

Hi,
(cc'ing mentors since you already filed an RFS [1])

> It builds a single, eponymous, binary package.
> 
> I think it is a useful, though extremely simple, utility:
> system administrators may use it to starts processes as a non-privileged
> user and ensure that they cannot attempt to exploit local setuid binaries.

I don't mean to discourage you, but doesn't setpriv --no-new-privs
already do that? It's available in Stretch and sid, in the package
setpriv, built from src:util-linux.

Regards,
Christian

[1] Also, weirdly, I didn't see your ITP on debian-devel for some
reason.



signature.asc
Description: OpenPGP digital signature

Bug#827678: ITP: pacapt -- Arch's pacman-like package manager for some Unices

[Christian Seiler]

On 06/20/2016 08:11 AM, Guillem Jover wrote:
> Hi!
> 
> On Sun, 2016-06-19 at 23:44:50 +0800, ChangZhuo Chen wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: "ChangZhuo Chen (陳昌倬)" 
> 
>> * Package name: pacapt
>>   Version : 2.3.8
>>   Upstream Author : Anh K. Huynh
>> * URL : https://github.com/icy/pacapt
>> * License : Fair
> 
> That license is pretty much non-free, as it does not allow
> modification nor redistribution, only using the code.

Well, according to

https://opensource.org/licenses/fair
http://fairlicense.org/

it's OSI-approved and there apparently has been a discussion on
debian-legal that deems it DFSG-free.

I get your point, to me a plain reading of this license seems
to indicate that modification or redistribution is not allowed,
but apparently in legal terms it does allow for that.

So deferring to debian-legal and OSI I'll consider it to be a
free software license, but I do think that the Fair license is
an epic fail when you measure it up against its goal of having
a license that's even simpler than BSD/MIT, because its primary
effect is to confuse people. (Shorter is not always simpler.)

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#799061: open-isns package in Debian

[Christian Seiler]

Control: owner -1 !

On 06/05/2016 12:20 AM, Peter Pentchev wrote:
> The truth is that it became apparent to me several months
> ago that due to some changes in my work priorities and plans
> there would not really be a use for open-isns in the project
> that we were working on, so I wouldn't really have the time
> to package it.

Thanks for getting back to me. I'll take that as affirmation
that you're OK with me taking over this ITP, which I am doing
with this email. :)

I assume that you also don't want to co-maintain the package
anymore, so I'm not going to add you to Uploaders: of the
initial package. If I'm wrong about that though, just let me
know.

Regards,
Christian

Bug#799061: open-isns package in Debian

[Christian Seiler]

Hi again,

On 05/27/2016 08:06 PM, Christian Seiler wrote:
> just wanted to ping you again about the open-isns package.

Just FYI: there was a question about getting iscsiuio into
Debian on the pkg-iscsi mailing list today:

http://lists.alioth.debian.org/pipermail/pkg-iscsi-maintainers/2016-May/002101.html

I'd really like to be able to tell users of the open-iscsi
package that I'm actively working on it, but I can't enable
iscsiuio support in open-iscsi until I upgrade it. But I
can't upgrade open-iscsi until open-isns is packaged for
Debian.

Since this has been stalled for the last 8 months, and I
haven't heard any replies from you for over 6 months (I
have pinged you 3 times with months of time in between
the pings), I'm hereby announcing that I'll take over this
ITP if I don't hear anything from you in the next 7 days.
I really don't want to step on your toes, especially since
you said you have already started packaging it; and if I
do take over the ITP, I'll be happy to co-maintain it with
you, but I cannot in good conscience let this stall the
progress on open-iscsi any longer - sorry!

Regards,
Christian

Bug#825623: ITP: nlohmann-json -- JSON for Modern C++

[Christian Seiler]

Control: retitle -1 ITP: nlohmann-json -- JSON for Modern C++

Hi again,

On 05/28/2016 12:48 PM, Muri Nicanor wrote:
> On 05/28/2016 12:17 PM, Christian Seiler wrote:
>> On 05/28/2016 11:56 AM, Muri Nicanor wrote:
>>> * Package name: json
>> Since the C++ namespace is called nlohmann (see the code example
>> using json = nlohmann::json), you could perhaps call the source
>> package nlohmann-json, with it creating a binary package called
>> libnlohmann-json-dev - or similar.
> 
> yes, you're totally right! thanks for the tip with the namespace, i'll
> call the package as you suggested.

Great, and thanks for your work on this. usbguard looks very
interesting from the description, I'll definitely take a look
once it's in the archive. :-)

I've retitled the ITP for you.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#825623: ITP: json -- JSON for Modern C++

[Christian Seiler]

Hi,

On 05/28/2016 11:56 AM, Muri Nicanor wrote:
> * Package name: json

I would suggest maybe calling the Debian package something else,
because 'json' is really, really generic, and while the library
you're packaging looks extremely nice (thanks for bringing it to
my attention), I don't think it makes sense to have it reserve
the 'json' package name.

Since the C++ namespace is called nlohmann (see the code example
using json = nlohmann::json), you could perhaps call the source
package nlohmann-json, with it creating a binary package called
libnlohmann-json-dev - or similar.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture

[Christian Seiler]

On 05/07/2016 03:59 PM, Geert Stappers wrote:
> On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote:
>>
>> My gut feeling says that the package 'sse-support' is sabotage on 
>> architecture "any".
>>
> 
> This is from #823465 http://bugs.debian.org/823465
> 
> | I'm afraid there's not enough people who care about 586 enough to maintain
> | it.  And the bad decision of i386 to stick to a single arch during its whole
> | life makes it hard to do so on debian-ports.  Compare with ARM: there's arm
> | armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to
> | make use of new CPU features, which also makes it easy to keep old compat
> | without forcing new processors to stay with the lowest common denominator.
> 
> 
> I now have a better idea _why_  a sse-suport package.
> 
> My concern is how should look a Debian control file at source level ( arch 
> all ).
> At arch Intel makes a 'Depends: sse-support' sense
> Having at arch ARM 'Depens: sse-support' also, will prevent install, but not 
> `build`.

I really don't get what you are saying here. Of course one would NOT
have an arch: any package in Debian that depends on sse-support on
non-i386, you'd put in Depends: sse-support [i386] in debian/control
and the package build would then add the dependency on i386, but not
and anything on other platforms. (If the package in question even
supports other platforms than x86 in the first place.)

Why so critical? The current situation is that if there's a package
in the archive that now only works with SSE extensions, and is not
easily portable to non-SSE (for example, if it contains hand-written
assembly code), then the only recourse that's available _now_ is to
drop i386 from that package's architecture (because it will segfault
without a good error message) - or to add detection in preinst...
(Because porting is not always an option, especially if it's lots of
code.) This does not, however, excuse packages to force SSE support
if a package CAN support other hardware, and it wasn't meant to. It
is meant to cover the cases where a package is either not available
on i386 at all or available to at least some users.

I fail to see why you would think this is a bad thing?

@Adam: One suggestion though: since this might also come in handy
in other places, I'd recommend you name the source package something
more generic (such as cpu-support or so, assuming that's not taken
already, I didn't check), and have it generate a binary package with
the name sse-support. I'm pretty sure that other cases could come up
with a similar requirement in the future, and that way they'd easily
find a home.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#811448: ITP: tiny-initramfs -- A minimalistic initramfs implementation

[Christian Seiler]

Package: wnpp
Owner: Christian Seiler <christ...@iwakd.de>
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: tiny-initramfs
  Version : 0.1
  Upstream Author : Christian Seiler <christ...@iwakd.de>
* URL : https://github.com/chris-se/tiny-initramfs
* License : GPL-3+
  Programming Lang: C
  Description : A minimalistic initramfs implementation

tiny-initramfs is a very minimalistic initramfs implementation for
booting Linux systems. It is designed for systems where a full
initramfs (such as dracut or initramfs-tools) is too large, but where
at least some functionality of an initramfs (such as mounting a
separate /usr partition, or the possibility to use microcode updates
for the processor) is required. It is less than 16 kiB in size.



signature.asc
Description: OpenPGP digital signature

Bug#788076: #788076: Packaged version of gtk3-nocsd (v2)

[Christian Seiler]

Hi Axel,

There were some bugs in version 1 of gtk3-nocsd I release earlier,
so I've now released version 2 upstream and also packaged that for
Debian.

I've uploaded the new version to mentors.debian.net:
https://mentors.debian.net/package/gtk3-nocsd

The library works with every Gtk+ version I could test it with, and
CSDs are consistently disabled. The functionality is enabled by
default on every X11 session that's not GNOME, but both the
administrator and each individual user may change this to their
liking. This is documented in README.Debian.

I've followed your guidelines for packages you sponsor,
https://people.debian.org/~abe/sponsoring/
as close as possible:

 - lintian:
 * 0 errors
 * 3 warnings, overridden for good reason
 Actually, there's only one thing, but it causes
 3 warnings. See the override file for a rationale.
 * 0 informational messages
 * 1 pedantic message: no GPG signatures on upstream
 tarballs
 * the lintian error on mentors is due to the ldconfig
   trigger change - lintian in unstable doesn't give
   that error
 - adequate: no messages
 - blhc: no messages
 - Build system: dh(7), minimal debian/rules
 - debian/copyright: DEP-5
 - proper symbols file for library (although it's a bit useless,
   because nothing is ever going to directly link against it,
   but policy dictates it)
 - library is properly Multi-Arch (thus 2 packages, one arch all
   for the wrapper script + Xsession.d integration, the other
   arch any for the library itself)

It would be great if you could review this and sponsor the upload.

Also, citing my previous mail:

On 10/02/2015 02:48 PM, Christian Seiler wrote:
> I'd like to also use git for packaging and collab-maint on alioth, but
> I can't create anything there myself (neither DD nor DM, although I
> plan to apply for DM status). It would be great if you could create a
> repository there and grant me access to it (my alioth username is
> chris_se-guest).

Best regards,
Christian




signature.asc
Description: OpenPGP digital signature

Bug#788076: #788076: Packaged version of gtk3-nocsd

[Christian Seiler]

Hi Axel,

I've now figured out a way to make gtk3-nocsd work with all relevant
Gtk+3 versions (including those currently in Debian stable, unstable
and experimental). Since I had already reported a couple of things
upstream earlier, and the original author is a bit short on time
currently, he gave me upstream commit access, so I pushed that upstream
and created an initial release on GitHub.

I've packaged that for Debian and uploaded it to mentors.debian.net:
https://mentors.debian.net/package/gtk3-nocsd

I've tried to follow your guidelines in
https://people.debian.org/~abe/sponsoring/
as close as possible:

 - no lintian errors
 - three lintian warnings that I override, please see the comment in
   the lintian-overrides file for as to why I do that
 - no lintian informational messages
 - two lintian pedantic messages w.r.t. upstream:
 - no upstream changelog
   (Ok, technically I could push a changelog upstream, but I'll
   only do that if there's a new release there. This is the
   first upstream version anyway.)
 - upstream releases are not gpg-signed
   (That would be something the original author would have to do,
   since it's his repository.)
 - adequate: no errors with the installed package
 - blhc: no messages
 - dh(7) build system with minimal debian/rules
 - debian/compat is 9
 - debian/copyright follows DEP-5
 - the preloadable library is properly Multi-Arch (thus two binary
   packages - one arch:all for the logic to enable preloading and
   one arch:any for the library itself)

I've successfully build-tested the package in a clean pbuilder
environment for both amd64 and i386 on all of jessie, stretch and
sid. I've been using the package on my Jessie system (where the
Gtk+3 version is old enough that the original version worked) for
quite a couple of months now - and I've tested the package against
more recent Gtk+3 versions.

The package disables CSDs by default (on X11), but this is overridable
by both the administrator and the user, see README.Debian for details.
If GNOME is used as a session, it makes sure that CSDs are enabled,
because I don't want to break the user experience of GNOME users.

It would be great if you could review it.

I'd like to also use git for packaging and collab-maint on alioth, but
I can't create anything there myself (neither DD nor DM, although I
plan to apply for DM status). It would be great if you could create a
repository there and grant me access to it (my alioth username is
chris_se-guest).

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#799061: ITP: open-isns -- Internet Storage Name Service server

[Christian Seiler]

On 09/15/2015 02:30 PM, Peter Pentchev wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Peter Pentchev 
> 
> * Package name: open-isns
>   Version : 0.1.0~git2014.09.04.0.267d43d
>   Upstream Author : Olaf Kirch, Mike Christie 
> * URL : 
> http://www.example.org://github.com/mikechristie/open-isns 
> * License : LGPL-2.1+
>   Programming Lang: C
>   Description : Internet Storage Name Service server
> 
>  This is a partial implementation of iSNS, according to RFC4171.
>  It is useful for in large deployments with many iSCSI targets and
>  initiators, limiting the number of targets visible to any given
>  initiator as needed, and also automating the initial discovery and
>  any further configuration updates.

Thanks very much for doing this. Until recently open-isns was embedded
in open-iscsi, but a couple of months ago it was separated out - so
when Ritesh and I talked at DebConf about this (we both co-maintain
open-iscsi), we decided that we will need to package open-isns. What
kept us from filing an ITP is that we both haven't used iSNS so far,
and the open-iscsi package only uses the client library, we never built
the daemons - so we put the whole thing on the backburner.

So it's great that you want to package it, because we're going to need
it after the next release of open-iscsi, which will drop the embedded
copy and depend on open-isns. (It's already in the open-iscsi upstream
git repository.)

Since this is directly related to iSCSI and open-iscsi is going to
depend on it, would you consider co-maintaining the package together
with Ritesh and myself? We already have the pkg-iscsi-maintainers
project on alioth (including a mailing list), so the infrastructure
is already there.

Note that Mike Christie isn't the primary maintainer of open-isns
anymore, now it's Lee Duncan. See (at the very bottom):
https://github.com/gonzoleeman/open-isns/blob/master/README

The new "official" upstream repository is:
https://github.com/gonzoleeman/open-isns
(Instead of the original one by Mike Christie.)

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#790933: ITP: drive - Google Drive tool

[Christian Seiler]

On 07/05/2015 09:15 AM, Jackson Doak wrote:
 It might be possible to rename the binary and symlink drive to it, which
 would allow you to give the binary name over easier

Personally, I think it would be best not to reserve such a generic name
'drive' for such a specific service. There could easily be something in
the future that actually fits that generic name that now can't be used
because the name is taken by something very specific.

A good example for this is the open(1) command: way back when Linux was
still in its infancy, somebody decided it would be a good idea to have
a command to run something on a different virtual text console, and
they named it 'open'. This is the reason why you have 'xdg-open' for
opening files according to their mime type (and that command is not
that known, because of its name), because 'open' was already taken. For
an operation such as starting something on a new virtual terminal, open
is far too generic a name to have been a sensible choice even back
then, but that ship has sailed.

So _please_, please choose a different name for the binary in
Debian,[1] because accessing a cloud service (that might not be around
in 10 years, see e.g. Google News as for how such things can disappear
in a relatively short time) is something really, really specific and
really shouldn't take up a generic name that will haunt us for years to
come.

Also, _please_ don't symlink it - because then you're also reserving
the name because people are going to use it. Add a comment to the
package's README.Debian that people may add an alias to ~/.profile if
they want to use the upstream name, because then they are aware of
what they're doing.

As for the package name: they can be recycled easier than binary names,
so I don't feel quite as strongly about them, but I would also prefer
'google-drive' or similar.

Thank you.

Christian

[1] Suggestion: 'gdrive', if that's not already taken by something e.g.
GLib/Gtk+-based (I haven't checked).



signature.asc
Description: OpenPGP digital signature

Bug#788076: RFP: gtk3-nocsd -- LD_PRELOADable library to disable GTK+ 3 client side decoration

[Christian Seiler]

Hi Axel,

On 06/09/2015 07:54 PM, Axel Beckert wrote:
 Christian Seiler wrote:
 and I found a fix for the crashes I saw. (I'll have to clean that up
 a bit and create a pull request for upstream.)
 
 Feel free to subscribe @xtaran on Github (i.e. me) to that issue/pull
 request.

So it turns out that while I found a solution that works quite well
with Gtk+ 3.14 (current Debian stable/testing/unstable), it doesn't
work with 3.16 at all (latest upstream release, will probably be in
Debian at some point in the future), because there the code was
changed so that there is no real chance of disabling CSDs anymore.

See my comment at:
https://github.com/PCMan/gtk3-nocsd/pull/8#issuecomment-65390

So I'm sorry to say, but I think that the only real alternative is
to patch Gtk. I am seriously doubtful that one can convince
upstream to provide the option - and therefore I'm not convinced
the maintainers in Debian will be willing to maintain such a
patch that upstream clearly rejects...

Therefore, I don't think it makes sense to package this for Debian
anymore, because it will have a lifetime of at most a month or two
(i.e. when 3.16 enters unstable) before it will stop working. Since
it's your RFP, I'm not closing it myself, but I really don't see
any alternative. :-(

If you want a version that works well with Jessie, you can compile:
https://github.com/chris-se/gtk3-nocsd/tree/various-fixes

Sorry for the bad news. :-(

Best regards,
Christian


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5579a529.5080...@iwakd.de

Bug#788076: RFP: gtk3-nocsd -- LD_PRELOADable library to disable GTK+ 3 client side decoration

[Christian Seiler]

On 06/08/2015 01:54 PM, Axel Beckert wrote:
 Package: wnpp
 Severity: wishlist
 
 * Package name: gtk3-nocsd
   Upstream Author : PCMan pcman.tw -AT- gmail.com
 * URL or Web page : https://github.com/PCMan/gtk3-nocsd
 * License : LGPL-2.1
   Description : LD_PRELOADable library to disable GTK+ 3 client side 
 decoration
 
 gtk3-nocsd is a small LD_PRELOADable library used to disable the client
 side decoration (CSD) of GTK+ 3.
 
 Since GTK+ 3.10, its developers added a so-called header bar or custom
 title bar.  With this and the client-side decoration, the original title
 bar and window border provided by the window manager are disabled by
 GTK+. This makes all GTK+ 3 programs look like alike. Even worse, this
 may break some window manager or compositors.

With the release of Jessie (and the advent of Gtk3-based software that
uses CSD), I've been playing around with gtk3-nocsd myself (compiling
it manually) and while I generally like the idea to return some sanity
to Gtk3-based apps, there are a couple of issues that I stumbled on to
(and prevent me from actually using it):

 - While this preloadable library does get rid of the window manager
   hints that disable server-side decorations, it does not get rid of
   the humongous title bars themselves. I've attached a screenshot
   featuring gedit run with preloaded gtk3-nocsd under KDE4 to
   illustrate the problem. While there are things there that can be
   considered just to be simple toolbar buttons, the windows title and
   the minimize/maximize/close buttons are still there and now
   duplicated. It looks *really* weird, and I think that's the main
   issue that should be solved: you also need to remove everything that
   can be found in the normal title bars of window managers.

 - Popup menus are cut off (see second attached screenshot) - if I run
   gedit without the preloaded lib, this doesn't happen.

 - It crashes some apps when preloaded; most notably virt-manager,
   which is in python2, but I've also seen crashes with apps that just
   use glib2 and not gtk3. Don't know why that is yet.

 - I don't think edit your ~/.profile, as suggested by upstream, is
   a fantastic deployment strategy for this. It kind of goes against
   Debian's just install it and it will work mantra.

Don't misunderstand me: I'm not against packaging this for Debian (in
principle I'm quite in favor of it, because I absolutely loathe the
current state of affairs with gtk3, and would probably be willing to
package that myself), but I think there are a couple of issues that
need to be ironed out first, before this becomes really usable.

Regards,
Christian

Bug#788076: RFP: gtk3-nocsd -- LD_PRELOADable library to disable GTK+ 3 client side decoration

[Christian Seiler]

Hi Axel,

On 06/09/2015 06:24 PM, Axel Beckert wrote:
 Christian Seiler wrote:
  - While this preloadable library does get rid of the window manager
hints that disable server-side decorations, it does not get rid of
the humongous title bars themselves. I've attached a screenshot
featuring gedit run with preloaded gtk3-nocsd under KDE4 to
illustrate the problem. While there are things there that can be
considered just to be simple toolbar buttons, the windows title and
the minimize/maximize/close buttons are still there and now
duplicated.
 
 Urgs. So this can't be get rid of?
 
 I mostly use Awesome and Ratpoison as window managers where the issue
 with borders and title bars are minor. With Awesome, these internal
 title bars and the fact that the window requests to be floating by
 default are the biggest annoyances.

Well, my hope is that one could hack that in additionally. (See below.)

  - I don't think edit your ~/.profile, as suggested by upstream, is
a fantastic deployment strategy for this. It kind of goes against
Debian's just install it and it will work mantra.
 
 Well, depends. The package could drop an appropriate file into
 /etc/X11/Xsession.d/, maybe configured via debconf. That was at least
 what I had in mind.

Sure, I had something along the lines of the following in mind:

BASESTARTUP=${STARTUP%% *}
BASESTARTUP=${BASESTARTUP##*/}
if [ $BASESTARTUP = x-session-manager ]; then
BASESTARTUP=$(basename $(readlink /etc/alternatives/x-session-manager))
fi
case $BASESTARTUP in
  gnome-session*)
# do nothing
;;
  *)
export LD_PRELOAD=...
;;
esac

(Detection logic stolen from gnome Xsession.d files, they should know
best how to do that properly. ;-))

But even then I'd make it configurable per user (and not via debconf per
host), think of large computer network setups at e.g. universities.
Some people might actually like the CSDs even on non-GNOME DEs/WMs.

 Don't misunderstand me: I'm not against packaging this for Debian (in
 principle I'm quite in favor of it, because I absolutely loathe the
 current state of affairs with gtk3, and would probably be willing to
 package that myself), but I think there are a couple of issues that
 need to be ironed out first, before this becomes really usable.
 
 Yeah, sounds like it's not yet as functional as I thought. :-(
 
 Well, on IRC I was suggested to use GTK+ 2 based applications from the
 MATE Desktop project instead. E.g. atril and eom instead of evince and
 eog, but that only helps for formerly official GNOME applications.

Yeah.

Since you've expressed interest in that thing, I got a bit of
motivation in looking at that again, and I found a fix for the crashes
I saw. (I'll have to clean that up a bit and create a pull request for
upstream.) I'm also going to take a look at the window decoration +
popup issues; maybe those can be fixed as well.

Since this is an RFP, so you don't intend to package it yourself: would
you be willing to sponsor an upload if I do package that? The whole CSD
decoration thing has been bugging me for a while now and I doubt the
number of Gtk3 apps is going to decrease soon (rather the opposite), so
the problem is likely going to get worse. And you've given me some
motivation to look into that issue a bit more.

Regards,
Christian


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55771b2c.60...@iwakd.de