Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output

[Jonathan Dowland]

On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote:
> During a rebuild of all packages in unstable, your package failed to build:
…
> t/po.t   (Wstat: 65280 (exited 255) Tests: 38 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: No plan found in TAP output

On the face of it this looks to be a result of po4a changes. I'm not
sure if the root cause is the same as #1072643 yet; further
investigation is required.


-- 
      Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1067303: trash-cli in Debian: test problems again

[Jonathan Dowland]

Hi Boyuan (and Andrea)

On Tue May 28, 2024 at 8:08 PM BST, Boyuan Yang wrote:
> On Sun, 26 May 2024 14:04:40 +0200 Andrea Francia  
> wrote:
> > Hi Jonathan and Lucas,
> >   I solved the problem in the new release (0.24.5.26).

That's great news! I' dli

> Can you take a look and prepare a new release into Sid recently? If not,
> would you mind a NMU into DELAYED/15 with the fix included?

I'll take a look Today. I'm otherwise happy for NMUs, I'm on the Low
Threshold NMU list.


Best wishes,

-- 

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1070312: O: zdbsp -- node builder library for OpenGL-based Doom-style games

[Jonathan Dowland]

retitle 1070312 ITA: zdbsp -- node builder library for OpenGL-based Doom-style 
games
owner 1070312 j...@debian.org
thanks

On Fri May 3, 2024 at 4:18 PM BST, Bastian Germann wrote:
> Jonathan Dowland has essentially orphaned zdbsp with
> https://salsa.debian.org/debian/zdbsp/-/commit/b37655b0ffeab5ba2d8519ecec141f0f0a1d6061

I did plan to do that, yes, but I changed my mind, and haven't
had occasion to update the package since.

I'll repurpose this bug so I can close it with a package upload
rather than close it now (although it might seem odd for the current
maintainer to be ITA'ing their own package.)

-- 
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1069236: openssh-server: X over ssh fails with "cannot open display"

[Jonathan Dowland]

On Thu, Apr 18, 2024 at 06:33:00AM -0500, allan wrote:
> Resolved the issue by editing /etc/ssh/sshd_config and changing
> #AddressFamily any
> to
> AddressFamily inet

This is not a reasonable change to make to the default configuration,
because it would mean that ssh did not work out of the box in IPv6
environments.

On Thu, Apr 18, 2024 at 07:53:52AM -0500, allan wrote:
> More info - IPv6 is disabled on all four machines.  I think
> "AddressFamily any" should have supported an IPv4 connection.

*How* is it disabled? More information will be needed to figure out
exactly what's gone on in your environment.

I speculate that the hostnames you were trying to connect to were
resolving as IPv6 addresses, and the connection failing because the
hosts are rejecting IPv6 traffic. If that's right, the ultimate fix
is to correct whatever name resolution is giving you the wrong
addresses in your environment.

If you are prepared to experiment, we might be able to drill down and
check that. If so, can you

1) reverse the sshd_config change you made on at least one of the
   hosts, and restart that sshd

2) assuming the troublesome host is named "myhost" in your environment
   (substitute as appropriate), from your client machine, report the
   result of running

getent hosts myhost
dig +short myhost
nslookup myhost
ping -c 1 myhost

(one or more of these commands may not exist on your machine)

2) re-attempt to connect from your client, this time passing -vv or
   -vvv, and capture the logging output

Bug#1051202: docker.io: Please upgrade to upstream version 24 or later

[Jonathan Dowland]

On Mon, Sep 04, 2023 at 07:28:06AM -0400, Reinhard Tartler wrote:
> I'll try to patch podman to use the older API, but it seems to me the
> docker.io package in debian is lagging several upstream releases behind
> anyways.
> 
> any plans to upgrade it soon?

Echoing Reinhard here. Lots of external tooling I work with has now
moved their minimum API versions on past the ceiling value supported
by the docker.io package (e.g. [1]).  We seem to be three versions
behind (23,42,25) and tracker.d.o notes that 26.0.0~rc2 is tagged, so
it's likely 26 is just around the corner.


Thank you!


[1] https://github.com/openshift/source-to-image/issues/1135

Bug#1061857: Recommends: is too strong for dante-client

[Jonathan Dowland]

Package: aerc
Version: 0.16.0-1
Severity: minor

Hi there,

I don't think dante-client meets the bar for Recommends: "The Recommends
field should list packages that would be found together with this one in
all but unusual installations." Quite honestly I think the opposite is
true, the need for things like dante-client is somewhat esoteric. I
think this should be dropped to Suggests, or removed entirely.

[ I wanted to git-blame the control file, and/or submit a patch, but
  Salsa is down right now and I couldn't find a mirror ]

Bug#1061505: aerc: colorize broken for text/plain with dracula or nord stylesets

[Jonathan Dowland]

Package: aerc
Version: 0.16.0-1
Severity: normal

With

  [ui]
  styleset-name=dracula
  ...
  [filters]
  text/plain=colorize

text/plain emails are not colorized. This is reproducible outside
aerc. Where ~/tmp/thomas is a text/plain mail I dumped for testing,
For STYLE={solarized, default, blue}, the following works

  AERC_STYLESET=/usr/share/aerc/stylesets/$STYLE 
/usr/libexec/aerc/filters/colorize < ~/tmp/thomas

but for STYLE={nord, dracula}, it doesn't.

The issue is that those two have e.g.

  diff_add.fg=2
  diff_del.fg=1
  quote_*.fg=6

Whereas the ones that work use HTML e.g.

  quote_*.fg=#93a1a1 # bright cyan
  quote_1.fg=#268bd2 # blue
  quote_2.fg=#cb4b16 # bright red
  quote_3.fg=#d33682 # magenta
  quote_4.fg=#6c71c4 # bright magenta

My guess is they haven't been updated with some change to aerc.

-- System Information:
Debian Release: 12.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-15-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aerc depends on:
ii  libc62.36-9+deb12u3
ii  libnotmuch5  0.37-1+b1
ii  python3  3.11.2-1+b1

Versions of packages aerc recommends:
ii  dante-client  1.4.2+dfsg-7
ii  gnupg 2.2.40-1.1
ii  w3m   0.5.3+git20230121-2

Versions of packages aerc suggests:
ii  notmuch  0.37-1+b1
pn  python3-vobject  

-- no debconf information

-- 
      Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#1061160: feed2toot: please ship some of the upstream documentation

[Jonathan Dowland]

Package: feed2toot
Version: 0.17-1
Severity: normal

Hi there,

feed2toot (the package) is almost undocumented (thank you for the
manpage!)

The upstream source has a docs/ directory, and a README.md. Crucially,
these describe how to construct a minimally functional feed2toot.ini.

Please consider shipping them (source and rendered) in the Debian
package.

Bug#998002: proposal to split mupdf binary package to mupdf,mupdf-gl (was Re: Bug#998002: mupdf: What is the purpose of /usr/bin/mupdf-gl?)

[Jonathan Dowland]

Hi Davide,

Thanks for the additional information.

In my limited testing, mupdf-gl does not appear to function as well as
mupdf. I can understand different people having a preference for one or
the other.

On Tue, Nov 21, 2023 at 06:22:55PM +0100, Davide Prina wrote:
> 2) a man page for mupdf-gl

Yes, this is required by Debian policy.

> 1) a selection of which you want use at installing and
>upgrading time

One way of addressing this would be to have mupdf-gl be a separate
binary package. Another argument for that would be to reduce the
binary package size. I myself have found myself in a situation where
I wanted to install mupdf but the binary was too large for the my
bandwidth at the time (I was on a train, using tethered, metered
Internet)

I would like to hear from the package maintainers as to what their
feelings are on splitting the binary package.  I am prepared to do
some of the work.  If I don't hear from the maintainers one way or
the other, I will prepare an NMU.

[ Maintainers: please consider marking yourself as supporting low
  threshold NMUs: <https://wiki.debian.org/LowThresholdNmu> ]



Best wishes,

-- 
Jonathan Dowland

Bug#1057087: RFA: ikiwiki -- wiki compiler

[Jonathan Dowland]

retitle 1057087 ITA: ikiwiki -- wiki compiler
owner 1057087 j...@debian.org
thanks

I'm still actively using IkiWiki and want it to continue to be
well-maintained in Debian. I am happy to co-maintain the package,
and I'm adjusting the bug metadata accordingly (I think that's the
convention).

Anyone else who wants to help; please get in touch. The package
lives in the Debian project on Salsa already, so is defacto
collab-maint; I wouldn't want to change that, and I'm pro-lowNMU
threshold.

Thank you Simon for doing an amazing job, upstream and in Debian,
keeping IkiWiki going.


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1055584: ITP: cekit -- Container image creation tool

[Jonathan Dowland]

Package: wnpp
Severity: wishlist
Owner: Jonathan Dowland 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: cekit
  Version : 4.9.1
  Upstream Contact: Jonathan Dowland 
* URL : https://cekit.io/
* License : MIT
  Programming Lang: Python
  Description : Container image creation tool


  CEKit is a container-source pre-processor with a strong focus on
  modularity and code re-use. Features include
  . 
  • Container images declaratively described in YAML documents and
Jinja templates
  • Container description decomposed into separate modules which may
live in external repositories, with inter-module dependency
resolution
  • Multiple build back-ends including Docker, Podman, Buildah
  • Integration/unit testing of container images (Behave/Cucumber)

CEKit has been organically built over a period of about ten years to
enable the production of containers for much of Red Hat's Middleware
product portfolio. CEKit is nowadays an independent community project
with users and contributors beyond Red Hat.

I intend to maintain CEKit (and necessary transitive dependencies)
within Debian, in the Debian Salsa project (formerly collab-maint)
and I am a supporter of low-threshold NMUs. Contributions welcome!

-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1033479: unarchiving 1033479, reopening 1033479

[Jonathan Dowland]

At initial package installation time (some time ago), the postinst
determined that my primary interface was enp3s0. That was written to
/etc/default/minissdpd *and* recorded in debconf:

* minissdpd/listen: enp3s0

Later on my network config changed and enp3s0 was no longer correct, I
manually fixed /etc/default/minissdpd (to br0) and moved on (as per the
discussion in #1033479 up to now).

Yesterday, upon upgrading to Bookworm (1.5.20190824-1 -> 1.6.0-1), the
postinst ran and overwrote my corrected /etc/default/minissdpd with the
older, invalid value.

I'm not sure (yet) whether the postinst re-calculated the (wrong) value
of enp3s0, or read the old value. In the latter case, I don't think it's
reasonable to expect a user to correct the value in the debconf DB as
well as the /etc conf-file. And in either case, I do not think that the
postinst should overwrite a manually specified user configuration in a
conf-file in /etc.


--
      Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1050348: ITP: melonds -- nintendo DS emulator

[Jonathan Dowland]

On Wed, Aug 23, 2023 at 03:07:15PM +, Mae Miller wrote:

I'm going to be packaging this as my first package partially because
it's a program I use and care about and partially in order to learn how
the system works and to make my first contribution to debian.


Those are great reasons!

Can melonDS be usefully used without a BIOS/firmware dump from a DS?

--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1043364: mutt-wizard: missing dependency on procps for /usr/bin/pgrep

[Jonathan Dowland]

tags 1043364 + pending
thanks

On Wed, Aug 09, 2023 at 03:10:14PM +0100, Jonathan Dowland wrote:

I was fully expecting Salsa to arrange to Fork the repository and create
a Merge Request for that patch, but it did not, instead it committed it
directly to master.


I've now pushed another commit to document this change in
debian/changelog. Apologies for direct-pushing, I didn't realise Salsa
would do that, and was intending to instead raise a Merge Request.

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1043364: mutt-wizard: missing dependency on procps for /usr/bin/pgrep

[Jonathan Dowland]

Package: mutt-wizard
Version: 3.3.1-2
Severity: important
Tags: patch

/usr/bin/mw-mailsync: 15: pgrep: not found

pgrep is provided by procps which is not an essential package, so
mutt-wizard must depend upon it.

Patch at
<https://salsa.debian.org/debian/mutt-wizard/-/commit/8efd5d8d46ea4fc93737b0cda240b975c219>.

I was fully expecting Salsa to arrange to Fork the repository and create
a Merge Request for that patch, but it did not, instead it committed it
directly to master.


-- System Information:
Debian Release: 12.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mutt-wizard depends on:
ii  curl   7.88.1-10
ii  isync  1.4.4-5
ii  msmtp  1.8.23-1
ii  neomutt20220429+dfsg1-4.1
ii  pass   1.7.4-6
ii  xdg-utils  1.1.3-4.1

Versions of packages mutt-wizard recommends:
ii  abook0.6.1-2+b1
ii  cron 3.0pl1-162
ii  lynx 2.9.0dev.12-1
ii  notmuch  0.37-1+b1
ii  urlview  0.9-23.1

Versions of packages mutt-wizard suggests:
pn  links2   
pn  mpop 
ii  mpv  0.35.1-4
ii  w3m  0.5.3+git20230121-2
pn  zathura  

-- no debconf information

-- 
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#1043362: mw-mailsync: guard to check for logged in user is flawed

[Jonathan Dowland]

Package: mutt-wizard
Version: 3.3.1-2
Severity: important

The following guard is used towards the top of mw-mailsync:

  pgrep -u "${USER:=$LOGNAME}" >/dev/null || { echo "$USER not logged in; sync will 
not run."; exit ;}

This is inadequate, because USER and LOGNAME might not be defined in the
running environment even if the user is logged in. For example, in a
container context:

  conf=/some/path/to/stick/muttwizard/conf/in
  podman run --rm -ti \
  --mount type=bind,ro=false,chown=true,src=$conf,dst=$HOME \
  mutt-wizard \
  neomutt

(where 'mutt-wizard' is the name of a debian:bookworm container
with mutt-wizard and its dependencies installed.)

Furthermore, the behaviour when this fails - ${USER:=$LOGNAME}
expands to the empty string, so the script invokes
"pgrep -u >/dev/null", which is at least benign and just dumps
the pgrep invocation output on the user's terminal.

(Why run mutt-wizard in a container? To mitigate against it not
isolating its own configuration from any pre-existing configuration
belonging to the user. See:
<https://github.com/LukeSmithxyz/mutt-wizard/issues/917>)





-- System Information:
Debian Release: 12.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mutt-wizard depends on:
ii  curl   7.88.1-10
ii  isync  1.4.4-5
ii  msmtp  1.8.23-1
ii  neomutt20220429+dfsg1-4.1
ii  pass   1.7.4-6
ii  xdg-utils  1.1.3-4.1

Versions of packages mutt-wizard recommends:
ii  abook0.6.1-2+b1
ii  cron 3.0pl1-162
ii  lynx 2.9.0dev.12-1
ii  notmuch  0.37-1+b1
ii  urlview  0.9-23.1

Versions of packages mutt-wizard suggests:
pn  links2   
pn  mpop 
ii  mpv  0.35.1-4
ii  w3m  0.5.3+git20230121-2
pn  zathura  

-- no debconf information

--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#1033479: minissdpd: Service fails to start on boot with "Error parsing address/mask..."

[Jonathan Dowland]

I've hit something similar. In my case the error in the logs is

Mar 07 17:59:33 phobos minissdpd-systemd-wrapper[1302]: Error parsing 
address/mask (or interface name) : enp3s0
Mar 07 17:59:33 phobos minissdpd-systemd-wrapper[1302]: can't parse 
"enp3s0" as a valid address or interface name

and my /etc/default/minissdpd contained

MiniSSDPd_INTERFACE_ADDRESS="enp3s0"

Likewise, I have not edited that file myself. I guess it was populated
by the debconf template[1]

It was probably correct at the time I installed minissdpd (which I did
transitively: and as such I'm not very familiar with what it does or how
it works, since it's a dependency package of something else) and has
become incorrect later on, as I've moved enp3s0 onto a bridge interface.

My fix (the inverse of yours I guess) is to substitute 


MiniSSDPd_INTERFACE_ADDRESS="br0"

In the config file.

But I suggest to the maintainer (Hi Thomas!): If you're confident that
you can guess the right interface at install time, why not do that at
service start up time instead? That way it will adjust to changing
environments.


[1] 
https://salsa.debian.org/miniupnp-team/minissdpd/-/blob/debian-sid/debian/minissdpd.config#L45

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#949033: neomutt: While installing neomutt it suggest "urlview mixmaster" but there is no candidate to mixmaster.

[Jonathan Dowland]

I independently noticed this a year or so ago and filed a Merge Request
that was sadly ignored (or missed) for the last year. I've just
refreshed the Merge Request so it's mergeable again. Mutt maintainers,
please consider this trivial patch!

https://salsa.debian.org/mutt-team/neomutt/-/merge_requests/4

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1033356: ruby-asciidoctor-kroki: No documentation, README from upstream removed

[Jonathan Dowland]

Package: ruby-asciidoctor-kroki
Version: 0.7.0-2
Severity: normal

I was curious how to use this package, but it contains no documentation.

I visited the upstream URI
(<https://github.com/ggrossetie/asciidoctor-kroki/>, which has been
renamed from the one in debian/control), and found that the source
contains a README.md which is very helpful.

I was puzzled why the Debian packaged lacked this documentation. This
led me to discover that README.md is present in upstream's v0.7.0 tag,
but not in Salsa's upstream/0.7.0 tag, which seems to be significantly
different:

 48 files changed, 1196 insertions(+), 20933 deletions(-)

What's going on?


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-rc2+ (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-asciidoctor-kroki depends on:
ii  ruby-asciidoctor  2.0.18-2

ruby-asciidoctor-kroki recommends no packages.

ruby-asciidoctor-kroki suggests no packages.

-- no debconf information

-- 
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#1031402: mutt-wizard: ships and generates invalid neomutt rc files

[Jonathan Dowland]

Package: mutt-wizard
Version: 3.3.1-2
Severity: important

I've just discovered mutt-wizard and thought I'd give it a go. I have
the neomutt version as in the archive frozen for Bookworm (version
string in the boilerplate below as usual). From what I can see, this
basically does not work at all in Debian, at least in conjunction with
Bookworm's version of neomutt.


;mw -u jon -a redac...@example.org
Give your email server's IMAP address (excluding the port number):
redacted
Give your email server's SMTP address (excluding the port number):
redacted
Enter password for redac...@example.org: 
Retype password for redac...@example.org: 
[master b270548] Add given password for redac...@example.org to store.

 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 redac...@example.org.gpg
sed: can't read /home/jon/.config/mutt/muttrc: No such file or directory
redac...@example.org (account #1) added successfully.


After execution, the file sed was complaining about
(/home/jon/.config/mutt/muttrc) exists and is a regular file. Tracing
the mw script reveals this to be the sed on line 227, within the
function "getboxes", for what it's worth. Moving on…


;neomutt -F ~/.config/mutt/muttrc
Error in /usr/share/mutt-wizard/mutt-wizard.muttrc, line 11: Option 
smtp_authenticators: gssapi is not a valid authenticator
Error in /home/jon/.config/mutt/muttrc, line 2: source: file 
/usr/share/mutt-wizard/mutt-wizard.muttrc could not be sourced
Error in /home/jon/.config/mutt/accounts/Redacted.muttrc, line 12: .: unknown 
command
Error in /home/jon/.config/mutt/muttrc, line 3: source: file 
/home/jon/.config/mutt/accounts/Redacted.muttrc could not be sourced
source: errors in /home/jon/.config/mutt/muttrc
Press any key to continue...


The first error is clear enough: this line in the package's etc file
specifies an authenticator that is not supplied in the neovim package
(anymore? There's a report against the neomutt package requesting it
at #1026356)

line 12 in my Redacted.muttrc looks like this


\. /usr/share/mutt-wizard/switch.muttrc


Perhaps this is a consequence of the failing sed earlier?



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mutt-wizard depends on:
ii  curl   7.87.0-2
ii  isync  1.4.4-5
ii  msmtp  1.8.23-1
ii  neomutt20220429+dfsg1-4.1
ii  pass   1.7.4-6
ii  xdg-utils  1.1.3-4.1

Versions of packages mutt-wizard recommends:
ii  abook0.6.1-2+b1
ii  cron 3.0pl1-156
ii  lynx 2.9.0dev.12-1
ii  notmuch  0.37-1+b1
ii  urlview  0.9-23.1

Versions of packages mutt-wizard suggests:
pn  links2   
pn  mpop 
ii  mpv  0.35.1-1
ii  w3m  0.5.3+git20230121-2
pn  zathura  

-- no debconf information

Bug#988688: found in recent kernels

[Jonathan Dowland]

found 988688 5.10-158-2 6.1.8-1
thanks

Note that the two kernels I've tried so far are built from
src:linux-signed-amd64 not src:linux as per this bug; I'm not sure how
you folks handle that discrepancy across the BTS. I doubt signing is
relevant, I've got secure boot off atm.

Bug#988688: linux-source-5.10: Lenovo ThinkPad Yoga 260 fails to suspend and resume

[Jonathan Dowland]

I have the same problem on the same laptop: Thinkpad 260 Yoga. Machine
goes into suspend, but cannot be woken up. I've tried the power button
and WOL packets.

Fresh install of current Bookworm using debian installer netinst with
firmware nightly, from 2022-02-15:

604f09ff97b5faddacff2d43f8710c564d4138d8807d74985f56ab5b76fcdb88  
firmware-testing-amd64-netinst.iso

minimal install. Kernel is linux-image-6.1.0-3-amd64 (6.1.8-1)

On Mon, May 24, 2021 at 08:59:01AM -0400, Kenichiro MATOHARA wrote:

$ sudo mount -o remount,sync /
$ sync
$ logger SUSPEND; systemctl suspend


Relevant logs from me doing the same (don't look useful sadly)

Feb 16 11:56:53 debian login[841]: ROOT LOGIN  on '/dev/tty1'
Feb 16 12:00:24 debian kernel: EXT4-fs (dm-1): re-mounted. Quota mode: none.
Feb 16 12:00:32 debian root[849]: SUSPEND
Feb 16 12:00:32 debian systemd-logind[664]: The system will suspend now!
Feb 16 12:00:32 debian systemd[1]: Reached target sleep.target - Sleep.
Feb 16 12:00:32 debian systemd[1]: Starting systemd-suspend.service - System 
Suspend...
Feb 16 12:00:32 debian systemd-sleep[851]: Entering sleep state 'suspend'...
Feb 16 12:00:32 debian kernel: PM: suspend entry (deep)


--
  Jonathan Dowland

Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting

[Jonathan Dowland]

On Sat, Jan 21, 2023 at 09:26:03PM -0600, Aaron Rainbolt wrote:
If the XScreenSaver configuration file is included as a part of the 
core xscreensaver package itself, as a file that is simply unpacked, 
the following situation will result:

…
If the configuration file is split out into its own separate 
xscreensaver-config package

…

This is totally orthogonal to a solution to the bug reporter's issue.
Splitting the xscreensaver package up and shipping the same files in
different sub-packages and adding alternatives or other metapackage
complications will do nothing to solve their problem.

Your motivation for all that extra complexity is also orthogonal to
Debian: you're talking about an enhancement for Ubuntu. As it stands,
you're talking about making Debian worse to make Ubuntu better, and
that's a hard sell.


--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#1029190: notmuch-mutt: please adjust Recommends: to accommodate neomutt

[Jonathan Dowland]

Package: notmuch-mutt
Version: 0.37-1
Severity: minor
Tags: patch

See attached. This prevents accidentally installing mutt on a neomutt
system.



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-1-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages notmuch-mutt depends on:
ii  libmail-box-perl   3.009-1
ii  libmailtools-perl  2.21-2
ii  libstring-shellquote-perl  1.04-3
ii  libterm-readline-gnu-perl  1.45-1
ii  notmuch0.37-1+b1
ii  perl   5.36.0-7

Versions of packages notmuch-mutt recommends:
pn  mutt  

notmuch-mutt suggests no packages.

-- no debconf information

-- 
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net
commit 5d822d9fdf59b07050f6512fe4099ad7ae7283c0
Author: Jonathan Dowland 
Date:   Thu Jan 19 10:52:02 2023 +

Recommends: on mutt | neomutt

On systems with install-recommends: Yes, this will prevent mutt
being pulled in if neomutt is installed already.

diff --git a/debian/control b/debian/control
index 31d6471c..9f23fb97 100644
--- a/debian/control
+++ b/debian/control
@@ -153,7 +153,7 @@ Depends:
  libmail-box-perl, libmailtools-perl,
  libstring-shellquote-perl, libterm-readline-gnu-perl,
  ${misc:Depends}
-Recommends: mutt
+Recommends: mutt | neomutt
 Enhances: notmuch, mutt
 Description: thread-based email index, search and tagging (Mutt interface)
  notmuch-mutt provides integration among the Mutt mail user agent and

Bug#1004728: haskell-platform: dead upstream; remove to avoid confusion

[Jonathan Dowland]

Source: haskell-platform
Severity: important

haskell-platform is effectively dead upstream. See e.g.
<https://www.reddit.com/r/haskell/comments/sgx9ze/comment/huz9op7>

The version in Debian is several years behind the last upstream
release which itself was several years ago.

I think its continued presence in Debian risks causing confusion
to users (indeed, I am motivated to write this by someone asking
for help relating to haskell-platform on the debian-user mailing
list) and so I think the package should be dropped.

Please ACK or NACK and I'll then re-assign/re-title etc. for the
ftp team/RoM.





--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1000206: nextcloud-desktop: Login Flow v2 waits indefinitely for auth (server 20.0.8.1)

[Jonathan Dowland]

Package: nextcloud-desktop
Version: 3.3.5-1
Severity: normal

I have a nextcloud instance on my LAN, version 20.0.8.1 (following the
"nextcloud:stable" docker container image) which is functioning
normally. I can access it fine via web browser and iOS mobile apps are
able to connect to it without issue.

However nextcloud in Debian cannot. When I attempt to add my instance
to the client, it uses the "Login Flow v2" method, fires up a browser
instance to get an auth token which sits waiting indefinitely on a
"grant access" page with a little spinning progress indicator. Meanwhile
the app sits at "Waiting for authorization... (n)" where n is a second
countdown that loops once it hits zero.

My web browser is Firefox (94.0.1).

Reproduced with nextcloud-client 3.3.5-1 and 3.1.1-2+deb11u1.


-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (999, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages nextcloud-desktop depends on:
ii  libc6  2.32-4
ii  libcloudproviders0 0.3.0-3
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libnextcloudsync0  3.3.5-1
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5keychain10.10.0-1
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5qml5 5.15.2+dfsg-6
ii  libqt5quick5   5.15.2+dfsg-6
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5sql5-sqlite  5.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5webenginecore5   5.15.2+dfsg-3
ii  libqt5webenginewidgets55.15.2+dfsg-3
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libstdc++6 10.2.1-6
ii  nextcloud-desktop-common   3.1.1-2+deb11u1
ii  nextcloud-desktop-l10n 3.1.1-2+deb11u1
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtqml-models2   5.15.2+dfsg-6
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-6
ii  qml-module-qtquick-window2 5.15.2+dfsg-6
ii  qml-module-qtquick25.15.2+dfsg-6

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.1.1-2+deb11u1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#999116: ~ Re: Bug#999116: doom-wad-shareware: missing required debian/rules targets build-arch and/or build-indep

[Jonathan Dowland]

Hi Fabian!

On Wed, Nov 10, 2021 at 10:53:32AM +0100, Fabian Greffrath wrote:

I am going to fix this bug by re-uploading a new package revision.


Fair enough yes. Good idea. I think it's quite interesting we've managed
to have only three uploads in 22 years, but that's no reason to put off
fixing this bug. (and also still amusing that the wrong IWAD was uploaded
in the first place all those years ago)

Should I take the opportunity and remove you from the Uploaders list, 
i.e. replace yourself with myself?


Sure if you're happy to be in uploaders, go right ahead and remove me.

You could consider moving to dh. Although it might seem a bit crazy for
a package of literally one file. But if I had done that instead of
golfing the packaging down to the bare minimum, this upload would not be
necessary (and likely :1.9.fixed-2 could have been avoided as well)

Best wishes,

--

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#998662: picocli: Please update to newer upstream version >= 4.6.1

[Jonathan Dowland]

Source: picocli
Version: 3.9.6-3
Severity: normal

I'd like to package some software that depends upon the picocli
API from 4.x onwards (specifically the latest upstream version
4.6.1, I haven't experimented to see whether I could get away
with earlier 4.x versions). 3.9.6 is too old for this software.
Please consider updating the Debian package.


-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (999, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#998631: discount incorrectly parses URIs with trailing parentheses

[Jonathan Dowland]

On Fri, Nov 05, 2021 at 09:41:22AM +, Jonathan Dowland wrote:

The URI's closing parenthesis has been incorrectly moved outside of the
hyperlink, resulting in broken link and messy text.


I've discovered that upstream consider this to be correct to the
markdown specification, which is to say, apprarently Gruber's original
code suffers the same bug: https://github.com/Orc/discount/issues/241


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#998631: discount incorrectly parses URIs with trailing parentheses

[Jonathan Dowland]

Package: discount
Version: 2.2.7-2
Severity: normal
Tags: upstream

See e.g.

  $ markdown
  [some link with parens in it](http://foo.com/parens(yeah))
  http://foo.com/parens(yeah">some link with parens in it)

The URI's closing parenthesis has been incorrectly moved outside of the
hyperlink, resulting in broken link and messy text.

The following markdown implementations get this right:

 * libtext-markdown-perl 1.31 (debian -3) 
 * multimarkdown 1.35 (debian -2)

Correct output is

  $ markdown
  [some link with parens in it](http://foo.com/parens(yeah))
  http://foo.com/parens(yeah)">some link with parens in it


-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (999, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages discount depends on:
ii  libc6 2.32-4
ii  libmarkdown2  2.2.7-2

discount recommends no packages.

discount suggests no packages.

-- no debconf information

Bug#981594: neomutt: Please use openssl

[Jonathan Dowland]

On Sun, Sep 12, 2021 at 01:33:06PM +0200, Stefan wrote:

What about a neomutt-openssl binary package?


IMHO there would have to be a strong compelling reason to have *both*
in the archive, to overcome the drawbacks of having both: much more
complex packaging, more user confusion about which to install, etc.

Another thing to look at would be, how many open TLS bugs are there
and would using ssl resolve them? I haven't checked, but I did just
file a bug (no number yet) which is related to gnutls and the expired
LE certificate root.


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#996765: neomutt/gnutls/nntp is not verifying a Lets Encrypt trust path correctly (news.gmane.io)

[Jonathan Dowland]

Package: neomutt
Version: 20201127+dfsg.1-1.2
Severity: normal

At the time of writing, news.gmane.io is offering 4 certificates in it's
TLS bundle, including two separate roots; the older, expired root for
Lets Encrypt certificates, and the newer one:

> $ gnutls-cli --starttls-proto=nntp -p 119 news.gmane.io
> Processed 129 CA certificate(s).
> Resolving 'news.gmane.io:119'...
> Connecting to '116.202.254.214:119'...
> - Certificate type: X.509
> - Got a certificate list of 4 certificates.
> - Certificate[0] info:
>  - subject `CN=ciao.gmane.io', issuer `CN=R3,O=Let's Encrypt,C=US', serial 
> 0x03c44d2a356cad184ca947cdee4a43c78bcf, RSA key 2048 bits, signed using 
> RSA-SHA256, activated `2021-08-27 19:26:46 UTC', expires `2021-11-25 19:26:45 
> UTC', pin-sha256="IackeqoJ2tG5yu6CeMwbOFcSTTjOFQdtMxi39o1By3c="
>   Public Key ID:
>   sha1:5e6c6071d852807c9867eb42a9ce8bc7690f90b6
>   
> sha256:21a7247aaa09dad1b9caee8278cc1b3857124d38ce15076d3318b7f68d41cb77
>   Public Key PIN:
>   pin-sha256:IackeqoJ2tG5yu6CeMwbOFcSTTjOFQdtMxi39o1By3c=
> 
> - Certificate[1] info:
>  - subject `CN=R3,O=Let's Encrypt,C=US', issuer `CN=ISRG Root X1,O=Internet 
> Security Research Group,C=US', serial 0x00912b084acf0c18a753f6d62e25a75f5a, 
> RSA key 2048 bits, signed using RSA-SHA256, activated `2020-09-04 00:00:00 
> UTC', expires `2025-09-15 16:00:00 UTC', 
> pin-sha256="jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0="
> - Certificate[2] info:
>  - subject `CN=ISRG Root X1,O=Internet Security Research Group,C=US', issuer 
> `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 
> 0x4001772137d4e942b8ee76aa3c640ab7, RSA key 4096 bits, signed using 
> RSA-SHA256, activated `2021-01-20 19:14:03 UTC', expires `2024-09-30 18:14:03 
> UTC', pin-sha256="C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M="
> - Certificate[3] info:
>  - subject `CN=DST Root CA X3,O=Digital Signature Trust Co.', issuer `CN=DST 
> Root CA X3,O=Digital Signature Trust Co.', serial 
> 0x44afb080d6a327ba893039862ef8406b, RSA key 2048 bits, signed using RSA-SHA1 
> (broken!), activated `2000-09-30 21:12:19 UTC', expires `2021-09-30 14:01:15 
> UTC', pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="
> - Status: The certificate is trusted. 
> - Description: 
> (TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
> - Session ID: 
> CA:77:1C:EB:16:E2:63:C0:77:19:77:9B:C1:FB:21:65:FC:48:5F:88:27:81:3B:C3:35:4D:90:5F:60:4C:23:79
> - Options:
> - Handshake was completed
> 
> - Simple Client Mode:

Note that gnutls-cli non-the-less trusts the certificate. Neomutt,
however, does not, and reports on the expired root:

> neomutt -f news://news.gmane.io/gmane.linux.debian.devel.policy
> 
> ...
> 
> This certificate belongs to:
>DST Root CA X3
>Digital Signature Trust Co.
> 
> This certificate was issued by:
>DST Root CA X3
>Digital Signature Trust Co.
> 
> This certificate is valid
>from Sat, 30 Sep 2000 21:12:19 UTC
>  to Thu, 30 Sep 2021 14:01:15 UTC
> 
> SHA1 Fingerprint: DAC9 024F 54D8 F6DF 9493 5FB1 7326 38CA 6AD7 7C13
> SHA256 Fingerprint: 0687 2603 31A7 2403 D909 F105 E69B CF0D
> 32E1 BD24 93FF C6D9 206D 11BC D677 0739
> 
> WARNING: Server certificate has expired

This is annoying because the user must "accept (o)nce" the certificate
on each connection, and there are frequent reconnections in normal use
(every time you change group, after a timeout, etc.)

The relevant expired root is in the ca-certificates bundle. I've tried
removing it, to no avail:

> $ grep '^!' /etc/ca-certificates.conf
> !mozilla/DST_Root_CA_X3.crt
> # update-ca-certificates
> ...

Since gnutls-cli is happy, my tentative conclusion is that neomutt is
doing something wrong.


-- Package-specific info:
NeoMutt 20201127
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.10.0-6-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2.20201114)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.7.1
libnotmuch: 5.3.0
storage: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
{--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt

Compilation CFLAGS: -g -O2 
-ffile-prefix-map=/build/neomutt-aFsTyZ/neomutt-20201127+dfsg.1=. 
-fstack-protector-strong -Wformat 

Bug#916446: netcfg: please statically define ip4-localhost (mirroring ip6-localhost)

[Jonathan Dowland]

Hi,

On Fri, Dec 14, 2018 at 03:19:16PM +, Jonathan Dowland wrote:

Package: netcfg
Severity: wishlist
Tags: patch

Patch at https://salsa.debian.org/installer-team/netcfg/merge_requests/4


I got a notification that someone asked a question on the Merge Request
and that reminded me of this, two years later.

I think this would still be useful, and the commit still applies cleanly
to today's netcfg `master` branch. Could someone please consider this?
Here are two other people who have requested the same thing over the
years:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858011;msg=5>,
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427067#5>.



Thanks,

--
      Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#988597: trash-cli version too old

[Jonathan Dowland]

On Wed, Oct 13, 2021 at 10:16:24AM +0100, Jonathan Dowland wrote:

Eyeballing the failures again quickly now, I think the majority of the
failures will be due to not finding the actual test utilities in an
expected place in the chroot, variations on:

   python3: can't open file
   '/<>/.pybuild/cpython3_3.9/build/trash-put': [Errno 2]
   No such file or directory


Expanding on this a bit, the build phase runs

/usr/bin/python3 setup.py build 


Which outputs the following (elided)


running build_py
creating /<>/.pybuild/cpython3_3.9/build/trashcli
copying trashcli/fstab.py -> 
/<>/.pybuild/cpython3_3.9/build/trashcli

...

running build_scripts
creating build
creating build/scripts-3.9
copying and adjusting trash -> build/scripts-3.9

...

Note: the initial 'copying' lines are to a path
/<>/.pybuild/cpython3_3.9/build/trashcli, but the latter
ones are to just "build/scripts-3.9". And indeed, if I run

sbuild --build-failed-commands '%SBUILD_SHELL'

I'm dropped into a shell in the build environment after the test

failure. Right now that's /build/trash-cli-Nkmibk, which has the
unpacked source at trash-cli-0.21.7.24, which corresponds to the
<> substitution in the output above.

I see the path
/build/trash-cli-Nkmibk/trash-cli-0.21.7.24/.pybuild/cpython3_3.9/build,
corresponding to the first set of "copying" lines above, and containing
"tests" and "trashcli". And I see
/build/trash-cli-Nkmibk/trash-cli-0.21.7.24/build/scripts-3.9,
containing the command-line tools, corresponding to the second set of
'copying' lines above.

When the tests are executed, the following is run

cd /<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest tests

And so at the time the tests run the command line tools are not in $PWD
and tests/run_command.py::run_command constructs a path that is not
valid.

So... the question is, why does the "build_py" phase of
distutils/setuptools have the correct path, where is that being
specified? Why doesn't the "build_scripts" phase also have the correct
path, and where can we specify that?

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#988597: trash-cli version too old

[Jonathan Dowland]

Hi,

On Mon, Oct 11, 2021 at 09:11:26PM +0200, Andrea Francia wrote:

 thank you for your work.


You're welcome.


In order to help I need to be able to reproduce the failures by myself.
Can you explain to me how to do it? For example, which command
do you use for launching the tests under chroot?


Thank you. 


On my local system all the tests pass so the issue is something to do
with the build environment, most likely an undeclared package dependency
or an environment variable or path assumption that isn't holding.

I'm using the tool "sbuild" to initiate the build. This is the same tool
as used by Debian's buildds, and works by maintaining a set of chroots
to represent a clean unstable install with just the declared build
dependencies installed. If you have a Debian system, it's quite easy to
set up, see the instructions here: <https://wiki.debian.org/sbuild>

Invocation from a clean checkout of that working branch is simply
"sbuild".

The test phase is invoked  via

   dh_auto_test -O--buildsystem=pybuild

This ultimately runs something provided by the "dh-python" package,
pybuild, which I am not very familiar with:
<https://wiki.debian.org/Python/Pybuild>

In turn pybuild appears to try to autodetect the test harness being used
and invokes that. It is correctly finding pytest:

python3.9 -m pytest tests

Eyeballing the failures again quickly now, I think the majority of the
failures will be due to not finding the actual test utilities in an
expected place in the chroot, variations on:

python3: can't open file
'/<>/.pybuild/cpython3_3.9/build/trash-put': [Errno 2]
No such file or directory


--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#995414: Acknowledgement (neomutt: pager sometimes displays the wrong mail content)

[Jonathan Dowland]

Oh of course this is because my header cache got corrupted.
--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#995414: neomutt: pager sometimes displays the wrong mail content

[Jonathan Dowland]

tt  20201127+dfsg.1-1.2

-- no debconf information

-- 
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net
# muttrc for jon@qusp
# not in version control
source ~/mail/mutt/muttrc.jon@qusp.redmars

# XXX move elsewhere
set encode_from=yes
# stuff we need before muttrc.main
index-format-hook  attn  "~h Content-Type:.multipart/mixed" ""

source ~/mail/mutt/muttrc.main

# let this be overridden by darkbg
color index brightmagenta default "~t alcopop.org"
source ~/mail/mutt/darkbg

source /etc/Muttrc.d/notmuch-mutt.rc

set imap_user = 'j...@redmars.org'
# set imap_pass…
set realname = "Jonathan Dowland" # XXX move to more common?

set folder = imaps://j...@redmars.org/
source "gpg -d ~/mail/mutt/redmars.passwords.gpg |"
set ssl_starttls=yes
set smtp_url = 'smtp://j...@redmars.org:587'
#set tunnel="ssh -q j...@redmars.org /usr/lib/dovecot/imap"
set spoolfile = =INBOX
set postponed = =Drafts

set record = =archive
folder-hook . 'my_hdr Bcc: j...@dow.land'

set header_cache = ~/.mail/hcache
set message_cachedir=~/.mail/hcache

# test
set display_filter="t-prot -mt -Mmutt --pgp-short"
# the newline trick here is not working sadly
color body color8 black "Sent from my iPhone[.\n]*"
color body color8 black "⚠ External sender.*"
color body color8 black "^(From|To|Sent|Subject): .*[\.\n]*"
color body color8 black ".---=| TOFU protection by t-prot: .* lines snipped 
|=---."

folder-hook . macro index S "=missed"
folder-hook . macro pager S "=missed"
folder-hook . macro index H "=notspam"
folder-hook . macro pager H "=notspam"
folder-hook . set pager_index_lines=0
folder-hook . set wait_key
folder-hook . macro index a "=archive/"
bind index A create-alias

folder-hook =phd macro index a "=phd/archive/"
folder-hook =cs-history macro index a 
"=cs-history/archive/"

folder-hook .  set from = "j...@dow.land"
folder-hook =l/debian-user set from = "jon+debian-u...@dow.land"

folder-hook .  set signature = ~/.signature
folder-hook =l/debian-user set signature = ~/mail/mutt/signature.debian

folder-hook =cs-history alternative_order text/html text/calendar text/plain 
text/*
# Jon's muttrc # Wed Jan  5 11:52:02 GMT 2005

# generic stuff (appropriate to any use of mutt)

#
## mailbox types and locations
#
unset record

# ^ = current folder (http://home.worldonline.dk/byrial/mutt/patches/)
# via http://wiki.mutt.org/index.cgi?MuttFaq/Folder
#folder-hook . 'set record="^"'

set nomark_old# new messages until read (no 'old')

set xterm_set_titles = yes
set xterm_title = "mutt: %f: %?m?%m messages messages?%?n? [%n NEW]?"

#
## displaying mail: index
## we try and use colour to indicate as much as possible, which frees up
## as much horizontal screen estate as possible. Display by thread,
## fallback to date, thraeads considered as old as the newest post.
#
# message status flags: O/N/D/* not needed (bold); how to express 'r'eplied, 
's'igned... %Z

set strict_threads = no# don't group common-subjects
folder-hook . set sort=threads
set sort_aux=last-date # bump old threads 
bind index   collapse-thread # easily hide threads
bind index  collapse-thread

macro index i '?'

# http://www.davidpashley.com/cgi/pyblosxom.cgi/2004/12/10#mutt-argh
bind index x noop  
# don't like accidentally quitting and having to feed my GPG pass in again
set quit=ask-no

# Thu 29 Jun 12:29:12 BST 2017 - substituting "%> " for "%| " to work around a 
neomutt
# bug (866366)
folder-hook . "set index_format=\"\
%?M?\
%@thrd@   %@date@ %-15.15F %s%* %@flag@\
&\
%@attn@%4C %@date@ %-15.15F %s%* %@flag@\
?\"" # collapsed threads vs. normal mail
# %4C  %{%b %d} %-15.15t %-15.15F %s?\""  # would be nice for filtered

# hack due to rendering errors in neovim
index-format-hook  thrd "~A" "淋  "
index-format-hook  date  "~d<1d""%[%H:%M] " # 05:51_ (6 chars)
index-format-hook  date  "~d<1m""%[%a %d]"  # Wed 28 (6 chars)
index-format-hook  date  "~d<1y""%[%b %d]"  # Jun 17 (6 chars)
#index-format-hook  date  "~A"   "%[%m/%y] " # 07/19_ (6 chars)
index-format-hook  date  "~A"   " %[%Y] "   # _2014_ (6 chars)

# other RC files should define more of these BEFORE this one is defined
# this is a catch-all
index-format-hook  attn  "~A" "  "

index-format-hook  flag  "~F" ""
#index-format-hook  flag  "~A" "  "
#★ A  

# other ideas for thread glyph: 淋瑱  
# attachment glyph:   

folder-hook . exec collapse-all# collapse t

Bug#988597: trash-cli version too old

[Jonathan Dowland]

On Tue, Sep 28, 2021 at 11:21:52PM +0100, Jonathan Dowland wrote:

I've begun work on updating to 0.21.7.24. I've pushed my in-progress
work here:
<https://salsa.debian.org/debian/trash-cli/-/tree/jmtd-update-0.21.7.24>


I've resolved the test_bump issue (remove it) as well as the next
significant problem, which was the assumption that '/usr/bin/env python'
will launch a python3 interpreter. This will never be true in Debian.
I've patched that everywhere, I think. (Note: I was a little surprised
that I had to patch setup.py *and* the generated binaries, as "python3.9
setup.py clean" re-generates them)

A huge chunk of tests are failing still, I've attached a list to this
mail. Feel free to help try and figure out why!


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net
=== FAILURES ===
___ TestDeletingExistingFile.test_a_trashinfo_file_should_have_been_created 

self = 

def test_a_trashinfo_file_should_have_been_created(self):
>   read_file(self.temp_dir / 'XDG_DATA_HOME/Trash/info/foo.trashinfo')

tests/test_trash_put_slow.py:50: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/tmpmkz9vn_y/XDG_DATA_HOME/Trash/info/foo.trashinfo'

def read_file(path):
>   with open(path) as f:
E   FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmpmkz9vn_y/XDG_DATA_HOME/Trash/info/foo.trashinfo'

trashcli/fs.py:82: FileNotFoundError
___ TestDeletingExistingFile.test_it_should_remove_the_file 

self = 

def test_it_should_remove_the_file(self):
>   assert not file_exists(self.temp_dir / 'foo')
E   AssertionError: assert not True
E+  where True = file_exists(('/tmp/tmp2ce8sk36' / 'foo'))
E+where '/tmp/tmp2ce8sk36' = 
.temp_dir

tests/test_trash_put_slow.py:44: AssertionError
_ Test_when_deleting_an_existing_file_in_verbose_mode.test_should_be_succesfull 
_

self = 


def test_should_be_succesfull(self):
>   assert 0 == self.fixture.exit_code
E   AssertionError: assert 0 == 2
E+  where 2 = .exit_code
E+where  = 
.fixture

tests/test_trash_put_slow.py:70: AssertionError
_ 
Test_when_deleting_an_existing_file_in_verbose_mode.test_should_tell_where_a_file_is_trashed
 _

self = 


def test_should_tell_where_a_file_is_trashed(self):
output = self.fixture.stderr.splitlines()
expected_line = "trash-put: '%s' trashed in %s/XDG_DATA_HOME/Trash" % \
(self.foo_file, self.fixture.temp_dir)
>   assert (expected_line in output)
E   AssertionError: assert "trash-put: '/tmp/tmptm9z736y/foo' trashed in 
/tmp/tmptm9z736y/XDG_DATA_HOME/Trash" in ["python3: can't open file 
'/<>/.pybuild/cpython3_3.9/build/trash-put': [Errno 2] No such 
file or directory"]

tests/test_trash_put_slow.py:67: AssertionError
 Test_when_fed_with_dot_arguments.test_dot_argument_is_skipped _

self = 

def test_dot_argument_is_skipped(self):

self.fixture.run_trashput(".")

# the dot directory shouldn't be operated, but a diagnostic message
# shall be written on stderr
>   self.assertEqual("trash-put: cannot trash directory '.'\n",
 self.fixture.stderr)
E   AssertionError: "trash-put: cannot trash directory '.'\n" != "python3: 
can't open file '/build/trash-cl[102 chars]ry\n"
E   - trash-put: cannot trash directory '.'
E   + python3: can't open file 
'/<>/.pybuild/cpython3_3.9/build/trash-put': [Errno 2] No such 
file or directory

tests/test_trash_put_slow.py:99: AssertionError
_ Test_when_fed_with_dot_arguments.test_dot_argument_is_skipped_even_in_subdirs 
_

self = 

def test_dot_argument_is_skipped_even_in_subdirs(self):
sandbox = MyPath.make_temp_dir()

self.fixture.run_trashput("%s/." % sandbox)

# the dot directory shouldn't be operated, but a diagnostic message
# shall be writtend on stderr
>   self.assertEqual("trash-put: cannot trash '.' directory '%s/.'\n" %
 sandbox,
 self.fixture.stderr)
E   AssertionError: "trash-put: cannot trash '.' directory '/t[15 
chars].'\n" != "python3: can't open file '/build/trash-cl[102 chars]ry\n"
E   - trash-put: cannot trash '.' directory '/tmp/tmp8lfflw9o/.'
E   + python3: can't open file 
'/<>/.pybuild/cpython3_3.9/build/trash-put': [Errno 2] No such 
file or directory

tests/test_trash_put_slow.py:118: AssertionError
__ Test_when_fed_with_dot_arguments.test_dot_dot_argument_is_skipped ___

self = 

def test_dot_dot_argument_is_skipped(self):

self.fixture.run_trashput("..")

 

Bug#988597: trash-cli version too old

[Jonathan Dowland]

Hello,

On Sun, May 16, 2021 at 06:08:09PM +0200, Andrea Francia wrote:

I've seen in https://salsa.debian.org/debian/trash-cli that I can also send
a Merge Request, I could try do it by myself but I don't know yet how
importing from sources from upstream works and which check I've to do after
the source code modifications to check the packages.


I've begun work on updating to 0.21.7.24. I've pushed my in-progress
work here:
<https://salsa.debian.org/debian/trash-cli/-/tree/jmtd-update-0.21.7.24>

The issue that I need to fix is that tests/test_bump.py fails because
the 'script' directory is not present in PYTHONPATH when the test is
invoked under the chroot environment that Debian packages are built
with.


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#986895: Suggests: mixmaster which does not exist in the archive

[Jonathan Dowland]

Source: mutt
Version: 2.0.5-4
Severity: minor
Tags: newcomer

As per the subject. mixmaster was removed from the archive in 2017. This
came up on debian-user@, someone was wondering what it was.



--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#397767: graphicsmagick-libmagick-dev-compat: Request for splitting the package

[Jonathan Dowland]

Happy 14th birthday, bug!

A lot has happened in the last 14 years, but one thing hasn't changed:
end-user tools written in Perl need something providing Image::Magick,
and if graphicsmagick-libmagick-dev-compat satisfies that then all the
development libraries for other toolchains are pulled in, unnecessarily.

One thing that has changed in the last 14 years is tooling, and the rise
of popularity of containers (docker, etc.). With that has come a renewed
focus on the footprint of images. For an image I'm working on right now,
the following are the size differences for the two providers of
Image::Magick for perl:

   libimage-magick-perl:  +29.1 MB
   graphicsmagick-libmagick-dev-compat: +94.2 MB

I respectfully submit that it still makes sense to split this package. 
Current maintainers, do you agree? Would you accept patches to do this,

perhaps after Bullseye?


Best wishes,

--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#855837: golang-petname: Do not include in stretch at request of maintainer

[Jonathan Dowland]

Hi Ivo,

I'm copying the Maintainers: email here (go list)

On Fri, Feb 05, 2021 at 10:21:46AM +0100, Ivo De Decker wrote:

I uploaded this as a dependency of LXD which unfortunately we did not finish
packaging in time for the Stretch freeze. As such, unless someone else is
prepared to help support it, and/or users of this package come out of the
woodwork, I do not think we should include this library in Stretch.


You filed this bug in 2017, and closed this in may 2020. However, there hasn't
been any update of this package in debian, and you removed yourself from
uploaders (in git). 


I think I closed in in May because I believed the package was otherwise
being looked after, and I've had nothing to do with it for years.
However, a look at tracker.debian.org suggests the only other uploader
was Michael Stapelberg who I believe has left Debian.

I recall the upstream maintainer, Dustin Kirkland, was interested in
working on the package, but I don't know if that's still the case.


Is there any point of shipping it in bullseye?


I doubt it, but I'm not qualified to judge any more.

If nobody in the Debian Go Packaging Team is interested in it, it's
probably worth officially orphaning.


Best wishes,

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#981176: RFP: doas -- minimal replacement for sudo

[Jonathan Dowland]

On Wed, Jan 27, 2021 at 10:59:58AM +0100, Bernd Zeimetz wrote:

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: doas


I'd like this too!


 Version : 6.8
 Upstream Author : Duncan Overbruck znc others
* URL : https://github.com/Duncaen/OpenDoas


There's also <https://github.com/slicer69/doas>

I have not compared the forks.

Note that for slice69's fork,


  persist  After the user successfully authenticates,
  do not ask for a password again for some time.
  Works on OpenBSD only, persist is not available on
  Linux or FreeBSD.


It looks like Duncaen's fork has (new, disabled-by-default, potentially
dangerous?) persist support. I think this feature will be almost
essential for this to be a viable replacement for sudo.


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#975664: mlocate: obsolete-conffile /etc/updatedb.conf

[Jonathan Dowland]

On Tue, Nov 24, 2020 at 09:46:58PM +0100, Thorsten Glaser wrote:

And, indeed, mlocate_0.26-4_amd64.deb no longer ships this file.
The debian/changelog is quiet about this. So this is most likely
a mistake?


Good catch, thanks! This should be fixed in 0.24-5, which I have just
uploaded.


Best wishes,

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#974568: debhelper: no init script but dh_installinit generates init-handling postinst

[Jonathan Dowland]

Package: debhelper
Version: 13.2.1
Severity: normal

I'm working on a modification for mlocate to add a systemd unit file[1]
that is intended to be activated by systemd timer, so, not run as a
daemon, and not analoguous to an init script. The unit is not installed
(has no [Install] section) and the package does not ship an init script.
(There's a .timer unit, too, which does have an [Install] section.)

The presence of the .service file, though, causes dh_installinit to
generate postinst snippets like this


# Automatically added by dh_installinit/13.2.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ 
"$1" = "abort-remove" ] ; then
if [ -x "/etc/init.d/mlocate" ]; then
update-rc.d mlocate defaults >/dev/null


This is superfluous, but relatively benign because it's guarded by
"[ -x". However, it triggers a Lintian test of severity "error".


E: mlocate: init.d-script-not-included-in-package etc/init.d/mlocate
N:
N:   The /etc/init.d script is registered in the postinst script, but is
N:   not included in the package.
N:
N:   Severity: error
N:
N:   Check: init.d


I've hesitated over whether to file this against debhelper, or the lintian
test, but the lintian test is "right", so far as it goes: the postinst does
reference an init script that is not included in the package. One could argue
the severity/certainty is wrong given the guard, I suppose. I'm CCing the
Lintian maintainers for their info.

[1] 
https://salsa.debian.org/debian/mlocate/-/commit/5df4fd837132cfbe1673977033c78a0b829e9bd1
 but it's still a work-in-progress


Best wishes,

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#748845: lintian: Please add a check for packages that ship a .service file but are not calling init-system-helpers

[Jonathan Dowland]

On Wed, May 21, 2014 at 01:52:23PM +0200, Laurent Bigonville wrote:

lintian should generate a warning/error when a package is shipping a
systemd service file but is not calling the init-system-helpers scripts,
especially for the services containing an [Install] section.


For services that do not contain an [Install] section, this requested
test should probably be skipped. Example: a service file shipped to be
activated by a systemd timer, not something intended to be running as a
daemon.

(I'm hitting problems with this assumption in other Lintian tests, hence
finding this wishlist bug)

--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#804722: git-buildpackage: import-dsc creates impractical merge commits after new upstream releases

[Jonathan Dowland]

I've been hitting this recently and wondering whether the current
behaviour is by accident or design (I'm surprised it's at least five
years old) but I concur with the filer that a much simpler, two-step
merge (merge upstream, then apply debian diff as the next commit) would
be *far* easier to work with. Do the maintainers have a view?


--
Jonathan Dowland

Bug#969901: torbrowser-launcher: depends on /usr/bin/gpg2 but dependency not expressed

[Jonathan Dowland]

Package: torbrowser-launcher
Version: 0.3.2-11~bpo10+1
Severity: serious
Justification: Policy 3.5

There's a few things going on in this session, but this bug report is
about the last backtrace in particular:

$ torbrowser-launcher
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.3.2
https://github.com/micahflee/torbrowser-launcher
Creating GnuPG homedir /home/jon/.local/share/torbrowser/gnupg_homedir
Downloading Tor Browser for the first time.
Downloading 
https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US
Latest version: 9.5.4
Downloading 
https://dist.torproject.org/torbrowser/9.5.4/tor-browser-linux64-9.5.4_en-US.tar.xz.asc
Downloading 
https://dist.torproject.org/torbrowser/9.5.4/tor-browser-linux64-9.5.4_en-US.tar.xz
Verifying Signature
Refreshing local keyring...
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/launcher.py", line 
589, in verify
c.verify(signature=sig, signed_data=signed)
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 559, in verify
raise errors.BadSignatures(results[1], results=results)
gpg.errors.BadSignatures: 110775B5D101FB36BC6C911BEB774491D9FF06E2: Key expired

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/launcher.py", line 
600, in run
verify()
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/launcher.py", line 
594, in verify
raise Exception
Exception

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/launcher.py", line 
603, in run
self.common.refresh_keyring()
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/common.py", line 
209, in refresh_keyring
'--refresh-keys'], stderr=subprocess.PIPE)
  File "/usr/lib/python3.7/subprocess.py", line 775, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.7/subprocess.py", line 1522, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/gpg2': 
'/usr/bin/gpg2'
Aborted




-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20190110
ii  libdbus-glib-1-2  0.110-4
ii  python3   3.7.3-1
ii  python3-gpg   1.12.0-6
ii  python3-pyqt5 5.11.3+dfsg-1+b3
ii  python3-requests  2.21.0-1
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.5.10-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.2-10

-- no debconf information

Bug#969522: mlocate: please consider moving the mlocate VCS to the "debian" project

[Jonathan Dowland]

Source: mlocate
Version: 0.13-3
Severity: minor

Prior to Salsa, the mlocate source was in the "collab-maint" VCS
repository. This signalled that the package was to be collaboratively
maintained.

The equivalent way on Salsa of signalling that a package should be
collaboratively maintained is for it to be part of the "debian" project.

If you are still happy for the package to be collaboratively maintained,
please consider moving the VCS repository into the "debian" project on
Salsa, to signal so.

Either way, please configure the project's default branch to "debian",
so Merge Requests are raised against that branch by default.



Best wishes!

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#880507: mlocate: daily cron job should be (optionally) splayed to prevent thundering herd

[Jonathan Dowland]

If #882993 is implemented (systemd support), then the default behaviour
of the systemd timer would be to splay, and you could consider this bug
addressed, assuming everyone who wanted splay is using systemd.


--
Jonathan Dowland

Bug#882993: mlocate: please supply a systemd unit for updatedb.mlocate

[Jonathan Dowland]

I'm (finally) working on a patch for this.

--
Jonathan Dowland

Bug#969038: openjdk-11-jre-headless: manpages describe JDK8, last updated in 2015

[Jonathan Dowland]

Package: openjdk-11-jre-headless
Version: 11.0.8+10-1~deb10u1
Severity: normal

/usr/lib/jvm/java-11-openjdk-amd64/man/man1/java.1.gz describes JDK8,
and omits descriptions of e.g. -Xpatch.  The bottom line of the manpage
reads

JDK 803 March 2015  java(1)

I've only checked that one, I don't know about the others.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openjdk-11-jre-headless depends on:
ii  ca-certificates-java  20190405
ii  java-common   0.71
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libcups2  2.2.10-6+deb10u3
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-3
ii  libnss3   2:3.42.1-1+deb10u2
ii  libpcsclite1  1.8.24-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxrender1   1:0.9.10-1
ii  libxtst6  2:1.2.3-1
ii  util-linux2.33.1-0.1
ii  zlib1g1:1.2.11.dfsg-1

openjdk-11-jre-headless recommends no packages.

Versions of packages openjdk-11-jre-headless suggests:
ii  fonts-dejavu-extra 2.37-1
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
ii  libnss-mdns0.14.1-1

-- no debconf information

Bug#936146: archivemail - Python 3 porting

[Jonathan Dowland]

On Mon, Jul 27, 2020 at 12:37:36AM -0400, Sandro Tosi wrote:

do you have any plan on completing this port? I'm not a user of
archivemail but it looks like it should be removed, not salvaged:

* no new upstream releases since 2011 (!)
* last upload to debian in 2014
* retired from fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1777616

maybe it's time to let it go?

If i dont hear otherwise in a week, i'll file for its removal


I think I'm happy for it to go. I'm certainly not going to be able to
work on porting it, and I'm most likely going to move to something else
for the purposes I use it.

Thanks,

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#956637: trash-cli: fail to find trashed file outside home directory

[Jonathan Dowland]

On Sun, May 24, 2020 at 10:03:56AM +0200, Samuele Battarra wrote:

Package: trash-cli
Version: 0.17.1.14-3
Followup-For: Bug #956637

Dear Maintainer,

attatched a patch


Thanks for that: one nit, the filesystem path(s) might not always be
utf-8, but the general approach looks right. The patch in #960566 does
much the same thing but determines the filesystem encoding too. It looks
like this also fixes using trash-cli on big endian machines.

Bug#962393: game-data-packager: warning about missing modules

[Jonathan Dowland]

On Sun, Jun 07, 2020 at 02:02:40PM +0200, Reiner Herrmann wrote:

I think this warning should only be shown when it's actually packaging
doom-related packages, because when I want to package data for a different
game, I'm not really interested in missing modules for doom.


I agree.

--
Jonathan Dowland

Bug#962450: forked-daapd: Please document (Description: or README.Debian) why the web UI is disabled

[Jonathan Dowland]

Package: forked-daapd
Version: 26.4+dfsg1-1
Severity: minor

I've figured out why the web UI is disabled by reading the packaging
source, changelog entries etc. But I think it would be better for our
users if this was explicitly stated somewhere very plain, such as
the package long Description: field, or README.Debian, since this is
a significant deviation from upstream.

Hopefully we can eventually solve the DFSG issues and enable a web UI
again!

-- System Information:
Debian Release: 10.2
 APT prefers stable
 APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages forked-daapd depends on:
ii  adduser   3.118
ii  avahi-daemon  0.7-4+b1
pn  libantlr3c-3.4-0 | libantlr3c-antlrdbg-3.4-0  
ii  libasound21.1.8-1
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavcodec58  7:4.1.4-1~deb10u1
ii  libavfilter7  7:4.1.4-1~deb10u1
ii  libavformat58 7:4.1.4-1~deb10u1
ii  libavutil56   7:4.1.4-1~deb10u1
ii  libc6 2.28-10
pn  libconfuse2   
ii  libcurl3-gnutls   7.64.0-4
ii  libevent-2.1-62.1.8-stable-4
pn  libevent-2.1-7
pn  libevent-pthreads-2.1-6   
pn  libevent-pthreads-2.1-7   
ii  libgcrypt20   1.8.4-5
ii  libgnutls30   3.6.7-4
ii  libgpg-error0 1.35-1
ii  libjson-c30.12.1+ds-2
ii  libjson-c40.13.1+dfsg-6
pn  libmxml1  
ii  libplist3 2.0.1~git20190104.3f96731-1
ii  libprotobuf-c11.3.1-1+b1
ii  libpulse0 12.2-4+deb10u1
ii  libsodium23   1.0.17-1
ii  libsqlite3-0  3.27.2-3
ii  libswscale5   7:4.1.4-1~deb10u1
ii  libunistring2 0.9.10-1
pn  libwebsockets15   
pn  libwebsockets8
ii  lsb-base  10.2019051400
ii  psmisc23.2-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages forked-daapd recommends:
pn  libavcodec-extra  

forked-daapd suggests no packages.

--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#886642: fixed? (please default to a larger /boot for guided partitioning)

[Jonathan Dowland]

Hi!

On Mon, May 25, 2020 at 01:22:03PM +0200, Holger Wansing wrote:

This is indeed fixed for bullseye, tracked in #893886 / #951709, leading to 
/boot
getting a size between 512 and 768MB (depending on disc size).


Thanks for fixing this,


I was not aware of this bug, so did not close it...


I'm not sure what to do with it, now. Partman is done and those bugs
archived. This is against debian-installer, and I presume there's some
lag before it picks up/bundles a fixed partman, so perhaps this bug
should track that. Can someone with more of a clue tell me if that makes
sense?


Should this be considered for backporting to stable?


And I'm guessing that should be tracked in yet another bug.

Bug#936146: archivemail - Python 3 porting

[Jonathan Dowland]

On Thu, May 14, 2020 at 03:31:31PM -0400, Scott Talbert wrote:
archivemail seems to be a good candidate to RM due to dead upstream. 
However, it still has a relatively high popcon, so people seem to be 
using it.


I'm willing to take a stab at porting to Python 3 if anyone is 
available to test it?  The port effort doesn't look that bad at first 
glance, but I don't use this package.


I'm happy to test anything you produce, but I'd warn you that I think
it's quite a significant piece of work. From what I remember when I last
looked at hacking a feature into it (#736327), archivemail uses the
older of two different APIs provided by the python "mailbox" library,
and only the newer one was carried forward to Python 3. So moving away
from that older API is a big part of the work. 



--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#952377: lists.debian.org: request new list debian-antispam-user

[Jonathan Dowland]

MTA configuration, antispam etc. is a conversation I might participate
in but it's not something I'd be prepared to subscribe to (yet another)
mailing list to do so, it's not worth the extra burden to me.

It's also on-topic for debian-user@, I believe. So I'm not sure there's
a pressing need for another mailing list. (I am not in the listmaster
team).

I would suggest trying to discuss MTA and anti-spam matters on
debian-user@ for a while and then re-evaluate whether you still want a
separate list afterwards.

--
  Jonathan Dowland
   https://jmtd.net

Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system

[Jonathan Dowland]

On Sun, Feb 09, 2020 at 11:12:48PM +0100, Manuel A. Fernandez Montecelo wrote:

2) These kind of methods are done for special packages like firmware,
very popular apps like flash (at the time), etc, or *data* packages
from games.


We have game-data-packager (gdp, which I originally wrote) for
situations like this. When you generate a .deb (as gdb does) containing
the data and install that, you get an Installed-Size which reflects the
actual disk usage of the package; you know that data is removed again
when you remove the package; you can express package inter-dependencies
properly, etc.

The ember package, at present

• claims to have an Installed-Size of 35.8 kB but will install
  177+MiB in pre-inst
• Does not clean that up again on package removal
• Doesn't handle "snap install" failing, silently completes package
  installation
• Supplies a .desktop file referencing Exec=ember but does not provide
  any ember binary (even as a route into the snap) in $PATH

It would be interesting to see whether game-data-packager could consume
data from snaps, and avoid all these pitfalls. I believe smcv was
interested in something similar for flatpaks (that might have been
installing into flatpaks, rather than consuming from them)


--
  Jonathan Dowland
   https://jmtd.net

Bug#951490: haskell-yaml: please split yaml2json out into a separate package

[Jonathan Dowland]

Source: haskell-yaml
Version: 0.8.32-4+b1
Severity: wishlist

/usr/bin/yaml2json is a potentially useful tool for many different people,
not just haskell hackers. The dep chain for libghc-yaml-dev is quite large.
On my system, it ruled out installing over a 3G network connection, even
though I already have lots of Haskell dev packages installed.

Please consider splitting it out into a separate binary package.



-- System Information:
Debian Release: 10.2
 APT prefers stable
 APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--
  Jonathan Dowland
   https://jmtd.net

Bug#950791: neomutt: missing debian/copyright entries for autosetup/*

[Jonathan Dowland]

Some initial work on this:

Bug#950791: neomutt: missing debian/copyright entries for autosetup/*

[Jonathan Dowland]

Source: neomutt
Version: 20180716+dfsg.1-1
Severity: serious
Justification: Policy 12.5

The file autosetup/autosetup leads with the following comment:

# Copyright (c) 2006-2011 WorkWare Systems http://www.workware.net.au/
# All rights reserved

This is a bit concerning, but the concern is alleviated by the contents of
autosetup/LICENSE, which looks DFSG-acceptable (but I haven't looked very
closely to be sure)

However, debian/copyright does not have a stanza for autosetup/* leaving '*'
as the applicable stanza, stating GPL-2+ which is not correct.

-- Package-specific info:
NeoMutt 20180716
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 4.19.0-6-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1.20180714)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-25' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-25) 


Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/lib 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-oDMtzm/neomutt-20180716+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3  -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
 +attach_headers_color +compose_to_sender +compress +cond_date +debug 
 +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
 +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
 +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
 +skip_quoted +smtp +status_color +timeout +tls_sni +trash 


Compile options:
 +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens +getaddrinfo 
 +gnutls +gpgme +gss +hcache -homespool +idn -locales_hack +lua +meta 
 +mixmaster +nls +notmuch -openssl +pgp +sasl +smime +start_color 
 +sun_attachment +typeahead 
MAILPATH="/var/mail"

MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
   https://github.com/neomutt/neomutt/issues
or send an email to: 


-- System Information:
Debian Release: 10.2
 APT prefers stable
 APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt is related to:
ii  neomutt  20180716+dfsg.1-1

-- no debconf information

--
  Jonathan Dowland
   https://jmtd.net

Bug#948328: mutt: NNTP/usenet support enabled but undocumented/possibly not working

[Jonathan Dowland]

Package: mutt
Version: 1.10.1-2.1
Severity: normal

According to mutt -v, nntp is enabled:

$ mutt -v | grep -i nntp
Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20190525095611.wDDr64yqq1.db.mutt/mutt-1.10.1=.
 -fstack-protector-strong -Wformat -Werror=format-security' 
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

But, it appears to be undocumented

$ zgrep -i nntp /usr/share/doc/mutt/manual.txt.gz 
$ echo $?
1 

And does not work (using a sample muttrc from the *neomutt* manual, to
set up the binds and variables for the NNTP patch)

> $ mutt -F mail/muttrc.usenet 
> Error in mail/muttrc.usenet, line 6: ask_follow_up: unknown variable
> Error in mail/muttrc.usenet, line 7: ask_x_comment_to: unknown variable
> Error in mail/muttrc.usenet, line 8: catchup_newsgroup: unknown variable
> Error in mail/muttrc.usenet, line 9: followup_to_poster: unknown variable
> Error in mail/muttrc.usenet, line 10: group_index_format: unknown variable
> Error in mail/muttrc.usenet, line 11: inews: unknown variable
> Error in mail/muttrc.usenet, line 12: mime_subject: unknown variable
> Error in mail/muttrc.usenet, line 13: newsgroups_charset: unknown variable
> Error in mail/muttrc.usenet, line 14: newsrc: unknown variable
> Error in mail/muttrc.usenet, line 15: news_cache_dir: unknown variable
> Error in mail/muttrc.usenet, line 16: news_server: unknown variable
> Error in mail/muttrc.usenet, line 17: nntp_authenticators: unknown variable
> Error in mail/muttrc.usenet, line 18: nntp_context: unknown variable
> Error in mail/muttrc.usenet, line 19: nntp_listgroup: unknown variable
> Error in mail/muttrc.usenet, line 20: nntp_load_description: unknown variable
> Error in mail/muttrc.usenet, line 21: nntp_pass: unknown variable
> Error in mail/muttrc.usenet, line 22: nntp_poll: unknown variable
> Error in mail/muttrc.usenet, line 23: nntp_user: unknown variable
> Error in mail/muttrc.usenet, line 24: post_moderated: unknown variable
> Error in mail/muttrc.usenet, line 25: save_unsubscribed: unknown variable
> Error in mail/muttrc.usenet, line 26: show_new_news: unknown variable
> Error in mail/muttrc.usenet, line 27: show_only_unread: unknown variable
> Error in mail/muttrc.usenet, line 28: x_comment_to: unknown variable
> Error in mail/muttrc.usenet, line 33: catchup: no such function in map
> Error in mail/muttrc.usenet, line 35: change-newsgroup: no such function in 
> map
> Error in mail/muttrc.usenet, line 37: edit-followup-to: no such function in 
> map
> Error in mail/muttrc.usenet, line 39: edit-newsgroups: no such function in map
> Error in mail/muttrc.usenet, line 41: edit-x-comment-to: no such function in 
> map
> Error in mail/muttrc.usenet, line 43: followup-message: no such function in 
> map
> Error in mail/muttrc.usenet, line 45: post-message: no such function in map
> Error in mail/muttrc.usenet, line 47: reload-active: no such function in map
> Error in mail/muttrc.usenet, line 51: subscribe-pattern: no such function in 
> map
> Error in mail/muttrc.usenet, line 53: uncatchup: no such function in map
> Error in mail/muttrc.usenet, line 57: unsubscribe-pattern: no such function 
> in map
> Error in mail/muttrc.usenet, line 59: change-newsgroup-readonly: no such 
> function in map
> Error in mail/muttrc.usenet, line 61: forward-to-group: no such function in 
> map
> Error in mail/muttrc.usenet, line 65: get-parent: no such function in map
> Error in mail/muttrc.usenet, line 69: get-message: no such function in map
> source: errors in mail/muttrc.usenet



-- Package-specific info:
Mutt 1.10.1 (2018-07-13)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.19.0-5-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none

Bug#948326: neomutt: nntp support missing or broken

[Jonathan Dowland]

Package: neomutt
Version: 20180716+dfsg.1-1.1
Severity: normal

The neomutt manual.txt.gz claims NNTP is supported, and documents
all the NNTP-related variables that can be set, functions that can
be bound, etc., and even provide a sample neomuttrc for use with
NNTP.

But the patch is not actually applied according to neomutt -v and
the binds, variables used in the sample neomuttrc do not work:

$ neomutt -v | grep nntp
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp 
+pop 

see +nntp there but missing is "--enable-nntp"

And

> $ mutt -F mail/muttrc.usenet 
> Error in mail/muttrc.usenet, line 6: ask_follow_up: unknown variable
> Error in mail/muttrc.usenet, line 7: ask_x_comment_to: unknown variable
> Error in mail/muttrc.usenet, line 8: catchup_newsgroup: unknown variable
> Error in mail/muttrc.usenet, line 9: followup_to_poster: unknown variable
> Error in mail/muttrc.usenet, line 10: group_index_format: unknown variable
> Error in mail/muttrc.usenet, line 11: inews: unknown variable
> Error in mail/muttrc.usenet, line 12: mime_subject: unknown variable
> Error in mail/muttrc.usenet, line 13: newsgroups_charset: unknown variable
> Error in mail/muttrc.usenet, line 14: newsrc: unknown variable
> Error in mail/muttrc.usenet, line 15: news_cache_dir: unknown variable
> Error in mail/muttrc.usenet, line 16: news_server: unknown variable
> Error in mail/muttrc.usenet, line 17: nntp_authenticators: unknown variable
> Error in mail/muttrc.usenet, line 18: nntp_context: unknown variable
> Error in mail/muttrc.usenet, line 19: nntp_listgroup: unknown variable
> Error in mail/muttrc.usenet, line 20: nntp_load_description: unknown variable
> Error in mail/muttrc.usenet, line 21: nntp_pass: unknown variable
> Error in mail/muttrc.usenet, line 22: nntp_poll: unknown variable
> Error in mail/muttrc.usenet, line 23: nntp_user: unknown variable
> Error in mail/muttrc.usenet, line 24: post_moderated: unknown variable
> Error in mail/muttrc.usenet, line 25: save_unsubscribed: unknown variable
> Error in mail/muttrc.usenet, line 26: show_new_news: unknown variable
> Error in mail/muttrc.usenet, line 27: show_only_unread: unknown variable
> Error in mail/muttrc.usenet, line 28: x_comment_to: unknown variable
> Error in mail/muttrc.usenet, line 33: catchup: no such function in map
> Error in mail/muttrc.usenet, line 35: change-newsgroup: no such function in 
> map
> Error in mail/muttrc.usenet, line 37: edit-followup-to: no such function in 
> map
> Error in mail/muttrc.usenet, line 39: edit-newsgroups: no such function in map
> Error in mail/muttrc.usenet, line 41: edit-x-comment-to: no such function in 
> map
> Error in mail/muttrc.usenet, line 43: followup-message: no such function in 
> map
> Error in mail/muttrc.usenet, line 45: post-message: no such function in map
> Error in mail/muttrc.usenet, line 47: reload-active: no such function in map
> Error in mail/muttrc.usenet, line 51: subscribe-pattern: no such function in 
> map
> Error in mail/muttrc.usenet, line 53: uncatchup: no such function in map
> Error in mail/muttrc.usenet, line 57: unsubscribe-pattern: no such function 
> in map
> Error in mail/muttrc.usenet, line 59: change-newsgroup-readonly: no such 
> function in map
> Error in mail/muttrc.usenet, line 61: forward-to-group: no such function in 
> map
> Error in mail/muttrc.usenet, line 65: get-parent: no such function in map
> Error in mail/muttrc.usenet, line 69: get-message: no such function in map


-- Package-specific info:
NeoMutt 20180716
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 4.19.0-5-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1.20181013)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=/usr/bin/cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-7' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 

Bug#945787: haskell-haddock-library: package description references non-existent "haddock" package

[Jonathan Dowland]

Source: haskell-haddock-library
Version: 1.5.0.1-2+b1
Severity: minor
Tags: newcomer

As per subject:

>   Description: library exposing some functionality of Haddock
>Haddock is a documentation-generation tool for Haskell
>libraries. These modules expose some functionality of it
>without pulling in the GHC dependency.
>.
>For interacting with Haddock itself, see the ‘haddock’ package.
   ^^^

The haddock package was removed in 2010.

Bug#944522: libsparkline-php: use of Object which is now a reserved word

[Jonathan Dowland]

Package: libsparkline-php
Version: 0.2-7
Severity: normal

I invoke sparkline via ikiwiki's sparkline plugin. Since updating to Buster
I now get:

remote: PHP Fatal error:  Cannot use 'Object' as class name as it is reserved 
in /usr/share/php/sparkline/Object.php on line 71


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.1.17-x86_64-linode128 (SMP w/2 CPU cores; PREEMPT)
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 libsparkline-php depends on:
ii  php-gd  2:7.3+69
ii  php7.0-gd [php-gd]  7.0.33-0+deb9u5
ii  php7.3-gd [php-gd]  7.3.4-2

libsparkline-php recommends no packages.

libsparkline-php suggests no packages.

-- no debconf information

Bug#944358: rss2email: New upstream repository, 2 new releases

[Jonathan Dowland]

Source: rss2email
Version: 1:3.9-4.1
Severity: normal

Seems the active home for rss2email is now
https://github.com/rss2email/rss2email

That has two releases ahead of the fork that the Debian package is
tracking.

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#944349: tootle: unexpectedly empty "Home"

[Jonathan Dowland]

Package: tootle
Version: 0.2.0-2
Severity: normal

"tootle" is presently showing a completely empty "Home", which is
obviously not right. If I log into my instance (mastodon.cloud) there's
obviously stuff in my "Home" stream there.



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tootle depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  elementary-xfce-icon-theme   0.13.1-1
ii  libc62.28-10
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgee-0.8-2 0.20.1-2
ii  libglib2.0-0 2.58.3-2+deb10u1
hi  libgranite5  5.1.0-2
ii  libgtk-3-0   3.24.5-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libsoup2.4-1 2.64.2-2

tootle recommends no packages.

tootle suggests no packages.

-- no debconf information

Bug#942108: ufw: enabling ufw is breaking the INPUT chain

[Jonathan Dowland]

Package: ufw
Version: 0.36-1
Severity: important

Dear Maintainer,

Post-buster upgrade, and ufw is no longer functioning correctly. I'm using
ip(6)tables-legacy, rather than the newer xtables stuff, for interoperability
with docker. My ufw ruleset has several ALLOWs, e.g.

# ufw status | grep 22
22 ALLOW   Anywhere

(taken when ufw is "running").

However upon first starting ufw ("ufw enable"), all incoming traffic to the
host is dropped. Via the console I can see that this is because the INPUT
chain policy has been set to DENY, and the ufw tables are not hooked in
properly. Excerpts from "iptables-save" after "ufw enable":

*filter
:INPUT DROP [2943:317505]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [80:9298]
…
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
…

So great, my rules are encoded into the ufw-user-input table fine, but that
table is not hooked into INPUT : iptables-save | grep "^-A INPUT" is empty.

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.1.2-x86_64-linode124 (SMP w/2 CPU cores; PREEMPT)
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 ufw depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  iptables   1.8.2-4
ii  lsb-base   10.2019051400
ii  python33.7.3-1
ii  ucf3.0038+nmu1

ufw recommends no packages.

Versions of packages ufw suggests:
ii  rsyslog  8.1901.0-1

-- debconf information:
* ufw/existing_configuration:
  ufw/allow_known_ports:
  ufw/allow_custom_ports:
  ufw/enable: true

Bug#941758: systemd: StopWhenUnneeded has stopped working for a mount unit

[Jonathan Dowland]

On Mon, Oct 07, 2019 at 12:49:01PM +0200, Michael Biebl wrote:

A buster-backport, sure, that is defintely going to happen.
The current version of systemd in bullseye is imho in a pretty good
shape, so I might just do a backport of 242-7.


Great.


Alternatively, assuming a reasonable patch can be extracted from
v241..v242, what is the likelyhood of accepting a patch in stable
updates for this issue?


I would consider such a patch. But it depends on how invasive that patch
would be.


Fair enough, thanks. Realistically I doubt I'll work on one and I'll 
wait instead for buster-backports. But I'll probably have a look to see 
if I can find the commit that fixed it just in case it's really simple.



Thank you,

--

Jonathan Dowland

Bug#941758: systemd: StopWhenUnneeded has stopped working for a mount unit

[Jonathan Dowland]

On Sat, Oct 05, 2019 at 02:20:48AM +0200, Michael Biebl wrote:

Do you know about automount units?
They would be the perfect fit for your use case.


From what I understand they behave like pre-systemd automounting, that
is, any process that attempted to read/open /backup would cause it to be
mounted, and what I want is only for "blessed" services to do so.  So an
accidental rm -f / won't hit it (unless, in my current setup, a backup
is running. But I hope to find a better solution with mount namespaces).


I could reproduce the behaviour with v241 for a .mount unit but not a
.service unit.


Excellent, thanks!


Upgrading to buster, i.e. v242, I could no longer reproduce the issue,
so closing the bug report for 242-7, the current version in buster.


Buster (stable) has v241. 


Are you likely to do a backport of ≥ v242 in Buster's lifetime?

Alternatively, assuming a reasonable patch can be extracted from
v241..v242, what is the likelyhood of accepting a patch in stable
updates for this issue?


Thanks,

--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#941209: rclone manpage details installing from upstream

[Jonathan Dowland]

Package: rclone
Version: 1.45-3
Severity: minor

The rclone(1) manpage has an "Install" section towards the beginning
which explains how to install rclone from upstream — i.e., download
the binary from the web and run that.

This is obviously not the preferred way of running rclone from the
rclone Debian package.

The manpage should be adjusted to be appropriate and relevant to a
Debian system. Probably just deleting that entire section would do.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rclone depends on:
ii  libc6  2.28-10

rclone recommends no packages.

rclone suggests no packages.

-- no debconf information

--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Bug#940708: acorn: please revisit your versioning strategy before making a sid upload

[Jonathan Dowland]

Source: acorn
Version: acorn
Severity: normal

The versioning strategy that you are using for the package, and
currently only reflected in experimental, results in versions like the
following

   
6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-5

I guess each version component corresponds to one of the bundled
libraries. Which is which, is not clear from the version string alone.
Perhaps it corresponds perfectly to the order of the bundled packages
in debian/control "provides". Perhaps it does not?

Please reconsider your approach to the version string. This is not a
useful scheme. No good can come from this. The super-long version string
*will*, however, cause pain and problems for other Debian developers. It
causes the display of package and versions in tabular form difficult or
broken. It makes it impossible to reliably remember or re-type the
version from memory. It's not useful from a dependency point-of-view,
because a dependent package cannot specify a dependency on only the
component they care about, so they would have to include the versions of
the packages they don't care about too. That makes it no more useful
than an invented single version triplet just for your bundle.

Continuing to use this scheme will make people's lives harder. It's
anti-social.

Please do not upload any package with the current version scheme to
sid.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--
Jonathan Dowland

Bug#931857: ioquake3: framerate/performance under wayland is poor (FPS misleading)

[Jonathan Dowland]

Package: ioquake3
Version: 1.36+u20181222.e5da13f~dfsg-2
Severity: normal

Hi,

Game performance under Wayland is much lower than under Xorg. I have FPS
displayed within the game and in both cases it reports something around
90fps at all times. But I suspect this is misleading in the Wayland case
(possibly due to off-screen rendering or buffers or something?); it
*feels* much lower. I cannot reliably hit things with the Rail gun,
whereas playing the same level/skill/#bots under Xorg is much smoother.



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ioquake3 depends on:
ii  ioquake3-server  1.36+u20181222.e5da13f~dfsg-2
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-3
ii  libgl1   1.1.0-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libogg0  1.3.2-1+b1
ii  libopenal1   1:1.19.1-1
ii  libopus0 1.3-1
ii  libopusfile0 0.9+20170913-1
ii  libsdl2-2.0-02.0.9+dfsg1-1
ii  libvorbis0a  1.3.6-2
ii  libvorbisfile3   1.3.6-2
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages ioquake3 recommends:
ii  x11-utils  7.7+4
ii  zenity 3.30.0-2

ioquake3 suggests no packages.

Versions of packages ioquake3 is related to:
ii  libgl1-mesa-dri  18.3.4-2

-- no debconf information

Bug#911074: tootle: some missing icons in tootle

[Jonathan Dowland]

found 911074 0.2.0-2
thanks

On Mon, Oct 15, 2018 at 11:57:32AM +0100, Jonathan Dowland wrote:

When viewing someone's profile in tootle, the unfollow icon is a placeholder
(see attached image). I keep clicking it by accident because it looks just
like the "new toot" image (unless that's also a missing image placeholder)


With 0.2.0-2, the "new toot" image seems to have been resolved, but
the "follow" icon still seems to be broken (see attached picture)

--
  Jonathan Dowland
   https://jmtd.net

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Jonathan Dowland]

Hi Shengjing Zhu (et al)

I've just (finally) attempted to reproduce this on my Buster host, but
could not on this attempt. Libvirtd did not change my ip_forward setting
from 0 to 1 in the test, but I had to do so manually to re-enable VM
networking outside of the host (I don't think I did this manually in the
first instance). Docker did not change the FORWARD chain policy since
ip_forward was set to 1. My libvirtd VMs are using the default bridged
network.

I'll keep trying to reproduce this but for now let's assume that it doesn't
happen.

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

Preserving the rather large CC list for now…

On Thu, Jun 20, 2019 at 06:05:22AM -0400, Sam Hartman wrote:

I feel very uncomfortable with a change as big as this revert happening
this late in the release cycle.


How big is big? The MR I raised resurrects a patch that changes one line
of code, and was shipped in the last stable release. Although it looks
like further work is needed to make the change as smooth as possible so
this would grow. However, the patch certainly needs more testing. Is the
issue that it results in a large change in terms of what software is
executed by the user as a consequence, and what of that has been tested
thus far in the freeze?

How late is late? How would you have felt about it back in early April,
when I first raised it? I was surprised to discover it then, and I felt
it was late in the cycle even then. But mostly whats happened since is
nothing.

I absolutely do not blame the GNOME team here. Simon McVittie and
Michael Biebl in particular have taken risks sticking their heads above
the parapet to engage with me on this matter, and both have made it
clear that it would be unreasonable for them to make the call given
their respective levels of involvement. I respect that, and I am
extremely grateful for them engaging with the issue. The others are
either too busy or have taken a decision not to engage with a
potentially toxic issue, and I respect that, too: we are all volunteers
who have to make our own choices about what we are prepared to do and
engage in. Besides, like many teams, the GNOME team is clearly
under-resourced.

I am a *little* disappointed that this does not seem to have been
thought of as an important, project-wide issue. Regardless of whether
one uses GNOME or Wayland oneself, the matter of the default desktop for
the distribution we are all working to produce, and the experience that
our users will get out of the box, I would have thought was important
for all of us. It reinforces the idea, to me, that we are largely
working in our own silos, and not concerned (enough) about the holistic
distribution as a whole.


And yet, the lack of a clear reconfirmation in this time line even given
the wonderfully civil discussion is telling.


I'm very pleased that the discussion has come across as civil. I've
tried really hard from my end to achieve that, I know that issues around
GNOME can result in some very toxic communications.


My proposal--which again I have no power to implement--is that we go
forward with the current default.  However, we remain open to a revert
in the first couple of buster point releases.


There are caveats with switching the default in either direction. 
Let's say we go with Wayland now, and later decide to switch as per the

criteria/process you sketch below.

• users of the default, who got Wayland from Buster onwards and had no
  problems, would subsequently find themselves switched to Xorg by
  stable-updates, which IMHO would be unexpected (if noticed) and
  contrary to the expectations of a stable release.

• A user who installed or upgraded and got Wayland by default but had
  problems, would have likely addressed them by switching to the Xorg
  session explicitly (assuming they could figure out that doing so
  mitigated their issues). Changing the default would only prevent
  *future* users from hitting the same problems.


The criteria for that revert should be based on the actual severity and
frequence of problems our users run into, but should specifically
exclude the blanket reluctance to  make a change like that in a point
release.  We would still need adequate testing of such a revert.


My concern with this is it's a new set of policies and procedures, not
codified anywhere, with a lot of detail to work out "on the hoof" (how
do we measure frequency of problems? do we go with the existing bug
severity guidelines? How much is adequate testing? etc.)

So combined with the user experience above, I think we would be best not
to change the default within a stable release cycle, unless there was
some kind of enormous catastrophic issue with Wayland that we don't
know about yet, and that's unlikely.

I still argue that the traditional Debian conservative, when-its-ready
approach would be the distribution status quo (Xorg), but I recognise
the concerns about the proposed patch, further work needed, lack of
testing etc.; and those are not issues I think I can resolve alone.


--
Jonathan Dowland

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

Hi Andrew

So far as I am aware there is still radio silence from active GNOME
packaging team members regarding this issue. No comment yet on the
patch I adapted, positive or negative; this bug (#927667) remains
at an RC severity.

I've not yet read all the thread that Samuel linked to[1] but it looks
like it leans in favour of preserving the current default (xorg).

I'm copying -release team to see if they have any (new) opinions on
the matter. Otherwise I guess it's up to someone to prepare an NMU
upload, which I will *try* to look at in the next few days, but can't
make any guarantees.

Further testers of the patch on this bug would be most welcome.

[1] https://lists.debian.org/debian-accessibility/2019/02/threads.html#4

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Jonathan Dowland]

On Mon, Jun 17, 2019 at 07:26:04PM +0800, Shengjing Zhu wrote:

Please do think more about this issue. And understand why docker does
this for the security reason.


I understand the security issue. I understand why it does it. But if its
the case that this does break unrelated software, i.e., if the ip_forward
check is not sufficient/is not working (I am still to retest), then we
also have that problem. And it's not clear which is "worse".


And I would argue this is a security issue too, if libvirt enables
ip_forward and does nothing else.


I agree.


They could add a "-j DROP" rule that was scoped specifically to the docker
subnet, after their other (-j ACCEPT) rules. That's just one way that this
could be done less disruptively.


No, because they enabled ip_forward setting.


Sure, but using a -j DROP rule means it's at least theoretically possible
for unrelated software to have its own rules in the forward chain that are
not broken by the chain policy change. Having said that, I'm only sketching
the outline of an alternative solution here; it would need working up into
a proper alternative solution, and I do not have the time to do that.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Jonathan Dowland]

On Mon, Jun 17, 2019 at 04:22:30AM +0800, Shengjing Zhu wrote:

Control: severity -1 normal

On Tue, Jun 11, 2019 at 6:09 PM Shengjing Zhu  wrote:

I checked more carefully on https://github.com/moby/moby/pull/28257
and https://github.com/moby/moby/issues/14041
Then I concluded that docker does nothing wrong in this case.


[...]

With the reason I explained last week, I would downgrade this issue.


Sorry for not replying sooner, I had a very busy week.

Your code review and conclusions from it are reasonable. I read them
last week (although I did not have time to reply) and my thoughts were:
is that the code in the current Debian package?

I ask because the reason I filed this in the first place is because I
hit it on my main Debian system. My kvm/libvirt-based VMs lost their
networking due to docker changing the forward iptables policy. I had
not manually modified the ip_forward /proc setting, so either

1) this was not necessary for libvirt/kvm's networking to function,
   and so is not a perfect test as to whether changing the forwarding
   iptables chain will break something

or

2) libvirt/kvm's networking set the ip_forward proc setting it required,
   and the packaged docker does not correctly check the proc value before
   making the change, despite the logic in the code linked above (or
   perhaps that is not the code corresponding to the docker version that
   is presently packaged)

(Or I suppose 3), a race is possible between the /proc check and the iptables
change, but I don't think that's likely what has happened in my case.)

So IMHO the severity drop is not appropriate because it's predicated on a
theoretical reasoning of the situation rather than a practical one, i.e., I
actually hit this on a real machine in real circumstances. But I will attempt
to reproduce it a second time on my real machine before challenging the
severity again.

To respond to some of your specific points:


So as for your VM scenario, why didn't you set ip_forward manually?


Because I did not need to. Either it was not necessary for the specific
networking setup for my libvirt/kvm VMs, or libvirt/kvm set it explicitly
itself. I do not manually need to tweak stuff in /proc. As part of
reproducing this I will check the specific network setup that the libvirt
VMs are using, but it's the package/debian default.


How docker know it's not a vulnerability if it didn't set FORWARD
chain to DROP when it enables ip_forward.


They could add a "-j DROP" rule that was scoped specifically to the docker
subnet, after their other (-j ACCEPT) rules. That's just one way that this
could be done less disruptively.

--

Jonathan Dowland

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Jonathan Dowland]

On Mon, Jun 17, 2019 at 09:16:18AM +0700, Arnaud Rebillout wrote:

I will, and can even go further and display an explicit message when
user upgrade the package maybe? (I'm not sure how to do that but I'm
sure I'll find an example easily).


That, in particular I think is a bad idea. It seems like it might be useful
when you consider one package in isolation, but then upgrades become really
painful when a whole load of such packages all have their messages one after
the other.


--

Jonathan Dowland

Bug#865975: #865975 docker.io breaks (bridged) network for VMs

[Jonathan Dowland]

severity 865975 critical
thanks

My report just got merged into this one as a duplicate, so sorry for being
late to the party…

On Tue, Nov 27, 2018 at 12:42:28PM +1100, Dmitry Smirnov wrote:

I'm lowering severity back to "important". You are not wrong that Docker is
hostile to other applications but I think many users would agree that we need
Docker in "testing" and upcoming Debian release despite of this problem.


With respect Dmitry, I don't think that this is an appropriate reason to lower
the severity.

I agree that we should ship Docker in Buster, even if we have not resolved this
issue in time, since we couldn't introduce it after the fact, and it's an
important and/or high-profile package.

But the bug clearly meets the criteria for Critical severity: "makes unrelated
software on the system (or the whole system) break": one can witness unrelated
VMs lose networking in real time by starting the docker daemon and triggering
the policy change.

The proper way to try and ensure that Docker does not get dropped from Buster
is to either fix the bug or request an exception from the release team (a
"buster-ignore" tag). Lowering the severity to avoid triggering a removal is 
just
hiding the bug from RC bug summaries and dashboards etc., violating SC §3 "We
will not hide problems".

I'm fairly confident that the release team would tag this buster-ignore. But,
the preferred solution is, of course, to fix the bug.

As Clint points out in [1], a solution is to ship a minimal conffile.
On the face of it that seems like a simple solution, which has not been 
discussed
by anyone else yet in the bug. I've tested the concept and it works, but needs
cooking up into a patch. What are the caveats for this? At a minimum we
would need a README.Debian too, I guess.


[1] <20180104025648.eycf37gbzkxe7...@scru.org>

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#930302: installing and starting docker changes iptables FORWARD policy, breaking unrelated things

[Jonathan Dowland]

On Mon, Jun 10, 2019 at 07:12:37PM +0800, Shengjing Zhu wrote:

I looked at the bug list of docker.io, found it's already reported at #865975


Thank you, I missed this when I looked myself.


docker did this intentionally, and also metioned this behaviour in its
chanelog(in src engine/CHANGELOG.md, not in /usr/share/doc)

* Change the default `FORWARD` policy to `DROP`
[#28257](https://github.com/docker/docker/pull/28257)

And please note that this change is since docker 1.13.0(2017-01-18).


All the above is interesting but seems entirely tangential to either
the discussion about severity or getting it fixed.


in #865975, people has already palyed with the bug severity, and I
don't think it's worth playing again this time.


Please feel free not to.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#903635: This is RC; breaks unrelated software

[Jonathan Dowland]

clone 903635 -1
retitle -1 installing and starting docker changes iptables FORWARD policy, 
breaking unrelated things
severity 903635 important
found 903635 18.09.1+dfsg1-7
found -1 18.09.1+dfsg1-7
thanks

On Mon, Jun 10, 2019 at 01:27:45AM +0800, Shengjing Zhu wrote:

Could you provide more info about "changed my FORWARD chain policy to
DROP"?


In a fresh test Buster installation. Before:


# iptables -L | grep FORWARD
Chain FORWARD (policy ACCEPT)
# dpkg -l docker.io
# dpkg-query: no packages found matching docker.io
# apt install -y docker.io


After


# iptables -L | grep FORWARD
Chain FORWARD (policy ACCEPT)
# systemctl start docker
# iptables -L | grep FORWARD
Chain FORWARD (policy DROP)


So: Installing (*and* starting) Docker, with no other configuration steps
performed by the user, changes the FORWARD table policy, which breaks e.g.
any running VMs on the host.


I set add `"iptables": false` to `/etc/docker/daemon.json`. Then reboot
my laptop. Then run `iptables-save`.


Setting that does stop this from happening, yes. If this was the package
default that would resolve the issue I have.

But that would not address the original filer's issue (unnecessary chain
DOCKER-USER creation, which I can reproduce). I should have filed a separate
issue really, sorry. I've cloned now.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Jonathan Dowland]

On Sat, Jun 08, 2019 at 10:13:03PM -0400, Afif Elghraoui wrote:

I don't understand... I thought the whole point of making a bug
release-critical is to keep the bug out of the release (either by having
it fixed or removing the package).


No, that's not the point; it's the consequence. There are clear criteria
for the bug categories, "breaks unrelated software" is one of them and
what is happening here.


if you want to pursue a buster-ignore tag, someone please contact the
release team and make it happen. https://www.debian.org/Bugs/Developer
says explicit authorization is needed from the release managers, but I'd
worry that an email to debian-rele...@lists.debian.org might get lost
and it'd be weird to file a bug on release.debian.org asking to apply a
tag to another bug.


Someone should indeed do this. I might get around to it, but I can't
promise, I'm very busy this week.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

reassign 927667 gdm3
tags 927667 +patch
thanks

On Fri, May 10, 2019 at 10:26:07AM +0100, Jonathan Dowland wrote:

Two ways of resolving this are: Either the default GNOME3 session in Debian
switched back to Xorg, or the default desktop session is switched away from
GNOME; but I would much prefer the former.


The attached debdiff (bringing back the similar change from 2016) seems
to work for me (tested in a VM) but I would appreciate any additional
testing that folks could spare.

The debdiff is an NMU but I currently have no plans to upload it as such.

Also available at:
   https://salsa.debian.org/gnome-team/gdm/merge_requests/8

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄
commit 049dc7f4142850ae34ea530b5447175dd8a3834e
Author: Jonathan Dowland 
Date:   Thu May 23 16:43:14 2019 +0100

postpone switch to Wayland as default, again

This is a repeat of 569d7f50fe3a06908886cefc5168126197fec570 from
2016, postponing the switch to Wayland for the default Debian
desktop. See #927667 for discussion.

diff --git a/debian/changelog b/debian/changelog
index fc06f058..d2e936f7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+gdm3 (3.30.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Re-introduce debian/patches/09_default_session.patch, switching the
+default session back to "default", postponing a move to Wayland by
+default for Buster. Closes: #927667.
+
+ -- Jonathan Dowland   Fri, 24 May 2019 10:52:17 +0100
+
 gdm3 (3.30.2-3) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/09_default_session.patch b/debian/patches/09_default_session.patch
new file mode 100644
index ..d41fc744
--- /dev/null
+++ b/debian/patches/09_default_session.patch
@@ -0,0 +1,19 @@
+Description: Prefer (Xorg-based) desktop session
+ Default to "default.desktop" session, postponing a switch to
+ Wayland for the default Debian desktop.
+
+Origin: commit:569d7f50fe3a06908886cefc5168126197fec570
+Bug-Debian: https://bugs.debian.org/927667
+
+index ca06608c..3276b902 100644
+--- a/daemon/gdm-session.c
 b/daemon/gdm-session.c
+@@ -560,7 +560,7 @@ get_fallback_session_name (GdmSession *self)
+ }
+ }
+ 
+-name = g_strdup ("gnome");
++name = g_strdup ("default");
+ if (get_session_command_for_name (self, name, NULL)) {
+ g_free (self->priv->fallback_session_name);
+ self->priv->fallback_session_name = name;
diff --git a/debian/patches/series b/debian/patches/series
index 69745241..87fece76 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,6 +2,7 @@ manager-don-t-kill-timed-login-session-immediately-after-.patch
 manager-session-Add-some-debugging-around-starting-reauth.patch
 session-Don-t-allow-greeter-operations-on-an-running-sess.patch
 GdmManager-Don-t-perform-timed-login-if-session-gets-star.patch
+09_default_session.patch
 16_xserver_path.patch
 90_config_comments.patch
 91_dconf_database_path.patch

Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Jonathan Dowland]

Hi Arnaud - sorry I missed your messages until now.

On Fri, May 10, 2019 at 09:03:41AM +0700, Arnaud Rebillout wrote:

As I mentioned above, there's a discussion with a work in progress to
fix that upstream: https://github.com/docker/libnetwork/pull/2339

I don't think it will be ready in time for buster though. So I see two
solutions going forward:

- 1 Jonathan lower the severity of the bug so that it's not RC.


I'd rather not do that, because I think RC is the right classification;
*but* I don't feel necessarily (given the circumstances) that docker.io
should be removed from Buster, so can I instead suggest we request that
this bug is ignored for Buster? I think we need to ask the release team
to do that (and tag accordingly) but I'll double-check the procedure.


- 2 I import the patch from github, even though it's work in progress. I
will follow up and update the patch as soon as upstream release a proper
fix, and it will be included in a point release of buster.



If I don't get any feedback from you Jonathan in the following days,
I'll go for solution number 2 then.


I bow to your judgement as maintainer as to whether the partial fix is
worth applying on its own. Will the patch in #2339 address the specific
issue of what happens on package install?

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#882715: neomutt: can I has an alternative for /usr/bin/mutt ?

[Jonathan Dowland]

On Fri, Sep 28, 2018 at 11:48:53AM +0200, Andreas Henriksson wrote:

CCing people who showed interest on the bug report. Help with
(additional) testing would be welcome.


I've performed a preliminary test here: applied and build both
packages, patches apply clean, builds are fine; installed both
packages in the following order: neomutt, then mutt; the alternative
was registered  for neomutt, then changed to mutt, then I overrode
it manually. This is all as expected and desired.


Thanks

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#928029: planner: segfaulted; now segfaults on every start-up

[Jonathan Dowland]

On Fri, May 17, 2019 at 11:33:41AM +0100, Jonathan Dowland wrote:

Some additional context:  was running in a GNOME/Wayland
session. I'm going to try GNOME/Xorg now.


Actually i mave have already been in GNOME/Xorg rather than Wayland,
unfortunately I cannot be sure now. The following happened on my next attempt
to use planner, definitely in an Xorg session this time. I did not set the
--g-* argument. SEGV happened when editing a text field "Name" in the "edit 
task"
dialog.

(gdb) run
Starting program: /usr/bin/planner 
[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Gtk-Message: 11:34:31.593: Failed to load module "canberra-gtk-module"
[New Thread 0x72281700 (LWP 29894)]
[New Thread 0x71a80700 (LWP 29895)]
[New Thread 0x7120c700 (LWP 29898)]

Thread 1 "planner" received signal SIGSEGV, Segmentation fault.
g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x7fffe8094080, 
   fundamental_type=fundamental_type@entry=0x50 [GObject]) at ../../../gobject/gtype.c:4026

4026../../../gobject/gtype.c: No such file or directory.
(gdb) bt
#0  0x7745c51f in g_type_check_instance_is_fundamentally_a
   (type_instance=type_instance@entry=0x7fffe8094080, 
fundamental_type=fundamental_type@entry=0x50 [GObject])
   at ../../../gobject/gtype.c:4026
#1  0x7743ca1e in g_object_ref (_object=0x7fffe8094080) at 
../../../gobject/gobject.c:3212
#2  0x774429b5 in g_weak_ref_get (weak_ref=) at 
../../../gobject/gobject.c:4387
#3  0x775a71d2 in g_settings_backend_invoke_closure 
(user_data=0x7fffe80a9800)
   at ../../../gio/gsettingsbackend.c:263
#4  0x77355dd8 in g_main_dispatch (context=0x55642c00) at 
../../../glib/gmain.c:3182
#5  0x77355dd8 in g_main_context_dispatch 
(context=context@entry=0x55642c00) at ../../../glib/gmain.c:3847
#6  0x773561c8 in g_main_context_iterate
   (context=0x55642c00, block=block@entry=1, dispatch=dispatch@entry=1, 
self=)
   at ../../../glib/gmain.c:3920
#7  0x773564c2 in g_main_loop_run (loop=0x55a898d0) at 
../../../glib/gmain.c:4116
#8  0x779ef8e7 in gtk_main () at 
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#9  0x55570bae in main ()

Bug#928029: planner: segfaulted; now segfaults on every start-up

[Jonathan Dowland]

On Sat, Apr 27, 2019 at 09:07:03AM +0300, Yavor Doganov wrote:

Control: tags -1 + unreproducible moreinfo

Jonathan Dowland wrote:

Package: planner
Version: 0.14.6-7
Severity: important

planner segfaulted me shortly after starting it for the first time
(upon inserting a new task); now, it segfaults upon each attempt to
start it.


Thanks for the report; unfortunately I cannot reproduce it.  And
that's an abort, not segfault.  Could you please run the planner
executable in gdb with --g-fatal-warnings?


Sorry for mixing the two up. Here's a trace with --g-fatal-warnings.
ON this occasion the crash happened when I attempted to resize the
window.  Some additional context:  was running in a GNOME/Wayland
session. I'm going to try GNOME/Xorg now.

Trace:

(gdb) set args --g-fatal-warnings
(gdb) run
Starting program: /usr/bin/planner --g-fatal-warnings
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Gtk-Message: 11:16:05.042: Failed to load module "canberra-gtk-module"
[New Thread 0x72281700 (LWP 24278)]
[New Thread 0x71a80700 (LWP 24279)]
[New Thread 0x7120c700 (LWP 24280)]
[New Thread 0x7fffe3a76700 (LWP 24284)]
[New Thread 0x7fffe3275700 (LWP 24285)]
[New Thread 0x7fffe250c700 (LWP 24286)]
[New Thread 0x7fffe1d0b700 (LWP 24287)]
[Thread 0x7fffe250c700 (LWP 24286) exited]
[Thread 0x7fffe3275700 (LWP 24285) exited]
[Thread 0x7fffe1d0b700 (LWP 24287) exited]
[New Thread 0x7fffe1d0b700 (LWP 24288)]
[New Thread 0x7fffe250c700 (LWP 24289)]
[Thread 0x7fffe1d0b700 (LWP 24288) exited]
[Thread 0x7fffe250c700 (LWP 24289) exited]
[Thread 0x7fffe3a76700 (LWP 24284) exited]

(planner:24274): GLib-GObject-CRITICAL **: 11:30:58.399: g_object_ref: 
assertion 'G_IS_OBJECT (object)' failed

Thread 4 "dconf worker" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7120c700 (LWP 24280)]
0x7735bca5 in _g_log_abort (breakpoint=1) at 
../../../glib/gmessages.c:554
554 ../../../glib/gmessages.c: No such file or directory.
(gdb) bt
#0  0x7735bca5 in _g_log_abort (breakpoint=1) at 
../../../glib/gmessages.c:554
#1  0x7735cfad in g_logv
   (log_domain=0x77464078 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, 
format=, args=args@entry=0x7120b840) at ../../../glib/gmessages.c:1371
#2  0x7735d17f in g_log
   (log_domain=log_domain@entry=0x77464078 "GLib-GObject", 
log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x773ab6bc "%s: 
assertion '%s' failed") at ../../../glib/gmessages.c:1413
#3  0x7735d9a9 in g_return_if_fail_warning
   (log_domain=log_domain@entry=0x77464078 "GLib-GObject", 
pretty_function=pretty_function@entry=0x774675f8 <__FUNCTION__.14906> "g_object_ref", 
expression=expression@entry=0x774663bf "G_IS_OBJECT (object)")
   at ../../../glib/gmessages.c:2762
#4  0x7743ca3c in g_object_ref (_object=0x55d00f00) at 
../../../gobject/gobject.c:3212
#5  0x774429b5 in g_weak_ref_get (weak_ref=) at 
../../../gobject/gobject.c:4387
#6  0x775a71d2 in g_settings_backend_invoke_closure 
(user_data=0x55c9f740)
   at ../../../gio/gsettingsbackend.c:263
#7  0x775a7370 in g_settings_backend_dispatch_signal
   (backend=0x556a9610 [DConfSettingsBackend], function_offset=8, name=0x55c20f10 
"/org/gnome/planner/views/task-view/assigned-to/", origin_tag=0x0, names=0x0) 
at ../../../gio/gsettingsbackend.c:334
#8  0x7275df09 in dconf_engine_watch_established
   (reply=, error=, handle=0x55abea40, 
engine=0x556f3950)
   at ../engine/dconf-engine.c:963
#9  0x7275df09 in dconf_engine_watch_established
   (engine=0x556f3950, handle=0x55abea40, reply=, 
error=)
   at ../engine/dconf-engine.c:938
#10 0x72760bec in dconf_gdbus_method_call_done
   (source=, result=, 
user_data=user_data@entry=0x55abea40)
   at ../gdbus/dconf-gdbus-thread.c:254
#11 0x7756a719 in g_task_return_now (task=0x7fffe80651e0 [GTask]) at 
../../../gio/gtask.c:1148
#12 0x7756b196 in g_task_return (task=0x7fffe80651e0 [GTask], 
type=)
   at ../../../gio/gtask.c:1206
#13 0x775c0b1a in g_dbus_connection_call_done
--Type  for more, q to quit, c to continue without paging--
   (source=, result=0x7fffe804b840, 
user_data=user_data@entry=0x7fffe80651e0)
   at ../../../gio/gdbusconnection.c:5715
#14 0x7756a719 in g_task_return_now (task=0x7fffe804b840 [GTask]) at 
../../../gio/gtask.c:1148
#15 0x7756a759 in complete_in_idle_cb (task=0x7fffe804b840) at 
../../../gio/gtask.c:1162
#16 0x77355dd8 in g_main_dispatch (context=0x55717a00) at 
../../../glib/gmain.c:3182
#17 0x77355dd8 in g_main_context_dispatch 
(context=context@entry=0x55717a00) at ../../../glib/gmain.c:3847
#18 0x773561c8 in g_main_context_iterate
   (context

Bug#929069: rename: description references rename in perl package, which has gone

[Jonathan Dowland]

Package: rename
Version: 1.10-1
Severity: minor

Quoting description

> Description: Perl extension for renaming multiple files
>  This package provides both a perl interface for renaming files
>  (File::Rename) and a command line tool 'rename' which is intended to
>  replace the version currently supplied by the perl package.

perl 5.28.1-6 (Buster) does not include rename any more.

(I installed this package hoping it was a drop-in replacement but
"rename -nv" does not work :/)

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rename depends on:
ii  perl  5.28.1-6

rename recommends no packages.

rename suggests no packages.

-- no debconf information

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

Hi Michael,

Thank you for sharing your take.

On Sat, May 11, 2019 at 11:21:22AM +0200, Michael Biebl wrote:

Then there is the case, that I sometimes need to use software like
teamviewer (I know, bad proprietary software), which is not Wayland
ready. I need something cross-plattform though, and I'm not aware of
another solution which runs on top of Wayland.


I think we should have some sympathy towards users of non-free software
on top of Debian, even if we aren't packaging it. Pragmatically many of
our users rely on it or want it. E.g. NVIDIA driver users, Google Chrome,
Steam… and IMHO we further our goals if we are sensitive to their needs
rather than making life harder for them.


Incidentally, I was the one responsible for switching back the default
to Xorg in stretch and the main reasons which guided my decision back
then mostly still apply today.


I thought you might have been, I started reading the git log of some
packages to try and figure out what patch would need to be written, I
saw your name in (I think) gdm3 (I haven't yet come up with a working
patch but this gave me some clues thank you)


That said, I'm no longer an active GNOME team member and haven't really
done any GNOME related work during the buster development cycle.


I hadn't realised you were no longer active in the GNOME team. I hope
you are still active in Debian :-) I've always enjoyed interacting with
you (and you may not remember but I think we met at DebConf '07)


And I'm convinced, that the people doing the work should decide.


Mostly agree :-)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#928751: cryptsetup-bin: description claims provides luksformat, which moved to cryptsetup-run

[Jonathan Dowland]

See attached, or
<https://salsa.debian.org/cryptsetup-team/cryptsetup/merge_requests/9>


Thanks

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.
commit fb673db9b8554375a388ba41eae8a3529b7911f8
Author: Jonathan Dowland 
Date:   Mon May 13 10:43:52 2019 +0100

Update descriptions to reflect move of luksformat

diff --git a/debian/changelog b/debian/changelog
index d7e31ad3..61ffc795 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+cryptsetup (2:2.2.0~rc0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update package descriptions to reflect the move of luksformat
+from cryptsetup-bin to cryptsetup-run. Closes: #928751.
+
+ -- Jonathan Dowland   Mon, 13 May 2019 10:43:09 +0100
+
 cryptsetup (2:2.2.0~rc0-1) experimental; urgency=low
 
   * New /testing/ upstream release 2.2.0 RC0.  Highlights include:
diff --git a/debian/control b/debian/control
index c09b080b..70cbc973 100644
--- a/debian/control
+++ b/debian/control
@@ -51,6 +51,9 @@ Description: disk encryption support - startup scripts
  automatically configuring encrypted devices at boot time via the config
  file /etc/crypttab. Additional features are cryptoroot support through
  initramfs-tools and several supported ways to read a passphrase or key.
+ .
+ This package provides the cryptdisk_start and stop wrappers and
+ luksformat.
 
 Package: cryptsetup-bin
 Architecture: linux-any
@@ -61,7 +64,8 @@ Description: disk encryption support - command line tools
  device mapper target dm-crypt. It features integrated Linux Unified Key
  Setup (LUKS) support.
  .
- This package provides cryptsetup, cryptsetup-reencrypt and luksformat.
+ This package provides cryptsetup, cryptsetup-reencrypt, integritysetup
+ and veritysetup.
 
 Package: cryptsetup-initramfs
 Architecture: all

Bug#928046: ~ Re: Bug#928046: dosbox: input issues under Wayland (some keys not behaving)

[Jonathan Dowland]

Hi all

On Sat, May 11, 2019 at 11:36:00AM +, Niels Thykier wrote:

Have you tried Stephen's suggestion of setting "usescancodes" and see if
that fixes the issue?


I hadn't, until now, but I can now confirm that this does resolve the issue.


Thanks,

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#928751: cryptsetup-bin: description claims provides luksformat, which moved to cryptsetup-run

[Jonathan Dowland]

Package: cryptsetup-bin
Version: 2:2.1.0-3
Severity: normal

the long description for cryptsetup-bin claims it provides the
luksformat binary, but that appears to have moved to the cryptsetup-run
package, which doesn't mention it at all.


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.19.0-1-amd64 root=/dev/mapper/qusp_vg-buster ro quiet

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
# / was on /dev/sda during installation
UUID=5fab5fb3-349e-4dcc-abe3-a7eb5609c268 /   ext4
errors=remount-ro 0   1
UUID=c1d5f76c-1efb-4e94-9aec-8eb09806674f /boot   ext2defaults  
  0   2
UUID=F944-299E  /boot/efi   vfatumask=0077  0   1

/dev/mapper/qusp_vg-home /home  ext4defaults,discard,nofail 
0   2

# swap was on /dev/sdb2 during installation
#UUID=c614fca4-bd88-41c4-879b-387b346d8e58 noneswapsw,nofail
  0   0
/dev/mapper/qusp_vg-swap noneswapsw,nofail  0   0

/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

/dev/mapper/qusp_vg-root /stretch   ext4
errors=remount-ro,nofail 0   1

LABEL=data /data ext4 defaults,nofail,discard 0 2
none /var/lib/schroot/union/overlay tmpfs uid=root,gid=root,mode=0750 0 0
LABEL=cevm /media/cevm ext4 defaults,nofail,discard 0 2

-- lsmod
Module  Size  Used by
veth   24576  0
cdc_acm32768  0
snd_hrtimer16384  0
snd_seq_dummy  16384  0
snd_seq81920  1 snd_seq_dummy
snd_seq_device 16384  1 snd_seq
vhost_net  24576  1
vhost  49152  1 vhost_net
tap24576  1 vhost_net
hid_lenovo 20480  0
hidp   28672  0
hid_generic16384  0
usbhid 57344  0
hid   139264  4 hidp,usbhid,hid_generic,hid_lenovo
nf_conntrack_netlink49152  0
xfrm_user  40960  1
xfrm_algo  16384  1 xfrm_user
iptable_nat16384  1
xt_addrtype16384  2
iptable_filter 16384  1
br_netfilter   24576  0
overlay   126976  0
fuse  122880  3
ctr16384  4
ccm20480  6
rfcomm 86016  4
nft_chain_route_ipv416384  1
xt_CHECKSUM16384  1
nft_chain_nat_ipv4 16384  4
ipt_MASQUERADE 16384  2
nf_nat_ipv416384  3 ipt_MASQUERADE,nft_chain_nat_ipv4,iptable_nat
nf_nat 36864  1 nf_nat_ipv4
xt_conntrack   16384  2
nf_conntrack  163840  5 
xt_conntrack,nf_nat,ipt_MASQUERADE,nf_nat_ipv4,nf_conntrack_netlink
nf_defrag_ipv6 20480  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
crc32c_generic 16384  0
ipt_REJECT 16384  1
nf_reject_ipv4 16384  1 ipt_REJECT
nft_counter16384  25
xt_tcpudp  16384  2
nft_compat 20480  22
tun49152  7 vhost_net
bridge188416  1 br_netfilter
stp16384  1 bridge
llc16384  2 bridge,stp
devlink77824  0
snd_hda_codec_hdmi 57344  1
snd_hda_codec_realtek   118784  1
snd_hda_codec_generic86016  1 snd_hda_codec_realtek
nf_tables 143360  128 
nft_chain_route_ipv4,nft_compat,nft_chain_nat_ipv4,nft_counter
nfnetlink  16384  4 nft_compat,nf_conntrack_netlink,nf_tables
cmac   16384  1
bnep   24576  2
arc4   16384  2
binfmt_misc20480  1
uvcvideo  118784  0
videobuf2_vmalloc  16384  1 uvcvideo
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 28672  1 uvcvideo
videobuf2_common   53248  2 videobuf2_v4l2,uvcvideo
btusb  53248  0
btrtl  16384  1 btusb
btbcm  16384  1 btusb
btintel24576  1 btusb
videodev  212992  3 videobuf2_v4l2,uvcvideo,videobuf2_common
iwlmvm294912  0
media  45056  2 videodev,uvcvideo
wmi_bmof   16384  0
mac80211  819200  1 iwlmvm
bluetooth 643072  32 btrtl,hidp,btintel,btbcm,bnep,btusb,rfcomm
nls_ascii  16384  2
snd_soc_skl   118784  0
snd_soc_skl_ipc73728  1 snd_soc_skl
snd_soc_sst_ipc16384  1 snd_soc_skl_ipc
nls_cp437  20480  2
snd_soc_sst_dsp36864  1 snd_soc_skl_ipc
vfat   20480  2
intel_rapl 24576  0
snd_hda_ext_core   28672  1 snd_soc_skl
fat86016  1 vfat
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
drbg

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

severity 927667 serious
thanks

[ I wrote the following reply to smcv's last mail to this bug, but only
sent it to -desktop: 
https://lists.debian.org/debian-desktop/2019/05/msg0.html ]

Thanks to Simon for filing this bug in the first place and for engaging
in discussion about the issue.

My personal conclusion is that we, as a project, need to spend more time
carefully evaluating Wayland prior to it being the default desktop technology
for Debian, following the approach we have used for other major technologies
adopted by default (e.g. systemd). This hasn't happened for Wayland yet, and
I'm concerned that it may just not be quite ready (e.g. #928030, #928002).

I want an explicit ACK or NACK on this, and so I'm bumping severity so that
this bug can't languish past Buster release. Justification is the regression
in behavour wrt X11 (as documented in those two bugs amongst others) break
unrelated software. I'll interpret downgrading as being a NACK, but I would
*really* appreciate engagement instead of just bug severity changes.

Two ways of resolving this are: Either the default GNOME3 session in Debian
switched back to Xorg, or the default desktop session is switched away from
GNOME; but I would much prefer the former.


--
Jonathan Dowland

Bug#928115: zdbsp FTCBFS: confuses build vs. host

[Jonathan Dowland]

Thanks for the report, and the patch. It looks good to me, but as
we are in hard freeze for Buster and this (sadly) would not qualify
for a freeze exception, I'm going to wait before applying it or
uploading a fixed package to sid.


Best wishes

Bug#928046: dosbox: input issues under Wayland (some keys not behaving)

[Jonathan Dowland]

Package: dosbox
Version: 0.74-2-3
Severity: normal

Under GNOME/Wayland, when I launch DOOM2.EXE under DOSBOX, the arrow keys are
not recognised. Other keys are (ESC in particular works) and I can type
alphanumeric keys w/o error. DOOM relies upon raw keyboard input from DOS.

Logging into GNOME/Xorg and the problem goes away.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 dosbox depends on:
ii  libasound2   1.1.8-1
ii  libc62.28-8
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libpng16-16  1.6.36-5
ii  libsdl-net1.21.2.8-6
ii  libsdl-sound1.2  1.0.3-9
ii  libsdl1.2debian  1.2.15+dfsg2-4
ii  libstdc++6   8.3.0-6
ii  libx11-6 2:1.6.7-1
ii  zlib1g   1:1.2.11.dfsg-1

dosbox recommends no packages.

dosbox suggests no packages.

-- no debconf information
# This is the configurationfile for DOSBox 0.74. (Please use the latest version 
of DOSBox)
# Lines starting with a # are commentlines and are ignored by DOSBox.
# They are used to (briefly) document the effect of each option.

[sdl]
#   fullscreen: Start dosbox directly in fullscreen. (Press ALT-Enter to go 
back)
#   fulldouble: Use double buffering in fullscreen. It can reduce screen 
flickering, but it can also result in a slow DOSBox.
#   fullresolution: What resolution to use for fullscreen: original or fixed 
size (e.g. 1024x768).
# Using your monitor's native resolution with aspect=true 
might give the best results.
# If you end up with small window on a large screen, try an 
output different from surface.
# windowresolution: Scale the window to this size IF the output device supports 
hardware scaling.
# (output=surface does not!)
#   output: What video system to use for output.
#   Possible values: surface, overlay, opengl, openglnb.
# autolock: Mouse will automatically lock, if you click on the screen. 
(Press CTRL-F10 to unlock)
#  sensitivity: Mouse sensitivity.
#  waitonerror: Wait before closing the console if dosbox has an error.
# priority: Priority levels for dosbox. Second entry behind the comma 
is for when dosbox is not focused/minimized.
# pause is only valid for the second entry.
#   Possible values: lowest, lower, normal, higher, highest, 
pause.
#   mapperfile: File used to load/save the key/event mappings from. 
Resetmapper only works with the defaul value.
# usescancodes: Avoid usage of symkeys, might not work on all operating 
systems.

fullscreen=false
fulldouble=true
fullresolution=original
windowresolution=1024x768
output=opengl
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-0.74.map
usescancodes=true

[dosbox]
# language: Select another language file.
#  machine: The type of machine tries to emulate.
#   Possible values: hercules, cga, tandy, pcjr, ega, vgaonly, svga_s3, 
svga_et3000, svga_et4000, svga_paradise, vesa_nolfb, vesa_oldvbe.
# captures: Directory where things like wave, midi, screenshot get captured.
#  memsize: Amount of memory DOSBox has in megabytes.
# This value is best left at its default to avoid problems with 
some games,
# though few games might require a higher value.
# There is generally no speed advantage when raising this value.

language=
machine=svga_s3
captures=capture
memsize=16

[render]
# frameskip: How many frames DOSBox skips before drawing one.
#aspect: Do aspect correction, if your output method doesn't support 
scaling this can slow things down!.
#scaler: Scaler used to enlarge/enhance low resolution modes.
#  If 'forced' is appended, then the scaler will be used even if 
the result might not be desired.
#Possible values: none, normal2x, normal3x, advmame2x, advmame3x, 
advinterp2x, advinterp3x, hq2x, hq3x, 2xsai, super2xsai, supereagle, tv2x, 
tv3x, rgb2x, rgb3x, scan2x, scan3x.

frameskip=0
aspect=false
scaler=normal2x

[cpu]
#  core: CPU Core used in emulation. auto will switch to dynamic if 
available and appropriate.
#Possible values: auto, dynamic, normal, simple.
#   cputype: CPU Type used in emulation. auto is the fastest choice.
#Possible values: auto, 386, 386_slow, 486_slow, pentium_slow, 
386_prefetch.
#cycles: Amount of instructions DOSBox tries to emulate each millisecond.
#Setting this value too high results in sound dropouts and lags.
#Cycles can be set in 3 ways:
#  

Bug#904309: appropriate priority for bugs under Wayland?

[Jonathan Dowland]

severity 904309 normal
thanks

Folks, I've seen a few occurences now of bugs like this which are being given
RC severity because Wayland is currently the default desktop technology for
Buster. The consequence of this is that the software (here tilda, elsewhere
synaptic, and perhaps others) are at risk of being dropped from Buster
entirely due to incompatibility under Wayland, despite working fine under X.

I'm not sure that this is fair or the right way to address issues of Wayland
compatibility with other (longer established) software. I'm directing this at
-release to ask the Release Team whether they have a position on the matter.
Thanks!

Related I'm not sure that Wayland is a suitable choice for the default desktop
technology yet either (see Bug #927667 for discussion of that, as well as a
subset of these bugs[1]). Please direct any thoughts on *that* to #927667
rather than here.

[1] 
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=wayland=pkg-gnome-maintainers%40lists.alioth.debian.org


Best wishes

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.