Acknowledgement sent
to Christoph Anton Mitterer <calestyo@scientia.net>:
New Bug report received and forwarded. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Tue, 10 Jul 2018 21:03:04 GMT) (full text, mbox, link).
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: gimp: completely broken
Date: Tue, 10 Jul 2018 22:59:04 +0200
Package: gimp
Version: 2.10.2-1
Severity: grave
Justification: renders package unusable
Hi.
Since some time the GIMP is completely broken.
In most cases it does not even start (e.g. when invoking
it from another program) or when:
$ gimp
or
$ gimp 0.jpg
(with 0.jpg not existing)
it simply hangs (with no GUI coming up)
when doing e.g.:
$ gimp Screenshot\ from\ 2018-06-02\ 04-36-57.png
Missing fast-path babl conversion detected, Implementing missing babl fast paths
accelerates GEGL, GIMP and other software using babl, warnings are printed on
first occurance of formats used where a conversion has to be synthesized
programmatically by babl based on format description
*WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double"
GIMP-Error: Unable to run plug-in "plugin-uncrop.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-resynth-sharpen.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-resynth-sharpen.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-resynth-fill-pattern.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-resynth-fill-pattern.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-resynth-enlarge.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-resynth-enlarge.py)
Failed to execute child process “python” (No such file or directory)
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
GIMP-Error: Unable to run plug-in "plugin-map-style.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-map-style.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-heal-transparency.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-heal-transparency.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-heal-selection.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-heal-selection.py)
Failed to execute child process “python” (No such file or directory)
One get's these weird python errors...
Even when Ctrl+C or killall gimp and so on, processes like:
10423 ? Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 35 33 -run 0
10443 ? Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 39 37 -run 0
10556 ? Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 47 45 -run 0
10571 ? Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 51 49 -run 0
are left behind
Trying to open or save files from within gimp, often leads to the GUI simply
hanging.
And even tools like the Free Select Tool are broken... on can start a selection
but not connect the two endpoints.
All this happens even with .config/GIMP and friends completel removed.
Cheers,
Chris.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gimp depends on:
ii gimp-data 2.10.2-1
ii libaa1 1.4p5-44+b2
ii libbabl-0.1-0 0.1.50-1
ii libbz2-1.0 1.0.6-8.1
ii libc6 2.27-4
ii libcairo2 1.15.10-3
ii libfontconfig1 2.13.0-5
ii libfreetype6 2.8.1-2
ii libgcc1 1:8.1.0-9
ii libgdk-pixbuf2.0-0 2.36.11-2
ii libgegl-0.4-0 0.4.2-1
ii libgexiv2-2 0.10.8-1
ii libgimp2.0 2.10.2-1
ii libglib2.0-0 2.56.1-2
ii libgs9 9.22~dfsg-2.1
ii libgtk2.0-0 2.24.32-2
ii libgudev-1.0-0 232-2
ii libharfbuzz0b 1.8.2-2
ii libheif1 1.3.2-1
ii libilmbase23 2.2.1-2
ii libjpeg62-turbo 1:1.5.2-2+b1
ii liblcms2-2 2.9-2
ii liblzma5 5.2.2-1.3
ii libmng1 1.0.10+dfsg-3.1+b5
ii libmypaint-1.3-0 1.3.0-2
ii libopenexr23 2.2.1-4
ii libopenjp2-7 2.3.0-1
ii libpango-1.0-0 1.42.1-2
ii libpangocairo-1.0-0 1.42.1-2
ii libpangoft2-1.0-0 1.42.1-2
ii libpng16-16 1.6.34-2
ii libpoppler-glib8 0.63.0-2
ii librsvg2-2 2.40.20-2
ii libstdc++6 8.1.0-9
ii libtiff5 4.0.9-6
ii libwebp6 0.6.1-2
ii libwebpdemux2 0.6.1-2
ii libwebpmux3 0.6.1-2
ii libwmf0.2-7 0.2.8.4-12
ii libx11-6 2:1.6.5-1
ii libxcursor1 1:1.1.15-1
ii libxext6 2:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxmu6 2:1.1.2-2
ii libxpm4 1:3.5.12-1
ii xdg-utils 1.1.3-1
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages gimp recommends:
ii ghostscript 9.22~dfsg-2.1
Versions of packages gimp suggests:
ii gimp-data-extras 1:2.0.2-1
ii gimp-help-de [gimp-help] 2.8.2-0.1
ii gimp-help-en [gimp-help] 2.8.2-0.1
pn gimp-python <none>
ii gvfs-backends 1.36.1-1+b1
ii libasound2 1.1.6-1
-- no debconf information
Acknowledgement sent
to Jeremy Bicha <jbicha@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Tue, 10 Jul 2018 21:24:05 GMT) (full text, mbox, link).
To: Christoph Anton Mitterer <calestyo@scientia.net>, 903514@bugs.debian.org
Subject: Re: Bug#903514: gimp: completely broken
Date: Tue, 10 Jul 2018 17:20:36 -0400
On Tue, Jul 10, 2018 at 4:59 PM, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> Since some time the GIMP is completely broken.
I don't know. It works fine here. Could you try to be more specific
about *when* things stopped working?
> GIMP-Error: Unable to run plug-in "plugin-uncrop.py"
> (/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py)
>
> Failed to execute child process “python” (No such file or directory)
Does it help if you install gimp-python?
Do you have anything unusual with your python install? Does python
otherwise work?
Thanks,
Jeremy Bicha
Acknowledgement sent
to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Tue, 10 Jul 2018 21:39:10 GMT) (full text, mbox, link).
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Jeremy Bicha <jbicha@debian.org>, 903514@bugs.debian.org
Subject: Re: Bug#903514: gimp: completely broken
Date: Tue, 10 Jul 2018 23:32:02 +0200
On Tue, 2018-07-10 at 17:20 -0400, Jeremy Bicha wrote:
> I don't know. It works fine here. Could you try to be more specific
> about *when* things stopped working?
I'm afraid I have no idea... I noticed it a week ago, which doesn't
mean though, that it wasn't introduced earlier.
Wasn't there recently some change in the python packaging, when Python
2 was split out into python2* packages (which the normal "python*"
packages depend upon however)?
> Does it help if you install gimp-python?
Hmm, at least not at a first glance...
When starting plain:
$ gimp
or when opening some
$ gimp foo.png
it hangs at it's GUI splash screen at "python-eval.py".
After Ctrl+C there's a
24556 pts/6 Sl 0:00 /usr/bin/python2 /usr/lib/gimp/2.0/plug-ins/python-eval.py -gimp 14 13 -query 0
left.
> Do you have anything unusual with your python install?
Nothing that I'd know of (I'm actually not using Python myself, so it's
only plain package installations as required for dependencies)
> Does python
> otherwise work?
It seems so... or at least soooo many other things in a normal desktop
Debian use python... nothing of that shows any issues recently.
Thanks!
Acknowledgement sent
to Harald Wenninger <debian-bugreport@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Thu, 12 Jul 2018 07:30:03 GMT) (full text, mbox, link).
To: Debian Bug Tracking System <903514@bugs.debian.org>
Subject: gimp doesn’t start up and segfaults when interrupted
Date: Thu, 12 Jul 2018 09:20:21 +0200
Package: gimp
Version: 2.10.2-1
Followup-For: Bug #903514
Dear Maintainer,
I have the same problem.
Last week gimp was functioning normally, now it doesn’t even start up
and segfaults when interrupted by Ctrl+C.
My python installation is fully functional, I use python every day.
Regards,
Harald
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gimp depends on:
ii gimp-data 2.10.2-1
ii libaa1 1.4p5-44+b2
ii libbabl-0.1-0 1:0.1.52-dmo1
ii libbz2-1.0 1.0.6-8.1
ii libc6 2.27-4
ii libcairo2 1.15.10-3
ii libfontconfig1 2.13.0-5
ii libfreetype6 2.8.1-2
ii libgcc1 1:8.1.0-9
ii libgdk-pixbuf2.0-0 2.36.11-2
ii libgegl-0.4-0 1:0.4.4-dmo1
ii libgexiv2-2 0.10.8-1
ii libgimp2.0 2.10.2-1
ii libglib2.0-0 2.56.1-2
ii libgs9 9.22~dfsg-2.1
ii libgtk2.0-0 2.24.32-2
ii libgudev-1.0-0 232-2
ii libharfbuzz0b 1.8.2-2
ii libheif1 1.3.2-1
ii libilmbase23 2.2.1-2
ii libjpeg62-turbo 1:1.5.2-2+b1
ii liblcms2-2 2.9-2
ii liblzma5 5.2.2-1.3
ii libmng1 1.0.10+dfsg-3.1+b5
ii libmypaint-1.3-0 1:1.3.0-dmo6
ii libopenexr23 2.2.1-4
ii libopenjp2-7 2.3.0-1
ii libpango-1.0-0 1.42.1-2
ii libpangocairo-1.0-0 1.42.1-2
ii libpangoft2-1.0-0 1.42.1-2
ii libpng16-16 1.6.34-2
ii libpoppler-glib8 0.63.0-2
ii librsvg2-2 2.40.20-2
ii libstdc++6 8.1.0-9
ii libtiff5 4.0.9-6
ii libwebp6 0.6.1-2
ii libwebpdemux2 0.6.1-2
ii libwebpmux3 0.6.1-2
ii libwmf0.2-7 0.2.8.4-12
ii libx11-6 2:1.6.5-1
ii libxcursor1 1:1.1.15-1
ii libxext6 2:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxmu6 2:1.1.2-2
ii libxpm4 1:3.5.12-1
ii xdg-utils 1.1.3-1
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages gimp recommends:
ii ghostscript 9.22~dfsg-2.1
Versions of packages gimp suggests:
pn gimp-data-extras <none>
pn gimp-help-en | gimp-help <none>
ii gimp-python 2.10.2-1
pn gvfs-backends <none>
ii libasound2 1.1.6-1
-- no debconf information
Acknowledgement sent
to James Van Zandt <jim.vanzandt@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Sat, 14 Jul 2018 17:48:03 GMT) (full text, mbox, link).
Package: gimp
Version: 2.10.2-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I may have the same problem. I updated many packages yesterday, and today
gimp will not launch.
Christoph reported that opening a .png file generated a splash screen
then error messages about babl and python. However, I get nothing (no
error message or splash screen) for any of these:
gimp
gimp foo.png # file does not exist
gimp g14601.png # file does exist
In each case, I got a segfault when I interrupted with ^C:
home:~$ gimp foo.png
^CSegmentation fault (core dumped)
I initially did not have gimp-python installed, but installing it didn't
help.
I then tried launching gimp with strace:
strace -o /tmp/log gimp
This time I got a splash screen (the first one I'd seen), with a progress
bar
stuck at 70%, the progress statement
Querying new Plug-ins
resynthesizer
plus these messages:
GEGL-Message: 12:45:41.515: Module
'/usr/lib/x86_64-linux-gnu/gegl-0.4/ff-load.so' load error:
/usr/lib/x86_64-linux-gnu/libhogweed.so.4: undefined symbol:
__gmpn_cnd_sub_n
GEGL-Message: 12:45:41.534: Module
'/usr/lib/x86_64-linux-gnu/gegl-0.4/ff-save.so' load error:
/usr/lib/x86_64-linux-gnu/libhogweed.so.4: undefined symbol:
__gmpn_cnd_sub_n
Missing fast-path babl conversion detected, Implementing missing babl
fast paths
accelerates GEGL, GIMP and other software using babl, warnings are
printed on
first occurance of formats used where a conversion has to be synthesized
programmatically by babl based on format description
*WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double"
The strace file showed that the last file opened was
/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py:
home:~$ grep -n "open" /tmp/log |tail -22
39878:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/cml-explorer",
O_RDONLY) = 14
39961:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/checkerboard",
O_RDONLY) = 14
40059:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/cartoon", O_RDONLY) =
14
40147:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/border-average",
O_RDONLY) = 14
40250:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/blur", O_RDONLY) = 14
40317:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/blinds", O_RDONLY) = 14
40413:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/animation-play",
O_RDONLY) = 14
40505:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/animation-optimize",
O_RDONLY) = 14
40712:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/align-layers",
O_RDONLY) = 14
40799:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/webexport", O_RDONLY)
= 14
40912:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_trans",
O_RDONLY) = 14
41229:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_resynth",
O_RDONLY) = 14
41337:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_opacity",
O_RDONLY) = 14
41441:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_color_levels",
O_RDONLY) = 14
41613:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_color_huesat",
O_RDONLY) = 14
41765:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/wavelet-denoise",
O_RDONLY) = 14
41874:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/streak", O_RDONLY) = 14
41955:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/separate_import",
O_RDONLY) = 14
42063:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/separate", O_RDONLY) =
14
42610:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/resynthesizer_gui",
O_RDONLY) = 14
42759:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/resynthesizer",
O_RDONLY) = 14
42875:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py",
O_RDONLY) = 14
The next time gimp froze again after opening the same file, but the
progress statement in the splash screen was:
Querying new Plug-ins
plugin-uncrop.py
(The last line is from memory. The splash screen got covered by other
windows, and was not re-rendered when uncovered.)
The second strace output ended like this:
home:~$ tail -50 /tmp/log2
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0 (Timeout)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
writev(3,
[{iov_base="5\30\4\0,\2\300\3\3\0\300\3\0\5e\0\213\4\6\0-\2\300\3,\2\300\3\204\1\0\0"...,
iov_len=1688}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) =
1688
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
pipe([10, 11]) = 0
pipe([12, 13]) = 0
fcntl(10, F_GETFD) = 0
fcntl(10, F_SETFD, FD_CLOEXEC) = 0
fcntl(13, F_GETFD) = 0
fcntl(13, F_SETFD, FD_CLOEXEC) = 0
fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl(10, F_GETFL) = 0 (flags O_RDONLY)
fstat(13, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl(13, F_GETFL) = 0x1 (flags O_WRONLY)
fstat(12, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl(12, F_GETFL) = 0 (flags O_RDONLY)
fstat(11, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl(11, F_GETFL) = 0x1 (flags O_WRONLY)
openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py", O_RDONLY)
= 14
fstat(14, {st_mode=S_IFREG|0755, st_size=6040, ...}) = 0
read(14, "#!/usr/bin/env python\n\n'''\nGimp "..., 4095) = 4095
close(14) = 0
vfork() = 21499
wait4(21499, 0x7ffe9e2b8844, WNOHANG, NULL) = 0
close(12) = 0
close(11) = 0
read(10, 0x7ffe9e2b8960, 4) = ? ERESTARTSYS (To be restarted
if SA_RESTART is set)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
futex(0x7f3bd51fe9e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "gimp: terminated: Interrupt\n", 28) = 28
futex(0x7f3bafff8d60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f3bafff8de0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f3bafff8d90, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f3bafff8e60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f3bafff8e10, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f3badd8c9d0, FUTEX_WAIT, 21357, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
munmap(0x7f3b877ff000, 8392704) = 0
munmap(0x7f3bab58b000, 33554496) = 0
munmap(0x7f3ba958a000, 33554496) = 0
munmap(0x7f3ba1fff000, 33554496) = 0
exit_group(1) = ?
+++ exited with 1 +++
home:~$
The third attempt generated no splash screen, and froze much earlier
in the launch process:
home:~$ wc /tmp/log*
42896 244437 2739803 /tmp/log
42738 243377 2728490 /tmp/log2
3157 15677 215550 /tmp/log3
88791 503491 5683843 total
My Debian installation appears okay, except for one package which
might conceivably be related to this problem:
home:~$ sudo apt-get check
Reading package lists... Done
Building dependency tree
Reading state information... Done
home:~$ sudo dpkg --configure -a
Setting up jython-stilts (3.1.4-1) ...
Exception in thread "main" java.lang.NoSuchMethodError:
java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
at jline.internal.InputStreamReader.<init>(InputStreamReader.java:104)
at jline.console.ConsoleReader.setInput(ConsoleReader.java:330)
at jline.console.ConsoleReader.<init>(ConsoleReader.java:248)
at org.python.util.JLineConsole.install(JLineConsole.java:107)
at org.python.core.Py.installConsole(Py.java:1744)
at org.python.core.PySystemState.initConsole(PySystemState.java:1258)
at org.python.core.PySystemState.doInitialize(PySystemState.java:1109)
at org.python.core.PySystemState.initialize(PySystemState.java:1023)
at org.python.core.PySystemState.initialize(PySystemState.java:979)
at org.python.core.PySystemState.initialize(PySystemState.java:974)
at org.python.util.jython.run(jython.java:263)
at org.python.util.jython.main(jython.java:142)
dpkg: error processing package jython-stilts (--configure):
installed jython-stilts package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
jython-stilts
home:~$ sudo apt-get install --reinstall jython-stilts
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 900 not
upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
E: Internal Error, No file name for jython-stilts:amd64
home:~$ dpkg -l jyth\*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
Description
+++-============================-===================-===================-==============================================================
ii jython 2.7.1+repack-3 all
Python seamlessly integrated with Java
un jython-doc <none> <none>
(no description available)
iF jython-stilts 3.1.4-1 all
Starlink Tables Infrastructure Library Tool Set (Jython packag
Please let me know if there's anything I can do to help.
- Jim Van Zandt <jim.vanzandt@gmail.com>
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (700, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gimp depends on:
ii gimp-data 2.10.2-1
ii libaa1 1.4p5-44+b1
ii libbabl-0.1-0 0.1.50-1
ii libbz2-1.0 1.0.6-8.1
ii libc6 2.27-4
ii libcairo2 1.15.10-3
ii libfontconfig1 2.13.0-5
ii libfreetype6 2.8.1-2
ii libgcc1 1:8.1.0-10
ii libgdk-pixbuf2.0-0 2.36.11-2
ii libgegl-0.4-0 0.4.2-1
ii libgexiv2-2 0.10.8-1
ii libgimp2.0 2.10.2-1
ii libglib2.0-0 2.56.1-2
ii libgs9 9.22~dfsg-2.1
ii libgtk2.0-0 2.24.32-2
ii libgudev-1.0-0 232-2
ii libharfbuzz0b 1.7.6-1
ii libheif1 1.3.2-1
ii libilmbase23 2.2.1-2
ii libjpeg62-turbo 1:1.5.2-2+b1
ii liblcms2-2 2.9-2
ii liblzma5 5.2.2-1.3
ii libmng1 1.0.10+dfsg-3.1+b5
ii libmypaint-1.3-0 1.3.0-2
ii libopenexr23 2.2.1-4
ii libopenjp2-7 2.3.0-1
ii libpango-1.0-0 1.42.1-2
ii libpangocairo-1.0-0 1.42.1-2
ii libpangoft2-1.0-0 1.42.1-2
ii libpng16-16 1.6.34-2
ii libpoppler-glib8 0.63.0-2
ii librsvg2-2 2.40.20-2
ii libstdc++6 8.1.0-10
ii libtiff5 4.0.9-6
ii libwebp6 0.6.1-2
ii libwebpdemux2 0.6.1-2
ii libwebpmux3 0.6.1-2
ii libwmf0.2-7 0.2.8.4-12
ii libx11-6 2:1.6.5-1
ii libxcursor1 1:1.1.15-1
ii libxext6 2:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxmu6 2:1.1.2-2
ii libxpm4 1:3.5.12-1
ii xdg-utils 1.1.3-1
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages gimp recommends:
ii ghostscript 9.22~dfsg-2.1
Versions of packages gimp suggests:
ii gimp-data-extras 1:2.0.2-1
ii gimp-help-en [gimp-help] 2.8.2-0.1
ii gimp-python 2.10.2-1
ii gvfs-backends 1.36.1-1
ii libasound2 1.1.6-1
-- no debconf information
Acknowledgement sent
to Pascal Giard <evilynux@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Wed, 18 Jul 2018 12:33:07 GMT) (full text, mbox, link).
Dear maintainer,
In case that may shed some light...
Before having gimp-python installed, gimp would start.
I could modify images and save them in the native gimp format.
Attempting to export to png or jpg would freeze though.
(With the exportation processes visible with `ps` but not doing anything,
it appears).
After installing gimp-python, attempting to start gimp, I get stuck on the
splash screen with status message "Interrogation des nouveaux greffons"
(python-eval.py).
Sorry, attempting to start with LC_ALL=C doesn't work; this loosely
translates to "Querying new plugins". Killing gimp, either of the following
process remains active
/usr/bin/python2 /usr/lib/gimp/2.0/plug-ins/py-slice.py -gimp 12 11 -query 0
/usr/bin/python2 /usr/lib/gimp/2.0/plug-ins/python-eval.py -gimp 12 11
-query 0
Best regards,
-Pascal
--
Homepage (http://giard.info)
Debian GNU/Linux (http://www.debian.org)
TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch)
Acknowledgement sent
to James Van Zandt <jim.vanzandt@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Thu, 19 Jul 2018 02:36:03 GMT) (full text, mbox, link).
I note that, according to the strace log, gimp successfully read in 138
plugins, but failed on the very first plug-in that was a Python script.
That can't be a coincidence.
- Jim Van Zandt
Acknowledgement sent
to "Benedict Geihe" <TAA-Trigger@gmx.de>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Tue, 24 Jul 2018 13:15:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Pascal Giard <evilynux@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Wed, 25 Jul 2018 13:54:07 GMT) (full text, mbox, link).
Hi,
Exact same results as Benedict Geihe, i.e., removing libopenblas-base
solves the issue.
Thanks A LOT for pointing this out Benedict!
Best regards,
-Pascal
--
Homepage (http://giard.info)
Debian GNU/Linux (http://www.debian.org)
TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch)
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>: Bug#903514; Package gimp.
(Sat, 04 Aug 2018 02:57:03 GMT) (full text, mbox, link).
Acknowledgement sent
to James Van Zandt <jim.vanzandt@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Sat, 04 Aug 2018 02:57:03 GMT) (full text, mbox, link).
Thanks, Benedict - the same solution worked for me.
Specifically:
sudo apt-get install libopenblas-base- libopenblas-dev- \
libblas3 liblapack3 libblas-dev liblapack-dev
Unfortunately julia and libjulia0.6 were also removed here, since they
depend on libopenblas-base. I intend to report this as a bug, and request
that they depend instead on the virtual packages libblas.so.3 and
liblapack.so.3 (which can also be provided by liblapack3 and libblas3,
resp.).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>: Bug#903514; Package gimp.
(Tue, 07 Aug 2018 22:15:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>.
(Tue, 07 Aug 2018 22:15:07 GMT) (full text, mbox, link).
To: 903514@bugs.debian.org, James Van Zandt <jim.vanzandt@gmail.com>,
Pascal Giard <evilynux@gmail.com>, Benedict Geihe <TAA-Trigger@gmx.de>,
Christoph Anton Mitterer <calestyo@scientia.net>
Hi,
On Fri, 3 Aug 2018 22:53:08 -0400 James Van Zandt
<jim.vanzandt@gmail.com> wrote:
> Thanks, Benedict - the same solution worked for me.
>
> Specifically:
>
> sudo apt-get install libopenblas-base- libopenblas-dev- \
> libblas3 liblapack3 libblas-dev liblapack-dev
>
> Unfortunately julia and libjulia0.6 were also removed here, since they
> depend on libopenblas-base. I intend to report this as a bug, and request
> that they depend instead on the virtual packages libblas.so.3 and
> liblapack.so.3 (which can also be provided by liblapack3 and libblas3,
> resp.).
After checking what could cause gimp issues, I found that on my machine,
gimp almost always hang showing nothing (no splashscreen) when
libopenblas-base is installed.
Using gdb to find where it hung (gimp-gdb.txt) gives threads waiting on
a lock while doing thread-local related stuff and the main thread is in
the process of dl_close-ing openblas waiting the threads to exit using
pthread_join.
It seems that the lock used in `tls_get_addr_tail` [0] is the same as
the one locked by _dl_close [1].
A recursive lock is used but here it does not help as the thread calling
`tls_get_addr_tail` and `_dl_close` are not the same.
This deadlock may not happen everytime, in my case, the openblas threads
are still initializing while dl_close is called.
Given this, I think the offending commit in openblas is bf40f806 [2]
which add TLS variables to avoid locking. But many change were done
since then.
One of related bug report is [3] which seems to indicate that the locks
handling is not easy inside glibc.
There were an attempt to fix deadlocks between tls_get_addr and a
dlclose of a module whose finalizer joins with that thread [4].
So I see these possibles solutions:
* Add a breaks between gimp and openblas
* Disable TLS in openblas build (if possible, but this would cause a
performance loss for users that use openblas without gimp)
* Patch glibc to not deadlock (but this seems not easy to do at all)
Also, this deadlock might not be the only cause of issues encountered in
this bug report.
Reassigning to glibc with affects on openblas and gimp as this is caused
by a deadlock inside glibc.
[0] https://github.com/bminor/glibc/blob/glibc-2.27/elf/dl-tls.c#L761
[1] https://github.com/bminor/glibc/blob/glibc-2.27/elf/dl-close.c#L812
[2]
https://github.com/xianyi/OpenBLAS/commit/bf40f806efa55c7a7c7ec57535919598eaeb569d#diff-31f8d4e8863583d95bf2f9529f83844e
[4] https://sourceware.org/ml/libc-alpha/2015-06/msg00062.html
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Added indication that 903514 affects gimp and libopenblas-base
Request was from Alexis Murzeau <amubtdx@gmail.com>
to control@bugs.debian.org.
(Tue, 07 Aug 2018 22:42:05 GMT) (full text, mbox, link).
Bug reassigned from package 'gimp' to 'src:glibc'.
Request was from Alexis Murzeau <amubtdx@gmail.com>
to control@bugs.debian.org.
(Tue, 07 Aug 2018 22:42:08 GMT) (full text, mbox, link).
No longer marked as found in versions gimp/2.10.2-1.
Request was from Alexis Murzeau <amubtdx@gmail.com>
to control@bugs.debian.org.
(Tue, 07 Aug 2018 22:42:09 GMT) (full text, mbox, link).
Marked as found in versions glibc/2.27-5.
Request was from Alexis Murzeau <amubtdx@gmail.com>
to control@bugs.debian.org.
(Tue, 07 Aug 2018 22:42:10 GMT) (full text, mbox, link).
Changed Bug title to 'Deadlock in _dl_close join-ing threads accessing TLS' from 'gimp: completely broken'.
Request was from Alexis Murzeau <amubtdx@gmail.com>
to control@bugs.debian.org.
(Tue, 07 Aug 2018 22:42:11 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Tue, 07 Aug 2018 23:03:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Tue, 07 Aug 2018 23:03:05 GMT) (full text, mbox, link).
To: 903514@bugs.debian.org, James Van Zandt <jim.vanzandt@gmail.com>,
Pascal Giard <evilynux@gmail.com>, Benedict Geihe <TAA-Trigger@gmx.de>,
Christoph Anton Mitterer <calestyo@scientia.net>,
Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>,
Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>
severity 903514 important
thanks
> Reassigning to glibc with affects on openblas and gimp as this is caused
> by a deadlock inside glibc.
Done.
Lowering severity as this does not render any package unusable by
themselves, but only a combination of them (GIMP + OpenBLAS).
I think a workaround solution against GIMP OpenBLAS should be done as
I'm not sure a good solution will emerge in glibc given attempts done in
the past. The work to be done seems non trivial.
My though on possible solutions:
* Add a breaks between GIMP and OpenBLAS
* Disable TLS in OpenBLAS build (if possible, but this would cause a
performance loss for users that use OpenBLAS without gimp)
* Add a delay in GIMP to not load then close libraries too fast (so
OpenBLAS threads are fully initialized when dl_close is called on it)
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Severity set to 'important' from 'grave'
Request was from Alexis Murzeau <amubtdx@gmail.com>
to control@bugs.debian.org.
(Tue, 07 Aug 2018 23:03:07 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Wed, 08 Aug 2018 22:27:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Wed, 08 Aug 2018 22:27:02 GMT) (full text, mbox, link).
To: 903514@bugs.debian.org, James Van Zandt <jim.vanzandt@gmail.com>,
Pascal Giard <evilynux@gmail.com>, Benedict Geihe <TAA-Trigger@gmx.de>,
Christoph Anton Mitterer <calestyo@scientia.net>,
Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>,
Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>
On 08/08/2018 00:59, Alexis Murzeau wrote:
> severity 903514 important
> thanks
>
>> Reassigning to glibc with affects on openblas and gimp as this is caused
>> by a deadlock inside glibc.
>
> Done.
>
> Lowering severity as this does not render any package unusable by
> themselves, but only a combination of them (GIMP + OpenBLAS).
>
> I think a workaround solution against GIMP OpenBLAS should be done as
> I'm not sure a good solution will emerge in glibc given attempts done in
> the past. The work to be done seems non trivial.
>
> My though on possible solutions:
> * Add a breaks between GIMP and OpenBLAS
> * Disable TLS in OpenBLAS build (if possible, but this would cause a
> performance loss for users that use OpenBLAS without gimp)
> * Add a delay in GIMP to not load then close libraries too fast (so
> OpenBLAS threads are fully initialized when dl_close is called on it)
>
Hi,
I've posted a issue on openblas upstream project [0] and they suggested
some solutions.
One of them is to disable the use of compiler supported TLS and instead
use pthreads.
I tested this and it seems to fix deadlocks while starting gimp (I tried
without arguments, with a non existing file and with an existing file).
I've pushed a merge request with the patch at [1].
I've also asked openblas upstream if this patch could be a good solution.
In that case would it be possible to have this patch tested for ones who
have major instabilities with gimp + openblas ?
Thanks :)
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Merged 903514904544
Request was from Simon McVittie <smcv@debian.org>
to 904544-submit@bugs.debian.org.
(Thu, 09 Aug 2018 13:15:05 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Fri, 10 Aug 2018 21:30:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>, 903514@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Fri, 10 Aug 2018 21:30:03 GMT) (full text, mbox, link).
To: 903514@bugs.debian.org, James Van Zandt <jim.vanzandt@gmail.com>,
Pascal Giard <evilynux@gmail.com>, Benedict Geihe <TAA-Trigger@gmx.de>,
Christoph Anton Mitterer <calestyo@scientia.net>,
Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>,
Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>,
Sébastien Villemot <sebastien@debian.org>
On 09/08/2018 00:22, Alexis Murzeau wrote:
> On 08/08/2018 00:59, Alexis Murzeau wrote:
>> severity 903514 important
>> thanks
>>
>>> Reassigning to glibc with affects on openblas and gimp as this is caused
>>> by a deadlock inside glibc.
>>
>> Done.
>>
>> Lowering severity as this does not render any package unusable by
>> themselves, but only a combination of them (GIMP + OpenBLAS).
>>
>> I think a workaround solution against GIMP OpenBLAS should be done as
>> I'm not sure a good solution will emerge in glibc given attempts done in
>> the past. The work to be done seems non trivial.
>>
>> My though on possible solutions:
>> * Add a breaks between GIMP and OpenBLAS
>> * Disable TLS in OpenBLAS build (if possible, but this would cause a
>> performance loss for users that use OpenBLAS without gimp)
>> * Add a delay in GIMP to not load then close libraries too fast (so
>> OpenBLAS threads are fully initialized when dl_close is called on it)
>>
>
> Hi,
>
> I've posted a issue on openblas upstream project [0] and they suggested
> some solutions.
> One of them is to disable the use of compiler supported TLS and instead
> use pthreads.
>
> I tested this and it seems to fix deadlocks while starting gimp (I tried
> without arguments, with a non existing file and with an existing file).
>
> I've pushed a merge request with the patch at [1].
> I've also asked openblas upstream if this patch could be a good solution.
>
> In that case would it be possible to have this patch tested for ones who
> have major instabilities with gimp + openblas ?
>
> Thanks :)
>
Hi,
I've updated the merge request [0] with the upstream proposed patch [1].
@openblas maintainers, maybe someone can build a package with this patch
and upload to experimental so others can check if gimp works fine with it ?
I've myself tested it and gimp does not deadlock.
I can provide a binary package that include this patch, but I'm not sure
this is the best thing to do (I'm not the official maintainer, nor know
a good place to upload it).
[0] https://salsa.debian.org/science-team/openblas/merge_requests/1
[1] https://github.com/xianyi/OpenBLAS/pull/1726
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Fri, 10 Aug 2018 22:03:03 GMT) (full text, mbox, link).
Acknowledgement sent
to James Van Zandt <jim.vanzandt@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Fri, 10 Aug 2018 22:03:03 GMT) (full text, mbox, link).
Awesome, thanks!
On Fri, Aug 10, 2018, 5:27 PM Alexis Murzeau <amubtdx@gmail.com> wrote:
> On 09/08/2018 00:22, Alexis Murzeau wrote:
> > On 08/08/2018 00:59, Alexis Murzeau wrote:
> >> severity 903514 important
> >> thanks
> >>
> >>> Reassigning to glibc with affects on openblas and gimp as this is
> caused
> >>> by a deadlock inside glibc.
> >>
> >> Done.
> >>
> >> Lowering severity as this does not render any package unusable by
> >> themselves, but only a combination of them (GIMP + OpenBLAS).
> >>
> >> I think a workaround solution against GIMP OpenBLAS should be done as
> >> I'm not sure a good solution will emerge in glibc given attempts done in
> >> the past. The work to be done seems non trivial.
> >>
> >> My though on possible solutions:
> >> * Add a breaks between GIMP and OpenBLAS
> >> * Disable TLS in OpenBLAS build (if possible, but this would cause a
> >> performance loss for users that use OpenBLAS without gimp)
> >> * Add a delay in GIMP to not load then close libraries too fast (so
> >> OpenBLAS threads are fully initialized when dl_close is called on it)
> >>
> >
> > Hi,
> >
> > I've posted a issue on openblas upstream project [0] and they suggested
> > some solutions.
> > One of them is to disable the use of compiler supported TLS and instead
> > use pthreads.
> >
> > I tested this and it seems to fix deadlocks while starting gimp (I tried
> > without arguments, with a non existing file and with an existing file).
> >
> > I've pushed a merge request with the patch at [1].
> > I've also asked openblas upstream if this patch could be a good solution.
> >
> > In that case would it be possible to have this patch tested for ones who
> > have major instabilities with gimp + openblas ?
> >
> > Thanks :)
> >
>
> Hi,
>
> I've updated the merge request [0] with the upstream proposed patch [1].
>
> @openblas maintainers, maybe someone can build a package with this patch
> and upload to experimental so others can check if gimp works fine with it ?
>
> I've myself tested it and gimp does not deadlock.
>
> I can provide a binary package that include this patch, but I'm not sure
> this is the best thing to do (I'm not the official maintainer, nor know
> a good place to upload it).
>
> [0] https://salsa.debian.org/science-team/openblas/merge_requests/1
> [1] https://github.com/xianyi/OpenBLAS/pull/1726
>
> --
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
>
>
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Sun, 12 Aug 2018 13:33:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>, 903514@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Sun, 12 Aug 2018 13:33:03 GMT) (full text, mbox, link).
To: 903514@bugs.debian.org, James Van Zandt <jim.vanzandt@gmail.com>,
Pascal Giard <evilynux@gmail.com>, Benedict Geihe <TAA-Trigger@gmx.de>,
Christoph Anton Mitterer <calestyo@scientia.net>,
Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>,
Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>,
Sébastien Villemot <sebastien@debian.org>,
Jun Jiang <jiangjun12321@gmail.com>
On 10/08/2018 23:27, Alexis Murzeau wrote:
> I can provide a binary package that include this patch, but I'm not sure
> this is the best thing to do (I'm not the official maintainer, nor know
> a good place to upload it).
>
As I was requested to provide binary package to test the patch, I'm
providing this as version `0.3.2+ds-1.1~1patchTLS` built with sbuild at [0].
Instructions are on the same page [0]:
execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net
--recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001`
and add `deb https://amurzeau.github.io/apt-repository unstable main` to
sources.list.
This APT repository contains both the source and amd64 binary packages.
If you try it, please tell if it works.
[0] https://amurzeau.github.io/apt-repository/
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Sun, 12 Aug 2018 14:00:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Jackie <jiangjun12321@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Sun, 12 Aug 2018 14:00:03 GMT) (full text, mbox, link).
Great. It works.
To make it clear, this is what I did to test:
1. Install libopenblas-base:amd64 (0.3.2+ds-1) and
libopenblas-dev:amd64 (0.3.2+ds-1) from official repo. After
installation complete, open a terminal and type gimp + ENTER. The cmd
hangs forever and Ctrl-C gets a segment fault.
2. sudo apt purge libopenblas-base libopenblas-dev. Upon finish, open a
terminal and type gimp + ENTER. Gimp lanuches without problem.
3. Add the repo you offered and install libopenblas-base:amd64
(0.3.2+ds-1.1~1patchTLS) and libopenblas-dev:amd64
(0.3.2+ds-1.1~1patchTLS). The installations go well, after that, open a
terminal and type gimp + ENTER. Gimp again lanuches without any
problem.
I think this validates both the existence of the bug and your solution.
Thank you very much.
Jiang Jun
On Sun, Aug 12, 2018 at 9:31 PM, Alexis Murzeau <amubtdx@gmail.com>
wrote:
> On 10/08/2018 23:27, Alexis Murzeau wrote:
>> I can provide a binary package that include this patch, but I'm not
>> sure
>> this is the best thing to do (I'm not the official maintainer, nor
>> know
>> a good place to upload it).
>>
>
> As I was requested to provide binary package to test the patch, I'm
> providing this as version `0.3.2+ds-1.1~1patchTLS` built with sbuild
> at [0].
>
> Instructions are on the same page [0]:
> execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net
> --recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001`
> and add `deb https://amurzeau.github.io/apt-repository unstable main`
> to
> sources.list.
>
> This APT repository contains both the source and amd64 binary
> packages.
> If you try it, please tell if it works.
>
> [0] https://amurzeau.github.io/apt-repository/
>
> --
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
>
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Sun, 12 Aug 2018 14:03:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Sun, 12 Aug 2018 14:03:02 GMT) (full text, mbox, link).
On 12/08/2018 15:55, Jackie wrote:
> Great. It works.
> To make it clear, this is what I did to test:
>
> 1. Install libopenblas-base:amd64 (0.3.2+ds-1) and libopenblas-dev:amd64
> (0.3.2+ds-1) from official repo. After installation complete, open a
> terminal and type gimp + ENTER. The cmd hangs forever and Ctrl-C gets a
> segment fault.
> 2. sudo apt purge libopenblas-base libopenblas-dev. Upon finish, open a
> terminal and type gimp + ENTER. Gimp lanuches without problem.
> 3. Add the repo you offered and install libopenblas-base:amd64
> (0.3.2+ds-1.1~1patchTLS) and libopenblas-dev:amd64
> (0.3.2+ds-1.1~1patchTLS). The installations go well, after that, open a
> terminal and type gimp + ENTER. Gimp again lanuches without any problem.
>
> I think this validates both the existence of the bug and your solution.
> Thank you very much.
Thank you too for testing that patch :)
Good to see it works for others having the gimp hang too.
>
> Jiang Jun
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Merged 903514904544906152
Request was from Sébastien Villemot <sebastien@debian.org>
to 906152-submit@bugs.debian.org.
(Wed, 15 Aug 2018 07:45:08 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Wed, 15 Aug 2018 13:06:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Wed, 15 Aug 2018 13:06:05 GMT) (full text, mbox, link).
Hi,
On Tue, 14 Aug 2018 23:27:18 -0300 Rogério Brito <rbrito@ime.usp.br> wrote:
> OK, now, to the actual report. With version 0.3.2 of openblas installed,
> whenever I call gimp (I always start programs from the command line), it
> just sits there and doesn't even show its splash screen.
>
> If I interrupt the execution with Ctrl+C, then I get a "Segmentation fault"
> message, which would lead me to think that the program would not even have
> finished being linked to all the shared libraries that it needs.
>
> If I run gimp under strace, I see that it hangs in a mutex call that never
> proceeds.
>
I've suggested a patch to openblas here : [0]
I've built a package with this patch available here: [1].
Instructions are on the same page [1]:
execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net
--recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001`
and add `deb https://amurzeau.github.io/apt-repository unstable main` to
sources.list.
Then update openblas package to version `0.3.2+ds-1.1~1patchTLS`.
Can you confirm if this patched package fixes your issue ?
[0] https://salsa.debian.org/science-team/openblas/merge_requests/1
[1] https://amurzeau.github.io/apt-repository/
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Severity set to 'grave' from 'important'
Request was from Adrian Bunk <bunk@debian.org>
to control@bugs.debian.org.
(Thu, 16 Aug 2018 13:39:02 GMT) (full text, mbox, link).
Removed indication that 903514 affects gimp and libopenblas-base
Request was from Jeremy Bicha <jbicha@debian.org>
to 906516-submit@bugs.debian.org.
(Fri, 17 Aug 2018 20:15:05 GMT) (full text, mbox, link).
Merged 903514904544906152906516
Request was from Jeremy Bicha <jbicha@debian.org>
to 906516-submit@bugs.debian.org.
(Fri, 17 Aug 2018 20:15:06 GMT) (full text, mbox, link).
Added indication that 903514 affects gimp and libopenblas-base
Request was from Alexis Murzeau <amubtdx@gmail.com>
to control@bugs.debian.org.
(Fri, 17 Aug 2018 20:24:02 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Fri, 07 Sep 2018 15:00:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Fri, 07 Sep 2018 15:00:03 GMT) (full text, mbox, link).
To: Alexis Murzeau <amubtdx@gmail.com>, 903514@bugs.debian.org, James Van
Zandt <jim.vanzandt@gmail.com>, Pascal Giard <evilynux@gmail.com>, Benedict
Geihe <TAA-Trigger@gmx.de>, Christoph Anton Mitterer
<calestyo@scientia.net>, Debian GNOME Maintainers
<pkg-gnome-maintainers@lists.alioth.debian.org>, Debian Science Team
<debian-science-maintainers@lists.alioth.debian.org>
Le vendredi 10 août 2018 à 23:27 +0200, Alexis Murzeau a écrit :
> On 09/08/2018 00:22, Alexis Murzeau wrote:
> > On 08/08/2018 00:59, Alexis Murzeau wrote:
> > > severity 903514 important
> > > thanks
> > >
> > > > Reassigning to glibc with affects on openblas and gimp as this is caused
> > > > by a deadlock inside glibc.
> > I've posted a issue on openblas upstream project [0] and they suggested
> > some solutions.
> > One of them is to disable the use of compiler supported TLS and instead
> > use pthreads.
I have just uploaded openblas 0.3.3+ds-1, which has TLS disabled.
I think this should fix the original issue, i.e. the gimp+openblas
deadlock. Please let me know if this is not the case.
Best,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Fri, 07 Sep 2018 22:51:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Fri, 07 Sep 2018 22:51:02 GMT) (full text, mbox, link).
To: Sébastien Villemot <sebastien@debian.org>,
903514@bugs.debian.org, James Van Zandt <jim.vanzandt@gmail.com>,
Pascal Giard <evilynux@gmail.com>, Benedict Geihe <TAA-Trigger@gmx.de>,
Christoph Anton Mitterer <calestyo@scientia.net>,
Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>,
Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>
Hi,
On 07/09/2018 16:57, Sébastien Villemot wrote:
>
> I have just uploaded openblas 0.3.3+ds-1, which has TLS disabled.
>
> I think this should fix the original issue, i.e. the gimp+openblas
> deadlock. Please let me know if this is not the case.
>
> Best,
>
Thanks for your update.
I tried to start gimp with this openblas version installed and it did
not crashed or hanged.
But there's still a possible crash that can occur, when I do a test that
does dl_open followed by dl_close of libopenblas, I get a segfault when
stopping the thread that does the dl_open/dl_close.
This crash doesn't seem to cause issues to gimp but might on some
machines (maybe no threads are used by gimp when indirectly loading
openblas and so the crash doesn't occur, but not sure at all).
More extensive information here: [0].
If no one object that gimp doesn't crash anymore with that 3.3 version,
maybe this bug can be closed (letting the crash of the dl_open/dl_close
test be handled by upstream only [0]).
[0] https://github.com/xianyi/OpenBLAS/issues/1720#issuecomment-418538099
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Sun, 31 Mar 2019 13:21:09 GMT) (full text, mbox, link).
Acknowledgement sent
to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Sun, 31 Mar 2019 13:21:09 GMT) (full text, mbox, link).
This bug is very likely a bug present in old glibc versions. It has been
brought to light when enabling TLS support in openblas and not by a new
glibc version.
Right now the bug has been workarounded by disabling TLS support in
openblas. The way to handle this bug is to write a small testcase that
can be forwarded upstream. It's not an easy task though.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Sun, 31 Mar 2019 20:57:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Sun, 31 Mar 2019 20:57:03 GMT) (full text, mbox, link).
Le 31/03/2019 à 15:19, Aurelien Jarno a écrit :
> This bug is very likely a bug present in old glibc versions. It has been
> brought to light when enabling TLS support in openblas and not by a new
> glibc version.
>
> Right now the bug has been workarounded by disabling TLS support in
> openblas. The way to handle this bug is to write a small testcase that
> can be forwarded upstream. It's not an easy task though.
>
Hi,
I've made a test case here [0].
I've not tested it against latest glibc commit.
But it does reproduce the deadlock with glibc 2.28 on Linux.
To run the test case, do this:
```
gcc test_compiler_tls.c -o test_compiler_tls -ldl -g -pthread
gcc test_compiler_tls_lib.c -shared -o test_compiler_tls_lib.so \
-g -pthread -fPIC
./test_compiler_tls ./test_compiler_tls_lib &
gdb --pid $! -ex 'thr a a bt'
```
This reproduce the deadlock that I've found in openblas:
1- The test_thread open the library which call its constructor
2- The library's constructor create a thread
`thread_that_use_tls_after_sleep`
3- The thread `thread_that_use_tls_after_sleep` sleep for 100ms (this
needs to be enough so dl_close is called before the sleep ends)
3- The test_thread close the library with dl_close
4- dl_close lock `dl_load_lock` and call the library's destructor
5- The library's destructor wait `thread_that_use_tls_after_sleep` to
finish
6- The `thread_that_use_tls_after_sleep` thread try to read the TLS
variable which cause a call to `__tls_get_addr`
7- `__tls_get_addr` cause a deadlock in `tls_get_addr_tail` trying to
lock the same `dl_load_lock` as dl_close does
8- Nothing happen because dl_close thread is waiting for the
`thread_that_use_tls_after_sleep` thread to finish which having the
lock and the latter thread try to lock the same lock as dl_close and
so never exit.
See [1] for the stacktrace.
Thread 3 is the library's thread created in its constructor and joined
in its destructor.
Thread 2 is the thread that does dl_open and dl_close.
Thread 1 is a "monitoring" thread to implement a timeout of 10s (useful
if this tests need to run on a CI system)
Where dl_close lock the `dl_load_lock`: [2]
Where tls_get_addr_tail lock the `dl_load_lock`: [3]
[0]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7
[1]:
https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7#file-gdb_stacktrace-txt
[2]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-close.c#L812
[3]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-tls.c#L761
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Marked as found in versions glibc/2.28-5.
Request was from Alexis Murzeau <amubtdx@gmail.com>
to control@bugs.debian.org.
(Sun, 31 Mar 2019 21:00:02 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Sun, 31 Mar 2019 21:21:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexis Murzeau <amubtdx@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Sun, 31 Mar 2019 21:21:03 GMT) (full text, mbox, link).
Le 31/03/2019 à 22:53, Alexis Murzeau a écrit :
> Le 31/03/2019 à 15:19, Aurelien Jarno a écrit :
>> This bug is very likely a bug present in old glibc versions. It has been
>> brought to light when enabling TLS support in openblas and not by a new
>> glibc version.
>>
>> Right now the bug has been workarounded by disabling TLS support in
>> openblas. The way to handle this bug is to write a small testcase that
>> can be forwarded upstream. It's not an easy task though.
>>
>
> Hi,
>
> I've made a test case here [0].
> I've not tested it against latest glibc commit.
> But it does reproduce the deadlock with glibc 2.28 on Linux.
>
> To run the test case, do this:
> ```
> gcc test_compiler_tls.c -o test_compiler_tls -ldl -g -pthread
> gcc test_compiler_tls_lib.c -shared -o test_compiler_tls_lib.so \
> -g -pthread -fPIC
> ./test_compiler_tls ./test_compiler_tls_lib &
> gdb --pid $! -ex 'thr a a bt'
> ```
>
> This reproduce the deadlock that I've found in openblas:
> 1- The test_thread open the library which call its constructor
> 2- The library's constructor create a thread
> `thread_that_use_tls_after_sleep`
> 3- The thread `thread_that_use_tls_after_sleep` sleep for 100ms (this
> needs to be enough so dl_close is called before the sleep ends)
> 3- The test_thread close the library with dl_close
> 4- dl_close lock `dl_load_lock` and call the library's destructor
> 5- The library's destructor wait `thread_that_use_tls_after_sleep` to
> finish
> 6- The `thread_that_use_tls_after_sleep` thread try to read the TLS
> variable which cause a call to `__tls_get_addr`
> 7- `__tls_get_addr` cause a deadlock in `tls_get_addr_tail` trying to
> lock the same `dl_load_lock` as dl_close does
> 8- Nothing happen because dl_close thread is waiting for the
> `thread_that_use_tls_after_sleep` thread to finish which having the
> lock and the latter thread try to lock the same lock as dl_close and
> so never exit.
>
> See [1] for the stacktrace.
>
> Thread 3 is the library's thread created in its constructor and joined
> in its destructor.
> Thread 2 is the thread that does dl_open and dl_close.
> Thread 1 is a "monitoring" thread to implement a timeout of 10s (useful
> if this tests need to run on a CI system)
>
> Where dl_close lock the `dl_load_lock`: [2]
> Where tls_get_addr_tail lock the `dl_load_lock`: [3]
>
> [0]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7
> [1]:
> https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7#file-gdb_stacktrace-txt
> [2]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-close.c#L812
> [3]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-tls.c#L761
>
Related links:
https://bugzilla.redhat.com/show_bug.cgi?id=1409899https://sourceware.org/bugzilla/show_bug.cgi?id=2377
Actually, the hang is caused by a C++ here, but that's the same deadlock
(the C++ exception require the `dl_load_lock´ lock).
It seems from the first link that using thread stuff in constructor and
destructor is risky and not well supported and that applications should
just avoid doing this.
I didn't find a really related bug in sourceware bugzilla, maybe we
should forward our bug to them ?
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Added tag(s) buster-ignore.
Request was from Niels Thykier <niels@thykier.net>
to control@bugs.debian.org.
(Sat, 13 Apr 2019 09:33:04 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Sun, 28 Apr 2019 22:27:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Wang Jianlin <jianlin@wang-wandagroup.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Sun, 28 Apr 2019 22:27:02 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>: Bug#903514; Package src:glibc.
(Mon, 04 May 2020 00:39:03 GMT) (full text, mbox, link).
Acknowledgement sent
to chienkwongp@gmail.com:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>.
(Mon, 04 May 2020 00:39:03 GMT) (full text, mbox, link).
Ich habe wichtige Geschäfte mit Ihnen zu besprechen. Antwort für weitere Details.
Wang Jianlin
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Added tag(s) bullseye-ignore.
Request was from Ivo De Decker <ivodd@debian.org>
to control@bugs.debian.org.
(Sat, 10 Apr 2021 18:00:37 GMT) (full text, mbox, link).
Message sent on
to Christoph Anton Mitterer <calestyo@scientia.net>:
Bug#903514.
(Sun, 12 Dec 2021 12:12:05 GMT) (full text, mbox, link).
Control: tag -1 pending
Hello,
Bug #903514 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/c569ea274923387e8448be3021649c7bdfd80095
------------------------------------------------------------------------
New upstream release:
* New upstream release:
- Treat 'W' as a distinct character in sv_SE locale. Closes: #511357.
- Fix a deadlock between pthread_create and ctors. Closes: #903514,
#904544, #906516.
- Add y2106 support for mips64. Closes: #983769.
- debian/symbols.wildcard: add 2.34.
- debian/libc6.symbols.common, debian/libc6.1.symbols.alpha,
debian/libc0.1.symbols.common, debian/libc0.3.symbols.hurd-i386: add
libc_malloc_debug.so.0.
- debian/patches/arm/local-sigaction.diff: rebased.
- debian/patches/hppa/git-fcntl.h-update.diff: upstreamed.
- debian/patches/hurd-i386/git-tiocflush.diff: upstreamed.
- debian/patches/hurd-i386/git-eintr.diff: upstreamed.
- debian/patches/hurd-i386/local-enable-ldconfig.diff: rebased.
- debian/patches/hurd-i386/local-clock_gettime_MONOTONIC.diff: rebased.
- debian/patches/hurd-i386/local-fix-nss.diff: rebased.
- debian/patches/all/submitted-po-fr-fixes.diff: rebased.
- debian/patches/any/local-ldso-disable-hwcap.diff: rebased.
- debian/patches/any/submitted-nptl-invalid-td.patch: rebased.
- debian/debhelper.in/libc-udeb.install{,.hurd-i386}: adjust paths
following the drop of the version number from the soname.
- debian/rules.d/build.mk: do not create symlink for ld.so.
- debian/rules.d/debhelper.mk: Stop making libpthread.so.0 executable and
strip it differently now that it is an empty library.
- debian/rules.d/debhelper.mk, debian/debhelper.in/libc.fixperms,
debian/debhelper.in/libc-alt.fixperms,
debian/debhelper.in/libc-otherbuild.fixperm: Use dh_fixperms to keep
ld.so and libc.so.6 executable now that they have a version independent
name.
- debian/rules.d/debhelper.mk, debian/debhelper.in/libc.postrm,
debian/debhelper.in/libc-otherbuild.lintian-overrides,
debian/debhelper.in/libc.lintian-overrides: change RTLD_SO to only
contain the basename instead of the absolute path.
- debhelper.in/libc.lintian-overrides, debhelper.in/libc.lintian-overrides,
debhelper.in/libc-otherbuild.lintian-overrides: update for the new
library naming.
------------------------------------------------------------------------
(this message was generated automatically)
--
Greetings
https://bugs.debian.org/903514
Added tag(s) pending.
Request was from Aurelien Jarno <noreply@salsa.debian.org>
to 903514-submitter@bugs.debian.org.
(Sun, 12 Dec 2021 12:12:05 GMT) (full text, mbox, link).
Reply sent
to Aurelien Jarno <aurel32@debian.org>:
You have taken responsibility.
(Sun, 12 Dec 2021 23:06:07 GMT) (full text, mbox, link).
Notification sent
to Christoph Anton Mitterer <calestyo@scientia.net>:
Bug acknowledged by developer.
(Sun, 12 Dec 2021 23:06:07 GMT) (full text, mbox, link).
Subject: Bug#903514: fixed in glibc 2.34-0experimental0
Date: Sun, 12 Dec 2021 23:03:49 +0000
Source: glibc
Source-Version: 2.34-0experimental0
Done: Aurelien Jarno <aurel32@debian.org>
We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 903514@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Aurelien Jarno <aurel32@debian.org> (supplier of updated glibc package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sun, 12 Dec 2021 23:52:06 +0100
Source: glibc
Architecture: source
Version: 2.34-0experimental0
Distribution: experimental
Urgency: medium
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Changed-By: Aurelien Jarno <aurel32@debian.org>
Closes: 511357903514904544906516983769
Changes:
glibc (2.34-0experimental0) experimental; urgency=medium
.
[ Aurelien Jarno ]
* New upstream release:
- Treat 'W' as a distinct character in sv_SE locale. Closes: #511357.
- Fix a deadlock between pthread_create and ctors. Closes: #903514,
#904544, #906516.
- Add y2106 support for mips64. Closes: #983769.
- debian/symbols.wildcard: add 2.34.
- debian/libc6.symbols.common, debian/libc6.1.symbols.alpha,
debian/libc0.1.symbols.common, debian/libc0.3.symbols.hurd-i386: add
libc_malloc_debug.so.0.
- debian/patches/arm/local-sigaction.diff: rebased.
- debian/patches/hppa/git-fcntl.h-update.diff: upstreamed.
- debian/patches/hurd-i386/git-tiocflush.diff: upstreamed.
- debian/patches/hurd-i386/git-eintr.diff: upstreamed.
- debian/patches/hurd-i386/local-enable-ldconfig.diff: rebased.
- debian/patches/hurd-i386/local-clock_gettime_MONOTONIC.diff: rebased.
- debian/patches/hurd-i386/local-fix-nss.diff: rebased.
- debian/patches/all/submitted-po-fr-fixes.diff: rebased.
- debian/patches/any/local-ldso-disable-hwcap.diff: rebased.
- debian/patches/any/submitted-nptl-invalid-td.patch: rebased.
- debian/debhelper.in/libc-udeb.install{,.hurd-i386}: adjust paths
following the drop of the version number from the soname.
- debian/rules.d/build.mk: do not create symlink for ld.so.
- debian/rules.d/debhelper.mk: Stop making libpthread.so.0 executable and
strip it differently now that it is an empty library.
- debian/rules.d/debhelper.mk, debian/debhelper.in/libc.fixperms,
debian/debhelper.in/libc-alt.fixperms,
debian/debhelper.in/libc-otherbuild.fixperm: Use dh_fixperms to keep
ld.so and libc.so.6 executable now that they have a version independent
name.
- debian/rules.d/debhelper.mk, debian/debhelper.in/libc.postrm,
debian/debhelper.in/libc-otherbuild.lintian-overrides,
debian/debhelper.in/libc.lintian-overrides: change RTLD_SO to only
contain the basename instead of the absolute path.
- debhelper.in/libc.lintian-overrides, debhelper.in/libc.lintian-overrides,
debhelper.in/libc-otherbuild.lintian-overrides: update for the new
library naming.
* debian/control.in/main, debian/rules.d/control.mk, debian/rules: build
with GCC 11.
.
[ Samuel Thibault ]
* debian/testsuite-xfail-debian.mk: Update hurd tests.
* debian/patches/hurd-i386/tg-glibc-2.24-restore-malloc-hook.diff: Drop
patch.
* debian/patches/hurd-i386/local-mach_print.diff: Drop patch.
Checksums-Sha1:
df3c43d22e9f44fcff2c159022fb2f9fd74c6560 9670 glibc_2.34-0experimental0.dsc
8f4aa359658ac026ea79fae2ab8c125c8dc8f0ce 17949940 glibc_2.34.orig.tar.xz
ddac2f2c76d7078eb13d216f109767f30ae96276 798548 glibc_2.34-0experimental0.debian.tar.xz
8d3473c37dfdded61a40a40604aeb70ff0091ec5 8812 glibc_2.34-0experimental0_source.buildinfo
Checksums-Sha256:
0d76ce591ee75b8dbe1c0ed6991a02878ec2f2e09ad179e162be3f946d877b15 9670 glibc_2.34-0experimental0.dsc
cc13047c7d42748108fc18cf1a4de8ca92f9e5c9bfcee09d6fada21d9a479878 17949940 glibc_2.34.orig.tar.xz
a046937a0895029bb82e63357e6739a1bb8531902fa5e2cc5722a3a135d3f8b3 798548 glibc_2.34-0experimental0.debian.tar.xz
9f5d72adfba3ff35c0dd3a29d3bb12d78f8b1c01998ccbdec82a3f2039c81360 8812 glibc_2.34-0experimental0_source.buildinfo
Files:
226d649fb092c710b31f34886dbda0f3 9670 libs required glibc_2.34-0experimental0.dsc
f20a012405afa4e11ec636427f2fe1d6 17949940 libs required glibc_2.34.orig.tar.xz
b085fb01aa9369b63c5aecc42d65f359 798548 libs required glibc_2.34-0experimental0.debian.tar.xz
d2b422462b4ffd3ae721c5cf8077e11c 8812 libs required glibc_2.34-0experimental0_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmG2ft0ACgkQE4jA+Jno
M2tb5A/9EP1Ii3FnV6gjJfttsMOPOuvoALcVaLp8e//MYbcMLO++3ab+7Pyt+vB4
t9RqVp2CZEykmOd3YnLrMGnHfsidTj4i8bF5XBWY7bzRe8LwwvSdL6agavMFR6b/
l4qZWuJqyrMHcJlD2JY7X+oGH/ydDmvw1OAZehoP8vg8i0K0sqgZgvW37ClBpbVC
NL7/nuNuzmThdRKjwaq9uGoiCphi0kbiED43lwOC5wX+hHp0i+/oX50Ruj1s3DCZ
AUBajjhpZhT9rggmN7dLZs4fptRwEybQfHvbizN5ky3oTrOSN3eJOhcqtZJFmZM+
pWQS8DjQkOKDM/h+cbJpg8S8VSbUPlb6rYKvBxOlOa8JaT4Nu3G6GNwOJj/ntf0p
NRsLZ3qOBbFYaDuV3IC83YxWklSxTX974ZM5/8kcsylhd4iD5aq5ri2Xp6cLBBiq
irIkD7INzl4QyR//VwGKCZoNjHjMj18WHihHtESOH6LY/FdYM4KyYm8hv2BLy6Jb
WkGtcB90Ugwrv07+qDxCaetWD1WzWFYC1so2NO42Jwyn7TZdRK5EH9BUH4u//Blh
xiB3KezE2ZnWhXz2GyQ7PtOmqYLO5o3L1t+d2NKgalcyES0Bk0w6wtCvgNzwMZfV
EmEhbwxwzQ8DMBHjUqobChXYUadWv3ujnX4RhswQO1spR/r8omE=
=B6ll
-----END PGP SIGNATURE-----
Reply sent
to Aurelien Jarno <aurel32@debian.org>:
You have taken responsibility.
(Sun, 12 Dec 2021 23:06:07 GMT) (full text, mbox, link).
Notification sent
to Jiang Jun <jiangjun12321@gmail.com>:
Bug acknowledged by developer.
(Sun, 12 Dec 2021 23:06:07 GMT) (full text, mbox, link).
Reply sent
to Aurelien Jarno <aurel32@debian.org>:
You have taken responsibility.
(Sun, 12 Dec 2021 23:06:08 GMT) (full text, mbox, link).
Notification sent
to Rogério Brito <rbrito@ime.usp.br>:
Bug acknowledged by developer.
(Sun, 12 Dec 2021 23:06:08 GMT) (full text, mbox, link).
Reply sent
to Aurelien Jarno <aurel32@debian.org>:
You have taken responsibility.
(Sun, 12 Dec 2021 23:06:09 GMT) (full text, mbox, link).
Notification sent
to Arnaud Meyer <arnaudmeyer@gmx.com>:
Bug acknowledged by developer.
(Sun, 12 Dec 2021 23:06:09 GMT) (full text, mbox, link).
Subject: Bug#904544: fixed in glibc 2.34-0experimental0
Date: Sun, 12 Dec 2021 23:03:49 +0000
Source: glibc
Source-Version: 2.34-0experimental0
Done: Aurelien Jarno <aurel32@debian.org>
We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 904544@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Aurelien Jarno <aurel32@debian.org> (supplier of updated glibc package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sun, 12 Dec 2021 23:52:06 +0100
Source: glibc
Architecture: source
Version: 2.34-0experimental0
Distribution: experimental
Urgency: medium
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Changed-By: Aurelien Jarno <aurel32@debian.org>
Closes: 511357903514904544906516983769
Changes:
glibc (2.34-0experimental0) experimental; urgency=medium
.
[ Aurelien Jarno ]
* New upstream release:
- Treat 'W' as a distinct character in sv_SE locale. Closes: #511357.
- Fix a deadlock between pthread_create and ctors. Closes: #903514,
#904544, #906516.
- Add y2106 support for mips64. Closes: #983769.
- debian/symbols.wildcard: add 2.34.
- debian/libc6.symbols.common, debian/libc6.1.symbols.alpha,
debian/libc0.1.symbols.common, debian/libc0.3.symbols.hurd-i386: add
libc_malloc_debug.so.0.
- debian/patches/arm/local-sigaction.diff: rebased.
- debian/patches/hppa/git-fcntl.h-update.diff: upstreamed.
- debian/patches/hurd-i386/git-tiocflush.diff: upstreamed.
- debian/patches/hurd-i386/git-eintr.diff: upstreamed.
- debian/patches/hurd-i386/local-enable-ldconfig.diff: rebased.
- debian/patches/hurd-i386/local-clock_gettime_MONOTONIC.diff: rebased.
- debian/patches/hurd-i386/local-fix-nss.diff: rebased.
- debian/patches/all/submitted-po-fr-fixes.diff: rebased.
- debian/patches/any/local-ldso-disable-hwcap.diff: rebased.
- debian/patches/any/submitted-nptl-invalid-td.patch: rebased.
- debian/debhelper.in/libc-udeb.install{,.hurd-i386}: adjust paths
following the drop of the version number from the soname.
- debian/rules.d/build.mk: do not create symlink for ld.so.
- debian/rules.d/debhelper.mk: Stop making libpthread.so.0 executable and
strip it differently now that it is an empty library.
- debian/rules.d/debhelper.mk, debian/debhelper.in/libc.fixperms,
debian/debhelper.in/libc-alt.fixperms,
debian/debhelper.in/libc-otherbuild.fixperm: Use dh_fixperms to keep
ld.so and libc.so.6 executable now that they have a version independent
name.
- debian/rules.d/debhelper.mk, debian/debhelper.in/libc.postrm,
debian/debhelper.in/libc-otherbuild.lintian-overrides,
debian/debhelper.in/libc.lintian-overrides: change RTLD_SO to only
contain the basename instead of the absolute path.
- debhelper.in/libc.lintian-overrides, debhelper.in/libc.lintian-overrides,
debhelper.in/libc-otherbuild.lintian-overrides: update for the new
library naming.
* debian/control.in/main, debian/rules.d/control.mk, debian/rules: build
with GCC 11.
.
[ Samuel Thibault ]
* debian/testsuite-xfail-debian.mk: Update hurd tests.
* debian/patches/hurd-i386/tg-glibc-2.24-restore-malloc-hook.diff: Drop
patch.
* debian/patches/hurd-i386/local-mach_print.diff: Drop patch.
Checksums-Sha1:
df3c43d22e9f44fcff2c159022fb2f9fd74c6560 9670 glibc_2.34-0experimental0.dsc
8f4aa359658ac026ea79fae2ab8c125c8dc8f0ce 17949940 glibc_2.34.orig.tar.xz
ddac2f2c76d7078eb13d216f109767f30ae96276 798548 glibc_2.34-0experimental0.debian.tar.xz
8d3473c37dfdded61a40a40604aeb70ff0091ec5 8812 glibc_2.34-0experimental0_source.buildinfo
Checksums-Sha256:
0d76ce591ee75b8dbe1c0ed6991a02878ec2f2e09ad179e162be3f946d877b15 9670 glibc_2.34-0experimental0.dsc
cc13047c7d42748108fc18cf1a4de8ca92f9e5c9bfcee09d6fada21d9a479878 17949940 glibc_2.34.orig.tar.xz
a046937a0895029bb82e63357e6739a1bb8531902fa5e2cc5722a3a135d3f8b3 798548 glibc_2.34-0experimental0.debian.tar.xz
9f5d72adfba3ff35c0dd3a29d3bb12d78f8b1c01998ccbdec82a3f2039c81360 8812 glibc_2.34-0experimental0_source.buildinfo
Files:
226d649fb092c710b31f34886dbda0f3 9670 libs required glibc_2.34-0experimental0.dsc
f20a012405afa4e11ec636427f2fe1d6 17949940 libs required glibc_2.34.orig.tar.xz
b085fb01aa9369b63c5aecc42d65f359 798548 libs required glibc_2.34-0experimental0.debian.tar.xz
d2b422462b4ffd3ae721c5cf8077e11c 8812 libs required glibc_2.34-0experimental0_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmG2ft0ACgkQE4jA+Jno
M2tb5A/9EP1Ii3FnV6gjJfttsMOPOuvoALcVaLp8e//MYbcMLO++3ab+7Pyt+vB4
t9RqVp2CZEykmOd3YnLrMGnHfsidTj4i8bF5XBWY7bzRe8LwwvSdL6agavMFR6b/
l4qZWuJqyrMHcJlD2JY7X+oGH/ydDmvw1OAZehoP8vg8i0K0sqgZgvW37ClBpbVC
NL7/nuNuzmThdRKjwaq9uGoiCphi0kbiED43lwOC5wX+hHp0i+/oX50Ruj1s3DCZ
AUBajjhpZhT9rggmN7dLZs4fptRwEybQfHvbizN5ky3oTrOSN3eJOhcqtZJFmZM+
pWQS8DjQkOKDM/h+cbJpg8S8VSbUPlb6rYKvBxOlOa8JaT4Nu3G6GNwOJj/ntf0p
NRsLZ3qOBbFYaDuV3IC83YxWklSxTX974ZM5/8kcsylhd4iD5aq5ri2Xp6cLBBiq
irIkD7INzl4QyR//VwGKCZoNjHjMj18WHihHtESOH6LY/FdYM4KyYm8hv2BLy6Jb
WkGtcB90Ugwrv07+qDxCaetWD1WzWFYC1so2NO42Jwyn7TZdRK5EH9BUH4u//Blh
xiB3KezE2ZnWhXz2GyQ7PtOmqYLO5o3L1t+d2NKgalcyES0Bk0w6wtCvgNzwMZfV
EmEhbwxwzQ8DMBHjUqobChXYUadWv3ujnX4RhswQO1spR/r8omE=
=B6ll
-----END PGP SIGNATURE-----
Subject: Bug#906516: fixed in glibc 2.34-0experimental0
Date: Sun, 12 Dec 2021 23:03:49 +0000
Source: glibc
Source-Version: 2.34-0experimental0
Done: Aurelien Jarno <aurel32@debian.org>
We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 906516@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Aurelien Jarno <aurel32@debian.org> (supplier of updated glibc package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sun, 12 Dec 2021 23:52:06 +0100
Source: glibc
Architecture: source
Version: 2.34-0experimental0
Distribution: experimental
Urgency: medium
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Changed-By: Aurelien Jarno <aurel32@debian.org>
Closes: 511357903514904544906516983769
Changes:
glibc (2.34-0experimental0) experimental; urgency=medium
.
[ Aurelien Jarno ]
* New upstream release:
- Treat 'W' as a distinct character in sv_SE locale. Closes: #511357.
- Fix a deadlock between pthread_create and ctors. Closes: #903514,
#904544, #906516.
- Add y2106 support for mips64. Closes: #983769.
- debian/symbols.wildcard: add 2.34.
- debian/libc6.symbols.common, debian/libc6.1.symbols.alpha,
debian/libc0.1.symbols.common, debian/libc0.3.symbols.hurd-i386: add
libc_malloc_debug.so.0.
- debian/patches/arm/local-sigaction.diff: rebased.
- debian/patches/hppa/git-fcntl.h-update.diff: upstreamed.
- debian/patches/hurd-i386/git-tiocflush.diff: upstreamed.
- debian/patches/hurd-i386/git-eintr.diff: upstreamed.
- debian/patches/hurd-i386/local-enable-ldconfig.diff: rebased.
- debian/patches/hurd-i386/local-clock_gettime_MONOTONIC.diff: rebased.
- debian/patches/hurd-i386/local-fix-nss.diff: rebased.
- debian/patches/all/submitted-po-fr-fixes.diff: rebased.
- debian/patches/any/local-ldso-disable-hwcap.diff: rebased.
- debian/patches/any/submitted-nptl-invalid-td.patch: rebased.
- debian/debhelper.in/libc-udeb.install{,.hurd-i386}: adjust paths
following the drop of the version number from the soname.
- debian/rules.d/build.mk: do not create symlink for ld.so.
- debian/rules.d/debhelper.mk: Stop making libpthread.so.0 executable and
strip it differently now that it is an empty library.
- debian/rules.d/debhelper.mk, debian/debhelper.in/libc.fixperms,
debian/debhelper.in/libc-alt.fixperms,
debian/debhelper.in/libc-otherbuild.fixperm: Use dh_fixperms to keep
ld.so and libc.so.6 executable now that they have a version independent
name.
- debian/rules.d/debhelper.mk, debian/debhelper.in/libc.postrm,
debian/debhelper.in/libc-otherbuild.lintian-overrides,
debian/debhelper.in/libc.lintian-overrides: change RTLD_SO to only
contain the basename instead of the absolute path.
- debhelper.in/libc.lintian-overrides, debhelper.in/libc.lintian-overrides,
debhelper.in/libc-otherbuild.lintian-overrides: update for the new
library naming.
* debian/control.in/main, debian/rules.d/control.mk, debian/rules: build
with GCC 11.
.
[ Samuel Thibault ]
* debian/testsuite-xfail-debian.mk: Update hurd tests.
* debian/patches/hurd-i386/tg-glibc-2.24-restore-malloc-hook.diff: Drop
patch.
* debian/patches/hurd-i386/local-mach_print.diff: Drop patch.
Checksums-Sha1:
df3c43d22e9f44fcff2c159022fb2f9fd74c6560 9670 glibc_2.34-0experimental0.dsc
8f4aa359658ac026ea79fae2ab8c125c8dc8f0ce 17949940 glibc_2.34.orig.tar.xz
ddac2f2c76d7078eb13d216f109767f30ae96276 798548 glibc_2.34-0experimental0.debian.tar.xz
8d3473c37dfdded61a40a40604aeb70ff0091ec5 8812 glibc_2.34-0experimental0_source.buildinfo
Checksums-Sha256:
0d76ce591ee75b8dbe1c0ed6991a02878ec2f2e09ad179e162be3f946d877b15 9670 glibc_2.34-0experimental0.dsc
cc13047c7d42748108fc18cf1a4de8ca92f9e5c9bfcee09d6fada21d9a479878 17949940 glibc_2.34.orig.tar.xz
a046937a0895029bb82e63357e6739a1bb8531902fa5e2cc5722a3a135d3f8b3 798548 glibc_2.34-0experimental0.debian.tar.xz
9f5d72adfba3ff35c0dd3a29d3bb12d78f8b1c01998ccbdec82a3f2039c81360 8812 glibc_2.34-0experimental0_source.buildinfo
Files:
226d649fb092c710b31f34886dbda0f3 9670 libs required glibc_2.34-0experimental0.dsc
f20a012405afa4e11ec636427f2fe1d6 17949940 libs required glibc_2.34.orig.tar.xz
b085fb01aa9369b63c5aecc42d65f359 798548 libs required glibc_2.34-0experimental0.debian.tar.xz
d2b422462b4ffd3ae721c5cf8077e11c 8812 libs required glibc_2.34-0experimental0_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmG2ft0ACgkQE4jA+Jno
M2tb5A/9EP1Ii3FnV6gjJfttsMOPOuvoALcVaLp8e//MYbcMLO++3ab+7Pyt+vB4
t9RqVp2CZEykmOd3YnLrMGnHfsidTj4i8bF5XBWY7bzRe8LwwvSdL6agavMFR6b/
l4qZWuJqyrMHcJlD2JY7X+oGH/ydDmvw1OAZehoP8vg8i0K0sqgZgvW37ClBpbVC
NL7/nuNuzmThdRKjwaq9uGoiCphi0kbiED43lwOC5wX+hHp0i+/oX50Ruj1s3DCZ
AUBajjhpZhT9rggmN7dLZs4fptRwEybQfHvbizN5ky3oTrOSN3eJOhcqtZJFmZM+
pWQS8DjQkOKDM/h+cbJpg8S8VSbUPlb6rYKvBxOlOa8JaT4Nu3G6GNwOJj/ntf0p
NRsLZ3qOBbFYaDuV3IC83YxWklSxTX974ZM5/8kcsylhd4iD5aq5ri2Xp6cLBBiq
irIkD7INzl4QyR//VwGKCZoNjHjMj18WHihHtESOH6LY/FdYM4KyYm8hv2BLy6Jb
WkGtcB90Ugwrv07+qDxCaetWD1WzWFYC1so2NO42Jwyn7TZdRK5EH9BUH4u//Blh
xiB3KezE2ZnWhXz2GyQ7PtOmqYLO5o3L1t+d2NKgalcyES0Bk0w6wtCvgNzwMZfV
EmEhbwxwzQ8DMBHjUqobChXYUadWv3ujnX4RhswQO1spR/r8omE=
=B6ll
-----END PGP SIGNATURE-----
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Wed, 14 Jun 2023 07:25:09 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
