angelog 2024-03-12 12:14:12.0 +0100
+++ cfengine3-3.21.4/debian/changelog 2024-04-18 11:32:38.0 +0200
@@ -1,3 +1,10 @@
+cfengine3 (3.21.4-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * d/patches/time-t-long-long.patch: coerce time_t to long long (closes: #1068665)
+
+ -- Eman
Hi Roland,
On 2024-03-05 03:15, Roland Mas wrote:
> close 1063631 5.0.0.3381-2
The version of hkl currently in unstable, 5.0.0.3381-1, fails to build.
Would it be possible to upload 5.0.0.3381-2 to unstable?
Emanuele
@ -1,3 +1,11 @@
+amberol (0.10.3-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Update build dependencies: librust-lofty-0.18-dev,
+librust-mpris-server-0.7-dev. (Closes: #1064531)
+
+ -- Emanuele Rocca Fri, 12 Apr 2024 12:23:35 +0200
+
amberol (0.10.3-2) unstable; u
+0200
@@ -1,3 +1,10 @@
+mathgl (8.0.1-8) unstable; urgency=medium
+
+ * Build-depend on python3-all to ensure all supported python versions are
+installed when running debian/tests/run-tests. (Closes: #1067367)
+
+ -- Emanuele Rocca Thu, 11 Apr 2024 15:00:39 +0200
+
mathgl (8.0.1-7) un
.
+ * Apply upstream patch to fix FTBFS on armhf/armel (Closes: #1067829)
+
+ -- Emanuele Rocca Thu, 28 Mar 2024 16:56:19 +0100
+
nfs-utils (1:2.6.4-3) unstable; urgency=medium
[ Salvatore Bonaccorso ]
diff -Nru nfs-utils-2.6.4/debian/patches/flushtime-long-long-int.patch nfs-utils-
Hi Andreas,
On 2024-03-19 10:40, Andreas Tille wrote:
> Since you all pinged that bug we now have another 4 weeks of time before
> anything gets removed from testing. So we just need to bear the noise
> from testing removal warnings of quite some packages (which I'd love to
> get rid of thus
Hi,
On 2024-03-19 06:24, Sébastien Jodogne wrote:
> Because of bug #1060104, a large majority of the packages related to
> medical imaging have just disappeared from Debian Unstable.
>
> But, if I correctly understand #1060104, it is specific to one single
> platform (armel).
Indeed, and
Source: grok
Version: 1.20110708.1-7.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: time-t
Hi,
grok fails to build from source if -Werror=implicit-function-declaration
is on. The flag was added to the default ones on armhf and armel to help
with the ongoing time64
Source: fakeroot
Version: 1.34-1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: time-t
Hi,
fakeroot fails to build on armhf and armel when compiled with the time64
flags:
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
Source: mongo-c-driver
Version: 1.26.0-1.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: time-t
Dear Maintainer,
mongo-c-driver fails to build from source on armhf. The failure may be
explained with the build flags introduced for the time64 migration,
which are on by
Hi Michael,
On 2024-03-01 09:13, Michael Tokarev wrote:
> This has nothing to do with time64.
Yes and no. :-)
> The prob here is -Werror=implicit-function-declaration
>
> Where that flag is coming from?
Source: udns
Version: 0.4-1.1
Severity: serious
Tags: ftbfs
User: debian-de...@lists.debian.org
Usertags: time64
Dear Maintainer,
udns fails to build on both armhf and armel with the time64 build flags, which
are on by default. It builds fine without.
Specifically, the following flags cause a
Source: google-perftools
Version: 2.15-1.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertag: time64
Dear Maintainer,
google-perftools fails to build from source when building with -D_TIME_BITS=64
on armhf and armel with the following error:
src/mmap_hook.cc:309:31: error:
On 2024-03-01 10:28, Emanuele Rocca wrote:
> /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed
> only with _FILE_OFFSET_BITS=64"
>26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
> | ^
The build
Source: v4l-utils
Version: 1.26.1-3.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertag: time64
Dear Maintainer,
v4l-utils fails to build from source on armhf and armel with the
following error:
In file included from /usr/include/features.h:393,
from
Hi,
On 2024-02-08 02:06, Colin Watson wrote:
> On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote:
> > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca :
> > >Perhaps this is related to the fact that 1.224 dropped the binary
> > >package console-s
Source: pycurl
Version: 7.45.2-7
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid trixie ftbfs
Dear Maintainer,
pycurl currently fails to build from source on amd64 and arm64 with the
following error:
===
Source: lsof
Version: 4.95.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid trixie ftbfs
Dear Maintainer,
lsof currently fails to build from source on amd64 and arm64 with the following
error:
Optional tests:
LTbigf ... OK
Source: console-setup
Version: 1.224
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid trixie ftbfs
Dear Maintainer,
console-setup 1.224 fails to build from source with the following error:
Dumping the encoded keymaps for pc105...
Source: libcap-ng
Version: 0.8.4-1
Severity: serious
Tags: sid trixie ftbfs
Hi,
libcap-ng currently FTBFS with the following error:
make[6]: Entering directory '/<>/build-py3.11/bindings/python3'
cat /usr/include/linux/capability.h | grep '^#define CAP' | grep -v '[()]' >
caps.h
cat
Hi,
On 2024-02-04 08:47, Paul Gevers wrote:
> With a recent upload of gcc-defaults the autopkgtest of mosquitto fails in
> testing when that autopkgtest is run with the binary packages of
> gcc-defaults from unstable on armel. It passes when run with only packages
> from testing. In tabular form:
.
+Closes: -1.
+
+ -- Emanuele Rocca Tue, 06 Feb 2024 20:23:38 +0100
+
gdb-mingw-w64 (13) unstable; urgency=medium
* Switch from the obsolete libncurses5-dev build-dependency to
diff -Nru gdb-mingw-w64-13/debian/rules gdb-mingw-w64-13+nmu1/debian/rules
--- gdb-mingw-w64-13/debian/rules 2023-09-29
Source: gcc-14
Version: 14-20240201-2
Severity: serious
Tags: sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
gcc-14 currently FTBFS on arm64 due to an upstream regression. Last known
working version was 20240131.
during GIMPLE pass: widening_mul
../../src/gcc/value-range-storage.cc:
load.
+ * Don't run autopkgtests on armhf due to valgrind bug #1061496. (Closes: #XXX)
+
+ -- Emanuele Rocca Fri, 26 Jan 2024 11:02:37 +0100
+
sndfile-tools (1.5-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru sndfile-tools-1.5/debian/tests/control sndfile-tools-1.5/debian/tests/contr
@@ -1,3 +1,11 @@
+libvorbis (1.3.7-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable test-coupling-segfault on armhf due to valgrind bug #1061496.
+(Closes: #XXX)
+
+ -- Emanuele Rocca Thu, 25 Jan 2024 16:25:09 +0100
+
libvorbis (1.3.7-1) unstable; urgency=medium
now that #1057693 is fixed.
+
+ -- Emanuele Rocca Thu, 25 Jan 2024 12:29:55 +0100
+
libgssglue (0.8-2) unstable; urgency=medium
* Disable valgrind in i386 due to #1057693.
diff -Nru libgssglue-0.8/debian/tests/control libgssglue-0.8/debian/tests/control
--- libgssglue-0.8/debian/tests
Source: kbtin
Version: 2.1-2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash
Hi,
kbtin currently fails to build from source on armhf. The failure is due
to an incompatibility between valgrind and stack-clash-protection on
32bit arm reported upstream at:
Source: jtdx
Version: 2.2.159-1
Severity: serious
Tags: ftbfs, patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash
Dear Maintainer,
jtdx currently fails to build from source on armel. To address the
immediate issue, please disable stack-clash-protection with the
following snippet
Hi Mathieu,
On 2024-01-14 11:24, Mathieu Malaterre wrote:
> On Sat, Jan 13, 2024 at 9:42 PM Emanuele Rocca wrote:
> > We should downgrade the severity to minor once the fix enters unstable, but
> > keep the bug open as this seems to be an interesting case of
> > s
Control: user -1 debian-...@lists.debian.org
Control: usertag -1 + 32bit-stackclash
Hi,
On Fri, Jan 05, 2024 at 11:45:28PM +0100, Sebastian Ramacher wrote:
> /tmp/ccm0eYhx.s: Assembler messages:
> /tmp/ccm0eYhx.s:537: Error: bad immediate value for offset (4100)
This is caused by
Source: dumpasn1
Version: 20210212-3
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash
Hi,
dumpasn1 currently fails to build from source on armhf. The failure is due to
an incompatibility between valgrind and stack-clash-protection on 32bit arm
reported
Source: abinit
Version: 9.10.4-2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash
Dear Maintainer,
abinit currently fails to build from source on armhf. To address the immediate
issue, please disable stack-clash-protection with the following snippet in
Hi Julian!
On 2024-01-12 01:47, Julian Andres Klode wrote:
> Either way, these are harmless
I'm not saying they're harmful, what I'm saying is:
1) the errors you see on armhf when building apt without
stack-clash-protection are the same valgrind reports on amd64 as
well. Hence, you could
Hi Julian,
On 2024-01-11 05:46, Julian Andres Klode wrote:
> And there aren't any hard errors. We could zero initialize
> those or add supressions to make things look nicer I suppose.
Mmmh no, they are all actual errors as far as valgrind is concerned.
The thing is, you're running valgrind
Hi Julian,
On 2024-01-08 10:28, Julian Andres Klode wrote:
> (in Ubuntu we have partially recovered by disabling stack clash
> protection but it crashes on invalid writes there, I suppose we need
> to rebuild some more apt dependencies without the flag...).
The 'invalid writes' issue seems
I've added more context to https://bugs.debian.org/1059352#38, but just to have
some info here too this is the error:
722s ==221367== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
722s ==221367== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright
info
722s ==221367==
Control: retitle -1 valgrind: Access not within mapped region on armhf
Hello Paul and Julian,
On 2023-12-24 07:31, Paul Gevers wrote:
> On 23-12-2023 20:40, Julian Andres Klode wrote:
> > the logs for well known bugs so that you don't end up filing bugs
> > against every package broken by
Hi,
On 2023-12-04 03:10, Ben Hutchings wrote:
> The D and W flags mean there were prior BUG and WARN errors logged.
> Please send those as well.
Here is the very first warning:
Nov 30 17:16:45 ci-worker-armhf-03 kernel: WARNING: CPU: 10 PID: 1592 at
fs/dcache.c:365 dentry_free+0x98/0xd0
Control: retitle -1 systemtap: FTBFS with g++-13 on i386, ppc64el, riscv64
On 2023-12-01 04:53, Emanuele Rocca wrote:
> In constructor ‘symresolution_info::symresolution_info(systemtap_session&,
> bool)’,
> inlined from ‘int semantic_pass_symbols(systemtap_session&)’ at
>
Package: systemtap
Version: 5.0-1
Severity: serious
g++ -DHAVE_CONFIG_H -I. -DBINDIR='"/usr/bin"' -DSYSCONFDIR='"/etc"'
-DPKGDATADIR='"/usr/share/systemtap"' -DPKGLIBDIR='"/usr/lib/systemtap"'
-DLOCALEDIR='"/usr/share/locale"' -DDOCDIR='"/usr/share/doc/systemtap"'
-DPYEXECDIR='""'
Hi!
On 2023-11-09 05:11, Rafael Laboissière wrote:
> The Fortran example x09f.f90, which is exercised during the building of
> plplot, now fails on armhf, due to the use of the compiler option
> -fstack-clash-protection.
The problem seems unrelated to stach-clash-protection I think, enabling
the
Hello Andrius,
On 2023-09-09 08:38, Andrius Merkys wrote:
> This is news to me. Could you please point out where in Debian Policy I can
> read more about such requirement? I thought I saw packages dropping support
> for one or another release architecture without being removed from testing.
See
Control: retitle -1 asmjit: FTBFS on armel and armhf
Hi Andrius,
On 2023-08-28 07:42, Andrius Merkys wrote:
> On Wed, 16 Aug 2023 14:29:10 +0200 Emanuele Rocca wrote:
> > asmjit does not build correctly on the following architectures:
> > armel, armhf, mips64el, mipsel, s
Hallo Andreas,
On Fri, Aug 25, 2023 at 11:28:16AM +0200, Andreas Tille wrote:
> Am Wed, Aug 16, 2023 at 03:43:24PM +0200 schrieb Emanuele Rocca:
> > btllib currently fails to build from source on armhf with the following
> > tests-related error:
>
> Armhf (as well as
Hi,
On 2023-08-25 09:46, Graham Inggs wrote:
> On Fri, 25 Aug 2023 at 09:03, Andreas Tille wrote:
> > upstream does not support 32bit and the usage of this package on 32bit is
> > questionable anyway so please remove all 32bit builds of this package.
>
> Andreas, what 32-bit builds? bbhash has
Source: cpu-features
Version: 0.7.0-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-...@lists.debian.org
Usertags: armhf armel
Hi,
cpu-features fails to build on armhf and armel with the following error:
In file included from /<>/test/cpuinfo_aarch64_test.cc:15:
Hi!
On 2023-08-21 07:36, Adam Borowski wrote:
> On Mon, Aug 21, 2023 at 10:38:52AM +0200, Emanuele Rocca wrote:
> > Well FTBFS is a bug isn't it? :-)
>
> A FTBFS on an architecture that has built before (and hasn't been RMed)
> is a bug, and one that's policied as high seve
Control: retitle -1 cpp-httplib: FTBFS on s390x, armhf due to flaky tests
Hi,
On 2023-07-24 04:26, Andrea Pappacoda wrote:
> I've looked into this, but I couldn't find any change which would
> cause test failures on s390x specifically. cpp-httplib's test suite
> is a bit flaky though, so it may
Hi Adam,
On 2023-08-16 05:14, Adam Borowski wrote:
> This is not a regression, thus why would it be a bug?
Well FTBFS is a bug isn't it? :-)
> There's nothing in birdtray itself that would prevent it from being built on
> these architectures the moment problems in thunderbird are resolved
Why
Hi Matthias,
On 2023-08-18 06:46, Matthias Klose wrote:
> still ftbfs on arm64 and armhf. would it be possible to pay attention to
> build failures after uploads, or even better to pay attention until the
> package migrates?
See https://bugs.debian.org/1037579#43
We are currently packaging the
Source: coinor-bonmin
Version: 1.8.9-1
Severity: serious
Tags: sid trixie ftbfs
Hi,
coinor-bonmin fails to build with the following error:
g++ -shared -nostdlib
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o .libs/BonCbc.o
Source: cctz
Version: 2.3+dfsg1-3
Severity: serious
Tags: sid trixie ftbfs
Hi,
cctz fails to build with the following error message:
75% tests passed, 1 tests failed out of 4
Total Test time (real) = 30.25 sec
The following tests FAILED:
2 - time_zone_lookup_test (Failed)
Errors
Source: coccinelle
Version: 1.1.1.deb-3
Severity: serious
Tags: sid ftbfs
User: debian-...@lists.debian.org
Usertags: armhf
Hi,
coccinelle fails to build from source on armhf with a "out of memory"
error.
(1) The error seems to be a red herring given that the machine on
which I'm building the
Source: btllib
Version: 1.4.10+dfsg-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
Hi,
btllib currently fails to build from source on armhf with the following
tests-related error:
Iteration 1
Test FASTA
Source: birdtray
Version: 1.9.0+ds-2
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
Hi,
birdtray is 'Architecture: any' and build-depends on thunderbird.
However, armhf, armel, and mipsel are not in thunderbird's architecture
list. For this reason birdtray cannot be build on
Source: bbhash
Version: 1.0.0-5
Severity: serious
Tags: sid trixie ftbfs
Hi,
bbhash does not build correctly on the following 32 bit architectures:
armel, armhf, i386, mipsel.
g++ -o example_custom_hash example_custom_hash.cpp -O3 -std=c++11 -lpthread
In file included from example.cpp:1:
Source: asmjit
Version: 0.0~git20230427.3577608-1
Severity: serious
Tags: sid trixie ftbfs
Hi,
asmjit does not build correctly on the following architectures:
armel, armhf, mips64el, mipsel, s390x.
On armel, armhf, and s390x the error is tests-related:
[...]
1: Success:
1: All tests
Package: src:arm-compute-library
Version: 20.08+dfsg-7
Severity: serious
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-13
With GCC-13, arm-compute-library fails to build from source on both arm64 and
armhf with the following errors:
Note that since the upload of 20.08-13 the package now fails to build for
different reasons on i386 vs arm64/armhf.
I've opened https://bugs.debian.org/1042942 for i386.
On arm64/armhf the bug seems to be due to a missing include in
core/utils/misc/Utility.h from libarm-compute-dev.
[ 2%]
Package: src:armnn
Version: 20.08-13
Severity: serious
armnn 20.08-13 seems to compile correctly on i386, but then FTBFS due to
the following test failures:
Running 430 test cases...
./src/armnn/test/ModelAccuracyCheckerTest.cpp(103): [1;31;49merror: in
Hi,
On 2023-07-08 08:43, Matthias Klose wrote:
> [...]
> checking linker soname option... yes
> checking linker --demangle support... no
> checking linker plugin support... 0
> checking assembler for explicit relocation support... no
> checking assembler for -mno-shared support... no
> checking
Hi Paul,
On 2023-04-25 10:03, Paul Gevers wrote:
> Your package has an autopkgtest, great. However, it fails since April 2023
> on arm64, i386, ppc64el and s390x. Can you please investigate the situation
> and fix it? I copied some of the output at the bottom of this report.
The reality of the
Hi Jeremy and Simon!
On 2023-03-15 11:50, Emanuele Rocca wrote:
> Motivated by this, I've tried to build mozjs78 with GCC 11 instead of
> 12, and it *did* build successfully. My proposal is thus to build
> mozjs78 with GCC 11 on armhf and armel, see attached patch.
I've now d
* Non-maintainer upload.
+ * Build with GCC 11 on armhf and armel (Closes: #1029167).
+
+ -- Emanuele Rocca Wed, 15 Mar 2023 10:36:30 +0100
+
mozjs78 (78.15.0-6) unstable; urgency=medium
* Add patch to fix build with Python 3.11 (Closes: #1028308)
diff -Nru mozjs78-78.15.0/debian/control.
On 2023-01-27 12:03, Adrian Bunk wrote:
> WITH_SYSTEM_ICU = yes fixes this error on armel.
And on armhf too.
> The build fails later due to 146 TEST-UNEXPECTED-FAIL,
> which is not a problem for 0ad who aren't running the mozjs testsuite.
Of those 146 test failures, many seem to be
Control: tags -1 + patch
On Fri, Mar 03, 2023 at 03:13:15PM +0100, Emanuele Rocca wrote:
> Firefox seems to erroneously enable NEON in places where it shouldn't. Trying
> to figure out exactly where and what's the best way to address this.
Patch attached.
According to the large disc
Hi,
On Wed, Mar 01, 2023 at 02:41:05PM +0100, Jérémy Lal wrote:
> For now I'm unlucky with the porterbox, because /var/run/schroot
> disappeared yesterday.
I can confirm that the issue isn't reproducible with V8_DEFAULT_STACK_SIZE_KB
set to 984. Built and tested on a Macbook M1.
Hi,
On Sun, Feb 14, 2021 at 02:12:17PM +, Vincent Arkesteijn wrote:
> Firefox is killed with SIGILL shortly after startup:
> $ firefox-esr -safe-mode
> Illegal instruction
> $
This is due to the fact that some armhf CPUs do not have support for NEON
instructions.
skia used to detect such
Package: armnn
Version: 20.08
Severity: serious
Tags: upstream ftbfs patch
Justification: fails to build from source (but built successfully in the past)
The package fails to build with gcc 12, currently in sid and bookworm. It does
build fine with gcc 10 in bullseye.
The issue has been fixed
Source: python-pytest-flake8
Version: 1.0.6-4
Severity: serious
The package fails to build with the flake8 version currently in sid,
namely 5.0.4-1. Multiple tests fail, partial output follows:
[...]
copying pytest_flake8.py ->
Source: flake8-class-newline
Version: 1.6.0-2
Severity: serious
Hi,
the test fails with the latest flake8 version in sid (5.0.4-1).
The output of flake8 --version with -class-newline installed is now:
$ flake8 --version
5.0.4 (flake8-class-newline: 1.6.0, mccabe: 0.6.1, pycodestyle: 2.9.1,
Source: ros-rosdep
Version: 0.22.1-1
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
Hi,
ros-rosdep fails to build with the flake8 version currently in sid.
The relevant part of a failed build follows:
1 E275 missing whitespace after keyword
- Captured
Source: budgie-extras
Version: 1.4.90-2
Severity: serious
Justification: FTBFS
Tags: sid ftbfs patch
Hi,
budgie-extras fails to build due to a pep8 error with pycodestyle
2.9.1-1 (currently in sid). The attached patch fixes the issue.
See the relevant part of the build logs:
./tools/run-pep8
=
tag 1011951 pending
thanks
Fixed in git:
https://salsa.debian.org/python-team/packages/python-gevent/-/blob/9fc8b389269f5d6415ef1019e81e2a458667829b/debian/changelog
On 12/08 02:36, Graham Inggs wrote:
> Source: tinyarray
> Version: 1.2.3-4
> Severity: serious
> Tags: ftbfs
> User: debian-pyt...@lists.debian.org
> Usertags: python3.10
>
> Hi Maintainer
>
> Your package FTBFS on i386 during the recent rebuilds for Python 3.10
I've enabled CI/CD on Salsa and
On 28/08 10:04, Gordon Ball wrote:
> Package: python3-testpath
> Version: 0.6.0+dfsg-2
> The package is empty except for the changelog.
Proposed fix here:
https://salsa.debian.org/python-team/packages/testpath/-/merge_requests/1
Hi,
On 08/04 09:36, Paul Gevers wrote:
> We are in the transition of making python3.10 the default Python versions
> [0]. With a recent upload of python3-defaults the autopkgtest of pytorch
> fails in testing when that autopkgtest is run with the binary packages of
> python3-defaults from
Package: bpftrace
Version: 0.11.3-3
Severity: grave
Justification: renders package unusable
Any attempt of running bpftrace programs fails on my sid workstation:
$ sudo bpftrace -e 'kprobe:do_nanosleep { printf("PID %d sleeping\n", pid); }'
Two passes with the same argument (-tti) attempted to
Package: systemtap
Version: 4.3-2
Severity: grave
With linux-image-5.8.0-3-amd64 version 5.8.14-1, stap fails as follows:
$ sudo stap -e 'probe oneshot { println("hello world") }'
[...]
/usr/share/systemtap/runtime/linux/access_process_vm.h: In function
‘__access_process_vm_’:
On 10/02 09:47, Matthias Klose wrote:
> ruby-http ftbfs for 2.5, but not for 2.3 in unstable:
Note that the bug is not reproducible with ruby-http 3.3.0-2 as tests
have been disabled:
https://salsa.debian.org/ruby-team/ruby-http/commit/728a3fbcc7c59ebb14cb55aa9f084b910d666971
On 25/02 03:29, Sandro Tosi wrote:
> Emanuele, pytest-localserver has been orphaned, so you can go ahead
> and upload it if you want
Done.
> (and i dont think it's appropriate anymore to use the DPMT git repo, i
> guess you can move it to the debian/ namespace)
Also done, thanks Sandro.
tag 911836 patch
tag 911836 pending
thanks
Fix pushed to salsa:
https://salsa.debian.org/python-team/modules/pytest-localserver/merge_requests/1/diffs?commit_id=bad8a656ec5383c5b8a1d1e52f75e7afbe7c8c1b
elog 2017-11-16 13:54:03.0 +0100
+++ xmms2-0.8+dfsg/debian/changelog 2019-02-25 08:12:48.0 +0100
@@ -1,3 +1,11 @@
+xmms2 (0.8+dfsg-18.2) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Build using GCC 8 and tighten dependency on the shared library. Closes:
+#871285
+
+ -- Em
+0100
+++ dstat-0.7.3/debian/changelog 2019-02-23 02:10:18.0 +0100
@@ -1,3 +1,11 @@
+dstat (0.7.3-1.1) unstable; urgency=high
+
+ * Non-maintainer upload
+ * Fix crash in top-int plugin (closes: #852927)
+ * Exclude ntp plugin from --all-plugins, used by make test (closes: #857973)
+
unstable; urgency=high
+
+ * Non-maintainer upload
+ * Fix crash in top-int plugin (closes: #852927)
+ * Exclude ntp plugin from --all-plugins, used by make test (closes: #857973)
+
+ -- Emanuele Rocca Sat, 23 Feb 2019 02:10:18 +0100
+
dstat (0.7.3-1) unstable; urgency=medium
* New upstrea
Package: systemtap
Version: 3.3-1
Severity: grave
Justification: renders package unusable
SystemTap 3.3-1 does not work with the kernel currently in sid,
linux-image-4.19.0-3-amd64 4.19.20-1.
$ sudo stap -e 'probe oneshot { println("hello world") }'
In file included from
Note that the failure is due to stapbpf/Makefile.am trying to add the
stapusr group, and the systemtap Debian package does that in
systemtap-runtime's postinst script already.
Perhaps it would make sense to patch stapbpf/Makefile.am to get rid of
install-exec-hook, and add a dpkg-statoverride
On 12/07 12:21, Emanuele Rocca wrote:
> We need to either patch varnishtest and hardcode feature_dns, or avoid
> running the tests altogether.
As ssm suggested, we can use libnss-wrapper instead and avoid actually
performing the DNS request:
http://anonscm.debian.org/cgit/pkg-varnish/v
Hi,
On 12/07 09:22, Chris Lamb wrote:
> Whilst varnish-modules builds successfully on unstable/amd64, according to
> Debian Policy 4.9 packages may not attempt network access during
> a build.
>
> 00:00:00.00 IP e66b957b9098.60905 >
> sitecomwlr1000.sitecomwlr1000.domain: 10880+ A?
as int to match getopt return type. Fixes
+apcaccess on ARM. (Closes: #770984)
+
+ -- Emanuele Rocca e...@debian.org Tue, 14 Apr 2015 09:14:33 +0200
+
apcupsd (3.14.12-1) unstable; urgency=low
* [84a0ea2] Imported Upstream version 3.14.12
diff -u apcupsd-3.14.12/debian/patches/series apcupsd
Hi,
On 25/11 07:15, Adrien Grellier wrote:
apcaccess is not working on raspberry pi : it always respond as if -h
option was given.
I can confirm that the issue is reproducible on asachi.debian.org (armhf):
(sid_armhf-dchroot)ema@asachi:~$ /sbin/apcaccess
Usage: apcaccess [-f
On 24/05 11:58, Lucas Nussbaum wrote:
Source: ruby-net-sftp
Version: 1:2.0.5-2
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20120524 qa-ftbfs
Justification: FTBFS on amd64
[...]
/usr/bin/ruby1.8 -I/usr/lib/ruby/vendor_ruby
Hi,
On 04/07 10:16, Andreas Beckmann wrote:
during a test with piuparts I noticed your package failed to install
(in 'squeeze'), remove (but not purge), distupgrade to 'wheezy',
and install again.
Before the second installation the package is in config-files-remaining
state. The
Hi guys,
On 28/09/09 - 10:47, Kumar Appaiah wrote:
Would you consider doing an NMU for this bug? Given that the bug has
been open with a patch for well over a month, I'd say you could
proceed with at least a DELAYED NMU.
No need to delay the NMU, feel free to upload.
ciao,
ema
* Vladimir Volovich [EMAIL PROTECTED], [2007-09-04 19:26 +0400]:
FK == Filipus Klutiero writes:
FK Hi, in July, Sune Vuorela sent a mail to debian-sparc requesting
FK to try reproducing #433801 on kdm, but there were no answers. I
FK checked the web archives and couldn't find the
Package: freepops
Version: 0.2.2-1
Severity: serious
freepops 0.2.2-1 fails to build from source:
# keep these in sync with win32 installer
cp: cannot stat `doc/manual*.pdf': No such file or directory
make[1]: Leaving directory `/build/buildd/freepops-0.2.2'
mv
Package: helix-player
Version: 1.0.8-2
Severity: serious
Justification: Fails to build
In #339469 the submitter reported two different problems: FTBFS on
powerpc and FTBFS on sparc.
While the upload of helix-player 1.0.7-1 fixed the former [1], the
latter is still present [2].
The attached
reopen 394475
tag 394475 patch
tag 395984 patch
thanks
Hello James,
* James R. Van Zandt [EMAIL PROTECTED], [2006-10-28 16:14 -0400]:
Actually automake is not required to build the package, so I removed
it from the list.
I've tried rebuilding minpack 19961126-10 under pbuilder, but it
tag 394475 patch
thanks
minpack builds correctly on hppa bumping the automake build dependency
to automake1.9.
Log of successful building:
http://people.debian.org/~ema/minpack-19961126-hppa.log
More information about the current automake situation:
http://wiki.debian.org/AutomakeTransition
* Yves-Alexis Perez [EMAIL PROTECTED], [2006-03-27 11:41 +0200]:
On Mon, 2006-03-27 at 11:10 +0200, Nando Santagata wrote:
*** glibc detected *** free(): invalid pointer: 0x083017a8 ***
I tried to remove the plug-ins one by one, just to determine if the it's
xfce4-panel itself to
1 - 100 of 103 matches
Mail list logo
