Bug#1053713: webkit2gtk: Build with ENABLE_PDFJS=OFF?

[Markus Demleitner]

Source: webkit2gtk
Version: 2.40.3-2~deb12u1
Severity: wishlist

Dear Maintainer,

Recent webkits force PDF rendering in the browser using pdf.js.

To me, this is a pain for several reasons, including pdf.js not
having my usual PDF viewer's key bindings, and PDF rendering being
entirely broken on sites I have disabled javascript for (i.e.,
almost all of them).  Regrettably, as far as I can tell, at this
point there is no way to turn off pdf.js at runtime.

I suspect the sort of person that is running webkit-based
browsers will typically have configured some PDF reader they like
as well and will hence likely be about as annoyed if their browser
ignores that choice as I am.

Given that, the lack of a runtime switch, and the fact that
building a webkit package takes the better part of a day on
my box: Any chance you could build with ENABLE_PDFJS=OFF at
least until upstream fiddles in a runtime switch?

Thanks,

   Markus


-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 6.1.38 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Bug#1053552: gavodachs2-server: Error while setting up with postgresql 16

[Markus Demleitner]

On Fri, Oct 06, 2023 at 09:56:41AM +0200, Ole Streicher wrote:
> 108s   alter role untrusted set extra_float_digits=3
> 108s
> 108s The database engine reported:
> 108s
> 108s   ERROR:  permission denied to alter role
> 108s DETAIL:  Only roles with the CREATEROLE attribute and the ADMIN option
> 108s on role "untrusted" may alter this role.
>
> I don't think that has anything to do with the astropy update. This
> seems to be connected to Postgresql version (16.0-2); a similar install
> (with Postgresql 15.4-3) succeeded.

Oh bother.  Yeah, that's unrelated to astropy and absolutely related
to increasingly tight rules in postgres.  I'll think about a
workaround (to restore this workaround) on Monday.

-- Markus

Bug#1043266: python3-mypy: stub error message could point to python3-typeshed package

[Markus Demleitner]

Package: python3-mypy
Version: 1.0.1-1
Severity: minor

Dear Maintainer,

When mypy notices missing stubs for a package that has stubs on typeshed, it
currently writes something like:

  utils/imgtools.py:17: error: Library stubs not installed for "PIL"  [import]
  utils/imgtools.py:17: note: Hint: "python3 -m pip install types-Pillow"
  utils/imgtools.py:17: note: (or run "mypy --install-types" to install all
missing stub packages)
  utils/imgtools.py:17: note: See
https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports

-- both recommendations are arguably wrong when the package-installed mypy runs
(and hence it stands to reason that it's the Debian-managed python running).
So, perhaps this message could be changed to

  Hint: On Debian systems, you can install the python3-typeshed package to
provide mypy with stubs for many popular libraries.  In virtual python
environments, you can instead run mypy --install-types for upstream stubs.

or something similar?


-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldstable-updates'), (500, 
'stable')
Architecture: i386 (x86_64)

Kernel: Linux 6.1.38 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python3-mypy depends on:
ii  libc6  2.36-9+deb12u1
ii  python33.11.2-1+b1
ii  python3-mypy-extensions0.4.3-4
ii  python3-pkg-resources  66.1.1-1
ii  python3-psutil 5.9.4-1+b1
ii  python3-typing-extensions  4.4.0-1

Versions of packages python3-mypy recommends:
ii  python3-lxml4.9.2-1+b1
ii  python3-setuptools  66.1.1-1

python3-mypy suggests no packages.

-- no debconf information

Bug#1042825: postgresql-common: pg_upgrade dumps diagnostics into new cluster and then drops it

[Markus Demleitner]

Package: postgresql-common
Version: 248
Severity: normal

Dear Maintainer,

I'm trying to run pg_upgradecluster to go from 13 to 15 like this:

pg_upgradecluster -k -m upgrade -v 15 13 main

This currently fails on my installation with the following text in
the terminal:


Checking for presence of required libraries fatal

Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
/var/lib/postgresql/15/main/pg_upgrade_output.d/20230801T145458.309/loadable_libraries.txt

Failure, exiting
Error: pg_upgrade run failed. Logfiles are in
/var/log/postgresql/pg_upgradecluster-13-15-main.tggb
Error during cluster dumping, removing new cluster


The trouble with that is: loadable_libraries.txt is itself below
/var/lib/postgresql/15 and is hence dropped with the (broken) new cluster,
and hence the file is gone by the time mere humans read the message.

Is there a special reason why loadable_libraries.txt is not dumpted into
the ordinary log directory?


-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldstable-updates'), (500, 
'stable'), (500, 'oldstable')
Architecture: i386 (x86_64)

Kernel: Linux 6.1.38 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages postgresql-common depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libjson-perl   4.1-1
ii  lsb-base   11.6
ii  perl   5.36.0-7
ii  postgresql-client-common   248
ii  ssl-cert   1.1.2
ii  sysvinit-utils [lsb-base]  3.06-4
ii  ucf3.0043+nmu1

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.47.0-2
ii  logrotate  3.21.0-1

postgresql-common suggests no packages.

-- debconf information:
* postgresql-common/obsolete-major:
  postgresql-common/untransitioned:
* postgresql-common/ssl: true
  postgresql-common/catversion-bump:

Bug#1012746: Holds, if differently, on bookworm and later libwebkit2gtk-s

[Markus Demleitner]

With bookworm, things have significantly changed; it seems webkit2gtk
is now pretty much broken on non-local displays, but then the
crashes are somewhat milder.

I believe the easiest webkit client to investigate the problem in is
surf, where the raw symptom is:

  $ ssh -X  surf http://www.debian.org
  libEGL warning: DRI2: failed to authenticate

  (WebKitWebProcess:498): Gdk-WARNING **: 13:11:26.540: The program 
'WebKitWebProcess' received an X Window System error.
  This probably reflects a bug in the program.
  The error was 'BadRequest (invalid request code or no such operation)'.
(Details: serial 173 error_code 1 request_code 154 (unknown) minor_code 1)
(Note to programmers: [...])
  web process terminated: crashed

Regrettably, this time I can't get the WebKitWebProcess to dump core
-- is there a simple knob to make it do that on a X error?  As
usual, the things die faster than you could attach to them.

On the plus side, it seems the crashes are now a fairly solid feature
that I'm seeing independent of particular screens on particular
graphics cards.

Oh, and, Good News: with WEBKIT_DISABLE_COMPOSITING_MODE=1 things are
just fine:

  $ ssh -X  env WEBKIT_DISABLE_COMPOSITING_MODE=1 surf 
http://www.debian.org

works in every combination I've tried.  If you say "live with
disabling compositing mode" I suppose I could live with closing this
bug.

Bug#1040630: gavodachs autopkg tests fail with pillow 10.0.0

[Markus Demleitner]

On Sat, Jul 08, 2023 at 09:23:21AM +0200, Matthias Klose wrote:
> 110s From it/q:
> 110s  ERROR SCS has a valid response
> 110s  ERROR TAP query with pgsphere yields plausible result

Interesting -- this fails because the server that's being tested
does not come up because:

  module 'PIL.Image' has no attribute 'ANTIALIAS'

And indeed, it does not:

  >>> from PIL import Image
  >>> Image.ANTIALIAS
  Traceback (most recent call last):
File "", line 1, in 
  AttributeError: module 'PIL.Image' has no attribute 'ANTIALIAS'

Now... this seems to be a fairly breaking change (or at least I
suspect there's a lot of code with Image.ANTIALIAS out there).
However, when looking for resize or ANTIALIAS in the upstream
changelog, I don't see it mentioned:
https://github.com/python-pillow/Pillow/blob/main/CHANGES.rst

That made me curious; ANTIALIAS as an alias of LANCZOS was dropped in
upstream commit f8e4e9c2dd94c6f4789639dd891b8a6d5fb16e14 with the
terse commit message "Added enums", where there's this:

  ...
  -LANCZOS = ANTIALIAS = 1

  -_filters_support = {BOX: 0.5, BILINEAR: 1.0, HAMMING: 1.0, BICUBIC: 2.0, 
LANCZOS: 3.0}
  +# resampling filters (also defined in Imaging.h)
  +class Resampling(IntEnum):
  +NEAREST = 0
  +BOX = 4
  +BILINEAR = 2
  +HAMMING = 5
  +BICUBIC = 3
  +LANCZOS = 1

Whether dropping the widely-documented ANTIALIAS alias was done
deliberately or not I can't say.  And hence I'll not decide whether or
not that's worth an upstream bug.  Instead, I'lljust move to LANCZOS
in DaCHS.

DaCHS users: if you urgently need the package on unstable, please use
our beta repo (https://soft.g-vo.org/repo) for the time being.
Release 2.8 wasn't our best one anyway.  Release 2.9 ought to come
around October-ish anyhow, at which time I'll close this bug (or
should be reminded to close it).

Bug#1002718: Password prompt

[Markus Demleitner]

Any news on this?  I'd still need to have some reproducer...

And could you try it with DaCHS 2.7 in current stable?

Bug#1027213: gavodachs: autopkgtest fail with numpy/1.24.1

[Markus Demleitner]

On Sun, Jan 08, 2023 at 03:51:47PM -0400, Stefano Rivera wrote:
> Control: tag -1 + patch
> 
> I haven't tested this beyond the autopkgtest, but it seems to work, so
> I'll NMU it.

I'd be fine with the patch, as it won't actually break anything that
hasn't been broken already, but I have already prepared a fix
in , waiting
for an upload (delayed because of holidays, I suspect).  So, if
you have not uploaded yet, I'd prefer that fix to go into the
archive.  Otherwise, as I said, I'm fine with your patch too, for the
time being.

Thanks!

Markus

Bug#1002718: Password prompt

[Markus Demleitner]

Marc,

Sorry for the late reaction -- regrettably, there's no notification
on bug reassignment, and I didn't get notified on the original bug
submission because of the wrong package name.

DaCHS is being installed with non-interacive dpkg all the time
(e.g., when building containers), so this must have some other
reason than non-interactivity.  I'm not aware of any way to make su
ask root for a password.  That would make me suspect that the
maintainer script would somehow run as a non-root user in your setup.
Is there anything magic on your system that might cause this?

[Btw, the su is necessary here to create and configure the database
and then to initialise the DaCHS environment with permissions that
won't cause too much grief later.  But there is certainly no
expectation that anyone would ever provide passwords to these su-s,
in particular considering that the dachsroot account does not even
have one at installation time]

Bug#1027398: gavodachs: autopkgtest needs update for new version of python-cryptography: fails to install

[Markus Demleitner]

On Fri, Dec 30, 2022 at 10:13:45PM +0100, Paul Gevers wrote:
> *** Error: Oops.  Unhandled exception AttributeError.
> 
> Exception payload: module 'lib' has no attribute
> 'SSL_CTX_set_ecdh_auto'

While DaCHS doesn't do a good job of communicating this, the
regression is actually within python3-openssl and python3-twisted.
There's a test case in python3-twisted that looks like it is
exercising the failing code.  I have tried to locate a corresponding
bug against twisted, but I have not been able to locate it.  Is there
any action I should take to alert the maintainers of the two packages?

Bug#1020404: luakit: aborts at start

[Markus Demleitner]

On Wed, Sep 21, 2022 at 11:36:08AM +0200, Arne Wichmann wrote:
> Bail out! ERROR:common/util.c:67:strip_ansi_escapes: assertion failed (err == 
> NULL): Error while compiling regular expression 
> ?[\u001b\u009b][[()#;?]*(?:[0-9]{1,4}(?:;[0-9]{0,4})*)?[0-9A-ORZcf-nqry=><]? 
> at char 3: unrecognised character following \ (g-regex-error-quark, 103)

Argl.  That's quite certainly the upstream bug
https://github.com/luakit/luakit/issues/1005

I've not commented on this because I was not really sure what
encoding the gchar *in would be -- if it's UCS-2, then the
complicated \u escapes make sense.  If it's UTF-8, a simple \x1b
would do the job.

Even more importantly, looking at where this code is being used (when
formatting tracebacks, and when writing via va_log when things are
going to a file), I'm now convinced that this is a lot less critical
than I first thought.  In particular, javascript console.log is *not*
sanitised at all, let alone by this code; to see that, run

  luakit http://www.tfiu.de/log-escape.html |& cat

(if you still have a running luakit somewhere) -- you'll see that the
colored messages are now b/w, but the escape sequence from javascript
is not filtered (which would feel like a good idea), so you end up
with a terminal writing in reverse video.

I hence felt it's ok to just experiment, and it seems we're talking
about UTF-8 strings here.

Can you build from https://salsa.debian.org/debian/luakit.git and see
whether the thing (a) builds and (b) whether luakit's log messages
are b/w when filtered through cat as above?

Thanks,

   Markus

Bug#1012746: libwebkit2gtk-4.0-37: 2.36.3-1~deb11u1 fails messily over glx

[Markus Demleitner]

Given the publicity of some recent webkit bugs I start getting mildly
nervous about the outdated webkit on my box.  After the latest update
didn't improve things, I started poking a bit more, and it turns out
that the bug title was *very much* over-generalising.

The crashes very specifically occur on one screen of a two-screen
"ZaphodHeads" setup on nouveau.  It is actually the case that

DISPLAY=display-host:0.0 luakit

runs just fine, whereas

DISPLAY=display-host:0.1 luakit

shows the crashes.

I have to admit this badly stumps me.

I'm still reluctant to delve into either of webkit or nouveau, so...
does someone perhaps have a theory what might possibly cause such a
thing that I could try before I start digging?

Bug#1012746: libwebkit2gtk-4.0-37: 2.36.3-1~deb11u1 fails messily over glx

[Markus Demleitner]

When 2.34.6-1~deb11 came along on Aug 16, I had great hopes it might
accidentally fix this, too -- but alas, it didn't.

Bug#1012746: libwebkit2gtk-4.0-37: 2.36.3-1~deb11u1 fails messily over glx

[Markus Demleitner]

On Tue, Jun 21, 2022 at 10:46:53AM +, Alberto Garcia wrote:
> If the web process crashes and you have the systemd-coredump package
> you should be able to see the core dump with coredumpctl.

Oh, right: WebKitWebProcess does indeed coredump once I ulimit -c
unlimited.  Here's a dump (I've not pulled the dbgsyms for GLX, X11,
gdk, and glib, hoping they're irrelevant for the problem at hand):

#0  0xf3b1d15b in g_log_writer_default ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#1  0xf3b1b2d8 in g_log_structured_array ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#2  0xf3b1bcc9 in g_log_structured_standard ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#3  0xf1eac916 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#4  0xf1eb9fb4 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#5  0xf0c5b208 in _XError () from /usr/lib/i386-linux-gnu/libX11.so.6
#6  0xeae96c62 in ?? () from /usr/lib/i386-linux-gnu/libGLX_mesa.so.0
#7  0xeae8fac8 in ?? () from /usr/lib/i386-linux-gnu/libGLX_mesa.so.0
#8  0xf17b1e24 in ?? () from /usr/lib/i386-linux-gnu/libGLX.so.0
#9  0xf6420528 in createGLXARBContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:109
#10 0xf6421fdf in WebCore::GLContextGLX::createWindowContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:195
#11 0xf6423f5b in WebCore::GLContextGLX::createContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:280
#12 0xf63d49b7 in WebCore::GLContext::createContextForWindow ()
at ../Source/WebCore/platform/graphics/GLContext.cpp:97
#13 0xf478b73b in WebKit::ThreadedCompositor::createGLContext ()
at 
../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:96
--Type  for more, q to quit, c to continue without paging--
#14 0xf478b86f in operator() ()
at 
../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:73
#15 call () at WTF/Headers/wtf/Function.h:53
#16 0xf4789bc7 in WTF::Function::operator()() const ()
at WTF/Headers/wtf/Function.h:82
#17 operator() ()
at 
../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp:90
#18 call () at WTF/Headers/wtf/Function.h:53
#19 0xf36f845f in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#20 0xf37588e8 in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#21 0xf375941c in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#22 0xf3b147a4 in g_main_context_dispatch ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#23 0xf3b14b69 in ?? () from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#24 0xf3b14ec1 in g_main_loop_run ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#25 0xf3759581 in WTF::RunLoop::run() ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#26 0xf478860c in operator() ()
at 
../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp:49
#27 call () at WTF/Headers/wtf/Function.h:53
#28 0xf36fad99 in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#29 0xf375c0c8 in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#30 0xf088b0b4 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#31 0xf3feb296 in clone () from /lib/i386-linux-gnu/libc.so.6

Thanks,

 Markus

Bug#1012746: libwebkit2gtk-4.0-37: 2.36.3-1~deb11u1 fails messily over glx

[Markus Demleitner]

On Tue, Jun 14, 2022 at 01:33:34PM +, Alberto Garcia wrote:
> I gave this a quick try using a VM and I can open luakit and midori
> just fine, with both WebKit versions... I'll try to see if I can
> reproduce this on a different computer.

Well, given that I just tried to get a trackback and discovered
that's harder than just following the advice and running

  ssh -tX  env GDK_SYNCHRONIZE=1 gdb luakit

and breaking on gdk_x_error; I figure it's because that breakpoint is
never reached in the UI process, only in the WebKitWebProcess.
A quick web search hasn't brought up quick advice on how to debug
things in there -- is there a quick howto somewhere?

Thanks,

  Markus

Bug#1012746: libwebkit2gtk-4.0-37: 2.36.3-1~deb11u1 fails messily over glx

[Markus Demleitner]

Package: libwebkit2gtk-4.0-37
Version: 2.36.3-1~deb11u1
Severity: normal
X-Debbugs-Cc: t...@security.debian.org

Dear Maintainer,

After the update to 2.36.3-1~deb11u1, webkit-using clients like luakit
or midori do not work any more through ssh-forwarded X connections (as in
ssh -X  luakit).  The clients emit messages like:

(WebKitWebProcess:8867): Gdk-ERROR **: 10:24:22.799: The program 
'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 220 error_code 8 request_code 151 (GLX) minor_code 34)

[plus the lecture on going sync to get backtraces, which I'll happily do
if there's any problem reproducing this] repeated a couple of times per second,
whereas in the syslog, one gets messages like:

traps: eadedCompositor[8752] trap int3 ip:f3b7315b sp:e9dfe480 error:0 
in libglib-2.0.so.0.6600.8[f3b33000+8b000]

again at a few Hertz, where the number in square brackets (the PID, I guess) 
quickly counts up.

Downgrading to 2.34.6-1~deb11u1 fixes things.

In both luakit and midori, the visible effect is that no webpage is displayed
(but the clients' UIs are properly drawn).

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  bubblewrap  0.4.1-3
ii  gstreamer1.0-plugins-base   1.18.4-2
ii  gstreamer1.0-plugins-good   1.18.4-2
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-13+deb11u3
ii  libcairo2   1.16.0-5
ii  libegl1 1.3.2-1
ii  libelogind0 [libsystemd0]   246.9.1-1+debian1
ii  libenchant-2-2  2.2.15-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-6
ii  libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii  libglib2.0-02.66.8-1
ii  libglx0 1.3.2-1
ii  libgstreamer-gl1.0-01.18.4-2
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libgtk-3-0  3.24.24-4+deb11u2
ii  libharfbuzz-icu02.7.4-1
ii  libharfbuzz0b   2.7.4-1
ii  libhyphen0  2.8.8-7
ii  libicu6767.1-7
ii  libjavascriptcoregtk-4.0-18 2.36.3-1~deb11u1
ii  libjpeg62-turbo 1:2.0.6-4
ii  liblcms2-2  2.12~rc1-2
ii  libmanette-0.2-00.2.5-1
ii  libnotify4  0.7.9-3
ii  libopengl0  1.3.2-1
ii  libopenjp2-72.4.0-3
ii  libpango-1.0-0  1.46.2-3
ii  libpng16-16 1.6.37-3
ii  libseccomp2 2.5.1-1+deb11u1
ii  libsecret-1-0   0.20.4-2
ii  libsoup2.4-12.72.0-2
ii  libsqlite3-03.34.1-3
ii  libstdc++6  10.2.1-6
ii  libtasn1-6  4.16.0-2
ii  libwayland-client0  1.18.0-2~exp1.1
ii  libwayland-egl1 1.18.0-2~exp1.1
ii  libwayland-server0  1.18.0-2~exp1.1
ii  libwebp60.6.1-2.1
ii  libwebpdemux2   0.6.1-2.1
ii  libwoff11.0.2-1+b1
ii  libwpe-1.0-11.10.0-2
ii  libwpebackend-fdo-1.0-1 1.8.0-1
ii  libx11-62:1.7.2-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxml2 2.9.10+dfsg-6.7+deb11u2
ii  libxslt1.1  1.1.34-4
ii  xdg-dbus-proxy  0.1.2-2
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

Versions of packages libwebkit2gtk-4.0-37 recommends:
pn  gstreamer1.0-gl   
pn  gstreamer1.0-libav
pn  gstreamer1.0-plugins-bad  
ii  libgl1-mesa-dri   20.3.5-1
ii  xdg-desktop-portal-gtk1.8.0-1

Versions of packages libwebkit2gtk-4.0-37 suggests:
pn  gstreamer1.0-alsa  

-- no debconf information

Bug#1010863: streamlink: Broken audio timestamps on arte.tv

[Markus Demleitner]

On Wed, May 18, 2022 at 02:09:47AM +0200, Alexis Murzeau wrote:
> Le 18/05/2022 à 01:42, Alexis Murzeau a écrit :
> > Le 17/05/2022 à 20:06, Alexis Murzeau a écrit :
> >> [...]
> > 
> > => So really the only option to use ffmpeg v5.x
> > 
> > 
> In Debian ffmpeg v5.0 is only in experimental, but you can try upstream
> linux binaries.

Getting the static binaries was what I did to solve my problem; in
case someone drops in here who uses the python API: you need to go
through a session, I guess; my code looks like this: 

options = {}
fallback_path = "/usr/local/ffmpeg/ffmpeg"
if os.path.exists(fallback_path):
options["ffmpeg-ffmpeg"] = fallback_path

session = streamlink.Streamlink(options or None)
streams = session.streams(url)

Thanks a lot for all that research -- I'm impressed how much I don't
understand about today's video containers...

I'm not sure whether to close this bug ("not streamlink's bug, and
it's well understood") or whether to keep it open because people
might miss it when it's closed, and I guess the problem won't go away
in bullseye.

I'm fine either way.  Thanks again!

Bug#1010863: streamlink: Broken audio timestamps on arte.tv

[Markus Demleitner]

Package: streamlink
Version: 3.2.0-1~bpo11+1
Severity: normal

Dear Maintainer,

When pulling video from arte, e.g.,

streamlink --output o.mp4 \
  https://www.arte.tv/de/videos/108210-039-A/mit-offenen-karten-im-fokus/ \
  worst

the audio timestamps for the resulting video file are broken for me (since
fairly recently), which leads to various failures in different clients (mpv has
seconds of hanging videos, vlc has stutters, webkit goes all haywire).

Upstream says it's not a streamlink problem, 
https://github.com/streamlink/streamlink/issues/4520;
I've suspected ffmpeg and so backported ffmpeg 4.4 -- to no avail.
I've also tried a uupdated streamlink 4 -- same result, broken
timestamps.

So... while I don't doubt upstream's analysis that it's not a streamlink
bug per se that's causing the bad timestamps, I don't know what else is.
I'm grateful for hints on what that might be -- and reports on whether
other people see the broken timestamps, too.

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

Kernel: Linux 5.16.19 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages streamlink depends on:
ii  python3 3.9.2-3
ii  python3-streamlink  3.2.0-1~bpo11+1

Versions of packages streamlink recommends:
ii  mpv  0.32.0-3
ii  vlc  3.0.16-1

streamlink suggests no packages.

-- no debconf information

Bug#985820: python3-cryptography: Core dump in buster openssl binding

[Markus Demleitner]

On Fri, Apr 09, 2021 at 11:34:54AM +0200, Markus Demleitner wrote:
> Since this appears to be a known problem, there's reason to hope
> it will go away when moving to bullseye, disabling https upgrading

Well, it didn't, and I finally wanted to have https on that service,
and so I had another look.  It turns out that the twisted bug
https://twistedmatrix.com/trac/ticket/9764 now has a bit more
information.  It is still somewhat unfulfilling, as nobody seems to
want to work out where the invalid free() comes from, but at least
there's a recipe to work around the bug.

Me, I'm disabling session caching for now.  Twisted seems to do the
same thing.  Since there *is* a severe, potentially exploitable
problem with session caching, perhaps this ought to be the default
in python3-openssl?

I'd be ok with closing this bug, anyway, as I'd say it's rather
clearly not python3-cryptography's own bug.

Bug#1005725: gavodachs2-server: fails to install with new python3-twisted.

[Markus Demleitner]

On Sun, Feb 13, 2022 at 11:57:56PM +, peter green wrote:
> > Exception payload: module 'twisted.web.template' has no attribute
> > '_ToStan'
> > dpkg: error processing package gavodachs2-server (--configure):
> >  installed gavodachs2-server package post-installation script subprocess 
> > returned error exit status 1
> 
> I attempted to fix that error (debdiff attatched), however it then
> failed with a "TypeError: 'Tag' object is not subscriptable", I
> modified the error handling to get a backtrace, but it didn't leave
> me any the wiser as to what the actual problem was.

The problem is a good deal deeper -- DaCHS needs some functionality
in the stan templates previously provided by nevow.  To have that, it
needs to patch template.Tag (and yes, someone should try to get
twisted.web have a configurable Tag class); that, however, has
changed its interface in subtle ways (and needs to be monkeypatched
in other places).

I *think* the patch at https://docs.g-vo.org/twisted-21-patch.txt
ought to do the trick, but since the postgres in my unstable
container keeps crashing on me right now, it's not properly tested
yet.

My plan right now would be to fix this in unstable by just packaging
release 2.6, which ought to happen in May 2022 and will contain the
patch (or whatever else).  If that's a major problem for someone,
speak up and I'll try to provide a more timely fix.

 -- Markus

Bug#1003926: ghostscript: ps2epsi broken because of bad LIBDIR

[Markus Demleitner]

Package: ghostscript
Version: 9.53.3~dfsg-7+deb11u2
Severity: normal

Dear Maintainer,

When running ps2epsi on any postscript file, it produces the error 
messsage:

Error: /undefinedfilename in (/usr/bin/ps2epsi.ps)

together with a stack trace.

This is because the script says

LIBDIR=`dirname $0`

which works out to /usr/bin in the Debian installation.   In the later
ghostscript invocation, this makes ghostscript look for ps2epsi.ps in
/usr/bin, which obviously cannot work.

Hacking

LIBDIR=/usr/share/ghostscript/9.53.3/lib/

into /usr/bin/ps2epsi fixes the problem.  Perhaps debian/rules can fiddle
something like that in?


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

Kernel: Linux 5.10.80 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ghostscript depends on:
ii  libc6   2.31-13+deb11u2
ii  libgs9  9.53.3~dfsg-7+deb11u2

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.53.3~dfsg-7+deb11u2

-- no debconf information

Bug#996772: luakit: Provide www-browser

[Markus Demleitner]

On Sat, Dec 04, 2021 at 01:21:18PM +0100, Bastian Germann wrote:
> Please fix https://salsa.debian.org/debian/luakit/-/jobs/2244789
> and I am going to sponsor.

Well, I've put in a rather sorry fix for the problem of
non-reproducible doc building.  I'm not proud of it at all, but at
least the hack is proposed by upstream, who are aware of the problem
(https://github.com/luakit/luakit/issues/975).

-- Markus

Bug#996772: luakit: Provide www-browser

[Markus Demleitner]

On Sat, Dec 04, 2021 at 01:21:18PM +0100, Bastian Germann wrote:
> Please fix https://salsa.debian.org/debian/luakit/-/jobs/2244789
> and I am going to sponsor.

Well, I would, if I could reproduce it; I've tried building in an
unstable-amd64 pbuilder three times, and it finished just fine every
time.  

Now, I remember having seen these doc building failures now and
then in the past, and I had hoped they were gone after a more careful
treatment of the lua-filesystem dependency, but alas, they aren't.
My working hypothesis is that it depends on the state of lua's hash
function, which could change the sequence in which the documents are
built.

I'll try to poke on this a bit more when I find time, and I'll
finally take this upstream, where someone with a bit more insight
into the doc building might immediately see the actual problem.

Meanwhile, I suspect just re-running the pipeline would hide the
problem for this round.  Ahem.

 -- Markus

Bug#996772: luakit: Provide www-browser

[Markus Demleitner]

On Fri, Dec 03, 2021 at 05:44:06PM +0100, Bastian Germann wrote:
> When will 1:2.3-1 be released?
> Note that you have referenced the change in a new -1.1 changelog
> entry even though -1 is not released yet.  I can offer sponsoring
> the release if you lack a sponsor.

My plan so far has been to wait for another upstream release, but
that of course was while I had forgotten that 2.3 was during the
bullseye freeze and hence didn't get uploaded.

So... what do I do with the changelog?  Squash the two entries?  With
the October timestamp?

And yes, I'm sure Ole (who's uploaded so far) will not be unhappy at
all if you sponsor the upload.

Bug#1000733: python-pygit2-doc: Generated parts of the documentation is missing

[Markus Demleitner]

Package: python-pygit2-doc
Version: 1.4.0+dfsg1-1
Severity: normal

Dear Maintainer,

The HTML generated in python-pygit2-doc is currently missing whatever the RST
autoclass text directive should produce.  See, for instance, in
html/repository.html the empty sections on "The Odb class" and "The Refdb
class", and compare with the expected
https://www.pygit2.org/repository.html

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

Kernel: Linux 5.10.80 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python-pygit2-doc depends on:
ii  libjs-sphinxdoc  3.4.3-2
ii  sphinx-rtd-theme-common  0.5.1+dfsg-1

python-pygit2-doc recommends no packages.

python-pygit2-doc suggests no packages.

-- no debconf information

Bug#987784: luakit: Luakit should provide more information why it does not like a certificate

[Markus Demleitner]

On Thu, Apr 29, 2021 at 02:45:09PM +0200, Arne Wichmann wrote:
> In the typical case when that happens, I want to find out what is wrong in
> more detail. Including a link to a summary of the certificate data would be
> very helpful.

I agree that UI could do with some improvement, and there's the
upstream bug https://github.com/luakit/luakit/issues/934 that has a
fairly similar drift.  I won't hold my breath for someone to actually
address it, though.

 -- Markus

Bug#996772: luakit: Provide www-browser

[Markus Demleitner]

On Mon, Oct 18, 2021 at 02:55:37PM +0200, Bastian Germann wrote:
> Package: luakit
> Severity: wishlist
> 
> luakit should provide the virtual package www-browser to help finding it
> when searching for a browser.

Good point.  I've added a corresponding line in commit edfd18d8, so
this should come with the next release.

 -- Markus

Bug#992030: ghostscript: ps2epsi does not find ps2epsi.ps any more

[Markus Demleitner]

Package: ghostscript
Version: 9.53.3~dfsg-7
Severity: normal

Dear Maintainer,

In bullseye, the ps2epsi script appears broken.  ps2epsi something.ps
invariably ends in

  Error: /undefinedfilename in (/usr/bin/ps2epsi.ps)

(and a ghostscript stack dump).

Looking into the script, this doesn't seem surprising, given it explicitly
says

# Note, we expect 'ps2epsi.ps' to be in the same directory as 'ps2epsi'

Indeed, replacing the "$LIBDIR/ps2epsi.ps" in the next line with
/usr/share/ghostscript/9.53.3/lib/ps2epsi.ps restores functionality.
Well...  thinking again: just removing the "$LIBDIR/" and relying on
ghostscript's search path is fine, too.



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

Kernel: Linux 5.13.4-dirty (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ghostscript depends on:
ii  libc6   2.31-13
ii  libgs9  9.53.3~dfsg-7

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.53.3~dfsg-7

-- no debconf information

Bug#991873: neomutt: Input fields are left when backspacing in position 0

[Markus Demleitner]

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

Dear Maintainer,

Since upgrading to bullseye neomutt, hitting backspace on an empty
input line sends off the input for me.  For an example of where
this is obnoxious, try:

(a) reply to a mail

(b) clear the To: field using backspace (or ^U), and then hit backspace
once again

The effect for me is that mutt proceeds to requesting the Subject line.
The original recipient (i.e., the address I just backspaced away) is
retained by neomutt.

I'm sort-of doubting my system because nobody else has reported this so
far and the misbehaviour has (for me) been consistent in testing since I
upgraded to it, but I can't really imagine how anything (inputrc?) might
cause this behaviour.

And yeah, using ^U mitigates the problem in this concrete scenario, but
there is quite a bit of confusion caused in other contexts, too.

-- 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.13.4-dirty (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=i686-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/i386-linux-gnu} 
{--libexecdir=${prefix}/lib/i386-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-8uPELd/neomutt-20201127+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 
-I/usr/include -I/usr/include/lua5.4 -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:
  +autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl 
  +smime +sqlite +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: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 5.13.4-dirty (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages neomutt depends on:
ii  libc6 2.31-13
ii  libgnutls30   3.7.1-5
ii  libgpg-error0 1.38-2
ii  libgpgme111.14.0-1+b2
ii  libgssapi-krb5-2  1.18.3-6
ii  libidn11  1.33-3
ii  liblua5.4-0   5.4.2-2
ii  libncursesw6  6.2+20201114-2
ii  libnotmuch5   0.31.4-2
ii  libsasl2-22.1.27+dfsg-2.1
ii  libsqlite3-0  3.34.1-3
ii  libtinfo6 6.2+20201114-2
ii  libtokyocabinet9  1.4.48-13
ii  sensible-utils0.0.14

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2.1
ii  locales   2.31-13
ii  mime-support  3.66

Versions of packages neomutt suggests:
ii  aspell 0.60.8-3
ii  ca-certificates20210119
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  gnupg  2.2.27-2
ii  ispell 3.4.02-2
pn  mixmaster  
ii  openssl1.1.1k-1
ii  urlview0.9-21

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

-- debconf-show failed

Bug#984555: gavodachs2-server: fails to install/upgrade. breaks on executing SQL script.

[Markus Demleitner]

On Fri, Jun 11, 2021 at 02:02:51PM +0200, Andreas Beckmann wrote:
> Unfortunately, this is not the case currently because we have
> 
> Package: postgresql-13-pgsphere
> Conflicts: postgresql-pgsphere (<< 1.1.1+2020)

> which causes the pg-11 extensions to be removed before pg_upgrade can be
> performed. But I think these Conflicts+Replaces can be safely dropped since
> all files in these two packages are in versioned paths.

I agree the conflicts needs to be removed.  This won't let us have a
postgresql-pgsphere virtual package depending on "pgsphere for the
current default postgres", though, will it?

> It will only be dropped automatically if you enable autoremoval of unneeded
> packages during the upgrade. But then postgresql-11 will probably go away as
> well...

Yes -- I suppose whoever runs postgres on Debian through a
dist-upgrade has that off.

Bug#988307: eslint --init fails with "cannot find module 'inquirer'

[Markus Demleitner]

Package: eslint
Version: 5.16.0~dfsg+~4.16.8-5
Severity: important

Dear Maintainer,

Immediately after an installation of eslint, running eslint --init
yields:

Error: Cannot find module 'inquirer'
Require stack:
- /usr/share/nodejs/eslint/lib/config/config-initializer.js
- /usr/share/nodejs/eslint/bin/eslint.js
at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:815:15)
at Function.Module._load (internal/modules/cjs/loader.js:667:27)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. 
(/usr/share/nodejs/eslint/lib/config/config-initializer.js:14:16)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)

I see there's a node-inquirer in recommends; that currently has no
installation candidate on my system, but this behaviour would suggest
this should really be a depends -- or, perhaps that a line or two on how
to run eslint without it in the manpage or a README.Debian would be
helpful.

Incidentally, trying with eslint --no-eslintrc I also get a missing 
dependency:

There was a problem loading formatter: ./formatters/stylish
Error: Cannot find module 'text-table'
Require stack:
- /usr/share/nodejs/eslint/lib/formatters/stylish.js
- /usr/share/nodejs/eslint/lib/cli-engine.js
- /usr/share/nodejs/eslint/lib/cli.js
- /usr/share/nodejs/eslint/bin/eslint.js

-- perhaps node-table needs to be promoted to depends, too?

Thanks,

   Markus


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 5.11.11 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages eslint depends on:
ii  node-ajv6.12.6-2
ii  node-concat-stream  2.0.0-1
ii  node-debug  4.3.1+~cs4.1.5-1
ii  node-doctrine   3.0.0-2
ii  node-eslint-scope   5.1.1-1
ii  node-eslint-utils   2.1.0-3
ii  node-eslint-visitor-keys [node-types-e  2.0.0+~0.0.45-1
ii  node-espree 7.3.1~dfsg1-1
ii  node-esquery1.3.1~ds-3
ii  node-estraverse 5.2.0-1
ii  node-esutils2.0.3-1
ii  node-file-entry-cache   6.0.0+~3.0.4+~2.0.0+~1.0.0+~2.0.1-1
ii  node-functional-red-black-tree  1.0.1+20181105-4
ii  node-glob   7.1.6+~7.1.3-1
ii  node-globals13.5.0-1
ii  node-ignore 5.1.4-5
ii  node-imurmurhash0.1.4-1.1
ii  node-json-schema [node-types-json-sche  0.3.0+~7.0.6-1
ii  node-json-stable-stringify  1.0.1+~cs5.1.32-1
ii  node-levn   0.3.0+dfsg-4
ii  node-lodash 4.17.21+dfsg+~cs8.31.173-1
ii  node-mkdirp 1.0.4+~1.0.1-1
ii  node-optionator 0.9.1+dfsg-1
ii  node-path-is-inside 1.0.2-1.1
ii  node-progress   2.0.3-1
ii  node-regenerate-unicode-properties  8.2.0+ds-1
ii  node-regexpp3.1.0-4
ii  node-resolve-from [node-import-fresh]   5.0.0+~3.1.0+~3.3.0+~2.0.0-1
ii  node-semver 7.3.4-1
ii  node-strip-json-comments3.1.1-1
ii  nodejs  12.21.0~dfsg-4

Versions of packages eslint recommends:
ii  node-chalk   4.1.0-1
pn  node-inquirer
ii  node-js-yaml 3.14.1+dfsg+~3.12.6-2
ii  node-strip-ansi  6.0.0-2
pn  node-text-table  

Versions of packages eslint suggests:
pn  node-babel-code-frame  
pn  node-babel-eslint  
ii  node-esprima   4.0.1+ds+~4.0.2-2
pn  node-esprima-fb
pn  node-table 

-- no debconf information

Bug#984555: gavodachs2-server: fails to install/upgrade. breaks on executing SQL script.

[Markus Demleitner]

Hi Andreas,

On Mon, May 03, 2021 at 07:19:52PM +0200, Andreas Beckmann wrote:
> Followup-For: Bug #984555
> I think I have an idea what is happening: The upgrade from buster to
> bullseye does not install postgresql-13-pgsphere and postgresql-13-q3c
> but keeps postgresql-pgsphere and postgresql-q3c from buster installed.

Yes, that's my analysis, too.

> This is a problem of the postgresql-* packages which switched from real
> packages postgresql-foo providing virtual postgresql-xx-foo to real
> packages postgresql-xx-foo providing virtual postgresql-foo.
> IMO it was wrong turning postgresql-foo into virtual packages,
> especially if multiple postgresql-xx-foo are expected to be
> co-installable, s.t. there are multiple packages providing
> postgresql-foo at the same time. postgresql-foo should have stayed a
> real package depending on the default version of postgresql-xx-foo.

Ah.  That might be a solution.  One thing that needs to be
ensured, though, is that on upgrades, the old pgsphere packages do
not get removed until the operator asks dpkg to explicitly.  Perhaps
stating the obvious, here's what needs to happen when upgrading from,
say pg 11 to 13:

(1) normal dist-upgrade pulls in (hopefully) postgres-13, keeps
postgres-11 running as normal (hence, pgsphere-11 must still be
there).
(2) operator runs pg_upgrade (for which both pg-13 and pg-11 must be
present with all necessary extensions)
(3) the last step of pg_upgrade is to make pg-13 the default db server,
and pg-11 isn't started any more
(4) the operator can now purge postgres-11 together with the
version 11 extensions.

My hunch is that when pgsphere-11 is installed as an auto-dependency
of pgsphere, it will be dropped in step (1), at which point pg-11
probably won't even start any more, or at least will be unable to
dump for the pg_upgrade.

> and reducing that to
> 
>   Depends: adduser, members, postgresql-13-pgsphere, postgresql-13-q3c, 
> python3-gavo (= 2.3+dfsg-2)

I've just done this, and I *think* that should do the right thing
when upgrading to bullseye.  I can't say I like it much, though, in
particular because it's going to be a permanent chore in maintaining
the explicit versions.

What I'd *really* want to say is:

"I depend on a postgres with the pgsphere and q3c extensions
installed, listening on port 5432."

How far we get there with the existing Depends logic would be
something I'd probably ask the postgres folks.

> 
> Perhaps also a
> 
>   Breaks: postgresql-pgsphere (<< 1.1.1+2020), postgresql-q3c (<< 2)
> 
> would work for the upgrades to bullseye.

Nah, that, I think, would be a disaster, because it'd throw out the
extensions before step (2) above could run, no?

Even though I think the problem is addressed for bullseye, I'm
leaving this bug open because I'm hoping for some better way to solve
this.

Bug#984555: Ping?

[Markus Demleitner]

Hi all,

Have you had a chance to see if my diagnosis about two versions of
postgres running is right?

-- Markus

Bug#985820: python3-cryptography: Core dump in buster openssl binding

[Markus Demleitner]

Hi Bernhard,

Thanks for looking into this.

On Thu, Apr 08, 2021 at 05:07:43PM +0200, Bernhard Übelacker wrote:
> I found following ticket [2] that shows in later entries
> similarities to the given backtrace.

Yes, this looks pretty much like what I'm seeing (assuming Glyph's
speculation it could be related to python2.7 is wrong, as this is on
python3; but I'm going with openssl as the central culprit).

> Further running the server with valgrind might show something
> related, if the crash happens there too.

Since this appears to be a known problem, there's reason to hope
it will go away when moving to bullseye, disabling https upgrading
made the crashes disappear, and I can live with http for this
particular service, I think at this point I'm willing to risk
something that feels rather exploitable for another few weeks.

These considerations would change if others were seriously concerned;
given the twisted ticket has indications on how to trigger the bug
outside of production, I might try to organise a windows client to
trigger it on a development system.

Thanks,

Markus

Bug#985820: python3-cryptography: Core dump in buster openssl binding

[Markus Demleitner]

Package: python3-cryptography
Version: 2.6.1-3+deb10u2
Severity: normal
Tags: security

A long-running, twisted-based server occasionally (days to weeks) gets aborted
when processing HTTPS requests.  Here's a basic core dump from an abort:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f604e0d2535 in __GI_abort () at abort.c:79
#2  0x7f604e129508 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f604e23428d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f604e12fc1a in malloc_printerr (
str=str@entry=0x7f604e23243b "free(): invalid pointer") at malloc.c:5341
#4  0x7f604e13142c in _int_free (av=, p=,
have_lock=) at malloc.c:4165
#5  0x7f604d77a9be in SSL_SESSION_free ()
   from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#6  0x7f604d5ddc8c in OPENSSL_LH_doall_arg ()
   from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#7  0x7f604d77bf57 in SSL_CTX_flush_sessions ()
   from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#8  0x7f604d7924d3 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#9  0x7f604d787e3e in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#10 0x7f604d773f34 in SSL_do_handshake ()
   from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#11 0x7f604d12971c in ?? ()
   from 
/usr/lib/python3/dist-packages/cryptography/hazmat/bindings/_openssl.abi3.so
#12 0x005ccba1 in _PyMethodDef_RawFastCallKeywords ()

This is about all I know at this point.  I've not yet managed to trigger this
on a development system.  On the operational system, I can live with
having a watchdog restart the service when it gets aborted, so I could
limp on until bullseye here.

On the other hand, an invalid free in openssl sounds a bit unnerving, and 
so I thought I'd report this and offer to at least install debug
packages and look more closely at the problem (disclaimer: as I may have 
to wait weeks until I'll get another abort, responses may be slow).

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.UTF-8), LANGUAGE=en_US (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages python3-cryptography depends on:
ii  libc62.28-10
ii  libssl1.11.1.1d-0+deb10u5
ii  python3  3.7.3-1
ii  python3-asn1crypto   0.24.0-1
ii  python3-cffi-backend [python3-cffi-backend-api-min]  1.12.2-1
pn  python3-cffi-backend-api-max 
ii  python3-six  1.12.0-1

python3-cryptography recommends no packages.

Versions of packages python3-cryptography suggests:
pn  python-cryptography-doc   
pn  python3-cryptography-vectors  

-- no debconf information

Bug#984555: gavodachs2-server: fails to install/upgrade.

[Markus Demleitner]

On Tue, Mar 16, 2021 at 10:49:24AM +0100, Markus Demleitner wrote:
> What is already making me nervous at a second glance: There's
> postgresql-11-pgsphere, but on bullseye postgres will be postgres 13.
> I'd hence suspect that the postgres DaCHS is talking to is not the
> one that has pgsphere.

Meanwhile, I'm pretty sure this is what happened here: You already had
a postgres 11 on your boxes, but at some point a postgres 13 was put
on the box as well, while postgres 11 lingered around.

Now, when installing DaCHS, the system satisified the pgsphere
dependency with postgres-11-pgsphere.  This, however, means that
there is no pgsphere on the operational pgsphere, which is what kills
DaCHS (and, really, there is very little point running DaCHS without
these extensions, which is why it doesn't even try to limp on).

Summing up: If you un-install postgres 11, things should start to
work.

Is there a good way to prevent this confusing situation?  I don't
know, but I'll ask around.

-- Markus

Bug#985396: Parsing non-trivial ADQL is broken

[Markus Demleitner]

Package: gavodachs2-server
Version: 2.3+dfsg-1
Severety: important

ADQL more complex than the most trivial queries is totally misparsed.  See, for
instance:

curl -FLANG=ADQL \
-FQUERY="SELECT TOP 1 * FROM tap_schema.tables natural join 
tap_schema.columns" \
http://localhost:8080/tap/sync -FFORMAT=votable/td

This produces an error message like:

syntax error at or near "."
LINE 1: ...97152823d0" CURSOR WITHOUT HOLD FOR SELECT 
natural.schema_na...

(rather than a proper response as when the query is not mangled to
"SELECT natural.schema...").

The reason for this is that pyparsing 2.4, as in sid and bullseye, has a
few API changes that break DaCHS' parsers for ADQL and STC; the
package tests have stupidly been run in a buster system (I can say
that because it was me who did that), so this went unnoticed.

As running ADQL queries through TAP probably is what most deployers of
this package are after, that's a fairly bad blow.

Bug#985395: TAP queries fail

[Markus Demleitner]

Package: gavodachs2-server
Version: 2.3+dfsg-1
Severety: important

When running a synchronous TAP query, output stops after the first
few bytes and the connection hangs.

To reproduce:  Run

  curl -FLANG=ADQL -FQUERY="SELECT TOP 1 * FROM tap_schema.tables" 
http://localhost:8080/tap/sync

against a freshly installed copy of DaCHS.

The server stops delivering bytes because its delivery code throws an
exception:

  File "/usr/lib/python3/dist-packages/gavo/svcs/streaming.py", line 
145, in cleanup
if self.isAlive():
builtins.AttributeError: 'DataStreamer' object has no attribute 
'isAlive'

The problem is that the code streaming out uses the isAlive method of
python threads that was deprecated in python 3.7 and dropped in
python 3.8.  Unfortunately, the package tests were run in Debian
stable, so this bug was missed.

Since TAP is what most people will use this package for, and this
affects essentially all uses of TAP, this is a fairly ugly thing.

Bug#984555: gavodachs2-server: fails to install/upgrade.

[Markus Demleitner]

> I tried your suggestion, but didn't get very far:
> $ psql gavo
> psql: error: FATAL:  role "jrv" does not exist
> 
> Let me know if there's something else you want to cross-check.

This one is easy to fix: postgres wants to know who it talks to, and
it doesn't know you.  The easiest fix is to become the user
dachsroot, which is recommended for DaCHS operations anyway.

An alternative that would generally work in other situations on
Debian:

  sudo -u postgres psql gavo

But this bug report made actually try running DaCHS on unstable, and
while I cannot reproduce the installation failure, that made me
realise some additional adaptations to unstable are necessary.

What is already making me nervous at a second glance: There's
postgresql-11-pgsphere, but on bullseye postgres will be postgres 13.
I'd hence suspect that the postgres DaCHS is talking to is not the
one that has pgsphere.

So, what would

  sudo -u postgres psql gavo -c "select version()"

say?

 -- Markus

Bug#984555: Fwd: Bug#984555: gavodachs2-server: fails to install/upgrade. breaks on executing SQL script.

[Markus Demleitner]

> createdb: database creation failed: ERROR:  database "gavo" already exists
> Creation of gavo database failed; assuming it's already there
> and carrying on.

This means that there has been a DaCHS on that machine before, i.e.,
that this is an upgrade.  Is that right?  If so, then this message
is expected (and we ought to hide it one of these days).

> /usr/lib/python3/dist-packages/gavo/user/initdachs.py:310: UserWarning: SQL
> script file for /usr/share/postgresql/contrib/pg_sphere.sql not found.

This is where things go wrong.  DaCHS should not even try to load the
pgsphere SQL, as all pgspheres that can possibly in use now already
use the new Postgres extension system.

So, why does it try this?  This:

> Versions of packages gavodachs2-server depends on:
> ii  postgresql-pgsphere [postgresql-11-pgsphere]  1.1.1+2018.10.13-1

is essentially as it should be.  I wonder if it has been like this at
the time of the DaCHS installation.

But let's see if things are properly there now.  Could you run 

  psql gavo

and then in psql

  select * from pg_available_extensions where name='pg_sphere';

What does that say?

Bug#976437: libwebkit2gtk-4.0-37: Websocket sends appens extra bytes to messages

[Markus Demleitner]

Package: libwebkit2gtk-4.0-37
Version: 2.30.3-1~deb10u1
Severity: normal

Dear Maintainer,

Since the last libwebkit update in buster, there is a (possibly 
information-disclosing) bug in the websockets implementation.  For instance
when a client sends, in order, the strings "disabled", "d20", "NOP" and 
"NOP", what the server receives in one run is

'disablede/im0'
'd20\x01\x17'
'NOPablede/im0'
'NOP\x01\x1e'

A repetition might yield

'disable'
'd20'
'enablee'
'NOPblee'

-- which not only breaks the websocket application but also might lead
to disclosing parts of memory that the server probably shouldn't be
seeing.

Steps to reproduce:

(1) get a browser using libwebkit2gtk-4.0.37 (I used luakit)

(2) connect to any websocket echo service (I used 
https://www.websocket.org/echo.html)

(3) Type a few messages of varying length and spot the replies contain extra 
bytes.

Actually, in these tests I noticed that there's probably more awry in that the 
websocket connection after a few messages apparently becomes unresponsive.


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

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  bubblewrap  0.3.1-4
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libegl1 1.1.0-1
ii  libenchant1c2a  1.6.0-11.1+b1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgcrypt20 1.8.4-5
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgl1  1.1.0-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgstreamer-gl1.0-01.14.4-2
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libharfbuzz-icu02.3.1-1
ii  libharfbuzz0b   2.3.1-1
ii  libhyphen0  2.8.8-7
ii  libicu6363.1-6+deb10u1
ii  libjavascriptcoregtk-4.0-18 2.30.3-1~deb10u1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libnotify4  0.7.7-4
ii  libopenjp2-72.3.0-2+deb10u1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libpangocairo-1.0-0 1.42.4-8~deb10u1
ii  libpng16-16 1.6.36-6
ii  libseccomp2 2.3.3-4
ii  libsecret-1-0   0.18.7-1
ii  libsoup2.4-12.64.2-2
ii  libsqlite3-03.27.2-3
ii  libstdc++6  8.3.0-6
ii  libsystemd0 241-7~deb10u4
ii  libtasn1-6  4.13-3
ii  libwayland-client0  1.16.0-1
ii  libwayland-egl1 1.16.0-1
ii  libwayland-server0  1.16.0-1
ii  libwebp60.6.1-2
ii  libwebpdemux2   0.6.1-2
ii  libwoff11.0.2-1
ii  libx11-62:1.6.7-1+deb10u1
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.32-2.2~deb10u1
ii  libxt6  1:1.1.5-1+b3
ii  xdg-dbus-proxy  0.1.1-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages libwebkit2gtk-4.0-37 recommends:
ii  gstreamer1.0-alsa  1.14.4-2
pn  gstreamer1.0-gl
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-pulseaudio1.14.4-1
ii  libgl1-mesa-dri18.3.6-2+deb10u1

libwebkit2gtk-4.0-37 suggests no packages.

-- no debconf information

Bug#962261: postgresql-pgsphere: Package name without postgres version

[Markus Demleitner]

Package: postgresql-pgsphere
Severity: wishlist

Dear Maintainer,

Postgres extensions have a hard dependency on the version of postgres
itself.  On the other hand, Debian lets people install multiple postgres
versions in parallel.  Therefore, the package name needs to contain the
postgres version the extension is complied again (e.g.,
postgres-11-pgsphere).

I'd say postgres-pgsphere should (roughly) copy what postgis does.
There, postgres-postgis is a virtual package, with packages like
postgres-11-postgis providing it.  Postgis takes another step in
allowing multiple versions of postgis itself being installable for a
single postgres version.  I don't think there's a credible use case for
that in pgsphere.

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

Kernel: Linux 5.4.7 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages postgresql-pgsphere depends on:
ii  libc6  2.28-10
ii  postgresql-11  11.7-0+deb10u1

postgresql-pgsphere recommends no packages.

postgresql-pgsphere suggests no packages.

Bug#962260: postgresql-q3c: Package name without postgres version

[Markus Demleitner]

Package: postgresql-q3c
Version: 1.6.0-1
Severity: wishlist

Dear Maintainer,

Postgres extensions have a hard dependency on the version of postgres
itself.  On the other hand, Debian lets people install multiple postgres
versions in parallel.  Therefore, the package name needs to contain the
postgres version the extension is complied again (e.g., 
postgres-11-q3c).

I'd say postgres-q3c should (roughly) copy what postgis does.  
There, postgres-postgis is a virtual package, with packages like
postgres-11-postgis providing it.  Postgis takes another step in 
allowing multiple versions of postgis itself being installable for a
single postgres version.  I don't think there's a credible use case for
that in q3c.


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

Kernel: Linux 5.4.7 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages postgresql-q3c depends on:
ii  libc6  2.28-10
ii  postgresql-11  11.7-0+deb10u1

postgresql-q3c recommends no packages.

postgresql-q3c suggests no packages.

-- no debconf information

Bug#945509: libwebkit2gtk-4.0-37: luakit should also force single process

[Markus Demleitner]

Package: libwebkit2gtk-4.0-37
Version: 2.26.2-1~deb10+1
Severity: normal

Dear Maintainer,

The transition to 2.26 and  the independent web processes als breaks luakit
in several ways discussed in https://github.com/luakit/luakit/issues/804.
I strongly suspect (though I've not tried it because rebuilding webkit
is such a pain) that including luakit in the client list in 
force-single-process.patch would fix this.  Could you do that?

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

Kernel: Linux 5.3.1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  bubblewrap  0.3.1-4
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libegl1 1.1.0-1
ii  libenchant1c2a  1.6.0-11.1+b1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u1
ii  libgcc1 1:8.3.0-6
ii  libgcrypt20 1.8.4-5
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgl1  1.1.0-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgstreamer-gl1.0-01.14.4-2
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libharfbuzz-icu02.3.1-1
ii  libharfbuzz0b   2.3.1-1
ii  libhyphen0  2.8.8-7
ii  libicu6363.1-6
ii  libjavascriptcoregtk-4.0-18 2.26.2-1~deb10+1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libnotify4  0.7.7-4
ii  libopenjp2-72.3.0-2
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libpng16-16 1.6.36-6
ii  libseccomp2 2.3.3-4
ii  libsecret-1-0   0.18.7-1
ii  libsoup2.4-12.64.2-2
ii  libsqlite3-03.27.2-3
ii  libstdc++6  8.3.0-6
ii  libtasn1-6  4.13-3
ii  libwayland-client0  1.16.0-1
ii  libwayland-egl1 1.16.0-1
ii  libwayland-server0  1.16.0-1
ii  libwebp60.6.1-2
ii  libwebpdemux2   0.6.1-2
ii  libwoff11.0.2-1
ii  libx11-62:1.6.7-1
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxslt1.1  1.1.32-2.2~deb10u1
ii  xdg-dbus-proxy  0.1.1-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages libwebkit2gtk-4.0-37 recommends:
ii  gstreamer1.0-alsa  1.14.4-2
pn  gstreamer1.0-gl
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-pulseaudio1.14.4-1
ii  libgl1-mesa-dri18.3.6-2

libwebkit2gtk-4.0-37 suggests no packages.

-- no debconf information

Bug#942807: tex-common: Cannot include hyphenation patterns with etex

[Markus Demleitner]

Dear Norbert,

On Wed, Oct 23, 2019 at 04:54:10PM +0900, Norbert Preining wrote:
> But you can definitely use different languages:
>   \uselanguage{ngerman}
>   ...

Indeed.  This is what I was looking for, but what comes up on 

texdoc etex 

doesn't mention \uselanguage, and actually looking for language or
hyphenation in there just yields a discussion of lccode, which didn't
help me a lot the other day. The document's introduction, on the
other hand, sounded more more like there's only additions to the DEK
tex feature set (this as an excuse for wasting your time).

Now, I give you etex is probably somewhat ancient and perhaps we
shouldn't bother, but as a wishlist item I might mention "Make
wherever doc you found uselanguage in a bit better discoverable
within texdoc or some other kind of documentation".

> Usage of languages are different in etex and latex, you cannot use
> ngerman.sty - or at least not as is.

Ok, I see.  I'm fine with closing this bug.  Or turning it into a
wishlist item.

Thanks a lot,

 Markus

Bug#942807: tex-common: Cannot include hyphenation patterns with etex

[Markus Demleitner]

Package: tex-common
Version: 6.11
Severity: normal

Dear Maintainer,

I'm trying to have non-English hyphenation patterns with etex on stretch,
and I'm unable to figure out how this is intended to happen.

Consider this input:

\input ngerman.sty
internationaler, internationaler, internationaler,
internationaler, internationaler, internationaler,
internationaler, internationaler,
\bye

Running "bplain tmp.tex", this correctly hyphenates "inter-nationaler" and 
produces a justified line.  bplain was produced using a conventional 
"bplain tex language.dat" in /etc/texmf/fmt.d.

Instead running "etex tmp.tex" without preparations (assuming it comes 
with all patterns built-in) first runs initex, like this (according to
the generated output):

pdftex -ini   -jobname=etex -progname=etex -translate-file=cp227.tcx 
*etex.ini'

-- and indeed, the initex log tells one that:

...
(/usr/share/texlive/texmf-dist/tex/generic/dehyph/dehyphn.tex
New German Hyphenation Patterns `dehyphn' Rev.31 <2001-05-07> (WaS)))
...

and hence the hyphens I'm after do get loaded.  I don't see any definition of
l@ngerman, though, and sure enough, the the normal TeX run then says:

ngerman -- \language number for ngerman undefined, default 255 used,
ngerman -- Please read "gerdoc.tex" how to install hyphenation 
patterns.)
Overfull \hbox (32.57936pt too wide) in paragraph at lines 2--5
[]\tenrm internationaler, internationaler, internationaler, 
internationaler, in
ternationaler, internationaler, internationaler,|

So, rather clearly, the hyphenation patterns are not available, and an 
overfull hbox ensues.

I've tried a few things to change this, in particular defining, against 
better judgement,

etexetexlanguage.def-etex 
-translate-file=cp227.tcx etex.ini

in an /etc/texmf/fmt.d/01etex.cnf.  This doesn't change anything but gives,
on update-fmtutil, a big warning with the explanation

Warning: Old configuration style found in /etc/texmf/fmt.d
Warning: For now these files have been included, 
Warning: but expect inconsistencies.
Warning: These packages should be rebuild with tex-common.
Warning: Please see /usr/share/doc/tex-common/NEWS.Debian.gz

-- that's not terribly helpful for hapless users who've migrated their 
personal configuration, because the NEWS.Debian.gz, as far as I could
make out, does not discuss that case.  But that's somewhat tangential
because it doesn't really change the trouble I'm having here anyway --
even with this sort of explicit language.def the patterns don't appear.

So: is there any way to have non-English hyphenation patterns with 
stretch etex (where at least my etex is linked to pdftex)?  Am I 
missing something fundamental?

Thanks for any insight (given that stretch pstricks is broken with DEK
tex I'd really like to be able to move to etex...)

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

Kernel: Linux 5.3.1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  12.1.1

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libpaper-utils 1.1.28
ii  sensible-utils 0.0.12
ii  texlive-binaries   2018.20181218.49446-1
ii  ucf3.0038+nmu1
ii  xdg-utils  1.1.3-1

Versions of packages texlive-base recommends:
ii  lmodern  2.004.5-6

Versions of packages texlive-base suggests:
ii  ghostscript [postscript-viewer]   9.27~dfsg-2+deb10u2
ii  gv [postscript-viewer]1:3.7.4-2
ii  mupdf [pdf-viewer]1.14.0+ds1-4
ii  perl-tk   1:804.033-2+b3
ii  xpdf [pdf-viewer] 3.04-13
ii  zathura-pdf-poppler [pdf-viewer]  0.2.9-1
ii  zathura-ps [postscript-viewer]0.2.6-1

Versions of packages texlive-binaries depends on:
ii  dpkg  1.19.7
ii  install-info  6.5.0.dfsg.1-4+b1
ii  libbrotli11.0.7-2
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.3.0-6
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgraphite2-31.3.13-7
ii  libgs99.27~dfsg-2+deb10u2
ii  libharfbuzz-icu0  2.3.1-1
ii  libharfbuzz0b 2.3.1-1
ii  libice6   2:1.0.9-2
ii  libicu63  63.1-6
ii  libkpathsea6  2018.20181218.49446-1
ii  libmpfr6  4.0.2-1
ii  libpaper1 1.1.28
ii  libpixman-1-0 0.36.0-1

Bug#941074: ghostscript: ps2pdf SAFER and transparency interference

[Markus Demleitner]

Package: ghostscript
Version: 9.27~dfsg-2+deb10u2
Severity: minor

ps2pdf14 as delivered in buster will only produce PDF transparency when
run with -dNOSAFER.  This deviates from previous releases (I'm quite
sure about jessie), when transparency was produced without further
configuration.  Although I *might* see some relationship to accepting
pdfmarks, the connection between SAFER and transparent colours frankly
strikes me as just a little non-intuitive (but that may be because I
don't know what's going on when producing transparency in PDFs).

Because of this, I'd suggest that if turning off PDF transparency
without -dNOSAFER is intentional, that should be documented in the NEWS,
even more so as I couldn't make out that fact in the upstream Use.htm
that the current 9.28~~rc1~dfsg-1 NEWS item refers to.  Perhaps that
particular item could be amended with saying something like "Note that
that has some rather unexpected consequences (e.g., PDF transparency is
now lost without -dNOSAFER)."

Here's my minimal working example:

With the LaTeX document

\documentclass{article}
\usepackage{pstricks}
\begin{document}

\psframebox*[linecolor=white,fillcolor=red,fillstyle=solid,
opacity=0.85,framesep=4mm]{abc}
\vskip -9mm
\psframebox*[fillcolor=white, opacity=0.5,strokeopacity=0.5,
fillstyle=solid,framesep=4mm,linewidth=3pt,linecolor=black]{abc}

\end{document}

in a.tex, run

latex a;dvips a;ps2pdf a.ps

and the second white box obscures most of the red box in the background
(i.e., pstricks opacity is ignored).  Run

latex a;dvips a;ps2pdf -dNOSAFER a.ps

and the two boxes blend as expected.


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

Kernel: Linux 5.1.9 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ghostscript depends on:
ii  libc6   2.28-10
ii  libgs9  9.27~dfsg-2+deb10u2

Versions of packages ghostscript recommends:
ii  gsfonts  1:8.11+urwcyr1.0.7~pre44-4.4

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.27~dfsg-2+deb10u2

-- no debconf information

Bug#918111: ITP: luakit -- A webkit2-based web browser extensible by Lua

[Markus Demleitner]

Package: wnpp
Severity: wishlist
Owner: Markus Demleitner 

* Package name: luakit
  Version : 2017-08-10
  Upstream Author : Aidan Holm https://luakit.github.io
* License : GPLv3
  Programming Lang: C, Lua
  Description : A webkit2-based web browser extensible by Lua

Luakit has been part of Debian up to and including stretch.  It was removed
from sid recently because the version in Debian depended on Webkit1.
Upstream, however, had ported the software to Webkit2 by then.
I would like to bring back the modernised luakit to Debian.

The description of the old package by and large still pertains (although
I give you it would be spiced up a bit): Luakit is a highly configurable
browser framework based on WebKit2GTK.  It is very fast and extensible
by Lua.  It is primarily targeted at power users, developers and any
people with too much time on their hands who want to have fine-grained
control over their web browser's behaviour and interface.

Bug#735873: zathura: Scrollbar settings do not work

[Markus Demleitner]

On Mon, Mar 03, 2014 at 06:17:12PM +0100, Sebastian Ramacher wrote:
 On 2014-01-21 09:23:38, Markus Demleitner wrote:
  On Tue, Jan 21, 2014 at 03:36:00AM +0100, Sebastian Ramacher wrote:
   On 2014-01-20 09:13:59, Markus Demleitner wrote:
They are.  My problem is that they don't disappear when the settings
are false.
 Are you using some kind of desktop environment? If so, which one? (This
 might help us chasing down the theme.)

No DE, this is in a sawfish in an xinit-started X.

However, it seems upstream knows about this and doesn't really care;
At least
http://www.pwmt.org/projects/jumanji/usage/#hide-scrollbars-in-gtk-3.0
would suggest as much:

  Since the 'show-scrollbars' option will not have any effect with
  GTK+-3.0...

(jumanji is based on girara, too, and scrollbars appear to be handled
by girara, so this seems pertinent).  They give a workaround there,
too.

I guess I wouldn't object to closing this bug given all this.

Thanks,

 Markus


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735873: zathura: Scrollbar settings do not work

[Markus Demleitner]

On Tue, Jan 21, 2014 at 03:36:00AM +0100, Sebastian Ramacher wrote:
 On 2014-01-20 09:13:59, Markus Demleitner wrote:
  They are.  My problem is that they don't disappear when the settings
  are false.
 
 Oh, okay. I've never seen this before. I'll try to reproduce the problem
 with a backport. Could you tell me if your ~/.config/gtk-3.0/gtk.css
 contains anything special? Which GTK+ 3 theme are you using?

gtk.css was empty when I reported the bug.  To mitigate the garish
scrollbar, I've put in 

.scrollbar {
-GtkRange-slider-width: 9;
-GtkRange-stepper-size: 9;
}

yesterday, which has the expected result of making the scrollbars
smaller.

As to the theme, neither a quick look in relevant-looking man pages
nor the Duck gave an obvious answer as to how to find out what theme
is active. I've not changed anything actively there, and the gtk.css
with the above content is the only thing in .config/gtk-3.0, so I'd
expect it's whatever is the wheezy default.

Thanks,

 Markus


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735873: zathura: Scrollbar settings do not work

[Markus Demleitner]

On Sat, Jan 18, 2014 at 07:51:10PM +0100, Sebastian Ramacher wrote:
 On 2014-01-18 07:30:05, Martin Demleitner wrote:
  In that situation, the show-scrollbars, show-h-scrollbar, and
  show-v-scrollbar settings have no effect, either in .zathurarc or
  interactively; scrollbars do not appear or disappear.
 Could please test if the scrollbars appear if you set all three settings
 to true, set guioptions to an empty value and then open a document and
 zoom in so that not everything is visible. The scrollbars should appear
 in this case.

They are.  My problem is that they don't disappear when the settings
are false.

 The problem seems to be that the statusbar hides the horizontal
 scrollbar. However, the vertical scrollbar should appear if you're
 zoomed in enough that there is something to scroll.

I can confirm that the statusbar hides the horizontal scrollbar here,
too, but that's just an aside.

Thanks,

   Markus


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534217: python-numarray: concatenate fails on amd64

[Markus Demleitner]

Package: python-numarray
Version: 1.5.2-4
Severity: normal

The program

import numarray
n = numarray.zeros((3,3))
print numarray.concatenate((n,n))

outputs the right thing on ia32, but raises a

Traceback (most recent call last):
  File zw.py, line 3, in module
print numarray.concatenate((n,n))
  File /usr/lib/python2.5/site-packages/numarray/generic.py, line 1115, in 
concatenate
return _concat(arrs)
  File /usr/lib/python2.5/site-packages/numarray/generic.py, line 1105, in 
_concat
dest[ix:ix+_shape0(a)]._copyFrom(a)
  File /usr/lib/python2.5/site-packages/numarray/generic.py, line 619, in 
_broadcast
return _broadcast(arr, self._shape)
  File /usr/lib/python2.5/site-packages/numarray/generic.py, line 93, in 
_broadcast
raise ValueError(Arrays have incompatible shapes)
ValueError: Arrays have incompatible shapes

on amd64 -- or at least the box I'm trying it on.  While trying to 
nail down what happens, I gave up when I found that 
NA_ShapeEqual(selfa, arra) in _numarraymodule.c, 426 is false on the
second iteration and gained the impression I'd have a relatively
hard time figuring out why...

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

Kernel: Linux 2.6.18-4-xen-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-numarray depends on:
ii  libblas3gf [libblas.so.3gf]   1.2-2  Basic Linear Algebra Subroutines 3
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libgfortran3  4.3.2-1.1  Runtime library for GNU Fortran ap
ii  liblapack3gf [liblapack.so.3g 3.1.1-1library of linear algebra routines
ii  python2.5.2-3An interactive high-level object-o
ii  python-central0.6.8  register and build utility for Pyt

python-numarray recommends no packages.

Versions of packages python-numarray suggests:
pn  python-numarray-dbg   none (no description available)
ii  python-numarray-doc   1.5.2-4An array processing package for Py

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org