Bug#1052144: ghc: Needs to link against libatomic on at least m68k
Control: tags -1 +patch
Hi!
The attached patch fixes the issue for me. The underlying problem is
the use of legacy atomic functions for which no 64-bit variants exist
on some architectures [1]. See also the upstream discussion here [2].
While this patch fixes the original problem, the stage2 build later
fails due to memory exhaustion for which I haven't found a solution
yet.
Thanks,
Adrian
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/23974
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: ghc-9.4.6/libraries/ghc-prim/cbits/atomic.c
===
--- ghc-9.4.6.orig/libraries/ghc-prim/cbits/atomic.c
+++ ghc-9.4.6/libraries/ghc-prim/cbits/atomic.c
@@ -291,28 +291,28 @@ extern StgWord hs_cmpxchg8(StgWord x, St
StgWord
hs_cmpxchg8(StgWord x, StgWord old, StgWord new)
{
- return __sync_val_compare_and_swap((volatile StgWord8 *) x, (StgWord8) old, (StgWord8) new);
+ return __atomic_compare_exchange((volatile StgWord8 *) x, (StgWord8 *) , (StgWord8 *) , false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}
extern StgWord hs_cmpxchg16(StgWord x, StgWord old, StgWord new);
StgWord
hs_cmpxchg16(StgWord x, StgWord old, StgWord new)
{
- return __sync_val_compare_and_swap((volatile StgWord16 *) x, (StgWord16) old, (StgWord16) new);
+ return __atomic_compare_exchange((volatile StgWord16 *) x, (StgWord16 *) , (StgWord16 *) , false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}
extern StgWord hs_cmpxchg32(StgWord x, StgWord old, StgWord new);
StgWord
hs_cmpxchg32(StgWord x, StgWord old, StgWord new)
{
- return __sync_val_compare_and_swap((volatile StgWord32 *) x, (StgWord32) old, (StgWord32) new);
+ return __atomic_compare_exchange((volatile StgWord32 *) x, (StgWord32 *) , (StgWord32 *) , false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}
extern StgWord hs_cmpxchg64(StgWord x, StgWord64 old, StgWord64 new);
StgWord
hs_cmpxchg64(StgWord x, StgWord64 old, StgWord64 new)
{
- return __sync_val_compare_and_swap((volatile StgWord64 *) x, old, new);
+ return __atomic_compare_exchange((volatile StgWord64 *) x, (StgWord64 *) , (StgWord64 *) , false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}
// Atomic exchange operations
Bug#1052382: sysprof: Should not build-depend on libunwind-dev on unsupported architectures
Source: sysprof Version: 45.0-1 Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello! src:sysprof build-depends on libunwind-dev unconditionally despite the fact that libunwind is not available on the following architectures: - alpha - arc - hurd-i386 - m68k - sparc64 - x32 NB: While libunwind is currently not built on loong64, upstream support is already present and it's therefore expected that libunwind will be available on loong64 in the near future. Can you please disable libunwind for the architectures mentioned above? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hello! I have been bisecting this issue but in order to be successful, I need a simple reproducer which isn't trivial since I cannot just reuse the build directory of an unsuccessful build due to the changing Haskell libraries for different GHC versions. Ideally, we should have a single command line with GHC which will trigger the segmentation fault. To bisect, I have done the following: # git bisect start # git bisect good ghc-8.10.7-release # git bisect bad ghc-9.2.7-release # git submodule update --init # ./boot ; python3 boot # echo "SRC_HC_OPTS += -lffi -latomic -optl-pthread" >> mk/build.mk && \ echo "Stage1Only := YES" >> mk/build.mk && \ echo 'utils/genprimopcode_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo 'compiler_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo 'utils/hpc_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo "HADDOCK_DOCS := NO" >> mk/build.mk \ && echo "BUILD_SPHINX_HTML := NO" >> mk/build.mk && echo "BUILD_SPHINX_PDF := NO" \ >> mk/build.mk # ./configure && make -j32 For newer versions, the build has to be performed with Hadrian, so the last step would be: # ./hadrian/build -j Prior to using Hadrian for the first time, the package database needs to be updated: # cabal update Now, if I had a simple reproducer, it would be rather easy to bisect the issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1052144: ghc: Needs to link against libatomic on at least m68k
Source: ghc Version: 9.4.6-1 Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello! On m68k, building ghc fails with: "inplace/bin/ghc-stage1" -o utils/iserv/stage2_p/build/tmp/ghc-iserv-prof -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -H32m -O -lffi -optl-pthread -Wall -hide-all-packages -package-env - -i -iutils/iserv/src -iutils/iserv/stage2_p/build -Iutils/iserv/stage2_p/build -iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/. -Iutils/iserv/stage2_p/build/. -optP-include -optPutils/iserv/stage2_p/build/iserv/autogen/cabal_macros.h -package-id array-0.5.4.0 -package-id base-4.17.2.0 -package-id binary-0.8.9.1 -package-id bytestring-0.11.5.1 -package-id containers-0.6.7 -package-id deepseq-1.4.8.0 -package-id ghci-9.4.6 -package-id libiserv-9.4.6 -package-id unix-2.7.3 -no-hs-main -XHaskell2010 -threaded -optl-Wl,--export-dynamic -no-hs-main -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -outputdir utils/iserv/stage2_p/build -split-sections -static -prof -H32m -O -lffi -optl-pthread -Wall -hide-all-packages -package-env - -i -iutils/iserv/src -iutils/iserv/stage2_p/build -Iutils/iserv/stage2_p/build -iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/. -Iutils/iserv/stage2_p/build/. -optP-include -optPutils/iserv/stage2_p/build/iserv/autogen/cabal_macros.h -package-id array-0.5.4.0 -package-id base-4.17.2.0 -package-id binary-0.8.9.1 -package-id bytestring-0.11.5.1 -package-id containers-0.6.7 -package-id deepseq-1.4.8.0 -package-id ghci-9.4.6 -package-id libiserv-9.4.6 -package-id unix-2.7.3 -no-hs-main -XHaskell2010 -threaded -optl-Wl,--export-dynamic -no-hs-main -no-user-package-db -rtsopts -Wnoncanonical-monad-instances utils/iserv/stage2_p/build/Main.p_o utils/iserv/stage2_p/build/cbits/iservmain.p_o Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld.bfd: /<>/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.9.1_p.a(atomic.p_o): in function `hs_cmpxchg64': atomic.c:(.text.hs_cmpxchg64+0x16): undefined reference to `__sync_val_compare_and_swap_8' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) make[2]: *** [utils/iserv/ghc.mk:104: utils/iserv/stage2_p/build/tmp/ghc-iserv-prof] Error 1 make[2]: *** Waiting for unfinished jobs which indicates that the build needs to link against libatomic. This issue has also been reported upstream [1]. Thanks, Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23974 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1052142: ghc: Please add patch to restore minimal build support for sparc and sparc64
Source: ghc Version: 9.4.6-1 Severity: normal Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! When upstream dropped NGC support for SPARC, they also accidentally removed build support for unregisterised builds by removing sparc* and sparc64* from m4/ghc_convert_cpu.m4 and m4/fptools_set_haskell_platform_vars.m4 meaning that building on sparc64 is no longer possible. The attached patch re-adds sparc and sparc64 to re-enable builds. The problem has also been reported upstream [1]. Thanks, Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23959 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Index: ghc-9.4.6/m4/ghc_convert_cpu.m4 === --- ghc-9.4.6.orig/m4/ghc_convert_cpu.m4 +++ ghc-9.4.6/m4/ghc_convert_cpu.m4 @@ -68,6 +68,12 @@ case "$1" in sh4) $2="sh4" ;; + sparc64*) +$2="sparc64" +;; + sparc*) +$2="sparc" +;; vax) $2="vax" ;; Index: ghc-9.4.6/m4/fptools_set_haskell_platform_vars.m4 === --- ghc-9.4.6.orig/m4/fptools_set_haskell_platform_vars.m4 +++ ghc-9.4.6/m4/fptools_set_haskell_platform_vars.m4 @@ -42,7 +42,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V riscv64) test -z "[$]2" || eval "[$]2=ArchRISCV64" ;; -hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|vax) +hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|sparc|sparc64|vax) test -z "[$]2" || eval "[$]2=ArchUnknown" ;; *)
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi! Note that this issue also prevents us from building the latest version of the GHC compiler [1]. I have tried to cross-compile GHC 9.4.6 to work around this issue and also tried building an unregisterised compiler. Both without success. I have forwarded the issue upstream [2]. I think the only way forward will be to bisect the problem unless a GHC expert can figure out what the problem is. Adrian > [1] https://buildd.debian.org/status/package.php?p=ghc=sid > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/23969 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051966: icmake: Please add bootstrap build profile to break circular build dependency
Source: icmake Version: 10.04.01-2 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! The changelog entry for icmake 10.03.02-1 reads: * New upstream version 10.03.02 adds bobcatbootstrap to build icmake on systems that haven't installed the bobcat library However, looking at debian/control, the build dependency on libbobcat-dev is actually unconditional and there is currently no way to build the icmake Debian package without having libbobcat-dev installed. This is in particular problematic because src:bobcat build-depends on icmake to build. A build profile which allows to disable the libbobcat-dev build dependency temporarily and use the aforementioned bootstrap mechanism would be very helpful for bootstrapping icmake on new architectures such as loong64. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051931: obs-studio: Please use whitelist for libluajit-5.1-dev build dependency
Source: obs-studio
Version: 29.1.3+dfsg-2
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org
Hello!
src:obs-studio currently only blacklists ppc64el in debian/control in its
build dependencies [1] while luajit is missing on many architectures [2].
Thus, it would make sense to use a whitelist for the libluajit-5.1-dev
build dependency in debian/control and also adjust debian/rules accordingly:
diff -Nru old/obs-studio-29.1.3+dfsg/debian/control
new/obs-studio-29.1.3+dfsg/debian/control
--- old/obs-studio-29.1.3+dfsg/debian/control 2023-08-02 13:39:19.0
+0200
+++ new/obs-studio-29.1.3+dfsg/debian/control 2023-09-14 14:02:58.869380395
+0200
@@ -27,7 +27,7 @@
libfreetype-dev,
libjack-jackd2-dev,
libjansson-dev,
- libluajit-5.1-dev [!ppc64el],
+ libluajit-5.1-dev [amd64 arm64 armel armhf hurd-i386 i386 mips64el s390x],
libmbedtls-dev,
libopengl-dev,
libpci-dev,
diff -Nru old/obs-studio-29.1.3+dfsg/debian/rules
new/obs-studio-29.1.3+dfsg/debian/rules
--- old/obs-studio-29.1.3+dfsg/debian/rules 2023-08-02 13:39:19.0
+0200
+++ new/obs-studio-29.1.3+dfsg/debian/rules 2023-09-14 14:02:41.005436844
+0200
@@ -18,7 +18,7 @@
confflags += -DOBS_VERSION_OVERRIDE=$(subst +dfsg,.1,$(DEB_VERSION))
confflags += -DAPPDATA_RELEASE_DATE=$(shell date --utc
--date=@$${SOURCE_DATE_EPOCH} +'%Y-%m-%d')
-ifeq (ppc64el,$(DEB_HOST_ARCH))
+ifeq (,$(filter amd64 arm64 armel armhf hurd-i386 i386 mips64el s390x,
$(DEB_HOST_ARCH)))
confflags += -DENABLE_SCRIPTING_LUA=OFF
endif
I have attached the patch as a file as well.
Thanks,
Adrian
> [1]
> https://salsa.debian.org/multimedia-team/obs-studio/-/blob/master/debian/control#L30
> [2] https://buildd.debian.org/status/package.php?p=luajit=sid
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff -Nru old/obs-studio-29.1.3+dfsg/debian/control
new/obs-studio-29.1.3+dfsg/debian/control
--- old/obs-studio-29.1.3+dfsg/debian/control 2023-08-02 13:39:19.0
+0200
+++ new/obs-studio-29.1.3+dfsg/debian/control 2023-09-14 14:02:58.869380395
+0200
@@ -27,7 +27,7 @@
libfreetype-dev,
libjack-jackd2-dev,
libjansson-dev,
- libluajit-5.1-dev [!ppc64el],
+ libluajit-5.1-dev [amd64 arm64 armel armhf hurd-i386 i386 mips64el s390x],
libmbedtls-dev,
libopengl-dev,
libpci-dev,
diff -Nru old/obs-studio-29.1.3+dfsg/debian/rules
new/obs-studio-29.1.3+dfsg/debian/rules
--- old/obs-studio-29.1.3+dfsg/debian/rules 2023-08-02 13:39:19.0
+0200
+++ new/obs-studio-29.1.3+dfsg/debian/rules 2023-09-14 14:02:41.005436844
+0200
@@ -18,7 +18,7 @@
confflags += -DOBS_VERSION_OVERRIDE=$(subst +dfsg,.1,$(DEB_VERSION))
confflags += -DAPPDATA_RELEASE_DATE=$(shell date --utc
--date=@$${SOURCE_DATE_EPOCH} +'%Y-%m-%d')
-ifeq (ppc64el,$(DEB_HOST_ARCH))
+ifeq (,$(filter amd64 arm64 armel armhf hurd-i386 i386 mips64el s390x,
$(DEB_HOST_ARCH)))
confflags += -DENABLE_SCRIPTING_LUA=OFF
endif
Bug#1051842: gensio: FTBFS: error: some symbols or patterns disappeared in the symbols file
Hi! On Wed, 2023-09-13 at 18:53 +0200, Marc Haber wrote: > thanks for your bug report. I have manually applied the patch (the file > had developed further in git). > > I don't quite understand your hints about riscvi, which might be > connected to my current personal stress level which makes it hard to > concentrate for me at the moment. I apologize for that. > > I would also like to suggest that you use wdiff for symbols files > differences, wdiff can mark changes inside long lines which makes it > easier to detect a change as "just add loong64 in the list of arches in > this line without doing additional changes". I actually recommend using pkgkde-symbolshelper from the KDE team to work with symbols files [1]. It automatically retrieves build logs and uses them to patch symbols files. This saves a lot of work! Adrian > [1] https://qt-kde-team.pages.debian.net/symbolfiles.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051918: openjdk-22: Please disable testsuite on powerpc
Source: openjdk-22 Version: 22~13ea-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hello! The testsuite on powerpc hangs forever and I had to kill the build process for openjdk-22 already in two cases. Could you please disable the testsuite on powerpc for the time being or add a timeout? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051907: aranym: Please update the outdated config.guess and config.sub to recognize the LoongArch
Hi Dandan! On Thu, 2023-09-14 at 10:33 +0800, zhangdandan wrote: > Please consider update the outdated config.guess and config.sub to > recognize the LoongArch. > Optionally, consider the patch (modify debian/rules) I have attached. > If you have any questions, you can contact me at any time. I'm aware of the problem and I will fix it for the next upload. I was planning to rewrite the debian/rules file anyway and I will probably fix with dh_autoreconf. I was not aware of dh_update_autotools_config, so thanks for the suggestion. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051763: dpkg: Please backport support for loong64 to oldstable and stable
Hi Guillem! On Tue, 2023-09-12 at 22:34 +0200, Guillem Jover wrote: > > In order to be able to add loong64-specific changes to source packages, > > the dpkg version on the infrastructure servers, in particular DAK, > > needs to be able to recognize loong64 in d/control. > > > Since the servers are running oldstable and stable and loong64 support > > was only added to dpkg 1.22.0, > > This was introduced in dpkg 1.21.10, reverted in 1.21.19 and reintroduced > in 1.21.21, but that was after the 1.22.x series had already been branched > (so it got cherry picked from git main at the time, and that's why it > looked like it got introduced only in 1.22.0). Thanks, I wasn't aware of that. > > I would like to ask for loong64 to be backported to the dpkg version > > in oldstable and stable. > > I guess I could backport it to dpkg 1.20.x for oldstable, but if the > infra servers are going to be upgraded soon (at least out of oldstable > to stable), then perhaps there's no point in bothering the release-team > with this? >From the discussions on #debian-devel it seemed that the servers are not going to be upgraded anytime soon, so having this patch backported to oldstable would definitely help speed things up. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051763: dpkg: Please backport support for loong64 to oldstable and stable
Source: dpkg Version: 1.21.22 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hello! In order to be able to add loong64-specific changes to source packages, the dpkg version on the infrastructure servers, in particular DAK, needs to be able to recognize loong64 in d/control. Since the servers are running oldstable and stable and loong64 support was only added to dpkg 1.22.0, I would like to ask for loong64 to be backported to the dpkg version in oldstable and stable. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051754: mpi-defaults: Please enable support for loong64 architecture
Source: mpi-defaults Version: 1.10.10+repack-2 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! We're currently bootstrapping the new architecture loong64 in Debian Ports and while more than 11900 packages have already been built, we still lack many packages. One major blocker is mpi-defaults which currently has no loong64 support and therefore blocks many numeric packages. Adding loong64 does not pose any problems for the archive mirrors as the case of src:postgresql-15 proves which added loong64 to debian/control recently [1]. Thanks, Adrian > [1] > https://salsa.debian.org/postgresql/postgresql/-/commit/644130c26acebe008f94b8d41b86cd500551fc44 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051687: rust-backtrace: Circular build dependency prevents build on new targets
Source: rust-backtrace Version: 0.3.68-2 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hello! It's currently not possible to build src:rust-backtrace on loong64 [1], a new target in Debian, due to a circular dependency which so far I am unable to resolve: rust-backtrace => rust-addr2line => rust-gimli => rust-indexmap => rust-quickcheck \ => rust-env-logger => rust-is-termal => rust-rustix => rust-once-cell \ => rust-parking-lot-core => rust-backtrace I am not sure whether rust-backtrace is the proper package to file the bug against, so please feel free to reassign. Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=rust-backtrace=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051447: wpewebkit: Circular build-dependency on gst-plugins-bad1.0 prevents bootstrap
Hi Alberto! On Fri, 2023-09-08 at 10:38 +, Alberto Garcia wrote: > On Fri, Sep 08, 2023 at 09:18:28AM +0200, John Paul Adrian Glaubitz wrote: > > Could you add a build profile to either src:gst-plugins-bad1.0 or > > src:wpewebkit to allow the packages to be boostrapped on loong64? > > Hi, I just gave this a quick try. > > In theory it should be possible to build wpewebkit without gstreamer > (-DENABLE_WEB_AUDIO=OFF -DENABLE_VIDEO=OFF) but wpewebkit 2.40.5 fails > to build because of a missing definition. > > These kinds of errors are normally not hard to fix but the real > problem is that this no-gstreamer configuration is not tested in any > of the bots, so while I can make 2.40.5 build fine this is likely to > break again in the future. > > I suspect that it's much easier to build gst-plugins-bad without the > WPE plugin, so I would suggest to add the new build profile there. Yes, I figured this out as well. Bootstrapping gst-plugins-bad1.0 with the WPE plugin disabled was rather easy, so I think we should move the bootstrap enabler to this package. > Did you file a separate bug, and if not can you reassign this one? I didn't and, yes, let's reassign this bug to src:gst-plugins-bad1.0. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051447: wpewebkit: Circular build-dependency on gst-plugins-bad1.0 prevents bootstrap
Source: wpewebkit Version: 2.40.5-1 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! src:wpewebkit can currently not be bootstrapped on loong64 since it build-depends on libgstreamer-plugins-bad1.0-dev which is built from src:gst-plugins-bad1.0 which itself build-depends on libwpewebkit-1.1-dev which is built from src:wpewebkit. Thus, currently it's not possible to bootstrap both packages on a new architecture. Could you add a build profile to either src:gst-plugins-bad1.0 or src:wpewebkit to allow the packages to be boostrapped on loong64? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051385: postgresql-15: Please disable LLVM support on loong64 for now
Hi Christoph! On Thu, 2023-09-07 at 10:47 +0200, Christoph Berg wrote: > PG does not support LLVM 16 yet, which seems to be pulled in by > llvm-dev on loong64, while in unstable it's still LLVM 14 (15 should > work as well). But these LLVM versions don't support loong64 yet. > > I'll do a new postgresql-15 upload. I forgot to mention: We need to check with DSA first whether the dpkg version on the DAK server already supports loong64. Otherwise, it could happen that the package gets rejected when you add loong64 to debian/control. Let me get some feedback first. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051385: postgresql-15: Please disable LLVM support on loong64 for now
Source: postgresql-15 Version: 15.4-1 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! While LLVM has already been ported to LoongArch (loong64), PostgreSQL does not support LLVM on this architecture yet. Since this currently results in an FTBFS [1], I would like to ask to disable LLVM on loong64 for the time being. In the meantime, I am going to build postgresql-15 with LLVM disabled manually and I'm going to upload it to unreleased to unblock more packages on the architecture. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=postgresql-15=loong64=15.4-1=1693836164=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051195: libcamera: Building with nodoc build profile results in FTBFS
Source: libcamera Version: 0.1.0-3 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hello! Trying to build src:libcamera with --profile=nodoc currently fails with: debian/rules override_dh_install make[1]: Entering directory '/<>' mv debian/tmp/usr/share/doc/libcamera-0.* debian/tmp/usr/share/doc/libcamera-doc mv: cannot stat 'debian/tmp/usr/share/doc/libcamera-0.*': No such file or directory make[1]: *** [debian/rules:30: override_dh_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:10: binary-arch] Error 2 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 This should be fixable by guarding the following line in debian/rules by testing whether the environment variable DEB_BUILD_PROFILES contains "nodoc": mv debian/tmp/usr/share/doc/libcamera-0.* debian/tmp/usr/share/doc/libcamera-doc Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051191: libsdl2: Please add stage1 profile to disable pipewire for bootstrap
Source: libsdl2 Version: 2.28.3+dfsg-1 Severity: normal Hello! There is currently a circular build-dependency in src:libsdl2 with src:pipewire which makes bootstrapping libsdl2 hard. In order to ease the bootstrap, it would be useful if the build dependency on libpipewire-0.3-dev could be disabled with a build profile. Could you add a "stage1" or "pkg.libsdl2.nopipewire" build profile to src:libsdl2? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051185: libsass: Please update symbols file for loong64
Source: libsas Version: 3.6.5+20220909-3 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! src:libsass currently FTBFS on loong64 due to a mismatching symbols file: (optional=templinst)_ZSt22__final_insertion_sortIN9__gnu_cxx17__normal_iteratorIPP13Sass_ImporterSt6vectorIS3_SaIS3_NS0_5__ops15_Iter_comp_iterIPFbRKS3_SC_vT_SG_T0_@Base 3.5.5-4~ (optional=templinst)_ZSt25__unguarded_linear_insertIN9__gnu_cxx17__normal_iteratorIPN4Sass10SharedImplINS2_14SimpleSelectorEEESt6vectorIS5_SaIS5_NS0_5__ops14_Val_comp_iterIPFbPS4_SD_vT_T0_@Base 3.6.4-2~ (optional=templinst)_ZSt4swapIN4Sass10SharedImplINS0_14SimpleSelectorNSt9enable_ifIXsrSt6__and_IJSt6__not_ISt15__is_tuple_likeIT_EESt21is_move_constructibleIS8_ESt18is_move_assignableIS8_EEE5valueEvE4typeERS8_SI_@Base 3.6.4-2~ - (optional=templinst)_ZSteqIcSt11char_traitsIcESaIcEEbRKNSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_@Base 3.6.5+20220909 - (optional=templinst)_ZSteqIcSt11char_traitsIcESaIcEEbRKNSt7__cxx1112basic_stringIT_T0_T1_EESA_@Base 3.6.5+20220909 +#MISSING: 3.6.5+20220909-3# (optional=templinst)_ZSteqIcSt11char_traitsIcESaIcEEbRKNSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_@Base 3.6.5+20220909 +#MISSING: 3.6.5+20220909-3# (optional=templinst)_ZSteqIcSt11char_traitsIcESaIcEEbRKNSt7__cxx1112basic_stringIT_T0_T1_EESA_@Base 3.6.5+20220909 (optional=templinst)_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEOS8_S9_@Base 3.6.4-2~ (optional=templinst|arch=amd64 arm64 kfreebsd-amd64 x32)_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_OS8_@Base 3.5.5-4~ + _ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_@Base 3.6.5+20220909-3 _ZTIN4Sass10AssignmentE@Base 3.5.5-4~ _ZTIN4Sass10AtRootRuleE@Base 3.6.4-2~ _ZTIN4Sass10Color_HSLAE@Base 3.6.4 dh_makeshlibs: error: failing due to earlier errors make: *** [debian/rules:15: binary-arch] Error 25 Could this be updated for the next upload using the build log? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=libsass=loong64=3.6.5%2B20220909-3=1693584389=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051124: libdex: Circular build dependency with sysprof makes bootstrap impossible
Source: libdex Version: 0.3.1-1 Severity: important Hello! Both src:libdex and src:sysprof have unconditional build dependencies on each other meaning that's not possible to bootstrap gtk4 at the moment. This affects riscv64 and loong64. Either libdex or sysprof need to be changed to have a build profile for bootstrapping without the other. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051104: marked as pending in sysprof
Hi! On Sat, 2023-09-02 at 20:20 +, Jeremy Bicha wrote: > Bug #1051104 in sysprof reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/gnome-team/sysprof/-/commit/277ed8cd349106e88bd118dc67c5f4d5bb6d5104 > > > Fix nogui build profile > > Closes: #1051104 > Thanks for fixing this. Could you upload the package soonish, so I can bootstrap sysprof and gtk4 on all Debian Ports architectures? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051104: sysprof: Building with profile "pkg.sysprof.nogui" results in FTBFS
Source: sysprof Version: 45~rc-1 Severity: important Hello! Trying to build src:sysprof with the "pkg.sysprof.nogui" profile FTBFS with: Run-time dependency glib-2.0 found: YES 2.77.2 Run-time dependency gio-2.0 found: YES 2.77.2 Run-time dependency gio-unix-2.0 found: YES 2.77.2 Did not find CMake 'cmake' Found CMake: NO Run-time dependency gtk4 found: NO (tried pkgconfig) ../meson.build:64:10: ERROR: Dependency "gtk4" not found, tried pkgconfig A full log can be found at /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt This means that breaking the gtk4 <=> sysprof build dependency circle is currently not possible preventing a successful bootstrap of gtk4 on new architectures such as loong64. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051068: sysprof: Should mark test build dependencies as
Source: sysprof Version: 45~rc-1 Severity: normal Hello! src:sysprof has multiple build dependencies in debian/control which are required for running the testsuite only but yet these build dependencies are not marked as to allow the package to be bootstrapped on a new architecture. Can you please mark the build dependencies as ? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1050994: xutils-dev: Please add support for loong64
Source: xutils-dev Version: 1:7.7+6.1 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: debian-de...@lists.debian.org,zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! Multiple X packages currently fail to build from source on loong64 due to missing architecture support in xutils-dev [1]: gcc: warning: LinuxMachineDefines: linker input file unused because linking not done gcc: error: LinuxMachineDefines: linker input file not found: No such file or directory This should be fixed in a similar fashion for loong64 as it has been done for riscv64 in [2]. I have CC'ed two engineers from Loongson to make them aware of the bug so they can work on a patch to add loong64 support. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=xaw3d=loong64=1.5%2BF-1.1=1693526902=0 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026002 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1050893: gcc-13: Please disable Ada, D, Go and M2 as well as GDB support on loong64
Source: gcc-13 Version: 13.2.0-2 Severity: normal Tags: patch User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: debian-de...@lists.debian.org Hello! In order to ease the bootstrap of the new loong64 port, please reduce the build dependencies and number of enabled languages. - Please disable Ada, D, Go and M2 for loong64 in debian/rules.def. - Please add "!loong64" for gdb in debian/control.m4 The attached patch implements these changes. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/gcc-13-13.2.0/debian/control.m4 new/gcc-13-13.2.0/debian/control.m4 --- old/gcc-13-13.2.0/debian/control.m4 2023-07-11 17:40:07.0 +0200 +++ new/gcc-13-13.2.0/debian/control.m4 2023-08-30 20:17:54.515043971 +0200 @@ -81,7 +81,7 @@ libzstd-dev, zlib1g-dev, SDT_BUILD_DEP USAGE_BUILD_DEP BINUTILS_BUILD_DEP, gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, - gdb`'NT [!riscv64 !mipsel !mips64el], OFFLOAD_BUILD_DEP + gdb`'NT [!loong64 !riscv64 !mipsel !mips64el], OFFLOAD_BUILD_DEP texinfo (>= 4.3), LOCALES, sharutils, procps, FORTRAN_BUILD_DEP GNAT_BUILD_DEP GO_BUILD_DEP GDC_BUILD_DEP GM2_BUILD_DEP ISL_BUILD_DEP MPC_BUILD_DEP MPFR_BUILD_DEP GMP_BUILD_DEP PHOBOS_BUILD_DEP diff -Nru old/gcc-13-13.2.0/debian/rules.defs new/gcc-13-13.2.0/debian/rules.defs --- old/gcc-13-13.2.0/debian/rules.defs 2023-08-04 04:48:33.0 +0200 +++ new/gcc-13-13.2.0/debian/rules.defs 2023-08-30 20:11:21.780573351 +0200 @@ -850,6 +850,7 @@ ada_no_cpus:= m32r sh3 sh3eb sh4eb ada_no_cpus+= arc ada_no_cpus+= ia64 +ada_no_cpus+= loong64 ada_no_systems := ada_no_cross := no ada_no_snap:= no @@ -1006,7 +1007,7 @@ with_libcc1 := endif -go_no_cpus := arc avr hppa +go_no_cpus := arc avr hppa loong64 go_no_cpus += m68k # See PR 79281 / PR 83314 go_no_systems := kfreebsd ifneq (,$(filter $(distrelease),precise)) @@ -1064,7 +1065,7 @@ # D --- d_no_cross := yes d_no_snap := -d_no_cpus := alpha arc ia64 m68k sh4 s390 sparc64 +d_no_cpus := alpha arc loong64 ia64 m68k sh4 s390 sparc64 d_no_systems := gnu kfreebsd-gnu ifneq ($(single_package),yes) @@ -1261,7 +1262,7 @@ with_m2 := yes endif endif -m2_no_archs = powerpc ppc64 sh4 kfreebsd-amd64 kfreebsd-i386 hurd-amd64 hurd-i386 +m2_no_archs = loong64 powerpc ppc64 sh4 kfreebsd-amd64 kfreebsd-i386 hurd-amd64 hurd-i386 ifneq (,$(filter $(DEB_TARGET_ARCH),$(m2_no_archs))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH) endif
Bug#1050503: suitesparse: FTBFS on loong64 and sparc64 due to packaging issues
Source: suitesparse Version: 1:7.1.0+dfsg-3 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! suitesparse FTBFS on loong64 and sparc64 due a packaging issue with an implicit CUDA dependency. The failing build step is actually at dpkg-shlibdeps which fails since it cannot find the lib*_cuda.so shared libraries anywhere [1][2]: dpkg-shlibdeps: error: cannot find library libspqr_cuda.so.3 needed by debian/libspqr3/usr/ \ lib/sparc64-linux-gnu/libspqr.so.3.0.4 (ELF format: 'elf64-sparc' abi: '0202002b'; RPATH: '') dpkg-shlibdeps: error: cannot find library libcholmod_cuda.so.4 needed by debian/libumfpack6/ \ usr/lib/sparc64-linux-gnu/libumfpack.so.6.1.1 (ELF format: 'elf64-sparc' abi: '0202002b'; RPATH: '') dpkg-shlibdeps: error: cannot find library libcholmod_cuda.so.4 needed by debian/libklu2/usr/ \ lib/sparc64-linux-gnu/libklu_cholmod.so.2.0.4 (ELF format: 'elf64-sparc' abi: '0202002b'; RPATH: '') This is not surprising since the corresponding lib*_cuda.so shared libraries are being deleted in debian/rules [3]. However, I have no clue why this affects loong64 and sparc64 only. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=suitesparse=loong64=1%3A7.1.0%2Bdfsg-3=1692910284=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=suitesparse=sparc64=1%3A7.1.0%2Bdfsg-3=1692414038=0 > [3] > https://salsa.debian.org/science-team/suitesparse/-/blob/master/debian/rules#L57 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1043225: qt6-base: Please add patch to re-enable support for SuperH (sh4)
Hi! Forgot to specify Q_BYTE_ORDER. Updated patch attached. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Index: qt6-base-6.4.2+dfsg/src/corelib/global/qprocessordetection.h === --- qt6-base-6.4.2+dfsg.orig/src/corelib/global/qprocessordetection.h +++ qt6-base-6.4.2+dfsg/src/corelib/global/qprocessordetection.h @@ -294,12 +294,12 @@ SuperH is bi-endian, use endianness auto-detection implemented below. */ -// #elif defined(__sh__) -// # define Q_PROCESSOR_SH -// # if defined(__sh4a__) -// #define Q_PROCESSOR_SH_4A -// # endif -// Q_BYTE_ORDER not defined, use endianness auto-detection +#elif defined(__sh__) +# define Q_PROCESSOR_SH +# if defined(__sh4a__) +#define Q_PROCESSOR_SH_4A +# endif +# define Q_BYTE_ORDER Q_LITTLE_ENDIAN /* SPARC family, optional revision: V9
Bug#1043225: qt6-base: Please add patch to re-enable support for SuperH (sh4)
Source: qt6-base Version: 6.4.2+dfsg-17 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello! For some reason, upstream disabled the platform detection for SuperH (sh4) in src/corelib/global/qprocessordetection.h by simply commenting the corresponding code out. As demanded by upstream in [1], I will provide a screenshot of Qt running on SH later this week. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025823 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- qt6-base-6.4.2+dfsg.orig/src/corelib/global/qprocessordetection.h +++ qt6-base-6.4.2+dfsg/src/corelib/global/qprocessordetection.h @@ -294,12 +294,12 @@ SuperH is bi-endian, use endianness auto-detection implemented below. */ -// #elif defined(__sh__) -// # define Q_PROCESSOR_SH -// # if defined(__sh4a__) -// #define Q_PROCESSOR_SH_4A -// # endif -// Q_BYTE_ORDER not defined, use endianness auto-detection +#elif defined(__sh__) +# define Q_PROCESSOR_SH +# if defined(__sh4a__) +#define Q_PROCESSOR_SH_4A +# endif +Q_BYTE_ORDER not defined, use endianness auto-detection /* SPARC family, optional revision: V9
Bug#990913: ausweisapp2: creates config in '~/.config/Unknown Organization'
Hello Rainer! On Fri, 2023-08-04 at 18:22 +0200, Reiner Herrmann wrote: > I just used it for the first time (version 1.26.6-1), and it still created > ~/.config/Unknown Organization/. As explained above, this is an upstream bug that needs to be addressed there. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1025779: onetbb: Please add patch to add support for ia64
Hello Petter! On Thu, 2023-08-03 at 15:56 +0200, Petter Reinholdtsen wrote: > [John Paul Adrian Glaubitz] > > If you feel fixing this, you can use yttrium.debian.net. > > > > I don't have much time for ia64 at the moment. > > Thanks. I just wanted to check the status and hopefully reduce the > amount of open bugs. I do not plan to increase the number of > architectures provided at this time, in case it will make it harder for > the package to propagate into testing. Ports architectures do not affect the propagation of packages to testing. So, feel free to ignore the tests on ia64. FWIW, I have also a patch that I sent upstream that fixes powerpc, but I need to clean it up again before upstream accepts it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1038585: virtualjaguar: Depends on SDL 1.2
Hi Teemu! On Thu, 2023-08-03 at 03:35 +0300, Teemu Hukkanen wrote: > I've done a preliminary SDL2 port, which was trivial due to the light > usage of SDL in virtualjaguar, available on the branch sdl2 at > <https://git.sr.ht/~tjhukkan/virtualjaguar>. I've already sent it > upstream. Great job! Which upstream did you send it to? The original Git repo [1] seems down. Adrian > [1] http://shamusworld.gotdns.org/git/virtualjaguar -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1027168: onetbb: Please add patch to fix FTBFS on sh4
Hi! On Thu, 2023-08-03 at 05:31 +0200, Petter Reinholdtsen wrote: > [John Paul Adrian Glaubitz 2022-12-28] > > I will forward the patch later after reformating it. > > Did you foward the sh4 patch upstream? I could not find it. Not yet, unfortunately. Upstream is quite picky with patches, so it takes quite long to get even simple fixes upstreamed. Help is welcome. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1025779: onetbb: Please add patch to add support for ia64
Hi Petter! On Thu, 2023-08-03 at 09:28 +0200, Petter Reinholdtsen wrote: > [Petter Reinholdtsen] > > Perhaps you can provide more information now the patched code is > > upstream? > > Note, the latest version fail during testing in > https://buildd.debian.org/status/fetch.php?pkg=onetbb=ia64=2021.9.0-2=1691031827=0 > >: > > > 87% tests passed, 18 tests failed out of 136 > > The failing tests segfaults. Could the issue be data type alignment? > ia64 will segfault on unaligned data access. If you feel fixing this, you can use yttrium.debian.net. I don't have much time for ia64 at the moment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1042489: webkit2gtk: Please build with -DENABLE_INTROSPECTION=OFF on ia64
Hi! On Sat, 2023-07-29 at 10:44 +0200, John Paul Adrian Glaubitz wrote: > On ia64, webkit2gtk FTBFS due to g-ir-scanner not understading the syntax used > in the header [1]: > > /usr/include/ia64-linux-gnu/sys/ucontext.h:92: syntax error, unexpected > typedef-name in ' \ > unsigned long _pad[__builtin_offsetof (mcontext_t, sc_gr[0])/8];' at > 'mcontext_t' > /usr/include/ia64-linux-gnu/sys/ucontext.h:94: syntax error, unexpected '}' > in ' }' at '}' > > To work around this, webkit2gtk should be built with introspection disabled: > > --- old/webkit2gtk-2.40.4/debian/rules 2023-07-06 11:51:25.0 +0200 > +++ new/webkit2gtk-2.40.4/debian/rules 2023-07-29 10:35:19.934123170 +0200 > @@ -55,6 +55,11 @@ > EXTRA_CMAKE_ARGUMENTS += -DENABLE_WEBGL=OFF > endif > > +# https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/471 > +ifneq (,$(filter $(DEB_HOST_ARCH),ia64)) > + EXTRA_CMAKE_ARGUMENTS += -DENABLE_INTROSPECTION=OFF > +endif > + > # libgbm-dev is not available in the Hurd (#1033999) > ifneq (,$(filter $(DEB_HOST_ARCH),hurd-i386)) > EXTRA_CMAKE_ARGUMENTS += -DUSE_GBM=OFF > > Can you apply this change for the next upload of webkit2gtk? I just noticed that there will be a number of files missing in dh_install when introspection is disabled. So, better not apply this fix at the moment and I will just build webkit2gtk on ia64 manually with a patched . We will have to wait until the upstream bug in g-ir-scanner has been fixed upstream. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1042519: webkit2gtk: Please update CFLAGS for sh4 to fix FTBFS
Source: webkit2gtk Version: 2.40.4-1 Severity: normal Tags: patch User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello! The current CFLAGS result in webkit2gtk FTBFS due to a GCC internal compiler error [1]: In file included from /<>/Source/JavaScriptCore/inspector/InjectedScriptHost.cpp:29, from JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-84c9f43f-1.cpp:7: /<>/Source/JavaScriptCore/inspector/JSInjectedScriptHost.h: In static member function ‘static JSC::Structure* Inspector::JSInjectedScriptHost::createStructure(JSC::VM&, JSC::JSGlobalObject*, JSC::JSValue)’: /<>/Source/JavaScriptCore/inspector/JSInjectedScriptHost.h:51:5: error: unable to find a register to spill in class ‘R0_REGS’ This is fixed by building webkit2gtk with "-O1" instead of "-Os" which used to be the case before but was changed in order to reduce memory usage during build [2]. However, on sh4, we need to keep "-O1" to make the register allocator happy. Could you apply the following change: --- old/webkit2gtk-2.40.4/debian/rules 2023-07-06 11:51:25.0 +0200 +++ new/webkit2gtk-2.40.4/debian/rules 2023-07-29 18:44:00.49550 +0200 @@ -71,7 +71,7 @@ endif # Lower memory requirements on architectures with only 2 GB address space -ifneq (,$(filter $(DEB_HOST_ARCH),m68k mips mipsel sh4)) +ifneq (,$(filter $(DEB_HOST_ARCH),m68k mips mipsel)) CFLAGS := $(CFLAGS:-g1=-g0) CFLAGS := $(CFLAGS:-O2=-Os) CPPFLAGS += --param ggc-min-expand=10 @@ -80,7 +80,9 @@ # 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)) + CFLAGS := $(CFLAGS:-g1=-g0) CFLAGS := $(CFLAGS:-O2=-O1) + CPPFLAGS += --param ggc-min-expand=10 endif ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS))) Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=sh4=2.41.4-1=1684382877=0 > [2] > https://salsa.debian.org/webkit-team/webkit/-/commit/3160dec4b3500e97418dbd4246481dc1ae0d2c37 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- old/webkit2gtk-2.40.4/debian/rules 2023-07-06 11:51:25.0 +0200 +++ new/webkit2gtk-2.40.4/debian/rules 2023-07-29 18:44:00.49550 +0200 @@ -71,7 +71,7 @@ endif # Lower memory requirements on architectures with only 2 GB address space -ifneq (,$(filter $(DEB_HOST_ARCH),m68k mips mipsel sh4)) +ifneq (,$(filter $(DEB_HOST_ARCH),m68k mips mipsel)) CFLAGS := $(CFLAGS:-g1=-g0) CFLAGS := $(CFLAGS:-O2=-Os) CPPFLAGS += --param ggc-min-expand=10 @@ -80,7 +80,9 @@ # 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)) + CFLAGS := $(CFLAGS:-g1=-g0) CFLAGS := $(CFLAGS:-O2=-O1) + CPPFLAGS += --param ggc-min-expand=10 endif ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
Bug#1042489: webkit2gtk: Please build with -DENABLE_INTROSPECTION=OFF on ia64
Source: webkit2gtk Version: 2.40.4-1 Severity: normal Tags: patch User: debian-i...@lists.debian.org Usertags: ia64 X-Debbugs-Cc: debian-i...@lists.debian.org Hi! On ia64, webkit2gtk FTBFS due to g-ir-scanner not understading the syntax used in the header [1]: /usr/include/ia64-linux-gnu/sys/ucontext.h:92: syntax error, unexpected typedef-name in ' \ unsigned long _pad[__builtin_offsetof (mcontext_t, sc_gr[0])/8];' at 'mcontext_t' /usr/include/ia64-linux-gnu/sys/ucontext.h:94: syntax error, unexpected '}' in ' }' at '}' To work around this, webkit2gtk should be built with introspection disabled: --- old/webkit2gtk-2.40.4/debian/rules 2023-07-06 11:51:25.0 +0200 +++ new/webkit2gtk-2.40.4/debian/rules 2023-07-29 10:35:19.934123170 +0200 @@ -55,6 +55,11 @@ EXTRA_CMAKE_ARGUMENTS += -DENABLE_WEBGL=OFF endif +# https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/471 +ifneq (,$(filter $(DEB_HOST_ARCH),ia64)) + EXTRA_CMAKE_ARGUMENTS += -DENABLE_INTROSPECTION=OFF +endif + # libgbm-dev is not available in the Hurd (#1033999) ifneq (,$(filter $(DEB_HOST_ARCH),hurd-i386)) EXTRA_CMAKE_ARGUMENTS += -DUSE_GBM=OFF Can you apply this change for the next upload of webkit2gtk? Thanks, Adrian [1] https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/471 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- old/webkit2gtk-2.40.4/debian/rules 2023-07-06 11:51:25.0 +0200 +++ new/webkit2gtk-2.40.4/debian/rules 2023-07-29 10:35:19.934123170 +0200 @@ -55,6 +55,11 @@ EXTRA_CMAKE_ARGUMENTS += -DENABLE_WEBGL=OFF endif +# https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/471 +ifneq (,$(filter $(DEB_HOST_ARCH),ia64)) + EXTRA_CMAKE_ARGUMENTS += -DENABLE_INTROSPECTION=OFF +endif + # libgbm-dev is not available in the Hurd (#1033999) ifneq (,$(filter $(DEB_HOST_ARCH),hurd-i386)) EXTRA_CMAKE_ARGUMENTS += -DUSE_GBM=OFF
Bug#1042078: ghc: Should not run inplace/bin/ghc-stage2 for cross-builds
Source: ghc Version: 9.0.2-4 Severity: normal User: helm...@debian.org Usertags: rebootstrap X-Debbugs-Cc: helm...@debian.org Hi! The debian/rules file for GHC has the following section: # Sort out the binaries if inplace/bin/ghc-stage2 --info | grep '"Have interpreter","NO"'; then \ cd debian/tmp/usr/bin ;rm -f ghci* runghc* runhaskell*; \ fi This will obviously fail when performing a cross-build. Hence, this part should only be run if the condition "ifeq (NO,$(BUILD_CROSS))" is met. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1041212: Acknowledgement (When ausweisapp2 is running, clicking on notifications for other apps always opens the ausweisapp2 window)
Hello Dirk! On Sun, 2023-07-16 at 08:51 +0200, Dirk Heinrichs wrote: > Every time Ausweisapp2 runs, clicking on incoming notifications from > (for example) Element or Thunderbird, results in the Ausweisapp2 window > being openend. If Ausweisapp2 doesn't run, the correct application > window is opened instead. This is most likely an upstream bug and not related to Debian packaging, it should therefore be reported upstream. I am CC'ing one of the upstream developers to make them aware. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040663: linux: Please build linux-libc-dev package for loong64
Hi Bastian! On Wed, 2023-07-12 at 11:07 +0200, Bastian Blank wrote: > On Sat, Jul 08, 2023 at 08:41:03PM +0200, John Paul Adrian Glaubitz wrote: > > Please enable building the linux-libc-dev package for the new Debian > > architecture loong64. > > The corresponding kernel architecture is called "loongarch". > > I can't find loong64 in the debian architecture table used on > ftp-master, so we can't add it yet. It's already part of the dpkg architecture table [1] and there is already a pool directory in Debian Ports [2]. I expect the architecture table to be updated in the near future. Adrian > [1] > https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=4c9e67b52672cb1cf19f7c3e86164bc70b749e77 > [2] http://ftp.ports.debian.org/debian-ports/pool-loong64/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 20:59 +0200, John Paul Adrian Glaubitz wrote: > With the above fix for the audit tests, the tests to ignore should be: > > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac Just verified this. With both patches above applied, the failures reduce to the four tests above. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
On Tue, 2023-07-11 at 20:57 +0200, Aurelien Jarno wrote: > > Correction: These two tests should be ignored as well: > > > > FAIL: elf/tst-rtld-run-static > > FAIL: nptl/tst-cancel24-static > > Noted. > > > So, it's only this failure that just got fixed today upstream [1]: > > > > FAIL: nptl/tst-cancel30 > > Ok, I see it's also fixed on the 2.37 branch, I'll pull it from there. And there is now a fix for the audit issues: > https://patchwork.sourceware.org/project/glibc/patch/20230711151558.314216-1-adhemerval.zane...@linaro.org/ And re-enable the 32-bit tests then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 20:52 +0200, Aurelien Jarno wrote: > > According to upstream, the following audit tests are not going to be > > fixed soon since the SPARC ABI makes it more difficult: > > > > FAIL: elf/tst-audit24a > > FAIL: elf/tst-audit24b > > FAIL: elf/tst-audit24c > > FAIL: elf/tst-audit24d > > Ok. It happens that Adhemerval just posted a patch for the audit issue a few hours ago: > https://patchwork.sourceware.org/project/glibc/patch/20230711151558.314216-1-adhemerval.zane...@linaro.org/ So, we might not have the blacklist these as well. > > These are going to be fixed upstream soon, the fixes are supposedly > > trivial: > > > > FAIL: elf/tst-rtld-run-static > > FAIL: nptl/tst-cancel24-static > > FAIL: nptl/tst-cancel30 > > Great. > > > This test is supposedly a kernel issue: > > > > FAIL: socket/tst-socket-timestamp > > > > And this one allegedly not related to sparc64: > > > > FAIL: stdlib/isomac > > What do you mean by "allegedly not related to sparc64"? This failure > only appears on sparc*. The sparc32 has the following comment in > debian/testsuite-xfail-debian.mk to ignore the failure: > > # Even if configured using --with-long-double-128, the biarch32 compiler > # on sparc64 defaults to 64-bit doubles, causing the failure below. This > # should be fixed by the following gcc patch: > # http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html > test-xfail-stdlib/isomac = yes > > Can you please check if there is a similar issue with the GCC > configuration on sparc64? That was the comment by Adhemerval when he looked at the issue. > > So, my suggestion would be to ignore the following tests for now: > > > > FAIL: elf/tst-audit24a > > FAIL: elf/tst-audit24b > > FAIL: elf/tst-audit24c > > FAIL: elf/tst-audit24d > > FAIL: socket/tst-socket-timestamp > > FAIL: stdlib/isomac > > Ok. > > > And looking at the testsuite results with 32-bit tests enabled [1], it > > looks like > > the failures are the same. So, I think we can just ignore the above tests > > and then > > re-enable testing on 32 bit as well. > > It appears that none of those fails on sparc32. Looking at it again, it > even appears that the sparc32 build passed the testsuite without issue, > so there was no need to disable it. Hmm, then I actually mixed up the two testsuites, sorry. You can re-enable it then. With the above fix for the audit tests, the tests to ignore should be: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 06:17 +0200, John Paul Adrian Glaubitz wrote: > The list of currently failing tests on sparc64 is: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: nptl/tst-cancel30 > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac > > According to upstream, the following audit tests are not going to be > fixed soon since the SPARC ABI makes it more difficult: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > > These are going to be fixed upstream soon, the fixes are supposedly > trivial: > > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: nptl/tst-cancel30 > > This test is supposedly a kernel issue: > > FAIL: socket/tst-socket-timestamp > > And this one allegedly not related to sparc64: > > FAIL: stdlib/isomac > > So, my suggestion would be to ignore the following tests for now: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac Correction: These two tests should be ignored as well: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static So, it's only this failure that just got fixed today upstream [1]: FAIL: nptl/tst-cancel30 Adrian > [1] > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=260d4b742bc36744aa2282421547f1a7b483d2f8 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1034779: pcre2: Please drop sparc from the JIT architectures in debian/rules
Hi Matthew! On Mon, 2023-04-24 at 23:28 +0100, Matthew Vernon wrote: > Hi, > > On 24/04/2023 10:28, John Paul Adrian Glaubitz wrote: > > > While we're currently not building Debian for 32-bit SPARC (sparc), > > it's still being bootstrapped in the Debian rebootstrap project [1]. > > > > The CI job for sparc is currently failing because pcre2 is still being > > configured with "--enable-jit" while JIT support [2] for 32-bit SPARC was > > dropped upstream [3]. See also for the corresponding change in buildroot > > [4]. > > I can remove sparc, certainly. Is this something you would like me to > try and get through the freeze? If not, I'd like to hold off making any > pcre2 uploads until after the release. Any chance this can be done now? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040828: fakeroot: Please add a stage1 build profile to allow bootstrapping
Source: fakeroot Version: 1.32-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: rebootstrap X-Debbugs-Cc: helm...@debian.org Hi! fakeroot build-depends on po4a for translating documentation which is not required for building a functional fakeroot package required for bootstrapping a new architecture such as the upcoming loong64 port. Thus, in order to ease bootstrapping, the fakeroot package should add a build profile which disables po4a which is what the attached patch does by modifying debian/control and debian/rules. Please consider applying this patch for one of the next uploads. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/fakeroot-1.32/debian/control new/fakeroot-1.32/debian/control --- old/fakeroot-1.32/debian/control2023-07-10 15:13:20.0 +0200 +++ new/fakeroot-1.32/debian/control2023-07-11 11:01:52.500152920 +0200 @@ -5,7 +5,7 @@ libacl1-dev, libcap-dev [linux-any], libcap2-bin [linux-any], - po4a, + po4a , sharutils Maintainer: Clint Adams Standards-Version: 4.6.1 diff -Nru old/fakeroot-1.32/debian/rules new/fakeroot-1.32/debian/rules --- old/fakeroot-1.32/debian/rules 2023-07-10 15:13:20.0 +0200 +++ new/fakeroot-1.32/debian/rules 2023-07-11 10:59:02.312600977 +0200 @@ -15,7 +15,9 @@ dhar-stamp: dh_autoreconf +ifeq (,$(findstring pkg.fakeroot.stage1,$(DEB_BUILD_PROFILES))) (cd doc && po4a -k 0 --rm-backups --variable "srcdir=../doc/" po4a/po4a.cfg) || exit 1 +endif touch $@ obj-sysv/config.status: dhar-stamp
Bug#1040817: glibc: Please ignore some tests on sparc64
Source: glibc Version: 2.37-5 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi! The list of currently failing tests on sparc64 is: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac According to upstream, the following audit tests are not going to be fixed soon since the SPARC ABI makes it more difficult: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d These are going to be fixed upstream soon, the fixes are supposedly trivial: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 This test is supposedly a kernel issue: FAIL: socket/tst-socket-timestamp And this one allegedly not related to sparc64: FAIL: stdlib/isomac So, my suggestion would be to ignore the following tests for now: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac And looking at the testsuite results with 32-bit tests enabled [1], it looks like the failures are the same. So, I think we can just ignore the above tests and then re-enable testing on 32 bit as well. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.37-1=1684283585=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040663: linux: Please build linux-libc-dev package for loong64
Source: linux Version: 6.3.11-1 Severity: normal User: debian-m...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: debian-m...@lists.debian.org Hello! Please enable building the linux-libc-dev package for the new Debian architecture loong64. The corresponding kernel architecture is called "loongarch". Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040462: glibc: Please ignore testsuite failures for 32-bit builds on sparc64
Source: glibc Version: 2.37-3 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! On sparc64, the following tests for the 32-bit build have been failing for a while now: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac See: https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.37-3=1688236651=0 Since we don't care so much about 32-bit SPARC these days, I think it's safe to ignore these testsuite failures. Can you therefore ignore the testsuite failures for 32-bit for the time being? I will report each of the testsuite failures in case this has not happened yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer
Hello! On Sat, 2023-05-20 at 15:07 +0200, Adam Borowski wrote: > The JFS filesystem is deprecated in the kernel: on life support since 2009 > and with talks of removal altogether. Not sure where you got this information from, but JFS [1] unlike ReiserFS [2] is not marked as deprecated in the kernel. There was a single mail by Christoph Hellwig suggesting to deprecate JFS in the near future but so far nothing has been decided yet. Adrian > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/jfs/Kconfig > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/reiserfs/Kconfig -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1038025: Bug#985183: aranym: Switch from SDL1 to SDL2
Hello Simon! On Sun, 2023-06-25 at 15:48 +0100, Simon McVittie wrote: > On closer inspection, the upstream default is SDL 2, so if libsdl2-dev > happens to be installed then aranym will already accidentally switch > from SDL 1.2 to SDL 2, even with the current unmodified Debian packaging. According to one of the upstream developers, Aranym's SDL-2 support doesn't seem to be very mature. Apparently, there are problems here and there [1]. > I'm intending to make the -dev package for sdl12-compat depend on > libsdl2-dev as a workaround for legacy SDL-dependent packages that > don't declare their build-dependencies explicitly, so when sdl12-compat > takes over the libsdl1.2-dev binary package name, aranym is going to > end up using SDL 2 in practice unless you explicitly configure with > --disable-sdl2 (please do that if you are aware of reasons why the SDL > 2 code paths are broken). OK, thanks for the heads-up. > aranym seems to compile fine in that configuration. I don't know what > Atari ROMs or other software (if any) it might need, so I haven't > attempted to test the resulting binaries. That should definitely be properly tested. We don't gain anything if a package builds find but doesn't work well for most users. Adrian > [1] https://github.com/aranym/aranym/issues/103#issuecomment-1593666173 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#826608: hfsprogs: Please switch to use libmd instead of OpenSSL's libcrypto
Hi Guillem! Apologies for the late reply! On Thu, 2023-03-23 at 23:15 +0100, Guillem Jover wrote: > [ Sorry had not seen the reply until now when I was doing a pass > over submitted bugs over the BTS web archive, as I was not CCed. ] > > On Tue, 2022-05-03 at 16:52:03 +0200, John Paul Adrian Glaubitz wrote: > > While I think this change is a sensible idea, I'm a bit hesitant to apply it > > as it changes quite a large number of source files. > > The bulk of the patch was mostly patch metadata and rebase artifacts, > the actual patch introducing the change modified only 4 files. > > > Are there any compelling reasons for not using OpenSSL? > > It reduces the dependency tree, as libbsd has transitively linked > against libmd for a long time, and libmd is now even in the > pseudo-essential set (via dpkg). :) Thanks, this is actually convincing and I am going to implement this change for the next upload. However, it will take a little longer until the next upload happens as I am currently reworking the package based on Apple's latest version of the HFS upstream code [1]. My fork of Apple's HFS repository can be found in [2] and is currently work in progress. I will hopefully finished within the next weeks. Thanks, Adrian > [1] https://github.com/apple-oss-distributions/hfs > [2] https://github.com/glaubitz/hfs -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#995159: hfsprogs: Directory hardlink problems cannot be repaired.
Hi Daniel! On Tue, 2023-06-20 at 07:11 +0200, Daniel Höpfl wrote: > Your answer is still faster than anything from Apple. Took me still way too long. > Just note that your links go to an unofficial repo. > The official repository is at > <https://github.com/apple-oss-distributions/hfs>. You're absolutely right and I only noticed this after sending the reply to your bug report. I will have to rebase my Linux patches. > HFS does not look like one of the projects that care about pull > requests: > <https://github.com/apple-oss-distributions/hfs/pulls> I saw your pull request and I think that Apple is simply not monitoring this repository. I am trying to find someone at Apple that can help us here, both with the license and community improvements. It certainly won't be easy though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#995159: hfsprogs: Directory hardlink problems cannot be repaired.
Hi Daniel! Apologies for the late reply. I had seen your message back then but it somehow fell of the table and eventually forgot to answer. I just now found your report again since I resumed working on the hfsprogs package. On Mon, 2021-09-27 at 12:45 +0200, Daniel Höpfl wrote: > Apple (the upstream) never finished the implementation of the directory > hardlink support > in fsck_hfs. Since, once again, my TimeMachine backup rendered unrepairable > due to directory > hardlink errors, I implemented what was required to fix the errors I > encountered. The current hfsprogs package in Debian is based on a patched version 540.1 of Apple's »diskdev_cmds« package [1] while Apple has actually continued their work on the HFS code. in that package. However, after version 557.3.1 Apple decided to move the HFS code into a separate package called just »hfs« [2] which makes sense given the fact that Apple switched their default filesystem to APFS instead and diskdev_cms is no longer strictly tied to HFS. I have started working on an updated Debian hfsprogs package which is based on the latest version 556.100.11 of the hfs package [3]. The code already compiles in openSUSE [4] but I don't consider the Linux port to be complete yet. However, you may want to try whether the latest version of Apple's own fsck_hfs has support for fixing hardlink problems. If not, you may want to rebase your patch on top of hfs 560.100.11. > My trust in Apple's feedback system is very low so I am sending the patch to > you in the hopes > that you can forward it to Apple. Try opening a pull request on Github [5]. Apple has actually moved their open source projects to Github and it seems they're actually accepting pull requests for some projects. > > The patch I added should work, with offsets, on both, Debian's sources as > well as Apple's sources. > > My changes: > > - Any hardlink inode with a parent other than the metadata directory is > changed > to have the correct parent. > I have seen these. I can understand how this happens when a normal directory > is hardlined for the first time. The journal SHOULD prevent this from being > a > problem but obviously this is not the case. > > - Directory hardlink inodes named "temp..." get deleted. > These directories were deleted while open when the volume was removed > without > unmounting. Since these directories have already been deleted, deleting them > in fsck is the right thing to do. (Documented like that for files in the > HFS+ > spec.) > > - Directory hardlink inodes with names other than "temp..." or "dir_..." are > moved > to "lost+found". > It would be better to rename them to "dir_..." in a first pass, there might > still > be valid links to them. These links are deleted by a different repair step > and I > did not see how to remove those other repair steps. Would probably lead to > a bigger > rewrite of the hardlink check code so I decided to just move these to l+f. > I have never seen this anyways. > > After all, none of the errors should happen in a journaled filesystem > (directory > hardlinks require the Journal to be active). My guess is that using HFS+ over > AFP > (as TimeMachine does) does not correctly persist the journal before > persisting changes. > Thus loosing the connection during directory hardlink operation can result in > partially > executed atomic operation. Sounds like a very useful and welcome improvement. I will definitely incorporate this patch once I'm ready with the new upstream version. But maybe we're lucky and you can get your changes merged upstream with Apple in the mean time. FWIW, I have also reached out to Apple Legal trying to convince them to relicense the hfs package to a more permissive license such as the Apache License like they have done for other projects such as mDNSResponder [6]. Apple's own APSL license is considered non-free by Debian [7] which makes redistribution of the package more complicated. > I will attach the patch and test cases for each of the three fixed errors. > These test > cases have been constructed in a hex editor, they might not be what a real > error looks > like. The first two repairs successfully repaired my broken backup file so I > guess > they work (sometimes). Thanks, having test cases will be very useful for verifying my patched hfs package! Adrian > [1] https://github.com/apple-opensource/diskdev_cmds/tree/540.1 > [2] https://github.com/apple-opensource/hfs > [3] https://github.com/glaubitz/hfs/tree/linux > [4] > https://build.opensuse.org/package/show/home:glaubitz:branches:filesystems/hfsplus-tools > [5] https://github.com/apple-opensource/hfs > [6] https://github.com/apple-oss-d
Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022
> On Jun 18, 2023, at 3:53 PM, Simon McVittie wrote: > > On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote: >> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can >> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must >> have triggered a regression between September 2022 and now. > > It would be helpful if someone with suitable hardware could put this > through debbisect or similar to find out which build-dependency triggered > this. TIL about debbisect. I can try to bisect this on big-endian PowerPC, I have root on multiple big-endian machines. Adrian
Bug#1037978: openjdk-19: Please update patch for m68k support
Source: openjdk-19
Version: 19.0.2+7-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org
Hello!
The patch for adding m68k support in the OpenJDK package needs to be updated
since the path for the file sizes-32-linux.txt was changed with OpenJDK 19
which is why we need to move the m68k version sizes-32-linux-m68k.txt as well.
I have done that for the patch m68k-support.diff, so the patch just needs to
be updated in debian/patches to fix the FTBFS of openjdk-19 and newer on m68k.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Subject: Fix alignment issues on m68k
Author: John Paul Adrian Glaubitz
Last Update: 2023-06-14
Index:
openjdk-19-19.0.2+7/make/modules/java.desktop/gensrc/GensrcX11Wrappers.gmk
===
---
openjdk-19-19.0.2+7.orig/make/modules/java.desktop/gensrc/GensrcX11Wrappers.gmk
+++ openjdk-19-19.0.2+7/make/modules/java.desktop/gensrc/GensrcX11Wrappers.gmk
@@ -29,9 +29,14 @@
# Put the generated Java classes used to interface X11 from awt here.
GENSRC_X11WRAPPERS_OUTPUTDIR :=
$(SUPPORT_OUTPUTDIR)/gensrc/java.desktop/sun/awt/X11
+GENSRC_X11_VERSION_VARIANT :=
+ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-m68k)
+ GENSRC_X11_VERSION_VARIANT := -linux-m68k
+endif
+
# The pre-calculated offset file are stored here:
GENSRC_X11WRAPPERS_DATADIR := $(MODULE_SRC)/unix/data/x11wrappergen
-GENSRC_X11WRAPPERS_DATA :=
$(GENSRC_X11WRAPPERS_DATADIR)/sizes-$(OPENJDK_TARGET_CPU_BITS).txt
+GENSRC_X11WRAPPERS_DATA :=
$(GENSRC_X11WRAPPERS_DATADIR)/sizes-$(OPENJDK_TARGET_CPU_BITS)$(GENSRC_X11_VERSION_VARIANT).txt
# Run the tool on the offset files to generate several Java classes used in
awt.
$(eval $(call SetupExecute, gen_x11wrappers, \
Index: openjdk-19-19.0.2+7/src/hotspot/share/memory/allocation.hpp
===
--- openjdk-19-19.0.2+7.orig/src/hotspot/share/memory/allocation.hpp
+++ openjdk-19-19.0.2+7/src/hotspot/share/memory/allocation.hpp
@@ -232,7 +232,7 @@ template class CHeapObj ALL
void operator delete(void* p) { FreeHeap(p); }
void operator delete [] (void* p) { FreeHeap(p); }
-};
+} __attribute__ ((aligned (4)));
// Base class for objects allocated on the stack only.
// Calling new or delete will result in fatal error.
@@ -243,7 +243,7 @@ class StackObj ALLOCATION_SUPER_CLASS_SP
void* operator new [](size_t size) throw();
void operator delete(void* p);
void operator delete [](void* p);
-};
+} __attribute__ ((aligned (4)));
// Base class for objects stored in Metaspace.
// Calling delete will result in fatal error.
@@ -365,7 +365,7 @@ class MetaspaceObj {
// that should be read-only by default. See symbol.hpp for an example. This
function
// is used by the templates in metaspaceClosure.hpp
static bool is_read_only_by_default() { return false; }
-};
+} __attribute__ ((aligned (4)));
// Base class for classes that constitute name spaces.
@@ -438,7 +438,7 @@ protected:
void* operator new [](size_t size, const std::nothrow_t& nothrow_constant)
throw() = delete;
void operator delete(void* p);
void operator delete [](void* p) = delete;
-};
+} __attribute__ ((aligned (4)));
// One of the following macros must be used when allocating an array
// or object to determine whether it should reside in the C heap on in
Index: openjdk-19-19.0.2+7/src/hotspot/share/oops/constMethod.hpp
===
--- openjdk-19-19.0.2+7.orig/src/hotspot/share/oops/constMethod.hpp
+++ openjdk-19-19.0.2+7/src/hotspot/share/oops/constMethod.hpp
@@ -530,6 +530,6 @@ private:
// Verify
void verify_on(outputStream* st);
-};
+} __attribute__ ((aligned (4)));
#endif // SHARE_OOPS_CONSTMETHOD_HPP
Index: openjdk-19-19.0.2+7/src/hotspot/share/oops/oop.hpp
===
--- openjdk-19-19.0.2+7.orig/src/hotspot/share/oops/oop.hpp
+++ openjdk-19-19.0.2+7/src/hotspot/share/oops/oop.hpp
@@ -315,7 +315,7 @@ class oopDesc {
static void* load_oop_raw(oop obj, int offset);
DEBUG_ONLY(bool size_might_change();)
-};
+} __attribute__ ((aligned (4)));
// An oopDesc is not initialized via a constructor. Space is allocated in
// the Java heap, and static functions provided here on HeapWord* are used
Index:
openjdk-19-19.0.2+7/src/java.desktop/unix/data/x11wrappergen/sizes-32-linux-m68k.txt
===
--- /dev/null
+++
openjdk-19-19.0.2+7/src/java.desktop/unix/data/x11wrappergen/sizes-32-linux-m68k.txt
@@ -0,0 +1,1017 @@
+long 4
+int4
+short 2
+ptr4
+Bool 4
+Atom 4
+Window 4
+XExtData.number0
+XExtData.next 4
+XExtData.free_private 8
+XExtData.private_data
Bug#1036946: webkit2gtk: Tries to build Bubblewrap support even if its disabled
Source: webkit2gtk Version: 2.40.2-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! webkit2gtk currently FTBFS on multiple architectures since it tries to build Bubblewrap support code despite being configured with -DENABLE_BUBBLEWRAP_SANDBOX=OFF. On sparc64, for example, at the configure stage, the feature is clearly off: -- Enabled features: -- ENABLE_BUBBLEWRAP_SANDBOX . OFF However, the build system still tries to build the corresponding code in Sandbox.cpp: [151/6185] /usr/bin/ccache /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1 \ -DBUILDING_WTF -DGETTEXT_PACKAGE=\"WebKitGTK-4.0\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1 \ -I/<>/build-soup2 -I/<>/build-soup2/WTF/DerivedSources -I/<>/Source/WTF \ -I/<>/Source/WTF/wtf -I/<>/Source/WTF/wtf/dtoa -I/<>/Source/WTF/wtf/fast_float \ -I/<>/Source/WTF/wtf/persistence -I/<>/Source/WTF/wtf/text \ -I/<>/Source/WTF/wtf/text/icu -I/<>/Source/WTF/wtf/threads \ -I/<>/Source/WTF/wtf/unicode -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/glib-2.0 -isystem \ /usr/lib/sparc64-linux-gnu/glib-2.0/include -isystem /usr/include/libmount -isystem /usr/include/blkid \ -fdiagnostics-color=always -Wextra -Wall -pipe -fmax-errors=20 -Wno-odr -Wno-stringop-overread \ -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type \ -Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith \ -Wmissing-format-attribute -Wformat-security -Wcast-align -Wno-tautological-compare -g1 -O2 \ -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security \ -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions \ -fno-rtti -fPIC -fvisibility=hidden -std=c++20 -MD -MT Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \ -MF Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o.d -o Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \ -c /<>/Source/WTF/wtf/glib/Sandbox.cpp FAILED: Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o /usr/bin/ccache /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1 -DBUILDING_WTF \ -DGETTEXT_PACKAGE=\"WebKitGTK-4.0\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1 \ -I/<>/build-soup2 -I/<>/build-soup2/WTF/DerivedSources -I/<>/Source/WTF \ -I/<>/Source/WTF/wtf -I/<>/Source/WTF/wtf/dtoa -I/<>/Source/WTF/wtf/fast_float \ -I/<>/Source/WTF/wtf/persistence -I/<>/Source/WTF/wtf/text \ -I/<>/Source/WTF/wtf/text/icu -I/<>/Source/WTF/wtf/threads -I/<>/Source/WTF/wtf/unicode \ -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/glib-2.0 -isystem /usr/lib/sparc64-linux-gnu/glib-2.0/include -isystem \ /usr/include/libmount -isystem /usr/include/blkid -fdiagnostics-color=always -Wextra -Wall -pipe -fmax-errors=20 -Wno-odr \ -Wno-stringop-overread -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type \ -Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith -Wmissing-format-attribute \ -Wformat-security -Wcast-align -Wno-tautological-compare -g1 -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong \ -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing \ -fno-exceptions -fno-rtti -fPIC -fvisibility=hidden -std=c++20 -MD -MT Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \ -MF Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o.d -o Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o -c \ /<>/Source/WTF/wtf/glib/Sandbox.cpp /<>/Source/WTF/wtf/glib/Sandbox.cpp: In function ‘bool WTF::isInsideUnsupportedContainer()’: /<>/Source/WTF/wtf/glib/Sandbox.cpp:49:13: error: ‘BWRAP_EXECUTABLE’ was not declared in this scope 49 | BWRAP_EXECUTABLE, | ^~~~ See: https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=sparc64=2.40.2-1=1685439602=0 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1036158: gcc-13: Please raise baseline for alpha to EV56
Hi Michael! On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote: > On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote: > > After a long discussion on IRC and the mailing list, we have agreed to > > raise the > > baseline for the alpha architecture to EV56 to improve the generated code > > and fix > > a number of issues. The change is already being implemented in the glibc > > packages > > which switches to EV56 [1] since hwcaps are no longer available with glibc > > 2.37 [2]. > > > > Could you raise the baseline for gcc on alpha to EV56? > > > > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56". > > Yes, please! > > I suggest the following in debian/rules2: > > ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH))) > CONFARGS += --with-cpu=ev56 --with-tune=ev6 > endif > > (the --with-tune only affects instruction scheduling and better tunes > code for ev6 and more recent machines, but allows execution down to > ev56.) I have tested this in the past with a rebuild of most packages > that are in the base essential chroot in the past and it works well. Doesn't that come with a speed penalty for EV56 machines? I'm asking because EV56 is currently the baseline for QEMU when emulating Alpha. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1011530: FTBFS: fails to include system headers
Hello! On Tue, 2023-05-16 at 22:13 +0200, Bastian Germann wrote: > I am uploading a NMU to fix this. > Please find the debdiff attached. Please don't do NMUs without using a delay [1]. I did not get a chance to review your change. Adrian > [1] https://ftp-master.debian.org/deferred.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1036158: gcc-13: Please raise baseline for alpha to EV56
Source: gcc-13 Version: 13.1.0-2 Severity: normal User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-al...@lists.debian.org Hello! After a long discussion on IRC and the mailing list, we have agreed to raise the baseline for the alpha architecture to EV56 to improve the generated code and fix a number of issues. The change is already being implemented in the glibc packages which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2]. Could you raise the baseline for gcc on alpha to EV56? I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56". Thanks, Adrian > [1] > https://salsa.debian.org/glibc-team/glibc/-/commit/7af7b56d5f5fef7a4f3c011b36774e4556563d3d > [2] > https://salsa.debian.org/glibc-team/glibc/-/commit/4d57b6af3efd1d6af277b2eb67fe9ee500e7ae68 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033935: unblock: ausweisapp2/1.26.3-1
Hello Paul! On Thu, 2023-04-27 at 10:40 +0200, John Paul Adrian Glaubitz wrote: > I don't really know a smart way to filter these out, unfortunately. I have been removing the copyright changes manually now, but that takes forever due to the number of files that were changed. I then tried using the "-I" option to diff to ignore comment lines, but that didn't work: $ diff -Nru --exclude='*.svg' --exclude='*.qml' --exclude='*.rst' --exclude='*.groovy' \ --exclude='*.txt' --exclude='*android*' --exclude='*.qrc' --exclude='*.wxs' \ --exclude='*.png' -I "^\/\*" -I "^\s\*" ausweisapp2-1.26.2/ ausweisapp2-1.26.3/ I'll have to ask on debian-devel if someone has any clue how to filter out comments properly. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033935: unblock: ausweisapp2/1.26.3-1
On Thu, 2023-04-27 at 10:10 +0200, Paul Gevers wrote: > Hi Adrian, > > On 27-04-2023 10:05, John Paul Adrian Glaubitz wrote: > > > > > Could you prepare a debdiff stripping tests (assuming those are not > > > > > influencing the build itself), stripping the copyright line changes > > > > > and > > > > albeit a lot of the changes seem to be > > changing copyright notices and not code, see attached. > > That's what I said :). I don't really know a smart way to filter these out, unfortunately. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1034779: pcre2: Please drop sparc from the JIT architectures in debian/rules
Hi Matthew! On Mon, 2023-04-24 at 23:28 +0100, Matthew Vernon wrote: > Hi, > > On 24/04/2023 10:28, John Paul Adrian Glaubitz wrote: > > > While we're currently not building Debian for 32-bit SPARC (sparc), > > it's still being bootstrapped in the Debian rebootstrap project [1]. > > > > The CI job for sparc is currently failing because pcre2 is still being > > configured with "--enable-jit" while JIT support [2] for 32-bit SPARC was > > dropped upstream [3]. See also for the corresponding change in buildroot > > [4]. > > I can remove sparc, certainly. Is this something you would like me to > try and get through the freeze? If not, I'd like to hold off making any > pcre2 uploads until after the release. It's not urgent and can be uploaded after Bookworm has been released. It's okay for Helmut Grohne to know it's going to be fixed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1034779: pcre2: Please drop sparc from the JIT architectures in debian/rules
Source: pcre2 Version: 10.36-2+deb11u1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! While we're currently not building Debian for 32-bit SPARC (sparc), it's still being bootstrapped in the Debian rebootstrap project [1]. The CI job for sparc is currently failing because pcre2 is still being configured with "--enable-jit" while JIT support [2] for 32-bit SPARC was dropped upstream [3]. See also for the corresponding change in buildroot [4]. Could you drop "sparc" from the list in [3]? Thanks, Adrian > [1] https://jenkins.debian.net/view/rebootstrap/ > [2] https://salsa.debian.org/debian/pcre2/-/blob/master/debian/rules#L16 > [3] > https://github.com/PCRE2Project/pcre2/commit/b67d5682019fd192a615a1d5ed254b564f54126b > [4] > https://patchwork.ozlabs.org/project/buildroot/patch/20230221115001.190317-1-fontaine.fabr...@gmail.com/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033935: unblock: ausweisapp2/1.26.3-1
Hello Paul! On Thu, 2023-04-20 at 10:40 +0200, Paul Gevers wrote: > On 04-04-2023 12:01, John Paul Adrian Glaubitz wrote: > > I would like to ask for the package ausweisapp2 to be unblocked for > > testing. While the debdiff is rather large (about 1.8 MB), > > Could you prepare a debdiff stripping tests (assuming those are not > influencing the build itself), stripping the copyright line changes and > dropping the changed png files? It seems this might be reviewable when > that's done. Thanks, this is a very good idea to make the debdiff more reviewable! I will look into this. > > the package > > itself is just a leaf package and used for a very specific purpose only > > which is providing the official ID card authentication app of the German > > government, so I think the risk conveyed by this update is rather low. > > Well, in the hard freeze we're looking for *targeted* fixes [1]. > > Paul > PS: you could consider if an (non-superficial) autopkgtest is > possible/reasonable I have no experience with autopkgtest yet, but this is definitely on my TODO list. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033731: sbcl: support bootstrap on riscv64
Hi! On Wed, 2023-04-05 at 16:29 +0800, Bo YU wrote: > Oops. > Could you try the package? > https://drive.google.com/file/d/1BqVpACiiXHM2pc5h1HzqqxWQugv4PGwN/view?usp=share_link > Or attachment file. > > It should work on my Unmatched board: > > ``` > rv@unmatched:~$ sbcl > This is SBCL 2.2.2.debian, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > * (defun hello () >(format t "Hello, World!~%")) > HELLO > * (exit) > rv@unmatched:~$ uname -a > Linux unmatched 6.1.0-6-riscv64 #1 SMP Debian 6.1.15-1 (2023-03-05) > riscv64 GNU/Linux > ``` > It still was 2.2.2. No luckly for 2.2.9.:( Same result with this package, unfortunately: root@neutron:/# sbcl This is SBCL 2.2.2.debian, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Segmentation fault (core dumped) root@neutron:/# This also explains why sbcl still doesn't build on the buildds. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033731: sbcl: support bootstrap on riscv64
Hi! On Fri, 2023-03-31 at 20:57 +0800, Bo YU wrote: > Oh. It seems the 2.2.9 can be built with the sbcl(2.2.2-1) riscv64 package. > But, very odd: I just gave it a try. Your 2.2.2 binary doesn't work on my StarFive Beagle-V: root@neutron:~/sbcl/sbcl-2.2.9# sbcl This is SBCL 2.2.2.debian, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Segmentation fault (core dumped) root@neutron:~/sbcl/sbcl-2.2.9# Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033935: unblock: ausweisapp2/1.26.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ausweisa...@packages.debian.org,aklitz...@gmail.com Control: affects -1 + src:ausweisapp2 Hello! I would like to ask for the package ausweisapp2 to be unblocked for testing. While the debdiff is rather large (about 1.8 MB), the package itself is just a leaf package and used for a very specific purpose only which is providing the official ID card authentication app of the German government, so I think the risk conveyed by this update is rather low. The changes between the testing (1.26.2-1) and unstable (1.26.3-1) version are mostly fixes and improvements and do not include any breaking changes: - Improvement of help and tutorial texts. - Improvements in diagnostics. - Fix an error in the NFC dialog on iOS. - Improved accessibility when entering PIN, CAN and PUK. - Introduction of unique FailureCodes in SDK. - Added the environment variable AUSWEISAPP2_AUTOMATIC_DEVELOPERMODE in the fully automated SDK. - Fixed incorrect progress display in SDK for iOS. - Added SECURESCREENKEYBOARD for corporate environments. - Bumped TargetSDK to 33 in SDK for Android. - Update of OpenSSL to version 3.0.8. Changes list translated from [1]. I have used the new version 1.26.3 for a while now myself and didn't run into any regressions. I'm maintaining the package both in Debian and openSUSE and have not received any reports about regressions in the upstream release 1.26.3, so I think it should be safe to update the version in testing to the version in unstable. My reasoning for asking for this unblock is to ensure we're shipping a version of ausweisapp2 in Debian Bookworm that is as recent as possible. I only missed the hard freeze for Debian Bookworm by a few days when I uploaded the new version in unstable. I am CC'ing one of the upstream developers who can give some more details on the changes if requested by the release team. unblock ausweisapp2/1.26.3-1 Kind Regards, Adrian > [1] https://github.com/Governikus/AusweisApp2/releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033888: ITP: usbscale -- read weight data from a USB scale
Hi John! > Package: wnpp > Severity: wishlist > Owner: John Scott > Tags: newcomer > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: usbscale > Upstream Contact: Eric Jiang > * URL : https://github.com/erjiang/usbscale > * License : GPL 3.0 or any later version > Programming Lang: C > Description : read weight data from a USB scale > > This package provides a utility one can use to read data from various > USB scales, ones which are sold as postage scales in particular. I'm actually about to buy such a scale with USB and I would therefore be interested in sponsoring this package. Let me know if you're interested. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033731: sbcl: support bootstrap on riscv64
Hello! On Fri, 2023-03-31 at 17:16 +0800, Bo YU wrote: > Sorry, the folder is wrong. The right folder is here: > https://drive.google.com/drive/folders/1c6AFD_EgGwXTbAiC_-1al6Gb_wBpfMpr Thanks. > > > > Did you build in a clean environment, i.e. using sbuild? > Yeah, I used sbuild(with --extra-package options) to build it. > I will gradually upgrade to 2.2.3(revert the commit) to see if this > problem still exists. What about 2.2.9? Has the bug not been fixed since 2.2.3? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033731: sbcl: support bootstrap on riscv64
Hello Bo! On Fri, 2023-03-31 at 16:53 +0800, Bo YU wrote: > The sbcl can be bootstraped on Debian riscv64 now. > A riscv64 sbcl package is available here: > https://drive.google.com/drive/folders/1wCCV6Ke0YMCrgGwKF4rjTTlEz8wr4Piq?usp=share_link The folder is empty. > Please note it is 2.2.2 from upstream to be bootstrapped. At first > used 2.3.2, but due to one commit[0] was introduced after 2.2.3: > was failed to bootstrap it after many attempts > There are many issues 0n Debian using ecl to bootstrap it also. > > So with help of Christoph[1], I first built sbcl in a cross build > way then patched the binary file into sbcl package which can be > bootstrapped itself at last. Well, Debian is using clisp for bootstrapping sbcl but that still doesn't work for sbcl, see: > https://buildd.debian.org/status/logs.php?pkg=sbcl=riscv64 > I hope it can reduce bootstrap pain on Debian r iscv64. And > I will also keep an eye on upstream changes and update here. > BTW, I have to modify the d/rules file to fix the issue that reported > cannot find `stage1/bin/sbcl` issue. It seems the file was cleared by > `./clean.sh` even with `chmod 100 stage 1` Did you build in a clean environment, i.e. using sbuild? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033042: webkit2gtk: Please disable ccache on m68k
Source: webkit2gtk
Version: 2.38.5-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org
Hi!
On m68k, the build currently fails with ccache enabled due to a bug in
qemu-user:
FAILED:
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/heap/StructureAlignedMemoryAllocator.cpp.o
/usr/bin/ccache /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore
-DBUILDING_WITH_CMAKE=1 \
(...)
-o
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/heap/StructureAlignedMemoryAllocator.cpp.o
\
-c
/<>/Source/JavaScriptCore/heap/StructureAlignedMemoryAllocator.cpp
ccache: pthread_mutex_lock.c:94: ___pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
This issue can be worked around by disabling ccache which will prolong the
build times, of course, but
at least the package gets built.
Thus, could you disable ccache on m68k with the following change to
debian/control{,.in}:
--- old/webkit2gtk-2.38.5/debian/control.in 2023-02-15 18:10:55.0
+0100
+++ new/webkit2gtk-2.38.5/debian/control.in 2023-03-11 10:42:47.033477170
+0100
@@ -7,7 +7,7 @@
Alberto Garcia
X-Ubuntu-Use-Langpack: no
Build-Depends: debhelper-compat (= 12),
- ccache [!i386],
+ ccache [!i386 !m68k],
bubblewrap (>= 0.3.1) [!alpha !ia64 !m68k !riscv64 !sh4
!sparc64 !hurd-any !kfreebsd-any],
xdg-dbus-proxy [!alpha !ia64 !m68k !riscv64 !sh4 !sparc64
!hurd-any !kfreebsd-any],
libseccomp-dev [!alpha !ia64 !m68k !riscv64 !sh4 !sparc64
!hurd-any !kfreebsd-any],
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- old/webkit2gtk-2.38.5/debian/control.in 2023-02-15 18:10:55.0
+0100
+++ new/webkit2gtk-2.38.5/debian/control.in 2023-03-11 10:42:47.033477170
+0100
@@ -7,7 +7,7 @@
Alberto Garcia
X-Ubuntu-Use-Langpack: no
Build-Depends: debhelper-compat (= 12),
- ccache [!i386],
+ ccache [!i386 !m68k],
bubblewrap (>= 0.3.1) [!alpha !ia64 !m68k !riscv64 !sh4
!sparc64 !hurd-any !kfreebsd-any],
xdg-dbus-proxy [!alpha !ia64 !m68k !riscv64 !sh4 !sparc64
!hurd-any !kfreebsd-any],
libseccomp-dev [!alpha !ia64 !m68k !riscv64 !sh4 !sparc64
!hurd-any !kfreebsd-any],
Bug#1032404: webkit2gtk: Please add m68k to the list of architectures with limited address space
Control: tags -1 pending On Mon, 2023-03-06 at 11:09 +0100, Alberto Garcia wrote: > Contro: tags -1 pending Let's retry this without a typo ;-). > Thanks, patch applied: > > > https://salsa.debian.org/webkit-team/webkit/-/commit/d0f16590033965c6a00bbb317a8587afb22d9ffd > Thanks a lot! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1032404: webkit2gtk: Please add m68k to the list of architectures with limited address space
Source: webkit2gtk Version: 2.38.5-1 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hi! webkit2gtk needs to built with reduced optimizations on m68k for the build to succeed as gcc runs out of memory at some point. Thus, please add m68k to the following list of architectures in debian/rules: --- debian/rules.orig 2023-02-15 18:10:55.0 +0100 +++ debian/rules2023-03-06 07:45:52.437878152 +0100 @@ -63,7 +63,7 @@ endif # Lower memory requirements on architectures with only 2 GB address space -ifneq (,$(filter $(DEB_HOST_ARCH),mips mipsel sh4)) +ifneq (,$(filter $(DEB_HOST_ARCH),m68k mips mipsel sh4)) CFLAGS := $(CFLAGS:-g1=-g0) CFLAGS := $(CFLAGS:-O2=-Os) CPPFLAGS += --param ggc-min-expand=10 I'm also attaching a patch. Note: There is a second issue on m68k which makes the build fail due to incorrect alignment. This issue will be addressed in a different manner hopefully soon by switching the default alignment on m68k to 32 bits. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2023-02-15 18:10:55.0 +0100 +++ debian/rules2023-03-06 07:45:52.437878152 +0100 @@ -63,7 +63,7 @@ endif # Lower memory requirements on architectures with only 2 GB address space -ifneq (,$(filter $(DEB_HOST_ARCH),mips mipsel sh4)) +ifneq (,$(filter $(DEB_HOST_ARCH),m68k mips mipsel sh4)) CFLAGS := $(CFLAGS:-g1=-g0) CFLAGS := $(CFLAGS:-O2=-Os) CPPFLAGS += --param ggc-min-expand=10
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Hello! On Sat, 2023-02-25 at 23:31 +0100, Amr Ibrahim wrote: > On gnome-shell with gnome-shell-extension-appindicator installed, the app > starts hidden in the background without any window or an icon on the dash. > > Its appindicator (tray icon) in the top panel only offers to quit the > application, however, double-clicking on the appindicator brings the app to > the > foreground. > > The correct behaviour should be that the app normally starts in the > foreground, > and its appindicator offers to show/hide the app in the foreground/background. AusweisApp2 is not a GNOME application but a Qt application and therefore I don't think you can expect the application to show GNOME-specific behavior. Unless upstream (CC'ed) wants to change this behavior in any way, I don't see any chance for this to be changed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1031647: git-annex: Bogus build dependency whitelist results in FTBFS on m68k
Hi Joey! On Thu, 2023-02-23 at 12:27 -0400, Joey Hess wrote: > Sean Whitton wrote: > > Joey, do you know why d/control restricts these build deps as it does? > > IIRC some of those deps are or were not available on some architectures > like m68k. And the deps used to be gated behind the webapp build flag, > so it would still build on those architectures without them installed. FWIW, adding m68k to the architecture list makes the package build fine. So, either way, I think m68k should be enabled to use all the possible build dependencies and doesn't need any limitation. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1031647: git-annex: Bogus build dependency whitelist results in FTBFS on m68k
Source: git-annex Version: 10.20230126-1 Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello! git-annex currently FTBFS on m68k with an error message that indicates that some build dependencies are missing: Configuring git-annex-10.20230126... Setup: Encountered missing or private dependencies: clientsession, wai, wai-extra, warp >=3.2.8, warp-tls >=3.2.2, yesod >=1.4.3, yesod-core >=1.6.0, yesod-form >=1.4.8, yesod-static >=1.5.1 Looking at debian/control, these build dependencies are for some reason only enabled for a subset of architectures, namely those where the build dependency doesn't arise: --- debian/control.old 2023-02-13 19:07:12.0 +0100 +++ debian/control 2023-02-19 19:37:53.133167401 +0100 @@ -34,16 +34,16 @@ libghc-hinotify-dev (>= 0.3.10) [linux-any], libghc-dbus-dev (>= 0.10.7) [linux-any], libghc-fdo-notify-dev (>= 0.3) [linux-any], - libghc-yesod-dev (>= 1.2.6.1) [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-yesod-core-dev (>= 1.6.0)[i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-yesod-form-dev (>= 1.3.15) [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-yesod-static-dev (>= 1.2.4) [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-shakespeare-dev (>= 2.0.0) [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-clientsession-dev[i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-warp-dev (>= 3.0.0.5)[i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-warp-tls-dev [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-wai-dev [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], - libghc-wai-extra-dev[i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 mips mips64el mipsel powerpc ppc64el s390x], + libghc-yesod-dev (>= 1.2.6.1), + libghc-yesod-core-dev (>= 1.6.0), + libghc-yesod-form-dev (>= 1.3.15), + libghc-yesod-static-dev (>= 1.2.4), + libghc-shakespeare-dev (>= 2.0.0), + libghc-clientsession-dev, + libghc-warp-dev (>= 3.0.0.5), + libghc-warp-tls-dev, + libghc-wai-dev, + libghc-wai-extra-dev, libghc-dav-dev (>= 1.0), libghc-persistent-dev (>= 2.8.1), libghc-persistent-template-dev, Thus, I would suggest removing the white-list and enabling the build dependencies for all architectures. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1030053: rustc: Please add patch to fix FTBFS on sparc64
Source: rustc
Version: 1.64.0+dfsg1-1~exp3
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Hi!
The attached patch is a backport of the commit in [1] which fixes the
rustix (and therefore rustc) FTBFS on sparc64 [2].
Could you apply it for the next rustc upload for version 1.64.x?
Thanks,
Adrian
> [1]
> https://github.com/bytecodealliance/rustix/commit/85ed94efa3d4ce05ba7edaacc78b37cd8fbf6793
> [2]
> https://buildd.debian.org/status/fetch.php?pkg=rustc=sparc64=1.64.0%2Bdfsg1-1%7Eexp3=1674399404=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/libc/process/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/libc/process/types.rs
@@ -199,7 +199,12 @@ pub enum Signal {
target_os = "openbsd",
all(
any(target_os = "android", target_os = "linux"),
-any(target_arch = "mips", target_arch = "mips64"),
+any(
+target_arch = "mips",
+target_arch = "mips64",
+target_arch = "sparc",
+target_arch = "sparc64"
+),
)
)))]
Stkflt = c::SIGSTKFLT,
@@ -276,7 +281,12 @@ impl Signal {
target_os = "openbsd",
all(
any(target_os = "android", target_os = "linux"),
-any(target_arch = "mips", target_arch = "mips64"),
+any(
+target_arch = "mips",
+target_arch = "mips64",
+target_arch = "sparc",
+target_arch = "sparc64"
+),
)
)))]
c::SIGSTKFLT => Some(Self::Stkflt),
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/libc/termios/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/libc/termios/types.rs
@@ -704,6 +704,8 @@ pub const B200: Speed = c::B200;
/// `B250`
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
@@ -715,6 +717,8 @@ pub const B250: Speed = c::B250;
/// `B300`
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
@@ -726,6 +730,8 @@ pub const B300: Speed = c::B300;
/// `B350`
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
@@ -737,6 +743,8 @@ pub const B350: Speed = c::B350;
/// `B400`
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/linux_raw/termios/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/linux_raw/termios/types.rs
@@ -338,15 +338,19 @@ pub const B150: Speed = linux_raw_sy
pub const B200: Speed = linux_raw_sys::general::B200;
/// `B250`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
pub const B250: Speed = linux_raw_sys::general::B250;
/// `B300`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
pub const B300: Speed = linux_raw_sys::general::B300;
/// `B350`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
pub const B350: Speed = linux_raw_sys::general::B350;
/// `B400`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
pub const B400: Speed = linux_raw_sys::general::B400;
/// `CSIZE`
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/termios/constants.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/termios/constants.rs
@@ -45,6 +45,8 @@ pub use imp::termios::types::B200;
)))]
pub use imp::termios::types::B250;
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
@@ -54,6 +56,8 @@ pub use imp::termios::types::B250;
)))]
pub use imp::termios::types::B300;
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly&
Bug#1029718: pydevd: Please update test exclusions for big-endian targets
Source: pydevd Version: 2.9.5+ds-2 Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello! The attached patch updates the exclusion lists for 32-bit and 64-bit big-endian targets. For example, on ppc64 and sparc64, the test failures are exactly the same as on s390x which is also 64-bit big-endian. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- pydevd2/pydevd-2.9.5+ds/debian/get_test_exclusions 2023-01-03 10:28:48.0 -0800 +++ pydevd/pydevd-2.9.5+ds/debian/get_test_exclusions 2023-01-26 08:15:12.142579087 -0800 @@ -91,8 +91,24 @@ tests_python/test_debugger_json.py::test_function_breakpoints_async ) -# s390x fails even more disastrously -if [ $arch = s390x ] +# 32-bit big-endian targets test exclusion list +if [ $arch = hppa -o $arch = m68k -o $arch = powerpc ] +then + EXCLUDES+=( + tests_python/test_debugger.py::test_gevent + tests_python/test_debugger.py::test_gevent_remote + tests_python/test_debugger_json.py::test_wait_for_attach_gevent + tests_python/test_debugger_json.py::test_gevent_show_paused_greenlets[True] + tests_python/test_debugger_json.py::test_gevent_show_paused_greenlets[False] + tests_python/test_debugger_json.py::test_gevent_subprocess_not_python + tests_python/test_debugger_json.py::test_gevent_subprocess_python + tests_python/test_debugger_json.py::test_notify_gevent + tests_python/test_utilities.py::test_gevent_notify + ) +fi + +# 64-bit big-endian targets test exclusion list +if [ $arch = ppc64 -o $arch = s390x -o $arch = sparc64 ] then EXCLUDES+=( tests_python/test_debugger.py::test_case_13
Bug#1022764: ffmpeg: Please disable checkasm-sw_scale on ppc64 as well
Hello! On 10/25/22 13:15, John Paul Adrian Glaubitz wrote: Like with ppc64el, the test checkasm-sw_scale fails on ppc64. Could you disable it on ppc64 as well? Note: filter-overlay_yuv420p10 needs to be disabled on ppc64 as well since it's a big-endian target. The attached patch makes the appropriate changes to debian/rules. Any chance this could be fixed with the next upload? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1028624: libdeflate: Please build with -O1 on alpha to fix FTBFS
Source: libdeflate Version: 1.14-1 Severity: normal Tags: patch User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-al...@lists.debian.org Hi! libdeflate currently FTBFS on alpha due to linker issues: cc -o libdeflate.so.0 -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now -fprofile-generate -O2 -fomit-frame-pointer -std=c99 -I. -Wall -Wundef -Wdeclaration-after-statement -Wimplicit-fallthrough -Wmissing-prototypes -Wpedantic -Wshadow -Wstrict-prototypes -Wvla -g -O2 -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -Wformat -Werror=format-security -fprofile-generate -fvisibility=hidden -D_ANSI_SOURCE \ -Wl,-soname=libdeflate.so.0 -shared lib/deflate_decompress.shlib.o lib/utils.shlib.o lib/arm/cpu_features.shlib.o lib/x86/cpu_features.shlib.o lib/deflate_compress.shlib.o lib/adler32.shlib.o lib/zlib_decompress.shlib.o lib/zlib_compress.shlib.o lib/crc32.shlib.o lib/gzip_decompress.shlib.o lib/gzip_compress.shlib.o lib/deflate_compress.shlib.o: in function `deflate_choose_match': ./lib/deflate_compress.c:2185:(.text+0x832c): relocation truncated to fit: GPRELHIGH against `.rodata' ./lib/deflate_compress.c:2185:(.text+0xa28c): relocation truncated to fit: GPRELHIGH against `.rodata' ./lib/deflate_compress.c:2185:(.text+0xbfa0): relocation truncated to fit: GPRELHIGH against `.rodata' collect2: error: ld returned 1 exit status This problem can be worked around by building the source -O1 which is what the attached patch does. Could you apply it for the next upload? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=libdeflate=alpha=1.14-1=1673418504=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2022-10-03 13:55:19.0 +0200 +++ debian/rules2023-01-13 16:48:12.970221727 +0100 @@ -4,6 +4,10 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all +ifeq (alpha,$(DEB_HOST_ARCH)) + export DEB_CFLAGS_MAINT_APPEND=-O1 +endif + %: dh $@
Bug#1028484: java-common: Please add powerpc to the list of openjdk-17 architectures
Source: java-common Version: 0.73 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hi! For some reason, powerpc is not in the list of openjdk-17 architectures [1] despite openjdk-17 building fine on powerpc [2]. Could you enable openjdk-17 for powerpc for the next upload? Thanks, Adrian > [1] > https://salsa.debian.org/java-team/java-common/-/blob/master/debian/java_defaults.mk#L4 > [2] https://buildd.debian.org/status/package.php?p=openjdk-17=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64
Hi! On 1/11/23 19:45, John Paul Adrian Glaubitz wrote: Attaching a patch which modifies debian/rules accordingly so that the build dependencies are corrected after running "debian/rules debian/control". Please consider including it for the next upload. Oops, I just realized I forgot to add the line for "llvm". Please find an updated patch. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2022-12-29 23:21:43.0 + +++ debian/rules 2023-01-11 18:53:56.537857661 + @@ -688,7 +688,7 @@ else ifeq "$(ALLOW_CLANG)" "y" ifeq "$(CLANG_VERSION)" "default" - BUILD_DEPS += , llvm [$(OOO_LE_ARCHS)] + BUILD_DEPS += , llvm [$(filter-out alpha ia64,$(OOO_LE_ARCHS))] else BUILD_DEPS += , llvm-$(CLANG_VERSION)-linker-tools [$(OOO_LE_ARCHS)] endif @@ -766,7 +766,7 @@ ifeq "$(CLANG_VERSION)" "default" export LO_CLANG_CC=clang export LO_CLANG_CXX=clang++ - BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out armel ppc64el,$(OOO_LE_ARCHS))] + BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out alpha armel ia64 ppc64el,$(OOO_LE_ARCHS))] # see #963162, #963167 which apparently don't exist on 11 BUILD_DEPS += , clang (>= 1:11) [armel] else
Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64
Control: tags -1 +patch Hi! Attaching a patch which modifies debian/rules accordingly so that the build dependencies are corrected after running "debian/rules debian/control". Please consider including it for the next upload. Thanks a lot! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2022-12-29 23:21:43.0 + +++ debian/rules 2023-01-11 18:40:30.535026543 + @@ -766,7 +766,7 @@ ifeq "$(CLANG_VERSION)" "default" export LO_CLANG_CC=clang export LO_CLANG_CXX=clang++ - BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out armel ppc64el,$(OOO_LE_ARCHS))] + BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out alpha armel ia64 ppc64el,$(OOO_LE_ARCHS))] # see #963162, #963167 which apparently don't exist on 11 BUILD_DEPS += , clang (>= 1:11) [armel] else
Bug#1028415: libfixmath: powerpc is in the UBSAN_ARCH list despite being unsupported
Hello! On 1/10/23 20:41, Rene Engelhard wrote: Hi, Am 10.01.23 um 20:30 schrieb John Paul Adrian Glaubitz: I just noticed that debian/rules adds the powerpc architecture to the UBSAN_ARCH arch list despite powerpc not supporting `__sync_val_compare_and_swap_8 [1]. But libubsan.so exists, which was what was intended with this variable... Removing it there would effectively disabling building and running the tests... Yes, ubsan.so exists. But in some cases (i.e. some sanitizer checks) it requires __sync_val_compare_and_swap_8 which is not available on 32-bit PowerPC. However, __sync_val_compare_and_swap_8 is deprecated anyway and has been replaced with __atomic_compare_exchange(), so I assume that the ubsan version in gcc-12 is outdated. I think in LLVM, we actually replaced __sync_val_compare_and_swap with __atomic_ compare_exchange() at some point for this particular reasons. Adrian [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1028415: libfixmath: powerpc is in the UBSAN_ARCH list despite being unsupported
Source: libfixmath Version: 0~20220222-3 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hello! I just noticed that debian/rules adds the powerpc architecture to the UBSAN_ARCH arch list despite powerpc not supporting `__sync_val_compare_and_swap_8 [1]. This results in libfixmath trying to build the testsuite and consequently FTBFS [2]: [ 94%] Linking C executable tests_rn08 /usr/bin/cmake -E cmake_link_script CMakeFiles/tests_rn08.dir/link.txt --verbose=1 /usr/bin/cc -Wall -pedantic -Wextra -Werror=return-type -Wl,-z,relro -fsanitize=undefined CMakeFiles/tests_rn08.dir/tests/tests.c.o CMakeFiles/tests_rn08.dir/tests/tests_basic.c.o CMakeFiles/tests_rn08.dir/tests/tests_lerp.c.o CMakeFiles/tests_rn08.dir/tests/tests_macros.c.o CMakeFiles/tests_rn08.dir/tests/tests_sqrt.c.o CMakeFiles/tests_rn08.dir/tests/tests_str.c.o -o tests_rn08 liblibfixmath_rn08.a -lm -latomic /usr/bin/ld: /usr/lib/gcc/powerpc-linux-gnu/12/libubsan.so: undefined reference to `__sync_val_compare_and_swap_8' collect2: error: ld returned 1 exit status Could you please remove "powerpc" from the UBSAN_ARCH list? Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 > [2] > https://buildd.debian.org/status/fetch.php?pkg=libfixmath=powerpc=0%7E20220222-3=1672966865=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1028200: glibc: FTBFS on alpha due to buggy GL(dl_phdr) and GL(dl_phnum) [BZ #29864]
Source: glibc
Version: 2.36-8
Severity: normal
Tags: patch upstream
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-al...@lists.debian.org
Hello!
glibc fails to build from source on alpha with many testsuite failures [1]
due to a regression introduced in glibc 2.34 [2].
According to the discussion on the libc-alpha mailing list, this issue
affects multiple architectures for static builds. It just happens that
it causes segmentation faults on alpha [3].
A proposed patch by Adhemveral Zanella has been posted on the list [4]
but not been merged yet. I tested the first version of the patch [3] and
can confirm that it works. I will test the posted version [4] now.
Adhemerval said that he plans to backport the patch down to 2.34, so it
will eventually show up in 2.36 as well. Either way, it might be a good
idea to already carry the patch in Debian but I'm not sure.
Thanks,
Adrian
> [1] https://buildd.debian.org/status/logs.php?pkg=glibc=alpha
> [2] https://sourceware.org/pipermail/libc-alpha/2023-January/15.html
> [3] https://sourceware.org/pipermail/libc-alpha/2023-January/144452.html
> [4] https://sourceware.org/pipermail/libc-alpha/2023-January/144457.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- Begin Message ---
The 73fc4e28b9464f0e refactor did not add the GL(dl_phdr) and
GL(dl_phnum) for static build, relying on the __ehdr_start symbol,
which is always added by the static linker, to get the correct values.
This is problematic in some ways:
- The segment may see its in-memory size differ from its in-file
size (or the binary may have holes). The Linux has fixed is to
provide concise values for both AT_PHDR and AT_PHNUM (commit
0da1d5002745c - "fs/binfmt_elf: Fix AT_PHDR for unusual ELF files")
- Some archs (alpha for instance) the hidden weak reference is not
correctly pulled by the static linker and __ehdr_start address
end up being 0, which makes GL(dl_phdr) and GL(dl_phnum) have both
invalid values (and triggering a segfault later on libc.so while
accessing TLS variables).
The safer fix is to just restore the previous behavior to setup
GL(dl_phdr) and GL(dl_phnum) for static based on kernel auxv. The
__ehdr_start fallback can also be simplified by not assuming weak
linkage (as for PIE).
The libc-static.c auxv init logic is moved to dl-support.c, since
the later is build without SHARED and then GLRO macro is defined
to access the variables directly.
The _dl_phdr is also assumed to be always non NULL, since an invalid
NULL values does not trigger TLS initialization (which is used in
various libc systems).
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
---
csu/libc-start.c| 21 --
csu/libc-tls.c | 25 ++--
elf/dl-support.c| 52 -
sysdeps/unix/sysv/linux/dl-parse_auxv.h | 1 +
4 files changed, 46 insertions(+), 53 deletions(-)
diff --git a/csu/libc-start.c b/csu/libc-start.c
index 543560f36c..bfeee6d851 100644
--- a/csu/libc-start.c
+++ b/csu/libc-start.c
@@ -262,28 +262,7 @@ LIBC_START_MAIN (int (*main) (int, char **, char **
MAIN_AUXVEC_DECL),
}
# endif
_dl_aux_init (auxvec);
- if (GL(dl_phdr) == NULL)
# endif
-{
- /* Starting from binutils-2.23, the linker will define the
- magic symbol __ehdr_start to point to our own ELF header
- if it is visible in a segment that also includes the phdrs.
- So we can set up _dl_phdr and _dl_phnum even without any
- information from auxv. */
-
- extern const ElfW(Ehdr) __ehdr_start
-# if BUILD_PIE_DEFAULT
- __attribute__ ((visibility ("hidden")));
-# else
- __attribute__ ((weak, visibility ("hidden")));
- if (&__ehdr_start != NULL)
-# endif
-{
- assert (__ehdr_start.e_phentsize == sizeof *GL(dl_phdr));
- GL(dl_phdr) = (const void *) &__ehdr_start + __ehdr_start.e_phoff;
- GL(dl_phnum) = __ehdr_start.e_phnum;
-}
-}
__tunables_init (__environ);
diff --git a/csu/libc-tls.c b/csu/libc-tls.c
index ca4def2613..51d3cf99bf 100644
--- a/csu/libc-tls.c
+++ b/csu/libc-tls.c
@@ -119,19 +119,18 @@ __libc_setup_tls (void)
__tls_pre_init_tp ();
/* Look through the TLS segment if there is any. */
- if (_dl_phdr != NULL)
-for (phdr = _dl_phdr; phdr < &_dl_phdr[_dl_phnum]; ++phdr)
- if (phdr->p_type == PT_TLS)
- {
- /* Remember the values we need. */
- memsz = phdr->p_memsz;
- filesz = phdr->p_filesz;
- initimage = (void *) phdr->p_vaddr + main_map->l_addr;
- align = phdr->p_align;
- if (phdr->p_align > max_align)
- max_align = phdr->p_align;
- break;
- }
+ for (p
Bug#1028195: gcc-12: Please drop build dependency on gdc-12 on unsupported D targets
Source: gcc-12 Version: 12.2.0-14 Severity: normal Hello! Similar to #1026201, gcc-12 is now BD-Uninstallable on a number of targets since there is no gdc-12 compiler available for the bootstrap. Thus, please disable D support for the affected architectures so that gcc-12 can build there again. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026201 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1027974: linux: FTBFS on alpha due to unversioned symbols
Source: linux Version: 6.0.12-1 Severity: normal User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-al...@lists.debian.org Hello! Since upstream version 5.19.x, src:linux FTBFS on alpha due to unversioned symbols [1]: > ABI is not completely versioned! Refusing to continue. > Unversioned symbols: > strcat module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strcpy module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strncat module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strncpy module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > Can't read ABI reference. ABI not checked! A local build showed that this is still present in the latest package version 6.0.12-1. According to this comment [2], this issue can be fixed by adding the appropriate include to arch/$ARCH/include/asm/asm-prototypes.h but the include for is already present, so I'm not sure what the actual problem is. I'm reporting this issue to hopefully get some feedback on what else to try to fix this issue. I'm happy to provide any patches once I know what to fix. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=linux=alpha=5.19.6-1=1663530012=0 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908161#10 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1027168: onetbb: Please add patch to fix FTBFS on sh4
Source: onetbb
Version: 2021.8.0-1
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org
Hi!
onetbb currently FTBFS on sh4 because the source code assumes that the target
FPU supports all four rounding modes (FE_TONEAREST, FE_DOWNWARD, FE_UPWARD and
FE_TOWARDZERO) which is not the case on sh4 which supports FE_TONEAREST and
FE_TOWARDZERO only [1].
The attached patch fixes these assumptions for sh4 and makes the code build. I
have already patched and uploaded the package to the unreleased distribution
so that the mold linker can build on sh4 as well.
I will forward the patch later after reformating it.
Thanks,
Adrian
> [1] https://sourceware.org/pipermail/libc-alpha/2012-May/031608.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- onetbb-2021.8.0.orig/test/common/fp_control.h
+++ onetbb-2021.8.0/test/common/fp_control.h
@@ -112,7 +112,11 @@ inline void SetRoundingMode ( int mode )
#include
+#if defined(__sh__)
+const int RND_MODE_MASK = FE_TONEAREST | FE_TOWARDZERO;
+#else
const int RND_MODE_MASK = FE_TONEAREST | FE_DOWNWARD | FE_UPWARD |
FE_TOWARDZERO;
+#endif
const int NumSseModes = 1;
const int SseModes[NumSseModes] = { 0 };
@@ -125,8 +129,13 @@ inline void SetSseMode ( int ) {}
#endif /* Other archs */
+#if defined(__sh__)
+const int NumRoundingModes = 2;
+const int RoundingModes[NumRoundingModes] = { FE_TONEAREST, FE_TOWARDZERO };
+#else
const int NumRoundingModes = 4;
const int RoundingModes[NumRoundingModes] = { FE_TONEAREST, FE_DOWNWARD,
FE_UPWARD, FE_TOWARDZERO };
+#endif
const int numFPModes = NumRoundingModes*NumSseModes;
inline void SetFPMode( int mode ) {
Bug#1027099: gccrs-13: Broken symlink /usr/bin/gccrs-13
Source: gcc-13
Version: 13-20221226-1
Severity: normal
User: debian-i...@lists.debian.org
Usertags: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org
Hello!
I just gave it a first try with the gccrs package on ia64 and it turns
out the gccrs-13 symlink in /usr/bin is broken as shown below. Manually
invoking ia64-linux-gnu-gccrs-13 works without any problems and I can
actually compile a working program.
glaubitz@electron:~$ dpkg -l gccrs-13
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==-=--=
ii gccrs-13 13-20221226-1 ia64 GNU Rust compiler
glaubitz@electron:~$ gccrs-13
-bash: gccrs-13: command not found
glaubitz@electron:~$ ls -l /usr/bin/gccrs-13
lrwxrwxrwx 1 root root 21 Dec 26 16:33 /usr/bin/gccrs-13 ->
ia64-linux-gnu-grs-13
glaubitz@electron:~$ /usr/bin/ia64-linux-gnu-gccrs-13
ia64-linux-gnu-gccrs-13: fatal error: no input files
compilation terminated.
glaubitz@electron:~$
Proof that gccrs works on ia64:
glaubitz@electron:~$ cat rust42.rs
fn main() -> i32 {
return 42;
}
glaubitz@electron:~$ ia64-linux-gnu-gccrs-13
-frust-incomplete-and-experimental-compiler-do-not-use rust42.rs -o rust42
glaubitz@electron:~$ ./rust42
glaubitz@electron:~$ echo $?
42
glaubitz@electron:~$
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1026362: RFS: binutils-sh-elf/2 -- GNU binary utilities for embedded SuperH devices
Hi John! On 12/19/22 02:08, John Scott wrote: Package: sponsorship-requests Severity: normal X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net debian-sup...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "binutils-sh-elf": * Package name : binutils-sh-elf Version : 2 (this is a native source package) * URL : https://sourceware.org/binutils/ * License : GPL-3+ * Vcs : https://salsa.debian.org/electronics-team/toolchains/binutils-sh-elf (but see below) Section : devel I'm going to upload this now. However, I can't tell you when this will be accepted into unstable due to the unavailability of ftp-master.debian.org. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices
Hi John! On 12/18/22 18:06, John Scott wrote: On Sun, 2022-12-18 at 08:49 +0100, John Paul Adrian Glaubitz wrote: I assume you're missing libreadline-dev from BuildDepends. You are, of course, absolutely right. I forgot to build in a clean environment. This has been fixed in a new upload to mentors.debian.net and a build in a clean environment succeeds now. As a heads-up: The ftp-master server is currently down, so I can't upload anything, see: https://lists.debian.org/debian-infrastructure-announce/2022/12/msg2.html Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices
Hello John! On 12/18/22 08:17, John Scott wrote: Control: owner -1 glaub...@physik.fu-berlin.de On Sun, 2022-12-18 at 08:09 +0100, John Paul Adrian Glaubitz wrote: I can sponsor this upload. Thanks so much! Please go ahead whenever you're ready. The package does not build in a clean unstable environment with an additional experimental repository on top, see: checking whether fwrite_unlocked is declared... no checking for readline in -lreadline... no configure: error: the required "readline" library is missing make[3]: *** [Makefile:10531: configure-sim] Error 1 make[3]: *** Waiting for unfinished jobs yes checking whether getchar_unlocked is declared... yes checking whether getc_unlocked is declared... yes I assume you're missing libreadline-dev from BuildDepends. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices
Hello John! On 12/18/22 06:22, John Scott wrote: Package: sponsorship-requests Severity: normal X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net debian-sup...@lists.debian.org Dear mentors and fellow Electronics Team members, I am looking for a sponsor for my package "gcc-sh-elf": * Package name : gcc-sh-elf Version : 5 * License : GPL-3+ * Vcs : https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf Section : devel I can sponsor this upload. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1025176: libicu71 missing on SH4 port
> On Dec 16, 2022, at 7:29 PM, John Paul Adrian Glaubitz > wrote: > > > > >>> On Dec 16, 2022, at 7:18 PM, Jérémy Lal wrote: >>> >> Source: icu >> Followup-For: Bug #1025176 >> X-Debbugs-Cc: debian-sup...@lists.debian.org >> >> Considering the needed porting work is only a few lines: >> https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform >> >> sh4 porters might be able to help here. > > icu or python-greenlet? The former has been built on sh4: Looking at the rest of the bug report The reason why boost1.74 is not up to date is this bug: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016904 The reason why gdb is missing is this bug report: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576242 See also: > https://github.com/glaubitz/binutils-gdb/tree/linux-sh There is no known issue with icu on sh4. Adrian
Bug#1025176: libicu71 missing on SH4 port
> On Dec 16, 2022, at 7:18 PM, Jérémy Lal wrote: > > Source: icu > Followup-For: Bug #1025176 > X-Debbugs-Cc: debian-sup...@lists.debian.org > > Considering the needed porting work is only a few lines: > https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform > > sh4 porters might be able to help here. icu or python-greenlet? The former has been built on sh4: > https://buildd.debian.org/status/package.php?p=icu=sid Adrian
Bug#1026201: gcc-13: Please drop build dependency on gdc-12 on unsupported D targets
Source: gcc-13 Version: 13-20221214-1 Severity: normal Hello! Both gcc-snapshot and gcc-13 have a build-dependency on gdc-12 which we haven't enabled on most ports architectures. Could this build dependency be dropped for the architectures that are BD-Uninstallable for gcc-13 [1] and gcc-snapshot [2]? We don't really need D language support in Debian Ports as the language has no standard library support for most architectures. Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=gcc-13=experimental > [2] https://buildd.debian.org/status/package.php?p=gcc-snapshot=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
