Sorry, forget the right email.
Forwarded Message
Betreff: Re: Bug#945814: audacity: various segfaults of audacity on startup
Datum: Tue, 14 Jan 2020 11:46:06 +0100
Von: Bernhard Übelacker
An: 945...@bugs.debian.org
Hello Tjeerd,
If this issue still exists on your system, you
Hello Tjeerd,
If this issue still exists on your system, you might try
to rename $HOME/.audacity-data to test if it depends on
some settings stored there.
If it still crashes then you might start it by following
and forward the output:
$ catchsegv audacity
Better would be if you could
Dear Maintainer, hello Benjamin,
the core seems at least related to the "Too many open files" lines.
Unfortunately I cannot get the whole backtrace (see below).
The crash seems to be the same as already reported in #851498, which
got forwarded to upstream in [1].
I guess in "Gnome - Settings -
Hello Asher, hello Markus,
sorry, I wasn't aware of that patch being applied at Salsa as
there was no more activity in 944431, so I thought it went
through unnoticed.
Sorry for the noise.
Kind regards,
Bernhard
Hello Gulfstream,
On Mon, 17 Jun 2019 11:17:48 +0800 (GMT+08:00) wg...@china.com wrote:
>
> I have install the proprietary nvidia drivers and it runs well.
>
Another user reported the same error and he had installed the nvidia
driver by their installer. He could solve the issue by
Dear Maintainer,
I could reproduce using linux-perf-5.2 and it is
also visible in linux-perf-5.4 5.4.8-1,
by just pressing enter.
The crash happens because in line 3172
function hist_browser__selected_entry returns
browser->he_selection, which is at this time a
null pointer.
This null pointer
Hello Jean-Luc,
thanks for your information.
Please use the reply-to-all button to have the
information forwarded to the bug report.
Am 08.01.20 um 17:21 schrieb Jean-Luc Lacroix:
> Hallo Bernhard,
>
> My system only has a single GPU (Nvidia GTX 970, see attached config)
> installed on a robust
Hello Paul,
in that case I guess kicad is really trying to leave
the process for some reason.
That reason is maybe written to stdout. Therefore maybe you
can run kicad from a terminal and attach its output.
Probably that could give any hints.
Otherwise maybe it is related to the used desktop
Hello Asher,
maybe you want to incorporate the changes given here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944431#31
Unfortunately I was too late there.
Then the call to e.g. SetThreadPriority would not needed to get
commented out, and the "-O0" fix in #944431 could be removed
again,
Dear Maintainer,
I could reproduce this issue.
Upstream fixed this crash with this upstream commit:
https://gitlab.gnome.org/GNOME/gnome-logs/commit/7d0062a4ab36d457b74fe17b8d494570d4a0334b
A package build with this patch applied still crashes,
which got fixed in this upstream commit:
Hello luca,
this bug might be related: https://bugs.debian.org/948671
Kind regards,
Bernhard
Hello Горбешко Богдан,
I am not involved in packaging samba but tried to get
some more details.
Currently smblcient fails with that message:
$ smbclient --user=testuser --ip-address=127.0.0.1 //testhost/C testtest
Unable to initialize messaging context
protocol negotiation failed:
Hello Paul,
I am not involved in packaging kicad or wxwidgets,
just trying to collect some more information.
Could you recheck - could it be that this pid 309563
was still running from a previous kicad session and
your hanging kicad was another, newer process?
Because, I guess, the
Dear Maintainer,
I could reproduce the crash now in an minimal unstable VM with the
given config and the command line from the coredumpctl output.
It seems that the function conf_parse_line is not prepared
for missing quotation marks for the argument in the section head [1].
Therefore, if quotes
Hello Miriam,
thanks for the backtraces, just the one from "coredumctl gdb" is enough.
Have you by any chance a file "/etc/nfsmount.conf" at this system?
If there are no secrets inside, could you attach that too?
Kind regards,
Bernhard
Hello Vincent,
I tried to find some more details about this issue.
In the regular case the resulting exe seems to link
to msvcrt.dll!_vsnprintf:
$ i686-w64-mingw32-objdump --private-headers test.c.exe
DLL Name: msvcrt.dll
vma: Hint/Ord Member-Name Bound-To
63e8
Hello Miriam,
if possible, you could install the additional package
systemd-coredump. Then in the output of 'journalctl --no-pager'
at the bottom should the known 'segfault at' line appear.
This and the following lines at that time would be of interest.
This would get better if the additional
Dear Maintainer,
the given code from dmesg points to this function:
LIBMTP_GetPartialObject at libmtp.c:9070
The related code [1] looks like function LIBMTP_Get_Filemetadata
returns a null pointer which get dereferenced unconditionally
in line 9070.
This part of the function seems unchanged
Hello Boris,
I am not involved in packaging gdm or orca
but tried to get more information.
I added also the a11y tag in the hope to get
the attention of the right people.
I tested inside a minimal VM with the gnome package installed.
In the gdm3 login screen I also got no reaction from the
5
<+261>: pop%r12
|| ...637
<+263>: pop%r13
...639
<+265>: pop%r14
Hello Pascal,
now I see one thing that would be even better:
coredumpctl gdb
info reg
thread apply all bt full
Sorry for not saying this sooner.
Kind regards,
Bernhard
Am 09.01.20 um 22:18 schrieb Pascal Vibet - ADACIS:
> @Bernhard : I install 'systemd-coredump' and 'centreon-engine-dbgsym'
> packages. I restart centengine. What information do you need? When
> centengine process crashes ? Or i run a program in same time ? What do
> you want me to do?
Great.
Am 09.01.20 um 17:56 schrieb crvi c:
> I am using the same bash / gnome-terminal as part of my daily work. The
> crash was random and it is not consistently reproducible. I have a
> couple of bash core files, if that would be of any help.
Ok, I see - had hoped it to be better reproducible.
In my
Dear Maintainer,
I got today the same crash as the submitter.
It happened short after disconnecting one android device,
connecting another and opening/retrying the MTP connection.
This upstream bug looks related:
https://bugs.kde.org/show_bug.cgi?id=415693
(Seems to be also from buster due to
Am 09.01.20 um 17:05 schrieb crvi c:
> gdb -q -batch -command ~/gdb-cmds.bash.txt --args bash
> Function "__pthread_tunables_init" not defined.
> Breakpoint 1 (__pthread_tunables_init) pending.
> [Detaching after fork from child process 37973]
Sorry, wasn't clear about that.
The prompt then shown
Dear Maintainer,
I just tried to get some more info from the
dmesg line, which seems to point to:
file ./src/retention/dump.cc, line 127. [1]
@Pascal: More information could maybe retrieved from the journal
if 'systemd-coredump' could be installed, even better if additionally
package
Hello Gulfstream, hello Jean-Luc,
this report got opened mentioning a "Thinkpad P1".
Reading through some pages about that device, it looks
like it contains some "hybrid graphics".
Maybe you both could confirm that your devices have such
"hybrid graphics", and if yes, maybe you could give some
Sorry, forgot to attach details.
# Bullseye/testing amd64 qemu VM 2020-01-08
apt update
apt dist-upgrade
apt install systemd-coredump xserver-xorg sddm openbox xterm net-tools mc
fakeroot gdb navit navit-dbgsym libgps25-dbgsym
apt build-dep navit
reboot
mkdir
Dear Maintainer,
I tried to gather some more information to this issue and
found below difference [1] [2] in sizes of struct gps_data_t,
by inspecting a running process in different stack frames.
Also I found that the current navit 0.5.3+dfsg.1-2+b1 was
built against libgps-dev 3.19-2 [6].
The
Dear Maintainer,
when comparing with a process while having debug symbols
installed, I guess the given backtrace would translate to
something like below.
Therefore I guess this crash is the same
as described in #929113.
Unfortunately I could not find a matching appearance of
function
Dear Maintainer,
I could reproduce the issue in a minimal bullseye VM.
>From my observations I guess the USR2 signal is sent
by logrotate:
/etc/logrotate.d/xdm:
kill -s USR2 $(cat /var/run/xdm.pid); \
If I read [1] right, then USR2 has a default action of
process termination.
Hello crvi c,
could you please add an example command
that you want to have completed?
And if you have changed the environment GLIBC_TUNABLES,
to which value?
Otherwise a gdb session driven by the two commands below
could maybe point to the exact location where the overwriting
takes place, if
Hello Md Ayquassar,
I am not involved in packaging gnome-shell, but may have
some pointers to gather some more informations for the
maintainer.
You could try to install the package systemd-coredump.
That way the output of 'journalctl --no-pager' should give
some information where the crash
Dear Maintainer,
I rebuilt a linux-image package with the patch applied
and the submitters' cryptsetup command finished
without visible error to me.
(console output and dmesg in second half of attached file.)
Due to my limited knowledge of cryptsetup I guess Jerad
could better judge if the
Dear Maintainer,
just as a side note, a similar bug was submitted
against the basilisk2 package.
https://bugs.debian.org/922323
Another user of slirp is qemu, which had some changes in
that area, which seems to have evolved into this library:
Hello Milan,
thanks for the fast response - I currently try to build a
package with your patch, but I guess this could take some time...
And I don't know what the usual approach is,
but the original reporter is probably Jerad?
(@Jerad maybe you could confirm your issue is the
same that I was
Dear Maintainer,
I just tried to reproduce the issue, but always
got a kernel oops instead of a usermode exception.
Therefore I guess this issue might be reassigned to src:linux?
By further looking it seems that in crypto_tfm_alg_blocksize
the __crt_alg member is dereferenced unconditionally
Short addition:
upstream changed that line urlbar.vala:109 in commit [1].
A locally built package including that patch
did not crash for me.
Kind regards,
Bernhard
[1]
https://github.com/midori-browser/core/commit/525f76c68fdde8a2d974c6975d9cc5ebe0cd594b
Dear Maintainer,
I tried to reproduce it also on amd64 and found it
crashing at the following location.
My knowledge of vala is limited, but is here the member
"suggestion_row.item.database" not yet set, but already accessed?
Kind regards,
Bernhard
Thread 1 received signal SIGSEGV,
Hello David,
I guess the package "thunar-dbgsym gdb" are installed
on your system, but could you please recheck if
packages "libglib2.0-0-dbgsym libgtk-3-0-dbgsym"
are really installed, too?
Kind regards,
Bernhard
Hello Antonio,
thanks for your comprehensive investigation.
I was not aware that rdesktop did not yet have a dbgsym package,
have opened bug #948126 for this.
And unfortunately if the backtrace in catchsegv ommits function
names, its output is just of help when using the debian binary
with a
Package: rdesktop
Version: 1.9.0-1
Severity: normal
Dear Maintainer,
attempting to support triaging another rdesktop bug I found
there does not yet exist a dbgsym package.
I tried to find out why and guess this is caused by the
strip command done in the Makefile.
As stripping would be done by
Hello Antonio,
could you please add to which windows version you
were trying to connect.
Maybe you could also try to start it that way:
catchsegv rdesktop ...
Even better would be if you could install debug symbols like
described in [1] and systemd-coredump.
Then after an application crashed
Short addition:
this upstream issue seems to match better:
https://gitlab.gnome.org/GNOME/gimp/issues/3630
Which got fixed in branches master and gimp-2-10
by these upstream commits:
https://gitlab.gnome.org/GNOME/gimp/commit/bbcc7ca5f55e62404bd69bf2e5b198039ad3f568
Control: tags -1 + patch upstream
Dear Maintainer,
I tried to have a look at this crash and I guess I found the reason.
The plugin calls into libgs.so.9 by gsapi_new_instance/psapi_new_instance.
Unfortunately the instance pointer is given to that function
uninitialized. But documentation states
Control: notfound -1 4:18.04.1-1
Control: found -1 4:19.08.1-1
Control: tags -1 unreproducible moreinfo
Hello Hans,
I tried to reproduce inside a minimal plasma testing VM.
But I could not see a noticeable amount of messages in
.xsession_errors while playing kpat.
If this is still visible on
Dear Maintainer,
I tried to reproduce this issue. And as far as I see
eog/cairo tries to allocate a pixmap from the xserver
in the size of the image file - in this case 44351x3013 pixel.
Unfortunately the xserver has a hard limit for such pixmap sizes:
Thread 1 "Xorg" hit Breakpoint 4,
Dear Maintainer,
the given backtrace should look like below with debug symbols installed.
For some reason it looks like the strchr at line 281 returns a null pointer.
Kind regards,
Bernhard
(gdb) bt no-filter
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1
Dear Maintainer,
the given valgrind backtrace should translate to something
like below (which did not crash for me).
The crashing instruction tries to read memory pointed by register $rdi,
that held in my test the address in parameters "v" / "key" / "name".
So I assume for some reason this
Dear Maintainer,
I tried to have a look and might have found something.
The crash happens because coroutine_stack_init returns NULL.
This is because of a buffer size check.
Building a package with doubled "DEFAULT_STATE_SIZE" went
through without crash (just tested on aarch64).
However, I am
Control: tags -1 + fixed-upstream patch
Dear Maintainer,
upstream fixed this issue in git by following commit:
https://ezix.org/src/pkg/lshw/commit/89b3b6b9ed03f22ca98954712db5a90acf2c6755
Kind regards,
Bernhard
Control: tags -1 + upstream
Control: forwarded -1 https://www.ezix.org/project/ticket/755
Dear Maintainer,
I tried to forward this issue upstream, where it is tracked
in this bug report: https://www.ezix.org/project/ticket/755
Hope it is ok to set this bug to forwarded.
Kind regards,
Bernhard
Hello Dave,
I am not involved in packaging lshw, just looking
at some random crash bug reports.
First, when reporting crashes that line from dmesg is most
of the time not sufficient. Therefore a simple way to retrieve
some more information could be to run it by 'catchsegv lshw'.
Better woudl be
Hello Wolfgang,
could you please count how many true type fonts you have installed,
e.g. by 'find /usr/share/fonts/truetype -iname "*.ttf" | wc -l'.
Because in a minimal test environment the application started to
behave strange after that number went over ~1250.
That test was done with these
Dear Maintainer,
I just tried to reproduce the crash but did not get it.
Maybe some more details of the configuration details of
host.cfg and DNS server setup could help,
because in my test I never reached with my IPv6 config
the faulting instruction.
At least the instruction, at that address
Hello Wolfgang,
Am 16.12.19 um 18:18 schrieb Wolfgang Rosner:
> -8<---
> script: Ungültige Option
> -- Try 'script --help' for more information.
> -8<---
Sorry, there was a -a too much inside the quotation marks.
> I get a log file of 13 MB in Size.
>
Hello Wolfgang,
Am 16.12.19 um 11:42 schrieb Wolfgang Rosner:
> Hi Bernhard,
>
> Thanks for the debug instructions.
>
> I'll go to try them, maybe the next weekend.
>
> Notes is an essential tool of my daily work, so extended trials block
> me from productive offfice work for some hours, since
Dear Maintainer,
tried to reconstruct the given backtrace with debug symbols
in a gdb session and came to following, maybe it could be
of some help.
(Still a proper backtrace with dbgsym packages
installed would be better.)
Kind regards,
Bernhard
Reconstructed:
#0 0x7f78b4cfb92f in
Hello Wolfgang,
I am not involved in packaging wine in debian, but
may have some hints.
Unfortunately I could not find any download for a trial version,
is there one known? Otherwise this can just be debugged
by users having access to that software.
Then a file containing some more output
Hello Jesús,
> Version: 2.10.12-0.1~mx19+1
Could not find a dbgsym package for that gimp version.
Is your system a MX Linux installation or a plain Debian?
At least in the first case, I guess, the MX Linux forums
can give better support.
And if the crash is reproducible it would help if you
Dear Maintainer,
I tried to have a look at this issue. I got this also on amd64 [2].
It looks like this is related to aeolus requesting its
memory never getting swapped out. [1]
Without this line a process does not give this fault.
But there is a "max locked memory" of 65536 kbytes
in place
Hello Daniel,
Am 12.12.19 um 18:27 schrieb Daniel James:
> Hi Bernhard,
>> Marking stops as 'Multi-Arch: foreign' should make
>> that installation possible.
>
> The package 'stops' contains binary instrument data, which as far as I
> know, is uniquely created by the undocumented and well-hidden
Control: tags -1 + upstream fixed-upstream patch
Dear Maintainer,
I tried to have a look at this crash
and I guess I found something.
The "Code:" sequence points to src/scan.c:1706.
There it seems like variable sr got a null pointer
and therefore the assignment crashes.
(gdb) list
(Forgot to attach some more debugging details.)
From submitter
Dec 12 09:40:11 lambda kernel: [55486.381334] iwd[202645]: segfault at 38 ip
55b1995e2056 sp 7ffc966c5360 error 6 in iwd[55b1995c4000+84000]
Dec 12 09:40:11 lambda kernel: [55486.381374] Code: 48 83 c4 20 e9 58 fe ff ff
0f
Package: stops
Version: 0.3.0-2
Severity: wishlist
Dear Maintainer,
I was trying to look at 943335, tried to look at it
with the rr debugger which is in the archive just for amd64.
Therefore tried to install aeolus:i386 which required
a package stops:i386.
Marking stops as 'Multi-Arch: foreign'
Control: tags -1 - upstream
Hello Felix,
maybe the information from following bug is
relevant in this case too.
https://bugs.debian.org/942860
Kind regards,
Bernhard
Hello Karl,
I am not involved in the packaging of phonon, but
still a few questions.
Have you any Qt4 applications installed?
Because src:phonon in version 4:4.10.3-2 was the last
version that built the Qt4 parts.
Since src:phonon 4:4.10.3-3 just the Qt5 packages
get build anymore.
And
Hello Adrian, hello Paul,
I could reproduce the issue in a minimal
revertable Unstable qemu VM with this command:
/usr/bin/autopkgtest libsoxr -- null
As far as I see the test is called this way:
src/debian/tests/inst-check
src/inst-check
src/inst-check-soxr
Dear Maintainer,
sorry, did attempt to output the build-id unconditionally,
fixed in attached patch version.
Kind regards,
Bernhard
>From 0a4a73d4eeaa45acdbeb6ea8fea878e134cbc11b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject:
Dear Maintainer,
while I was at it, I attempted to change the output to
deliver the before mentioned information for addr2line too.
Attached is a improved patch, that would now output following:
Backtrace:
[0x55f317f9175b] main at
/usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79
Package: libc-bin
Version: 2.29-3
Severity: wishlist
Tags: upstream patch
Dear Maintainer,
since upstream commit in 2012 [1] the function __backtrace_symbols_fd
seems to outputs in one of this formats:
program(+)[]
program(function+)[]
Therefore the /usr/bin/catchsegv cannot find the
Hello Jack Barns,
I am not involved in packaging spacefm, but just tried
to reproduce the issue. "Unfortunately" for my test it
did not freeze.
If you still can reproduce it, maybe you can execute
following command while a single spacefm process is in
the system and hangs:
script -a
Hello David,
I fear that output is not sufficient for that
type of application.
Maybe you could install following packages:
thunar-dbgsym gdb libglib2.0-0-dbgsym libgtk-3-0-dbgsym
For this you would need to add a matching package archive
like described in this link:
tus=) at exit.c:139
#11 0x555883f6 in main (argc=, argv=,
env=) at perlmain.c:166
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 607) killed]
(gdb) q
cd /home/benutzer/source/libsvn1
cp orig try2 -a
cd try2/subversion-1.10.4
945443_A
Control: tags -1 + patch upstream fixed-upstream
Hello Mladen Mijatov, dear Maintainer,
the first frames would be translated by addr2line to following [1].
This looks like the crash is caused by an invalid pointer pself/self
in function cc_display_mode_dbus_is_supported_scale [112].
This
Hello local10,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.
catchsegv gnome-control-center
Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
information of
Hello Mladen Mijatov,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.
catchsegv gnome-control-center
Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
Hello Ludovic,
I tried to collect some more information from your crash dump.
With debug symbols this backtrace should look like below.
I guess you are running a nvidia graphics card
with the nouveau drivers?
As a workaround it may work if you start the client
from a terminal by following:
Hello Christian,
if you still see this crash, maybe you could install the
package systemd-coredump.
If then a process crashes again some more information
should be visible at the end of:
journalctl --no-pager
Kind regards,
Bernhard
Hello Andrew,
On Sun, 8 Dec 2019 15:17:45 -0500 Andrew Engelbrecht wrote:
> I was able to reproduce and to get a backtrace, which I attached to this
> email.
Your backtrace with full debug symbols should read like below [4].
This seems to point to the upstream issue [1].
Unfortunately I
Hello Andrew,
I tried to reproduce this crash but it did not show up for me.
Maybe you could install systemd-coredump, then a backtrace
would be written automatically into the journal:
journalctl --no-pager
Kind regards,
Bernhard
Hello David,
I tried to reproduce the issue but I did not receive a crash.
There should have been two lines in the syslog - the line with "Code"
would at least help to identify in which function the crash happened.
Maybe you could also start thunar or nautilus from a terminal by e.g.
thunar
Am 07.12.19 um 18:20 schrieb Colin Watson:
> On Sat, Dec 07, 2019 at 04:52:19PM +0100, Bernhard Übelacker wrote:
>> I could reproduce the issue in a i386 qemu VM with
>> a downgraded 3.16-3-686-pae kernel.
>> Attached file contains a debug session.
>>
>> At the
Hello dinar qurbanov,
I am guessing you are using Buster/stable i386?
If reportbug would be used for reporting bugs, such
information gets added automatically to the report.
Then the "Code" in the syslog the crash most probably
happened in _cairo_surface_set_error [1].
Unfortunately I doubt that
Dear Maintainer,
I could reproduce the issue in a i386 qemu VM with
a downgraded 3.16-3-686-pae kernel.
Attached file contains a debug session.
At the sysenter instruction in function shmdt
the signal SIGSYS is received.
Kind regards,
Bernhard
(gdb) bt
#0 shmdt (shmaddr=0xb774) at
Dear Maintainer,
I tried to reproduce inside a minimal Buster i386 qemu VM
and received also an "Illegal instruction" message.
It looks like it tries to execute an AVX instruction that
my CPU should support, but is not enabled inside the VM.
The usage of AVX might originate from the compiler
Control: tags -1 + upstream patch
Dear Maintainer,
I tried to have a look into this issue and guess I found something.
It looks like the application is exhausting its stack by
allocation an integer array with maxpid elements.
At least in my test VM this leads to 16 MB array size,
while stack
Package: libkf5kiocore5
Version: 5.54.1-1
Severity: normal
Tags: patch upstream
Dear Maintainer,
in the last year I hit a few crashes with kate,
without knowing how to reproduce the crash.
Today I found this upstream reports [1] and several
duplicates. With that information it was easy to
... a short addition:
This issue might also the the same as
described in this upstream issue:
https://github.com/scim-im/scim/issues/26
Kind regards,
Bernhard
Control: reassign -1 scim-gtk-immodule 1.4.18-2.1
Control: affects -1 + gimp
Hello Masa O,
I tried to reproduce the crash you describe in a Buster/stable VM,
but was not able to reach the crash.
>From your backtrace there are some modules for scim input method
visible, but failed also to setup
Hello Geoff Tree,
I am not involved in packaging mousepad, but tried to reproduce
the issue. Unfortunately I could not trigger the crash.
Maybe you could install a coredump collector like systemd-coredump.
The last lines of the output of the command 'journalctl --no-pager'
should give the
Dear Maintainer,
I reported the issue upstream:
https://github.com/rzvncj/xCHM/issues/9
Kind regards,
Bernhard
Control: tags -1 + upstream patch
Dear Maintainer,
I could reproduce the crash with some old versions of
php_enhanced_en.chm I found on the net [1].
The current version from php.net [2] does not crash.
While it looks like the search is also not working
and gives no results.
With a package
Hello Stuart Lindley,
I am not involved in packaging qemu and just looking
through some bug reports.
Some informations that might be interesting for the
maintainer might be, which version of freenas you are running?
Based on your screenshot you start it via libvirt?
Maybe you could deliver the
Hello Jean-Paul,
this might be the same issue as in following bug, which
has some more information and a patch:
https://bugs.debian.org/945188
Kind regards,
Bernhard
Hello all,
this might be the same issue as in following bug, which
has some more information and a patch:
https://bugs.debian.org/945188
Kind regards,
Bernhard
Control: tags -1 + patch
Dear Maintainer,
I tried to have a look and found something.
This issue might be in the package since poppler-0.71.patch.
This patch makes some changes how containers get accessed.
Following I found and tried to change in attached patch:
- std::erase, std::clear,
Am 21.11.19 um 16:13 schrieb Marius Mikučionis:
> 2019-11-21, th, 13:14 Bernhard Übelacker <mailto:bernha...@mailbox.org>> wrote:
>
>
> I forgot to mention that I used a local built wine-4.20.
> There were lately some changes in that area in Wine, therefore
&
Am 21.11.19 um 12:09 schrieb Marius Mikučionis:
>
> 2019-11-21, kt, 01:16 Bernhard Übelacker <mailto:bernha...@mailbox.org>> rašė:
> $ wine strftime-ucrt-7.exe
> [%a]: [Tue]
> [%e]: [ 5]
> [%d]: [05]
> [%-d]: (empty
Hello Marius Mikucionis,
I am not anyhow involved in maintaining mingw-w64.
But I guess I found something.
First I fear that mingw-w64 does not link as much static
as you expect it to.
All crossbuilt executables still dynamically link to msvcrt.dll.
$ i686-w64-mingw32-objdump -p
501 - 600 of 1271 matches
Mail list logo
