Package: mariadb-server
Version: 1:10.11.3-1
Dear Maintainer,
When trying to upgrade a (sysvinit) Debian Bullseye[-backports] server with
MariaDB 10.5 to Bookworm, I ran into the following issue:
Setting up mariadb-server (1:10.11.3-1) ...
Stopping MariaDB database server: mariadbd.
Starting
Tags: fixed-upstream
Using webp-dev on buster with test file bug.c from the second bug
mentioned above compiled with -lwebp, malloc reported: "free():
corrupted unsorted chunks" within WebPIDelete().
This suggests to me that the bug may be exploitable on systems with
libwebp6 installed - of
Dear Maintainer,
It might be too late for bullseye(?), but libwebp-1.2.0 is now out - as before:
https://chromium.googlesource.com/webm/libwebp/+/refs/heads/master/NEWS
I'm concerned about the state of WebP. The upstream code
Debian/Ubuntu's distribution is based on is now over four years old.
> Kernel 5.6 was released yesterday
> from upstream, so isn't it a bit late
> now for 5.5?
>From what I've seen, it's not unusual for Debian's kernel team to wait
several minor point releases until there is a kernel they're happy with -
indeed, I wouldn't be surprised if the policy is to wait
I appreciate the concern of Debian developers for the security of their
users' data.
However, I also spent too long debugging this problem, going through the
same process of "it works in munin-run, it works if I run munin-node from
the command line; why isn't it working?"
The behaviour *is*
Package: sysstat
Version: 12.1.7-1
Severity: wishlist
Tags: upstream
As of 12.1.2 iostat reports discard statistics separately from writes:
http://sebastien.godard.pagesperso-orange.fr/changelog.html
This can be a useful feature; however, it increases the width to the point
that lines start to
I had a look at and it appears to have gone into both 5.3 (final) and
5.2.15.
For what it's worth, it took only a day or so to exhibit the issue on our
(admittedly active) nginx/postgres/PHP server; we weren't doing any unusual
work during that time. If you're using btrfs, and you can't apply a
We seem to have run into this yesterday on a production server sing a
custom compile of the 5.2.9 buster-backports kernel. nginx was hung in D
status, sync hung as well, no obvious reason for it; I ended up having to
reset the machine.
On boot I found we had lost several hours of logs and worse,
On Sun, 14 Oct 2018 12:19:33 +0200 Andreas Beckmann wrote:
> Version: 7.2.5.1+dfsg-1
>
> A new upstream version is available in experimental.
Unfortunately this fails to build from source on all 32-bit platforms:
https://buildd.debian.org/status/package.php?p=virtuoso-opensource=experimental
On
Source: embree
Version: 3.5.0+dfsg-3
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: x32
Dear Maintainers,
Embree lists architecture as 'any-amd64' as of 3.5.0+dfsg-3. This
causes it to be built under x32 (aka 'x32-gnu-linux-amd64').
The code seems to assume that 'unsigned [int]' is
> Erk. Why would they ship a header that errors instead of no file at all?
It seems the idea of not shipping it was proposed but dismissed:
https://libc-alpha.sourceware.narkive.com/NmybqkkT/patch-add-x32-dummy-sysctl#post5
As I parse this: attempting to use sysctl on x32 is a clear error, it
> > Perhaps adding && !(__X86_64__ && __ILP32__) in there as well would fix it?
>
> That check is for sys/sysctl.h, if that file still exists on X32 then
> it's not the right macro to fix.
> A better fix would be around HAVE_DECL_RANDOM_UUID in config.h.guess.
> ...
> A suitable fix would be to
Package: lua-luaossl
Version: 20161208-3
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: x32
lua-luaoss fails to build from source on x32 because:
In file included from /usr/include/x86_64-linux-gnux32/sys/sysctl.h:63:0,
from src/openssl.c:9089:
Package: libss7-2.0
Version: 2.0.0-2
Tags: ftbfs
Usertags: x32
Priority: minor
libss7 2.0 fails to build on x32 because it assumes time_t is of type
long int when it can be long long int (64-bit, on a system with a
32-bit long).
gcc -g -O2 -fdebug-prefix-map=/<>=.
Package: lzop
Version: 1.03-4+b1
Tags: ftbfs
Usertags: x32
Dear Maintainer,
lzop 1.04 was released on 10 Aug 2017:
https://www.lzop.org/lzop_news.php
Changes in 1.04 (10 Aug 2017)
* Happy 20th anniversary release!
* Added CMake build support.
* Assorted minor updates.
On Thu, 1 Aug 2019 00:58:44 + Clint Adams wrote:
> On Wed, Jul 31, 2019 at 10:29:56AM +0100, Laurence Parry wrote:
> > The issue appears to have been reported upstream as
> > "cborg fails to compile when optimize-gmp is disabled"
> > https://github.com/well-t
In fact this seems to be happening on several platforms:
https://buildd.debian.org/status/package.php?p=ghc=sid
I was looking particularly at the x32 build, which ran for over three
hours before falling over with a lack of virtual memory. It has never
successfully built 8.6.x, only 8.4.x:
Thanks for that. To be honest, what the test is doing seems odd to begin
with - looks like it's converting a double to protobuf native format, then
interpreting the result (which would be in python's '0x...' format?) as an
integer (varint?) as it doesn't know what type it should be. But again, my
Unfortunately the build now fails earlier on x32 (indeed it seems on
most 32-bit platforms) during the Python 2.7 tests, so we can't see if
the fix worked yet:
https://buildd.debian.org/status/package.php?p=protobuf=experimental
I believe this is
Control: retitle -1 [REGRESSION] e4defrag version 1.44.5-1 segfaults
on 32-bit (but 1.44.4-2 doesn't)
> I guess that, if other people participating on this thread (which I had not
> received, BTW) don't have problems with this version, then it can be closed
> (and the version in unstable should
Control: fixed -1 1.44.6
This does appear to be fixed by
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/misc/e4defrag.c?id=c3749cad154ace57ef3c23a950fbaf44c7ad8a3b
I noticed because I tried it on a production 32-bit x86 cache that
trivially segfaulted on buster due to the previous
In fact, as I was writing they released 0.2.2.0:
https://hackage.haskell.org/package/cborg
https://github.com/well-typed/cborg/commit/992b730ca6fd9c1da191bfecb2b67cabf31b54ad
...
* Support GHC built with integer-simple
...
--
Laurence "GreenReaper" Parry
http://www.greenreaper.co.uk/
Source: haskell-cborg
Version: 0.2.0.0-1
Tags: ftbfs patch upstream fixed-upstream
Usertag: x32
>From the build log:
https://buildd.debian.org/status/fetch.php?pkg=haskell-cborg=x32=0.2.1.0-1=1564205257=0
-
...
Flags chosen: optimize-gmp=False
...
[ 9 of 14] Compiling Codec.CBOR.Magic (
Control: forward -1 https://bugs.ruby-lang.org/issues/16030
I believe the necessary change is to add the line:
when 24 then expect = 54
to def test_memsize at the end of test/ruby/test_time.rb
I've taken the liberty of suggesting this upstream since it is present
in master:
I just ran e4defrag on an image cache updated to buster, which had had
some files cleared and so had space to add new ones. This resulted in
following output, demonstrating an invalid failure count close to
ULONGLONG_MAX as predicted in #15:
# e4defrag -v /cache/
...
Package: protobuf
Version: 3.5.2-1
Tags: ftbfs upstream
Usertags: x32
Severity: important
Justification: Fails to build from source (previously built
successfully for x32)
X-Debbugs-CC: debian-am...@lists.debian.org
Dear maintainer,
ruby-google-protobuf does not link under the x32 ABI, and seems
This bug was reported upstream here:
https://github.com/bitcoin/bitcoin/issues/14580
It appears to be a GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
The fix merged for the upcoming 0.19.0, 0.18.1 and 0.17.2 was to
compile with -fno-stack-reuse:
Package: postgresql-11
Version: 11~rc1-1
On most official platforms, postgresql-11 Depends on llvm70, used for
Just-in-Time Compilation:
https://www.postgresql.org/docs/current/jit.html
However, this has led to a 170% increase in package size - from ~5MB to
~13.5MB - due primarily to precompiled
It looks like x32 support was added in the development/3.11 (using -b -32
instead) in July 2012:
https://github.com/math-atlas/math-atlas/commit/5cd827d381a67fc575c4e8e331cddbbe8a12efe8
https://github.com/math-atlas/math-atlas/commit/b25a55524c1a16dd9fcbe1f0bfd57cd94a050cfa
However we're using
Package: bugs.debian.org
My avatar (and indeed all avatars) are not showing up on bugs.debian.org.
When I tried to access the URL:
https://bugs.debian.org/cgi-bin/libravatar.cgi?email=greenreaper%40gmail.com
I got an 500 Internal Server Error:
---
Internal Server Error
The server encountered an
I think the problem may be that code to use libcurl is compiled into
libphobos (std.net.curl) and tests for it are executed which do not
correctly handle its absence.
Neither libgphobos-8-dev nor libgphobos76 appear to depend on, recommend or
suggest libcurl4 and it does not appear in the build
I'm unsure this fix addresses the problem reported - perhaps due to my
choice of title!
The more extensive commit message from
https://fossies.org/linux/misc/e2fsprogs-1.44.5.tar.gz/e2fsprogs-1.44.5/doc/RelNotes/v1.44.5.txt
is:
"Use 64-bit counters to track the number of files that are
Thanks Kurt. I wasn't familiar with upstream's update cadence, but I now
see 0.175 is imminent:
https://sourceware.org/ml/elfutils-devel/2018-q4/msg00104.html
--
Laurence
>
>
This seems to be blocking me from building a x32 chroot using the
documented process for doing so, because the ELF library is a required
package (iproute2 depends on libelf-dev as of 4.6.0-2; see #812774). I
appreciate that x32 is not a great priority, but it's not going to get
better if we can't
Package: e2fsprogs
Version: 1.43.4-2
Severity: minor
I have a web cache which creates and destroys new files on a regular basis.
I tried defragmenting the cache folder recently and got this result:
# ionice -c3 nice -n 20 e4defrag -v /cache
...
I agree, and frankly I don't think it's a minor bug if your web server
doesn't come back up after a reboot.
--
Laurence "GreenReaper" Parry
Package: munin-plugins-core
Version: 2.0.33-1
The postfix_mailvolume plugin seems not to be writing its state file when
being run. This file is important for the reading of large mail logs - it
specifies the offset which has already been reached, reading only from that
point. This can greatly
Package: linux-image-amd64
Version: 4.9+80
Debian's use of the SLAB allocator combined with ongoing kernel changes mean
the ext4 inode cache wastes ~21% of space allocated to it on recent amd64
kernels, a regression from the ~2% waste in jessie.
SLAB enforces a first-order allocation (i.e. 4KB
memory cgroups decreased the stability of 4.8, regardless of whether they
were actively being used; we were not actively using them, but still
experienced lockups. Disabling them on the kernel command line fixed it.
I'm not sure if it's been fixed in 4.9 because I removed memcgroups them
from
Should this be submitted upstream via https://bugs.gw.com? I have not done
so myself because the FAQ suggests that the maintainer should, if necessary.
I appreciate that it'd be nice to have a Debian-developed resolution, as
this issue was triggered by a fix for another Debian issue. However,
This appears to be due to the cgroups memory controller. I've had had good
experience with adding cgroup_disable=memory on the kernel boot line.
You can also compile your own kernel without the the memory controller,
which I recommend if you have the capability, as it cuts out a non-trivial
Perhaps, though the SWF format does not make it easy . . .
== FWS ==
https://www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf-file-format-spec.pdf
(See Appendix A for another walkthrough)
All integer values are little-endian byte order, but big-endian bit order
within bytes. Signed
Package: file
Version: 1:5.22+15-2+deb8u2
Tags: upstream
Flash files compiled with -swf-version=32 or above are being recognized as
'application/octet-stream' (data) rather than
'application/x-shockwave-flash' due to a restriction in the magic
definition file.
Command:
file -b --mime-type
43 matches
Mail list logo
