Bug#1063909: grub_plugin.py: fails to install grub-ieee1275 on sparc64

[Lars Wirzenius]

FYI: I've applied the patch upstream and the test suite passes.
However, I'm not sure the test suite tests vmdb2 in a way that this
patch would affect.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#1056546: When using a cached root-fs, vmdb2 runs apt before mounting the virtual filesystems, leading to some errors

[Lars Wirzenius]

I don't often look at the vmdb2 bugs in Debian, sorry, so replies are
often late.

On Wed, Nov 22, 2023 at 05:41:47PM +0100, Daniel Leidert wrote:
> I'm not quite sure about this, but shouldn't "virtual-filesystems" be a
> requirement before running apt (which seems to be called by vmdb2 internally,
> not by a target).

The debootstrap plugin runs "apt-get update" in case the rootfs
tarball is old. If this breaks building an image unless
virtual-filesystems is used before, that's news to me. The vmdb2 test
suite (see base.vmdb) has virtual-filesystems after debootstrap, but
does use cached rootfs tarballs, and it works.

I'm probably missing something.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#1021341: vmdb2: missing dependency on zerofree

[Lars Wirzenius]

On Sat, 2023-11-11 at 10:30 -0600, Gunnar Wolf wrote:
> I am adding a Recommends: on zerofree and will soon upload (and close
> thus bug). Michael: I understand your point, but given this is a
> design decision from our upstream author, I prefer adding a Cc: to
> Lars and ask him to consider switching from zerofree over to fstim,
> maybe he has reasons not to.
> 
> Greetings,
> 
>-Gunnar


vmdb2 uses zerofree by default so that the generated image will compress to
be smaller. This is important for my own use cases.

If this isn't great for other use cases, one can avoid the zerofree by
adding `zerofree: false` to the `mount` step. See
 for details.

I'm happy to consider a patch to use fstrim instead of zerofree, but I'm
not likely to make one myself any time soon, sorry.

Bug#1021802: vmdb2: Grub UEFI installation fails when rootfs is created by debootstrap

[Lars Wirzenius]

Thanks! I've reviewed this, and it looks good to me, and I've merged it
upstream.

On Fri, 2022-10-14 at 23:02 -0300, Antonio Terceiro wrote:
> Package: vmdb2
> Version: 0.26-1
> Severity: normal
> Tags: patch
> X-Debbugs-CC: l...@liw.fi
> 
> Dear Maintainer,
> 
> I was trying to create an arm64 image with GRUB and UEFI from my amd64
> laptop, using the attached definition. It would fail at the GRUB install
> phase, and the error message was saying that it was trying to install
> grub-efi-amd64 even though I was creating an arm64 image. I then noticed
> that the debootstrap plugin was not setting the architecture globally,
> what caused the grub plugin to not use the correct architecture.
> 
> The attached patch fixes this.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (500, 
> 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages vmdb2 depends on:
> ii  cmdtest 0.32.14.gcdfe14e-4
> ii  debootstrap 1.0.127+nmu1
> ii  e2fsprogs   1.46.6~rc1-1
> ii  kpartx  0.9.0-4
> ii  parted  3.5-2
> ii  python3 3.10.6-1
> ii  python3-jinja2  3.0.3-2
> ii  python3-yaml5.4.1-1+b2
> ii  qemu-utils  1:7.1+dfsg-2
> 
> Versions of packages vmdb2 recommends:
> ii  ansible   6.4.0+dfsg-1
> ii  dosfstools4.2-1
> ii  qemu-user-static  1:7.1+dfsg-2
> 
> vmdb2 suggests no packages.
> 
> -- no debconf information



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

Bug#1016843: apt: should probably use "sop" for OpenPGP

[Lars Wirzenius]

Package: apt
Severity: wishlist

Currently apt is using gpgv to verify Release.gpg files. It would
probably be a good idea to use an implemenation of the SOP interface
instead. SOP is short for "stateless OpenPGP", and it's a
specification by Daniel Kahn Gillmor (dkg). See

https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

There are many implementations of that, including one for GnuPG.
Having a consistent interface makes it easier to switch to a different
implementation. The OpenPGP Interoperabiolity Test Suite
(https://tests.sequoia-pgp.org/) uses this.

If APT used SOP, it could even allow a sysadmin to choose what
implementation they want. This would free apt from being locked into
GnuPG without abandoning OpenPGP entirely.

The SOP interface is pretty good for programmatic use.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#992496: monkeysphere: Homepage doesn't exist anymore (https://web.monkeysphere.info)

[Lars Wirzenius]

Package: monkeysphere
Version: 0.43-3.1
Severity: minor

Dear Maintainer,

When I look at the package, it lists a home page that doesn't exist.

Package: monkeysphere
Version: 0.43-3.1
Priority: optional
Section: net
Maintainer: Debian Privacy Tools Maintainers 

Installed-Size: 285 kB
Depends: adduser, gnupg (>= 2.1.17), libcrypt-openssl-rsa-perl, 
libdigest-sha-perl, lockfile-progs | procmail, openssh-client, perl:any
Recommends: agent-transfer, cron-daemon, netcat-openbsd | netcat | socat, 
ssh-askpass
Suggests: monkeysphere-validation-agent
Enhances: openssh-client, openssh-server
--> Homepage: https://web.monkeysphere.info/
Tag: protocol::ssh, protocol::ssl, security::authentication
Download-Size: 78.6 kB
APT-Sources: http://deb.debian.org/debian bullseye/main amd64 Packages
Description: leverage the OpenPGP web of trust for SSH and TLS 
authentication
 SSH key-based authentication is tried-and-true, but it lacks a true
 Public Key Infrastructure for key certification, revocation and
 expiration.  Monkeysphere is a framework that uses the OpenPGP web of
 trust for these PKI functions.  It can be used in both directions:
 for users to get validated host keys, and for hosts to authenticate
 users.  Current monkeysphere SSH tools are designed to integrate
 with the OpenSSH implementation of the Secure Shell protocol.
 .
 Monkeysphere can also be used by a validation agent to validate TLS
 connections (e.g. https).

The web.monkeysphere.info name does not seem to be in DNS. My DNS
seems to work otherwise.

~~~sh
$ host web.monkeysphere.info
Host web.monkeysphere.info not found: 3(NXDOMAIN)
$ host monkeysphere.info
Host monkeysphere.info not found: 3(NXDOMAIN)
$ host google.com
google.com has address 142.250.74.110
google.com has IPv6 address 2a00:1450:400f:80b::200e
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
$ 
~~~


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages monkeysphere depends on:
ii  adduser3.118
ii  gnupg  2.2.27-2
pn  libcrypt-openssl-rsa-perl  
ii  openssh-client 1:8.4p1-5
ii  perl [libdigest-sha-perl]  5.32.1-4+deb11u1
ii  procmail   3.22-26

Versions of packages monkeysphere recommends:
pn  agent-transfer   
ii  cron [cron-daemon]   3.0pl1-137
ii  netcat-openbsd [netcat]  1.217-3
ii  netcat-traditional [netcat]  1.10-46
pn  ssh-askpass  

Versions of packages monkeysphere suggests:
pn  monkeysphere-validation-agent  

Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64

[Lars Wirzenius]

On Tue, Dec 08, 2020 at 05:12:57PM +, David Edmondson wrote:
> I figured that out today (need to specify a 64 bit CPU) and provided an
> updated set of patches.

I'll just note that David updated his patches and that I've merged
them now.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64

[Lars Wirzenius]

As it happens, David Edmonson (dme), added to cc, has been working on
adding arm64 support for the grub plugin. Part of his changes is that the
grub plugin will know the target archietecure, and choose the right grub
.deb package to install based on that.

Unfortunatly, the tests for his changes don't pass yet.

David, do you have any commnent on this?

On Sat, 2020-11-07 at 23:42 -0600, Gunnar Wolf wrote:
> Hello Lars,
> 
> I am writing to you regarding the bug report I am Cc:ing here. Please
> help me correctly answer to this! The submitter says, in the initial
> mail:
> 
> > I am trying to let autopkgtest-build-qemu work on arm64.
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038
> > for relevant report.
> > The original autopkgtest-build-qemu uses "grub: bios" for vmdb2,
> > which let vmdb2 install grub-pc on arm64, and fail.
> > 
> > So I try "grub: uefi" for vmdb2.
> > Then vmdb2 tries to install grub-efi-amd64,
> > and again fails.
> > There is no way to let vmdb2 to create a bootable image on arm64.
> > vmdb2 seems completely unusable on arm64 (and armhf, armel, etc.)
> > So I set severity grave.
> 
> He sent a workaround that does not fix the issue, but lets him build
> for his target system:
> 
> --- usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py-orig
> 2020-10-31 12:47:04.796899268 +0900
> +++ usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py 
> 2020-10-31 12:50:00.322817935 +0900
> @@ -112,8 +112,8 @@
>  raise Exception('"efi" or "efi-part" required in UEFI GRUB 
> installation')
>  
>  vmdb.progress("Installing GRUB for UEFI")
> -grub_package = "grub-efi-amd64"
> -grub_target = "x86_64-efi"
> +grub_package = "grub-efi-arm64"
> +grub_target = "arm64-efi"
>  self.install_grub(values, settings, state, grub_package, 
> grub_target)
>  
>  def install_bios(self, values, settings, state):
> 
> *If* there is any information to plugins as to which architecture is
> being built, the fix is basically trivial... But I could not find
> anything on that regard. Can you suggest anything?
> 
> Thanks a lot!

Bug#916405: vmdb2 (called from autopkgtest-build-qemu) fails to unmount loop

[Lars Wirzenius]

On Fri, Dec 14, 2018 at 01:28:14AM +0100, Bernhard Schmidt wrote:
> building a new autopkgtest image with autopkgtest-build-qemu (which uses 
> vmdb2)
> fails with the following error
...
> I have no exact idea why, but the culprit is a mount of
> /tmp/tmpz1biu6_9/sys/fs/fuse/connections that is not visible anywhere.

I don't know to check for Debian's autopkgtest results, and I don't
know if this is still an issue, but I also can't reproduce this. vmdb2
does try, these days, to unmount anything under foo/ before unmounting
foo/ itself.

If there's a way to reproduce this, I'd be very interested in hearing
that. Without a reproduction, I don't know think I can fix this.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#966201: vmdb2: temporary Ansible inventory files are not removed properly

[Lars Wirzenius]

On Fri, Jul 24, 2020 at 05:05:16PM +0100, Bob Ham wrote:
It seems that only the last-created inventory file is removed:

As upstream, I confirm this. (Now reported upstream:
https://gitlab.com/larswirzenius/vmdb2/-/issues/38)

Should be an easy fix: either remember all the inventory files, and
delete all of them; or only create one and reuse it the next time the
plugin is used.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#951766: vmdb2: assumes grub-install in target has --force-extra-removable option

[Lars Wirzenius]

On Fri, Feb 21, 2020 at 12:21:29PM +, Simon McVittie wrote:
> This appears to be because --force-extra-removable is a Debian-specific
> option, added by
> .

I confirm that diagnosis. I would really, really prefer it if Ubuntu
didn't break compatbility with Debian here. I'd really, really prefer
to avoid having vmdb2 sniff whether some option is available or not.
But it seems Ubuntu didn't reverse this for their current LTS release.

I also don't understand PC booting very deeply, so I'm not sure if the
option is necessary for vmdb2 to use. (Help and explanations would be
appreciated.)

Given that Ubuntu is the unmoveable object here, I see two options for
vmdb2:

1. vmdb2 runs grub-install --help and looks for the
  --force-extra-removable, and only use it if listed in the output.

2. vmdb2 won't use the option by default and requires the user to say
   they want it by adding an "force-extra-removable: yes" field to the
   grub step.

I'm leaning towards the second. Opinions?

> I think this would also be a problem if installing a
> non-Debian-derived OS.

But only those who are incompatible with Debian's grub-install, I think.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#949456: vmdb2: grub failure with mklabel gpt

[Lars Wirzenius]

On Mon, Jan 20, 2020 at 05:54:03PM -0800, Matt Taggart wrote:
> When I use the example yaml config at
> 
> https://vmdb2-manual.liw.fi/#getting-started

Note that in the mean while the manual has changed and uses an msdos
partition table now. The code does have a working example, which gets
tested automatically:
https://gitlab.com/larswirzenius/vmdb2/-/blob/master/uefi.vmdb

> If I change the mklabel step to use msdos instead of gpt then it works.

The following is a working version. You need to use UEFI for grub, and
add an EFI partition. I don't know of a way to use gpt with BIOS
booting, but I may just be ignorant about that.

~~~yaml
steps:
  - mkimg: "{{ output }}"
size: 4G
  - mklabel: gpt
device: "{{ output }}"
  - mkpart: primary
device: "{{ output }}"
start: 0%
end: 100M
tag: efi
  - mkpart: primary
device: "{{ output }}"
start: 100M
end: 100%
tag: /
  - kpartx: "{{ output }}"
  - mkfs: vfat
partition: efi
  - mkfs: ext4
partition: /
  - mount: /
  - debootstrap: buster
mirror: http://deb.debian.org/debian
target: /
  - apt: install
packages:
- linux-image-amd64
tag: /
  - fstab: /
  - grub: uefi
tag: /
efi: efi
~~~

I hope that helps.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#948125: Please use partx (in essential util-linux) rather than kpartx

[Lars Wirzenius]

On Sat, Jan 04, 2020 at 02:55:00AM -0800, Josh Triplett wrote:
vmdb2 depends on the kpartx package; could it, instead, use partx from
> the essential util-linux package?

Speaking as upstream here: I had a look at partx, but I couldn't
figure out how to replace kpartx with it. If you can show me how to do
that, I'd be happy to make the changes to vmdb2 to use partx and to
drop the kpartx dependency.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#928485: Error messages are not shown without --verbose

[Lars Wirzenius]

On Wed, Dec 11, 2019 at 06:29:49PM -0600, Gunnar Wolf wrote:
> tags 928485 + patch,pending
> thanks
> 
> I have submitted a patch upstream fixing this issue. Merge request
> available at:
> 
> https://gitlab.com/larswirzenius/vmdb2/merge_requests/4

Thank you for the MR. I decided not to accept it, as it happens. I'm
not fond of a --quiet option for suppressing error messages. I did,
however, remove the need for --verbose to see error messages. I must
have been asleep when I added that code originally.

vmdb2 still needs a lot of improvement in how it detects and reports
errors, though.

I leave it to gwolf to close this bug when updating the package in
Debian.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#922713: vmdb2: please add a step to create /etc/fstab in the image (PATCH)

[Lars Wirzenius]

I've finally  merged this patch, with a minor fix. It's pushed to both
public, official git repositories (git.liw.fi, gitlab.com).

On Thu, Feb 21, 2019 at 09:47:45AM -0300, Antonio Terceiro wrote:
> It turns out I needed to make quite a few changes. I needed to add two
> new attributes to tags: one to record the filesystem type of each
> partition, and another to record the target mount point, because the
> existing mount point attribute records the mount point in the host.
> 
> You will find the final patches attached.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#945480: [PATCH 0/1] Drop remaining usage of python2

[Lars Wirzenius]

On Thu, 2019-11-28 at 10:40 -0600, Gunnar Wolf wrote:
> Lars Wirzenius dijo [Thu, Nov 28, 2019 at 11:27:54AM +0200]:
> > Thanks, I've applied the changes and pushed them to git.liw.fi and
> > gitlab.
> 
> Thanks for your prompt attention, Lars!
> 
> I am about to board a plane, but will try to work on this bug later
> today. Lars, do you want to tag a release? Or should I do again the
> "+git20191128" way?

If you could do the +git... thing this time, I'd appreciate it.

Safe travels.


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

Bug#945480: [PATCH 0/1] Drop remaining usage of python2

[Lars Wirzenius]

Thanks, I've applied the changes and pushed them to git.liw.fi and
gitlab.

On Mon, Nov 25, 2019 at 03:27:31PM -0300, Antonio Terceiro wrote:
> Hello,
> 
> The following patch drops the remaining usage of python2 in vmdb2, in
> the build system and test suite.
> 
> Gunnar: I just uploaded a cmdtest ported to python3, so without this
> vmdb2 will still fail to build because the test suite uses yarn
> internals which will not be available for python2 anymore.
> 
> Antonio Terceiro (1):
>   Remove remaining usage of python2
> 
>  check |  2 +-
>  setup.py  |  2 +-
>  yarns/900-implements.yarn | 10 +-
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> -- 
> 2.24.0
> 

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#910201: Processed: tagging 910201

[Lars Wirzenius]

On Wed, 2019-03-06 at 12:39 +0200, Jonathan Carter wrote:
> Hi Lars, I promise that we will stop using vmdebootstap as soon as
> humanly possible after buster. I'm just not sure it's safely and
> reasonably possible before then.

Good. If I get betterer, I may be able to help with that in, say, six months.
Feel free to ask me then, especially if you are willing to consider using
vmdb2 as a replacement.

Happy hacking!


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

Bug#910201: Processed: tagging 910201

[Lars Wirzenius]

On Wed, Mar 06, 2019 at 06:33:00AM +, Niels Thykier wrote:
> I am sorry to hear that you are sad by this.  To be honest, I had
> expected you were informed about this already.
> 
> This was requested in #922826 with the argument that our live image
> builds no longer worked and that it was too risky to rewrite it at this
> time in the release cycle (I remember some of this discussion from IRC,
> so it might not be visible in the bug).
> 
> I have CC'ed the people requesting/supporting this change as they are
> better suited for answering any questions you have in details but also
> figuring out where we go from here (even if that ends up being something
> as trivial as replacing you the maintainer field, so you are not listed
> at the direct contact point vmdebootstrap longer than you had anticipated).

Since I retired, I don't follow any Debian mailing lists, and I'm only
on one obscure Debian related IRC channel, which mostly doesn't even
talk about Debian. I feel better this way, as so much of Debian is bad
for my serenity and mental health. There's a lot of great people in
Debian, and a lot of great work happens in Debian, and I like the
distro, but there's also a number of people doing things that make me
really unhappy about being associated with the in any way. Which is
why I retired.

I made some very really incompetent, rookie mistakes when first
writing vmdebootstrap, and as a result it is one of the worst pieces
of software I've released in decades. It's so fundamentally bad that
it can't be fixed without rethinking and redesigning it from scratch.
That it sometimes mostly works is no excuse.

I've been trying to kill it off for a couple of years now.
Unfortunately, I've not been able to help those using it from
transitioning to something better. Specifically, Debian's live image
building.

When I retired from Debian last year I intentionally didn't upload a
version setting the maintainer to QA, since that carried the risk that
someone would adopt it. I don't want it adopted, I want it killed.

If it was my decision, I'd rather Debian release without a live image
than release one built with vmdebootstrap. However, I realise that
this would not be acceptable to most people and that live images are
used by enough people that Debian needs to provide them.

In a cruel twist of fate, I originally wrote vmdebootstrap because the
Debian live image building tools were buiding images that weren't
suitable for my needs, and also I found the tools to be written in way
thatI didn't want to even try to change them to suit my needs. Writing
my own tool from scratch seemed like it would be easy and an
interesting challenge. I'm paying for that hubris now.

I accept that buster will release with vmdebootstrap. If you could
make it so I don't get any emails about, taking me off as the package
maintainer, that would be nice and I would appreciate that. Thank you.

I'm afraid I won't be answering any bug reports, accept any patches,
or provide any help in keeping vmdebootstrap alive or working through
the life of the buster release.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#910201: Processed: tagging 910201

[Lars Wirzenius]

On Tue, Mar 05, 2019 at 07:24:03PM +, Debian Bug Tracking System wrote:
> Added tag(s) bullseye and sid.

Does this mean buster is going to be released with vmdebootstrap? This
would make me sad. Why is this? I'm not going to spend any time to fix
vmdebootstrap. I'd really rather nobody else did, either, and instead
spent the effort on fixing anything that still uses vmdebootstrap to
use something else.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#922660: Patch applied

[Lars Wirzenius]

I've applied the patch in upstream git. Thanks.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#922713: vmdb2: please add a step to create /etc/fstab in the image (PATCH)

[Lars Wirzenius]

On Tue, Feb 19, 2019 at 03:34:35PM -0300, Antonio Terceiro wrote:
> Only vmdb2 can know exactly what device is mounted as the image rootfs.
> Therefore, the only reliable way of creating /etc/fstab to have a
> working image, is to do that from withing vmdb2 itself.
> 
> Patch attached.

Thank you. Creating an fstab seems like a good idea. However, it looks
to me like it only handles one mount point, and vmdb2 allows any
number, e.g., /boot may be separate.

Would it make sense to change this so that it creates an fstab that
has all mount points without them needing to be listed by the user? I
think this should be doable by iterating over the tags structure. What
do you think?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#922709: vmdb2: variable for rootfs caching is incorrectly documented

[Lars Wirzenius]

On Tue, Feb 19, 2019 at 03:29:02PM -0300, Antonio Terceiro wrote:
> Package: vmdb2
> Version: 0.13.2+git20190215-1
> Severity: normal
> Tags: patch
> 
> (debbugs cc: Lars)
> 
> The documentation says `rootfs-unpacked`, but the variable is actually
> called `rootfs_unpacked`.

Confirmed. Thanks.

> Patch attached.

Ouch, I missed that there was a patch, so I sed'd it myself. But I
credited you in the commit message anyway.

Fixed in upstream commit ab93e16dd188a43c33ac9b845f7c11a35e5e96c0.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#922020: gnome-shell: Keyboard layout not applied in programs using Xwayland

[Lars Wirzenius]

> What precisely do you mean by "not applied"? Does typing into Firefox
> and GTK2 apps behave as though you were using a USA keyboard
> (shift+2 -> @, shift+3 -> #, etc.)  or does it have some other
> behaviour?

In native GNOME applications, pressing the key that normally gives
me "-" (dash) gives me "-", which is appropriate for the Finnish
keyboard layout. In other programs, it gives me "/", which is US
layout, and other keys are also consistent with US layout (shift-3 is
# and not £ so it's not UK layout).

> What is in your /etc/default/keyboard?

XKBMODEL="pc105"
XKBLAYOUT="fi"
XKBVARIANT=""
XKBOPTIONS=""
BACKSPACE="guess"

> What does `gsettings list-recursively
> org.gnome.desktop.input-sources` say?

org.gnome.desktop.input-sources show-all-sources false
org.gnome.desktop.input-sources xkb-options @as []
org.gnome.desktop.input-sources per-window false
org.gnome.desktop.input-sources current uint32 0
org.gnome.desktop.input-sources mru-sources @a(ss) []
org.gnome.desktop.input-sources sources [('xkb', 'fi')]

(Under X, not Wayland. See below.)

> Are there any warnings in the systemd journal or syslog that look
> relevant?

I wouldn't know.

> Have you restarted gnome-shell (logged out and back in) since upgrading?
> (I don't expect that this would make any difference, but whether you
> did or not is an important data point in trying to reproduce the bug.)

I rebooted after dist-upgrading, yes.

> Does downgrading gnome-shell to the version in testing resolve this
> for you?

I didn't try, and it's not convenient for me to try.

> Other packages that might be relevant include mutter,
> gnome-settings-daemon, and anything else that /var/log/apt mentions as
> having been upgraded around the same time as gnome-shell.

I did two weeks' worth of dist-upgrade at once. There were lots of
packages. I haven't narrowed down what it was.

I worked around this problem by changing /etc/gdm3/daemon.conf have
WaylandEnable=false
instead of it being commented out, and rebooting. Now everything works.


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

Bug#914030: O: cmdtest -- blackbox testing of Unix command line programs

[Lars Wirzenius]

Package: wnpp
Severity: normal

I intend to orphan the cmdtest package. I'm retiring from Debian.

The package description is:
 cmdtest black box tests Unix command line tools. Roughly, it is given a
 a script, its input files, and its expected output files. cmdtest runs
 the script, and checks the output is as expected.
 .
 cmdtest is aimed specifically at testing non-interactive Unix command
 line programs, and tries to make that as easy as possible.
 .
 Also included is a "scenario testing" tool, yarn.
 cmdtest black box tests Unix command line tools. Roughly, it is given a
 a script, its input files, and its expected output files. cmdtest runs
 the script, and checks the output is as expected.
 .
 cmdtest is aimed specifically at testing non-interactive Unix command
 line programs, and tries to make that as easy as possible.
 .
 Also included is a "scenario testing" tool, yarn.

Bug#914029: O: python-coverage-test-runner -- fail Python program unit tests unless they test everything

[Lars Wirzenius]

Package: wnpp
Severity: normal

I intend to orphan the python-coverage-test-runner package.

The package description is:
 This package contains the Python module CoverageTestRunner, which runs
 unit tests implemented using the unittest module in the Python standard
 library. It runs them using coverage.py (in the python-coverage package)
 and fails the test if all statements are not covered.

Bug#914028: O: python-cliapp -- Python framework for Unix command line programs

[Lars Wirzenius]

Package: wnpp
Severity: normal

I intend to orphan the python-cliapp package.

The package description is:
 cliapp makes it easier to write typical Unix command line programs,
 by taking care of the common tasks they need to do, such as
 parsing the command line, reading configuration files, setting
 up logging, iterating over lines of input files, and so on.

Bug#914026: O: python-ttystatus -- terminal progress bar and status output for Python

[Lars Wirzenius]

Package: wnpp
Severity: normal

I intend to orphan the python-ttystatus package. (Already uploaded
with Maintainer set to QA.)

The package description is:
 ttystatus is a Python library for showing progress reporting and status
 updates on terminals, for (Unix) command line programs. Output is
 automatically adapted to the width of the terminal: truncated if it does
 not fit, and re-sized if the terminal size changes.
 .
 Output is provided via widgets. Each widgets formats some data into
 a suitable form for output. It gets the data either via its initializer,
 or from key/value pairs maintained by the master object. The values are
 set by the user. Every time a value is updated, widgets get updated
 (although the terminal is only updated every so often to give user time
 to actually read the output).
 .
 The output from ttystatus goes to the terminal (`/dev/tty`) and is
 restricted to a single line.
 ttystatus is a Python library for showing progress reporting and status
 updates on terminals, for (Unix) command line programs. Output is
 automatically adapted to the width of the terminal: truncated if it does
 not fit, and re-sized if the terminal size changes.
 .
 Output is provided via widgets. Each widgets formats some data into
 a suitable form for output. It gets the data either via its initializer,
 or from key/value pairs maintained by the master object. The values are
 set by the user. Every time a value is updated, widgets get updated
 (although the terminal is only updated every so often to give user time
 to actually read the output).
 .
 The output from ttystatus goes to the terminal (`/dev/tty`) and is
 restricted to a single line.
 ttystatus is a Python library for showing progress reporting and status
 updates on terminals, for (Unix) command line programs. Output is
 automatically adapted to the width of the terminal: truncated if it does
 not fit, and re-sized if the terminal size changes.
 .
 Output is provided via widgets. Each widgets formats some data into
 a suitable form for output. It gets the data either via its initializer,
 or from key/value pairs maintained by the master object. The values are
 set by the user. Every time a value is updated, widgets get updated
 (although the terminal is only updated every so often to give user time
 to actually read the output).
 .
 The output from ttystatus goes to the terminal (`/dev/tty`) and is
 restricted to a single line.

Bug#914027: O: vmdb2 -- creator of disk images with Debian installed

[Lars Wirzenius]

Package: wnpp
Severity: normal

I intend to orphan the vmdb2 package.

The package description is:
 vmdb2 will be a successor of vmdebootstrap. It will create disk images
 for virtual machines and real hardware, with partitioning, and a boot
 loader, and a Debian installation.

Bug#911690: vmdb2 FTBFS: tests fail

[Lars Wirzenius]

On Tue, Oct 23, 2018 at 04:51:39PM +0200, Helmut Grohne wrote:
> Source: vmdb2
> Version: 0.13.2-1
> Severity: serious
> Tags: ftbfs
> 
> vmdb2 fails to build from source in unstable for multiple architectures,
> e.g. amd64:

Noting this for whoever looks at this again: the problem is that new
versions of pylint invent new reasons to be unhappy with code that it
was happy with before. The fix is to not use pylint.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#913997: cmdtest: Should not 'provide' yarn

[Lars Wirzenius]

On Sun, Nov 18, 2018 at 12:22:57PM +0100, Olaf van der Spek wrote:
> But that's also not what Provides is for is it?

Virtual packages is one of the things Provides is for.

You want me to drop the Provides. I don't want to. The fact that some
people try to guess package names and get it wrong is not a
sufficiently convincing an argument for me.

Please don't try to bully me into giving up the yarn name in Debian.
I've had enough of this conversation.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#913997: cmdtest: Should not 'provide' yarn

[Lars Wirzenius]

On Sun, Nov 18, 2018 at 12:05:15PM +0100, Olaf van der Spek wrote:
> That might be problematic..

Yes. Flat namespaces have collision problems. The JS yarn developers
refused to pick a different name.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#913997: cmdtest: Should not 'provide' yarn

[Lars Wirzenius]

On Sun, Nov 18, 2018 at 12:14:58PM +0100, Olaf van der Spek wrote:
> Got a link to the discussion?

No.

> Still, is Provides meant to be used like this? I thought it was for
> package names, not for command names.

It's not for the command name. It's for the functionality that my yarn
program provides.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#910349: radicale: long description says "either" for more than two options

[Lars Wirzenius]

Package: radicale
Version: language mistake in long description
Severity: minor

Dear Maintainer,

the long description says:

 Some authentication schemes require either of the packages
 apache2-utils,
 python-ldap,
 python-passlib,
 python-pampy,
 courier-authdaemon or
 python-requests.

Either implies choice of two. A better way to express this would be "one of":

 Some authentication schemes require one of the following packages

Happy hacking.

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages radicale depends on:
ii  adduser  3.118
ii  lsb-base 9.20170808
ii  python   2.7.15-3
pn  python-radicale  

radicale recommends no packages.

Versions of packages radicale suggests:
ii  apache2-utils   2.4.34-1
pn  courier-authdaemon  
pn  python-dulwich  
pn  python-ldap 
pn  python-pampy
pn  python-passlib  
ii  python-requests 2.18.4-2
pn  python-sqlalchemy   

Bug#907751: RM: vmdebootstrap -- ROM; upstream discontinued, obsolete, better options exist

[Lars Wirzenius]

Package: ftp.debian.org
Severity: normal

I wrote vmdebootstrap in 2011, originally. It has been maintained by
others since then, upstream and in Debian. I am now again the upstream
and Debian maintainer since last year.

As upstream, I am ashamed of having written such a lousy program. It
has a bad architecture that makes the software inflexible, difficult
to modify, hard to test, and it is not suitable for large number of
use cases. I admit a number of people have managed to make use of it.

There are better options now: I wrote vmdb2, and there is debos. FAI
is probably also better than vmdebootstrap.

As upstream, I want vmdebootstrap gone. This means it should be
removed from Debian as well. I don't want someone else to adopt it:
it's that bad. It is my birthday and my birthday wish to be rid of
this blight. (Whenever ftpmaster has time for it is fine: I just want
to make the request today.)

I've announced my intention to ask vmdebootstrap to be removed on
debian-cloud, in NEWS.Debian in the package, on debian-devel-announce,
and in my blog, at various points this year, so I feel I've given
ample warning. unstable still has two reverse dependencies: lava and
live-wrapper.

Bug#907614: vmdb2: please provide documentation

[Lars Wirzenius]

On Thu, 2018-08-30 at 09:57 +0200, Johannes 'josch' Schauer wrote:
> Could you please provide documentation of vmdb2 in its binary package?

You're right that documentation is missing. I wrote up some:

http://code.liw.fi/vmdb2.html

This will eventaully be included in the package. Any feedback you may have
is welcome.




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

Bug#902437: xwayland: Firefox crashes Wayland on some web pages

[Lars Wirzenius]

On Tue, 2018-06-26 at 20:10 +0100, Steve McIntyre wrote:
> Confirmed here on a fresh install of sid on another X220...

This seems to work on my Yoga laptop now.



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

Bug#874421: python3-cliapp: fails to upgrade from 'stretch' - trying to overwrite /usr/share/man/man5/cliapp.5.gz

[Lars Wirzenius]

I've uploaded a version that should fix this.

On Sat, 2018-08-11 at 19:42 +, Niels Thykier wrote:
> On Thu, 05 Jul 2018 17:35:30 +0300 Lars Wirzenius  wrote:
> > On Thu, 2018-07-05 at 15:06 +0200, Andreas Beckmann wrote:
> > > But the upgrade path from stretch is not clean:
> > > 
> > >   Selecting previously unselected package python3-cliapp.
> > >   Preparing to unpack .../python3-cliapp_1.20170827-1_all.deb ...
> > >   Unpacking python3-cliapp (1.20170827-1) ...
> > >   dpkg: error processing archive 
> > > /var/cache/apt/archives/python3-cliapp_1.20170827-1_all.deb (--unpack):
> > >trying to overwrite '/usr/share/man/man5/cliapp.5.gz', which is also 
> > > in package python-cliapp 1.20160724-2
> > >   Errors were encountered while processing:
> > >/var/cache/apt/archives/python3-cliapp_1.20170827-1_all.deb
> > > 
> > > So you will need some Breaks and Replaces against the old
> > > package in stretch.
> > 
> > I see the problem now. I was confused by you calling it an upgrade problem,
> > when it isn't. It's a problem with one package containing the same file as
> > another package, and the two packages are only tangentially related.
> > 
> > It doesn't seem to me to be a particularly likely scenario, to me. A user
> > would need to change their sources.list to point from stretch to buster,
> > and then not upgrade anything else, but install python3-cliapp.
> > 
> > I'll add the Breaks and Replaces some day. Or have all of cliapp removed
> > from Debian.
> 
> Hi Lars,
> 
> Do you have an ETA on the upload fixing cliapp?  At the moment, cliapp
> is a key package and as such a potential blocker for the new Debian release.
> 
> If you are pondering a removal (per your last sentence), the following
> packages currently rely on cliapp in testing and would need to migrate
> away first:
> 
> """
> 
> Checking reverse dependencies...
> # Broken Depends:
> 
> cmdtest: cmdtest
> freedom-maker: freedom-maker
> live-wrapper: live-wrapper
> vmdb2: vmdb2
> vmdebootstrap: vmdebootstrap
> 
> # Broken Build-Depends:
> cmdtest: python-cliapp
> freedom-maker: python3-cliapp
> live-wrapper: python-cliapp
> vmdb2: python3-cliapp
> """
> 
> Thanks,
> ~Niels
> 


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

Bug#874421: python3-cliapp: fails to upgrade from 'stretch' - trying to overwrite /usr/share/man/man5/cliapp.5.gz

[Lars Wirzenius]

On Sat, 2018-08-11 at 19:42 +, Niels Thykier wrote:
> Do you have an ETA on the upload fixing cliapp?  At the moment, cliapp
> is a key package and as such a potential blocker for the new Debian release.

Key pacakge? I did not know that. What makes cliapp a key package?

I'll try to get this fixed soon. Sorry about the delay.



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

Bug#821055: Bug#821088: Secure Boot support in live-wrapper

[Lars Wirzenius]

On Fri, 2018-08-03 at 23:03 +0800, Ben Hutchings wrote:
> On Fri, 2018-08-03 at 17:50 +0300, Lars Wirzenius wrote:
> > On Fri, 2018-08-03 at 21:56 +0800, Ben Hutchings wrote:
> > > Since vmdebootstrap is no longer developed, bug #821088 will not be
> > > fixed there, but perhaps Secure Boot will be supportable using vmdb2.
> > > 
> > > If vmdb2 allows its users to specify which package(s) to install as
> > > boot loaders, then I don't think it needs to do anything specific to
> > > support Secure Boot.
> > > 
> > > If vmdb2 has specific logic for installing grub2, #821088 should be
> > > reassigned to vmdb2.
> > 
> > I'm afraid I have no idea what's needed, if anything, for vmdb2 to support
> > Secure Boot.
> 
> As I understand it, you would need to install grub-efi-$ARCH-signed and
> shim-signed, instead of grub-efi-$ARCH.

That would be easy enough to do. I'm thinking the uefi could gain a third
flavor (currently "bios" and "uefi": "uefi-secure-boot". The difference
with the "uefi" flavour would be packages installed. That would be an easy
to patch to make (but I have no idea how I'd test it).



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

Bug#821088: Secure Boot support in live-wrapper

[Lars Wirzenius]

On Fri, 2018-08-03 at 21:56 +0800, Ben Hutchings wrote:
> Since vmdebootstrap is no longer developed, bug #821088 will not be
> fixed there, but perhaps Secure Boot will be supportable using vmdb2.
> 
> If vmdb2 allows its users to specify which package(s) to install as
> boot loaders, then I don't think it needs to do anything specific to
> support Secure Boot.
> 
> If vmdb2 has specific logic for installing grub2, #821088 should be
> reassigned to vmdb2.

I'm afraid I have no idea what's needed, if anything, for vmdb2 to support
Secure Boot. I've never used SB, don't know much about it, I fear touching
the grub-related parts of vmdb2, and I'm afraid I'm unlikely to have time
or energy to learn in the next few months. I'm not even sure I have
hardware on which I could test SB. However, I'm happy to accept patches.

The grub installation in vmdb2 is done by this module:

http://git.liw.fi/vmdb2/tree/vmdb/plugins/grub_plugin.py

Kernel installation is typically done by this module:

http://git.liw.fi/vmdb2/tree/vmdb/plugins/apt_plugin.py

This is a .vmdb file for a PC with UEFI (I've not tested it recently, but
it used to work):

http://git.liw.fi/vmdb2/tree/uefi.vmdb

I'm happy to guide whoever works on this at the correct parts of vmdb2, and
to answer questions about it, but I can't promise to do much more than
that, sorry.



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

Bug#904972: vmdebootstrap going away in September, switch now

[Lars Wirzenius]

On Wed, 2018-08-01 at 13:54 +0200, Paul Gevers wrote:
> I have zero experience with either vmdebootstrap or any of its
> successors. Would you be able and willing to propose a replacement
> command for that example?

I, on the other hand, have never used autopkgtest... I see Martin linked to
the /usr/share/autopkgtest/setup-commands/setup-testbed file, but given I
entirely lack the context, it's a bit tricky to try to translate that to
something vmdb2 or debos does, blindly. I'm afraid I don't really have the
time or energy to try. I can answer specific questions, though.



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

Bug#904972: vmdebootstrap going away in September, switch now

[Lars Wirzenius]

Package: autopkgtest
Version: 5.4.2


On Sun, 2018-07-29 at 23:24 +0200, Michael Biebl wrote:
> I notice that the autopkgtest man pages still reference vmdebootstrap,
> specifically autopkgtest-virt-qemu.1:
> 
> > BUILDING IMAGES
> >Debian
> >For Debian you can use vmdebootstrap(8) to build a suitable image. 
> > E. g. for unstable:
> > 
> >   vmdebootstrap --verbose --serial-console --distribution=sid \
> >  
> > --customize=/usr/share/autopkgtest/setup-commands/setup-testbed \
> >  --user=test/test --size=100 --grub 
> > --image=autopkgtest-sid.raw
> >   qemu-img convert -O qcow2 autopkgtest-sid.raw  
> > autopkgtest-sid.img
> >   rm autopkgtest-sid.raw
> 
> 
> Could those man pages be updated to list the commands for a/the
> recommended replacement/successor of vmdebootstrap?

vmdebootstrap is going away and the manual page quoted above needs to be
updated to use a replacement, such a debos or vmdb2 or FAI.

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

Bug#874421: python3-cliapp: fails to upgrade from 'stretch' - trying to overwrite /usr/share/man/man5/cliapp.5.gz

[Lars Wirzenius]

On Thu, 2018-07-05 at 15:06 +0200, Andreas Beckmann wrote:
> But the upgrade path from stretch is not clean:
> 
>   Selecting previously unselected package python3-cliapp.
>   Preparing to unpack .../python3-cliapp_1.20170827-1_all.deb ...
>   Unpacking python3-cliapp (1.20170827-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/python3-cliapp_1.20170827-1_all.deb (--unpack):
>trying to overwrite '/usr/share/man/man5/cliapp.5.gz', which is also in 
> package python-cliapp 1.20160724-2
>   Errors were encountered while processing:
>/var/cache/apt/archives/python3-cliapp_1.20170827-1_all.deb
> 
> So you will need some Breaks and Replaces against the old
> package in stretch.

I see the problem now. I was confused by you calling it an upgrade problem,
when it isn't. It's a problem with one package containing the same file as
another package, and the two packages are only tangentially related.

It doesn't seem to me to be a particularly likely scenario, to me. A user
would need to change their sources.list to point from stretch to buster,
and then not upgrade anything else, but install python3-cliapp.

I'll add the Breaks and Replaces some day. Or have all of cliapp removed
from Debian.


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

Bug#874421: python3-cliapp: fails to upgrade from 'stretch' - trying to overwrite /usr/share/man/man5/cliapp.5.gz

[Lars Wirzenius]

On Wed, Jul 04, 2018 at 06:34:41PM +0300, Lars Wirzenius wrote:
> (Also, the advice to use Replaces+Breaks is just wrong for this
> package. The bug is that the same file is in both the python2 and
> python3 versions of the package. The correct solution is to have it in
> at most one package. I will be making that fix eventually.)

In fact, it turns out I had already done this, in 1.20170827-1. Both
python-cliapp and python3-cliapp can now be installed at the same
time. I will close the bug. Thanks for reporting the issue, I must
have failed to close the bug in the changelog when uploading.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#874421: python3-cliapp: fails to upgrade from 'stretch' - trying to overwrite /usr/share/man/man5/cliapp.5.gz

[Lars Wirzenius]

On Wed, Sep 06, 2017 at 12:31:19AM +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'stretch'.
> It installed fine in 'stretch', then the upgrade to 'buster' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

While it's true there's a bug, and I will fix that, I do not
understand why piuparts is installing python3-cliapp. That doesn't
seem like an obvious thing to do. The python3 version of the package
did not exist in stretch, and upgrading the python2 version from
stretch to buster seems to work just fine: I just tested that manually
in a chroot.

From the piuparts log I see that it is explicitly installing the
python3 version after upgrading to buster.

(Also, the advice to use Replaces+Breaks is just wrong for this
package. The bug is that the same file is in both the python2 and
python3 versions of the package. The correct solution is to have it in
at most one package. I will be making that fix eventually.)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#902437: xwayland: Firefox crashes Wayland on some web pages

[Lars Wirzenius]

Package: xwayland
Version: 2:1.20.0-2
Severity: important

Dear Maintainer,

My apologies for ruining your day with what looks like a tricky driver
bug. I hate debugging such things, myself.

I'm marking this "important", because the issue makes me not dare to
browse the web: I've had to reboot my system several times a day
lately. If you think it should be a lower severity, please downgrade.

Also, I made a wild guess at which package to report this issue
against, and I am so utterly, comically ignorant of everything in a
modern Debian desktop system that I may have guessed wrongly; please
reassign if so.

I run Debian sid on two different laptops: a Lenovo Thinkpad X220, and
a Lenovo Yoga 900. Both use an Intel graphics card or chip. For the
past week or two, the X220 has been crashing from time to time. I
thought it might be bad memory in the laptop, so I switched to the
Yoga. Then the Yoga started crashing.

After much headbanging and wailing, I've manged to find way to
reproduce the crash. I use Firefox as my web browser, and certain web
pages trigger the crash reproducibly. One such web page is here:

http://johannesbrodwall.com/2018/06/24/forget-about-clean-code-lets-embrace-compassionate-code/

What happens is that Firefox does not render that page, only updates
the page title in the window title, and then becomes unresponsive.
Menus don't react in anyway. i can't close the tab or window with
Ctrl-W, or by clicking on the window close button. After a few more
seconds, the whole desktop stops working, meaning that pressing the
capslock key no longer toggles the LED. The mouse cursor may or may
not work. If it does work, moving it to the top left corner of the
GNOME desktop makes the mouse not work anymore. Also, the desktop does
not do the "whoosh" feature of GNOME where it shows all windows on the
current virtual desktop, and the "dock" on the left side of the
screen.

The machine seems to work otherwise: I can log into it via ssh, and
run commands on the command line. I can restart gdm3 from the ssh
session, but if I log back in, it doesn't work: I get a dark grey
screen, no windows, and nothing else for about half a minute, and then
it's back to the gdm3 login screen. Logging in as a different user
seems to work.

There's nothing new in dmesg output, when the crash happens. I've run
the in-kernel memtest on the Yoga, and it resports no problems. (I've
not bothered to run it on the X220 yet. I can, if it'd be helpful to
you.)

I reconfigured gdm3 on the Yoga to start Xorg instead of Wayland, and
now the web page above works fine in Firefox. No crash.. The webpage
renders fine under Wayland using Chromium.

I am OK with this workaround, but I assume the bug should be fixed if
Wayland is to be the default in Debian. The problem is reproducible
for me. If others can reproduce it, it should be doable on any X220,
which is, or used to be, a common laptop. I will be keeping mine
in storage for a while, so that if there's a need, I can try new
package versions to see if they fix the problem.

Happy hunting.



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

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

Versions of packages xwayland depends on:
ii  libaudit1   1:2.8.3-1
ii  libbsd0 0.9.1-1
ii  libc6   2.27-3
ii  libdrm2 2.4.92-1
ii  libegl1 1.0.0+git20180308-3
ii  libepoxy0   1.4.3-1
ii  libgbm1 18.1.2-1
ii  libgcrypt20 1.8.3-1
ii  libgl1  1.0.0+git20180308-3
ii  libpixman-1-0   0.34.0-2
ii  libselinux1 2.8-1
ii  libsystemd0 239-1
ii  libwayland-client0  1.15.0-2
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:1.20.0-2

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#900403: RM: summain -- ROM; few users, upstream wants to retire it

[Lars Wirzenius]

Package: ftp.debian.org
Severity: normal

I'm the upstream and Debian maintainer of summain. It has a popcon of
25, which means it has practically no users apart from myself, and it
turns out I don't use it much myself anymore, either. I wrote it for
testing Obnam (RIP). I intend to retire it upstream, and the only
reason I haven't, is because it's in Debian.

Please remove summain from Debian. Thanks.

Bug#899155: vmdebootstrap: command failed: umount /tmp/tmp... | ERROR: /tmp/tmp.../etc/machine-id: Device or resource busy

[Lars Wirzenius]

On Sat, 2018-05-19 at 20:41 -0300, Helen Koike wrote:
> Package: vmdebootstrap
> Version: 1.11-1
> Severity: important
> 
> Dear Maintainer,
> 
> I am trying to run vmdebootstrap, but I am getting the error below:

I'm afraid vmdebootstrap is nearing its end of life. You'd be advised
to try another tool, such as vmdb2, debos, or FAI.

I am afraid I can't reproduce the problem you reported. My suggestion,
if you can switch to another tool, is to try to remove all options
that you can, and to build an image based on stretch instead of sid.
That might work.


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

Bug#895798: /usr/bin/systemd-nspawn: systemd-nspawn doesn't recognise -E, does recognise --setenv

[Lars Wirzenius]

I'm OK with this not being fixed in stretch. But I'm OK with the fix
being backported, too, or just having -E removed from --help and
manpage.

I've fixed my immediate problem by using --setenv.


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

Bug#895974: RM: python-tracing -- ROM; RoM; unused, obsolete

[Lars Wirzenius]

Package: ftp.debian.org
Severity: normal

I wrote python-tracing (as upstream) to help develop Obnam. Obnam is
gone. Nothing and nobody seems to be using python-larch, so it should
go, too.

Bug#895973: RM: python-larch -- ROM; RoM; obsolete, unused

[Lars Wirzenius]

Package: ftp.debian.org
Severity: normal

python-larch was used by Obnam. Obnam is now gone. python-larch can go
as well.

Bug#895972: RM: genbackupdata -- ROM; few, if any users; bored upstream

[Lars Wirzenius]

Package: ftp.debian.org
Severity: normal

I'm upstream developer of genbackupdata, and also the Debian package maintainer.

As upstream, I have no use for the program anymore. It's something I
wrote for developing Obnam, and Obnam is gone. I don't have any other
use for it, either. I don't know of any other people using it, either.

Thus, as Debian package maintainer, I would like it to be removed from
Debian.

Bug#895798: /usr/bin/systemd-nspawn: systemd-nspawn doesn't recognise -E, does recognise --setenv

[Lars Wirzenius]

Package: systemd-container
Version: 232-25+deb9u3
Severity: minor
File: /usr/bin/systemd-nspawn

Dear Maintainer,

I wanted to set an environment variable inside the container, when
running a command with systemd-nspawn. -E doesn't work, --setenv does.

First, to show that the container works:

$ sudo systemd-nspawn -D tmp env
Spawning container tmp on /scratch/liw/systrees/tmp.
Press ^] three times within 1s to kill container.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
container=systemd-nspawn
TERM=xterm-256color
HOME=/root
USER=root
LOGNAME=root
container_uuid=2f016265-dfad-46e0-944e-7708b7f44bef
NOTIFY_SOCKET=/run/systemd/nspawn/notify
Container tmp exited successfully.

Second, set environment variable with -E: it doesn't work.

$ sudo systemd-nspawn -D tmp -E FOO=bar env
systemd-nspawn: invalid option -- 'E'

Third, do it with --setenv, and it works:

$ sudo systemd-nspawn -D tmp --setenv FOO=bar env
Spawning container tmp on /scratch/liw/systrees/tmp.
Press ^] three times within 1s to kill container.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
container=systemd-nspawn
TERM=xterm-256color
HOME=/root
USER=root
LOGNAME=root
container_uuid=2f016265-dfad-46e0-944e-7708b7f44bef
NOTIFY_SOCKET=/run/systemd/nspawn/notify
FOO=bar
Container tmp exited successfully.

I'd be OK with removing -E from the docs, or to make it work. I can
live with writing the option as --setenv.

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages systemd-container depends on:
ii  dbus 1.10.26-0+deb9u1
ii  libacl1  2.2.52-3+b1
ii  libblkid12.29.2-1+deb9u1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-11+deb9u3
ii  libcurl3-gnutls  7.52.1-5+deb9u5
ii  libgcrypt20  1.7.6-2+deb9u2
ii  libip4tc01.6.0+snapshot20161117-6
ii  liblzma5 5.2.2-1.2+b1
ii  libseccomp2  2.3.1-2.1
ii  libselinux1  2.6-3+b3
ii  systemd  232-25+deb9u3
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages systemd-container recommends:
ii  btrfs-progs4.7.3-1
ii  btrfs-tools4.7.3-1
ii  libnss-mymachines  232-25+deb9u3

systemd-container suggests no packages.

-- no debconf information

Bug#894512: gunicorn3: can't serve large files

[Lars Wirzenius]

Package: gunicorn3
Version: 19.6.0-10+deb9u1
Severity: normal

Dear Maintainer,

I'm writing a web application that needs to server fairly large files,
in the terabyte range. I am using python3-bottle for my code, and it
works just fine. However, when I run my application with gunicorn3 it
doesn't work.

I've distilled this into a small test case. The application code,
saved as file foo.py:

import bottle

def blob(*args, **kwargs):
return bottle.static_file('blob', '.')

app = bottle.Bottle()
app.route(path='/blob', callback=blob)

This is the script that starts it, saved as file start.sh:

#!/bin/sh

set -eu

truncate -s 1G blob
gunicorn3 --bind 0.0.0.0:12765 foo:app

To test, run "sh +x start.sh", and then from another host run:

curl http://195.201.99.89:12765/blob > blob

This always fails for me: curl complains:

 curl: (18) transfer closed with 611469105 bytes remaining to read

It seems to always work over localhost. It always works when the blob
is sufficiently small, such as 1024 bytes, even between hosts.

If I don't use gunicorn, and use the Bottle built-in HTTP server, it
always works. Like this:

import bottle

def blob(*args, **kwargs):
return bottle.static_file('blob', '.')

app = bottle.Bottle()
app.route(path='/blob', callback=blob)

if __name__ == '__main__':
app.run(host='0.0.0.0', port=12765)

I ran that on one machine, and ran curl on a different host and it
worked 10 times in a row.

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages gunicorn3 depends on:
ii  python3   3.5.3-1
ii  python3-gunicorn  19.6.0-10+deb9u1

gunicorn3 recommends no packages.

Versions of packages gunicorn3 suggests:
pn  gunicorn-examples 
pn  python3-pastedeploy   
pn  python3-setproctitle  
pn  python3-tornado   

-- no debconf information

Bug#893466: bugs.debian.org: email based interaction with bugs.debian.org is slow

[Lars Wirzenius]

On Mon, 2018-03-19 at 10:54 -0700, Don Armstrong wrote:
> On Mon, 19 Mar 2018, Lars Wirzenius wrote:
> > My smarthost provider confirmed that it was not stuck on their server
> > due to greylisting. The mail was greylisted at 06:58 UTC, but went
> > through at 07:07 UTC. My local time is UTC+2. It thus took 43 minutes
> > to reach the smarthost (I don't know why), but after it got to
> > bugs.debian.org, it took about 5 hours for it be acted on.
> 
> Was that 2018-03-19 07:07 UTC? (The only mail that I have at that time
> is the mail you sent to submit@; was it some earlier time?)

It's possible that was for the bug report that opened this bug. But
it's all the info I have access to, sorry. Nothing else in my own log
file.

This is very mysterous. And that's part of why I'd prefer to not have
to use email to manipulate bugs.


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

Bug#893466: bugs.debian.org: email based interaction with bugs.debian.org is slow

[Lars Wirzenius]

On Mon, 2018-03-19 at 10:24 -0700, Don Armstrong wrote:
> Messages that are signed, have things that look like valid control
> commands, etc. are all scored very quickly and usually short-circuit
> spam assassin. The delays (if any) should be very short, on the order of
> under 3 minutes.

I used the bts command to send the mail so I'm going to assume it was
correctly constructed.

> On Mon, 19 Mar 2018, Lars Wirzenius wrote:
> Could you send me the message-id of the message which was delayed? Even
> if you had hit postgrey, and it was tempfailed, it should have only been
> delayed by about 5-10 minutes. Usually longer delays indicate that there
> is some kind of mail misconfiguration or queuing issue.

My smarthost provider confirmed that it was not stuck on their server
due to greylisting. The mail was greylisted at 06:58 UTC, but went
through at 07:07 UTC. My local time is UTC+2. It thus took 43 minutes
to reach the smarthost (I don't know why), but after it got to
bugs.debian.org, it took about 5 hours for it be acted on.

Because bts doesn't save a copy of the mail anywhere, I don't have a
copy of the sent mail, but log files indicate the Message-Id may have
been 1521440158-1404-bts-...@liw.fi. I hope that helps.

> I'm actually planning on writing such a thing, but it'll use part of the
> mail stack as a queue to process the changes with the appropriate locks
> and everything.

Cool.

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

Bug#893466: bugs.debian.org: email based interaction with bugs.debian.org is slow

[Lars Wirzenius]

The reassign request I sent at 08:15 local time finally reached
debbugs about 14:00 local time, but which time another request by
another user had just made the same change. That's almost six hours of
waiting time for me.

If I had time for it to implement one, I'd offer to write an HTTP API,
with authentication, which would interact directly with the debbugs
data structures (database) bypassing the entire mail stack. Would that
be welcome?


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

Bug#893466: bugs.debian.org: email based interaction with bugs.debian.org is slow

[Lars Wirzenius]

Package: bugs.debian.org
Severity: normal

Dear Maintainer,

bugs.debian.org runs debbugs, which is architected to require all
manipulation commands to happen via email: to close a bug, to mark a
bug fixed in some version of a package, etc. This is all good.

However, bugs.debian.org is targeted by much spam, and has quite
strict spam filtering. This causes some delays in email processing.
This is not good.

I often have the situation that when I want to manipulate a bug, I
have to wait for quite long times to receive a response from
bugs.debian.org. As an example, I have used the following command
earlier today, in order to reassign a bug to the correct package:

bts reassign 890628 cmdtest

I ran that command at 08:15 local time. It is now 08:53, and I have
not received a response. This is detrimental to my getting this task
done: use the bts command rarely enough that I want to check the
results, from the bugs.debian.org web interface, to make sure the
command worked correctly. Having to wait makes this harder. Worse, I
have no way to know if the command will ever be processed: the
bugs.debian.org spam filter may have eaten it completely. I may have
to time-out on waiting and try again.

Would it be possible to have a "fast lane" for mails that are clearly
not spam? Such as PGP signed mail or mail that has debbugs control
commands?

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Bug#845439: [Vmdebootstrap-devel] Bug#845439: [PATCH] Don???t enforce (U)EFI on arm64

[Lars Wirzenius]

On Fri, 2018-03-02 at 08:24 +0100, Michael Stapelberg wrote:
> vmdb2

Debian has no shortage of image building tools. We even had a talk at
the 2015 Debconf about this. Back then we had 11 tools. Now we have at
least two more: vmdb2 and debos. I don't have a complete list, but
it'd be nice if someone collected one on wiki.debian.org.

I am clearly biased towards vmdb2, having written it. I won't say it's
the best one, not having used most of the others, so any such claim by
me would be pure hubris, supported only by my enormous ego. I'm often
stupid, but not that stupid.


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

Bug#845439: [Vmdebootstrap-devel] Bug#845439: [PATCH] Don???t enforce (U)EFI on arm64

[Lars Wirzenius]

On Thu, 2018-03-01 at 12:39 +0100, Guido Günther wrote:
> On Sun, Aug 20, 2017 at 11:02:13PM +0200, Petter Reinholdtsen wrote:
> > Note, this is one of two vmdebootstrap issues blocking the creating
> > of Debian Stretch based images for Raspberry Pi 3 using only packages
> > in Debian, see https://wiki.debian.org/RaspberryPi3 >.
> > 
> > It would be great if it could be possible to create RPi images
> > using only vmdebootstrap and a list of options. :)
> 
> Dear maintainers, any objections to an NMU?

Yes. Please don't. Please spend that effort switching away from
vmdebootstrap.


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

Bug#890983: ITP: continuity -- A transport-agnostic, filesystem metadata manifest system

[Lars Wirzenius]

On Wed, 2018-02-21 at 18:58 +0700, Arnaud wrote:
> 
> On 02/21/2018 06:27 PM, Lars Wirzenius wrote:
> > On Wed, 2018-02-21 at 18:06 +0700, Arnaud Rebillout wrote:
> > >  This project is a staging area for experiments in providing transport
> > >  agnostic metadata storage.
> > 
> > Something like my summain program?
> 
> What is your summain program ? continuity is a library used by
> containerd and docker.

apt show summain

Yes, it's a program. Your ITP doesn't say anything about being a
library. If that's important, you should amend the package
description.

I was merely curious if continuity is doing what I've already done
some years ago for a different use case. Never mind.


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

Bug#890983: ITP: continuity -- A transport-agnostic, filesystem metadata manifest system

[Lars Wirzenius]

On Wed, 2018-02-21 at 18:06 +0700, Arnaud Rebillout wrote:
>  This project is a staging area for experiments in providing transport
>  agnostic metadata storage.

Something like my summain program?


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

Bug#890628: vmdb2: Test fail with ImportError: No module named yarnutils

[Lars Wirzenius]

On Fri, 2018-02-16 at 23:19 +0100, Benjamin Drung wrote:
> Standard error from shell command:
> Traceback (most recent call last):
>   File "/tmp/tmpWTVTHk", line 7, in 
> from yarnutils import *
> ImportError: No module named yarnutils

I seem to have failed to upload to Debian a version of cmdtest with
yarnutils. I will fix this and add a versioned dependency on it to
vmdb2. Thanks for reporting.



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

Bug#889826: ITP: vmdb2 -- create disk images with Debian installed

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius <l...@liw.fi>

* Package name: vmdb2
  Version : 0.9
  Upstream Author : Lars Wirzenius <l...@liw.fi>
* URL : https://github.com/larswirzenius/vmdb2
* License : GPL3+
  Programming Lang: Python
  Description : create disk images with Debian installed

 vmdb2 creates disk images with Debian installed. Conceptually it's
 like vmdebootstrap, except that the output is a disk image instead of
 a directory tree. Such images can be used for virtual machines, as well
 as real hardware.
 .
 vmdb2 is a successor of vmdebootstrap and intends to replace it. It's
 intentionally not backwards compatible with vmdebootstrap, however.

Bug#886772: ITP: debos -- Debian OS builder

[Lars Wirzenius]

On Thu, 2018-01-11 at 11:00 +0100, Benjamin Drung wrote:
> Both tools create a Debian OS and use a Jinja config which allows
> specifying individual steps. Can the forces be joined?

One is in Go, one in Python. There's nothing similar in the code bases.
I see no chance of "joining forces", nor much point.

Bug#886238: Please introduce official nosystemd build profile

[Lars Wirzenius]

On Thu, Jan 04, 2018 at 10:44:24PM +0300, Hleb Valoshka wrote:
> On 1/3/18, Steve Langasek  wrote:
> 
> > Moreover, defining an official nosystemd profile in Debian signals that we
> > are willing to support it, which means any maintainers who refuse such
> > patches will immediately become the targets of abuse from anti-systemd
> > zealots.
> 
> "anti-systemd zealots" Steve, when did you join LP fanclub? When
> Ubuntu decided to throw away your upstart and use systemd instead?
> Should I remind your votes in CTTE?
> 
> Please take your Ubuntu employee hat off and speak as DD.

I think you're out of line. Please stop.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#884581: RM: obnam -- ROM; upstream has retired proejct

[Lars Wirzenius]

Package: ftp.debian.org
Severity: normal

I would like to remove obnam from the Debian archive. I am the Debian
package maintainer and also the upstream developer, and as upstream I
have retired the project and will be developing it no more. I don't
want people to install it from Debian without realising it's dead
upstream. See this blog post:

https://blog.liw.fi/posts/2017/08/13/retiring_obnam/

Thank you.

Bug#878171: [Vmdebootstrap-devel] Bug#878171: vmdebootstrap: misformatted man page

[Lars Wirzenius]

> Here's how vmdebootstrap's manpage is formatted:
> 
>   1:| VMDEBOOTSTRAP(8)   System Manager's Manual  
> VMDEBOOTSTRAP(8)
>   2:| 
>   3:| " "vmdebootstrap"
>   4:| 
>   5:| NAME
>   6:|vmdebootstrap - install basic Debian system into virtual disk 
> image
>   7:| 
>   8:| PURPOSE
> 
> It seems there's an extraneous line (#3).

The whole manual page is so far away from manual page conventions, it
should be rewritten from scratch, before minor mistakes are worth
considering. However, since I'd like the whole program to die, I'm
afraid I'm not interested in fixing this formatting mistake.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#845526: [Vmdebootstrap-devel] Bug#845526: [PATCH] Allow users to specify the boot directory path

[Lars Wirzenius]

On Thu, Sep 21, 2017 at 09:37:40AM +0200, Petter Reinholdtsen wrote:
> [Lars Wirzenius]
> > I'm afraid I don't think this feature will ever land in vmdebootstrap.
> > Let me explain.
> 
> I sure understand your point of view, and unwillingness to keep working on
> vmdeboostrap when you want users to switch to vmdb2, and the problems it
> causes for testing the program, but keep in mind that the changes we talk
> about here are very small and will have great impact.

I don't agree, I'm afraid. I understand that Pi users who want Debian
would like vmdebootstrap to support building images for the Pi, but on
the other hand, for me, not having to add features to a code base that
is an unmaintainable mess is more important. I'd prefer Pi users to
help get Pi support in vmdb2 instead.

Also, given that it's my goal to get vmdebootstrap removed from Debian
sooner rather than later, I think it'd be cruel to add a Pi feature
now, and then yank it away in the next instant.

There will be no new features in vmdebootstrap.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#876078: gitano as error for unknown user is maybe in need of improvement

[Lars Wirzenius]

Package: gitano
Version: 1.0-2
Severity: normal

Dear Maintainer,

I made a typo when giving Gitano an "as" command.

17:52 ~ $ ssh g...@git.liw.fi as stever sshkey add default < steve.pub
/usr/bin/lua5.1: /usr/share/lua/5.1/gitano/usercommand.lua:182: attempt 
to index local 'utab' (a nil
value)
stack traceback:
/usr/share/lua/5.1/gitano/usercommand.lua:182: in 
function 'prep'
/usr/share/lua/5.1/gitano/admincommand.lua:106: in 
function 'prep'
/usr/share/lua/5.1/gitano/auth.lua:151: in function 
'is_authorized'
/usr/lib/gitano/bin/gitano-auth:64: in main chunk
[C]: ?

"stever" is wrong, should be "steve", but the error message seems like
it could be improved and should say something like "user 'stever' does
not exist".

-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages gitano depends on:
ii  curl7.52.1-5
ii  git 1:2.11.0-3+deb9u1
ii  gnupg   2.1.18-6
ii  lua-clod1.0.2-3
ii  lua-gall1.2-1
ii  lua-lace1.3.1-1
ii  lua-luxio [lua-luxio0]  12-1
ii  lua-luxio0  12-1
ii  lua-rex-pcre2.7.2-4
ii  lua-scrypt  1.1-3
ii  lua-supple  1.0.7-1
ii  lua-tongue  0.8-1
ii  lua5.1  5.1.5-8.1+b2

Versions of packages gitano recommends:
ii  apache2-utils  2.4.25-3+deb9u2
ii  rsync  3.1.2-1

Versions of packages gitano suggests:
ii  git-annex  6.20170101-1+b1

-- no debconf information

Bug#821088: reassign #821088 to live-wrapper?

[Lars Wirzenius]

Ack, I will not close or reassign the bug, then. Thanks.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#821088: reassign #821088 to live-wrapper?

[Lars Wirzenius]

This bug has a message from Iain that says "This bug should be
reassigned to live-wrapper once it has entered the archives".
live-wrapper is in Debian (stable onwards). Should we reassign this
bug to live-wrapper?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#873650: obnam: backup raises UnicodeDecodeError

[Lars Wirzenius]

On Mon, Sep 11, 2017 at 12:27:26PM +0200, Moritz Lennert wrote:
> > I can't reproduce this and you didn't provide enough information for
> > me to guess what it might be. What is the actual command you ran and
> > what is the config you have (obnam --dump-config)?
> 
> I can reproduce on testing, with obnam 1.22-1. I get exactly the same
> traceback. My locale is fr_BE@UTF-8.

What is the actual command you ran? Could you send me the complete log
file from one failing run of obnam, with options --log-level=debug
--trace=obnamlib ? Either to this bug report or directly to me?

Thanks.

> Could you explain why ? I have been using obnam for years and it has
> always done a good job for me.

See https://blog.liw.fi/posts/2017/08/13/retiring_obnam/

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#873650: obnam: backup raises UnicodeDecodeError

[Lars Wirzenius]

On Tue, Aug 29, 2017 at 09:10:55PM +0200, Max Hofer wrote:
> after updating to the newest version of python-cliapp which should have fixed 
> #873298
> the 'backup' command spamms the console output with following messages:
> 
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 41: 
> ordinal not in range(128)
> Logged from file backup_plugin.py, line 397
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit
> msg = self.format(record)
>   File "/usr/lib/python2.7/logging/__init__.py", line 734, in format
> return fmt.format(record)
>   File "/usr/lib/python2.7/logging/__init__.py", line 476, in format
> raise e

I can't reproduce this and you didn't provide enough information for
me to guess what it might be. What is the actual command you ran and
what is the config you have (obnam --dump-config)?

Also, you should switch to another backup program. Sooner rather than
later would be good.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#872819: ikiwiki: !table doesn't handle [foo][] links

[Lars Wirzenius]

Package: ikiwiki
Version: 3.20170111
Severity: normal

Dear Maintainer,

I create the following files.

8< index.mdwn 
# Table link bug example

The table below should have [link][] in the elements,
but only [foo](http://foo.example.com) works.

[link]: http://link.example.com

[[!table data="""
first | second
[link][] | link?
[foo](http://foo.example.com) | foo?
[[bar|bar]] | bar?
"""]]
8<

8< bar.mdwn 
This exists
8<

And the following ikiwiki.setup file:

8<
# IkiWiki::Setup::Yaml - YAML formatted setup file
wikiname: test
url: "http://wiki.example.com;
srcdir: /home/liw/tmp/ikwiki/src
destdir: /home/liw/tmp/ikwiki/html
add_plugins:
- goodstuff
disable_plugins:
- recentchanges
- favicon
8<

Then I run the following commandS:

rm -rf html src/.ikiwiki
mkdir html
ikiwiki --setup ikiwiki.setup

The result has (snipping all but the genarated table):

Table link bug example

The table below should have http://link.example.com;>link 
in the elements,
but only http://foo.example.com;>foo works.




first
 second




[link][]
 link?


http://foo.example.com;>foo
 foo?


bar
 bar?




Note how [foo][] got exanded in the text before the table, but not in
the actual table. This surprises me and I consider it a bug.



-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ikiwiki depends on:
ii  libhtml-parser-perl 3.72-3
ii  libhtml-scrubber-perl   0.15-1
ii  libhtml-template-perl   2.95-2
ii  libjson-perl2.90-1
ii  libtext-markdown-discount-perl  0.11-1+b3
ii  liburi-perl 1.71-1
ii  libyaml-libyaml-perl0.63-2
ii  perl5.24.1-3+deb9u1

Versions of packages ikiwiki recommends:
ii  gcc [c-compiler] 4:6.3.0-4
ii  gcc-5 [c-compiler]   5.4.1-4
ii  gcc-6 [c-compiler]   6.3.0-18
ii  git [git-core]   1:2.11.0-3+deb9u1
ii  libauthen-passphrase-perl0.008-2
ii  libc6-dev [libc-dev] 2.24-11+deb9u1
ii  libcgi-formbuilder-perl  3.10-1
ii  libcgi-pm-perl   4.35-1
ii  libcgi-session-perl  4.48-3
ii  libcrypt-ssleay-perl 0.73.04-2
ii  libgravatar-url-perl 1.07-1
ii  liblwpx-paranoidagent-perl   1.12-1
ii  libmail-sendmail-perl0.79.16-2
ii  libnet-openid-consumer-perl  1.18-1
ii  librpc-xml-perl  0.80-1
ii  libterm-readline-gnu-perl1.35-1
ii  libtimedate-perl 2.3000-2
ii  libxml-simple-perl   2.22-1
ii  subversion   1.9.5-1+deb9u1

Versions of packages ikiwiki suggests:
ii  dvipng 1.14-2+b3
ii  file   1:5.30-1
ii  gettext0.19.8.1-2
ii  ghostscript9.20~dfsg-3.2
ii  graphviz   2.38.0-17
ii  libfile-mimeinfo-perl  0.27-1
ii  libhighlight-perl  3.18-3+b5
ii  libhtml-tree-perl  5.03-2
ii  libimage-magick-perl [perlmagick]  8:6.9.7.4+dfsg-11+deb9u1
ii  liblocale-gettext-perl 1.07-3+b1
ii  libmagickcore-6.q16-3-extra [libmagickcore-extra]  8:6.9.7.4+dfsg-11+deb9u1
ii  libmailtools-perl  2.18-1
pn  libnet-amazon-s3-perl  
pn  libnet-inet6glue-perl  
pn  libsearch-xapian-perl  
pn  libsort-naturally-perl 
pn  libsparkline-php   
ii  libtext-csv-perl   1.33-2
pn  libtext-multimarkdown-perl 
pn  libtext-textile-perl   
pn  libtext-typography-perl
pn  libtext-wikicreole-perl
pn  libtext-wikiformat-perl
pn  libxml-feed-perl   
ii  libxml-writer-perl 0.625-1
pn  po4a   
pn  polygen
ii  python 

Bug#872810: /usr/bin/namecheck: namecheck checks obsolete sites, interprets error as "reserved"

[Lars Wirzenius]

Package: devscripts
Version: 2.17.6+deb9u1
Severity: normal
File: /usr/bin/namecheck

Dear Maintainer,

I wanted to check if the name "salami" is in use.

$ namecheck salami
Testing salami.tuxfamily.org - Available
Testingalioth.debian.org - Available
Testingfreshmeat.netERROR fetching 
http://freshmeat.net/projects/salami  - 500 Status read failed: Connection 
reset by peer
Testinglaunchpad.net - Available
Testing savannah.gnu.org - Available
Testing  sourceforge.netERROR fetching 
http://sourceforge.net/projects/salami- 500 Status read failed: Connection 
reset by peer
Testingwww.ohloh.net - Available
Testing  gna.orgERROR fetching https://gna.org/projects/salami  
 - 500 Can't connect to gna.org:443
Testing  code.google.com - In use
Aborting - name 'salami' is currently used.
$ 

The freshmeat, sourceforge, and gna sites seems to be gone or
permanently down. Possily namecheck should stop checking them.

Also, if a site reports an error that doesn't mean the name is in use.
At best namecheck should report that it doesn't know if a name is in
use if one of the sites reports an error.

Thanks and happy hacking.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=44E17740B8611E9C
DSCVERIFY_KEYRINGS=/home/liw/.gnupg/pubring.gpg

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.18.24
ii  libc6 2.24-11+deb9u1
ii  libfile-homedir-perl  1.00-1
ii  perl  5.24.1-3+deb9u1
ii  python3   3.5.3-1

Versions of packages devscripts recommends:
ii  apt 1.4.7
ii  at  3.1.20-3
ii  curl7.52.1-5
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.05.28
ii  dput0.12.1
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-3.1
ii  file1:5.30-1
ii  gnupg   2.1.18-6
ii  gnupg2  2.1.18-6
ii  libdistro-info-perl 0.14
ii  libdpkg-perl1.18.24
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.29-1
ii  lintian 2.5.50.4
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
ii  python3-magic   1:5.30-1
ii  sensible-utils  0.0.9
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.18-5
ii  xz-utils5.2.2-1.2+b1

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.3
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.0.5+dfsg1-6+deb9u1
ii  gpgv 2.1.18-6
ii  how-can-i-help   15
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.1.1-1
pn  mozilla-devscripts   
ii  mutt 1.7.2-1
ii  openssh-client [ssh-client]  1:7.4p1-10+deb9u1
pn  piuparts 
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-34

-- no debconf information

Bug#871590: printer-driver-ptouch: QL-550 doesn't print on 62 mm labels

[Lars Wirzenius]

Package: printer-driver-ptouch
Version: 1.4.2-2+b1
Severity: normal

Dear Maintainer,

I have a Brother P-touch QL-550 label printer, and it works just fine
when printing to 12 mm wide labels (from a continuous roll). However,
if I print on 62 mm wide labels (also from continuous roll), the
printer just blinks its LED at 1-2 Hertz.

That's with the 1.4.2-2+b1 version of the package, from stretch.

If I downgrade the package to 1.3-8, printing works for 62 mm wide
labels, and also 12 mm labels. With 1.4-1 printing doesn't work, so it
looks like 1.3-8 from snapshot.debian.net is the newest version that
works.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages printer-driver-ptouch depends on:
ii  ghostscript9.20~dfsg-3.2
ii  libc6  2.24-11+deb9u1
ii  libcups2   2.2.1-8
ii  libcupsimage2  2.2.1-8
ii  python33.5.3-1
ii  xz-utils   5.2.2-1.2+b1

printer-driver-ptouch recommends no packages.

printer-driver-ptouch suggests no packages.

-- no debconf information

Bug#845526: [Vmdebootstrap-devel] Bug#845526: [PATCH] Allow users to specify the boot directory path

[Lars Wirzenius]

Hi,

how essential is this? Could it be implemented with a sufficiently
complicated customize script?

I ask because I would like to avoid adding any further features into
vmdebootstrap, which is quite a complicated program already. Instead
all my development work goes into vmdb2 (not yet in Debian), which is
a much simpler program, thanks to a completely different architecture,
and where it would be more feasible to add all sorts of
customizability.

I would like to make vmdebootstrap go into deep maintenance mode,
where I only change things to fix problems that affect official Debian
ISO image building, or when other vmdebootstrap users can't otherwise
build their images and can't switch to vmdb2 either.

On Sun, Jun 18, 2017 at 11:08:07PM +0200, martin schitter wrote:
> the suggested vmdebootstrap patch by Michael doesn't set the customized boot
> mount point in /etc/fstab of the generated images.
> 
> i also think, the '--bootdirfmt' and its unusual "%s..." syntax doesn't look
> very handy. therefore i used a simple '--bootdir' option in my fix.
> 
> working patch attached.

> diff --git a/bin/vmdebootstrap b/bin/vmdebootstrap
> index d9a697d..e4e7e60 100755
> --- a/bin/vmdebootstrap
> +++ b/bin/vmdebootstrap
> @@ -78,6 +78,7 @@ class VmDebootstrap(cliapp.Application):  # pylint: 
> disable=too-many-public-meth
>  self.settings.string(['bootflag'], 'specify flag to set for /boot/', 
> default='')
>  self.settings.bytesize(['bootoffset'], 'Space to leave at start of 
> the '
> 'image for bootloader', default='0')
> +self.settings.string(['bootdir'], 'Mount point of /boot partition', 
> default='/boot/')
>  self.settings.boolean(['use-uefi'], 'Setup image for UEFI boot', 
> default=False)
>  self.settings.bytesize(['esp-size'], 'Size of EFI System Partition - 
> '
> 'requires use-uefi', default='5mib')
> @@ -248,9 +249,9 @@ class VmDebootstrap(cliapp.Application):  # pylint: 
> disable=too-many-public-meth
>  elif bootdev:
>  boottype = self.settings['boottype']
>  filesystem.mkfs(bootdev, fstype=boottype)
> -self.bootdir = '%s/%s' % (rootdir, 'boot/')
> +self.bootdir = '%s/%s' % (rootdir, self.settings['bootdir'])
>  filesystem.devices['bootdir'] = self.bootdir
> -os.mkdir(self.bootdir)
> +os.makedirs(self.bootdir)
>  self.mount(bootdev, self.bootdir)
>  
>  # set user-specified flags, e.g. lba
> diff --git a/doc/overview.rst b/doc/overview.rst
> index 43693f2..da0f236 100644
> --- a/doc/overview.rst
> +++ b/doc/overview.rst
> @@ -107,6 +107,8 @@ Options
>   --boottype=FSTYPE Filesystem to use for the /boot partition. (default 
> ext2)
>   --bootflag=FLAG   Flag to set on the first partition. (default none)
>   --bootoffset=SIZE Space to leave at start of the image for bootloader
> + --bootdir=PATHMount point of /boot partition.
> +   Default is ``/boot/``. 
>   --roottype=FSTYPE Filesystem to use for the / (root) partition. 
> (default ext4)
>   --part-type=PART-TYPE
> Partition type to use for this image. (default msdos)
> diff --git a/vmdebootstrap/filesystem.py b/vmdebootstrap/filesystem.py
> index b911c05..d9241c9 100644
> --- a/vmdebootstrap/filesystem.py
> +++ b/vmdebootstrap/filesystem.py
> @@ -171,8 +171,8 @@ class Filesystem(Base):
>  fstab.write('%s / %s %s 0 1\n' %
>  (rootdevstr, roottype, 
> self.get_mount_flags(roottype)))
>  if bootdevstr:
> -fstab.write('%s /boot %s %s 0 2\n' %
> -(bootdevstr, boottype, 
> self.get_mount_flags(boottype)))
> +fstab.write('%s %s %s %s 0 2\n' %
> +(bootdevstr, self.settings['bootdir'], boottype, 
> self.get_mount_flags(boottype)))
>  if self.settings['swap'] > 0:
>  fstab.write("/dev/sda3 swap swap defaults 0 0\n")
>  elif self.settings['swap'] > 0:

> ___
> Vmdebootstrap-devel mailing list
> vmdebootstrap-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/vmdebootstrap-devel


-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#852330: dia: dia --export to svg adds junk to end

[Lars Wirzenius]

On Fri, Jul 14, 2017 at 10:13:37PM +0200, Tomas Pospisek wrote:
> The line "auth.dia --> /dev/stdout" goes to STDERR though. So if you do:
> 
>   dia --export=/dev/stdout --filter=svg auth.dia > outfile.svg
> 
> then everything works as it should.

It seems that's not what happened when I filed the bug, however. But
if it works now, good.

> * some info about the processing of the file for the user goes to STDERR

This bit is, however, if not a bug at least a wart in the program.
stderr is not a place for random info to be shown to the user, but for
error messages. The proper place for "foo.dia -> output" messagges is
either /dev/null (unless a verbose mode is requested), /dev/tty (for
interactive users), or a log file. In my opinion.

> Can you agree with me? Can we close this bug?

You can close the bug.

Bug#867141: [Vmdebootstrap-devel] Bug#867141: Cannot build Debian Hurd Live

[Lars Wirzenius]

On Tue, Jul 04, 2017 at 08:50:43AM +0200, Narcis Garcia wrote:
>   E: Couldn't find these debs: linux-image-hurd-i386 acpid

vmdebootstrap seems to use the following method for picking the kernel
package name:

def kernel_package(self):
packages = []
if self.settings['no-kernel'] or self.settings['kernel-package']:
return packages
if self.settings['arch'] == 'i386':
# wheezy (which became oldstable on 04/25/2015) used '486'
if self.was_oldstable(datetime.date(2015, 4, 26)):
kernel_arch = '486'
else:
kernel_arch = '586'
elif self.settings['arch'] == 'armhf':
kernel_arch = 'armmp'
elif self.settings['arch'] == 'ppc64el':
kernel_arch = 'powerpc64le'
else:
kernel_arch = self.settings['arch']
packages.append('linux-image-%s' % kernel_arch)
return packages

If you give vmdebootstrap the --kernel-package to set the kernel
package for Hurd (whatever that is), does that work? I don't know how
to get live-wrapper to do that, never having tried it.

You may also want to use the --no-acpid option.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#866374: nm.debian.org: rendereed page starts with ...

[Lars Wirzenius]

Package: nm.debian.org
Severity: normal

Dear Maintainer,

When visiting https://nm.debian.org/process/206 the rendered
page starts with this text:

https://nm.debian.org/static/js/jquery-1.10.2.min.js";> https://nm.debian.org/static/js/nm.js";>

I don't know if that affects the functionality of the page, but it's ugly.

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#863404: pass: returns with 0 if a key it is meant to encrypt to is expired

[Lars Wirzenius]

Package: pass
Version: 1.6.5-6
Severity: important

Dear Maintainer,

I have a pass key repository shared with co-workers. A co-worker's key
expired today, and this happened:

$ tar -C gpg -cf - . | base64 | pass insert -m infra/ci-gnupg.tar.base64
tar: ./S.gpg-agent.extra: socket ignored
tar: ./S.gpg-agent: socket ignored
tar: ./S.gpg-agent.ssh: socket ignored
tar: ./S.gpg-agent.browser: socket ignored
Enter contents of infra/ci-gnupg.tar.base64 and press Ctrl+D when finished:

gpg: removing stale lockfile (created by 12012)
gpg: E8C1BC59AB5040EC08413CC161726E19C6D5BA72: skipped: Unusable public key
gpg: [stdin]: encryption failed: Unusable public key

The pass exit code was 0. However, because gpg refused to encrypt to
the expired key, the inserted secret wasn't actually inserted. A
non-zero exit code would make this situation be much easier to notice.
A zero exit code makes pass fail its primary job for me.

Suggestion for fix: If gpg fails, pass should exit with a non-zero
exit code.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64
 (x86_64)

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

Versions of packages pass depends on:
ii  gnupg   2.1.18-6
ii  gnupg2  2.1.18-6
ii  pwgen   2.07-1.1+b1
ii  tree1.7.0-5

Versions of packages pass recommends:
ii  git 1:2.11.0-3
ii  gnupg2  2.1.18-6
ii  xclip   0.12+svn84-4+b1

Versions of packages pass suggests:
ii  libxml-simple-perl  2.22-1
ii  perl5.24.1-2
ii  ruby1:2.3.3

-- no debconf information

Bug#860453: ITP: sparseutils -- interact with sparse files

[Lars Wirzenius]

On Mon, Apr 17, 2017 at 09:51:24AM +0200, Eduard Bloch wrote:
> >   Description : interact with sparse files
> 
> This doesn't align with the extended description. Sounds more like
> "automated creation and inspection of sparse files".

I'll tweak the short the description. I disagree that mine doesn't
align with the long one, though.

> >  This package contains the utilities sparsemap and mksparse. Sparsemap
> >  lists the areas of a file that are holes and data, and mksparse creates
> >  a new file with holes and data.
> 
> It would be nice to have such functionality directly in fallocate(1)
> rather than having to install python 3 just for that.

Feel free to get fallocate upstream to change it to work like mksparse
does, and to write a tool like sparsemap.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#860453: ITP: sparseutils -- interact with sparse files

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius <l...@liw.fi>

* Package name: sparseutils
  Version : 0.0.1
  Upstream Author : Richard Ipsum <richardip...@fastmail.co.uk>
* URL : https://pypi.python.org/pypi/sparseutils/
* License : GPL3+
  Programming Lang: Python3
  Description : interact with sparse files

 This package contains the utilities sparsemap and mksparse. Sparsemap
 lists the areas of a file that are holes and data, and mksparse creates
 a new file with holes and data.


The test suite for Obnam, my package, will be using this in the future.

Bug#860408: pbuilder: leaves a 0-byte tgz file if creation fails

[Lars Wirzenius]

Package: pbuilder
Version: 0.228.6
Severity: normal

When I run pbuilder to create a base tgz file, and there's an error
during the process, I'm left with a 0-byte output file. It would be
better to not create the output file unless debootstrap finished
correctly.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  debootstrap1.0.89
ii  dpkg-dev   1.18.23
ii  initscripts2.88dsf-59.9
ii  util-linux 2.29.2-1
ii  wget   1.18-5

Versions of packages pbuilder recommends:
ii  devscripts  2.17.5
ii  eatmydata   105-5
ii  fakeroot1.21-3.1
ii  iproute24.9.0-1
ii  net-tools   1.60+git20161116.90da8a0-1
ii  sudo1.8.19p1-1

Versions of packages pbuilder suggests:
pn  cowdancer   
ii  gdebi-core  0.9.5.7+nmu1

-- debconf information:
  pbuilder/rewrite: false
  pbuilder/mirrorsite: http://ftp.fi.debian.org/debian
  pbuilder/nomirror:

Bug#860407: pbuilder: warns about not having pbuilderrc

[Lars Wirzenius]

Package: pbuilder
Version: 0.228.6
Severity: minor

Dear Maintainer,

When I run pbuilder on my wheezy build machine, it warns that I don't
have /root/.pbuilderrc. This is correct, I don't. However, I don't
think it should be a warning, at most an information message, and my
preference would be to not say anything (except perhaps in a nitpick
mode).

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  debootstrap1.0.89
ii  dpkg-dev   1.18.23
ii  initscripts2.88dsf-59.9
ii  util-linux 2.29.2-1
ii  wget   1.18-5

Versions of packages pbuilder recommends:
ii  devscripts  2.17.5
ii  eatmydata   105-5
ii  fakeroot1.21-3.1
ii  iproute24.9.0-1
ii  net-tools   1.60+git20161116.90da8a0-1
ii  sudo1.8.19p1-1

Versions of packages pbuilder suggests:
pn  cowdancer   
ii  gdebi-core  0.9.5.7+nmu1

-- debconf information:
  pbuilder/nomirror:
  pbuilder/rewrite: false
  pbuilder/mirrorsite: http://ftp.fi.debian.org/debian

Bug#858247: python-openstackclient: "openstack --help" fails unless OS_* env vars are set for API access

[Lars Wirzenius]

Package: python-openstackclient
Version: 3.2.1-1
Severity: normal

Dear Maintainer,

My /usr/bin/openstack is provided by python-openstackclient, via an
alternative. The command has no manual page. When trying to get some
help, I run it with --help. This is the output:

$ openstack --help
Auth plugin requires parameters which were not given: auth_url
$

If I set the various OS_* environment variables, it works. I think
it's surprising that you need to set up access to a server to get
--help to work.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python-openstackclient depends on:
ii  python-babel   2.3.4+dfsg.1-2
ii  python-cinderclient1:1.9.0-3
ii  python-cliff   1.15.0-5
ii  python-crypto  2.6.1-7
ii  python-glanceclient1:2.5.0-3
ii  python-keyring 10.1-1
ii  python-keystoneauth1   2.12.1-2
ii  python-keystoneclient  1:3.2.0-4
ii  python-neutronclient   1:6.0.0-2
ii  python-novaclient  2:6.0.0-2
ii  python-openstacksdk0.9.5-2
ii  python-os-client-config1.16.0-1
ii  python-osc-lib 1.1.0-2
ii  python-oslo.config 1:3.17.0-3
ii  python-oslo.i18n   3.9.0-3
ii  python-oslo.serialization  2.13.0-2
ii  python-oslo.utils  3.16.0-2
ii  python-pbr 1.10.0-1
ii  python-requests2.12.4-1
ii  python-six 1.10.0-3
ii  python-stevedore   1.17.1-2
pn  python2.7:any  
pn  python:any 

python-openstackclient recommends no packages.

python-openstackclient suggests no packages.

-- no debconf information

Bug#829076: general: Random freezes but the mouse can still move

[Lars Wirzenius]

(Reply-to points at me, I doubt there's any need for much discussion.
If you disagree, tweak you headers accodingly.)

On Sun, Feb 26, 2017 at 02:06:17PM +0100, Geert Stappers wrote:
> On Sun, Feb 26, 2017 at 01:00:03PM +, Debian Bug Tracking System wrote:
> > From: Lee Garrett 
> > To: 829076-cl...@bugs.debian.org
> > Subject: close
> > User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.23)
> >  Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
> > 
> > close
> 
> Why?

Timeline of this bug:

* John Muir reports problem on his computer (GUI freeze, details
  irrelevant right now).
* Abou Al Montacir responds and tries to help.
* Lee Garrett responds as well, suggesting one of the Debian support
  channels.
* John Cuffs tells Lee to "shut the fuck up", and quotes a spam that
  isn't visible (anymore?) in the bug log.
* Lee closes ticket.

To me this looks like behaves like an unpleasant person, and Lee
possibly confusing the two Johns with each other and closing the
ticket under the assumption that John Muir doesn't want to be helped.

In any case, I think Lee's first response is correct: the BTS isn't
the best place to diagnose the problem. If a diagnosis is done and a
reasonble culprit is found, an more realistically actionable bug
report should be opened, and until then, closing this one seems OK,
even disregarding John Cuffs's attempt to moderate the discussion.

While I have your attention: it's February 26, and Sunday, so you
should make a backup today and then verify that it works.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#854227: unblock: python-cliapp/1.20160724-2

[Lars Wirzenius]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-cliapp

1.20160724-1 fails to build from source because after it was
originally uploaded, pylint was upgraded, and now has new checks,
which fail the build. In 1.20160724-2 I have disabled build-time
tests. I decided to disable the tests rather than fixing the thing
that pylint now complains about, because I think it's a smaller, safer
change than making code changes at this stage of the release cycle.

Source debdiff:

diff -Nru python-cliapp-1.20160724/debian/changelog 
python-cliapp-1.20160724/debian/changelog
--- python-cliapp-1.20160724/debian/changelog   2016-07-24 20:54:18.0 
+0200
+++ python-cliapp-1.20160724/debian/changelog   2017-02-05 09:19:14.0 
+0100
@@ -1,3 +1,17 @@
+python-cliapp (1.20160724-2) unstable; urgency=medium
+
+  * Fix "FTBFS: Test failures" by disabling build-time checks
+(Closes: #852882)
+  - when -1 was uploaded, the tests passed, but pylint is
+now a newer version with new checks
+  - Debian is in a freeze, this is the minimal change to work
+around the bug; the tests have passed in previuos uploads,
+with an older pylint, so disabling them should be sufficiently
+safe and less risky than hacking up code at the last second of
+a release cycle
+
+ -- Lars Wirzenius <l...@liw.fi>  Sun, 05 Feb 2017 09:19:14 +0100
+
 python-cliapp (1.20160724-1) unstable; urgency=medium
 
   * Change debian/rules to run automated tests during build.
diff -Nru python-cliapp-1.20160724/debian/rules 
python-cliapp-1.20160724/debian/rules
--- python-cliapp-1.20160724/debian/rules   2016-07-24 20:41:27.0 
+0200
+++ python-cliapp-1.20160724/debian/rules   2017-02-05 09:19:14.0 
+0100
@@ -7,12 +7,6 @@
$(MAKE)
dh_auto_build --with=python2 --buildsystem=python_distutils
 
-override_dh_auto_test:
-   $(MAKE) clean check
-   # RE-build
-   $(MAKE)
-   dh_auto_build --with=python2 --buildsystem=python_distutils
-
 override_dh_auto_clean:
$(MAKE) clean
dh_auto_clean --with=python2 --buildsystem=python_distutils
[PREVIOUS COMMAND EXIT: 1]
~/.../cliapp $ 


unblock python-cliapp/1.20160724-2

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#852882: python-cliapp: FTBFS: Test failures

[Lars Wirzenius]

Thanks for the bug report, and for doing rebuild tests.

On Sat, Jan 28, 2017 at 09:27:24AM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > fi
> > * Module cliapp.app
> > C:346,30: Consider iterating the dictionary directly instead of calling 
> > .keys() (consider-iterating-dictionary)
> > C:364,30: Consider iterating the dictionary directly instead of calling 
> > .keys() (consider-iterating-dictionary)

These are errors from pylint. So what's happened is that pylint got
updated after my previous upload. When I uploaded the current version,
the version of pylint at that time didn't have these checks, and so
everything went fine. With the newer pylint, a rebuild fails.

I'll upload a new verison of python-cliapp once I'm back home from
travels, which will fix the code. At this stage of the Debian release,
I don't think pylint will change again, so I'll allow the tests to
still run pylint.

Or someone else can do an NMU to disable the pylint test, if they want
to fix the bug faster. I'm on the LowThresholdNmu list so you can just
do the upload.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#852330: dia: dia --export to svg adds junk to end

[Lars Wirzenius]

Package: dia
Version: 0.97.3+git20160930-5
Severity: normal

Dear Maintainer,

I have a .dia file that I need to convert to SVG which I do from the
command line:

dia --export=/dev/stdout --filter=svg auth.dia

This adds the following line to the end of the output:

auth.dia --> /dev/stdout

This breaks using the output in many SVG-capable programs. I can
easily filter it out but it'd be nice to not have to.

Thanks.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages dia depends on:
ii  dia-common   0.97.3+git20160930-5
ii  libart-2.0-2 2.3.21-2
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.3-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  libpng16-16  1.6.26-6
ii  libpython2.7 2.7.13-1
ii  libxml2  2.9.4+dfsg1-2.1
ii  libxslt1.1   1.1.29-2
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages dia recommends:
ii  dia-shapes   0.6.0-3
ii  gsfonts-x11  0.24

dia suggests no packages.

-- no debconf information

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

[Lars Wirzenius]

On Thu, Jan 05, 2017 at 01:05:09PM +0530, Abhishek Lolage wrote:
> * URL : https://github.com/sindresorhus/plur
>   Description : Pluralize a word

The package description should make it clear this code only works for
English.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#805154: [Vmdebootstrap-devel] Bug#805154: Please reconsider tagging this bug wontfix

[Lars Wirzenius]

On Fri, Oct 21, 2016 at 03:18:40PM -0400, Sam Hartman wrote:
> 
> 
> I do understand that the proposed fix is inadequate.  You'd need to not
> include nobarrier on the esp partition.
> 
> However, the performance of vmdebootstrap is really fairly bad compared
> to other image creation solutions I've used in the past, and it does
> significantly impact the test/development cycle.
> If you don't want to develop a patch fine, but perhaps help or no tags
> would be more appropriate than wontfix.

On the whole, I agree that is important to make vmdebootstrap faster.
I don't yet know enough about the nobarrier mount option to say yea or
nay on it specifically, but my plan for rewritint vmdb will make it
feasible to do in the future without complicating vmdb.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#845409: ITP: node-strip-eof -- Strip the End-Of-File (EOF) character from a string/buffer

[Lars Wirzenius]

On Wed, Nov 23, 2016 at 11:28:54AM +0530, Pirate Praveen wrote:
> * URL : https://github.com/sindresorhus/strip-eof
>   Description : Strip the End-Of-File (EOF) character from a
> string/buffer

Could you fix the  Debian package description to be correct? There are
no EOF characters, and in any case the code actually strips CR and LF
characters (i.e., it strips them away, if the string ends with LR, CR,
or CRLR, but not more if there's more of those characters). Upstream's
description of what the code does isn't accurate.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 06:04:26PM +0100, Paolo Greppi wrote:
> On 03/11/2016 17:54, Lars Wirzenius wrote:
> > I see the following possibilities now:
> > 
> > a) You rename the yarn package manager in Debian (both package and
> >binary). I keep the yarn name for my program and package.
> > 
> > b) We both rename. Nobody uses the name yarn, either as package or as
> >a binary name.
> 
> I'd go for a).
> 
> It is clear that this package will install /usr/bin/yarnpkg binary only.
> The package itself should be yarnpkg or node-yarnpkg.

Cool. Thank you.

> Should I just retitle this bug ?

Retitling the bug report is probably a convenience to those reading it
later, but the important bit is that the package and binary names are
correct when you upload.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 04:17:37PM +0100, Paolo Greppi wrote:
> On 03/11/2016 15:28, Lars Wirzenius wrote:
> > The JS package manager called yarn is quite new. It wouldn't be
> > unreasonable to suggest to them to rename it to avoid a naming
> > conflict, in my opinion.
> 
> Fine, I have opened an "Issue" in the github tracker, let's see if this
> is received constructively:
> https://github.com/yarnpkg/yarn/issues/1656

Upstream seems to not want to change the name. They closed that bug
with the following explanation:

# We don't have any intentions of using the yarnpkg binary as the sole
# one. There's prior art here with Node.js using node instead of
# nodejs even though there's already a Debian package called node. See
# #673 for more information.

The upstream 673 bug doesn't actually contain an explanation, though.

I see the following possibilities now:

a) You rename the yarn package manager in Debian (both package and
   binary). I keep the yarn name for my program and package.

b) We both rename. Nobody uses the name yarn, either as package or as
   a binary name.

I'm not happy if I have to give up the yarn name. I find it unfair
that I have to rename just because some new upstream decides to use I
name I've already been using for years, and refuses to reconsider
their use of the name.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 04:17:37PM +0100, Paolo Greppi wrote:
> Fine, I have opened an "Issue" in the github tracker, let's see if this
> is received constructively:
> https://github.com/yarnpkg/yarn/issues/1656

Thank you.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 02:02:31PM +, Ian Jackson wrote:
> I searched github for `yarn'.

You don't find my software on github. I do not want to rely on
non-free services like github.

> There are lots of hits for other
> programs, including:
>   - a dialogue editor (for games, I think)
>   - a VM
>   - something to do with mongodb and .net
>   - the Hadoop thing
>   - a blogging application
>   - a wrapper for ssh.
> and lots more.

How many of those were public in mid-2013?

> Obviously "yarn" is a really bad name.  Someone who picks a name like
> that must obviously expect that they can't necessarily have that name
> in every namespace.

When I chose the name in 2013, I didn't other software that was called
yarn.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 01:32:14PM +0100, Paolo Greppi wrote:
> cmdtest provides yarn since this commit:
> http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cmdtest/commit/?id=859bb5ba9631df883dd7b074ff649ea2ca76e1ad

Yep, in 0.27-1, uploaded Sep 21 this year. cmdtest has included the
yarn program since June, 2013. I added that because people kept having
trouble finding the package when they want to install (my) yarn.

> A package search for yarn currently returns no match.
> https://packages.debian.org/search?keywords=yarn

I assume that's because it's a Provides, and not an actual package
name. I haven't created a separate yarn package to avoid making the
FTP masters from processing another package in NEW.

> The real issue here is that both cmdtest and the proposed package
> install a yarn binary.

I don't think that's the only reason, I think the package name
conflict is also an issue. But you're right that the binary name
conflict also needs be resolved.

> 1. as you suggest, renaming this package and the binary it installs to
> yarnpkg

Yes, please. :)

> 2. keeping the package name yarn but renaming the binary to yarnpkg

I don't see why you'd call the package yarn. There would be a conflict
with the yarn name that cmdtest provides.

> 3. renaming the executable yarn in cmdtest to yarn-something-else, and
> have cmdtest provide yarn-something-else

It's been called yarn in the cmdtest package for years. I'd prefer to
not rename it, thanks. It's a name that's dear to me, has some
pleasant memories associated with it, and that I've gotten used to.

The JS package manager called yarn is quite new. It wouldn't be
unreasonable to suggest to them to rename it to avoid a naming
conflict, in my opinion.

> 4. ignoring the conflict and setting the Conflict flags in both packages
> (https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts)

I don't think this is acceptable at all. There's no reason for these
two packages to conflict. There's no reason why we'd prevent someone
from installing both at the same time.

> For 3, there could be a cmdtest-legacy package for those who do not use
> yarn/yarnpkg and like to invoke the yarn binary in cmdtest as yarn
> rather than yarn-something-else.

Oh dear, please no. This is just insane. A whole bunch of work with no
actual benefit. It just makes things more complicated for everyone.

> At the moment we are confusing the newbies who come to Debian for
> JavaScript development.

I understand. I admit that I don't much care. Having to learn that
it's called yarnpkg in Debian, yarn on MacOS, and maybe something else
somewhere else seems not too big a deal to me. It's a very minor
difference compared to the churn in the Javascript ecosystem.

> It would be easier if they could apt-get install node/yarn and then just
> type node/yarn to use them.

Traditionally in Debian, we've handled naming conflicts by giving a
name to the first package using it. There have been exceptions of
course: node, and git come to mind. Some of these conflicts have been
solved by decree by the FTP masters, a couple by the technical
committee. Many have been resolved amicably by the Debian package
maintainers. Let's aim for that in this case.

I don't know of any cases when naming conflicts in Debian have been
solved by having a duel at Debconf. It's nearly a year to the next
Debconf, which is probably too long for solving this. Also, I've lost
my lightsabre.

We in Debian will always have naming conflicts like this, as long as
we have a flat namespace for packages (or in /usr/bin). It doesn't
help when upstreams don't do sufficient due diligence when choosing
names, meaning that we need to resolve them in Debian.

> - cmdtest has ~50

It's not a particularly popular package. I make no claim of
popularity, only of having used the name first.

> - for yarn/yarnpkg it's difficult to predict now, but probably it will
> end up in the range 0-6000, high or low depending how much traction it
> will get.

I don't think that is implausible. I'm not sure it's important, though.

> In conclusion, I leave it to those who know more what is the best thing
> to do !

Well, my opinion is still that it'd be nice if you called both the
package and binary yarnpkg. That would be a very simple, easy
solution. If you can convince upstream to also call the binary yarnpkg
(or yarnjs, or some other variant), that would be even better.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature