Bug#689273: grub-ieee1275: grub-install chooses wrong boot-device parameter for openfirmware nvram
User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 Hello Daniel! Can you retest with the latest ISO images [1] on powerpc or ppc64 and see if this problem still persists? We have switched both powerpc and ppc64 over to GRUB and so far, most users reported that GRUB works without problems except for Apple systems with very old versions of OpenFirmware. If it works, please consider closing this bug report. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/2020-04-19/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#737999: grub-ieee1275: Fails to boot linux on my PowerPC-based Mac Mini, complains about "incompatible license"
User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 Hello Nicolas! Can you retest with the latest ISO image [1] on powerpc and see if this problem still persists? We have switched both powerpc and ppc64 over to GRUB and so far, most users reported that GRUB works without problems except for Apple systems with very old versions of OpenFirmware. Adrian > [1] > https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-powerpc-NETINST-1.iso -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#958451: ausweisapp2: gets stuck when using service "Arbeitnehmer online"
Hi Juergen! On 4/24/20 7:48 PM, Jürgen Bausa wrote: > ok, I understand. I will try to find out which version of the QML platform > module is offered by Buster. And then try to change the requirement in > Ausweisapp2. I'm not sure whether overriding the version requirement will fix the problem, normally the minimum version for a dependency is set for a reason. The software might behave erratically. > However, I am wondering why the second bug report on this problem > disappeared. > I think it would be good to keep at least one of this two bug reports (or > merge them) with an explanation. This would help all people who try to use > the > backport. I merged both bug reports into one because these are reporting the same issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#958451: ausweisapp2: gets stuck when using service "Arbeitnehmer online"
Control: forcemerge -1 958190 Control: found -1 1.20.0-2~bpo10+1 Control: notfound -1 1.20.0-2 Control: retitle -1 ausweisapp2: Fails to start because QML platform module is too old On 4/24/20 8:50 AM, Jürgen Bausa wrote: > Maybe its a problem with the version? Ausweisapp2 asks for 1.1. But how do I > know, which version is provided by the debian package? qt version is 5.12.5 > but I thinks that doesnt help. I assume that the QML platform module on stable is simply too old and I'm afraid there is not much we can do about this as updating the platform module would involve updating all of Qt. You could ask the Qt maintainers if they have an idea how to address this but I don't think there is. The only possible solution I see is when upstream reduces their version requirement from 1.1 to 1.0. Please note, while I gladly try to support the package on stable, backports packages are not officially supported, so we can't take the full extent of measures to address this problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#958646: ffmpegfs: FTBFS caused by passing custom target flags in CFLAGS
Package: ffmpegfs Version: 1.98-1 Severity: serious Tags: upstream Justification: ftbfs User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 ppc64el Hello! ffmpegfs fails to build from source on multiple architectures [1], including release architectures because it passes target flags via -march in CFLAGS which is not allowed: g++: error: unrecognized command line option ‘-march=native’; did you mean ‘-mcpu=native’? make[3]: *** [Makefile:559: ffmpegfs.o] Error 1 make[3]: *** Waiting for unfinished jobs g++: error: unrecognized command line option ‘-march=native’; did you mean ‘-mcpu=native’? make[3]: *** [Makefile:559: cache.o] Error 1 g++: error: unrecognized command line option ‘-march=native’; did you mean ‘-mcpu=native’? g++: error: unrecognized command line option ‘-march=native’; did you mean ‘-mcpu=native’? For one, as you can see, "-march" is not supported on every architecture, and, secondly, you are not allowed to build a package with "-march=native" as this will adjust the baseline to the one on the buildd hardware instead of using the baseline that is determined by the gcc specs set by dpkg which is not allowed according to Debian Policy. Adrian > [1] https://buildd.debian.org/status/package.php?p=ffmpegfs=unstable -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#958556: gmt: Platform support for RISC-V and SuperH
Source: gmt Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 sh4 Hi! The attached patch adds build support for riscv64 and sh4. Please include it in the next upload. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Description: Add build support for riscv64 and sh4 Defines UC_IP() on riscv64 and sh4 so that gmt can be built on these targets. . Author: John Paul Adrian --- Forwarded: https://github.com/GenericMappingTools/gmt/pull/3155 Last-Update: 2020-04-23 Index: gmt-6.0.0+dfsg/src/common_sighandler.c === --- gmt-6.0.0+dfsg.orig/src/common_sighandler.c +++ gmt-6.0.0+dfsg/src/common_sighandler.c @@ -86,8 +86,12 @@ void backtrace_symbols_fd(void *const *b # define UC_IP(uc) ((void *) (uc)->uc_mcontext.sc_iaoq[0]) # elif defined(__m68k__) # define UC_IP(uc) ((void *) (uc)->uc_mcontext.gregs[R_PC]) +# elif defined(__riscv) +# define UC_IP(uc) ((void *) (uc)->uc_mcontext.__gregs[REG_PC]) # elif defined(__s390__) # define UC_IP(uc) ((void *) (uc)->uc_mcontext.psw.addr) +# elif defined( __sh4__) +# define UC_IP(uc) ((void *) (uc)->uc_mcontext.pc) # elif defined(__sparc__) # if defined (__arch64__) # define UC_IP(uc) ((void *) (uc)->uc_mcontext.mc_gregs[MC_PC])
Bug#944017: libsoxr: autopkgtest regression: segmentation fault
Hi Bernhard! On 12/12/19 2:42 AM, Bernhard Übelacker wrote: > In the end it runs: > > dd if=/dev/urandom count=1000 | /tmp/tmp.bQI47Dtfhv/4-split-channels 7 > 6 2 2 3 > (...) > Thread 1 received signal SIGTRAP, Trace/breakpoint trap. > 0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, > src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67 > 67 DO_16; > (gdb) bt > #0 0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, > src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67 > #1 _soxr_interleave_f (data_type=, dest0=0x4c241a0, > src=, n=6735, ch=1, seed=0x4c51500) at ./src/data-io.c:213 > #2 0x0484d60f in soxr_output_1ch (p=p@entry=0x4c513e0, i=0, > dest=dest@entry=0x4c24100, len=, len@entry=6923, > separated=separated@entry=true) at ./src/soxr.c:664 > #3 0x0484d8cc in soxr_process._omp_fn.0 () at ./src/soxr.c:786 > #4 0x04bcaa42 in GOMP_parallel (fn=0x484d830 > , data=0x1fff000800, num_threads=4, flags=0) at > ../../../src/libgomp/parallel.c:171 > #5 0x0484ef78 in soxr_process (p=0x4c513e0, in=0x4c24150, > ilen0=, idone0=0x0, out=0x4c24100, olen=6923, > odone0=0x1fff0008a8) at ./src/soxr.c:781 > #6 0x00109fd8 in main (n=0, arg=0x1fff000b28) at > 4-split-channels.c:142 Thanks. This helps. I can reproduce the issue now. I'm looking into this now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#958522: O: hfsprogs -- mkfs and fsck for HFS and HFS+ file systems
Control: retitle -1 ITA: hfsprogs -- mkfs and fsck for HFS and HFS+ file systems Control: owner -1 ! I will adopt this package to update it to the latest upstream version as HFS support is still needed to support Debian on Apple PowerMac. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#958522: O: hfsprogs -- mkfs and fsck for HFS and HFS+ file systems
Package: wnpp Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 Hello! I'm orphaning the hfsprogs package with the intention to adopt it. The package hasn't been updated for a long time by the current maintainer and has a couple of issues that need resolving. He has also agreed on handing over maintenance [1]. Thanks, Adrian > [1] https://lists.debian.org/debian-powerpc/2020/04/msg00197.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#958451: ausweisapp2: gets stuck when using service "Arbeitnehmer online"
Hi David! On 4/22/20 10:54 AM, David Hebbeker wrote: > I am trying to use the service "Arbeitnehmer online" by Datev: > > 1. Start `AusweisApp2` with no further arguments using CLI > 2. Visit with Firefox > https://www.datev.de/ano/nutzungsbedingungen.html > 3. Accept terms on website refering to > https://secure6.datev.de/zrrgnpa/register.do > > - browser waits forever for 127.0.0.1 This is something that should be forwarded upstream, as the bug doesn't seem Debian-specific to me. I have CC'ed one of the upstream developers. @Andre: Would it be possible to allow issues in the Github tracker? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#826796: Request for a new: linux-image-powerpc64-4K
Hi Mathieu! On 4/21/20 11:26 AM, Mathieu Malaterre wrote: > Dear Debian-kernel team, > >> Would it be possible to ship an alternate ppc64 kernel build without >> the 64K page option ? > > Could someone please clarify if this is possible/acceptable ? The new > ppc64 kernel would not be the default but could be installed on G5 > machine after installation. Another kernel flavor for powerpc64 is surely possible. It should be called -4k though as Debian does not allow uppercase letters in package names. On sh4, we also have two different flavors, see [1]. I suggest creating a branch in your Salsa home project with the necessary changes and then open a pull request. It should be mostly copy and paste work. Adrian > [1] > https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fconfig%2Fsh4 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#955603: RM: xserver-xorg-input-aiptek -- ROM; unmaintained, obsolete, or both
Hello! > xserver-xorg-video-ast > xserver-xorg-video-geode > xserver-xorg-video-mach64 > xserver-xorg-video-neomagic > xserver-xorg-video-r128 > xserver-xorg-video-savage > xserver-xorg-video-siliconmotion > xserver-xorg-video-sisusb > xserver-xorg-video-tdfx > xserver-xorg-video-trident The r128 driver is actually required for older Apple hardware and there was just a user reporting a missing video driver on his iMac. Would there be any problems if I maintained the driver myself if necessary? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#666707: hfsprogs is not DFSG-Free
Hello! I have done some research and I do not think that the claim that this software is not dfsg-free is correct. First of all, the license claimed in debian/copyright is incorrect. The upstream package that hfsprogs is based on - diskdev_cmds-332.25 [1] - is not covered by the APSL-2.0 but versions 1.0, 1.1 and 1.2 [2, 3, 4]. Secondly, the APSL-1.2 [5] does not fail the dissident test in my opinion as claimed in [6] as the paragraph 2.2 (c), which mandates the public distribution of modifications to the software package, talks about "Deployed Modifications", i.e. public distribution: > (c) You must make Source Code of all Your Deployed Modifications publicly > available under the terms of this License, including the license grants > set forth in Section 3 below, for as long as you Deploy the Covered Code > or twelve (12) months from the date of initial Deployment, whichever > is longer. You should preferably distribute the Source Code of Your > Deployed Modifications electronically (e.g. download from a web site); > and What "Deploy" means, is explained in 1.4: > 1.4 "Deploy" means to use, sublicense or distribute Covered Code other than > for Your internal research and development (R) and/or Personal Use, > and includes without limitation, any and all internal use or distribution > of Covered Code within Your business or organization except for R use > and/or Personal Use, as well as direct or indirect sublicensing or > distribution > of Covered Code by You to any third party in any form or manner. Thus, the license does not fail the dissident test as explained in [7] as the requirement for public distribution of modifications explicitly excludes personal use and/or use in research and development. I do not see how the APSL-1.2 deviates from the GPL-2 here which also requires the distribution of modifications outside personal use [8]: > 3. You may copy and distribute the Program (or a work based on it, under > Section > 2) in object code or executable form under the terms of Sections 1 and 2 > above > provided that you also do one of the following: > > a) Accompany it with the complete corresponding machine-readable source > code, >which must be distributed under the terms of Sections 1 and 2 above on > a >medium customarily used for software interchange; or, > b) Accompany it with a written offer, valid for at least three years, to > give >any third party, for a charge no more than your cost of physically > performing >source distribution, a complete machine-readable copy of the > corresponding >source code, to be distributed under the terms of Sections 1 and 2 > above on >a medium customarily used for software interchange; or, > c) Accompany it with the information you received as to the offer to > distribute >corresponding source code. (This alternative is allowed only for > noncommercial >distribution and only if you received the program in object code or > executable >form with such an offer, in accord with Subsection b above.) The GPL-2 is even stricter as it mandates three years of availability of modifications in 3. b) while the APSL-1.2 requires only 12 months. Adrian > [1] https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-332.25/ > [2] > https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-332.25/newfs_hfs.tproj/newfs_hfs.c.auto.html > [3] > https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-332.25/fsck_hfs.tproj/fsck_hfs.c.auto.html > [4] > https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-332.25/mount_hfs.tproj/mount_hfs.c.auto.html > [5] https://opensource.apple.com/source/hfs/hfs-522.0.9/APPLE_LICENSE > [6] https://lists.debian.org/debian-legal/2001/09/msg00103.html > [7] https://wiki.debian.org/DissidentTest > [8] https://www.gnu.org/licenses/old-licenses/gpl-2.0.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#882076: Invalid OpenBOOT path for a device
Control: tags -1 +patch
Attaching a patch squashing my three commits to address the issue
from my fork on Github in the mac-support tree [1].
Adrian
> [1] https://github.com/glaubitz/powerpc-utils/tree/mac-support
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From b5e6f5151a1720f0443af2dea5d641fe966998c6 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Fri, 17 Apr 2020 15:23:33 +0200
Subject: [PATCH] ofpathname: Add support for Macintosh OF paths
---
scripts/ofpathname | 54 +++---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/scripts/ofpathname b/scripts/ofpathname
index c37c6bd..7011ca5 100755
--- a/scripts/ofpathname
+++ b/scripts/ofpathname
@@ -37,6 +37,8 @@ PSERIES_PLATFORM=$(dirname $0)/pseries_platform
PLATFORM=$(sed /proc/cpuinfo -ne "s/^machine\t*: \(.*\)/\1/p")
case $PLATFORM in
EFIKA5K2\ *) PLATFORM=efika ;;
+PowerBook*) PLATFORM=mac ;;
+PowerMac*) PLATFORM=mac ;;
esac
# Usage statemnet
@@ -519,6 +521,13 @@ l2of_ide()
if [[ -z $link ]]; then
err $ERR_NO_SYSFS_DEVINFO
fi
+
+# partition number: N in sd*N
+local devpart="${DEVICE##*[a-z]}"
+if [[ $devpart = $DEVICE ]]; then
+devpart='' # no partition number
+fi
+
cd $link
# get the device number
@@ -547,7 +556,11 @@ l2of_ide()
devno=0,0
fi
-OF_PATH=$OF_PATH/disk@$devno
+if [ "$PLATFORM" = "mac" ] ; then
+OF_PATH=$OF_PATH/@$devno
+else
+OF_PATH=$OF_PATH/disk@$devno
+fi
}
#
@@ -584,6 +597,13 @@ l2of_vd()
if [[ -z $OF_PATH ]]; then
err $ERR_NO_OFPATH
fi
+
+# No partition specified.
+if [[ -z $devpart ]]; then
+return
+fi
+
+OF_PATH="${OF_PATH}:${devpart}"
}
#
@@ -786,6 +806,12 @@ l2of_scsi()
err $ERR_NOT_CONFIG
fi
+# partition number: N in sd*N
+local devpart="${DEVICE##*[a-z]}"
+if [[ $devpart = $DEVICE ]]; then
+devpart='' # no partition number
+fi
+
# follow the 'device' link
local link=`get_link "device"`
if [[ -z $link ]]; then
@@ -804,6 +830,7 @@ l2of_scsi()
goto_dir $PWD "devspec"
OF_PATH=`$CAT $PWD/devspec`
+SYS_PATH=$PWD
if [[ -z $OF_PATH ]]; then
err $ERR_NO_OFPATH
fi
@@ -922,12 +949,22 @@ l2of_scsi()
fi
fi
else
+
+plug_id=$(ls -dv $SYS_PATH/*/host* 2>/dev/null | grep -n "/host$HOST$")
+[ -z "$plug_id" ] && {
+plug_id=$(ls -dv $SYS_PATH/host* 2>/dev/null | grep -n "/host$HOST$")
+}
+plug_id=$((${plug_id%%:*}-1))
+
# make sure the "scsi" information is on the end of the path
local scsi_name=${OF_PATH##/*/}
scsi_name=${scsi_name%%@*}
-if [[ $scsi_name != "scsi" ]]; then
+if [[ $scsi_name != "scsi" && "$PLATFORM" != "mac" ]]; then
scsi_name="scsi@$BUS"
OF_PATH=$OF_PATH/$scsi_name
+elif [[ $scsi_name != "scsi" && "$PLATFORM" = "mac" && $devtype != "ata" ]]; then
+scsi_name="@$plug_id"
+OF_PATH=$OF_PATH/$scsi_name
fi
local modalias=""
@@ -941,9 +978,20 @@ l2of_scsi()
diskno=`get_scsi_disk_no $device_dir`
OF_PATH=$OF_PATH/disk\@$diskno
else
- OF_PATH=$OF_PATH/sd@$ID,$LUN
+ if [ "$PLATFORM" = "mac" ] ; then
+ OF_PATH=$OF_PATH/@$ID
+ else
+ OF_PATH=$OF_PATH/sd@$ID,$LUN
+ fi
fi
fi
+
+# No partition specified.
+if [[ -z $devpart ]]; then
+return
+fi
+
+OF_PATH="${OF_PATH}:${devpart}"
}
#
--
2.26.0
Bug#956952: O: powerpc-utils
Control: retitle -1 ITA: powerpc-utils Control: owner -1 ! I will adopt this package to update it to the latest upstream version and also add support for most NewWorld PowerBooks and PowerMacs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#956952: O: powerpc-utils
Package: wnpp Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 ppc64el Hello! I'm orphaning the powerpc-utils package with the intention to adopt it. The package hasn't been updated for a long time by the original maintainer and has a couple of issues that need resolving. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#927255: powerpc-utils is uninstallable
Control: severity -1 normal Hi! Lowering the severity as this affects powerpc and ppc64 only [1], so no release architectures. On the other hand, I have uploaded pmac-utils to unreleased for powerpc and ppc64. On the other hand, it looks like that the package seems orphaned, so I will try to adopt it, update it to the latest version and possibly figure out whether pmac-utils is still required or not. Thanks, Adrian > [1] https://sources.debian.org/src/powerpc-utils/1.3.2-1.1/debian/control/#L13 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#956605: texlive-bin: FTBFS on powerpc & sparc64
Hi Hilmar! (Please keep the mailing lists CC'ed, I didn't receive your message as I'm not subscribed to the bug report) > May first attempt was wrong, the d/rules files needs to be fixed. > > Still tries to do a "make -j32". > > make[1]: Leaving directory '/<>' >dh_auto_build -a -O--builddirectory=Work > cd Work && make -j32 It didn't work because you did not filter the list you are comparing to: NO_MASSIVE_PARALLEL_BUILD := powerpc ppc64 sparc64 ifeq ($(DEB_HOST_ARCH), $(NO_MASSIVE_PARALLEL_BUILD)) MAKEFLAGS += -j8 endif This will always compare "DEB_HOST_ARCH" against "powerpc", as the Makefile interpreter will just pick the first item from your list. Instead, you need to use filter like this: ifneq (,$(filter $(NO_MASSIVE_PARALLEL_BUILD), $(DEB_HOST_ARCH))) MAKEFLAGS += -j8 endif Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#956605: texlive-bin: FTBFS on powerpc & sparc64
On 4/15/20 6:17 PM, Hilmar Preuße wrote: > I expected something like this, as the -1 package built fine. Hence I > did not really expect an issue, which needed to be addressed by the porters. Well, you put the architecture names in the subject, so it would have been useful to CC us ;). As for the -1 package building fine, it's a race condition. It may fail, but it doesn't have to fail. As you can see, it now built fine on sparc64 since it was picked up by the buildd "nvg5120" which has fewer vCPUs than landau which has 128 vCPUs. >> I recommend forwarding this issue upstream and limiting the parallel jobs >> for texlive-bin to 16 or even 8. >> > We have to perform another upload anyway, so I'll try to change that > parameter and do another upload ASAP. Seems that anybody triggered a > rebuild on sparc, which run on nvg5120 with -j16 and was successful. So > I'll limit to -16 I did that :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#956605: texlive-bin: FTBFS on powerpc & sparc64
Hi Hilmar! Please always CC the arch-specific mailing lists when filing arch-specific bugs. Looking at the issue, it seems that texlive-bin has issues when built with many jobs in parallel. On both powerpc and sparc64, the package was built with "make -j32" [1, 2]. Both kapitsa and landau are systems with many virtual CPUs (both are VMs on POWER and SPARC servers) something that is still unusual on x86_64. I recommend forwarding this issue upstream and limiting the parallel jobs for texlive-bin to 16 or even 8. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=texlive-bin=powerpc=2020.20200327.54578-2=1586764340=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=texlive-bin=sparc64=2020.20200327.54578-2=1586764228=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#956728: openjdk-11: Please enablel buildwatch.sh on sh4
Source: openjdk-11
Version: 11.0.7+9-1
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4
Hello!
I just noticed that sh4 is missing in the list of architectures for which
the buildwatch.sh script is enabled. This explains why the builds on sh4
sometimes time out.
Can you enable the buildwatch.sh script on openjdk-{11,13,14,15} to address
this issue?
This should do it:
--- debian/rules.orig 2020-03-26 08:33:35.0 +0100
+++ debian/rules2020-04-14 20:03:01.302882997 +0200
@@ -993,7 +993,7 @@
stamps/build: stamps/configure
@echo '== $@ =='
-ifneq (,$(filter $(DEB_HOST_ARCH), alpha armel armhf ia64 m68k mips mipsel
mips64 mips64el powerpc powerpcspe riscv64 s390x sparc sparc64))
+ifneq (,$(filter $(DEB_HOST_ARCH), alpha armel armhf ia64 m68k mips mipsel
mips64 mips64el powerpc powerpcspe riscv64 s390x sh4 sparc sparc64))
sh -c 'sh debian/buildwatch.sh $(CURDIR)/$(builddir) &'
endif
if $(EXTRA_BUILD_ENV) $(MAKE) -C $(builddir) $(build_target); then \
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- debian/rules.orig 2020-03-26 08:33:35.0 +0100
+++ debian/rules2020-04-14 20:03:01.302882997 +0200
@@ -993,7 +993,7 @@
stamps/build: stamps/configure
@echo '== $@ =='
-ifneq (,$(filter $(DEB_HOST_ARCH), alpha armel armhf ia64 m68k mips mipsel
mips64 mips64el powerpc powerpcspe riscv64 s390x sparc sparc64))
+ifneq (,$(filter $(DEB_HOST_ARCH), alpha armel armhf ia64 m68k mips mipsel
mips64 mips64el powerpc powerpcspe riscv64 s390x sh4 sparc sparc64))
sh -c 'sh debian/buildwatch.sh $(CURDIR)/$(builddir) &'
endif
if $(EXTRA_BUILD_ENV) $(MAKE) -C $(builddir) $(build_target); then \
Bug#956413: rustc: Please drop workaround to disable incremental builds on sparc64
Source: rustc Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! I just noticed that debian/rules still contains the following workaround for sparc64: ifneq (,$(filter $(DEB_BUILD_ARCH), sparc64)) export CARGO_INCREMENTAL = 0 endif This workaround is no longer necessary as the underlying bug was fixed upstream, please remove it. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#956400: pdf: FTBFS on multiple 32-bit architectures, needs libatomic
Source: qpdf Version: 10.0.1-1 Severity: serious Justification: ftbfs User: debian-...@lists.debian.org Usertags: armel Hi! qpdf fails to build from source on multiple architectures due to missing symbols from libatomic [1]: /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status make[1]: *** [libtests/build.mk:52: libtests/build/aes] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: *** [libtests/build.mk:52: libtests/build/bits] Error 1 make[1]: *** [zlib-flate/build.mk:22: zlib-flate/build/zlib-flate] Error 1 /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status make[1]: *** [libtests/build.mk:52: libtests/build/buffer] Error 1 /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status This is a known issue with gcc [2] and can be fixed by linking against libatomic, similar to apt-cacher-ng [3] and [4]. Please apply such a fix for armel, mipsel, m68k, powerpc and sh4. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=qpdf=armel=10.0.1-1=1586486160=0 > > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862002 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859689
Bug#955845: librsvg: Debian package FTBFS on powerpc, upstream builds fine
Hi! This has been fixed upstream now [1]. This issue can be closed when 2.48.3 is uploaded to unstable. Also, the workaround from #895723 can be removed as well. Adrian > [1] https://gitlab.gnome.org/GNOME/librsvg/-/issues/581 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895723 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#955845: librsvg: Debian package FTBFS on powerpc, upstream builds fine
Control: tags -1 +patch On 4/5/20 11:16 PM, John Paul Adrian Glaubitz wrote: > This is actually still #895723 [1], for some reason the fix doesn't work > on powerpc while it works on ppc64 and ppc64el. > > I suggest we just disable the testsuite on powerpc completely for the > time being. Attaching a patch. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2020-04-05 23:32:24.043398267 +0300 +++ debian/rules 2020-04-06 00:12:01.338385767 +0300 @@ -61,6 +61,12 @@ CARGO_INCREMENTAL=1 dh_auto_test -- TESTS=$(TESTS) endif +# https://bugs.debian.org/955845 +ifneq (,$(filter $(DEB_HOST_ARCH), powerpc)) +override_dh_auto_test: + : +endif + override_dh_auto_test-arch: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) mkdir -p $(CURDIR)/debian/locales
Bug#955845: librsvg: Debian package FTBFS on powerpc, upstream builds fine
Control: retitle -1 librsvg: Testsuite linking failure still affects powerpc This is actually still #895723 [1], for some reason the fix doesn't work on powerpc while it works on ppc64 and ppc64el. I suggest we just disable the testsuite on powerpc completely for the time being. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895723 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#955845: librsvg: Debian package FTBFS on powerpc, upstream builds fine
Source: librsvg Version: 2.48.0-2 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc Hi! librsvg currently fails with a linking error on powerpc [1]: = note: /usr/bin/ld: bss-plt forced due to /<>/target/release/deps/rsvg_c_api-19fee46e3aa0cb72.16te3j7dbumhvm74.rcgu.o /usr/bin/ld: /<>/target/release/deps/rsvg_c_api-19fee46e3aa0cb72.2bda6oryqf97lk8y.rcgu.o: in function `rsvg_c_api::c_api::CHandle::set_base_url': 2bda6oryqf97lk8y:(.text._ZN10rsvg_c_api5c_api7CHandle12set_base_url17h7b7ca170a5e223b2E+0xa4): undefined reference to `rsvg_g_critical_from_c' /usr/bin/ld: /<>/target/release/deps/rsvg_c_api-19fee46e3aa0cb72.2bda6oryqf97lk8y.rcgu.o: in function `rsvg_c_api::c_api::CHandle::get_handle_ref': 2bda6oryqf97lk8y:(.text._ZN10rsvg_c_api5c_api7CHandle14get_handle_ref17hb5b3d86143bb7e4aE+0x178): undefined reference to `rsvg_g_critical_from_c' collect2: error: ld returned 1 exit status This particular problem on powerpc does not show on openSUSE [2] and I cannot reproduce it when building the upstream source instead of the Debian package. I have tried removing Debian-specific build flags from debian/rules and also adding Debian's own build flags for an upstream build using "dpkg-buildflags --export" plus playing around with the configure flags, but so far I haven't figured out why the linking problems show only when building the Debian package. The issue can be reproduced on the porterbox perotto.debian.net. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=librsvg=powerpc=2.48.0-2=1586078010=0 > [2] > https://build.opensuse.org/build/openSUSE:Factory:PowerPC/standard/ppc/librsvg/_log -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954075: busybox: provide a low-priority alternative for vi, view, editor
On 3/28/20 5:16 PM, Cyril Brulebois wrote: > John Paul Adrian Glaubitz (2020-03-17): >> I think enabling vi in the busybox configuration is actually the best >> approach to address this problem as this way we continue to ship vi >> with debian-installer and at the same time get rid of the vim >> dependency which is regularly causing headaches when building >> debian-installer images for Debian Ports. > > Can you expand on that? src:vim is regularly failing to build from source, even on release architectures and I think that this is rather unfortunate for packages that are required for even a minimal Debian installation. Just the latest upload of src:vim is failing on ppc64el again: > https://buildd.debian.org/status/package.php?p=vim=sid > https://buildd.debian.org/status/logs.php?pkg=vim=ppc64el >> It also seems that the maintainer of the vim package would like to >> get rid of vim-tiny which he currently only ships because of >> debian-installer [1]. >> >> Switching the vi implementation in debian-installer from src:vim to >> src:busybox would therefore make both parties happy, I would say. > > I'm not aware of vi playing any part in Debian Installer (there's nano > instead) but maybe I've been missing some piece of information during > all those years? vim-tiny is always installed when debootstrap installs a minimal Debian system and vim-tiny is built from src:vim. My suggestion would be to replace the problematic vim-tiny with the less problematic vile: > https://buildd.debian.org/status/package.php?p=vile=sid > Digging a bit more in the mail you pointed to (and its references…), > it seems you might be referring to the “Priority: important” field for > vim-tiny. While this is indeed used in Debian Installer through > debootstrap(-udeb), the former is not depending on anything provided > by vim-tiny. We've had a number of packages having their priorities > changed over the last release cycle(s), mainly initiated by Ansgar. I > don't think vim-tiny is special here, and if the consensus is that it > should no longer be “Priority: important”, I'm not immediately seeing > reasons for the installer team to object. I just want to avoid debian-installer to be dependent on a package that has regularly quality issues and rather replace it with a simple VI clone which will hopefully also take away pressure from the maintainer of src:vim since he can remove vim-tiny (which he actually wants to) and not bother about debootstrap or debian-installer if the package FTBFS in unstable again. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#955774: rustc: Please reduce the number of allowed testsuite failures on powerpc to 12
Source: rustc Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc Hello! Starting from version 1.41, Rust contains a couple of ABI fixes for powerpc which have helped to reduce the number of testsuite failures down to 10 [1]. So, I think it's safe to move powerpc in debian/rules from 180 allowed testsuite failures to 12 allowed failures, similar to ppc64 and ppc64el. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=rustc=powerpc=1.41.1%2Bdfsg1-1%2Bb1=1586026446=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
(Switched back to my main address, accidentally switched to GMail) On 4/1/20 5:05 PM, Sébastien Villemot wrote: >> So, the currently only candidate for this scenario is mipsel and I think this >> is a risk that is bearable, in particular since upstream considers 32-bit >> mips >> one of the supported architectures unlike alpha and hppa. > > There is also armel that you added recently (I don’t know how supported > it is by upstream). ARMv5 is actually the default baseline that upstream supports. A patch by me to raise the baseline for ARM was rejected by Stas. >> In the worst case, you will have to file a removal bugs for sbcl on mipsel >> if upstream is really unwilling to fix the build issue on mipsel which I >> don't >> think is the case. I have had a lot of interaction with Doug Kratzman from >> sbcl upstream and he is usually very responsive. >> >> I will help with the package in any case. > > Note that several reverse build-dependencies of sbcl (e.g. pgloader) > would have to be removed as well. Good point, but I think the list isn't too long: Checking reverse dependencies... # Broken Depends: buildapp: buildapp [amd64 arm64 armel armhf i386 ppc64el] # Broken Build-Depends: apt-dpkg-ref: sbcl buildapp: sbcl cafeobj: sbcl cffi: sbcl cl-alexandria: sbcl cl-asdf: sbcl cl-unicode: sbcl pgcharts/non-free: sbcl (>= 1.2.0) pgloader: sbcl (>= 1.1.13) stumpwm: sbcl > In any case, thanks for your commitment to helping with portability. > I’m going to apply the patch attached to the present bug in the next > upload. Thanks and you're welcome. I enjoy fixing these portability issues. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Hi! On 4/1/20 4:51 PM, Sébastien Villemot wrote: >> FWIW, sbcl builds fine for me on mipsel if clang is used as the C compiler, >> I'll file a separate bug report for that. > > I have mixed feelings about this. I am worried by the fact that those > architectures are not really supported upstream. Hence, if by chance we > manage to compile SBCL on one of those mostly-unsupported archs, I > don’t know how we would be able to deal with regressions that could > appear in the future, and that would block testing migration for > supported archs. First of all, testing migration is only affected if: a) a package previously built fine on a certain architecture b) the architecture in question is one of the release architectures (this does not apply for alpha, hppa, ppc64, riscv64) So, the currently only candidate for this scenario is mipsel and I think this is a risk that is bearable, in particular since upstream considers 32-bit mips one of the supported architectures unlike alpha and hppa. In the worst case, you will have to file a removal bugs for sbcl on mipsel if upstream is really unwilling to fix the build issue on mipsel which I don't think is the case. I have had a lot of interaction with Doug Kratzman from sbcl upstream and he is usually very responsive. I will help with the package in any case. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Hi! On 3/16/20 1:16 AM, John Paul Adrian Glaubitz wrote: > sbcl has partial support for alpha, hppa, mips*, ppc64 and riscv64 > and if we try to build sbcl on any architecture using clisp, we will > be able to provide upstream with a build log of sbcl on any architecture > that might be supported in the future (like ppc64 and riscv64) or > was previously supported and is currently broken (like alpha and hppa). > > The attached patch enables building with clisp on all unsupported > architectures. Any chance we can get this implemented for the next upload? FWIW, sbcl builds fine for me on mipsel if clang is used as the C compiler, I'll file a separate bug report for that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#939453: sbcl: Please pass host architecture explicitly when calling make.sh in debian/rules
Hi Sébastien! On 9/14/19 4:43 PM, Sébastien Villemot wrote: >> I was just trying to build sbcl for ppc64 on a powerpc Debian with a ppc64 >> chroot and noticed that the build set the compiler architecture to "ppc" >> during build. > > It looks like this particular case is somehow expected. See line 362 of > make-config.sh: for a Debian architecture of "ppc64", the SBCL > architecture is explicitly set at "ppc". However, for a Debian > architecture of "ppc64el", then the SBCL architecture is "ppc64". Yes, that's correct. On hppa, on the other hand, the problem is that sbcl does not consider the case of a 32-bit userland on a 64-bit, although this is currently the common use case for hppa. > I don’t really understand why there is such a strange mapping, but at > least your problem does not come from the Debian packaging. The mapping exists because for architectures like PowerPC and SPARC it used to be very common to use a 32-bit userland on a 64-bit kernel. This way you would get the advantage to use large virtual address spaces on the one hand and getting high performance due to the use of 32-bit pointers on the other hand. Unlike x86, both PowerPC and SPARC didn't make very big jumps from 32 to 64 bits unless the 32-bit baseline you started from was very old which was not the case in Debian, for example. In any case, it would be very useful if this mapping could be added to debian/rules for at least hppa and ppc64. ifeq (hppa,$(DEB_HOST_ARCH)) export SBCL_ARCH=hppa endif ifeq (ppc64,$(DEB_HOST_ARCH)) export SBCL_ARCH=ppc64 endif Could you add this to debian/rules? FWIW, for hppa, you can alternatively backport my patch which I contributed upstream [1]. Thanks, Adrian > [1] > https://github.com/sbcl/sbcl/commit/d78e5e730dd41c6db80c4f6604a9cb66f41171b3 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954843: ausweisapp2 is listed as a unviersal access app
On 3/30/20 7:06 PM, A. Klitzing wrote: > ah, ok... is this ok? > Categories=Utility;System;Security; I think it would have to be Categories=System;Security; "Utility" and "System" are both main categories, so that's mutually exclusive. > Looks like we don't fit in any other category. > Even "security" isn't the right place. Otherwise a browser should be > listed in security, too. ;-) Oh yeah, I fully agree. I don't know either which category to use. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954843: ausweisapp2 is listed as a unviersal access app
Hi André! On 3/30/20 6:50 PM, A. Klitzing wrote: > the AusweisApp2 supports accessibility but is not a "screen reader" > itself, right. > We removed it. It will be fixed in 1.20.1! I'm not sure whether you can use "Utility" alone. Looking at the current list of freedesktop categories [1], I think there isn't really a category that fits AusweisApp2 well. Maybe System;Security? Adrian > [1] https://en.opensuse.org/openSUSE:Packaging_desktop_menu_categories -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#955338: sbcl: Please backport patch to fix build on kfreebsd-*
Source: sbcl Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: kfreebsd-amd64 Hi! sbcl fails to build from source on kfreebsd-amd64 [1] the same way it did on powerpc, so I sent a patch upstream which was merged to fix the issue the same way as on powerpc [2]. Can you include the attached patch for the next upload to fix the build on kfreebsd-*? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=sbcl=kfreebsd-amd64=2%3A2.0.2-2=1584178866=0 > [2] > https://github.com/sbcl/sbcl/commit/d85d2f8c39e7fc6feca3ebf6f494c961dc5226d8 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From d85d2f8c39e7fc6feca3ebf6f494c961dc5226d8 Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz Date: Mon, 30 Mar 2020 01:04:48 +0200 Subject: [PATCH] kfreebsd: Add -no-as-needed to OS_LIBS --- src/runtime/Config.x86-64-gnu-kfreebsd | 2 +- src/runtime/Config.x86-gnu-kfreebsd| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/runtime/Config.x86-64-gnu-kfreebsd b/src/runtime/Config.x86-64-gnu-kfreebsd index 89975c48f..6fd4cdd05 100644 --- a/src/runtime/Config.x86-64-gnu-kfreebsd +++ b/src/runtime/Config.x86-64-gnu-kfreebsd @@ -15,7 +15,7 @@ include Config.x86-64-bsd # worked fine for most things, but LOAD-FOREIGN & friends require # dlopen() etc., which in turn depend on dynamic linking of the # runtime. -OS_LIBS += -lutil -ldl +OS_LIBS += -lutil -ldl -Wl,-no-as-needed # use libthr (1:1 threading). libpthread (m:n threading) does not work. ifdef LISP_FEATURE_SB_THREAD diff --git a/src/runtime/Config.x86-gnu-kfreebsd b/src/runtime/Config.x86-gnu-kfreebsd index 385209023..e49dde4a6 100644 --- a/src/runtime/Config.x86-gnu-kfreebsd +++ b/src/runtime/Config.x86-gnu-kfreebsd @@ -17,7 +17,7 @@ include Config.x86-bsd # runtime. LINKFLAGS += -dynamic -Wl,--export-dynamic -m32 -OS_LIBS += -lutil -ldl +OS_LIBS += -lutil -ldl -Wl,-no-as-needed # use libthr (1:1 threading). libpthread (m:n threading) does not work. ifdef LISP_FEATURE_SB_THREAD -- 2.26.0
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
Control: reopen -1 On 3/28/20 6:16 PM, John Paul Adrian Glaubitz wrote: > On 3/28/20 5:39 PM, Ivo De Decker wrote: >> This bug wasn't fixed in time for buster. Is it still present in bullseye? If >> so, it might be good to try to fix it this time. > > I fixed the bug upstream [1], so we can safely close the issue here. Ah, I just realized this bug also affected s390x. Sorry, I will reopen it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954718: grub-installer: update templates for UEFI and other media than hard disks
On 3/26/20 2:05 PM, Steve McIntyre wrote: > I think this is better, yes. :-) Taking into account Adrian's > feedback, maybe s/primary drive/hard disk/ in most places? > > Thanks for this effort - it's definitely good to move away from the > misleading "MBR" text. Sounds reasonable to me. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954718: grub-installer: update templates for UEFI and other media than hard disks
On 3/25/20 3:03 PM, Holger Wansing wrote: >> It's not always easy to tell reliably if you're installing to a >> virtual device. It's still a "drive" as far as most people are >> concerned, so I'd just stick with that. > > I have attached an updated patch, which might be considered. Well, my opinion is still that it's a very bad idea to get rid of the term "hard disk". I assume more people understand the meaning of "hard disk" but not the meaning of "primary drive". In fact, I just asked my 62-year-old dad who happens to sit next to me whether he understands what the meaning "the primary drive of your computer" is and whether he understood what "the hard disk in your computer" means. He didn't understand "primary drive", but he perfectly well understood what "hard disk" refers to which is my whole point. You are actually making it harder to understand because you think it's more important to use the technically correct term instead of just using a term every user will understand. And, FWIW, you can also install GRUB on secondary, tertiary or external drives. So "primary drive" isn't even correct either. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#946836: Build failure on powerpc architectures
Hi Martin!
On 3/25/20 9:27 AM, Martin Maechler wrote:
> Thanks a lot, Adrian!
>
> { When I had added __PPC64__ it was because it "seemed clear"
> (by the OP, I don't have access to these architectures) that the
> clause should only be used for powerpc architectures where
> -mlong-double-128
> is available / in used .. and so I would have "concluded"
> would only apply to 64-bit pppc ..
> }
As mentioned in my earlier mail, you can get free access to a POWER
machine (and many other architectures) through the GCC compile farm,
you just need to apply for an account.
> https://gcc.gnu.org/wiki/CompileFarm
> But it seems using the macro instead of the static variable is
> safer (albeit possibly somewhat slower when the code is run, but
> that will probably also depend much on the compilation
> optimizations ..).
>
> I will change to use __powerpc__ now and wait some hours (on
> a possible reply from you !) before committing the change to the
> upstream sources.
I can only say that the workaround is needed on 32-bit PowerPC
as well, so it should match against "__powerpc__" and not just
"__PPC64__", the former is defined on all PowerPC targets.
Thanks for fixing the issue upstream, much appreciated.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#946836: Build failure on powerpc architectures
On 3/24/20 8:32 PM, Dirk Eddelbuettel wrote: > In r-devel I see > > #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) > # ifdef __PPC64__ > // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with > LDOUBLE > # define q_1_eps (1 / LDBL_EPSILON) > # else > static LDOUBLE q_1_eps = 1 / LDBL_EPSILON; > # endif > #else > static double q_1_eps = 1 / DBL_EPSILON; > #endif > > which is the same as what we have in R 3.6.3. So unless fixed, R 4.0.0 will > also fail :-/ See my other mail. Just use __powerpc__ instead of __PPC64__ and adjust the comment. Uploading a manually built package for powerpc in the meantime, so don't be confused it shows as fixed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#946836: Build failure on powerpc architectures
Hi! On 3/24/20 8:01 PM, John Paul Adrian Glaubitz wrote: > It would be nice if this bug could be fixed as the missing r-base package > is blocking a lot of other packages on powerpc. This can be easily fixed by replacing __PPC64__ with __powerpc__ which is defined on all PowerPC architectures (ppc64el, ppc64, powerpc). Suggestion to change the patch into: #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) +# ifdef __powerpc__ + // PowerPC (when gcc has -mlong-double-128) breaks here ... +# define q_1_eps (1 / LDBL_EPSILON) +# else static LDOUBLE q_1_eps = 1 / LDBL_EPSILON; +# endif #else static double q_1_eps = 1 / DBL_EPSILON; #endif Proof that __powerpc__ is available on all three PowerPC targets. On powerpc architecture: (sid-powerpc-sbuild2)root@kapitsa:/# gcc -dM -E - < /dev/null|grep __powerpc__ #define __powerpc__ 1 (sid-powerpc-sbuild2)root@kapitsa:/# On ppc64 architecture: (sid-ppc64-sbuild2)root@kapitsa:/# gcc -dM -E - < /dev/null|grep __powerpc__ #define __powerpc__ 1 (sid-ppc64-sbuild2)root@kapitsa:/# On ppc64el architecture: (sid_ppc64el-dchroot)glaubitz@plummer:~$ gcc -dM -E - < /dev/null|grep __powerpc__ #define __powerpc__ 1 (sid_ppc64el-dchroot)glaubitz@plummer:~$ Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#946836: Build failure on powerpc architectures
(Re-sent as the bug report had to be unarchived first) Control: reopen -1 User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-CC: debian-powe...@lists.debian.org Hello! This bug is still present [1], not sure why this bug report was closed. A Debian powerpc/ppc64 porterbox is available, no restrictions apply [2], it's available to all Debian Developers and anyone with a Debian guest account. The GCC compile farm also has PowerPC boxes available [3], any open source developer can request access to a PowerPC for free [4]. It would be nice if this bug could be fixed as the missing r-base package is blocking a lot of other packages on powerpc. PS: Please always set the proper usertags and CC the architecture mailing list when filing architecture-specific bugs. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=r-base=powerpc=3.6.3-1=1583981629=0 > [2] https://db.debian.org/machines.cgi?host=perotto > [3] https://gcc.gnu.org/wiki/CompileFarm > [4] https://cfarm.tetaneutral.net/users/new/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954843: ausweisapp2 is listed as a unviersal access app
Hi Thorsten!
On 3/24/20 12:57 PM, Thorsten Ehlers wrote:
> ausweisapp2 works fine for me (Gnome 3 w/ gnome-shell-extension-top-icons-plus
> installed) but I found a minor nuisance as the app appears in category
> "universal access" ("Barrierefreiheit" in German) in the Gnome applications
> menu - if enabled.
>
> This app does not target disabled persons in the first place so may be another
> category will be more suitable?
This entry is part of the upstream source [1], so the best idea is to report
the issue to the upstream developers. I have CC'ed Andre Klitzing who is one
of the upstream developers.
Thanks,
Adrian
> [1]
> https://github.com/Governikus/AusweisApp2/blob/community/resources/packaging/linux/com.governikus.ausweisapp2.desktop.in
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954718: grub-installer: update templates for UEFI and other media than hard disks
On 3/23/20 5:43 PM, Holger Wansing wrote: >> It's not always easy to tell reliably if you're installing to a >> virtual device. It's still a "drive" as far as most people are >> concerned, so I'd just stick with that. > > Just trying to improve the old situation "Installing to a hard disk / drive". > If people think we should stay at that old situation, feel free to ignore this > bugreport. > Otherwise provide a better patch, if you can. I understand your motivation but I don't think you can come up with a one-fits-all in this situation as there are just too many different possible combinations of boot loader installation locations (boot sector, EFI directory, chainloader) and disk types. While I totally agree that Linux isn't exclusively installed to hard disks *, I don't think the messages are particularly misleading, especially since the GRUB sources itself still use the "hard disk" terminology everywhere. I think "hard disk" is just understood as the generic term for a system disk on which the operating system is installed and I assume everyone who understands the concept of disks and partitions would also know why it's called "hard disk". Adrian * = Installing to other drives than hard-disks isn't actually that new, the NeXT Cube from 1990 didn't actually have a hard disk but an MO disk as its primary disk drive. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954718: grub-installer: update templates for UEFI and other media than hard disks
On 3/22/20 3:59 PM, Holger Wansing wrote: > - MBR is outdated -> UEFI came as a successor; What about the boot mechanisms of all other architectures? Open-Firmware machines use GRUB as well and they have a boot sector. Other architectures use GRUB via chainloading with uboot, so you need to include this well if you want to be comprehensive. And s390x supports GRUB as well. Do you want to include all these, too? > - hard disks are no longer the only/mainly used storage media (depending on > architecture); these days we are installing OS'es on SD cards or USB > thumbdrives for example. What about virtual devices? Is "drive" appropriate in these cases or should it be "disk image"? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954071: matplotlib: Circular dependency chain with python3-sphinx-gallery
On 3/21/20 12:21 AM, Sandro Tosi wrote: >> It's no longer possible to bootstrap matplotlib using the stage1 profile >> since python3-sphinx-gallery depends on python3-matplotlib itself. >> >> Can you mark python3-sphinx-gallery also as "" if possible? > > would it work the same if i mark it as ? Not sure. I think you can activate only one profile at the time, can't you? So, when you bootstrap matplotlib with --profile=stage1, can you still set "nodoc"? If you want this in "nodoc", maybe would make more sense? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954167: d-shlibs: fontforge FTBFS - There is no package matching [libutil1-dev] and noone provides it
Source: d-shlibs Severity: normal User: debian-...@lists.debian.org Usertags: m68k Hi! The package fontforge fails to build from source on some architectures with an error message that seems to originate in d-shlibs [1]: --> libpango1.0-dev package exists. --> libpng-dev package exists. --> libpython3.8-dev package exists. --> libreadline-dev package exists. --> libspiro-dev package exists. --> libtiff5-dev package exists. --> libuninameslist-dev package exists. devlibs error: There is no package matching [libutil1-dev] and noone provides it, please report bug to d-shlibs maintainer --> libxml2-dev package exists. --> zlib1g-dev package exists. make: *** [debian/rules:67: debian/stamp-local-shlibs-libfontforge] Error 1 I'm not really sure what the exact problem is since I haven't looked into d-shlibs yet, but since the error message suggested reporting a report, I have opened this bug report in the hope that the maintainers of d-shlibs can tell me what the problem is. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=fontforge=m68k=1%3A20190801%7Edfsg-4=1584195707=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954134: [d-i bullseye alpha2] installing grub fails
On 3/17/20 12:49 PM, Holger Wansing wrote: > However: > >> Mar 16 09:55:43 main-menu[285]: (process:1258): grub-probe: error: unknown >> filesystem. > [...] >> Mar 16 09:55:43 main-menu[285]: (process:1258): corrupted size vs. prev_size >> Mar 16 09:55:43 main-menu[285]: (process:1258): Aborted >> Mar 16 09:55:43 main-menu[285]: WARNING **: Configuring 'grub-installer' >> failed with error code 134 >> Mar 16 09:55:43 main-menu[285]: WARNING **: Menu item 'grub-installer' >> failed. Yes, I have seen that. However, grub-installer is basically a script which invokes grub-install, so I'm not sure where that crash should come from. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954134: [d-i bullseye alpha2] installing grub fails
On 3/17/20 11:05 AM, Holger Wansing wrote: > Logs attached. grub-installer did not report any problems: Mar 16 09:55:41 grub-installer: info: Installing grub on '/dev/sda' Mar 16 09:55:41 grub-installer: info: grub-install does not support --no-floppy Mar 16 09:55:41 grub-installer: info: Running chroot /target grub-install --force "/dev/sda" Mar 16 09:55:41 grub-installer: Installing for i386-pc platform. Mar 16 09:55:42 grub-installer: Installation finished. No error reported. Mar 16 09:55:42 grub-installer: info: grub-install ran successfully Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954075: busybox: provide a low-priority alternative for vi, view, editor
On 3/17/20 10:38 AM, Simon McVittie wrote: > On Tue, 17 Mar 2020 at 09:13:33 +0100, John Paul Adrian Glaubitz wrote: >> I think enabling vi in the busybox configuration is actually the best >> approach >> to address this problem as this way we continue to ship vi with >> debian-installer >> and at the same time get rid of the vim dependency which is regularly causing >> headaches when building debian-installer images for Debian Ports. > > I think you're mixing up the mostly-udeb-based system that *runs* d-i > with the deb-based system that *is installed by* d-i, and I think you're > mixing up enabling the vi applet with making it available as the 'vi' > command in PATH. Right. But that doesn't change the fact that I still think the idea is sensible to fix the installation issue in d-i. > The vi applet is already enabled in the ordinary and static .deb packages: > after "apt install busybox" or "apt install busybox-static", you can run > "busybox vi example.txt" to get a basic vi-compatible editor. It's a less > fully-featured vi than you're probably used to (in particular there is > no undo!) but it works. vim-tiny isn't a fully-featured vim either, is it? > If you want busybox vi to be available in the default system installed > by d-i or debootstrap, then that's a separate feature request, for which > you would need to ask the ftp team to raise the Priority of busybox from > optional to important. > > If you want busybox vi to provide a vi command in the default system > installed by d-i or debootstrap, then you need the alternatives to be set > up (#954075), *and* you need the ftp team to raise the Priority of the > package (and probably lower the Priority of vim-tiny at the same time). OK. > If you want busybox vi to be available in the shell while d-i is running, > then that's a different separate feature request, for enabling vi in > the busybox *udeb* (debian/config/pkg/udeb). At the moment the busybox > udeb doesn't enable CONFIG_VI, and the only visual text editor with a > udeb seems to be nano-udeb. (vim, nvi, elvis don't produce udebs either, > so there is no vi(1) in the d-i environment, and that isn't a regression.) I really only care about fixing this issue so that I don't have to build vim manually on half a dozen architectures with the testsuite disabled just to be able to build usable debian-installer images. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954075: busybox: provide a low-priority alternative for vi, view, editor
Hi Simon! On 3/16/20 12:31 PM, Simon McVittie wrote: > Steps to reproduce: > > - Install a chroot/container > - Install busybox > > Expected results: > > - If a more fully-featured vi is installed (vim, vim-*, nvi, etc.) then it > provides the vi and view commands in PATH > - Otherwise, "vi foo.txt" runs busybox vi > - Ideally, "view foo.txt" would be equivalent to "busybox vi -R foo.txt" > (but this might require a two-line shell script wrapper or busybox code > changes to recognise view as a command, rather than just a symlink) > > - If a more fully-featured editor is installed (one of the above, or a non-vi > editor like nano, emacs etc.) then it provides the editor command in PATH > - Otherwise, "editor foo.txt" runs busybox vi > > Actual result: > > - If a more fully-featured editor is installed, we get the expected result > - Otherwise, vi, view and editor are unimplemented, even though busybox could > implement them > > For editor, busybox vi should probably be a higher priority than ed, but > a lower priority than any non-minimal editor. > > For vi, busybox vi should probably be a lower priority than any > separately-installed vi implementation, on the basis that if you installed > nvi or elvis-tiny or something, it's probably because you wanted to use it. I think enabling vi in the busybox configuration is actually the best approach to address this problem as this way we continue to ship vi with debian-installer and at the same time get rid of the vim dependency which is regularly causing headaches when building debian-installer images for Debian Ports. It also seems that the maintainer of the vim package would like to get rid of vim-tiny which he currently only ships because of debian-installer [1]. Switching the vi implementation in debian-installer from src:vim to src:busybox would therefore make both parties happy, I would say. Thanks, Adrian > [1] https://lists.debian.org/debian-devel/2020/03/msg00246.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
On 3/16/20 5:34 PM, John David Anglin wrote: > With patch, I get following error: See [1], the build system is not very smart, unfortunately. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939453 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954091: mypaint: Please honour "nocheck" in DEB_BUILD_OPTIONS
Source: mypaint Severity: normal User: debian-...@lists.debian.org Usertags: m68k Hi! mypaint overrides the dh_auto_test target in debian/rules without checking for "nocheck" being set in DEB_BUILD_OPTIONS. This results in the testsuite being run even though "nocheck" is passed in DEB_BUILD_OPTIONS. Being able to disable the testsuite is necessary when building packages in emulated environments where the testsuite might not pass due to emulation issues or for cross-builds where the testsuite cannot be run due to the build and target architectures being different. In order to fix this, the code inside the override_dh_auto_test target should be guarded with an if conditional which tests for "nocheck" being present in DEB_BUILD_OPTIONS: ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),) endif See also #908373 [1] for reference. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908373 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954071: matplotlib: Circular dependency chain with python3-sphinx-gallery
Source: matplotlib Severity: normal User: debian-...@lists.debian.org Usertags: m68k Hello! It's no longer possible to bootstrap matplotlib using the stage1 profile since python3-sphinx-gallery depends on python3-matplotlib itself. Can you mark python3-sphinx-gallery also as "" if possible? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Source: sbcl Severity: normal Tags: patch Hi! In order to provide some basic level of continuous integration for sbcl upstream, it would be great if the sbcl package could be tried to build on any of the currently unsupported architectures using clisp. sbcl has partial support for alpha, hppa, mips*, ppc64 and riscv64 and if we try to build sbcl on any architecture using clisp, we will be able to provide upstream with a build log of sbcl on any architecture that might be supported in the future (like ppc64 and riscv64) or was previously supported and is currently broken (like alpha and hppa). The attached patch enables building with clisp on all unsupported architectures. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/sbcl-2.0.2/debian/control new/sbcl-2.0.2/debian/control --- old/sbcl-2.0.2/debian/control 2020-03-07 09:45:04.0 +0100 +++ new/sbcl-2.0.2/debian/control 2020-03-16 01:08:41.739735423 +0100 @@ -7,7 +7,8 @@ Priority: optional Build-Depends: debhelper-compat (= 12), debhelper (>= 12.8~), - sbcl, + clisp [!amd64 !arm64 !armhf !i386 !powerpc !ppc64el], + sbcl [amd64 arm64 armhf i386 powerpc ppc64el], sbcl-source, texinfo, zlib1g-dev, diff -Nru old/sbcl-2.0.2/debian/rules new/sbcl-2.0.2/debian/rules --- old/sbcl-2.0.2/debian/rules 2020-03-07 10:05:22.0 +0100 +++ new/sbcl-2.0.2/debian/rules 2020-03-16 00:52:53.830038807 +0100 @@ -4,6 +4,10 @@ export DH_VERBOSE=1 +ifeq (,$(filter amd64 arm64 armhf i386 powerpc ppc64el, $(DEB_HOST_ARCH))) + BOOTSTRAPLISP := clisp +endif + ifeq (,$(BOOTSTRAPLISP)) BOOTSTRAPLISP := /usr/bin/sbcl --disable-debugger --no-sysinit --no-userinit endif
Bug#954004: systemd-udevd: do_page_fault() type=15 address=0x00000005
User: debian-h...@lists.debian.org Usertags: hppa X-Debbugs-CC: debian-h...@lists.debian.org On 3/15/20 6:31 PM, Michael Biebl wrote: > This will need a hppa porter to look into this so adding them to CC Thanks for letting the Debian Ports folks (us) know :). > hppa porters: do you use usertags so this bug report can be tagged (and > tracked) properly? Yes, I just added them. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953869: glibc: Please disable nptl/tst-cond8-static and nptl/tst-mutex{,pi}8-static on sparc64
On 3/14/20 11:26 AM, John Paul Adrian Glaubitz wrote: > With glibc 2.31, the number of testsuite failures has dropped to just three > failures on sparc64: > > FAIL: nptl/tst-cond8-static > FAIL: nptl/tst-mutex8-static > FAIL: nptl/tst-mutexpi8-static > > I have reported these failures upstream [1, 2]. > > Since 2.31 seems to be a big improvement on sparc64, can you disable these > three tests so that we can quickly enable 2.31 on sparc64? I have rebuild glibc_2.31 with these tests marked as XFAIL multiple times and the number of failures is reproducible for me. So, can we get this change included? --- debian/testsuite-xfail-debian.mk~ 2020-03-12 00:39:25.0 +0300 +++ debian/testsuite-xfail-debian.mk2020-03-15 14:10:30.480945698 +0300 @@ -985,6 +985,9 @@ test-xfail-XOPEN2K8/pthread.h/conform = yes test-xfail-XOPEN2K8/setjmp.h/conform = yes test-xfail-XPG4/setjmp.h/conform = yes +test-xfail-tst-cond8-static = yes +test-xfail-tst-mutex8-static = yes +test-xfail-tst-mutexpi8-static = yes test-xfail-tst-protected1a = yes test-xfail-tst-protected1b = yes test-xfail-tst-realloc = yes Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953958: Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Hi Marco! On 3/15/20 2:33 AM, Marco d'Itri wrote: > On Mar 15, John Paul Adrian Glaubitz wrote: > >> Do you have a patch handy, then I'll fix the package manually for the time >> being for ia64 only? > Just edit debian/patch_libtool. Works. I had to modify debian/libcrypt1.symbols.ia64 as well: --- libcrypt1.symbols.ia64~ 2020-02-28 20:26:01.0 +0100 +++ libcrypt1.symbols.ia64 2020-03-15 09:20:38.110547617 +0100 @@ -1,4 +1,4 @@ -libcrypt.so.1.1 libcrypt1 #MINVER# +libcrypt.so.1 libcrypt1 #MINVER# #include "libcrypt1.symbols.common" GLIBC_2.0@GLIBC_2.0 1:4.1.0 crypt@GLIBC_2.0 1:4.1.0 So, please don't forget this. > Let me know if it works and I will apply the change. Thanks. Please go ahead changing debian/patch_libtool and debian/libcrypt1.symbols.ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
On 3/14/20 5:19 PM, James Clarke wrote: > This is just the opposite of #947606; ia64 is meant to have libcrypt.so.1, not > libcrypt.so.1.1 like alpha, and so that change needs to be reverted. See [1] > for an old glibc build log to demonstrate the correct name (and note that, > unlike alpha, sysdeps/unix/sysv/linux/ia64/shlib-versions does not override > libcrypt's version). Do you have a patch handy, then I'll fix the package manually for the time being for ia64 only? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Package: libcrypt1 Version: 1:4.4.15-1 Followup-For: Bug #953562 User: debian-i...@lists.debian.org Usertags: ia64 Hello! This actually causes issues on ia64 now: Setting up libc6.1:ia64 (2.30-2) ... /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory dpkg: error processing package libc6.1:ia64 (--configure): installed libc6.1:ia64 package post-installation script subprocess returned error exit status 127 Errors were encountered while processing: libc6.1:ia64 E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. E: Package installation failed So it's not just a theoretical issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953869: glibc: Please disable nptl/tst-cond8-static and nptl/tst-mutex{,pi}8-static on sparc64
Source: glibc Version: 2.31-0experimental0 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hello! With glibc 2.31, the number of testsuite failures has dropped to just three failures on sparc64: FAIL: nptl/tst-cond8-static FAIL: nptl/tst-mutex8-static FAIL: nptl/tst-mutexpi8-static I have reported these failures upstream [1, 2]. Since 2.31 seems to be a big improvement on sparc64, can you disable these three tests so that we can quickly enable 2.31 on sparc64? 2.30 seems to be broken on sparc64, unfortunately, as it already causes segfaults during installation: Setting up libc6:sparc64 (2.30-2) ... dpkg: error processing package libc6:sparc64 (--configure): installed libc6:sparc64 package post-installation script subprocess was killed by signal (Segmentation fault) Errors were encountered while processing: libc6:sparc64 E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. E: Package installation failed Thanks, Adrian > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25671 > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=25672 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953847: sbcl: Please include patch to fix build on powerpc and ppc64el
Source: sbcl Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: powerpc,ppc64el Hello! The attached patch fixes the sbcl build on powerpc and ppc64el, I have already included it in the sbcl package on openSUSE [1]. Please apply. Thanks, Adrian > [1] https://build.opensuse.org/package/show/devel:languages:misc/sbcl -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru sbcl-2.0.2.orig/src/runtime/Config.ppc64-linux sbcl-2.0.2/src/runtime/Config.ppc64-linux --- sbcl-2.0.2.orig/src/runtime/Config.ppc64-linux 2020-02-29 21:25:50.0 +0100 +++ sbcl-2.0.2/src/runtime/Config.ppc64-linux 2020-03-13 15:20:42.148527131 +0100 @@ -10,7 +10,7 @@ # files for more information. CFLAGS += -m64 -LINKFLAGS += -rdynamic -m64 +LINKFLAGS += -rdynamic -m64 -Wl,-no-as-needed NM = ./linux-nm ASSEM_SRC = ppc64-assem.S diff -Nru sbcl-2.0.2.orig/src/runtime/Config.ppc-linux sbcl-2.0.2/src/runtime/Config.ppc-linux --- sbcl-2.0.2.orig/src/runtime/Config.ppc-linux2020-02-29 21:25:50.0 +0100 +++ sbcl-2.0.2/src/runtime/Config.ppc-linux 2020-03-13 15:18:48.903522685 +0100 @@ -10,7 +10,7 @@ # files for more information. CFLAGS += -m32 -LINKFLAGS += -rdynamic -m32 +LINKFLAGS += -rdynamic -m32 -Wl,-no-as-needed NM = ./linux-nm ASSEM_SRC = ppc-assem.S
Bug#953643: gdk-pixbuf FTBFS on powerpc due to "ModuleNotFoundError: No module named 'giscanner._giscanner'"
Hi Simon and Daniel! On 3/11/20 8:25 PM, Simon McVittie wrote: > On Wed, 11 Mar 2020 at 01:20:56 -0400, Daniel Kahn Gillmor wrote: >> ModuleNotFoundError: No module named 'giscanner._giscanner' > > I think this is the python3.8 transition, combined with powerpc not having > built gobject-introspection since #950267 was fixed. > > The powerpc binary for gobject-introspection only contains a _giscanner.so > for python3.7 (which was current when it was built), but is run with the > default python3, which is now python3.8. It should have had a dependency > on python3 (<< 3.8) to represent that, but the correct dependency wasn't > generated due to a packaging bug (#950267, now fixed). > > A powerpc porter might be able to rescue this by doing a manual binNMU > of powerpc's outdated source version of gobject-introspection against > python3.8-as-default, or by building gdk-pixbuf with python3 (<< 3.8) > installed, or something. Thanks so much for already doing some investigative work on this. I actually wanted to look into this issue tonight but I was out for some hours today so I didn't have the time. I will try to perform the manual binNMU now after dinner. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#931630: ntp: Please include patch to fix build on m68k (alignment)
On 3/10/20 8:43 AM, Bernhard Schmidt wrote: >> Due to its native alignment being 16 bits wide, m68k needs an additional >> padding in the struct conf_restrict: > > This has supposedly been fixed in 4.2.8p14 (according to > https://bugs.ntp.org/show_bug.cgi?id=3599 and I do see the diff), but > the build is still failing with the same error > > https://buildd.debian.org/status/fetch.php?pkg=ntp=m68k=1%3A4.2.8p14%2Bdfsg-1=1583525084=0 Most likely they made another change to their structs which changed the overall alignment again. I will have a look and report a bug if necessary. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#951387: Please accept https://salsa.debian.org/installer-team/console-setup/merge_requests/3
Hi! On 3/9/20 10:33 PM, Nicholas D Steeves wrote: >> Hi, why such simple patch isn't accepted - 3 weeks already passed... >> > > Don't feel bad! Here's one I've been waiting three years for (tested > with custom install media in a VM): > > > https://salsa.debian.org/installer-team/partman-btrfs/-/merge_requests/1/commits I can have a look tomorrow. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
On 3/9/20 9:16 AM, Martin Quinson wrote: > I think it should be OK now: > https://salsa.debian.org/debian/simgrid/-/commit/fd9c3ef7f78a48718dc008e16649b49d7e424bf1 Yes, that looks good. Thank you! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
On 3/9/20 3:31 AM, Martin Quinson wrote: > I'm currently building the next version of the package to include > this. Thanks all for the patches. You should be able to enable Java on any architecture but not ns3 (not sure if that's related to the Java stuff). > On Mon, Mar 09, 2020 at 12:09:14AM +0100, Aurelien Jarno wrote: >> [1] Note that #950527 provides a patch to build a 64-bit binutils version on >> some 32-bit architectures that should make ns3 buildable again on >> mipsel. > > Cool! thanks for the pointer. I subscribed to the PR on salsa to > follow this. I think the sensible choice is then to change the libns3-dev dependency to "libns3-dev [!mipsel]". Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
On 3/9/20 12:14 AM, John Paul Adrian Glaubitz wrote: > On 3/9/20 12:09 AM, Aurelien Jarno wrote: >>> Attaching a patch which enables Java support on all architectures. >> >> Has it been tested on at least one of the other architectures? > > Currently test-building on m68k, it's almost finished. Confirmed to build fine on m68k, powerpc and ppc64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
Hello! On 3/9/20 12:09 AM, Aurelien Jarno wrote: >> Attaching a patch which enables Java support on all architectures. > > Has it been tested on at least one of the other architectures? Currently test-building on m68k, it's almost finished. > At least this part is not correct as libns3-dev is not available > anymore due to linker memory usage issue [1]. So if you want to enable > ns3 support on all the other architectures [2] it should probably be > [!mipsel]. Okay, that's unexpected then. I tested on m68k and assumed ns3 would be available everywhere if it's available on m68k. > [1] Note that #950527 provides a patch to build a 64-bit binutils version on > some 32-bit architectures that should make ns3 buildable again on > mipsel. > > [2] Note that ns3 is not buildable anymore on ia64, k-a, k-i and > powerpc. Yes, as a result of other packages currently FTBFS. But that should mean fixing the FTBFS in these cases. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
Hi!
On 3/8/20 11:33 PM, John Paul Adrian Glaubitz wrote:
> In fact, this whitelist shouldn't be necessary at all and Java should just
> be enabled for all architectures (I will eventually get around fixing
> hppa).
Attaching a patch which enables Java support on all architectures.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff -Nru old/simgrid-3.25+dfsg/debian/control new/simgrid-3.25+dfsg/debian/control
--- old/simgrid-3.25+dfsg/debian/control 2020-02-21 20:31:20.0 +0100
+++ new/simgrid-3.25+dfsg/debian/control 2020-03-08 23:35:44.819782490 +0100
@@ -7,14 +7,14 @@
dh-python,
cmake,
chrpath,
- default-jdk (>= 2:1.7~) [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x],
+ default-jdk (>= 2:1.7~),
# valgrind is missing on armel
valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x],
gfortran,
liblua5.3-dev, lua5.3,
# Disabled for now: libboost-context-dev. Seems broken on amd64
libboost-dev,
- libns3-dev [amd64 arm64 armel armhf i386 mips64el ppc64el s390x],
+ libns3-dev,
# Needed to build the doc
# doxygen,
# python3-breathe,
@@ -69,7 +69,7 @@
Package: libsimgrid-java
Section: java
-Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x
+Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libsimgrid3.25 (>= ${source:Version})
#Recommends: simgrid-doc (>= ${source:Version})
Breaks: simgrid (<< 3.11), simgrid-java
diff -Nru old/simgrid-3.25+dfsg/debian/rules new/simgrid-3.25+dfsg/debian/rules
--- old/simgrid-3.25+dfsg/debian/rules 2020-02-21 20:31:20.0 +0100
+++ new/simgrid-3.25+dfsg/debian/rules 2020-03-08 23:38:00.895783078 +0100
@@ -21,12 +21,6 @@
CFLAGS += -O3
endif
-ifneq (,$(findstring $(DEB_HOST_ARCH_CPU),amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x))
- CMAKE_FLAGS += -Denable_java=ON
-else
- CMAKE_FLAGS += -Denable_java=OFF
-endif
-
ifneq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
CMAKE_FLAGS += -Denable_documentation=off
endif
@@ -50,6 +44,7 @@
-Denable_msg=ON \
-Denable_smpi_MPICH3_testsuite=ON \
-Denable_lib_in_jar=OFF \
+ -Denable_java=ON \
${CMAKE_FLAGS}
override_dh_auto_build:
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
On 3/8/20 11:31 PM, John Paul Adrian Glaubitz wrote: > On 3/8/20 11:21 PM, Aurelien Jarno wrote: >> The problem is that java support is not enabled on riscv64. After >> enabling it (as well as ns3 which is also available) I have verified that >> simgrid builds fine on riscv64. >> >> I have attached the patch I have used. Would it be possible to include >> it in the next upload? > > Can we do this for all architectures, please? > > Looking at the build logs, the issue exists for all ports architectures. In fact, this whitelist shouldn't be necessary at all and Java should just be enabled for all architectures (I will eventually get around fixing hppa). Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
Hi! On 3/8/20 11:21 PM, Aurelien Jarno wrote: > The problem is that java support is not enabled on riscv64. After > enabling it (as well as ns3 which is also available) I have verified that > simgrid builds fine on riscv64. > > I have attached the patch I have used. Would it be possible to include > it in the next upload? Can we do this for all architectures, please? Looking at the build logs, the issue exists for all ports architectures. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#952815: grub2: Please drop TARGET_CCASFLAGS from debian/rules for 2.06 release
Source: grub2 Version: 2.04-5 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hello! The upcoming 2.06 release contains a fix to set -no-PIE in TARGET_CCASFLAGS [1] such that the current workaround in debian/rules will no longer be necessary. The following patch should be applied to debian/rules once 2.06-1 is uploaded to the archive: --- debian/rules.orig 2019-12-16 16:48:45.0 +0100 +++ debian/rules2020-02-29 19:40:17.759252139 +0100 @@ -23,10 +23,6 @@ export TARGET_CPPFLAGS := -Wno-unused-but-set-variable export TARGET_LDFLAGS := -no-pie -ifneq (,$(filter sparc sparc64,$(DEB_HOST_ARCH_CPU))) -export TARGET_CCASFLAGS := -fno-PIE -endif - # Ensure that debhelper doesn't try to set these; we need to be careful # about HOST_* vs. TARGET_*. export CPPFLAGS := Before 2.06, the workaround in debian/rules needs to be kept. Thanks, Adrian > [1] > http://git.savannah.gnu.org/cgit/grub.git/commit/?id=c71be831f159ab5b8913132143bdb783a8b4b2a3 --- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#952482: webkit2gtk: Please pass -mlra and -fno-move-loop-invariants on sh4
On 2/26/20 2:40 PM, Alberto Garcia wrote: > Thanks, patch applied. It won't help, unfortunately. Because there is one other source file where the removed optimization won't help. The mlra is necessary in any case and I'm about to switch GCC on sh4 to use LRA by default now. > The sh4 build is currently failing because of this however: > > Running > >'/usr/bin/ninja' '--version' > > failed with: > >Process terminated due to timeout > > But this has nothing to do with this patch, right? Yes, this is completely unrelated and just an artifact which can be ignored. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#902635: Closing due to lack of response.
Control: reopen -1 On 2/26/20 1:09 AM, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! I'm closing this bug due to lack of response. Please feel free to > reopen it or opening a new bug if you can provide us with more > information as required. The issue has not been fixed. Closing a bug without fixing the issue behind it makes no sense. Bug reports are supposed to document issues, closing reports means hiding issues. The issue has not been properly addressed yet because it's fundamentally difficult to fix. The bug is a result of an underlying design problem which is a result of upstream ignoring that the upper 16 address bits in a 64 bit physical address are reserved by Intel. However, they have actually understood the problem now and they are planning to address the problem in the near future since x86_64 and arm64 are expanding their virtual address spaces as well [1]. Thanks, Adrian > [1] https://bugreports.qt.io/browse/QTBUG-56264 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#952525: openjdk-11: Please disable testsuite on sparc64
Source: openjdk-11 Version: 11.0.6+10-2 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! Our buildds for sparc64 have many cores which can result in the OpenJDK testsuite killing the kernel. The problem affects POWER as well, but only under certain conditions (in our case a big-endian VM running on a little-endian host [1]), but we can avoid the issue by restricting the openjdk-NN builds on certain buildds. However, for sparc64, we don't have that possibility, hence the testsuite for all openjdk-NN packages should be disabled until the kernel bug has been fixed. Thanks, Adrian > [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204210.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#952482: webkit2gtk: Please pass -mlra and -fno-move-loop-invariants on sh4
Source: webkit2gtk Version: 2.26.4-1 Severity: normal Tags: patch User: debian-sup...@lists.debian.org Usertags: sh4 Hi! In order for webkit2gtk to build on sh4, it's necessary to enable the new register allocator on sh4 (LRA), see [1, 2]. Also, there is a regression in gcc-9 and gcc-10 that needs one optimization to be disabled as otherwise the compiler will crash with an internal compiler error (ICE) [3]. Please apply the attached patch for the next upload. Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 > [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- webkit2gtk-2.26.4/debian/rules.orig 2020-02-14 14:55:40.0 +0100 +++ webkit2gtk-2.26.4/debian/rules 2020-02-24 23:06:26.482766937 +0100 @@ -37,6 +37,14 @@ EXTRA_CMAKE_ARGUMENTS += -DUSE_LD_GOLD=OFF endif +# Enable the new register allocator on SH and +# disable one particular optimization flag +# See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 +# and: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 +ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4)) +CPPFLAGS += -mlra -fno-move-loop-invariants +endif + ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS))) EXTRA_CMAKE_ARGUMENTS += -DUSE_SYSTEM_MALLOC=ON CPPFLAGS += -DRELEASE_WITHOUT_OPTIMIZATIONS
Bug#949955: RM: aboot -- RoQA; Multiple RC bugs, can no longer be built due to missing alpha buildds
On 2/24/20 9:37 PM, Moritz Mühlenhoff wrote: > On Sun, Feb 02, 2020 at 02:06:12PM +0100, John Paul Adrian Glaubitz wrote: >> Hello! >> >> On 1/29/20 11:49 PM, John Paul Adrian Glaubitz wrote: >>> One of the Gentoo developers has forked aboot and is maintaing it on >>> Github [1]. I have filed an issue regarding the manpage issue and will >>> coordinate a new release of the bootloader with the aforementioned >>> issues addressed. >> >> I have created a pull request now upstream [1] to fix this issue. >> >> Also, I would like to take over the aboot package and plan to modernize >> it the same way as the palo package which is the bootloader for hppa. > > I'm not part of the original maintainers, but given that the last > active maintainer acked the removal, please by all means adopt it! Will upload an updated package within the next days. I had to push some patches upstream first. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#952386: src:libseccomp: please add support for riscv64
On 2/23/20 6:17 PM, Aurelien Jarno wrote: > libseccomp fails to build on riscv64 as the support for this > architecture is missing. It has just been added upstream: > > https://github.com/seccomp/libseccomp/commit/5432e15521d5ce5a7d3f26bf78674cbaa9d73d1f Hmm, I wonder whether I can do this for m68k and sparc64 as well. But I assume this also requires support in the kernel, doesn't it? I think Helge added support for it for hppa? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#951496: libffi: libffi 3.3 breaks OpenJDK Zero on powerpc
Control: tags -1 +patch Hi! On 2/17/20 2:08 PM, John Paul Adrian Glaubitz wrote: > Once the issue has been fixed and this bug is closed, I will mark the package > for > building again on powerpc. Upstream has fixed the problem now [1], attaching the patch. I have not actually tested yet whether the patch fixes the problem. Adrian > [1] > https://github.com/libffi/libffi/commit/4d6d2866ae43e55325e8ee96561221804602cd7a -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From 4d6d2866ae43e55325e8ee96561221804602cd7a Mon Sep 17 00:00:00 2001 From: Samuel Holland Date: Fri, 21 Feb 2020 21:06:15 -0600 Subject: [PATCH] Update powerpc sysv assembly for ffi_powerpc.h changes (#541) Some of the flag bits were moved when adding powerpc64 vector support. Fixes #536 --- src/powerpc/sysv.S | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/src/powerpc/sysv.S b/src/powerpc/sysv.S index 1474ce70..df977342 100644 --- a/src/powerpc/sysv.S +++ b/src/powerpc/sysv.S @@ -104,17 +104,16 @@ ENTRY(ffi_call_SYSV) bctrl /* Now, deal with the return value. */ - mtcrf 0x01,%r31 /* cr7 */ + mtcrf 0x03,%r31 /* cr6-cr7 */ bt- 31,L(small_struct_return_value) bt- 30,L(done_return_value) #ifndef __NO_FPRS__ bt- 29,L(fp_return_value) #endif stw %r3,0(%r30) - bf+ 28,L(done_return_value) + bf+ 27,L(done_return_value) stw %r4,4(%r30) - mtcrf 0x02,%r31 /* cr6 */ - bf 27,L(done_return_value) + bf 26,L(done_return_value) stw %r5,8(%r30) stw %r6,12(%r30) /* Fall through... */ @@ -145,10 +144,9 @@ L(done_return_value): #ifndef __NO_FPRS__ L(fp_return_value): .cfi_restore_state - bf 28,L(float_return_value) + bf 27,L(float_return_value) stfd %f1,0(%r30) - mtcrf 0x02,%r31 /* cr6 */ - bf 27,L(done_return_value) + bf 26,L(done_return_value) stfd %f2,8(%r30) b L(done_return_value) L(float_return_value):
Bug#951774: openjdk-11: Please disable jhsdb for sh4 in debian/rules
Source: openjdk-11 Version: 11.0.6+10-2 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 Hi! I was just manually bootstrapping openjdk-11 for sh4 after it hasn't been building for a while. At the end, the build failed with dh-install complaining about jhsdb missing: dh_install --sourcedir=debian/tmp -XLICENSE dh_install: warning: Cannot find (any matches for) "usr/lib/jvm/java-11-openjdk-sh4/bin/jhsdb" (tried in debian/tmp, debian/tmp) dh_install: warning: openjdk-11-jdk-headless missing files: usr/lib/jvm/java-11-openjdk-sh4/bin/jhsdb dh_install: error: missing files, aborting make: *** [debian/rules:1223: install] Error 25 So, I guess we need to add sh4 to the list of architectures where jhsdb isn't build. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#951732: fails to show UI on gnome
Hi! On 2/21/20 10:55 AM, Markus Frosch wrote: > Am Donnerstag, den 20.02.2020, 22:48 +0100 schrieb Lee Garrett: >> Found the minimum hard deps needed: >> >> qml-module-qtquick-controls2 >> qml-module-qtqml-models2 >> >> Adrian, please add those two as hard deps to ausweisapp2. > > I can confirm this fixes problems with the new UI not working correctly. Thanks. I will verify that on a clean system in the weekend and upload a fixed version. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#951732: fails to show UI on gnome
Hi Lee! On 2/20/20 9:58 PM, Lee Garrett wrote: > I'm trying to run ausweisapp2 on gnome. I tried running it via terminal, > and also get terminal output. But it's impossible for me to get it to show an > UI. Running > it again on another terminal will create the following output on the first > one: > > (...) > > So it seems like it *should* be raised somewhere, but still no UI visible. > > At the start of ausweisapp2 following output was shown: > > Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use > QT_QPA_PLATFORM=wayland to run on Wayland anyway. > > For the fun of it, I installed qtwayland5 and tried running it with: > > QT_QPA_PLATFORM=wayland AusweisApp2 > > However, the problem still persists (no GUI). Did you try running it on KDE on your machine? > I tried authenticating in on a German government site via ausweisapp2, but the > connection stalls, and eventually times out. I'm assuming that the GUI is > waiting for some kind of confirmation, or the PIN. Normally the app should be put in the foreground so you can enter your PIN and that worked for me on KDE when I tried it. I did not test it on GNOME though. > It would be great if we could get it to also work on gnome, I'm assuming it > works on other DEs. I would suggest asking upstream. I can put one of the developers in the loop. > Thanks for packaging ausweisapp2! Sure. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#951714: ruby2.5: Please include small workaround to fix the build on sh4
Source: ruby2.5 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 Hello! Due to a compiler bug in gcc-9 and newer, ruby2.5 (and ruby2.7) currently gets miscompiled and crashes with an 'Illegal Instruction' error [1]. The problem can be easily worked around by passing -fno-crossjumping through CFLAGS to the compiler. Could you include the small attached workaround in the next upload of ruby2.5 (and ruby2.7) to fix the build on sh4 until the compiler bug has been fixed upstream? diff -Nru old/ruby2.5-2.5.7/debian/rules new/ruby2.5-2.5.7/debian/rules --- old/ruby2.5-2.5.7/debian/rules 2019-10-23 17:48:04.0 +0200 +++ new/ruby2.5-2.5.7/debian/rules 2020-02-20 15:17:13.910784900 +0100 @@ -55,6 +55,11 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow configure_options += $(shell dpkg-buildflags --export=configure) +# See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 +ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4)) +export DEB_CFLAGS_MAINT_APPEND += -fno-crossjumping +endif + # Always build with /bin/bash, to get consistent rbconfig.rb (which embeds SHELL). export SHELL := /bin/bash Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/ruby2.5-2.5.7/debian/rules new/ruby2.5-2.5.7/debian/rules --- old/ruby2.5-2.5.7/debian/rules 2019-10-23 17:48:04.0 +0200 +++ new/ruby2.5-2.5.7/debian/rules 2020-02-20 15:17:13.910784900 +0100 @@ -55,6 +55,11 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow configure_options += $(shell dpkg-buildflags --export=configure) +# See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 +ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4)) +export DEB_CFLAGS_MAINT_APPEND += -fno-crossjumping +endif + # Always build with /bin/bash, to get consistent rbconfig.rb (which embeds SHELL). export SHELL := /bin/bash
Bug#951709: /boot should get a bigger share of disk in default installation
On 2/20/20 2:20 PM, Pirate Praveen wrote: > With initrd around 60+ MBs, 236 MB /boot in a 300 GB hard disk can hold only > 2 versions > of the kernels at the same time. When installing a 3rd kernel /boot gets > filled up. Please note that the default partition layout and hence the size of /boot is architecture- specific. Thus, you need to specify the architecture when asking to change the partition sizes. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#951496: libffi: libffi 3.3 breaks OpenJDK Zero on powerpc
Source: libffi Version: 3.3-3 Severity: important Tags: upstream User: debian-powe...@lists.debian.org Usertags: powerpc Hi! Since libffi 3.3 breaks OpenJDK Zero on powerpc [1], I have reverted the breaking changes in a manual upload (3.3-3+powerpc) in Debian Ports and have set the package to "not-for-us" until the issue has been fixed upstream. Once the issue has been fixed and this bug is closed, I will mark the package for building again on powerpc. Thanks, Adrian > [1] https://github.com/libffi/libffi/issues/536 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#950974: sqlite3: Regressions on big-endian targets break other packages
Source: sqlite3
Severity: critical
Tags: patch
Justification: breaks unrelated software
User: debian-s...@lists.debian.org
Usertags: s390x
Hi!
Due to a regression in sqlite3, git has been failing to build from source
on multiple big-endian targets, including the release target s390x [1].
openSUSE has recently cherry-picked two upstream commits which address
this issue [2, 3, 4] and I have verified that these patches fix git
in Debian on ppc64 (and I assume s390x and sparc64 as well). Thus, please
include these patches to unbreak git on ppc64, sparc64 and s390x.
Severity set to 'critical' as this bug breaks unrelated software.
Attaching the two patches taken from openSUSE.
Thanks,
Adrian
> [1] https://marc.info/?l=git=158120991004802=2
> [2]
> https://build.opensuse.org/package/rdiff/server:database/sqlite3?linkrev=base=241
> [3] https://sqlite.org/src/info/04885763c4cd00cb
> [4] https://sqlite.org/src/info/b20503aaf5b6595a
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: ext/fts5/test/fts5matchinfo.test
==
--- ext/fts5/test/fts5matchinfo.test
+++ ext/fts5/test/fts5matchinfo.test
@@ -498,23 +498,26 @@
CREATE VIRTUAL TABLE t1 USING fts5(x, y);
INSERT INTO t1 VALUES('a', 'b');
INSERT INTO t1 VALUES('c', 'd');
}
+if {$tcl_platform(byteOrder)=="littleEndian"} {
+ set res {X'0200'}
+} else {
+ set res {X'0002'}
+}
do_execsql_test 15.1 {
SELECT quote(matchinfo(t1, 'n')) FROM t1 LIMIT 1;
-} {X'0200'}
-
+} $res
do_execsql_test 15.2 {
DELETE FROM t1_content WHERE rowid=1;
SELECT quote(matchinfo(t1, 'n')) FROM t1 LIMIT 1;
-} {X'0200'}
+} $res
fts5_aux_test_functions db
do_execsql_test 15.3 {
SELECT fts5_test_all(t1) FROM t1 LIMIT 1;
} {
{columnsize {0 0} columntext {c d} columntotalsize {2 2} poslist {} tokenize
{c d} rowcount 2}
}
finish_test
-
Index: test/fts4aa.test
==
--- test/fts4aa.test
+++ test/fts4aa.test
@@ -227,17 +227,22 @@
} {1 {database disk image is malformed}}
# 2019-11-18 https://bugs.chromium.org/p/chromium/issues/detail?id=1025467
db close
sqlite3 db :memory:
+if {$tcl_platform(byteOrder)=="littleEndian"} {
+ set res
{X'02000E000E000100010001000100'}
+} else {
+ set res
{X'0002000E000E0001000100010001'}
+}
do_execsql_test fts4aa-6.10 {
CREATE VIRTUAL TABLE f USING fts4();
INSERT INTO f_segdir VALUES (77,91,0,0,'255
77',x'000130804d5c4ddd4d4d7b4d4d4d614d8019ff4d0501204d4d2e4d6e4d4d4d4b4d6c4d004d4d4d4d4d4d3d4d5d4d4d645d4d004d4d4d4d4d4d4d4d4d454d6910004d05054d646c4d004d5d4d4d4d4d3d4d4d4d4d4d4d4d4d4d4d4d69624d4d4d04004d4d4d4d4d604d4ce1404d554d45');
INSERT INTO f_segdir VALUES (77,108,0,0,'255
77',x'000131fa64004d4d4d3c5d4d654d4d4d614d8000ff4d0501204d4d2e4d6e4d4d4dff4d4d4d4d4d4d00104d4d4d4d4d4d4d0400311d4d4d4d4d4d4d4d4d4d684d6910004d05054d4d6c4d004d4d4d4d4d4d3d4d4d4d4d644d4d4d4d4d4d69624d4d4d03ed4d4d4d4d4d604d4ce1404d550080');
INSERT INTO f_stat VALUES
(0,x'808080801064004d4d4d3c4d4d654d4d4d614d8000ff4df6ff1a00204d4d2e4d6e4d4d4d104d4d4d4d4d4d00104d4d4d4d4d4d69574d4d4d31044d4d4d3e4d4d4c4d05004d6910');
SELECT quote(matchinfo(f,'pnax')) from f where f match '0 1';
-} {X'02000E000E000100010001000100'}
+} $res
# 2019-11-18 Detect infinite loop in fts3SelectLeaf()
db close
sqlite3 db :memory:
do_catchsql_test fts4aa-7.10 {
Index: src/insert.c
==
--- src/insert.c
+++ src/insert.c
@@ -2168,16 +2168,18 @@
** Hence, make a complete copy of the opcode, rather than using
** a pointer to the opcode. */
x = *sqlite3VdbeGetOp(v, addrConflictCk);
if( x.opcode!=OP_IdxRowid ){
int p2; /* New P2 value for copied conflict check opcode */
+ const char *zP4;
if( sqlite3OpcodeProperty[x.opcode]_JUMP ){
p2 = lblRecheckOk;
}else{
p2 = x.p2;
}
- sqlite3VdbeAddOp4(v, x.opcode, x.p1, p2, x.p3, x.p4.z, x.p4type);
+ zP4 = x.p4type==P4_INT32 ? SQLITE_INT_TO_PTR(x.p4.i) : x.p4.z;
+ sqlite3VdbeAddOp4(v, x.opcode, x.p1, p2, x.p3, zP4, x.p4type);
sqlite3VdbeChangeP5(v, x.p5);
VdbeCoverageIf(v, p2!=x.p2);
}
nConflictCk--;
addrConflictCk++;
Bug#950950: hamlib: Please include patch to fix unaligned access in dummy/dummy.c
Source: hamlib Version: 3.3-8 Severity: normal Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! The attached patch fixes an unaligned access in dummy_get_level() which resulted in the testsuite crashing on sparc64 [1]. I have opened a pull request upstream as well to address the issue [2], so carrying the patch should hopefully not be necessary in the future. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=hamlib=sparc64=3.3-8=1580780480=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 dummy/dummy.c: Fix unaligned access in dummy_get_level() This fixes an unaligned access in dummy/dummy.c in the function dummy_get_level() which resulted in crashes (Bus Error) on systems with stricter alignment requirements such as SPARC. On x86_64 (and any other architecture with less strict alignment requirements), the compiler automatically optimizes the memcpy() out if necessary such that there are no performance issues. --- hamlib-3.3.orig/dummy/dummy.c +++ hamlib-3.3/dummy/dummy.c @@ -834,7 +834,7 @@ static int dummy_get_level(RIG *rig, vfo } } - *val = curr->levels[idx]; + memcpy (val, >levels[idx], sizeof(value_t)); rig_debug(RIG_DEBUG_VERBOSE,"%s called: %s\n",__FUNCTION__, rig_strlevel(level));
Bug#950591: O: aboot
Control: retitle -1 ITA: aboot Control: owner -1 ! Changing to ITA and setting myself as owner. My pull request to switch to docbook-utils for aboot has been merged [1] upstream in the meantime. Thanks, Adrian > [1] > https://github.com/mattst88/aboot/commit/45004d6e3e26f385469c150989d51159cd33c802 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#950653: guile-3.0: Please include patch to fix build on ia64
Source: guile-3.0
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64
Hi!
Similar to hppa, the build of guile-3.0 is currently failing on ia64 due to
a regression.
I have created a patch to fix the issue and submitted it upstream [1].
Please include it in the next upload.
Thanks,
Adrian
> [1] https://lists.gnu.org/archive/html/guile-devel/2020-02/msg00022.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From 48bf85af0f02111a0e075b8128f4acefaf43eec0 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Tue, 4 Feb 2020 13:30:09 +0100
Subject: [PATCH] Fix build on ia64
* libguile/continuations.c (capture_auxiliary_stack): Fix
logic in preprocessor code when checking for ia64 host;
fix dereferencing of ctx variable.
* libguile/threads.h (struct scm_thread): Add missing member
SCM_STACKITEM *auxiliary_stack_base.
---
libguile/continuations.c | 6 +++---
libguile/threads.h | 5 +
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/libguile/continuations.c b/libguile/continuations.c
index 67a47d38c..b8b6e1dca 100644
--- a/libguile/continuations.c
+++ b/libguile/continuations.c
@@ -143,7 +143,7 @@ static void
capture_auxiliary_stack (scm_thread *thread, scm_t_contregs *continuation)
{
#if SCM_HAVE_AUXILIARY_STACK
-# if !(defined __ia64 or defined __ia64__)
+# if !defined __ia64 || !defined __ia64__
# error missing auxiliary stack implementation for architecture
# endif
char *top;
@@ -155,9 +155,9 @@ capture_auxiliary_stack (scm_thread *thread, scm_t_contregs
*continuation)
#if defined __hpux
__uc_get_ar_bsp (ctx, (uint64_t *) );
#elif defined linux
- top = (char *) ctx->uc_mcontext.sc_ar_bsp;
+ top = (char *) ctx.uc_mcontext.sc_ar_bsp;
#elif defined __FreeBSD__
- top = (char *)(ctx->uc_mcontext.mc_special.bspstore
+ top = (char *)(ctx.uc_mcontext.mc_special.bspstore
+ ctx->uc_mcontext.mc_special.ndirty);
#else
#error missing auxiliary stack implementation for ia64 on this OS
diff --git a/libguile/threads.h b/libguile/threads.h
index 337dc83a9..e6a60e96b 100644
--- a/libguile/threads.h
+++ b/libguile/threads.h
@@ -118,6 +118,11 @@ struct scm_thread {
/* Stack base. Used when checking for C stack overflow. */
SCM_STACKITEM *base;
+#if SCM_HAVE_AUXILIARY_STACK
+ /* Auxiliary stack base. */
+ SCM_STACKITEM *auxiliary_stack_base;
+#endif
+
/* JIT state; NULL until this thread needs to JIT-compile something. */
struct scm_jit_state *jit_state;
};
--
2.25.0
Bug#950635: guile-3.0: Please include patch to fix build on hppa
Source: guile-3.0 Severity: normal Tags: patch User: debian-h...@lists.debian.org Usertags: hppa Hi! The build of guile-3.0 on hppa currently fails with: continuations.c: In function 'scm_dynthrow': continuations.c:326:5: error: too few arguments to function 'grow_stack' 326 | grow_stack (cont); | ^~ continuations.c:276:1: note: declared here 276 | grow_stack (SCM cont, uint8_t *mra) | ^~ make[4]: *** [Makefile:2857: libguile_3.0_la-continuations.lo] Error 1 This is a regression in 3.0 and simply fixed by the attached patch which I have also sent upstream [2]. Please include it in the next upload. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=guile-3.0=hppa=3.0.0%2B1-1=1580702308=0 > [2] https://lists.gnu.org/archive/html/guile-devel/2020-02/msg00017.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From 9081d45472709b27f36a6b7f4be47e88f956a190 Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz Date: Tue, 4 Feb 2020 12:12:24 +0100 Subject: [PATCH] Fix build of platforms where the stack grows upwards * libguile/continuations.c (scm_dynthrow): Fix missing mra parameter to grow_stack for SCM_STACK_GROWS_UP. --- libguile/continuations.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libguile/continuations.c b/libguile/continuations.c index 3f86c6bd4..67a47d38c 100644 --- a/libguile/continuations.c +++ b/libguile/continuations.c @@ -323,7 +323,7 @@ scm_dynthrow (SCM cont, uint8_t *mra) #if SCM_STACK_GROWS_UP if (dst + continuation->num_stack_items >= _top_element) -grow_stack (cont); +grow_stack (cont, mra); #else dst -= continuation->num_stack_items; if (dst <= _top_element) -- 2.25.0
Bug#950591: O: aboot
Package: wnpp Severity: normal User: debian-al...@lists.debian.org Usertags: alpha Hi! I am orphaning aboot on behalf of the current maintainer now as he has agreed on removing the package [1]. I would like to adopt aboot and address the open RC bugs so it can be kept in the main archive. This way we don't have to upload the package to the Debian Ports unreleased archive in order to be able to build installation images for the alpha architecture. I will update the package to use the fork of aboot that is being maintained by a Gentoo developer on Github [2]. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949711#10 > [2] https://github.com/mattst88/aboot -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#949955: RM: aboot -- RoQA; Multiple RC bugs, can no longer be built due to missing alpha buildds
Hello! On 1/29/20 11:49 PM, John Paul Adrian Glaubitz wrote: > One of the Gentoo developers has forked aboot and is maintaing it on > Github [1]. I have filed an issue regarding the manpage issue and will > coordinate a new release of the bootloader with the aforementioned > issues addressed. I have created a pull request now upstream [1] to fix this issue. Also, I would like to take over the aboot package and plan to modernize it the same way as the palo package which is the bootloader for hppa. Adrian > [1] https://github.com/mattst88/aboot/pull/2 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#936566: fs-uae: Python2 removal in sid/bullseye - reopen 936566
On 1/31/20 6:34 AM, Sandro Tosi wrote: >> On 1/19/20 3:23 AM, Sandro Tosi wrote: >>> This bug was closed, but the package has still some dependencies towards >>> Python2 packages, in details: >>> >>> (binary:fs-uae-arcade)Recommends->python-lhafile >> >> FWIW, a Recommends is not the same as a Dependency meaning that >> if a Recommends is not available it won't get installed. > > hm are you sure you're not mixing Recommends and Suggests? also note > that Recommends are installed by default nowadays. Yes, I'm sure. As I said, python-lhafile isn't even in the archive and fs-uae installs fine. This is actually the reason why I missed this part. >> And, secondly, python-lhafile was never part of Debian. The Recommends >> he is just an artifact from the upstream packaging code. It was never >> used in any way. >> >>> Re-opening, so that they can be taken care of. >> >> I understand. But I don't this the severity "serious" is justified >> in this case. > > ok, can you fix it then? you make it sound pretty easy so can you just > go ahead and address it? as per the severity, please check the > reference in the first severity bump email. I will address it the next days. I wanted to check first whether it would make sense to include a Python3-version of the package. I'm also very busy with work. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#936566: fs-uae: Python2 removal in sid/bullseye - reopen 936566
Hello! Thanks for notifying me. On 1/19/20 3:23 AM, Sandro Tosi wrote: > This bug was closed, but the package has still some dependencies towards > Python2 packages, in details: > > (binary:fs-uae-arcade)Recommends->python-lhafile FWIW, a Recommends is not the same as a Dependency meaning that if a Recommends is not available it won't get installed. And, secondly, python-lhafile was never part of Debian. The Recommends he is just an artifact from the upstream packaging code. It was never used in any way. > Re-opening, so that they can be taken care of. I understand. But I don't this the severity "serious" is justified in this case. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#949955: RM: aboot -- RoQA; Multiple RC bugs, can no longer be built due to missing alpha buildds
Hi again! One of the Gentoo developers has forked aboot and is maintaing it on Github [1]. I have filed an issue regarding the manpage issue and will coordinate a new release of the bootloader with the aforementioned issues addressed. I didn't know about these RC bugs otherwise I would have reacted earlier. Adrian > [1] https://github.com/mattst88/aboot -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#949955: RM: aboot -- RoQA; Multiple RC bugs, can no longer be built due to missing alpha buildds
> Please remove aboot. It blocks the sgmltools-lite removal and is RC-buggy > otherwise for a last > time (like for the removal of sp). Steve Langasek pointed out as one of the > last alpha maintainers > in #949711 that the arch: all binaries can only be built on an alpha buildd, > which we no longer > have, so let's remove it. Why was the debian-alpha mailing list not CC'ed so that people can look into the issue? I'm pretty sure it's not impossible to get rid of the SGML dependency and bootloaders can also be cross-built in Debian, we're doing that for palo as well. I will look into this issue. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#950192: Please remove build dep on aboot
On 1/29/20 11:09 PM, Moritz Muehlenhoff wrote: > Package: debian-installer > Severity: important > > aboot has a open RC bug (#949955), but d-i still build depends on it. alpha > isn't a release > arch for a long time anyway. Huh? That should be a Build-Dependency with [alpha] only anyway. I will look at that in a minute, just need to reboot. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#949595: cockpit: Please include patch to fix build on sparc64
Hi! On 1/24/20 11:34 AM, Martin Pitt wrote: > John Paul Adrian Glaubitz [2020-01-22 16:40 +0100]: >> cockpit FTBFS on sparc64 due to unaligned access. The attached package fixes >> it. I have also forwarded the issue upstream [1]. > > Thanks a lot Adrian for tracking this down! The fix landed upstream and thus > will be part of 212. Great, thank you. FWIW, I'm going to update the openSUSE package as well while I'm at it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
