Package: kodi-inputstream-adaptive
Version: 20.3.2+ds-1
Severity: important
X-Debbugs-Cc: d...@fastmail.com
Dear Maintainer,
When resuming a Youtube video, Kodi will crash with the following stack
trace:
Thread 1 (Thread 0x7ff6751026c0 (LWP 100225)):
#0 0x7ff771d63ccc in () at
that, it's a copy/paste that I forgot to update. Here is the good
configuration :
Linux 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
Regards,
David
On Wed, 8 Feb 2023 at 17:17, Marc Haber
wrote:
> Control: tags -1 moreinfo unreproducible
> thanks
>
> On W
Package: aide
Version: 0.17.3-4+deb11u1
When I invoke `aideinit' without arguments from an ordinary shell
prompt it prints:
`ERROR: /etc/aide/aide.conf.d/31_aide_munin-nodes (stdout):1:
unexpected character: '/' (line:
Package: xabacus
Version: 8.2.2
Severity: wishlist
Tags: l10n patch
Hi,
The inital Norwegian Bokmål translation for xabacus is attached.
# ABACUS TEACH
# Copyright (C) 2017 - 2019
# This file is distributed under the same license as the xabacus package.
#
# David Bagley , 2019.
# David
Hello,
I'm interested in potentially taking on maintenance of this package. I
am new to Debian but I'd like to start contributing.
To explore this possibility, I've created a proof-of-concept transition
script. Please take a look at the attached script and let me know your
thoughts and
tags 778137 + patch
thanks
Here's a fix for the GCC 5 build error. I added '-std=gnu89' to
DEB_CFLAGS_MAINT_APPEND in debian/rules.
--
David S. Roth
Hewlett-Packard
--- tabble-0.43/debian/rules.orig 2015-07-02 23:01:46.804822037 +
+++ tabble-0.43/debian/rules 2015-07-02 22:59:24.832819098
Package: ifupdown
Version: 0.7.52
The system under test has 3 network interfaces each configured using dhcp.
System configuration:
/etc/network/interfaces:
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
auto eth2
allow-hotplug eth2
iface eth2 inet dhcp
auto eth3
allow-hotplug eth3
iface
From: Clint Adams [EMAIL PROTECTED]
Date: Sun, 11 Dec 2005 17:41:55 -0500
Replacing Aurelien's patch with this one fixes the
/lib64/libc.so.6: error while loading shared libraries: unexpected reloc type
0x4f
problem, and /lib64/libc.so.6 --version works fine.
However, 64-bit binaries
Package: libc6-sparc64
Version: 2.3.5-8
Severity: normal
There are some critical things missing in the sparc64 TLS support code
in the current debian glibc tree, for example none of the TLS
relcation support is in sysdeps/sparc/sparc64/dl-machine.h, and
therefore so no binary linked against
From: Bernd Eckenfels [EMAIL PROTECTED]
Date: Sun, 14 Aug 2005 19:51:39 +0200
I have this error report on ifconfig (also a problem with ip link) that a
down interface receives packets. I remeber this was discussed before but
cannot find a result of the outcome. Is this a driver problem?
From: Jim Crilly [EMAIL PROTECTED]
Date: Tue, 24 May 2005 14:42:27 -0400
True, but building kernels on sparc64 wasn't terribly fun for me the last
time I tried it either so I decided it wasn't worth it and just stuck with
the Debian kernel images.
Amusing as I do all of the sparc64 kernel
From: Ben Collins [EMAIL PROTECTED]
Date: Tue, 24 May 2005 14:29:16 -0400
And what about building kernels? They will by default be building
sparc32 kernels. That's the most likely place for this to be a
problem.
People can't wrap their brain around how to build a sparc64
kernel often right
From: [EMAIL PROTECTED]
Date: Mon, 23 May 2005 13:24:18 -0700
The other alternative is to touch /etc/disable_64_gcc
Sure, but in the mail you are specifically replying to I stated:
Also, /etc/disable_64_gcc is a workaround and should not be there
by default as it is now, especially on your
From: Ben Collins [EMAIL PROTECTED]
Date: Mon, 23 May 2005 20:21:57 -0400
But (and this but is for David), that means users can't simply do
apt-get source foo; cd foo-1.1; dpkg-buildpackage and get the same build
they got from us, which is a consistency Debian needs. Maintainers trying
to fix
On Sat, 21 May 2005 14:06:52 +0200
Falk Hueffner [EMAIL PROTECTED] wrote:
this bug has been open for quite some time as important. Can some
sparc people please comment on it?
This is not a bug, it should be closed. On sparc64, gcc should emit
64-bit code by default. If you want 32-bit code
From: Thiemo Seufer [EMAIL PROTECTED]
Date: Sun, 22 May 2005 01:37:50 +0200
David S. Miller wrote:
[snip]
This is not a bug, it should be closed. On sparc64, gcc should emit
64-bit code by default. If you want 32-bit code emitted on a sparc64
system you have exactly two options 1) add
On Fri, 29 Apr 2005 11:48:07 +0200
Frans Pop [EMAIL PROTECTED] wrote:
One problem is that the Mostek RTC driver currently does not support the
RTC_(RD/SET)_TIME. However, the thread contains a patch that will fix
this. I am not completely sure if this patch is final yet or if has will
be
On Sat, 16 Apr 2005 03:10:17 -0400 (EDT)
Jurij Smakov [EMAIL PROTECTED] wrote:
Please review and apply if it makes sense :-).
Looks good, I'll apply this.
Thanks Jurij.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Mon, 14 Mar 2005 22:21:53 -0500
Joey Hess [EMAIL PROTECTED] wrote:
Yes, but I didn't realize that it was probably a non-bug. Do you think I
ought to revert that then?
I think so, just autoloading modules to work around incorrect
SBUS module loading isn't such a good idea.
Ben didn't
On Mon, 14 Mar 2005 23:57:08 -0500 (EST)
Jurij Smakov [EMAIL PROTECTED] wrote:
It only looks for (and scans for devices on) the first one
it finds. I am reassigning this report to dicover1 and will try to cook up
a patch for that.
Perfect. sun4d systems would need such a fix as well, they
20 matches
Mail list logo