Bug#989714: kdump-tools is broken out of the box

[Dominique MARTINET]

Hi,

reviving this...

(Rich, sorry for double mail - my initial reply incorrectly replied to
your mail which didn't have 989...@bugs.debian.org anywhere to properly
tag... Hopefully this will get through better)

Rich Ercolani wrote on Fri, Jun 11, 2021 at 03:43:17AM -0400:
> I installed kdump-tools to take a crash dump, rebooted, verified the 
> crashkernel was configured,
> triggered the problem I wanted to examine and a dump...the machine became 
> entirely unresponsive
> over ssh or local console (kind of expected) but didn't print any sign it was 
> doing anything
> like booting the crashkernel (bad).
> 
> I left it for 15 minutes, and nothing changed, so I hard rebooted it, and 
> tried again, same result.
> 
> So I tried installing kdump-tools and then using echo 'c' | sudo tee 
> /proc/syrq-trigger  on bullseye,
> same outcome. Same on jessie/x86_64 (with manual configuration of 
> crashkernel= in the grub config).

Also got bitten by this.
What's quite horrible is that when it happened on the real machine I
wanted to debug there was no sign it was doing anything -- the HDMI
screen setup probably didn't have time to happen on crash kernel to be
able to print anything, so even connecting a screen wouldn't help.

I also misread the 384M:-128M syntax to 384M@128M (second digit being
location in the later case) so tried to increase the first value which
obviously had no impact... and then tried in a VM at which point serial
works and it was clear enough, but the default experience was just
horrible, especially since the system never came back.

We probably ought to add 'panic=30' (or some arbitrary time) to
KDUMP_CMDLINE_APPEND's defaut value.


> So I looted part of the crashkernel= setting from the Ubuntu system 
> (crashkernel=512M-:192M was theirs,
> I used 384M-:192M) - no change. Tried 384M-:256M, and it worked. So I tried 
> theirs verbatim, and it
> also worked every time.
> 
> So maybe we need different defaults on at least x86_64 systems?

I haven't tried with less memory, but I'd say we can make use of the
range syntax to provide bigger values when the system has more than a
few GB of ram at least.
I can spend a bit of time to try in a VM with various values, but
something like crashkernel=512M-4G:192M,4G-64G:256M,64G-:384M is
probably sensible?
(lowest value coming from ubuntu's settings, would need to test how much
is needed for a system with 384MB but I'd be reluctant to take half of
its ram for crashkernel)

> (I specify x86_64 because using 512M-:192M breaks crashkernel more on my i386 
> testbeds.)

(Can't help about i386 though)

Thanks,
--
Dominique Martinet

Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Dominique Martinet]

Paul Eggert wrote on Fri, Dec 15, 2023 at 11:21:06AM -0800:
> The cat is to some extent out of the bag. Unless one insists on (FreeBSD |
> coreutils 9.2-9.4), or insist on coreutils 7.1-9.1, one should not rely on
> cp -n failing or silently succeeding when the destination already exists.
> This will remain true regardless of whether coreutils reverts to its 7.1-9.1
> behavior.

This. Scripts that want to be portable already can't assume cp -n will
do what they want, so at this point it doesn't really matter what
coreutils does in the grand scheme of things.

For distros like debian since even -testing hasn't seen coreutils 9.2,
there's still value in reverting locally (with a warning that it's not
reliable perhaps?), but in general coreutils 9.2 has been out for 9
months (2023 March 20), so many systems can already be considered
affected; but it's a disservice to users to just try to hide the problem
under the rug.


(To give a data point, this did bite us as well, and I was annoyed
enough that I went to look for the old bug report back in September, but
at that point 9.3 had already been out and I had given up without
reporting anything as nothing would change the fact that my scripts
would need updating. For the gory details I also need compatibility
with busybox cp (where -n silently ignores existing files), so
--update=none is not an option, but I for this particular usage I
settled for '-u' (--update=older, that busybox also support as short
option only...), and I since hurried to forget about it)

-- 
Dominique Martinet | Asmadeus

Bug#1050340: [Pkg-puppet-devel] Bug#1050340: puppetserver: incompatibility with system hiera-eyaml

[Dominique Martinet]

Georg Faerber wrote on Tue, Sep 19, 2023 at 10:19:57AM +:
> So, symlinks to the rescue:
>
> [...]

This is horrible.
So I obviously did the same. Thanks a lot!

I'd be interested in a better solution that'll survive upgrades
though -- I agree wth Georg's analysis that this is "just" a problem of
loading paths, so either the puppetserver package could add hiera-eyaml
in its vendored-jruby-gems (which probably isn't too hard, but debian
frowns on vendored stuff in general so I don't see why it'd be better
for ruby deps..), or we'll need to look into why system gems cannot be
used with jruby...

-- 
Dominique Martinet | Asmadeus

Bug#1054150: surf: no longer display web pages after webkitgtk upgrades

[Dominique Martinet]

Alberto Garcia wrote on Fri, Oct 20, 2023 at 04:19:55PM +0200:
> On Wed, Oct 18, 2023 at 05:06:16PM +0900, Dominique Martinet wrote:
> > After upgrading my system to the latest security updates surf no
> > longer displays anything.
> 
> I had a look at this, the problem is caused by Surf's AppArmor
> configuration.

d'oh ! I need to remember debian now ships this on by default...

> I can make it run on my computer with something like this added to
> /etc/apparmor.d/usr.bin.surf, but your mileage may vary:
> 
>   /sys/devices/virtual/dmi/id/chassis_type r,
>   /etc/glvnd/egl_vendor.d/ r,
>   /etc/glvnd/egl_vendor.d/** r,
>   /usr/share/glvnd/egl_vendor.d/ r,
>   /usr/share/glvnd/egl_vendor.d/** r,
>   /usr/share/libdrm/* r,  

Thanks, I can confirm this works for me as well on various systems
(bullseye VM and bookworm with intel GPU)

(I'm especially annoyed because I saw these in strace output, but the
previous version of webkit also used to try to look at chassis_type and
egl_vendor.d directories so I dismissed that too fast... It's possible
previous versions of webkit were also disabling compositing mode due to
the apparmor rules, but the new one fails to disable it properly when it
didn't find what it wanted there? If so I guess one could argue that's a
bug on its own)

> I think that Surf's AppArmor profile is just too restrictive for a
> program that has so many dependencies.

Right, I guess it's a tight line between trying to sandbox a web browser
and allowing all sort of things a web browser might need to do...
I'll leave follow-ups to Reiner (surf's maintainer), and definitely
remember about apparmor next time.

Thank you again for looking Alberto !

-- 
Dominique

Bug#1054150: Acknowledgement (surf: no longer display web pages after webkitgtk upgrades)

[Dominique Martinet]

This seems to be the same problem as reported for the 'tauri' web
browser here:
https://github.com/tauri-apps/tauri/issues/7927

They've reported a workaround of setting this variable, which I've
confirmed to work with surf as well:
WEBKIT_DISABLE_COMPOSITING_MODE=1

So something in the GPU acceleration code broke for small users of
webkitgtk...

I don't have much time to look further right now, but I'll keep looking
as time permits...

Thanks,
-- 
Dominique

Bug#1054150: surf: no longer display web pages after webkitgtk upgrades

[Dominique Martinet]

Package: surf
Version: 2.0+git20201107-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: dominique.marti...@atmark-techno.com

Dear Maintainer,

After upgrading my system to the latest security updates surf no longer 
displays anything.
The pages actually load, hovering on links shows the cursor changing and links 
can be clicked, but the page is blank

I've tested both in VMs on debian bullseye (this bug report) and debian stable 
on real hardware (2.1+git20221016-4), both exhibit the same issue.

For bullseye, this package upgrade reliably triggers the issue, and installing 
old packages back makes surf work again:
Unpacking libwebkit2gtk-4.0-37:amd64 (2.42.1-1~deb11u1) over (2.40.5-1~deb11u1) 
...
Unpacking libjavascriptcoregtk-4.0-18:amd64 (2.42.1-1~deb11u1) over 
(2.40.5-1~deb11u1) ...

Thanks you

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, armhf

Kernel: Linux 5.10.0-25-amd64 (SMP w/4 CPU threads)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 surf depends on:
ii  libc62.31-13+deb11u7
ii  libgcr-base-3-1  3.38.1-2
ii  libgcr-ui-3-13.38.1-2
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u3
ii  libjavascriptcoregtk-4.0-18  2.42.1-1~deb11u1
ii  libwebkit2gtk-4.0-37 2.42.1-1~deb11u1
ii  libx11-6 2:1.7.2-1+deb11u2

Versions of packages surf recommends:
ii  curl  7.74.0-1.3+deb11u10
ii  gnome-terminal [x-terminal-emulator]  3.38.3-1
ii  suckless-tools46-1
ii  x11-utils 7.7+5
ii  xterm [x-terminal-emulator]   366-1+deb11u1

Versions of packages surf suggests:
ii  apparmor  2.13.6-10

-- no debconf information

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Simon McVittie wrote on Thu, Jan 19, 2023 at 11:22:29AM +:
> 11.7 will not get gtk+3.0_3.24.34-5, regardless. The changes between
> 3.24.24 and 3.24.34 are too extensive to ask the release team to review
> them (1242 lines of changes in gtk/gtkimcontextsimple.c alone) and have
> triggered serious regressions in the past, although I hope all the known
> regressions are now fixed for Debian 12.

Ah, I had misread that as 24-4 -> 24-5 (or 34-4 -> 34-5), 24->34 is
indeed quite bigger; sorry or the confusion.

> What *could* go into either 11.7 or a later 11.x point release is a
> version derived from the version 3.24.24-4+deb11u2 currently in stable,
> with the change that fixes GLES-only platforms applied as a patch. It
> would end up versioned as 3.24.24-4+deb11u3, unless it gets preempted
> by an urgent security fix or something like that.

That'd be appreciated !

> Is upstream commit 0e5fe45ea20cce074a128911949dbedf4f8265bf, from
> , necessary
> and sufficient to fix this in the 3.24.24 codebase? Or are there other
> changes required?

Yes, that commit is necessary & sufficient for my use-case.

> If upstream !5062 is believed to be sufficient, please try building
> 
> (it can be built with git-buildpackage, or let me know if you need a
> complete source package), and verify that it solves the problem for you
> on your GLES-only device(s)/driver(s).

I'll try that today and report back directly on the MR.
While the build runs I've run a diff with the local package I've been
using since late September and changelog entry / name of the patch file
aside the content is identical, so I do not expect any problem for our
workload, but might as well make sure.

> Also, please check that what I've written in the changelog is accurate.
> I don't think I had fully realised until I looked again at this patch
> that while your bug report talks about GTK failing to use GL on GLES-only
> platforms and doesn't mention X11 vs. Wayland, your patch only changes
> the Wayland code path. From a quick look at gdk/x11/gdkglcontext-x11.c,
> it seems your change is making the Wayland/EGL code path match what
> X11/GLX already did, and so you could have worked around this bug with
> GDK_BACKEND=x11, except that presumably you'd prefer to have the benefits
> of using native Wayland?

The changelog entry looks good to me, I'll comment on salsa directly to
leave a trace.
I can confirm that affects only wayland, the purpose of this patch is to
allow epiphany(/WebkitGTK) to run in a kiosk environment and having less
moving parts is appreciable, we currently run without Xwayland so I did
not actually test the X11 backend.

> The other testing that is needed on this version is to confirm that
> it doesn't break anything on Debian 11 systems where "desktop" OpenGL
> *is* available, such as ordinary x86 PCs, and presumably also embedded
> systems that use Mesa (such as the etnaviv driver). I can try it on x86,
> but any testing you can do on this would also improve our confidence
> about this backport.

I'm afraid I also won't be of much help here; my understanding is that
it would also help there (in case both GL and GLES are available,
forcing GLES would still be querying GL for init properties and would
incorrectly try to use potentially missing extensions), but I do not
have any such system to test...
For a "more normal" x86/intel system I'm running bookworm so indirectly
have that patch through 3.24.36-1 and just tested various combinaisons
of setting GDK_GL=gles or not, wayland or native X11, and it all seems
to work properly.
(I'd test the proposed package, but I do not have any stable system with
a destkop environment available right now, sorry)


Thank you for your time and explanations, I'll follow up on salsa unless
prompted here.
-- 
Dominique

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Hi Simon,

Dominique Martinet wrote on Mon, Nov 28, 2022 at 11:47:07AM +0900:
> > I've added it to <https://wiki.debian.org/Gnome/BullseyeUpdates>.
> 
> Thank you!

Just a follow-up on this proposed updates mechanism -- it looks like
this wasn't included in the december 11.6 point update (as expected,
since we agreed to let it be tested for a bit), is there anything I
should/can do to make sure the next 11.7 gets gtk+3.0 3.24.34-5, or is
that still too early?

(there doesn't seem to be any plan for 11.7 yet, release.debian.org says
"maybe mid-February", but I assume it will be harder to justify adding
it once bookworm is released in a few more months and bullseye gets
branded oldstable so next release sounds optimal for me)


Thank you,
-- 
Dominique

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Simon McVittie wrote on Fri, Nov 25, 2022 at 05:00:11PM +:
> On Thu, 29 Sep 2022 at 08:42:40 +0900, Dominique Martinet wrote:
> > when using GTK on platforms with a GLES-only GL implementation like some
> > raspberry pi or iMX platforms with vivante driver, GTK fails to
> > initialize its GL stack because it tries to bind to regular GL first
> > anyway before using the correct API as configured.
> 
> I believe this is fixed in testing/unstable by 3.24.34-5 and 3.24.35,
> can you confirm?

Thank you!

Unfortunately our openGL stack depends on proprietary binaries that I
cannot easily run on bookworm :(

I also couldn't just build the bookworm source package on bullseye, so
this won't be of much help, but I've confirmed that code-wise both
3.24.34-5 (patch in debian/ directory) and 3.24.35 (patch in orig
source) should be correct.
I'm currently building a local package with just that patch in our
debian/ folder so this much is at least known to work but I'd like to
provide a better feedback.

I'll give a try to openGL on bookworm again in the next few days and
report back if I can get it to work.


> This seems like a change in sufficiently core code that I would want to
> watch for regressions in testing/unstable for some time before considering
> a backport.

Right -- happy to wait a bit.

>From my understanding of the code, the variable here would only be used
with `GDK_GL=gles` exported, and the only change here is briefly for
init to check a handful of egl extensions, so even if there are
platforms with both GL/GLES support and the variable is set to select
GLES the current result would be incorrect and things should only work
better.

As usual, the difference between theory and practice is practice, so
I agree we can/should give it a bit more time to get feedback first.

> I've added it to <https://wiki.debian.org/Gnome/BullseyeUpdates>.

Thank you!
-- 
Dominique

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Hi,

Dominique Martinet wrote on Thu, Sep 29, 2022 at 08:42:40AM +0900:
> when using GTK on platforms with a GLES-only GL implementation like some
> raspberry pi or iMX platforms with vivante driver, GTK fails to
> initialize its GL stack because it tries to bind to regular GL first
> anyway before using the correct API as configured.
> 
> This can be tested by running gtk3-demo and the OpenGL area demo, which
> will show nothing as no GL implementation could be found -- but it also
> affects real GTK applications like epiphany (gnome web).
> 
> This was reported upstream a couple of years ago:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/3028
> and I submitted a patch yesterday:
> https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5062

This merge request has been merged, so I'd like to move this bug forward:
https://gitlab.gnome.org/GNOME/gtk/-/commit/0e5fe45ea20cce074a128911949dbedf4f8265bf

Is there any opposition to backporting it to debian stable (eventually
on next point update as this isn't a security fix, I'm not sure what the
exact process is here) ?


I'll be happy to do the actual package update work (adding the patch,
verifying it applies etc) but I don't want to step on any toes, so any
input is appreciated :)

Thanks!
-- 
Dominique Martinet

Bug#983675: wev: Emits "invalid version" error at startup and consumes 100% CPU

[Dominique MARTINET]

I'd also like to use wev under weston.

For this particular error (invalid version for global xdg_wm_base (18):
have 1, wanted 2), we don't actually need xdg_wm_base version two in wev
(the only API we use here is xdg_wm_base_get_xdg_surface()) and the API
is backwards compatible, so just downgrading the requested version from
2 to 1 as follow fixes wev for me:


>From bdbad4e1e58d090654e2f5e804659bb8709f2f45 Mon Sep 17 00:00:00 2001
From: Dominique Martinet 
Date: Wed, 5 Oct 2022 11:19:27 +0900
Subject: [PATCH] protocols: lower xdg_wm_base requirement to 1

We do not need anything in API v2, and using the older v1 API makes wev
work on weston <= 9

diff --git a/wev.c b/wev.c
index 9d25491ba4b5..b0e7005b166b 100644
--- a/wev.c
+++ b/wev.c
@@ -811,7 +811,7 @@ static void registry_global(void *data, struct wl_registry 
*wl_registry,
{ _compositor_interface, 4, (void **)>compositor },
{ _seat_interface, 6, (void **)>seat },
{ _shm_interface, 1, (void **)>shm },
-   { _wm_base_interface, 2, (void **)>wm_base },
+   { _wm_base_interface, 1, (void **)>wm_base },
{ _data_device_manager_interface, 3,
(void **)>data_device_manager },
};


Note upgrading weston to version 10 or above would also fix the issue.

I'm not bothering to send this patch upstream as it would likely be
rejected (on the grounds of upstream weston already been upgraded), but
it would be great if we could add this patch to the debian stable
package.
(it's not needed for testing onwards, but it won't cause any harm there
either as far as I understand)


Thank you,
-- 
Dominique

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Hi Alberto, Sebastian,

Sebastian Krzyszkowiak wrote on Thu, Sep 29, 2022 at 06:15:56PM +0200:
> the patch that sets setAllowsServerPreconnect does not fix the
> original issue, however, this one does:
> https://github.com/WebKit/WebKit/pull/4790
> 
> With this applied on top of your recent backport of 2.38.0, WebKit
> becomes somewhat usable on arm64 in bullseye. It still crashes on some
> pages (such as Twitter), but in a different way (somewhere in JSC)
> which probably deserves a separate issue.

Thank you for finding this other PR -- I can confirm that fixes the
original issue which crashed almost immediately on any page, and also
confirm there are leftover crashes with a clang build on this patch.

Here's the backtrace I get:
(gdb) bt
#0  codeBlock () at ../Source/JavaScriptCore/interpreter/RegisterInlines.h:41
#1  codeBlock () at ../Source/JavaScriptCore/interpreter/CallFrameInlines.h:62
#2  operationArithNegateProfiledOptimize () at 
../Source/JavaScriptCore/jit/JITOperations.cpp:3361
#3  0x74148358 in ?? ()
#4  0x2ed44080 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

unfortunately it looks like gdb doesn't manage to unwind it properly (or
indeed corrupted), so that might be difficult to debug.

Since gcc build appears to fix the issue I think that's the way to go
for bullseye, at least until we understand where that makes a
difference...

Sebastian Krzyszkowiak wrote on Fri, Sep 30, 2022 at 01:01:55PM +0200:
> I can still see some backtraces showing up in logs due to preconnect
> attempts, so applying PR 4790 will likely still be a good idea, but it
> doesn't bring down the whole process anymore.

I agree on principle; out of curiousity where did you see these logs?
I do not see anything on stdout/stderr with the gcc build, but I would
assume this to be logged elsewhere or perhaps only if some magic env var
is set?

Thanks,
-- 
Dominique

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Dominique MARTINET wrote on Fri, Sep 30, 2022 at 01:26:03PM +0900:
> Alberto Garcia wrote on Thu, Sep 29, 2022 at 11:19:04AM +:
> > Hmmm... ok, this may be a bug in the compiler. The official Debian
> > builds are made using clang (because of bug #1008098), did you use
> > gcc?
> 
> Hm, that is not specified in the control or rule file?
> 
> I've triggered a fresh build to check and can confirm it's using gcc...
> Interesting that my build didn't fail on this (well, I guess ldd
> segfault was just as bad :-D)
> 
> I've had a quick look but wasn't able to figure how to build with clang
> to check -- would building the package with clang in CC/CXX suffice,
> e.g. `CC=clang CXX=clang++ dpkg-buildpackage` ?
> (that appears to do the job, I'll send a new mail on Monday if build
> didn't finish in time to test today)

build finished, tested -- I can reproduce ! :)

The build has been quite stable with gcc for me, so while I trust
Sebastian the patch he pointed at fixes the immediate issue I'll try to
rebuild with it as well and start looking at the next crashes.

(It's a bit annoying to take 3+ hours to build though so I might have a
stab at running from build dir again first though...)

Cheers,
-- 
Dominique

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Alberto Garcia wrote on Thu, Sep 29, 2022 at 11:19:04AM +:
> On Wed, Sep 28, 2022 at 08:58:28AM +0900, Dominique MARTINET wrote:
> > So I can confirm the same package as sid's 2.38.0-2 without any
> > extra patch works just fine if I recompile it -- so it must be a
> > difference in our build environment.
> 
> Hmmm... ok, this may be a bug in the compiler. The official Debian
> builds are made using clang (because of bug #1008098), did you use
> gcc?

Hm, that is not specified in the control or rule file?

I've triggered a fresh build to check and can confirm it's using gcc...
Interesting that my build didn't fail on this (well, I guess ldd
segfault was just as bad :-D)

I've had a quick look but wasn't able to figure how to build with clang
to check -- would building the package with clang in CC/CXX suffice,
e.g. `CC=clang CXX=clang++ dpkg-buildpackage` ?
(that appears to do the job, I'll send a new mail on Monday if build
didn't finish in time to test today)

> > Happy to send you the list of packages I have installed or anything
> > else that might be useful to track this down further!
> 
> Yes, that would be helpful.

Here's the full list (no more useful text after it):

adduser 3.118
adwaita-icon-theme  3.38.0-1
apt 2.2.4
at-spi2-core2.38.0-4
autoconf2.69-14
automake1:1.16.3-2
autopoint   0.21-4
autotools-dev   20180224.1+nmu1
base-files  11.1+deb11u5
base-passwd 3.5.51
bash5.1-2+deb11u1
binutils2.35.2-2
binutils-aarch64-linux-gnu  2.35.2-2
binutils-common:arm64   2.35.2-2
bison   2:3.7.5+dfsg-1
bsdextrautils   2.36.1-8+deb11u1
bsdutils1:2.36.1-8+deb11u1
bubblewrap  0.4.1-3
build-essential 12.9
bzip2   1.0.8-4
ca-certificates 20210119
ccache  4.2-1
clang   1:11.0-51+nmu5
clang-111:11.0.1-2
cmake   3.18.4-2+deb11u1
cmake-data  3.18.4-2+deb11u1
coreutils   8.32-4
cpp 4:10.2.1-1
cpp-10  10.2.1-6
dash0.5.11+git20200708+dd9ef66-5
dbus1.12.20-2
dbus-user-session   1.12.20-2
dconf-gsettings-backend:arm64   0.38.0-2
dconf-service   0.38.0-2
debconf 1.5.77
debhelper   13.3.4
debian-archive-keyring  2021.1.1
debianutils 4.11.2
dh-autoreconf   20
dh-strip-nondeterminism 1.12.0-1
dictionaries-common 1.28.4
diffutils   1:3.7-5
dirmngr 2.2.27-2+deb11u2
dmsetup 2:1.02.175-2.1
docbook 4.5-6
docbook-to-man  1:2.0.0-45
docbook-xml 4.5-9
docbook-xsl 1.79.2+dfsg-1
dpkg1.20.12
dpkg-dev1.20.12
dwz 0.13+20210201-1
e2fsprogs   1.46.2-2
eatmydata   105-9
emacsen-common  3.0.4
fakeroot1.25.3-1.1
file1:5.39-3
findutils   4.8.0-1
flex2.6.4-8
fontconfig  2.13.1-4.2
fontconfig-config   2.13.1-4.2
fonts-cantarell 0.111-3
fonts-dejavu-core   2.37-2
g++ 4:10.2.1-1
g++-10  10.2.1-6
gcc 4:10.2.1-1
gcc-10  10.2.1-6
gcc-10-base:arm64   10.2.1-6
gcc-9-base:arm649.3.0-22
gdb 10.1-1.7
gettext 0.21-4
gettext-base0.21-4
gir1.2-atk-1.0:arm642.36.0-2
gir1.2-atspi-2.0:arm64  2.38.0-4
gir1.2-cloudproviders-0.3.0:arm64   0.3.0-3
gir1.2-colord-1.0:arm64 1.4.5-3
gir1.2-

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Package: libgtk-3-0
Version: 3.24.24-4+deb11u2
Severity: wishlist
Tags: patch

Dear Maintainer,

when using GTK on platforms with a GLES-only GL implementation like some
raspberry pi or iMX platforms with vivante driver, GTK fails to
initialize its GL stack because it tries to bind to regular GL first
anyway before using the correct API as configured.

This can be tested by running gtk3-demo and the OpenGL area demo, which
will show nothing as no GL implementation could be found -- but it also
affects real GTK applications like epiphany (gnome web).

This was reported upstream a couple of years ago:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3028
and I submitted a patch yesterday:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5062
(note as said there, this is already fixed in gtk 4)

Assuming the patch does get positive feedback and gets merged (I'm not
asking to backport some code before upstream review!!), what would the
way forward be?
gtk3 hasn't had a point release since May, and bullseye didn't get
updated to the latest stable release, so I assume we could backport the
patch? Would that be acceptable?

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.145-0-at (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3+deb11u2
ii  libepoxy01.5.5-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-common  3.24.24-4+deb11u2
ii  libharfbuzz0b2.7.4-1
ii  libjson-glib-1.0-0   1.6.2-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  librest-0.7-00.8.1-1.1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon01.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 2.0-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin 3.24.24-4+deb11u2
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages libgtk-3-0 suggests:
pn  gvfs  

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
pn  ibus-gtk3 
pn  imhangul-gtk3 
pn  libcanberra-gtk3-module   
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#1020891: ltrace: enable arm/aarch64 builds

[Dominique Martinet]

Source: ltrace
Version: 0.7.3-6.3
Severity: normal

Dear Maintainer,

Using https://gitlab.com/cespedes/ltrace that you seem to maintain arm
and aarch64 versions of ltrace compile and work.

Would it be possible to consider cutting a new release and updating the
package in sid/bookworm for these archs?

Thank you

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.145-0-at (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Hello,

Dominique MARTINET wrote on Tue, Sep 27, 2022 at 01:58:40PM +0900:
> I will rebuild the package again without the patch, to check if I can
> reproduce the issue without it in my build environment.
> 
> That takes quite a while, so will probably only report back tomorrow.

So I can confirm the same package as sid's 2.38.0-2 without any extra
patch works just fine if I recompile it -- so it must be a difference in
our build environment.

Happy to send you the list of packages I have installed or anything else
that might be useful to track this down further!


(As a side note, it turns out that even when this does works, gdk opengl
context creation fails on my system because it apparently always try to
initialize the context as opengl first regardless of GLES setting so
this isn't as good as I was hoping... In particular the fallback code
rotates the rendered pixels by 180° for some reason so it's upside down,
but removing that as well is perfect if just a bit slow.
Hopefully I can figure that out next... Did I already say I hate closed
drivers?
But anyway that's unrelated to this bug: epiphany (and MiniBrowser) work
just fine at this point; and I'll open a bug upstream directly for the
fallback code)

-- 
Dominique

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Dominique MARTINET wrote on Tue, Sep 27, 2022 at 10:10:40AM +0900:
> (Or I guess I could actually build the deb package now I have ldd figured
> out, but allowing partial builds would be great for actual development...)

hmpf!

So I have rebuilt as a package, and it .. just works?

At this point I'm starting to think the build environment matters quite
a bit, would you mind comparing with what I'm doing:

- I do not have any beefy aarch64 machine, so building from a x86_64
host with qemu-user-static and binfmt

- in order to get the sysroot I just run inside a container:
podman run docker.io/arm64v8/debian:bullseye
(using a volume for build data)

- in that container I intalled all required dependencies with apt
build-dep in build tree, I don't think there is anything else, so it
should be similar to pdebuild

- there is a bug with ldd and qemu user: I replace ldd with the
following script
---
#!/bin/sh

lddtree "$@" 2>/dev/null \
| sed -e '/^[^ ]/d' -e 's/^  */\t/' \
-e 's/ld-linux-aarch64.so.1.*/ld-linux-aarch64.so.1/' \
-e 's/$/ (0x005501acc000)/'
---
This is used by g-ir-scanner afaiu; build fails for me without it.

- I used the upstream tarball
https://webkitgtk.org/releases/webkitgtk-2.38.0.tar.xz

- I used the debian directory from sid, with a few adjustments:
http://deb.debian.org/debian/pool/main/w/webkit2gtk/webkit2gtk_2.38.0-2.debian.tar.xz

diff -ur orig/debian/patches/series webkitgtk-2.38.0/debian/patches/series
--- orig/debian/patches/series  2022-09-26 18:25:41.0 +0900
+++ webkitgtk-2.38.0/debian/patches/series  2022-09-27 10:27:48.811885275 
+0900
@@ -5,3 +5,4 @@
 dont-detect-sse2.patch
 reduce-memory-overheads.patch
 fix-ftbfs-hurd.patch
+fix-bullseye.patch
diff -ur orig/debian/rules webkitgtk-2.38.0/debian/rules
--- orig/debian/rules   2022-09-26 18:25:41.0 +0900
+++ webkitgtk-2.38.0/debian/rules   2022-09-27 11:09:31.391250044 +0900
@@ -12,8 +12,8 @@
 # soup3 build -> 4.1 API packages
 # gtk4 build  -> 5.0 API packages
 ENABLE_SOUP2=YES
-ENABLE_SOUP3=YES
-ENABLE_GTK4=YES
+ENABLE_SOUP3=NO
+ENABLE_GTK4=NO
 # Set to YES to use the docs from the tarball instead of generating them.
 # Use only if gi-docgen is not available.
 USE_PREBUILT_DOCS=NO
diff -ur orig/debian/control.in webkitgtk-2.38.0/debian/control.in
--- orig/debian/control.in  2022-09-26 18:25:41.0 +0900
+++ webkitgtk-2.38.0/debian/control.in  2022-09-27 11:11:07.441672820 +0900
@@ -51,7 +51,7 @@
libegl1-mesa-dev,
libgl-dev,
libgles-dev
-Build-Depends-Indep: gi-docgen, libglib2.0-doc, libgtk-3-doc, libsoup2.4-doc
+Build-Depends-Indep: libglib2.0-doc, libgtk-3-doc, libsoup2.4-doc
 Standards-Version: 4.6.1.0
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/webkit-team/webkit
-

+ fix-bullseye.patch as per link
-
--- a/Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp 
+++ a/Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp 
@@ -498,6 +498,9 @@ WebKit::WebsiteDataStore& 
webkitWebsiteDataManagerGetDataStore(WebKitWebsiteData
 
configuration->setServiceWorkerRegistrationDirectory(FileSystem::stringFromFileSystemRepresentation(priv->swRegistrationsDirectory.get()));
 if (priv->domCacheDirectory)
 
configuration->setCacheStorageDirectory(FileSystem::stringFromFileSystemRepresentation(priv->domCacheDirectory.get()));
+#if !ENABLE(SERVER_PRECONNECT)
+configuration->setAllowsServerPreconnect(false);
+#endif
 priv->websiteDataStore = 
WebKit::WebsiteDataStore::create(WTFMove(configuration), 
PAL::SessionID::generatePersistentSessionID());
 priv->websiteDataStore->setIgnoreTLSErrors(priv->tlsErrorsPolicy == 
WEBKIT_TLS_ERRORS_POLICY_IGNORE);
 }
-

- I built without documentation because no gi-docgen:
DEB_BUILD_OPTIONS=nodoc dpkg-buildpackage


With that package, epiphany works just fine.


I will rebuild the package again without the patch, to check if I can
reproduce the issue without it in my build environment.

That takes quite a while, so will probably only report back tomorrow.


Thanks,
-- 
Dominique

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Alberto Garcia wrote on Mon, Sep 26, 2022 at 07:44:24AM +:
> > I've tried the patched variant, it seems to fail in the same place?
> 
> Ok, thanks. I uploaded the unpatched version, although I suspect it's
> not going to make any difference.

I agree it shouldn't make any difference : I tried anyway, and can
confirm I hit the same trace.

I've also finally finished building yesterday (the last failure I was
referring to wasn't the badly escaped argument -- that was just a
warning -- but ldd segfaulting on qemu-user aarch64 on the webkit so,
presumably because it is too big? I've replaced it with a wrapper around
lddtree and could finish building...), but unfortunately I run into a
different crash before I can test this; I suspect this is due to my
build options, I will try to get closer to the deb package options...
(Or I guess I could actually build the deb package now I have ldd figured
out, but allowing partial builds would be great for actual development...)


I'll report again when/if I make progress, thanks for the follow up and
packages :)

-- 
Dominique

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Alberto Garcia wrote on Mon, Sep 26, 2022 at 12:00:04AM +:
> I just uploaded the packages built for bullseye, same URL, the patched
> ones are available already, the unpatched ones soon.

Thanks!

I've tried the patched variant, it seems to fail in the same place?

Here's the new trace with adjusted lines:

/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x817b3aa0 in __GI_abort () at abort.c:79
#2  0x8427958c in WTFCrashWithInfo(int, char const*, char const*, int) 
() at WTF/Headers/wtf/Assertions.h:754
#3  0x8525db20 in captureStackTrace () at 
../Source/WTF/wtf/StackTrace.cpp:79
#4  0x85232d18 in WTFReleaseLogStackTrace () at 
../Source/WTF/wtf/Assertions.cpp:602
#5  0x884e8934 in internalError () at 
../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0x869e6c14 in preconnectTo () at 
../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:733
#7  0x8689baf8 in 
callMemberFunctionImpl
 >, WebKit::NetworkResourceLoadParameters&&), 
std::tuple >, 
WebKit::NetworkResourceLoadParameters>, 0, 1> () at 
../Source/WebKit/Platform/IPC/HandleMessage.h:131
#8  callMemberFunction
 >, WebKit::NetworkResourceLoadParameters&&), 
std::tuple >, 
WebKit::NetworkResourceLoadParameters>, std::integer_sequence > () at ../Source/WebKit/Platform/IPC/HandleMessage.h:137
#9  handleMessage
 >, WebKit::NetworkResourceLoadParameters&&)> () at 
../Source/WebKit/Platform/IPC/HandleMessage.h:259
#10 didReceiveNetworkConnectionToWebProcessMessage () at 
DerivedSources/WebKit/NetworkConnectionToWebProcessMessageReceiver.cpp:357
#11 0x86b3ff1c in dispatchMessage () at 
../Source/WebKit/Platform/IPC/Connection.cpp:1150
#12 0x86b402b4 in dispatchOneIncomingMessage () at 
../Source/WebKit/Platform/IPC/Connection.cpp:1219
#13 0x8525c4b0 in operator() () at ../Source/WTF/wtf/Function.h:82
#14 performWork () at ../Source/WTF/wtf/RunLoop.cpp:133
#15 0x852b5570 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:80
#16 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:79
#17 0x852b48f4 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#18 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#19 0x81d25ab4 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#20 0x81d25e5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#21 0x81d261b0 in g_main_loop_run () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#22 0x852b4ef8 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#23 0x86b11004 in run () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:71
#24 AuxiliaryProcessMain () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:97
#25 0x817b3e18 in __libc_start_main (main=0x400878 <__wrap_main>, 
argc=3, argv=0xcfa17918, init=, fini=, 
rtld_fini=, stack_end=) at 
../csu/libc-start.c:308
#26 0x00400874 in _start ()



/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xa0afdaa0 in __GI_abort () at abort.c:79
#2  0xa35c358c in WTFCrashWithInfo(int, char const*, char const*, int) 
() at WTF/Headers/wtf/Assertions.h:754
#3  0xa45a7b20 in captureStackTrace () at 
../Source/WTF/wtf/StackTrace.cpp:79
#4  0xa457cd18 in WTFReleaseLogStackTrace () at 
../Source/WTF/wtf/Assertions.cpp:602
#5  0xa7832934 in internalError () at 
../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0xa61e6f6c in internallyFailedLoadTimerFired () at 
../Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:503
#7  0xa45ff61c in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:177
#8  __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:169
#9  0xa45fe8f4 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#10 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#11 0xa106fab4 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#12 0xa106fe5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#13 0xa10701b0 in g_main_loop_run () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#14 0xa45feef8 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#15 0xa62a1aac in run () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:71
#16 AuxiliaryProcessMain () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:97
#17 0xa0afde18 in __libc_start_main (main=0x400878 <__wrap_main>, 
argc=3, argv=0xc73c1cc8, init=, fini=, 
rtld_fini=, stack_end=) at 
../csu/libc-start.c:308
#18 0x00400874 in _start ()


Since the patched variant does not resolve the problem I'm not going to
bother with the unpatched -- please ask if you'd like me to try anyway.


Meanwhile 

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Hi,

Alberto Garcia wrote on Fri, Sep 23, 2022 at 12:38:58AM +0200:
> I built two sets of packages, the unpatched vanilla version of
> 2.38.0 and the one with the patch I mentioned in my previous comment:
> 
> https://people.debian.org/~berto/files/webkitgtk-2.38.0-arm64/
> 
> Can you test them both and tell me if things get better?

Thanks!
You were indeed faster than me... But it looks like these packages were
built for debian testing/bookworm (require libc6 >= 2.34), so I cannot
test easily due to proprietary libGL and other drivers woes.

(I actually do have some frankendebian version for testing, I'll give it
a try on Monday, but this will not necessarily have the same problems as
what I had reported here on stable/bullseye)


I should get access to a beefier machine at work and will resume my
building attempts there, and report with both tests (the packages you
provided on bookworm and stable package with patch) hopefully by the end
of Monday.

-- 
Dominique

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Hi Alberto,

Alberto Garcia wrote on Wed, Sep 21, 2022 at 12:54:22PM +0200:
> On Fri, Sep 16, 2022 at 10:18:32AM +0900, Dominique MARTINET wrote:
> > The traces are slightly different:
> > 
> > /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
> > (gdb) bt
> > #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > #1  0x7cfdfaa0 in __GI_abort () at abort.c:79
> > #2  0x7fa8ac50 in WTFCrashWithInfo(int, char const*, char const*, 
> > int) () at WTF/Headers/wtf/Assertions.h:741
> > #3  0x80a2d5a8 in captureStackTrace () at 
> > ../Source/WTF/wtf/StackTrace.cpp:79
> > #4  0x80a08ea0 in WTFReleaseLogStackTrace () at 
> > ../Source/WTF/wtf/Assertions.cpp:592
> > #5  0x83c06550 in internalError () at 
> > ../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
> > #6  0x820e8d1c in preconnectTo () at 
> > ../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:735
> 
> do you think you can try this patch?
> 
>
> https://bug-244026-attachments.webkit.org/attachment.cgi?id=462492=diff=raw=1

Thanks!

> If you have problems / are unsure about how to build WebKit I can
> provide packages for you. Just let me know.

I'm definitely unsure about how to build WebKit, but that can be
fixed... I might need to find somewhere with a bit more memory though,
been trying to build the 2.38 release yesterday and build got OOM killed
even with -j1 on a VM with 6GB of ram :/

If you have time to build a package you might be faster than me, so I'd
appreciate it :)

-- 
Dominique

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

roblem is the same and having debug symbols
installed will help pinpoint what's wrong.

(a likely reason it's different is I run with WEBKIT_FORCE_SANDBOX=0
because the sandbox forbids access to GPU driver /dev non-standard
node... but honestly at this point it could be completely different,
I wasn't sure if I should open a new bug report or not :/)

I've downloaded the sources and will start looking into it as free time
permits.


Thanks,
-- 
Dominique Martinet

Bug#1012601: wireless-regdb: alternative broken on debian-installer install

[Dominique Martinet]

Ben Hutchings wrote on Thu, Jun 30, 2022 at 02:08:24AM +0200:
> > Sorry this wasn't clear. I didn't mean obsolete as no longer useful,
> > just that it is old: wireless-regdb-udeb hasn't been updated in two
> > years, while the main wireless-regdb package keeps getting updates
> > regularly.
> 
> You are comparing wireless-regdb-udeb in stable with wireless-regdb in
> unstable.
> 
> Both the regular and udeb packages are outdated in stable, but this
> should be fixed in the next point release.

Ah, sorry I didn't realize they had the same source package.

> > Yeah, it probably makes more sense to just remove whatever was there in
> > the post-install script.
> > I'll leave the resolution to you unless you want/need help with
> > something.
> 
> That is what I've now implemented.

I've had a look at the postinst script[1] after the automated
notification and it looks good to me, thank you.

[1] 
https://salsa.debian.org/kernel-team/wireless-regdb/-/blob/master/debian/wireless-regdb.postinst

-- 
Dominique

Bug#1012601: wireless-regdb: alternative broken on debian-installer install

[Dominique Martinet]

Ben Hutchings wrote on Mon, Jun 13, 2022 at 04:39:23PM +0200:
> On Fri, 2022-06-10 at 09:39 +0900, Dominique Martinet wrote:
> > the udeb regdb is also slightly obsolete, I'm not sure why it was needed
> > in the first place but it might be possible to use the normal package
> > instead?
> 
> Why do you think it's obsolete?  It is useful to have this file present
> in the installer.

Sorry this wasn't clear. I didn't mean obsolete as no longer useful,
just that it is old: wireless-regdb-udeb hasn't been updated in two
years, while the main wireless-regdb package keeps getting updates
regularly.

That means it's possible a firmware that requires the updated version
to work for new band regulations will not have access to these bands
for IR.

Note that for clients (installer usecase), it _also_ doesn't matter: if
an AP uses regulated bands, the client will (should?) rightfully use
these. Regulations mean a wireless emetter cannot start broadcasting on
regulated bands unless they know it's safe, but if an access point or
other clients use the band they can tell it's OK and will allow it.
The regdb will thus only matter for people setting up hotspots or AP on
their system, or perhaps if the remote AP is also missing its regdb but
I'm not sure how the ssid would come up then.
(At least, the marvell/NXP chip I've tested this with does that
properly; there can be other aspects to regdb I'm not aware of or didn't
understand)

In that sense, removing the firmware from installer also should not make
a difference to most users, but I'm not suggesting to remove it in this
bug as I'm sure there was a reason for it to be added in the first place.

I'd just like post-install systems which install the package to get the
new version :)

> > That won't fix existing systems though.
> > If wireless-regdb had been owning the files in dpkg it would be fair
> > game to just overwrite the files (dpkg overwrites any untracked file
> > when installing a package that provides the path).
> > 
> > Would it make sense to include regulatory.db -> regulatory.db-debian
> > (+same for p7s) links in the package itself, so package installation
> > overwrites these and the post update-alternative step fixes it?
> > It seems to fix "broken" links without force in this case.
> > (or push real links to /etc/alternatives/regulatory.db would work too)
> 
> I don't think it's right to include symlinks in the package that are
> supposed to be managed by update-alternatives.  I would rather fix this
> up in the postinst script.

Yeah, it probably makes more sense to just remove whatever was there in
the post-install script.
I'll leave the resolution to you unless you want/need help with
something.

-- 
Dominique

Bug#1012601: wireless-regdb: alternative broken on debian-installer install

[Dominique Martinet]

ller.d/50install-firmware#L14
 - it copies /lib/firmware content in base post-install step

the udeb regdb is also slightly obsolete, I'm not sure why it was needed
in the first place but it might be possible to use the normal package
instead?

That won't fix existing systems though.
If wireless-regdb had been owning the files in dpkg it would be fair
game to just overwrite the files (dpkg overwrites any untracked file
when installing a package that provides the path).

Would it make sense to include regulatory.db -> regulatory.db-debian
(+same for p7s) links in the package itself, so package installation
overwrites these and the post update-alternative step fixes it?
It seems to fix "broken" links without force in this case.
(or push real links to /etc/alternatives/regulatory.db would work too)


Thanks,
-- 
Dominique Martinet

Bug#869596: libconfig: New upstream version 1.6 on github available

[Dominique MARTINET]

Hi,

On Mon, 24 Jul 2017 22:18:32 +0100 Jonathan McCrohan  
wrote:
> Source: libconfig
> Followup-For: Bug #869596
> 
> I am aware of this, but libconfig 1.6 is not suitable for upload to
> Debian right now. At the most basic level, the SONAME has not been
> bumped despite ABI breakage [1]. This is outstanding for 18 months at
> this stage, and the original upstream maintainer even advises people to
> revert to 1.5 for now [2].
> 
> Until these issues are fixed, I do not plan on uploading libconfig 1.6
> to Debian.
> 
> [1] https://github.com/hyperrealm/libconfig/issues/49
> [2] https://github.com/hyperrealm/libconfig/issues/47#issuecomment-220809446

Since then libconfig 1.7.2 has been released in 11/2017 which bumps the
soname to so.11 and both issues have been closed.

bullseye is in hard freeze now so now is probably not the best time
debian-wise, but I guess nothing prevents from updating libconfig in sid
and prepare for the next release.

The changelog[1] has plenty of fixes and changes, in particular I would
have liked to rely on the more lenient syntax for trailing commas on
list and arrays, but unfortunately it doesn't look like I will be able
to...

[1] https://github.com/hyperrealm/libconfig/blob/master/ChangeLog


I'm actually rather bad with debian but I did a local build with the
following debian directory[2] successfully, if that helps (based on the
1.5-0.4 package, renaming things from 9 to 11 as I could).
Since the soname was bumped both can be installed in parallel with no
problem.

Feel free to use part of all of it if you'd like.

[2] https://codewreck.org/debian/libconfig_1.7.2-1.debian.tar.xz


Thanks,
-- 
Dominique

Bug#981010: rxvt-unicode: urxvt segfaults at exit

[Dominique Martinet]

FWIW I have the same error on (PE)RL_DESTRUCT_LEVEL here:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __GI_getenv (name=0x7fcd3fea700d "RL_DESTRUCT_LEVEL") at getenv.c:84
(gdb) bt
#0  __GI_getenv (name=0x7fcd3fea700d "RL_DESTRUCT_LEVEL") at getenv.c:84
#1  0x7fcd3fd4a563 in perl_destruct () from 
/lib/x86_64-linux-gnu/libperl.so.5.32
#2  0x557110f65845 in rxvt_perl_interp::~rxvt_perl_interp() ()
#3  0x7fcd3fb294d7 in __run_exit_handlers (status=0, listp=0x7fcd3fca9718 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:108
#4  0x7fcd3fb2967a in __GI_exit (status=) at exit.c:139
#5  0x7fcd3fb11d11 in __libc_start_main (main=0x557110f41230 , 
argc=1, argv=0x7fff0b0ae308, init=, fini=, 
rtld_fini=, stack_end=0x7fff0b0ae2f8) at ../csu/libc-start.c:342
#6  0x557110f4557a in _start ()



Since it's in perl I would expect some extension to be required to have
that crash?


Anyway, it looks like opensuse has a patch for it since a couple of months
ago:

https://github.com/bmwiedemann/openSUSE/blob/5c5842c9dda0ca970847167c3710d96b0d9e4dfd/packages/r/rxvt-unicode/rxvt-unicode-9.22-perl_environ_segfault.patch
(copied here for archive purpose, credits to Marcus Huewe )
--- a/src/rxvtperl.xs.orig
+++ b/src/rxvtperl.xs
@@ -376,6 +376,7 @@ rxvt_perl_interp::~rxvt_perl_interp ()
 {
   if (perl)
 {
+  localise_env set_environ (perl_environ);
   perl_destruct (perl);
   perl_free (perl);
   PERL_SYS_TERM ();


Please consider the patch for inclusion as well!
-- 
Dominique Martinet | Asmadeus

Bug#876318: kexec-tools: fails to parse kcore on 4.1.2.0

[Dominique Martinet]

Package: kexec-tools
Version: 1:2.0.14-1
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
Tying to load a kexec kernel fails with this kind of errors:

Starting kdump-tools:
Unknown type (Reserved) while parsing /sys/firmware/memmap/5/type. Please 
report this as bug. Using RANGE_RESERVED now.
Unknown type (Reserved) while parsing /sys/firmware/memmap/1/type. Please 
report this as bug. Using RANGE_RESERVED now.
Unknown type (Reserved) while parsing /sys/firmware/memmap/6/type. Please 
report this as bug. Using RANGE_RESERVED now.
Unknown type (Reserved) while parsing /sys/firmware/memmap/4/type. Please 
report this as bug. Using RANGE_RESERVED now.
Unknown type (Reserved) while parsing /sys/firmware/memmap/2/type. Please 
report this as bug. Using RANGE_RESERVED now.
ELF core (kcore) parse failed
Cannot load /var/lib/kdump/vmlinuz
failed to load kdump kernel ... failed!
failed to load kdump kernel

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Upgrading to 2.0.15 fixes the issue upstream.

(fwiw, ubuntu appears to have done a similar upgrade recently as well,
here:
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5245110.html
)


-- System Information:
Distributor ID: PureOS
Description:PureOS GNU/Linux 8
Release:8
Codename:   green
Architecture: x86_64

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

Versions of packages kexec-tools depends on:
ii  debconf   1.5.63
ii  libc6 2.24-17
ii  lsb-base  9.20161125
ii  zlib1g1:1.2.8.dfsg-5

kexec-tools recommends no packages.

kexec-tools suggests no packages.

-- debconf information excluded

Bug#688929: parallel: config file leads to non-standard behaviour

[Dominique Martinet]

Hi,

Ondřej Surý wrote on Fri, Sep 28, 2012 :
 On Fri, Sep 28, 2012 at 4:17 AM, Rogério Brito rbr...@ime.usp.br wrote:
  (*) Perhaps one situation to accomodate both behaviors would be to check
  (both by moreutils and GNU parallel) if the program was invoked as, say,
  gparallel or tparallel and take some appropriate measure, but that's for
  later, not in a freeze.
 
 I would suggest README.Debian notice (if not already there) and remove
 the default option on NEW installs in wheezy+1 with NEWS.Debian notice
 how to re-enable old behaviour. Also we need to check for rev-deps (if
 any).
 
 Nothing like that can be done in freeze.

I don't know what can or can't be done in freeze, but I've been using
GNU Parallel for quite a while (thanks for this great tool!) and
recently tried to use it on debian...
Well, I've got too say I'm rather unhappy at how long it took me to
finally figure it was just a configuration file somewhere added for
legacy. I probably would never have found about it without the bugs in
here, actually.

I'd much rather have a big fat conflict with clear package names than
spending hours finding out that this bug was actually a feature. It's
not the first time two packages provide programs with the same names,
and people can live with either or manually install one in the very
unlikely case they need both.


I know this mail isn't exactly helpful, but I just felt like ranting as
well ;)


Regards,
-- 
Asmadeus | Dominique Martinet


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