Upstream is currently working on this. For the time being adding
-D_LARGEFILE64_SOURCE fixes this bug
David JamesFrom 9b718bbf7f94899e7643563e9f30a6665d1e8b39 Mon Sep 17 00:00:00 2001
From: Castor216
Date: Tue, 4 Jun 2024 19:22:49 +0100
Subject: [PATCH] add -D_LARGEFILE64_SOURCE to CFLAGS
Package: libsingular4m3n0t64
Version: 1:4.4.0+ds-1
Severity: serious
Justification: Policy 8.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
According to policy 8.1
"The run-time shared library must be placed in a package whose name
changes whenever the SONAME of the shared library changes."
--
David Waitzman
Principal Distributed Systems Engineering
d...@domaintools.com
On Thu, 18 Apr 2024 23:39:14 + IvanAbs wrote:
> On 2024-04-17 several of my servers running Debian 10 received an
> update for the tzdata package via Debian unattended-upgrade. However,
> this update resulted in corruption of files within the
> /usr/share/zoneinfo directory.
I, too,
On Mon, Apr 29, 2024 at 06:05:08PM +0200, Daniel Baumann wrote:
> my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've
> fixed that locally but a build to confirming on an armel porterbox is
> runnning before uploading 10.0-0.3 in some minutes..
I've synced in (all of) your
the best fix for this is, I looked at
https://wiki.debian.org/ReleaseGoals/64bit-time but there is no mention
of atomic ops on time_t. Googling didn't yield anything either. Is frr
the only package using "_Atomic time_t"?
Input appreciated...
-equi (David)
Control: severity -1 important
> Source: racket
> Version: 8.12+dfsg1-7
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel
OK, I figured out why this doesn't show up on the buildd's: they don't
tag 1041415 - upstream
thanks
Ultimately this fails because /proc is not available in the chroot.
The version of libc in use *emulates* fchmodat() using /proc/self/fd
rather than using the fchmodat system call.
When /proc is provided in the chroot, the fchmodat emulation works
successfully and
tag 1041415 + upstream
thanks
The error message:
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File
>>error (("Doing chmod" "Operation not supported"
>>"/usr/share/emacs/site-lisp/debian-startup.elcFx8oFi"))
comes from the emacs byte compiler. Tracing through the
Ah, by specifically using a chroot rather than a systemd-nspawn
container, I *am* able to reproduce the failure.
Off to debug...
--
I'm not living in the real world, no more, no more.
I was not able to reproduce this failure.
Is there anything interesting about the filesystem underlying the chroot
used during the install?
Is root able to write files with impunity in the relevant directories?
Are you able to reproduce the failure?
--
Time is waiting to explain, why refuse?
The failure to build elpa-cider is caused by:
> In toplevel form:
> cider.el:218:1: Error: Wrong number of arguments: (3 . 4), 2
In the source, this corresponds to:
> (define-obsolete-variable-alias 'cider-default-repl-command
> 'cider-jack-in-default)
In recent versions of emacs, the
Control: tag -1 confirmed
Lucas Nussbaum writes:
> Source: racket
> Version: 8.12+dfsg1-7
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel
>
> Hi,
>
> During a rebuild of all packages in sid,
s bug gets resolved.
Thank you.
_
David Landry
y hands make light-er work, I guess
David
Control: reassign -1 flint
Sebastian Ramacher writes:
> Source: polymake
> Version: 4.11-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
>
>
Control: reassign -1 flint
Lucas Nussbaum writes:
> Source: polymake
> Version: 4.11-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240319 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed
Package: org-mode
Version: 9.6.10+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: debian-emac...@lists.debian.org, Debian Security Team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In https://list.orgmode.org/87o7b3eczr@bzg.fr/T/#t, Ihor
Source: emacs
Version: 29.2+1-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team ,
debian-emac...@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
According to the 29.3 release notes
* Changes in Emacs 29.3
Emacs 29.3
on python3-packaging. This
change was made to libglib2.0-dev-bin in version 2.78.3-2 on 23 Jan
2024.
I've committed the Build-Depends change to Debian Salsa.
Thanks.
--
David W. Kennedy
Control: tag -1 pending
Hello,
Bug #1064726 in 0ad 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:
Control: tag -1 pending
Hello,
Bug #1064726 in 0ad 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:
Hi,
I've been looking at this via Ubuntu 24.04 since it has the same FTBFS.
I've PRd a fix upstream for this and have enclosed a debdiff for the
suggested fix here.
thanks
David
content_patch.debdiff
Description: Binary data
ate to testing for too long: uploader built
arch:all binary
https://bugs.debian.org/1065038
So I think things are not in a good state. What is the solution to this?
Thanks,
David
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
if nobody objects
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
objects
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
this package in Trixie (not sure if we actually want to remove
it from Bookworm, Bullseye, etc.)
I intend to follow up with RM requests in a few months if nobody objects
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
in PEAR as a way to distribute PHP packages compared
to Composer). We should probably not ship this package in Trixie (not
sure if it is worth removing from Bookworm).
I intend to follow up with RM requests in a few months if nobody objects
(but feel free to beat me to it).
Regards
David
this package in Trixie (not sure if we actually want to remove it
from Bookworm, Bullseye, etc.)
I intend to follow up with RM requests in a few months if nobody objects
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
Bookworm and Bullseye).
I intend to follow up with RM requests in a few months if nobody objects
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
should probably not ship these packages in
Trixie (not sure if we actually want to remove them from Bookworm).
I intend to follow up with RM requests in a few months if nobody objects
(but feel free to beat me to it).
Regards
David
signature.asc
Description: PGP signature
Paul Gevers writes:
> Source: racket-mode
> Version: 20231222git0-1
> Severity: serious
> Control: close -1 20240129git0-1
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
In principle the autopkgtest failure should be fixed with 20240129git0-2
just
testing (cf. #996108)
and unstable (cf. #1036726). There is a priori little point to ship
php-sql-formatter in the next (or current TBH) stable Debian release.
I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).
Regards
David
signature.asc
This looks like overkill to me, for openconnect.
There's precisely one function exported from libopenconnect which uses
time_t, and I suspect there aren't any *users* of that function in the
distribution anyway (neither openconnect(8) nor NetworkManager-
openconnect use it). So although it's not
close 1060946 1.25.0-2
thanks
application before I
have free reign to upload things, and I’ll switch this package to
fall under my ownership like a collection of other packet things to
make life a little easier going forward.
Cheers
DH
On 1 Jan 2024, at 16:46, David Ranch wrote:
Hello DaveH,
I have pushed the required fixes
fix offered by Svenis good enough for now to keep Linpac in the Debian
Unstable/Testing repos?
--David
KI6ZHD
On 12/18/2023 02:40 AM, Dave Hibberd wrote:
Hi both,
I'll prepare a team upload for this in advance of the new upstream
release (thanks David), and upload it independently
them by generating work for many people and potentially
new upgrade problems for everyone – or if we declare them, existing or
not, a non-issue at least for the upgrade to trixie.
And on a sidenote: I would advise to reconsider interacting with dpkg
too casually – but luck is probably on your side in any case.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
exhibit the
required setup).
(I will write another mail in another subthread about the finer details
of what interacting with dpkg in an upgrade means and what might be
problematic if you aren't careful – in general, not just with aliasing)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
dless, I am planning to eventually
merge the develop branch into the Master branch and releae 0.29 in the
near future which will include this and other fixes.
--David
KI6ZHD
On 12/16/2023 10:01 AM, Sven Joachim wrote:
Control: tags -1 + patch
On 2023-12-05 23:07 +0100, Santiago Vila wrote:
Package: fanwor
Version: 1.16-1
Severity: serious
Justification: Music is ineligible for inclusion in main and is not
properly attributed in debian/copyright
Dear Maintainer,
The music for fanwor located at /usr/share/fanwor/sounds/backgrnd.mod,
while a jazzed-up remix, is unmistakably the
for a spot).
So, I am currently waiting for either vim or upstream to act first while
dealing with other housekeeping things (clang-17 support) in the
meantime; so much as a status report in case anyone wonders.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Sat, Oct 28, 2023 at 12:13 AM László Böszörményi (GCS)
wrote:
>
> Hi David,
>
> On Sat, Oct 28, 2023 at 6:39 AM David Aguilar wrote:
> > This step in the build log looks suspicious:
> >
> > sed -i 's|env python|env python3|' \
> >
> > /<>
231027=lu...@debian.org=1=1=1=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please mark it as 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
--
David
Gianfranco Costamagna writes:
> Source: darktable
> Version: 4.4.2-1
> Severity: serious
> forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
> tags: ftbfs
>
Do you think maybe there should be a debian gcc bug? after all, the
distinction you point to is a difference of debian
sbin, /bin und /lib – but that isn't
all that /usr-merge entails and APT doesn't really want to be checking
for everything. Just for some easy to verify truths to ensure nothing
went south… like it seems to have happened on your system.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Control: severity -1 important
David Bremner writes:
> Andreas Beckmann writes:
>
>> Package: compat-el
>> Version: 29.1.4.1-2
>> Severity: serious
>>
>> elpa-hl-todo/sid is currently uninstallable since it depends on
>> elpa-compat (>= 29.1.4.2).
Andreas Beckmann writes:
> Package: compat-el
> Version: 29.1.4.1-2
> Severity: serious
>
> elpa-hl-todo/sid is currently uninstallable since it depends on
> elpa-compat (>= 29.1.4.2).
>
>
> Andreas
Maybe it doesn't matter, but I don't think this is a serious bug in
compat.el. It's not like a
Source: flycheck
Severity: serious
Justification: Team decision
X-Debbugs-Cc: debian-emac...@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nobody has stepped up to take care of flycheck, and it currently
blocks the transition of emacs 29 to testing.
- -- System Information:
the file was reintroduced.
--
⢀⣴⠾⠻⢶⣦⠀ David da Silva Polverari
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Debian: The universal operating system
⠈⠳⣄
kinda
scary to block the defaults meta package for a programming language
you know nothing about with your leaf package…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Source: qt6-declarative
Version: 6.4.2+dfsg-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
Build fails here:
[22/6600] cd /<>/obj-hppa-linux-gnu/src/quick &&
/usr/lib/qt6/bin/qsb --glsl 100es,120,150 --hlsl 50
Package: maildir-utils
Version: 1.8.14-2
Severity: serious
Justification: violates policy 8.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I think that libguile-mu.* need to be either moved to a private
directory or to their own packages. I don't know enough about guile to
say which is
Matthias Klose writes:
> Package: src:maildir-utils
> Version: 1.8.14-1
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
>
> [This bug is targeted to the upcoming trixie release]
>
> Please keep this issue open in the bug tracker for the package
Hi,
Le 29/06/2023 à 00:24, Athos Ribeiro a écrit :
On Wed, Jun 28, 2023 at 10:31:53PM +0100, Adam D. Barratt wrote:
On Wed, 2023-06-28 at 17:57 -0300, Athos Ribeiro wrote:
[…]
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags:
Control: reopen -1
Control: found -1 racket-mode/20230425git0-1
> The release team has announced [1] that failing autopkgtest on amd64 and
> arm64 are considered RC in testing. [Release Team member hat on] Because
> we're currently in the hard freeze for bookworm, I have marked this bug
> as
roucaries bastien writes:
>
> Yes in your case i cheched by grepping thé build log. Lua ils compiléd what
> why i set rc severity.
I suspect that you saw a different package with Lua in the name, namely
LuaAutoC. The embedding of that library is a bug, but I'm not sure
there's any practical
Bastien Roucariès writes:
> Source: darktable
> Version: Use packaged lua
> Severity: serious
> Justification: embded code copy
>
> Dear Maintainer,
>
> It appear that your package embded and compile lua
>
> Could you:
> - use the packaged lua lib
> - repack in order to avoid accidental
Paul Gevers writes:
> Source: racket-mode
> Version: 20210916git0-2
> Severity: serious
> Control: tags -1 bookworm-ignore
> User: debian...@lists.debian.org
> Usertags: regression
This bug should be fixed in testing as soon as the just-uploaded
20230425git0-2 migrates to testing (a few days?).
Fixed upstream in 9f1ba873637fd6ce4a2d366eafcf41402775852b for 8.4,
pending pick-up together with fix for #1036062 / CVE-2023-31490.
(Would bump to upstream 8.4.4 if that's acceptable?)
-equi
Fixed upstream in 9f1ba873637fd6ce4a2d366eafcf41402775852b on stable/8.4
branch.
Debian fix incoming with bump to 8.4.4 if that's OK? That wouldn't be a
targeted security fix, but FRR minor versions are bugfix-only.
-equi
Argh, wrong bug, previous mail was for 1036061.
On Tue, Jun 13, 2023 at 03:17:52PM +0200, David Lamparter wrote:
> Fixed upstream in 9f1ba873637fd6ce4a2d366eafcf41402775852b on stable/8.4
> branch.
CVE-2023-31489 / 1036062 was fixed upstream on master but not backported
to 8.4 yet; now p
notfound 1035829 frr/8.4.2-1
stop
On Tue, May 09, 2023 at 09:19:30PM +0200, Moritz Mühlenhoff wrote:
> CVE-2022-43681[0]:
> CVE-2022-40318[1]:
> CVE-2022-40302[2]:
All 3 issues are fixed/not present in 8.4 and thus also 8.4.2-1:
- CVE-2022-43681 - 6c4ca9812976596bf8b5226600269fc4031f1422
-
Antoine Beaupre writes:
> Package: elpa-markdown-toc
> Version: 0.1.5-2
> Severity: grave
>
> In Debian bookworm, markdown-toc is currently unusable.
>
> Given the following markdown buffer:
>
Hi Antoine;
I agree that markdown file looks innocuous, but do you know if it is
just this file or
Maxim Nikulin writes:
> Package: elpa-org
> Version: 9.5.2+dfsh-4
> Severity: serious
>
> Installing elpa-org package to current Debian testing (bookworm) results
> in older Org version than Org shipped with Emacs. I consider it as a
> really bad surprise for people who will upgrade from
Hi Paul,
Thanks for the report.
Le 25/04/2023 à 21:43, Paul Gevers a écrit :
Source: symfony
[…]
Your package has an autopkgtest, great. However, it fails since April
2023.
Meh, between 3 and 19 on Sid and between 11 and 21 on Bookworm.
[…]
Targeted fixes are still welcome.
[…]
7)
Also note that we have been shipping the linked patch in Debian’s
opendmarc for a while now. It is included in stable, testing, unstable
as ‘arcseal-segfaults.patch’.
See the report at #1007926, and the proposed stable update in #1033591.
Debian testing/1.4.2-2 is not affected as far as I have seen – do you
use 1.4.2-2 and it crashes for you?
Control: tag -1 unreproducible
Control: severity -1 important
H.-Dirk Schmitt writes:
> Package: elpa-flycheck
> Version: 32~git.20200527.9c435db3-3
> Severity: grave
> X-Debbugs-Cc: none, H.-Dirk Schmitt
>
>
> The combination of Emacs28 + elpa-flycheck + shellcheck in *bookworm*
> spawn
Package: 0ad
Version: 0.0.26-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the
past)
X-Debbugs-Cc: dav...@reasoned.us
Hello,
When I try to build 0ad version 0.0.26-3 in Debian unstable with
python3.11 and python3-virtualenv, build fails.
David Bremner writes:
> Adrian Bunk writes:
>
>>> FTR, the dates when epl started to FTBFS in sid and bookworm are
>>> a good match for when emacs 1:28.2+1-9 entered sid and bookworm:
>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.
Adrian Bunk writes:
>> FTR, the dates when epl started to FTBFS in sid and bookworm are
>> a good match for when emacs 1:28.2+1-9 entered sid and bookworm:
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.html
>
> Correct link:
>
Sergio Durigan Junior writes:
> On Monday, February 27 2023, David Bremner wrote:
>
>> Sergio Durigan Junior writes:
>>>
>>> I was testing with an upstream build. For Debian's Emacs, we should
>>> use:
>>>
>>> buttercup --eval "(
Sergio Durigan Junior writes:
>
> I was testing with an upstream build. For Debian's Emacs, we should
> use:
>
> buttercup --eval "(setq comp-enable-subr-trampolines nil)" -L .
>
Did you get that working with the upstream version currently in master
or with a new upstream snapshot? I tried
I was not able to use the grub2 build as-is because we are running bullseye and
the built image required newer versions of glibc.
However, I grabbed the original source code from Debian and the Debian code
patch from https://people.debian.org/~anarcat/debian/sid/ and rebuilt it myself
with
Sergio Durigan Junior writes:
> Agreed. I'm thinking about filing an RM bug against cycle-quotes; its
> last release happened 4 years ago (although there are some non-useful
> new commits on https://github.com/emacsmirror/cycle-quotes), it fails to
> build with Emacs 28, has been blocked for
David Bremner writes:
> I don't think these are the same as previously encountered
> native-compilation related failures. I get the same / similar failures
> when running
>
> EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l
> buttercup -f buttercup-run-dis
to solve
this problem.
Now we can provide this package as it is or no package exist and all
packages that depends to it are unusable.
Greetings
David
Hi,
Le Sun, Oct 23, 2022 at 02:41:49PM +0200, Lucas Nussbaum a écrit :
> Source: lucene4.10
[…]
> > [javac]
> > /<>/test-framework/src/java/org/apache/lucene/util/TestRuleSetupAndRestoreClassEnv.java:298:
> > error: cannot access SelfDescribing
> > [javac]
Hi,
Le Thu, Oct 13, 2022 at 09:17:02PM +0200, Moritz Mühlenhoff a écrit :
> Source: nekohtml
[…]
> The following vulnerability was published for nekohtml.
>
> CVE-2022-24839[0]:
I prepared an upload (new upstream release) of this package in order to
fix this RC-bug as part of the BSP currently
Hi,
Le Sat, Dec 31, 2022 at 11:42:12PM +0100, Timo R=F6hling a =E9crit :
> forwarded 1026549 https://github.com/pytest-dev/pytest-xprocess/issues/117
Thanks Timo,
I prepared an upload (new upstream release) of this package in order to
fix this RC-bug as part of the BSP currently happening in
Hi,
Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit :
> On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson
> wrote:
> > Here's a slightly different patch to implement basically the same thing
>
> Yes, I like this patch better too.
Unfortunately, even if both patches allow me
I don't think these are the same as previously encountered
native-compilation related failures. I get the same / similar failures
when running
EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l buttercup
-f buttercup-run-discover
as a non-root user with a defined home
Lucas Nussbaum writes:
> Source: epl
> Version: 0.9-5
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230101 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
This
fixed 1021278 3.0.2-2
thanks
fixed 1021278 3.0.2-1
thanks
ibnode.so.108
(gdb)
```
This is _likely_ unrelated, but I faced a "similar" (stack-related issues) bug
with golang, patch:
https://go-review.googlesource.com/c/go/+/409055/6/src/runtime/lfstack_64bit.go#40
bug report:
https://github.com/golang/go
ages, but the way to get them with apt does not work:
https://salsa.debian.org/apt-team/apt/-/merge_requests/261
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Hi,
Le 18/11/2022 à 06:36, Olly Betts a écrit :
On Fri, Nov 18, 2022 at 11:06:07AM +0800, Bo YU wrote:
On Fri, Nov 18, 2022 at 3:34 AM Olly Betts wrote:
[…]
| I suggest you to pick the current trunk code (r13000), it is not a
| release but it is more stable than 20.03
So they're
-cache/3.0.0-1).
php-symfony-polyfill is affected by the same issue (that currently
prevents me from providing the latest upstream version), probably
related to icu latest 72 upstream version.
Regards
David
OpenPGP_signature
Description: OpenPGP digital signature
o
>> be necessary: a test build picked the 3.2-dev even though both were present.
>> However I can easily do so if you prefer.
>
>Uploaded.
>
>Can you please commit that Build-Depends change to your packaging repo and
>also tag it "debian/8.0-1"?
Done.
Many thanks for the upload!
David
iced that. Now fixed and re-uploaded.
I didn't add libwxgtk3.0-gtk3-dev to Build-Conflicts, but it doesn't seem to be
necessary: a test build picked the 3.2-dev even though both were present.
However I can easily do so if you prefer.
David
a few days for a sponsor to appear before 4pane is autoremoved
on 8/11. So if you, or someone you know, would be able to do this I'd be most
grateful. Or if it's possible to delay the autoremoval...
Regards,
David
This looks of it could be the same issue as bug 1021938, which is due to a
regression in libical version 3.0.15.
--
David Jarvie
KAlarm author, KDE developer
Sorry, I made a mistake when trying to send the link to the closed bug
[1]. You can find the right link below.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976350
Regards,
David.
Hi,
I adjusted the affected versions in the BTS, but I couldn't find any
patch for it. The reference to buffer overflows seem related to
CVE-2020-27818, so I wonder whether it is a duplicate or not.
If it is, it was already closed in [1].
[1] CVE-2020-27818
Regards,
David
Source: qt6-base
Version: 6.3.1+dfsg-10
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
The build fails here:
[357/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS
1 - 100 of 4598 matches
Mail list logo
