Re: tests failing without specific locales

[Guilhem Moulin]

Hi,

On Thu, 09 Jun 2022 at 08:38:40 +0200, Marc Haber wrote:
> On Thu, Jun 09, 2022 at 02:28:48PM +0800, Paul Wise wrote:
>> On Thu, 2022-06-09 at 07:28 +0200, Marc Haber wrote:
>>> I am working on a package written in python that thankfully has a
>>> test suite. Unfortunately, one of the tests fails if the en_GB.UTF-8
>>> locale is not present.
>> 
>> Any idea why the test requires that locale? Tried C.UTF-8?
> 
> I havent looked at the test in detail, I have not yet decided whether
> the package would be helpful in Debian. It looks like the test has
> en_GB.UTF-8 hardcoded, sets the locale to that value and then fails
> it it's not there. Most likely it's the home locale of the dev.
> 
>>> How do I solve this? Do I need to build-depend on the locales-all
>>> package or is there a less ugly way?
>> 
>> I think that using locales-all is currently the only way to ensure that
>> a specific locale other than C/C.UTF-8 is installed.
> 
> And build-depending on that is not bad in some way?

If a single locale is needed then an alternative is to ‘Build-Depends:
locales’ — which is much smaller than locales-all — and generate the
desired locale at build time (and/or via autopkgtests):

debian/control:
Build-Depends: […], locales 

debian/rules:
override_dh_auto_test:
[ -d tests/.locale ] || mkdir tests/.locale
localedef -c -i en_GB -f UTF-8 tests/.locale/en_GB.utf8
env LOCPATH=$(CURDIR)/tests/.locale test_command

debian/clean:
tests/.locale/

At least this is what I've done in a similar situation.  I don't know
if that's better or worse than Build-Depends: locales-all :-)

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#847113: RFS: lacme/0.2-1 - ACME client written with process isolation and minimal privileges in mind

[Guilhem Moulin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lacme"

* Package name: lacme
  Version : 0.2-1
  Upstream Author : Guilhem Moulin <guil...@fripost.org>
* URL : https://git.guilhem.org/lacme/about/
* License : GPL-3+
  Section : utils

It builds the following binary packages:

  lacme — ACME client written with process isolation and minimal privileges in 
mind
  lacme-accountd — lacme account key manager

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/lacme

You can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/l/lacme/lacme_0.2-1.dsc

Changes since the last upload:

* New upstream release.
* debian/control:
  + Promote lacme-accountd from lacme's Suggests to Recommends.
  + Bump Standards-Version to 3.9.8.  No changes.

Thanks!
Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#827425: RFS: lacme/0.1-1 [ITP] -- ACME client written with process isolation and minimal privileges in mind

[Guilhem Moulin]

Hi there,

On Thu, 16 Jun 2016 at 02:30:45 +0200, Guilhem Moulin wrote:
> I am looking for a sponsor for my package "lacme"
> […]
> Alternatively, one can download the package with dget using this command:
> 
>  dget -x https://mentors.debian.net/debian/pool/main/l/lacme/lacme_0.1-1.dsc
> 
> More information about lacme can be obtained from 
> https://git.guilhem.org/lacme/about/ .

I'm still looking for a sponsor for this package.  Would anyone be
willing to sponsor (or at least review) it?

Thanks! ;-)
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#827425: RFS: lacme/0.1-1 [ITP] -- ACME client written with process isolation and minimal privileges in mind

[Guilhem Moulin]

Hi there,

On Mon, 20 Jun 2016 at 22:19:06 +0200, Guilhem Moulin wrote:
> On Wed, 15 Jun 2016 at 22:30:18 -0400, Harlan Lieberman-Berg wrote:
>> Guilhem Moulin <guil...@guilhem.org> writes:
>>> I am looking for a sponsor for my package "lacme"
>>
>> This looks like a well-Debianized package to me.
>> […]
>> I also want to make you aware of the Let's Encrypt Debain Packaging
>> Team, in case you were interested in having the package be co-maintained
>> with us (with the team in Uploaders), or maintained under that heading
>> entirely (with the team in Maintainer).
> 
> Although you didn't take Bug Ownership, did I understand correctly that
> you or your fellow team members might be interested in sponsoring this
> upload?  No hurries, I'm just wondering if I should poke the list again
> in two weeks or so ;-)

Alright, I take the lack of response as a “no”.  (Dropping letsencrypt-
devel@l.a.d.o from the CC.)  I am therefore still in need for a sponsor
for my package lacme, so please allow me to bump the thread in the d-m
archives :-)

https://bugs.debian.org/827425

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#827425: RFS: lacme/0.1-1 [ITP] -- ACME client written with process isolation and minimal privileges in mind

[Guilhem Moulin]

Hi Harlan,

On Wed, 15 Jun 2016 at 22:30:18 -0400, Harlan Lieberman-Berg wrote:
> Guilhem Moulin <guil...@guilhem.org> writes:
>> I am looking for a sponsor for my package "lacme"
>
> This looks like a well-Debianized package to me.
> […]
> I also want to make you aware of the Let's Encrypt Debain Packaging
> Team, in case you were interested in having the package be co-maintained
> with us (with the team in Uploaders), or maintained under that heading
> entirely (with the team in Maintainer).

Although you didn't take Bug Ownership, did I understand correctly that
you or your fellow team members might be interested in sponsoring this
upload?  No hurries, I'm just wondering if I should poke the list again
in two weeks or so ;-)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#827425: RFS: lacme/0.1-1 [ITP] -- ACME client written with process isolation and minimal privileges in mind

[Guilhem Moulin]

Hi Harlan,

On Wed, 15 Jun 2016 at 22:30:18 -0400, Harlan Lieberman-Berg wrote:
> I'm curious about how you would differentiate a package like this from
> the other ACME clients out there -- I know specifically letskencrypt
> seems to fall in the same kind of category (highly isolated
> components; it uses pledge(2) and chroot(2) as well).

I was not aware of Letskencrypt :-P.  lacme development started in early
December 2015 because at the time I was not happy with the ACME clients
offer out there.  It has expanded quite a bit since [0], and I'd some
time to checkout all the clients.  I'm glad to learn I wasn't the only
one raising concern with the monolithic approach of the official client,
though.

But as far as I can tell, lacme's account key management is unique in
that it enables storing the account key on a different host (using the
UNIX-domain socket forwarding facility of OpenSSH 6.7), optionally
PGP-encrypted.  IMHO this is a desirable property as I'm not satisfied
with the current compromise that having early expiration dates forces
site operators to use (and therefore expose) account keys more often.
(On a side note I'm looking forward to GET renewal being implemented in
boulder [1].)  An alternative solution would be to store the account key
on a smartcard; adding smartcard support would be trivial to implement
in lacme, but I don't own one to test it out :-P.

Another feature of lacme is that it is not limited to webservers: for
instance one can automatically issue a certificate for a MTA even when
there is no webserver running on the host.  iptables(8) rules are then
added on the fly (and removed afterwards), and a tiny webserver is
spawned to handle the "http-01" challenges.  However, while lacme can
execute an arbitrary command to restart or reload a given service, it
will not automatically modify server configurations.  (This is a
deliberate choice.)
 
> I also want to make you aware of the Let's Encrypt Debain Packaging
> Team, in case you were interested in having the package be co-maintained
> with us (with the team in Uploaders), or maintained under that heading
> entirely (with the team in Maintainer).

Thanks for coming forward!  I was aware of the team, but didn't dare to
drop you a line :-/  I would be happy with co-maintenance (with the team
in Uploaders).

Cheers,
-- 
Guilhem.

[0] https://github.com/certbot/certbot/wiki/Links
[1] https://tools.ietf.org/html/draft-ietf-acme-acme-02#section-6.5


signature.asc
Description: PGP signature

Bug#827425: RFS: lacme/0.1-1 [ITP] -- ACME client written with process isolation and minimal privileges in mind

[Guilhem Moulin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "lacme"

* Package name: lacme
  Version : 0.1-1
  Upstream Author : Guilhem Moulin <guil...@fripost.org>
* URL : https://git.guilhem.org/lacme/about/
* License : GPL-3+
  Section : utils

It builds the following binary packages:

  lacme — ACME client written with process isolation and minimal privileges in 
mind
  lacme-accountd — lacme account key manager

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/lacme

Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/l/lacme/lacme_0.1-1.dsc

More information about lacme can be obtained from 
https://git.guilhem.org/lacme/about/ .

Changes since the last upload:

  lacme (0.1-1) unstable; urgency=low

* Initial release.  (Closes: #827357, #827358.)

Thanks!
Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#806330: RFS: dropbear/2015.70-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Package: sponsorship-requests
Severity: normal

Dear Mentors,

I am looking for a sponsor for my package "dropbear"

* Package name: dropbear
  Version : 2015.70-1
  Upstream Author : Matt Johnston <m...@ucc.asn.au>
* URL : http://matt.ucc.asn.au/dropbear/
* License : MIT
  Section : net

It builds those binary packages:

  dropbear - transitional dummy package for dropbear-{run,initramfs}
  dropbear-bin - lightweight SSH2 server and client - command line tools
  dropbear-initramfs - lightweight SSH2 server and client - initramfs 
integration
  dropbear-run - lightweight SSH2 server and client - startup scripts

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/dropbear

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.70-1.dsc

More information about dropbear can be obtained from 
http://matt.ucc.asn.au/dropbear/ .

Changes since the last upload:

  [ Matt Johnston ]
  * New upstream release.

  [ Guilhem Moulin ]
  * dropbear-initramfs:
+ Take dropbear options from the DROPBEAR_OPTIONS environment variable,
  for consistency with DROPBEAR_IFDOWN.  For backward compatibility the
  value of $PKGOPTION_dropbear_OPTION is used when DROPBEAR_OPTIONS is
  unset.
+ Take ownership of cryptsetup's /usr/share/doc/cryptsetup/README.remote
  and ship it as /usr/share/doc/dropbear-initramfs/README.initramfs .
  * debian/patches:
+ 0001-dbclient.1-dbclient-uses-compression-if-compiled-with.diff: Remove
  patch applied upstream.
+ 0002-dropbearkey.8-mention-y-option-add-example.diff: Remove patch
  applied upstream.

Regarding the cryptsetup (README.initramfs doc), there is a cryptsetup
bug open (#801471); I haven't had any response yet, but I thought I
would go ahead anyway since the cryptsetup doc is outdated and I don't
see any reason to ship dropbear-specific doc in the cryptsetup package.
I'll change the #801471's title after the upload.  (I don't mind
reverting that change if someone objects, though.)

Thanks!
Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#803993: RFS: netmask/2.4.3-1 - helps determine network masks

[Guilhem Moulin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "netmask"

* Package name: netmask
  Version : 2.4.3-1
  Upstream Author : Robert Stone <ta...@trap.mtview.ca.us>
* URL : https://github.com/talby-/netmask
* License : GPL-2+
  Section : net

It builds those binary packages:

  netmask - helps determine network masks

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/netmask

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/n/netmask/netmask_2.4.3-1.dsc

Changes since the last upload:

  [ Robert Stone ]
  * New upstream release.  (Closes: #802884.)

  [ Guilhem Moulin ]
  * debian/patches:
+ Make the build reproducible: setting --version twice no longer prints
  the build timestamp.
  * debian/control:
+ Change 'Vcs-Git' and 'Vcs-Browser' fields to use collab-maint.
+ Set 'Multi-Arch: foreign'.
  * debian/patches:
+ Remove 'Add foreign to AM_INIT_AUTOMAKE macro' patch, applied upstream.
  * Fix debian/watch file.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Hi,

On Fri, 09 Oct 2015 at 17:19:24 +, Gianfranco Costamagna wrote:
> how do you feel about merging the two above Ubuntu deltas in the Debian 
> packaging?

Thanks for pointing that out.  I didn't check the Ubuntu uploads, actually.

> https://launchpad.net/ubuntu/+source/dropbear/2014.65-1ubuntu1
> + debian/initramfs/premount-devpts, debian/rules: drop the script, this is
>   handled by initramfs-tools.

Done already:

  + Delete debian/initramfs/premount-devpts, since /dev/pts in mounted by
init since initramfs-tools 0.94.  (Closes: #632656, #797939.)

> + debian/initramfs/dropbear-hook: do not install dropbear in the initramfs
>   if there's no uncommented line in /etc/crypttab.

IMHO this is no longer relevant.  The hook now only belongs to the
‘dropbear-initramfs’ binary package, the sole purpose of which is to install
dropbear in the initramfs.  For backward compatibility it's still possible to
disable the hook by setting ‘DROPBEAR=n’, but I don't think we need to make
extra checks: if someone doesn't want the hook they can simply uninstall the
package.  (Furthermore, Ubuntu refuses to install the hook if the crypttab is
nonexistant or empty regardless of the value of $DROPBEAR, which is probably a
bug.  A SSH server in the initrd can have uses beyond remote cryptroot
unlocking.)

> + debian/initramfs/premout-dropbear: fix so that the network configuration
>   happens before dropbear takes hold of the network card.

I believe it's no longer necessary, with this changelog:

  + Run configure_networking in the foreground.  (Closes: #584780, #626181,
#739519.)

> https://launchpad.net/ubuntu/+source/dropbear/2014.65-1ubuntu2
> * Enable hmac-sha2-256 and hmac-sha2-512 MAC algorithms (LP: #1409798)

Upstream took care of that in the subsequent release:

  * New upstream release.  (Closes: #631858, #775222.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Hi!

On Fri, 02 Oct 2015 at 15:49:18 +, Gianfranco Costamagna wrote:
> no problem, just ping me whenever your package becomes ready again.

So with Guillem Jover's help on #debian-dpkg I managed to solve the
problem of the configuration file in dropbear 2014.65-1's /usr.  (Using
dpkg-maintscript-helper to move it to /etc upon upgrade.)  As a
consequence the source package is now lintian-clean and upgrades
smoothly from Jessie :-)

Moreover, piuparts is now happy \o/  (Ignoring the broken symlink
warnings.)  Interestingly, piuparts complains when given the .changes
file; but giving the .deb by order of dependence makes it happy (I guess
one ought to file a bug against dpkg or piuparts):

  sudo piuparts --schroot=unstable-amd64-sbuild … \
dropbear_2015.68-1_all.deb \
dropbear-bin_2015.68-1_amd64.deb \
dropbear-run_2015.68-1_amd64.deb \
dropbear-initramfs_2015.68-1_amd64.deb

I therefore changed the distribution from experimental back to unstable,
and uploaded a new version:

  dget -x 
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.68-1.dsc


Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Hi,

On Fri, 02 Oct 2015 at 14:47:21 +, Gianfranco Costamagna wrote:
> cat of what? I'm not sure this is correct... can you please clarify?

cat of the ‘showpubkey’ function's standard input :-)  ‘showpubkey’ is
used as follows:

  dropbearkey … | showpubkey "$keyfile"

dropbearkey(1) prints the public part of the host key to the standard
output.  If ssh-keygen(1) is available it is used to display its
fingerprint and ASCII art representation, which is arguably more useful
than the public key itself.  If ssh-keygen(1) isn't available showpubkey
is a noop: it merely boils down to ‘dropbearkey … | cat’.

Actually I'd like to give a last try to make piupart happy this
week-end.  I didn't totally give up yet ;-)  Would you mind waiting
until Monday?  I'll report here how it went.  (That said I guess it
doesn't matter if a not puiparts-clean version is uploaded to
experimental in the meantime.)

Many thanks for the thorough review!  And for bringing my attention to
piuparts ;-)
Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Hi,

On Thu, 01 Oct 2015 at 17:53:21 +0100, Gianfranco Costamagna wrote:
> Hi, I could own the bug no problem, just I would like to avoid
> stealing the package to Helmut!

Fair enough :-)
 
> - dpkg shows that a default configuration file has changed, asking me how to 
> proceed

This is because /etc/default/dropbear (from dropbear-run) is modified by
the postinst script to add NO_START=1 if the OpenSSH server is
installed.  (In fact ‘d/dropbear-run.dropbear.default’ is empty and
content is added by the postinst script.)

FWIW, dropbear have had this behavior since 2007 at least (the starting
year of its git repo).  I wish I knew a better way achieve the same
thing.
 
> - there is a lintian error about conf files in usr (that might be
> mounted in read only mode) (this is an old issue)

Yes, this is a regression from 2014.64-1.  In the first version of my
packages (until 5 days ago) I used to no longer mark this file as a conf
file, but you pointed out that you couldn't upgrade from Wheezy and
after further investigation it seems that dpkg chokes on the double
change of package name (dropbear vs. dropbear-initramfs) and file name
(/usr/… file moved to /etc + creation of a symlink in /usr).  That's why
I propose to proceed in two steps and keep that lintian error until
Strech.  (See the lintian override comment, or message #117 of this
bug.)
 
> since I'm unsure about the first, and since I need to dpkg -f the
> files, I would like to ask you to go for experimental and wait for
> some automatic piuparts test

Sure :-)

> (or manual of course).
> 
> I know I asked you to go for unstable, but I'm not confident enough
> about my review
> 
> (and I can't run piuparts successfully).

I tried hard to make piupart happy, but wasn't successful at it either.
The further I got was to upgrade seamlessly (/etc/default/dropbear
aside) from clean (short of dialog, busybox, and initramfs-tools) Jessie
chroot.  And ensure that nothing is remaining after removal.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Hej Gianfranco!

On Fri, 25 Sep 2015 at 20:25:08 +0200, Guilhem Moulin wrote:
> You'll find the new upload at
> 
>  dget -x 
> http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.68-1.dsc

Did you have time to look at the new upload yet?  (Since you didn't take
ownership of the RFS I don't know if you're intending to sponsor it or
if you're “only” providing — valuable! — feedback.  In the latter case I
should probably poke d-m@l.d.o again ;-)

Thanks!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#799615: RFS: netmask/2.4.2-1 [ITA] - helps determine network masks

[Guilhem Moulin]

On Tue, 29 Sep 2015 at 11:21:29 +0200, Paul Wise wrote:
> For the uscan OpenPGP support to work, upstream needs to release
> tarballs (using make distcheck), upload detached OpenPGP signatures
> and debian/watch needs to contain an pgpsigurlmangle= option. The
> github releases feature can be used to store the tarballs and detached
> OpenPGP signatures.

Yes I know, I do that on dropbear already :-)  Also in my first mail to
upstream I asked them to consider publishing detached signatures along
with the tarballs (although I didn't know it was possible to do it with
GitHub).  In the meantime I added d/upstream/signing-key.asc so the
world can check signatures on upstream's Git tags against the same key
that I use.  Signed Git tags is so much better than no signature at all
;-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#799615: RFS: netmask/2.4.0-1 [ITA] - helps determine network masks

[Guilhem Moulin]

On Mon, 28 Sep 2015 at 11:37:39 +0200, Paul Wise wrote:
> On Fri, Sep 25, 2015 at 9:26 PM, Guilhem Moulin wrote:
>> not a reason for rejection
> 
> Not being willing to sponsor the package isn't a rejection, just an
> indicator that I don't have time for a proper initial review and
> ongoing sponsorship.

That's also what I understand since you wrote that upfront.  Sorry if I
sounded rude :-/  I was merely arguing in case a potential sponsor would
wait for me to fix these before stepping forward ;-)

> My mail was part quick review for things you might want to look at and
> part advertisment for the check-all-the-things tool :)

Yeah, many thanks for the review anyway.  And as far as I'm concerned
the advertisement is a success and I'll make sure to watch your talk from
Debconf ;-)

>> Done for the homepage and upstream/metadata.  Thanks for the tips.
>> (Unfortunately upstream currently doesn't tag their release nor provide
>> tarballs, so the watchfile is useless right now since I don't know how
>> to mangle the versions, right?)
> 
> There is a versioned upstream tarball available on the author's
> website, I assumed that was where you got your tarball from but I
> guess you generated it from github somehow?
> 
> http://trap.mtview.ca.us/~talby/
> http://trap.mtview.ca.us/~talby/netmask_2.4.tar.gz

Yes indeed, I also found this tarball, but it's much older than github's
2.4.0.  In particular IPv6 addresses are not supported.

>> I serve git over (smart) HTTP.  And well, the CA is valid, it just
>> happen not to be in your CA store :-P
> 
> Nor in any other default CA store ;-P

Yeah the way #718434 is a pity IMHO :-/  Anyway that's why I intend to
to switch to Let's Encrypt in two months.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#799615: RFS: netmask/2.4.2-1 [ITA] - helps determine network masks

[Guilhem Moulin]

Control: retitle -1 RFS: netmask/2.4.2-1 [ITA] - helps determine network masks

On Mon, 28 Sep 2015 at 11:37:39 +0200, Paul Wise wrote:
> Part of the package maintainer's job is to forward patches, bug
> reports and feedback upstream, so thanks for doing that :)

Moreover upstream has been super reactive on this one and has already
released a new version with some of the fixes you suggested, which also
allowed me to further simplify debian/rules.  I just finished the
packaging and uploaded it to d.m.n:

  dget -x 
http://mentors.debian.net/debian/pool/main/n/netmask/netmask_2.4.2-1.dsc

Thanks!
Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

On Fri, 25 Sep 2015 at 13:59:11 +, Gianfranco Costamagna wrote:
>> Making people upset was certainly not my intention.  And it's precisely
>> because I don't have upload rights that I didn't put my name in the
>> Uploaders fields.  Anyway I don't care either way, so if it's less
>> controversial to swap the addresses I'll do that.
> I guess maintainer is a more important role than uploaders, but nobody objects
> your good intentions, and I won't complain if you want to leave things as is 
> :)

Alright :-)

>> Hmm.  dpkg -c on the the 4 deb files tells me this file is only shipped
>> by dropbear-initramfs, not dropbear.  Could that be because it was
>> marked by dropbear 2014.64 and 2014.65 as a configuration file?  I
>> ceased to do so as it violates the Debian Policy Manual section 10.7.2.
> 
> I guess here the problem might be due to some missing break+replaces
> prior the file was owned by dropbear,
> […]
> so maybe you just need to add some stuff in the control file
> https://wiki.debian.org/PackageTransition
> 
> (not sure, I didn't check, I see many breaks+replaces there)

Adding Breaks+Replaces fields to the 'dropbear' binary package didn't
help.  It's possible that I didn't try the right combination of
Breaks/Replaces.  Here is what I propose as a workaround:

  2015.68-1 → Strech:
revert commit e76daa2 and add
/usr/share/initramfs-tools/conf-hooks.d/dropbear back to
dropbear-initramfs's configuration files.  (This violates the Debian
Policy Manual section 10.7.2.)

  from Strech onwards:
make /usr/share/initramfs-tools/conf-hooks.d/dropbear a symlink to
/etc/initramfs-tools/conf-hooks.d/dropbear, which can been added
dropbear-initramfs's configuration files without policy violation.

I didn't manage to make seamless upgrade from Wheezy without the
intermediate step.  It looks like dpkg can't handle the package rename
somehow:  I successfully upgraded shamelessly from Wheezy's dropbear to
dropbear-{,-run,-bin,initramfs} 2015.68-1 (1st step), then to 2015.68-2
(2nd step).

You'll find the new upload at

  dget -x 
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.68-1.dsc

(I added lintian override for the TODO note, even though the tag is
non-overridable.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#799615: RFS: netmask/2.4.0 - helps determine network masks

[Guilhem Moulin]

Hi Paul,

On Wed, 23 Sep 2015 at 18:03:41 +0200, Paul Wise wrote:
> The source package should not be a native source package as netmask
> isn't Debian specific.

It has however (to my surprise as well) been a native package since its
integration to Debian in 1999.  Just made it non-native as you
suggested, though.

> Are buildflags.mk and override_dh_auto_build nessecary? Usually they
> aren't for autoconf.

Yes, upstream has a weird way to manage the CFLAGS/CPPFLAGS/LDFLAGS.
The only way I could override the variables to add the hardening options
was to pass them to ‘make’.
 
> Is debian/info nessecary? Usually the upstream build system is
> responsible for installing info documents.

No indeed it's not, thanks.
 
> The upstream NEWS file doesn't look very useful, I would suggest
> asking upstream to rename the ChangeLog to NEWS (or just not
> installing NEWS).
> 
> The upstream README file has an incorrect version number and claim
> about initial public release in it, you might want to suggest upstream
> to remove the version number from it.

Will do.  Not a reason for rejection though :-P
 
> Is debian/dirs nessecary? Usually the upstream build system and
> debhelper automatically create those two dirs.

No indeed it's not, thanks.
 
> I would suggest adding a Homepage field pointing at the github page to
> debian/control.
> 
> I would suggest adding a debian/watch file and a debian/upstream/metadata 
> file.
> 
> https://wiki.debian.org/debian/watch
> https://wiki.debian.org/UpstreamMetadata

Done for the homepage and upstream/metadata.  Thanks for the tips.
(Unfortunately upstream currently doesn't tag their release nor provide
tarballs, so the watchfile is useless right now since I don't know how
to mangle the versions, right?)

> I would suggest that upstream tag their releases and upload their
> tarballs to github using the releases feature.
> 
> https://github.com/talby-/netmask/releases

Yeah, that would be great.  I asked about that already ;-)

> I would suggest that upstream should remove from git all the files
> generated or copied in by autotools.
> 
> Yourself and upstream might want to OpenPGP-sign git commits, git tags
> and release tarballs:
> 
> http://mikegerwitz.com/papers/git-horror-story
> https://help.riseup.net/en/security/message-security/openpgp/best-practices

I have done that right after my ITA :-)  Didn't get a reply yet, though.
 
> This line in the upstream configure.in looks weird, usually -O only
> goes up to 3:
> 
> : ${CFLAGS='-Wall -g -O6'}

Will tell upstream about that.
 
> aclocal: warning: autoconf input should be named 'configure.ac', not
> 'configure.in'
> automake: warning: autoconf input should be named 'configure.ac', not
> 'configure.in'
> configure.in:3: warning: AM_INIT_AUTOMAKE: two- and three-arguments
> forms are deprecated.  For more info, see:
> configure.in:3:
> http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
> automake: warning: autoconf input should be named 'configure.ac', not
> 'configure.in'
>
> lintian:
> 
> X: netmask source: deprecated-configure-filename

Yeah, the build system is from 1999 and hasn't been much upgraded since
:-/  Surely upstream noticed the warning already, but I'll point it out
anyway.  However IMHO it's not a reason for rejection either :-P

> $ duck
> E: debian/control: Vcs-Git: https://git.guilhem.org/netmask: ERROR
> (Certainty:certain)
>  fatal: unable to access 'https://git.guilhem.org/netmask/': server
> certificate verification failed. CAfile:
> /etc/ssl/certs/ca-certificates.crt CRLfile: none

I serve git over (smart) HTTP.  And well, the CA is valid, it just
happen not to be in your CA store :-P

> $ fdupes -q -r .
> ./testdata.14
> ./testdata.15
> 
> ./testdata.19
> ./testdata.23
> 
> ./version.texi
> ./stamp-vti
> 
> $ licensecheck --check=. --recursive --copyright . | grep -i incorrect
> ./errors.h: GPL (v2 or later) (with incorrect FSF address)
> ./main.c: GPL (v2 or later) (with incorrect FSF address)
> ./missing: GPL (v2 or later) (with incorrect FSF address)
> ./mdate-sh: GPL (v2 or later) (with incorrect FSF address)
> ./errors.c: GPL (v2 or later) (with incorrect FSF address)
> ./texinfo.tex: GPL (v2 or later) (with incorrect FSF address)
> ./netmask.c: GPL (v2 or later) (with incorrect FSF address)
> 
> $ licensecheck --check=. --recursive --copyright . | grep -F 'GENERATED FILE'
> ./configure: GENERATED FILE
> ./Makefile.in: GENERATED FILE

Again I intend to be the maintainer, not upstream :-P  (And the package
has been around in its current state for 16 years.)  I'll forward your
remarks upstream though.

In the meantime I have uploaded a new version:
  dget -x 
http://mentors.debian.net/debian/pool/main/n/netmask/netmask_2.4.0-1.dsc

Thanks for the feedback,
cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Hi!  Thanks for your interest.  And generally for your mentoring work :-)

On Fri, 25 Sep 2015 at 12:11:54 +, Gianfranco Costamagna wrote:
>> I don't mind either way :-)  But why would you swap the addresses?
>> (Yes I read section 3.3 of the policy, it didn't help me
>> understanding.)
> 
> for two reasons, don't make people upset, and because he is a DD :)

Making people upset was certainly not my intention.  And it's precisely
because I don't have upload rights that I didn't put my name in the
Uploaders fields.  Anyway I don't care either way, so if it's less
controversial to swap the addresses I'll do that.

>> GPL vs MIT is not my choice, as debian/initramfs/* was originally
>> contributed by  under GPL-2+.  Anyway upstream
>> could as well GPL-license the remote cryptroot unlocking feature, but
>> AFAIK they are not interested in merging it.
 
> well, I tried to install on an Ubuntu machine:
> sudo dpkg -i ../dropbear_2015.68-1_all.deb  
> ../dropbear-initramfs_2015.68-1_amd64.deb ../dropbear-run_2015.68-1_amd64.deb 
> ../dropbear-bin_2015.68-1_amd64.deb
> dpkg: regarding .../dropbear-initramfs_2015.68-1_amd64.deb containing 
> dropbear-initramfs:
> dropbear-initramfs conflicts with plymouth
> plymouth (version 0.9.0-0ubuntu9) is present and installed.

Yes, remote cryptroot unlocking doesn't work with plymouth because
unlike /lib/cryptsetup/askpass it doesn't create a FIFO on which to dump
the passphrase.  A bug has been opened on laundpad (#733268), but in the
meantime I made dropbear-initramfs conflict with plymouth to avoid bad
surprises ;-)
 
> Converting existing OpenSSH DSA host key to Dropbear format.
> Key is a ssh-dss key
> Wrote key to '/etc/dropbear/dropbear_dss_host_key'
> 1024 mykey /etc/dropbear/dropbear_dss_host_key (DSA)
> […]
> Converting existing OpenSSH RSA host key to Dropbear format.
> Key is a ssh-rsa key
> Wrote key to '/etc/dropbear/dropbear_rsa_host_key'
> […]
> Converting existing OpenSSH ECDSA host key to Dropbear format.
> Key is a ecdsa-sha2-nistp256 key
> Wrote key to '/etc/dropbear/dropbear_ecdsa_host_key'

Yes this is normal.  dropbear's post-install script has done that for
years for RSA and DSA.  As mentioned in the changelog, I added ECDSA
conversion and ACSII art (via ssh-keygen) to dropbear-run's post-install
script.

> OpenSSH appears to be installed.  Setting /etc/default/dropbear so that
> Dropbear will not start by default.  Edit this file to change this behaviour.

Again this is inherited from dropbear ≤2014.65.  (Both OpenSSH and
dropbear want to listen on port 22.)  It's weird to install two SSH
severs, but I did that myself as I put dropbear to the initramfs and use
OpenSSH otherwise.  (With the split I would not install dropbear-run to
avoid the above messages.)

> also piuparts seems to be not really happy
> 
> http://debomatic-amd64.debian.net/distribution#unstable/dropbear/2015.68-1/piuparts

I don't know about the broken-symlink /etc/dropbear/log/main →
/var/log/dropbear .  It has been there for years and might have to do
with runit, so I just left it there.

Thanks for pointing the untracked file and directory.  I've now added

  debian/dropbear-initramfs.dirs
  debian/dropbear-run.default

> and I can't upgrade from a jessie machine
> trying to overwrite /usr/share/initramfs-tools/conf-hooks.d/dropbear which is 
> also in package dropbear 2015.68-1

Hmm.  dpkg -c on the the 4 deb files tells me this file is only shipped
by dropbear-initramfs, not dropbear.  Could that be because it was
marked by dropbear 2014.64 and 2014.65 as a configuration file?  I
ceased to do so as it violates the Debian Policy Manual section 10.7.2.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Hi,

On Mon, 21 Sep 2015 at 15:03:16 +, Gianfranco Costamagna wrote:
> +Maintainer: Guilhem Moulin <guil...@guilhem.org>
> +Uploaders: Gerrit Pape <p...@smarden.org>,
> 
> I would do the opposite, but well, as you wish :)

I don't mind either way :-)  But why would you swap the addresses?  (Yes
I read section 3.3 of the policy, it didn't help me understanding.)

> I think dh-autoreconf is already enough, but please double check (I didn't 
> test a build)

Ah yes indeed, I forgot to remove autoconf and automake after deciding
to add dh-autoreconf to Build-Depends as a fix for #689618.
 
> 2)changelog: changes are huge, maybe urgency=low might be more appropriate 
> (or experimental)

Alright.  I went for medium urgency as the upload fixes some important
bugs, but none were RC indeed.
 
> 3)copyright: with upstream MIT, and you GPL-2 or GPL-3, it becomes impossible 
> to forward patches
> to them.
> 
> Do you have any good reason for using a different license?

GPL vs MIT is not my choice, as debian/initramfs/* was originally
contributed by <deb...@x.ray.net> under GPL-2+.  Anyway upstream could
as well GPL-license the remote cryptroot unlocking feature, but AFAIK
they are not interested in merging it.
 
Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Hi Helmut & Gianfranco,

By the way if you don't have time or are no longer interested in
sponsoring this upload (which is no longer an NMU by the way) please
just say it out loud so I can poke debian-mentors@l.d.o again :-)

Thanks!
Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#799615: RFS: netmask/2.4.0 - helps determine network masks

[Guilhem Moulin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "netmask"

* Package name: netmask
  Version : 2.4.0
  Upstream Author : Robert Stone <ta...@trap.mtview.ca.us>
* URL : https://github.com/talby-/netmask
* License : GPL-2+
  Section : net

It builds those binary packages:

  netmask - helps determine network masks

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/netmask

Alternatively, one can download the package with dget using this command:

  dget -x http://mentors.debian.net/debian/pool/main/n/netmask/netmask_2.4.0.dsc

Changes since the last upload:

  [ Robert Stone ]
  * New upstream release.  (Closes: #79512.)

  [ Guilhem Moulin ]
  * New maintainer.  (Closes: #784185.)
  * debian/compat: bump debhelper compatibility level from 4 to 9.
  * debian/control:
+ Bump Standards-Version to 3.9.6 (no changes necessary).
+ Add 'Vcs-Git' and 'Vcs-Browser' fields.
+ Add 'dh-autoreconf' and 'texinfo' to Build-Depends.
  * debian/copyright: convert to machine-readable format (1.0).
  * debian/gbp.conf: add file.
  * netmask.texi: Add the missing '@direntry' to the info document.

Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#790125: RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

[Guilhem Moulin]

Control: title -1 RFS: dropbear/2015.68-1 - lightweight SSH2 server and client

Hi Gerrit & al.,

On Wed, 16 Sep 2015 at 12:19:39 +, Gerrit Pape wrote:
> Comaintenance is fine too.

Awesome, thanks!  I've therefore removed the NMU annotations and
uploaded 2015.68-1 to m.d.n:

  dget -x 
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.68-1.dsc

I've also applied for a repository at collab-maint to ease
collaboration.  However I didn't set the Vcs-{Git,Browser}: fields in
the above upload, as I'm waiting for the directory to be created first.

Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#790125: RFS: dropbear/2015.67-1.1 NMU

[Guilhem Moulin]

Hi Gianfranco,

On Thu, 20 Aug 2015 at 07:23:55 +, Gianfranco Costamagna wrote:
 I didn't follow the thread, and seems that other DDs are already caring of
 this one, so I would just put my .02$ (and let me know if you need a review
 or help).

Thanks!  So far only Helmut has given feedback and offered to have
another look when time allows.  I'll ping you if there is no follow-up
by the end of the month or so.  (That said I wouldn't mind more eyeballs
looking at the package either ;-)

 2) what about updating to the latest version and upload on experimental?
 
 I don't see all this need to go for unstable, I might even sponsor an 
 experimental upload
 because if Gerrit is not satisfied he can continue and upload his version to 
 unstable,
 and experimental will disappear automagically.
 
 Isn't this one the experimental suite pourpose?
 We are still in the Stretch early stage, we might delay unstable until other 
 folks tested it.

If by “update to the latest version” you meant my dropbear-{bin,run,initramfs} 
packages,
you'll find them there:

  dget -x 
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.68-0.1.dsc

Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#790125: RFS: dropbear/2015.67-1.1 NMU

[Guilhem Moulin]

Hi there,

On Thu, 30 Jul 2015 at 22:21:21 +0200, Helmut Grohne wrote:
 In general, I'd find sponsoring this NMU much easier if the package
 split and the fixing of those many bugs could happen in separate
 uploads. Each part is complex and the fallout is hard to estimate. I
 understand that such a separation would mean more work for you. Do you
 think that doing this in two steps is worth the added effort?

Alright, would it help moving forward if I were doing that?  Reverting
to 2014.65 is easy, and the current 2015.68-1 could always be uploaded
once 2014.65-1 has entered testing.  It'd be quite sad to upload known
bugs in a package containing multiple lintian warnings and errors [0],
but if someone is willing to review and upload the package, but only
with the split of dropbear-{bin,run,initramfs} and without the many
extra bug fixes, then I'm ready to clean, test and release [1].

Cheers,
-- 
Guilhem.

[0] https://lintian.debian.org/full/p...@smarden.org.html#dropbear_2014.65-1
[1] 
https://gitweb.guilhem.org/dropbear?p=dropbear;a=commit;h=64ea640134b67e68daad2096d54afc91b0722895


signature.asc
Description: Digital signature

Bug#790125: RFS: dropbear/2015.67-1.1 NMU

[Guilhem Moulin]

Hi Helmut,

On Fri, 31 Jul 2015 at 07:46:26 +0200, Helmut Grohne wrote:
 That was quick. Let me answer some of your comments already. I intend
 to take another stab at the upload when I find more time, but that
 shall not prevent other interested sponsors from uploading it earlier.
 Possibly Gerrit replied by then.

I still have a hope to make it to Debconf (I'm currently on the waiting
list :-/).  Would be great to make it happen there!

FYI upstream made a new release today.  That includes a fix to the two
issues you reported in #27;  my own patches included in patches/series
have been applied as well.

  http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2015q3/001777.html

However, this time I didn't pull in the changes (although Debian is now 3
releases behind…)

 On Fri, Jul 31, 2015 at 05:44:09AM +0200, Guilhem Moulin wrote:
 Alright, this one is new to me.  I'm not sure how blindly I can follow
 
https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools
 
 because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’.
 So checked the package source for openssh and found that openssh-server
 uses Multi-Arch:foreign, but openssh-sftp-server, which ships
 ‘/usr/lib/openssh/sftp-server’, doesn't.  So all in all I'm unsure what
 to in my case.
 
 It is actually much easier than that. Since dropbear does not ship any
 libraries or similar, the only Multi-Arch tag that makes sense is
 foreign. So this is mostly a matter of asking: Does a package expose
 its architecture via one of its public interfaces? If the answer is
 no, then foreign is appropriate.
 […]
 I didn't spot any reason for not marking all of the dropbear packages
 M-A:foreign, but this probably warrants a closer look.

Thanks for the explanation.  Yes, ‘Multi-Arch: foreign’ is the right tag
in that case.  I have updated my debian/control, but I'll wait for a
second round of feedback before uploading the package to mentors.

-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#790125: RFS: dropbear/2015.67-1.1 NMU

[Guilhem Moulin]

Hi Helmut,

On Thu, 30 Jul 2015 at 22:21:21 +0200, Helmut Grohne wrote:
 Thanks for your work on dropbear. Much appreciated.

And thanks for the extensive feedback!  I know it's quite a heavy
changelog, so I didn't really expect anyone other than Gerrit perhaps to
check it out that closely.

 On Sat, Jul 11, 2015 at 03:20:52PM +0200, Guilhem Moulin wrote:
 Note that while the current maintainer (Gerrit, CC'ed) told me to go
 ahead and proceed with a NMU, they are not able to sponsor me at the
 moment.  Furthermore I'm currently a DM and would be open to
 co-maintenance once time is ripe.
 
 My reading of Gerrit's mail is a bit more limited. He wrote to d-devel:
 | Unfortunately I cannot support you, but don't hesitate to NMU the
 | dropbear package to be able to proceed.
 
 May be this is hair-splitting, but I'd read this as NMUing specifically
 for the purpose of splitting out the initramfs stuff (and then moving it
 to a different source package). I'd not assume that doing a new upstream
 release is covered by the above. Maybe Gerrit can clarify that or we can
 go via a delayed queue.

Yeah true, I might have taken too much liberty here.  I noticed upstream
was already two releases ahead so I wildly pulled in the new tarball :-/
(plus it fixed #775222 ;-)  Then I couldn't split the package without
doing major refactoring (which thanks to debhelper automatically solved
#689618, #692932, #777324, #793006, #793917).  And later I guess I got
carried away with enthusiasm on the way and decided to try to fix the
remaining bugs (some of them were quite old, and most fixes were rather
easy; at least the one relevant to the initramfs feature, which didn't
seem to be maintained anymore, and which bothered me personally since I
use this feature myself) :-P

 Despite me having lots of comments, your changes are actually of high
 quality. Don't get scared! Some comments are picky/matter of taste. Feel
 free to disagree.

No worries.  Constructive criticism never hurts anyway ;-)

 Since you bump the upstream release your NMU version should be -0.1
 instead of -1.1.

Thanks, fixed.

 I note that the new tilde expansion functionality in the upstream
 release is a bit strange. If my own home is /home/helmut, it will
 expand ~/foo to /home/helmut//foo (note the double slash). Worse, it
 will expand expand ~otheruser/foo to /home/helmut/otheruser/foo,
 which does not match the general expectation of tilde expansion.

Well spotted.  I guess one ought to file a bug.

 Gerrit asked for the binaries to be located in dropbear, but you place
 them in dropbear-bin. Maybe Gerrit can also ack this? (It was stated
 as a preference.)

In fact in a later mail in the d-d thread Gerrit agreed to make
“dropbear” a transitional package and place binaries to “dropbear-bin”,
as suggested to me by Adam Borowski:

https://lists.debian.org/debian-devel/2015/06/msg00290.html
 
 Since dropbear-initramfs relies on initramfs-tools 0.94 features, the
 dependency should be versioned.

Thanks, fixed.  (Didn't think it mattered since even oldoldstable has
said feature.)

 If you disable password logins by default, please mention in a NEWS
 entry!

It was never enabled in the initramfs (disabling it without notice would
have been foolish otherwise, indeed).  The change I made (initramfs-only
only) is to no longer make the server *advertise* it, so that clients
won't prompt for a password and try to send it to the server (which is
bound to reject it anyway).  Sorry for the confusion.
 
 Would it make sense to install the NEWS file to the transitional package
 only? (i.e. mv debian/NEWS debian/dropbear.NEWS)

Yes it would!  Fixed, thanks for the suggestion.
 
 It might be safer in the future if dropbear-{initramfs,run} use a (=
 ${binary:Version}) dependency on dropbear-bin. Will you remember to bump
 such a dependency when dropbear-run starts to use a new option? (But
 --link-doc incurs this dependency anyway.)

You mean if upstream starts deprecate options used in
dropbear-{initramfs,run}?  Which by the way seems to happen right now
with ‘-d’ with is now an alias for ‘-r’ but has been removed from the
manpage, see #761143.  (And now I realize I could have written a note
regarding s/-d/-r/ in the NEWS regarding that change :-/)

Yeah that makes sense, I tightened the dependency by specifying the
${binary:Version}.

 Please consider whether Multi-Arch:foreign markings are appropriate for
 some packages.

Alright, this one is new to me.  I'm not sure how blindly I can follow

https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools

because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’.
So checked the package source for openssh and found that openssh-server
uses Multi-Arch:foreign, but openssh-sftp-server, which ships
‘/usr/lib/openssh/sftp-server’, doesn't.  So all in all I'm unsure what
to in my case.

 Why are dropbear-{initramfs,run} marked as Architecture:any? Do they
 contain any architecture specific

Bug#790125: RFS: dropbear/2015.67-1.1 NMU

[Guilhem Moulin]

Hi Vincent, Gerrit,

On Tue, 14 Jul 2015 at 18:42:53 -0700, Vincent Cheng wrote:
 NMUs are intended to be minimally intrusive and be targeted to fix
 specific bugs (and usually RC/important ones); that means that in
 general, you should avoid things like new upstream releases and
 extensive packaging changes, and your proposed debdiff should be as
 small as possible.

Yes I know: I intended to split the initramfs stuff, but I couldn't make
multiple binary packages into the same source package without major
refactoring.

 Your changes are more in scope of a package adoption than a NMU.

I'd be open for adoption of dropbear-initramfs indeed, but it's best to
keep the same source package for the three dropbear-*, hence my offer to
co-maintenance instead ;-)

 While I don't want to discourage you from doing extensive work to
 improve dropbear, you'll likely find it difficult to find a DD other
 than the maintainer who's willing to sponsor this as a NMU.

Fair enough, I'll wait then.  Thanks for you answer anyway :-)

-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#790125: RFS: dropbear/2015.67-1.1 NMU

[Guilhem Moulin]

Dear mentors,

I am still in need for a sponsor for my package dropbear, so please
allow me to bump the thread :-)

https://bugs.debian.org/790125

Note that while the current maintainer (Gerrit, CC'ed) told me to go
ahead and proceed with a NMU, they are not able to sponsor me at the
moment.  Furthermore I'm currently a DM and would be open to
co-maintenance once time is ripe.

 To access further information about this package, please visit the following 
 URL:
 
 http://mentors.debian.net/package/dropbear
 
 Alternatively, one can download the package with dget using this command:
 
 dget -x 
 http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.67-1.1.dsc

Feedback would also be appreciated, whether it leads to sponsorship or
not.

Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Re: uscan warning: pgpsigurlmangle option exists, but the upstream keyring does not exist

[Guilhem Moulin]

Hi Mathieu,

On Mon, 29 Jun 2015 at 21:26:50 +0200, Mathieu Malaterre wrote:
 uscan warning: pgpsigurlmangle option exists, but the upstream keyring does
 not exist
  in debian/watch, skipping:

uscan(1) uses its own keyring, which is usually checked out in the
debian branch: You need to export the signing key(s) to one of:

debian/upstream/signing-key.pgp
debian/upstream/signing-key.asc
debian/upstream-signing-key.pgp.

For instance:

gpg --export-option export-minimal --armor --export \
  D31BEF17F9EAA92AF3C0FD59CE76547BAC103A8D debian/upstream/signing-key.asc

Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#790125: RFS: dropbear/2015.67-1.1 NMU

[Guilhem Moulin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package dropbear

* Package name: dropbear
  Version : 2015.67-1.1
  Upstream Author : Matt Johnston m...@ucc.asn.au
* URL : http://matt.ucc.asn.au/dropbear/
* License : MIT
  Section : net

It builds those binary packages:

  dropbear - transitional dummy package for dropbear-{run,initramfs}
  dropbear-bin - lightweight SSH2 server and client - command line tools
  dropbear-initramfs - lightweight SSH2 server and client - initramfs 
integration
  dropbear-run - lightweight SSH2 server and client - startup scripts

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/dropbear

Alternatively, one can download the package with dget using this command:
   
  dget -x 
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.67-1.1.dsc

More information about dropbear can be obtained from 
http://matt.ucc.asn.au/dropbear/ .
The maintainer told me to go ahead a proceed with the NMU [0].

Changes since the last upload:

  * Non-maintainer upload.

  [ Matt Johnston ]
  * New upstream release.  (Closes: #775222.)

  [ Guilhem Moulin ]
  * debian/source/format: 3.0 (quilt)
  * debian/compat: 9
  * debian/control: bump Standards-Version to 3.9.6 (no changes necessary).
  * debian/copyright: add machine-readable file.
  * Split up package in dropbear-bin (binaries), dropbear-run (init scripts)
and dropbear-initramfs (initramfs integration).  'dropbear' is now a
transitional dummy package depending on on dropbear-run and
dropbear-initramfs.  (Closes: #692932.)
  * Refactorize the package using dh_* tools, including dh_autoreconf.
(Closes: #689618, #777324.)
  * dropbear-run:
+ Add a status option to the /etc/init.d script.
+ Pass key files with -r not -d in /etc/init.d script.  (Closes: #761143.)
+ Post-installation script: Generate missing ECDSA in addition to RSA and
  DSS host keys.  (Closes: #776976.)
  * dropbear-initramfs:
+ Don't mark /usr/share/initramfs-tools/conf-hooks.d/dropbear as a
  configuration file, since it violates the Debian Policy Manual section
  10.7.2.  (Regression from 2014.64-1.)
+ Delete debian/initramfs/premount-devpts, since /dev/pts in mounted by
  init since initramfs-tools 0.94.  (Closes: #632656.)
+ Auto-generate host keys in the postinstall script, not when runing
  update-initramfs.  Pass the '-R' option (via $PKGOPTION_dropbear_OPTION)
  for the old behavior.  Also, print fingerprint and ASCII art for
  generated keys (if ssh-keygen is available).
+ Revert ad2fb1c and remove warning about changing host key.  Users
  shouldn't be encouraged to use the same keys in the encrypted partition
  and in the initramfs.  The proper fix is to use an alternative port or
  UserKnownHostFile.
+ Set ~root to `mktemp -d $DESTDIR/root-XX` to avoid collisions with
  $rootmnt.  (Closes: #558115.)
+ Exit gracefully if $IP is 'none' or 'off'.  (Closes: #692932.)
+ Start dropbear with flag -s to explicitly disable password logins.
+ Terminate all children before killing dropbear, to avoid stalled SSH
  connections.  (Closes: #735203.)
+ Run configure_networking in the foreground.  (Closes: #584780, #626181,
  #739519.)
+ Bring down interfaces and flush network configuration before existing
  the ramdisk, to avoid misconfigured network in the regular kernel.
  (Closes: #715048, #720987, #720988.)
+ Add a script '/bin/unlock' to the initramfs to make remote unlocking
  easier and possibly as a forced-command restrictions in authorized_keys.

Cheers,
-- 
Guilhem.

[0] https://lists.debian.org/debian-devel/2015/06/msg00285.html


signature.asc
Description: Digital signature

Upgrading debian/copyright to version 1.0

[Guilhem Moulin]

 can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
  (at your option) any later version. You can find a copy of it in your
  Debian system under /usr/share/common-licenses/

License for gpgwrap:
  It was downloaded from http://unusedino.de/gpgwrap/

  Copyright: Copyright 2004-2006 by Karsten Scheibler gpgw...@unusedino.de

  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
  (at your option) any later version. You can find a copy of it in your
  Debian system under /usr/share/common-licenses/

License for gpgparticipants-prefill:
  Copyright 2013, Stefan Huber shu...@sthu.org

  Permission is hereby granted, free of charge, to any person
  obtaining a copy of this software and associated documentation
  files (the Software), to deal in the Software without
  restriction, including without limitation the rights to use,
  copy, modify, merge, publish, distribute, sublicense, and/or sell
  copies of the Software, and to permit persons to whom the
  Software is furnished to do so, subject to the following
  conditions:

  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
  HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  OTHER DEALINGS IN THE SOFTWARE.
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: native package

Files: *
Copyright: © 2000, 2002, 2004, 2005, 2006  Peter Palfrader pe...@palfrader.org
   © 2004-2008  Christoph Berg c...@df7cb.de
   © 2001-2005  Simon Richter s...@debian.org
   © 2005-2008  Thijs Kinkhorst th...@debian.org
   © 2008-2011  Franck Joncourt fra...@debian.org
   © 2014  Guilhem moulin guil...@guilhem.org
License: FIXME

Files: caff/*
Copyright: © 2004, 2005, 2006  Peter Palfrader pe...@palfrader.org
   © 2005, 2006  Christoph Berg c...@df7cb.de
   © 2014  Guilhem Moulin guil...@guilhem.org
License: BSD-3-clause

Files: caff/pgp-clean
Copyright: © 2004, 2005  Peter Palfrader pe...@palfrader.org
   © 2006  Christoph Berg c...@df7cb.de
License: BSD-3-clause

Files: caff/pgp-fixkey
Copyright: © 2004, 2005  Peter Palfrader pe...@palfrader.org
License: BSD-3-clause

Files: gpgdir/*
Copyright: © 2002-2008  Michael B. Rash (m...@cipherdyne.org)
License: GPL-2+
Comment: Downloaded from http://www.cipherdyne.com/gpgdir/ .

Files: gpg-key2ps/*
Copyright: © 2001-2005  Simon Richter s...@debian.org
   © 2005-2008  Thijs Kinkhorst th...@debian.org
   © 2005-2008  Christoph Berg c...@df7cb.de 
License: GPL-2+

Files: gpglist/*
Copyright: © 2004  Uli Martens u...@youam.net
   © 2005  Peter Palfrader pe...@palfrader.org 
License: BSD-3-clause

Files: gpg-mailkeys/*
Copyright: © 2001-2005  Simon Richter s...@debian.org
   © 2005  Thijs Kinkhorst th...@debian.org
License: GPL-2+

Files: gpg-mailkeys/gpg-mailkeys.1
Copyright: © 2005  Simon Richter s...@debian.org
License: GPL-2+

Files: gpgparticipants/*
Copyright: © 2008  Philippe Teuwen p...@teuwen.org
License: GPL-2+

Files: gpgparticipants/gpgparticipants-prefill*
Copyright: © 2013  Stefan Huber shu...@sthu.org
   © 2014  Peter Palfrader pe...@palfrader.org
License: MIT

Files: gpgsigs/*
Copyright: © 2004  Uli Martens u...@youam.net
   © 2004, 2005  Peter Palfrader pe...@palfrader.org
   © 2004, 2005, 2006, 2007  Christoph Berg c...@df7cb.de
   © 2014  Guilhem Moulin guil...@guilhem.org
License: BSD-3-clause

Files: gpgwrap/*
Copyright: © 2004-2006  Karsten Scheibler gpgw...@unusedino.de
License: GPL-2+
Comment: Downloaded from http://unusedino.de/gpgwrap/ .

Files: keyanalyze/*
Copyright: © M. Drew Streib dt...@dtype.org
License: GPL-2
Comment: Downloaded from http://dtype.org/keyanalyze/code.php .

Files: keyanalyze/keyanalyze.c
Copyright: © 2001  M. Drew Streib dt...@dtype.org
   © 2001  Thomas Roessler roess...@guug.de
   © 2001  Hal J. Burch hbu...@halport.lumeta.com
   © 2001  Matt Kraai kr...@alumni.carnegiemellon.edu
   © 2001  Steve Langasek vor...@netexpress.net
License: GPL-2

Files: keyanalyze/keyanalyze.1 keyanalyze/pgpring/pgpring.1 
keyanalyze/process_keys.1
Copyright: © 2004  Matthew Wilcox wi...@debian.org
License: GPL-2

Files: keyanalyze/pgpring/extlib.c
Copyright: © 1999-2000  Thomas Roessler roess