I'm also encountering this with 7.11~repack-2.
I tried bisecting the available versions, and the last good version
seems to be 7.5~repack-1, which you can still get on the snapshots
archive: https://snapshot.debian.org/package/wine-development/7.5~repack-1/
On Thu, 11 Nov 2021 23:06:44 +1100 =?UTF-8?B?4oCN5bCP5aSq?=
wrote:
> So either the change needs to be backported to v94, or we'll just have to wait
> until v95 (or compile the browser ourselves)
I was a bit adventurous and tried doing a binary patch on the current debian
version (94.0-1), and
I narrowed down the freeze to the cubeb pulse code (part of the audio library
firefox uses), and I found that it was actually fixed almost a month ago:
https://github.com/mozilla/cubeb-pulse-rs/pull/72
It's already been merged into firefox on-track for v95:
On Sun, 3 Oct 2021 12:33:48 +0100 Simon McVittie wrote:
> On Sat, 02 Oct 2021 at 20:48:55 +1000, 小太 wrote:
> > What I can add is from reading the documentation of
> > g_quark_from_static_string()
> > (https://docs.gtk.org/glib/func.quark_from_static_string.html)
> >
On Sun, 3 Oct 2021 at 20:47, Ryan Thoryk wrote:
>
> When I had jack dump out it's module filenames during library load, it
> only appeared to load jack_firewire once. The clue as to what's
> happening is that valgrind reports "Bad permissions for mapped region",
> if you look at the function,
Since the offending code seems to be present upstream in the
glibmm-2-66 branch, I've also reported it upstream:
https://gitlab.gnome.org/GNOME/glibmm/-/issues/96
I can also confirm this issue also happens to me, and that downgrading
glibmm from 2.66.1-1 to 2.64.2-2 successfully resolves the issue.
I followed similar debugging steps as r...@thoryk.com above which
produced the same backtrace, before finding this bug already reported.
What I can add is from
Package: src:linux
Version: 5.10.40-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: nos...@kota.moe
After updating from linux-image-5.10.0-6-amd64, jackd now fails to sync to my
DICE-compatible firewire audio interface (Profire 610), with the following
error messages (full log attached):
> $
Apologies - I jumped to conclusions in my original bug report
After applying your patch and seeing it did not fix the issue, I did a bit
of investigation myself.
It turns out the problem wasn't in the linked commit, but actually part of
the upstream kernel:
Package: linux-source-5.10
Version: 5.10.9-1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: nos...@kota.moe
Trying to build in-tree kernel modules without the rest of the kernel (with the
M=... make target) results in the build failing with "ld: cannot open linker
script file -o: No such file or
On Wed, 15 Jul 2020 at 14:41, 小太 wrote:
>
> On Tue, 14 Jul 2020 at 19:21, 小太 wrote:
> >
> > On Tue, 14 Jul 2020 at 00:19, Hans van Kranenburg wrote:
> > > 小太, can you do...
> > >
> > > xl create -vvv
> > >
> > > ...w
On Tue, 14 Jul 2020 at 19:21, 小太 wrote:
>
> On Tue, 14 Jul 2020 at 00:19, Hans van Kranenburg wrote:
> > 小太, can you do...
> >
> > xl create -vvv
> >
> > ...which should show how qemu is invoked. Can you show that command?
> >
> > I can provid
On Tue, 14 Jul 2020 at 00:19, Hans van Kranenburg wrote:
> 小太, can you do...
>
> xl create -vvv
>
> ...which should show how qemu is invoked. Can you show that command?
>
> I can provide you with some test packages with the mentioned upstream
> patch applied (on top of
On Sun, 12 Jul 2020 at 19:55, Michael Tokarev wrote:
>
> 10.07.2020 17:29, 小太 wrote:
> > Package: qemu-system-x86
> > Version: 1:5.0-5
>
> > I upgraded my qemu-system-x86 from 1:5.0-5 to 1:5.0-6 today (since it was
> > just
> > migrated to testing).
>
On Sat, 11 Jul 2020 at 20:37, Michael Tokarev wrote:
>
> 10.07.2020 17:29, 小太 wrote:
> > Package: qemu-system-x86
> > Version: 1:5.0-5
> > Severity: important
> >
> > I upgraded my qemu-system-x86 from 1:5.0-5 to 1:5.0-6 today (since it was
> > ju
Package: qemu-system-x86
Version: 1:5.0-5
Severity: important
I upgraded my qemu-system-x86 from 1:5.0-5 to 1:5.0-6 today (since it was just
migrated to testing).
After upgrading, trying to boot a Xen HVM DomU (in this case named "windows")
crashes immediately, with the following logs in
16 matches
Mail list logo
