Bug#935923: libmodbus: FTBFS on hppa - unit-test-server: no process found

I did some analysis, and this bug was quite interesting... Patch which fixes it (and probably armel too) is below. a) The "unit-test-server: no process found" error is misleading. It does not indicate that the server or client test program did not start, but it just means the "killall" program in

Bug#1070056: oath-toolkit FTBFS on 32-bit big-endian hppa platform

Source: oath-toolkit Version: 2.6.11 Tags: ftbfs, patch X-Debbugs-Cc: del...@debian.org User: debian-...@lists.debian.org Usertags: time-t As can be seen here: https://buildd.debian.org/status/fetch.php?pkg=oath-toolkit=hppa=2.6.11-2.1=1713624192=0 oath-toolkit testsuite fails on hppa like this:

Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding

Source: libcbor Version: 0.10.2-1.2 Tags: ftbfs X-Debbugs-Cc: del...@debian.org libcbor fails to build from source on the hppa and mips architectures. Reason is, that a testcases which checks the binary representation of NaN fails on those architectures, because they use a different binary

Bug#1069771: libslow5lib FTBFS on big endian architectures

Source: libslow5lib Version: 0.7.0+dfsg-2.1 Tags: ftbfs build log reports: [slow5_open_with::ERROR] Big endian machine detected. slow5lib only supports little endian at this time. Please open a github issue stating your machine spec . Full log

Bug#1067197: xserver-xorg-video-nouveau ftbfs

On 3/19/24 23:46, Helge Deller wrote: The problem is that the hppa and powerpc buildds have an outdated version of dpkg-dev installed, although a newer one has been available for over a week. Oh... yes. Luckily I just updated the chroots a few hours ago. Giving-back packet again to try. You

Bug#1067197: xserver-xorg-video-nouveau ftbfs

The problem is that the hppa and powerpc buildds have an outdated version of dpkg-dev installed, although a newer one has been available for over a week. Oh... yes. Luckily I just updated the chroots a few hours ago. Giving-back packet again to try. Thanks! Helge

Bug#1067197: xserver-xorg-video-nouveau ftbfs

Source: xserver-xorg-video-nouveau Version: 1:1.0.17-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: del...@debian.org Failure can be seen on hppa architecture, but I assume it will show up on armel too:

Bug#1067026: graphviz patch for ports architectures..

On 3/19/24 16:35, Helge Deller wrote: + librsvg2-dev [!alpha !hppa !hurd-amd64 !hurd-i386 ia64 !m68k !sh4], Argh... the line above is missing a "!" in front of ia64. And, debian/libgvc6-plugins-gtk.install lists the lubrsvg shared object which would need to be removed from tha

Bug#1067026: graphviz patch for ports architectures..

It seems this change in debian/control is sufficient? --- debian/control 2024-03-19 15:27:01.567243176 + +++ debian/control.org 2024-03-19 15:23:54.838549231 + @@ -37,7 +37,7 @@ libgtk2.0-dev, libgts-dev, libann-dev, - librsvg2-dev, + librsvg2-dev [!alpha !hppa !hurd-amd64

Bug#1065973: kmod: FTBFS due to time64 transition

The patch below builds for me on the hppa platform. Testcases needs verifying on physical hardware though. Helge diff -up ./testsuite/path.c.org ./testsuite/path.c --- ./testsuite/path.c.org 2024-03-13 07:01:04.610222544 + +++ ./testsuite/path.c 2024-03-13 07:11:16.630339502 + @@

Bug#1059676: kernel FTBFS on hppa

This kernel bug is now fixed, since binutils will now support hppa64 binaries as well. See bz #1059674

Bug#1059676: kernel FTBFS on hppa

Package: linux Tags: hppa, ftbfs Version: 6.6.8-1 Depends: 1059674 Kernel FTBFS on hppa. Problem is, that on hppa the 32-bit strip and 32-bit objdump binaries can't process hppa 64-bit objects. Log shows, e.g.: make[3]: Leaving directory '/home/deller/build/linux/linux-6.6.8' dh_strip

Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes

On 11/21/23 23:38, Zebediah Beck wrote: Excellent, please explain the bug in question in further detail as this is interesting There is not much to say about it. The main challenge on parisc is, that it's the only platform left where the stack grows upwards. So, the kernel has special

Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes

I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU 8.0.2. Kernel: Linux 6.3.0-2-parisc parisc PA-RISC Linux kernels starting from 6.2 up until 6.7-rc1 have been lightly tested because I was mostly busy with enabling 64-bit hppa CPU support in qemu. On Debian we currently

Bug#1050408: pycurl FTBFS on hppa due to missing shebang

Package: pycurl Tags: ftbfs, hppa Version: 7.45.2-3 pycurl fails to build from source on qemu-based buildds. The problem is, that the "./tests/ext/test-suite.sh" file is not a script, although it's marked executable. It's missing a shebang at the beginning, e.g. "#!/bin/sh", as in this patch:

Bug#1050178: ocaml-extunix FTBFS on hppa

Package: ocaml-extunix Tags: ftbfs, hppa Version: 0.4.1-3 This package fails like this: Failure: tests:7:resource:0:setrlimit:1:RLIMIT_STACK soft limit expected: infinity but got: 8388608 see: https://buildd.debian.org/status/fetch.php?pkg=ocaml-extunix=hppa=0.4.1-3=1692284259=0 The problem

Bug#1050123: libssh FTBFS on hppa

Package: libssh Tags: ftbfs, hppa Version: 0.10.5-3 The package sometimes fails to build from source, because it runs into the "ctest timeout", e.g.: https://buildd.debian.org/status/fetch.php?pkg=libssh=hppa=0.10.5-3=1692499006=0 The following tests FAILED: 7 - torture_misc (Timeout)

Bug#1042583: vnlog ftbfs on qemu-user buildds

Package: vnlog Tags: patch, ftbfs, hppa Version: 1.36-2 The file test/test_python3_parser.sh misses a trailing shebang which makes the package fail to build on qemu based buildds. Please add: #!/bin/bash to the top of test/test_python3_parser.sh to fix it. (for example the test/test_c_api.sh

Bug#1030587: strace FTBFS on hppa

Hello Andreas, sorry, I somehow missed your follow-up on this bug, but just stumbled over it again now... On Sat, 11 Feb 2023 18:27:25 +0100 Andreas Henriksson wrote: Could you please have a look at https://salsa.debian.org/debian/strace/-/commits/wip/hppa and see if it builds (and if you

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

On 7/17/23 22:21, Michael Tokarev wrote: 17.07.2023 22:58, Helge Deller wrote: This patch seems to work. Tested with qemu-arm and qemu-amd64. Wow! diff --git a/linux-user/elfload.c b/linux-user/elfload.c index a26200d9f3..b583018591 100644 --- a/linux-user/elfload.c +++ b/linux-user

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

This patch seems to work. Tested with qemu-arm and qemu-amd64. diff --git a/linux-user/elfload.c b/linux-user/elfload.c index a26200d9f3..b583018591 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -3615,6 +3631,13 @@ int load_elf_binary(struct linux_binprm *bprm, struct

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Without the patch this is the memory layout: startend size prot 0001-00011000 1000 r-x 00011000-0002 f000 --- 0002-00021000 1000 rw- 4000-40001000 1000 --- 40001000-40801000 0080 rwx 40801000-40802000 1000 r-x The difference between armhf and

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

This patch (hack) fixes the crash on armhf. diff --git a/linux-user/elfload.c b/linux-user/elfload.c index a26200d9f3..2efa981061 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -3674,7 +3685,7 @@ int load_elf_binary(struct linux_binprm *bprm, struct image_info *info) * The

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Hello, Could someone please try the 3 qemu patches (and one revert) which I pushed to my "upx-fix" branch with this binary? It's based on top of qemu git master: https://github.com/hdeller/qemu-hppa/commits/upx-fix You can pull from: git pull https://github.com/hdeller/qemu-hppa.git upx-fix

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

On 7/14/23 01:56, Thorsten Glaser wrote: Dixi quod… My guess here is that it’s, as usual, the fault of qemu-user, Strong evidence for that: doesn’t look like it even executes one bit of klibc code: $ qemu-arm-static -d cpu ./fstype --help qemu: uncaught target signal 11 (Segmentation fault)

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

Can you check if this patch fixes the problem: https://patchew.org/QEMU/mvmpm55qnno@suse.de/ (linux-user: make sure brk(0) returns a page-aligned value, from Andreas Schwab) Ursprüngliche Nachricht Von: Thorsten Glaser Datum: 14.07.23 00:48 (GMT+01:00) An:

Bug#1029614: (no subject)

The blueprint-compiler is actually crashing on all BIG-ENDIAN platforms (s390x, hppa, m68k, powerpc, ppc64, sparc64), not just on s390x

Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat

Just wondering / guessing: Are the ARM machines on ci.debian.net (ci-worker-arm??-??) physical machines, or are they running on qemu-user VMs? If they run qemu, this bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024653 might be similiar. If so, then qemu probably needs fixing

Bug#1036459: pre-unblock: palo/2.23

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 src:palo This pre-unblock request is to get a decision from the Bookworm release team if I'm allowed to upload the palo 2.23 bug-fix version. - palo is a bootloader

Bug#1034083: apt-cacher-ng cron job exits sometimes with error code 134

Package: apt-cacher-ng Version: 3.7.4-1 Since quite many months I see occasionally (~ once a month) this cron job warning: /etc/cron.daily/apt-cacher-ng: Aborted run-parts: /etc/cron.daily/apt-cacher-ng exited with return code 134 I originally assumed it was because of missing

Bug#990560: Some questions regarding Inodes

Hello Bernhard, On 3/29/23 17:17, Bernhard wrote: The limiting factor is how many inodes a filesystem allows. This depends on the "inode size" and can be specified when formatting the filessystem. 32-bit applications can only address 2^32-1 inodes, which is ~ 4 million. < 2^32 is ~4

Bug#990560: Thanks for investigations

On 3/27/23 07:13, Bernhard wrote: My very first test with i386 was in a Acer Netbook with 64GB SSD. This failure was not shown. If i understand it right, this failure don't happen in case, of small partition <1TB: 2^31*512byte=1TB. Can you please confirm? But this failure happens at my Banana

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

Hi Faidon, On 3/17/23 13:21, Faidon Liambotis wrote: Friendly bump on this! I'd just like to agree on next steps while we have this in our recent memory :) Ok, let's summarize. Because we don't know in advance how libev it built (with or without 64-bit offsets), we: - can't enable

Bug#1032958: rsyslog: Enable Large File Support (LFS)

On 3/14/23 19:20, Michael Biebl wrote: Am 14.03.23 um 19:13 schrieb Helge Deller: On 3/14/23 19:06, Helge Deller wrote: That flag is then used only for one C-file in the subdir contrib/omhiredis. Which flag? I meant the compiler preprocessor defines: The c-files should be compiled

Bug#1032958: rsyslog: Enable Large File Support (LFS)

On 3/14/23 19:06, Helge Deller wrote: That flag is then used only for one C-file in the subdir contrib/omhiredis. Which flag? I meant the compiler preprocessor defines: The c-files should be compiled with: -D_FILE_OFFSET_BITS=64  -D_LARGEFILE_SOURCE Example: In plugins/impstats/impstats.c

Bug#1032958: rsyslog: Enable Large File Support (LFS)

That flag is then used only for one C-file in the subdir contrib/omhiredis. Which flag? I meant the compiler preprocessor defines: The c-files should be compiled with: -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE

Bug#1032958: rsyslog: Enable Large File Support (LFS)

On 3/14/23 18:56, Helge Deller wrote: On 3/14/23 18:52, Michael Biebl wrote: See also https://github.com/rsyslog/rsyslog/commit/71ffb32ab8a1847f746a298ad20f7dd8b40570a0 I think this patch is wrong. It drops the "define _FILE_OFFSET_BITS 64" from the rsyslog.h file, and instead near

Bug#1032958: rsyslog: Enable Large File Support (LFS)

On 3/14/23 18:52, Michael Biebl wrote: See also https://github.com/rsyslog/rsyslog/commit/71ffb32ab8a1847f746a298ad20f7dd8b40570a0 I think this patch is wrong. It drops the "define _FILE_OFFSET_BITS 64" from the rsyslog.h file, and instead nearly nowhere adds that flag. Helge

Bug#1032958: rsyslog: Enable Large File Support (LFS)

On 3/14/23 18:47, Michael Biebl wrote: Control: tags -1 + moreinfo The upstream build system already checks for large file system support via the AC_SYS_LARGEFILE autoconf macro and enables it by default: So for example on i386 I get

Bug#1032958: rsyslog: Enable Large File Support (LFS)

Package: rsyslog Tags: ftbfs, hppa, patch Version: 8.2302.0-1 rsyslog randomly fails to build from source on the hppa platform due to some testcases randomly failing. I've tracked down various issues, partly related to how the debian buildd server is setup on hppa, but the main problem is, that

Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa

On 3/12/23 22:40, Lisandro Damián Nicanor Pérez Meyer wrote: I'm afraid we had similar problems before. Let's better wait for someone to properly test that things are working. Just out of couriosity: Do you know if someone tested on mips, mips64el, mipsel, powerpc, ppc64, riscv64 or s390x ?

Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa

Hello Dmitry, On 3/11/23 19:19, Dmitry Shachnev wrote: On Mon, Feb 06, 2023 at 10:12:37PM +0100, Helge Deller wrote: Package: qtquickcontrols-opensource-src Tags: ftbfs, hppa Version: 5.15.8-2 qtquickcontrols-opensource-src FTBFS on hppa with this testcase failure: FAIL! : qtquickcontrols

Bug#1032187: fuse3 FTBFS on hppa

Package: fuse3 Tags: ftbfs, hppa, patch Version: 3.14.0-2 fuse3 fails to build from source on the big-endian hppa platform because the testcase fails: https://buildd.debian.org/status/fetch.php?pkg=fuse3=hppa=3.14.0-2=1677387190=0 Please add hppa to the other big-endian platforms for which the

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

Hello Faidon, On 2/27/23 18:36, Faidon Liambotis wrote: 2) the stat() calls, via ev_stat_init etc., in the mon and extfile plugins. ... However, (2) is not self-contained, with stat structures crossing an ABI boundary (libev's). Hence why the test suite (legitimately) fails when building with

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

Hello Faidon, On 2/20/23 09:38, Faidon Liambotis wrote: On Sat, Feb 11, 2023 at 08:43:07PM +0100, Helge Deller wrote: Actually, most packages already enable LFS by default (e.g by checking and using the _FILE_OFFSET_BITS=64 possibility, or by using future=+lfs), so there are not so many

Bug#1006529: mariadb fails on hppa

Hi Otto, Just FYI: mariadb fails on the hppa architecture, because there is a kernel bug (on parisc and probably other architectures) in the io_uring syscall. This is worked on upstream, e.g. this mail thread: https://lore.kernel.org/io-uring/507c7873--dbcb-c512-4659af486...@bell.net/T/#t We

Bug#1031125: ell FTBFS on hppa b/c of missing LFS suppport

Package: ell Tags: ftbfs, hppa, patch Version: 0.56-3 ell sometimes fails to build from source on hppa: https://buildd.debian.org/status/fetch.php?pkg=ell=hppa=0.56-3=1676182857=0 Reason is, that ell is not compiled with Large File Support (LFS). To solve this issue, please change in

Bug#1031106: partclone FTBFS on hppa due to missing shebang

Package: partclone Tags: ftbfs, hppa Version: 0.3.23+repack-1 partclone fails to build from source: https://buildd.debian.org/status/fetch.php?pkg=partclone=hppa=0.3.23%2Brepack-1=1676139304=0 Log is: parallel-tests: installing './test-driver' debian/rules override_dh_auto_configure make[1]:

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

Does this mean that a bug needs to be filed and d/rules to be adjusted for every package that uses readdir()? That's a pretty massive MBF and I don't think it would scale very well :) Yes, correct. Actually, most packages already enable LFS by default (e.g by checking and using the

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

On 2/11/23 19:21, Faidon Liambotis wrote: On Sat, Feb 11, 2023 at 06:53:16PM +0100, Helge Deller wrote: I'm not very familiar with the LFS work; could you help me understand a bit better the need for adding this flag? Is this an MBF or something specific to gdnsd? Why would this need

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

Hi Faidon, On 2/11/23 18:15, Faidon Liambotis wrote: On Fri, Feb 10, 2023 at 08:48:37AM +0100, Helge Deller wrote: On 32-bit platforms this package may fail to build when running on large discs. One example is visible in log from the hppa platform: https://buildd.debian.org/status/fetch.php

Bug#1031034: apr: Missing LFS support triggers FTBFS on other packages

Package: apr Tags: ftbfs, hppa, lfs Version: 1.7.2-2 On 32-bit platforms it's necessary to compile programs and libraries with Large File Support (LFS) in order to allow them to function correctly on filesystems with > 2GB or 4GB size. This can be solved by adding "-D_LARGEFILE_SOURCE

Bug#990560: subversion: Error message "Value too large for defined data type"

The "devscripts" package FTBFS too because subversion isn't compiled with LFS support: https://buildd.debian.org/status/fetch.php?pkg=devscripts=hppa=2.23.1=1676035013=0 The log shows: svnadmin: E72: Repository creation failed svnadmin: E72: Could not create top-level directory svnadmin:

Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants

On 2/10/23 16:16, Thorsten Glaser wrote: Helge Deller dixit: No, it needs to have been in the release. Please help me to understand the dependencies you mention. That patch is targetted for dietlibc in unstable. Is dietlibc/unstable shipped backwards into oldstable (in which No, but Debian

Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants

On 2/10/23 15:57, Thorsten Glaser wrote: Helge Deller dixit: You know that new kernel features have to be in oldstable before they can be depended on, right? The kernel patch was backported and is in upstream Linux kernel version 6.2, alternatively stable kernels from versions 6.1.6, 5.15.87

Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants

On 2/10/23 15:27, Thorsten Glaser wrote: Helge Deller dixit: This upstream patch has been downported to all stable kernel trees as well. Please apply for next upload. You know that new kernel features have to be in oldstable before they can be depended on, right? The kernel patch

Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants

compliled programs to use the standard MADV_* constants. Please apply for next upload. Signed-off-by: Helge Deller --- diff -up ./include/sys/mman.h.org ./include/sys/mman.h --- ./include/sys/mman.h.org2023-02-10 09:38:51.324985574 + +++ ./include/sys/mman.h2023-02-10 09:39:02.32509

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

Package: gdnsd Tags: ftbfs, hppa, lfs Version: 3.5.2-1 On 32-bit platforms this package may fail to build when running on large discs. One example is visible in log from the hppa platform: https://buildd.debian.org/status/fetch.php?pkg=gdnsd=hppa=3.8.0-1=1676009104=0 which reports error:

Bug#1022023: xrdp timeout

Seems upstream is discuing to increase the time: https://github.com/neutrinolabs/xrdp/pull/2214 and: https://github.com/neutrinolabs/xrdp/issues/2213

Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa

Package: qtquickcontrols-opensource-src Tags: ftbfs, hppa Version: 5.15.8-2 qtquickcontrols-opensource-src FTBFS on hppa with this testcase failure: FAIL! : qtquickcontrols::Tests_TreeView::test_pressAndHold() Compared values are not the same Actual (): 0 Expected (): 1 Loc:

Bug#1030587: strace FTBFS on hppa

Package: strace Tags: patch, ftbfs, hppa Version: 6.1-0.1 strace FTBFS on hppa. I just sent a few patches upstream to fix this, which have been accepted: https://lists.strace.io/pipermail/strace-devel/2023-January/011135.html can you please include them, or simply update to latest git head?

Bug#1030553: tup FTBFS on hppa

Package: tup Tags: patch, ftbfs, hppa Version: 0.7.11-3 The attached patch fixes the tup build on hppa. In addition it would make sense that tup is compiled with the "future+lfs" flags to support large files on large discs on 32-bit builds. It currently builds with -D_FILE_OFFSET_BITS=64 but

Bug#1030546: qt6-base FTBFS on hppa

relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC Signed-off-by: Helge Deller --- diff -up ./cmake/FindWrapZSTD.cmake.org ./cmake/FindWrapZSTD.cmake --- ./cmake/FindWrapZSTD.cmake.org 2023-02-04 17:50:29.119361823 + +++ ./cmake/FindWrapZSTD.cmake 20

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

On Tue, 31 Jan 2023 18:27:27 +0100 Andreas Henriksson wrote: > > export DEB_BUILD_MAINT_OPTIONS = future=+lfs > export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument Might be useful to add a comment here saying: # Workaround gnulib issue: The below three lines can be

Bug#1030159: dpkg: Please add future:+time64 option for y2038 support on 32-bit platforms)

Just for the record: The "tar" package is one example needs LFS- and 64-bit time support to sucessfully run the built-in testcase and as such would be a good user for a new "future:+time64" flag. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204#42 Helge

Bug#1030159: dpkg: Please add future:+time64 option for y2038 support on 32-bit platforms

Package: dpkg Severity: wishlist Tags: lfs, patch, hppa Version: 1.21.17 Binaries on most (all?) 32-bit platforms will have the y2038 problem, if they haven't been compiled with the "_TIME_BITS=64" define. This bug report is about the request to add a dpkg option similar to the "future=+lfs"

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

Hi David & Andreas, On 1/28/23 12:10, David Prévot wrote: 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 Unfortunately, even if

Bug#1028320: Enable lfs (large file support) by default on hppa

Hi Guillem, On 1/24/23 11:55, Guillem Jover wrote: On Mon, 2023-01-09 at 15:20:41 +0100, Helge Deller wrote: Package: dpkg Severity: important Tags: lfs, hppa Version: 1.21.17 Tags: hppa, patch, ftbfs This is a follow-up for #1020335 regarding "enabling LFS by default on hppa arch&qu

Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB

Hi Helmut, On 1/24/23 06:27, Helmut Grohne wrote: On Mon, Jan 23, 2023 at 10:48:27PM +0100, Helge Deller wrote: --- ./init.org 2023-01-23 21:40:33.079738389 + +++ ./init 2023-01-23 21:40:45.983861851 + @@ -205,6 +205,15 @@ else resume=${RESUME:-} fi +if [ -z "${RU

Bug#1029574: indent shebang bug and misses LFS support

Hi Santiago, On 1/24/23 20:07, Santiago Vila wrote: El 24/1/23 a las 18:48, Helge Deller escribió: Package:  indent Version: 2.2.12 Tags: hppa, patch, lfs, FTBFS The indent package has a bug in the script "regression/TEST" which starts with "#/bin/sh" instead of a correct

Bug#1029574: indent shebang bug and misses LFS support

Package: indent Version: 2.2.12 Tags: hppa, patch, lfs, FTBFS The indent package has a bug in the script "regression/TEST" which starts with "#/bin/sh" instead of a correct shebang which would be "#!/bin/sh". This leads to a FTBFS on the hppa architecture when running virtualized in qemu-user.

Bug#999915: (no subject)

I think the patch I sent in #1027915 should fix this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027915#24

Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB

). Please apply to the next initramfs-tools update. Signed-off-by: Helge Deller diff -up ./init.org ./init --- ./init.org 2023-01-23 21:40:33.079738389 + +++ ./init 2023-01-23 21:40:45.983861851 + @@ -205,6 +205,15 @@ else resume=${RESUME:-} fi +if [ -z "${RUNSIZE}" ] || [[

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

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. Helge

Bug#1028304: howardhinnant-date FTBFS on 32-bit arches (may fail in testcase)

Hi Andrea, On 1/10/23 23:54, Andrea Pappacoda wrote: On Mon, 9 Jan 2023 12:35:06 +0100 Helge Deller wrote: > Package:  howardhinnant-date > Version: 3.0.1+ds > Tags: hppa, patch, ftbfs > Severity: important > > The testcases may fail on 32-bit arches at runtime if

Bug#1017504: Enabling large file support in doxygen

Hi Paolo, On 1/11/23 10:52, Paolo Greppi wrote: Hi! sorry for the long delay, at last I'm looking at incorporating your patch. It's now WIP here: https://salsa.debian.org/debian/doxygen Thanks! Before I upload it to unstable, I was wandering: 1. what would be the easiest way to turn this

Bug#1028320: Enable lfs (large file support) by default on hppa

Package: dpkg Severity: important Tags: lfs, hppa Version: 1.21.17 Tags: hppa, patch, ftbfs This is a follow-up for #1020335 regarding "enabling LFS by default on hppa arch". It's unfeasable to try to fix every package which fails on hppa due to missing large file support. The problem is, that

Bug#1028304: howardhinnant-date FTBFS on 32-bit arches (may fail in testcase)

Package: howardhinnant-date Version: 3.0.1+ds Tags: hppa, patch, ftbfs Severity: important The testcases may fail on 32-bit arches at runtime if those are running on huge discs, e.g. see https://buildd.debian.org/status/fetch.php?pkg=howardhinnant-date=hppa=3.0.1%2Bds-1=1664074656=0 This can

Bug#1026973: rrdtool FTBFS on 32-bit arches (may fail in testcase)

On 1/5/23 19:15, Diederik de Haas wrote: On Sun, 25 Dec 2022 12:49:27 +0100 Helge Deller wrote: Package: rrdtool Version: 1.7.2-4 Tags: hppa, patch, ftbfs Severity: important The command "rrdtool list /some/dir/" fails on 32-bit arches at runtime if those are running on huge discs

Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB

Hi Helmut, On 1/4/23 14:26, Helmut Grohne wrote: On Wed, Jan 04, 2023 at 02:08:00PM +0100, Helge Deller wrote: My suggestion: Please check that the /run mountpoint is mounted with at least 20MB, independend of the installed RAM memory in the machine... Your suggestion makes sense

Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB

Package: systemd Version: 252.4-1 Severity: important Systemd mounts the /run tmpfs filesystem at bootup with a given/calculated size (I assume ~ 10% of free memory?). The problem is, that this size needs to be at least 16MB (probaly better 20MB), because otherwise systemd refuses to reload

Bug#1026973: rrdtool FTBFS on 32-bit arches (may fail in testcase)

Package: rrdtool Version: 1.7.2-4 Tags: hppa, patch, ftbfs Severity: important The command "rrdtool list /some/dir/" fails on 32-bit arches at runtime if those are running on huge discs, e.g. see failing "list1" testcase on hppa:

Bug#1026755: aws-crt-python FTBFS and wrongly checks hard for MADV_WIPEONFORK==18

Package: aws-crt-python Version: 0.15.3+dfsg-1 Tags: hppa, patch, ftbfs Package fails to build like this: cd /<>/build/temp.linux-hppa-cpython-311/deps/s2n && /usr/bin/cc -D_POSIX_C_SOURCE=200809L -I/<>/crt/s2n -I/<>/crt/s2n/api -g -O2 -ffile-prefix-map=/<>=. -Wformat -Werror=format-security

Bug#990560: Error message "Value too large for defined data type"

On 12/16/22 23:19, James McCoy wrote: However, I'm not sure changing subversion's build alone will address the problem. APR may need a similar change. I'll look into apr as well. Note that #1026235 is relevant as well - it changed the behaviour of some calls, which is why this problem pops up

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

Package: tar Version: 1.34+dfsg-1.1 Tags: hppa, patch, ftbfs, lfs I wondered why tar now suddenly fails to build on those platforms. Testcase # 151 does create files whith access dates which are outside of the reach for 32-bit plaforms with a default of 32-bit timestamps in glibc. This does

Bug#1026171: Please enable large file support for sqllite3

Package: sqlite3 Version: 3.40.0 Tags: hppa, patch, ftbfs Please enable large file support (LFS) when building sqllite3. This is necessary for 32-bit applications to be able to run on larger filesystems. For example the "subversion" debian package depends on this feature to successfully run

Bug#1017504: Please build doxygen with large file support

Please urgently install this patch. Since doxygen isn't built with large file support, the doxygen binaries trigger build errors in many other packages which use doxygen. Example: https://buildd.debian.org/status/fetch.php?pkg=wireplumber=hppa=0.4.13-1=1671031175=0 Thanks, Helge

Bug#990560: Error message "Value too large for defined data type"

tag: hppa, lfs, patch This bug usually indicates that a 32-bit application uses functions like readdir() which (by default on a 32bit platform) can only handle 32-bit values for inode numbers. You can overcome that issue by recompiling the code while providing "-D_FILE_OFFSET_BITS=64" on the gcc

Bug#1024653: git: FTBFS on s390x due to test failure, incorrect /proc/cpuinfo parsing

The same bug happens on hppa and sparc architecture as well, as can be seen in those logs: https://buildd.debian.org/status/fetch.php?pkg=git=hppa=1%3A2.39.0-1=1670883297=0 https://buildd.debian.org/status/fetch.php?pkg=git=sparc64=1%3A2.39.0-1=1670887934=0 Isn't there a better way to get the

Bug#1025378: dracut FTBFS

Package: dracut Version: 057+157-4 Tags: hppa, patch, ftbfs I wondered why dracut failed to build on hppa. You can see the various log builds here: https://buildd.debian.org/status/logs.php?pkg=dracut=hppa Interestingly, dracut builds sucessfully on the build servers atlas, panama, sap and

Bug#1021972: webdis: Add small delay in tests

Package: webdis Version: 0.1.9+dfsg-1 Tags: ftbfs, hppa, patch webdis sometimes FTBFS on hppa, because the tests failed like this: Generating config files.. Starting redis-server.. Starting webdis.. Setting up redis/webdis server FAILED. Problem is, that starting webdis may take some time,

Bug#900181: camp fails in camptest-qt test

There is still a problem with powerpc and hppa, see: https://buildd.debian.org/status/package.php?p=camp=sid If you want you can use the hppa porterbox: https://db.debian.org/machines.cgi?host=panama Helge

Bug#1021310: libsdl2: FTBFS on hppa - patch attached

As Dave wrote, it's (partly) a 32-bit big-endian issue. This check in test/testevdev.c #if ULONG_MAX == 0xUL # define SwapLongLE(X) SDL_SwapLE32(X) #else /* assume 64-bit */ # define SwapLongLE(X) SDL_SwapLE64(X) #endif always chooses the #else part, because the file isn't

Bug#1020909: Enable lfs (large file support) in apt-cacher-ng

On 9/29/22 00:15, Eduard Bloch wrote: [*] _LARGEFILE_SOURCE or _FILE_OFFSET_BITS=64 Both of them? I don't think so. _LARGEFILE_SOURCE will export some XYZo functions of the C API, but I don't use them. Ok. apt-cacher-ng has been adding those defines since the early days of its

Bug#1020909: Enable lfs (large file support) in apt-cacher-ng

On 9/28/22 22:12, Helge Deller wrote: The problem here is, that if those flags [*] aren't set, the "struct dirent" will only be able to hold file numbers which are max. 32bits width. "File numbers" is wrong... I meant "Inode number" (of the file). Helge

Bug#1020909: Enable lfs (large file support) in apt-cacher-ng

On 9/28/22 21:52, Eduard Bloch wrote: Hallo, Hallo Eduard, * Helge Deller [Wed, Sep 28 2022, 12:46:53PM]: Package: apt-cacher-ng Severity: 3.7.4-1 Tags: lfs, hppa, patch Please enable large file support. apt-cacher-ng uses readdir() which can fail on 32-bit arches running on large discs

Bug#1020909: Enable lfs (large file support) in apt-cacher-ng

Package: apt-cacher-ng Severity: 3.7.4-1 Tags: lfs, hppa, patch Please enable large file support. apt-cacher-ng uses readdir() which can fail on 32-bit arches running on large discs. Sometimes I see a cron job warning: /etc/cron.daily/apt-cacher-ng: Aborted run-parts:

Bug#1016141: ghc uses a 64-bit assembler instruction on 32-bit hppa platform

I've been able to analyze that further. It seems, that ghc produces/uses this 64-bit hppa assembler instruction although ghc is built for 32-bit: depd,z,*ev dp,63,32,r11 How to reproduce/analysis: apt install haskell-devscripts-minimal ghc:native -> Setting up ghc (9.0.2-3) ...

Bug#1020335: Enable lfs (large file support) by default for building packages

Just one more question:    DEB_BUILD_MAINT_OPTIONS="future=+lfs" With that everyone (on a 32-bit platform) would e.g. get: dpkg-buildflags --get CPPFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 Since many packages just use CFLAGS or CXXFLAGS (but not

Bug#1020335: Enable lfs (large file support) by default for building packages

Hi Guillem, On 9/20/22 12:19, Guillem Jover wrote: On Tue, 2022-09-20 at 12:03:41 +0200, Helge Deller wrote: Package: dpkg Severity: wishlist Tags: lfs, hppa I've seen quite some lfs errors (on 32-bit platform) with packages in the last weeks. Isn't it time now (year 2022), to take lfs down

  1   2   3   4   5   >