On 6.10.2021 19.25, Simon McVittie wrote:
Source: mesa
Version: 21.2.2-1
Severity: important
Justification: cannot migrate to testing
mesa recently moved to llvm-toolchain-13, which might have been too soon:
* it fails to build on i386 (#995786, fixed upstream), leading to multiarch
skew
Package: libmediainfo-dev
Version: 21.09+dfsg-1
Severity: serious
Dear Maintainer,
When I try to link an application (cine encoder (not in Debian)) to
libmediainfo I see :
/usr/bin/ld :
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libmediainfo.so :
référence indéfinie vers «
Am 07.10.21 um 10:55 schrieb Rhonda D'Vine:
I think you misunderstand how the GPL works. The GPL is known to be
viral, and licenses compatible with the GPL are indeed compatible with
it because they allow to be covered under the GPL. The whole work in
the end is covered by the GPL, and thus
Severity: -1 minor
* Bastian Germann [2021-10-07 00:31:00 CEST]:
> abook contains distribution licenses that are not copied to
> debian/copyright. At least BSD-2-clause (xmalloc.c, misc.c), old-style
> MIT (ldif.c), FSFULLR (configure, Makefile.in), X11 (install-sh), and
> probably others.
I
On Thu, Apr 23, 2020 at 4:31 AM Ben Hutchings wrote:
>
> On Tue, 2020-04-21 at 11:26 +0200, Mathieu Malaterre wrote:
> > Dear Debian-kernel team,
> >
> > > Would it be possible to ship an alternate ppc64 kernel build without
> > > the 64K page option ?
> >
> > Could someone please clarify if this
Package: libinput10
Version: 1.19.1-1
Severity: normal
Tags: patch upstream
Forwarded: https://gitlab.freedesktop.org/libinput/libinput/-/issues/680
There's a regression in 1.19.1 which causes the cursor to jump when a
hold gesture is detected and then discarded because the motion event is
Control: reopen -1
Hey Vincent!
On Thu, Oct 07, 2021 at 08:51:37AM +0200, Vincent Bernat wrote:
> ❦ 6 October 2021 15:03 +02, Salvatore Bonaccorso:
>
> > After updating bpftrace to 0.13.0-1 in unstable, I noticed invocation
> > using a BEGIN block do not work anymore, the BEGIN_trigger
Package: raspberrypi-kernel
Version: 1:1.20210928-1~buster
Severity: normal
File: drm
Dear Maintainer,
I found this using dmesg and don_t know if it is relevant for a Pi4 2GB for
normal operation
[85186.639426] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]]
*ERROR*
Source: assimp
Severity: normal
It seems that the autopkg tests fail on all 32-bit archs (they always
did, so there is no regression):
| ARCH| state || kernel-arch |
|-|---||-|
| amd64 | pass || amd64 |
| arm64 | pass || arm64 |
| ppc64el | pass ||
Hi all,
With the risk of sounding nit-picking...
On 07-10-2021 01:26, Samuel Thibault wrote:
> Gregory Nowak, le mer. 06 oct. 2021 16:20:13 -0700, a ecrit:
>> It seems that the updated brltty package hasn't yet made it into
>> bullseye-proposed-updates.
>
> Yes, I was too busy and didn't manage
Source: r-cran-testthat
Version: 3.0.4-1
Severity: important
Hi Maintainer
Your package uses a vendored copy of catch.hpp. It will FTBFS once
glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer
being defined.
You could take this opportunity to switch to using the catch package
❦ 6 October 2021 15:03 +02, Salvatore Bonaccorso:
> After updating bpftrace to 0.13.0-1 in unstable, I noticed invocation
> using a BEGIN block do not work anymore, the BEGIN_trigger symbol
> cannot be resolved, basically reproducible with the minimal:
>
> # bpftrace -e 'BEGIN { }'
> Attaching
Package: devscripts
Version: 2.21.4
Severity: normal
Hi,
after switching socket++ watch file to git mode[1] since upstream does not
provide any tags, I've got:
$ uscan --verbose --force-download
uscan info: uscan (version 2.21.4) See uscan(1) for help
uscan info: Scan watch files in .
uscan
@l0f4r0 Can you still reproduce this issue? Is it still present in
latest upstream tagged version (ie. v1.9.3 [1])? Is it still present in
latest version from git master branch [2]?
[1]: https://github.com/ranger/ranger/releases/tag/v1.9.3
[2]: https://github.com/ranger/ranger
--
Arnaud
101 - 114 of 114 matches
Mail list logo
