Bug#1068164: bart: please add support for loong64
Thanks wuruilong! this will be fixed with the next upload. Best, Martin Am Montag, dem 01.04.2024 um 07:19 +0200 schrieb Andreas Tille: > Hi Martin, > > can you please comment on this? > > Kind regards > Andreas. > > Am Mon, Apr 01, 2024 at 01:22:03AM + schrieb wuruilong: > > Source: bart > > Severity: normal > > User: debian-loonga...@lists.debian.org > > Usertags: loong64 > > X-Debbugs-Cc: wuruil...@loongson.cn > > > > Dear Maintainer, > > > > bart failed to compile on loongarch, the attachment fixes the bug > > > > wuruilong > > > > -- System Information: > > Debian Release: trixie/sid > > APT prefers unreleased > > APT policy: (500, 'unreleased'), (500, 'unstable') > > Architecture: loong64 (loongarch64) > > > > Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads) > > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > > Shell: /bin/sh linked to /usr/bin/dash > > Init: unable to detect > > > --- bart-0.9.00/debian/rules2024-03-30 06:12:54.235656645 + > > +++ bart-0.9.00/debian/rules2023-12-11 17:42:37.0 + > > @@ -12,7 +12,7 @@ > > export PARALLEL_NJOBS=1 > > > > # some archs require turning of some optimizations > > -NOEXPOPT_ARCHS=arm64 ppc64el s390x ia64 powerpc ppc64 riscv64 loong64 > > +NOEXPOPT_ARCHS=arm64 ppc64el s390x ia64 powerpc ppc64 riscv64 > > > > # turn off hanging tests on i386 > > ifeq ($(DEB_BUILD_ARCH), i386) > > > ___ > > Debian-med-packaging mailing list > > debian-med-packag...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > >
Bug#1058276: bart-view: FTBFS: (.text+0xa4e): undefined reference to `shared_obj_destroy'
Am Mittwoch, dem 10.01.2024 um 08:16 +0100 schrieb Andreas Tille: > Hi Martin, > > I tried to open an issue upstream but it seems the repository does not > feature submitting issues. Can you have a look please? > > Kind regards > Andreas. > Hi Andreas, I just tagged a new upstream release and also prepared a new Debian package. Please take a look. Martin
Bug#1058276: bart-view: FTBFS: (.text+0xa4e): undefined reference to `shared_obj_destroy'
Hi Andreas, thanks. I missed this. I will look at this tomorrow. Martin Am Mittwoch, dem 10.01.2024 um 08:16 +0100 schrieb Andreas Tille: > Hi Martin, > > I tried to open an issue upstream but it seems the repository does not > feature submitting issues. Can you have a look please? > > Kind regards > Andreas. >
Bug#918914: add -fstack-clash-protection to default buildflags
On Wed, 21 Jun 2023 17:57:41 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= wrote: > Am Fri, May 27, 2022 at 09:48:05AM +0200 schrieb Guillem Jover: > > I don't think the issues presented by Florian were ever resolved, so > > my concerns in https://bugs.debian.org/918914#15 would still apply, > > even though Ubuntu has enabled this, but they have a different set of > > architectures. > > I worked with Lucas last month who made an archive rebuild on amd64, the list > of FTBFSes is very small: http://qa-logs.debian.net/2023/05/24/ > > Since dpkg-buildflags supports different flags per arch, my proposal to be > posted to debian-devel would be to initially enable this for amd64 only > and solicit feedback from porters for other archs. Based on their feedback > this can then be enabled for amd64 and the other archs deemed compatible. > Is there an upstream bug report for the GCC issue affecting wine and gdb-mingw-64 ? Martin
Bug#1016625: bart-cuda: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'
Am Mittwoch, den 24.08.2022, 00:10 +0530 schrieb Nilesh Patra: > Control: reassign -1 nvidia-cuda-toolkit/11.4.3-4 > Control: retitle -1 Please update nvidia-cuda-toolkit to 11.5.1 or later > > > On 8/23/22 23:58, Martin Uecker wrote: > > Am Dienstag, den 23.08.2022, 23:45 +0530 schrieb Nilesh Patra: > > > On Tue, Aug 23, 2022 at 07:00:44PM +0200, Martin Uecker wrote: > > > > I think I fixed this. At least it compiles locally in > > > > a sid pbuilder environment, but I needed to build-depend > > > > on gcc-10. > > > > > > gcc-10 will be removed from the archive some day, so this cannot > > > be a permanent fix. > > > > > > > It is a workaround for another cuda problem, which > > apparently can not deal with newer glibc headers and > > which is fixed in 11.5.1 not yet in Debian. > > In that case, I am re-assigning this to nvidia-cuda-toolkit. > There is 11.5.2 in exp but it needs to get to unstable. For reference, the "other cuda problem" mentioned above is the same as this: https://forums.developer.nvidia.com/t/cuda-11-5-samples-throw-multiple-error-attribute-malloc-does-not-take-arguments/192750
Bug#1016625: bart-cuda: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'
Am Dienstag, den 23.08.2022, 23:45 +0530 schrieb Nilesh Patra: > On Tue, Aug 23, 2022 at 07:00:44PM +0200, Martin Uecker wrote: > > I think I fixed this. At least it compiles locally in > > a sid pbuilder environment, but I needed to build-depend > > on gcc-10. > > gcc-10 will be removed from the archive some day, so this cannot > be a permanent fix. > It is a workaround for another cuda problem, which apparently can not deal with newer glibc headers and which is fixed in 11.5.1 not yet in Debian.
Bug#1016625: bart-cuda: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'
I think I fixed this. At least it compiles locally in a sid pbuilder environment, but I needed to build-depend on gcc-10. Martin Am Sonntag, den 07.08.2022, 13:06 +0530 schrieb Nilesh Patra: > Hi Martin, > > [CC'ing both your email addresses since I don't know which one you use] > > Since this is your package, could you consider taking a look please? > > On Thu, 04 Aug 2022 04:31:30 +0200 Andreas Beckmann wrote: > > Source: bart-cuda > > Version: 0.7.00-5 > > Severity: serious > > Tags: ftbfs > > Justification: fails to build from source > > > > Hi, > > > > bart-cuda recently started to FTBFS in sid, while it still succeeds in > > testing. > > > > /usr//bin/nvcc -DUSE_CUDA -Xcompiler -fPIC -Xcompiler -fopenmp -O3 > > -I/build/bart-cuda- > > 0.7.00/src/ -m64 -ccbin gcc -c > > /build/bart-cuda-0.7.00/src/wavelet/wl3-cuda.cu -o /build/bart- > > cuda-0.7.00/src/wavelet/wl3-cuda.o > > /usr/include/c++/10/type_traits:71:52: error: redefinition of 'constexpr > > const _Tp > > std::integral_constant<_Tp, __v>::value' > >71 | template > > |^ > > > > /usr/include/c++/10/type_traits:59:29: note: 'constexpr const _Tp value' > > previously declared > > here > >59 | static constexpr _Tp value = __v; > > | ^ > > make[2]: *** [Makefile:332: /build/bart-cuda-0.7.00/src/wavelet/wl3-cuda.o] > > Error 1 > > > > Andreas
Bug#1017849: gcc-11: ICE with LTO: internal compiler error: tree code ‘c_maybe_const_expr’ is not supported in LTO streams
Package: gcc-11
Version: 11.3.0-5
Severity: important
Tags: upstream
X-Debbugs-Cc: ma.uec...@gmail.com
When investigating why BART fails to build with LTO because
GCC crashed, I reduced this to the following test case.
Upstream bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106702
$ cat test.c
extern void bar(int M, int N, float S[(N > M) ? M : N]);
void foo(int M, int N)
{
bar(M, N, 0);
}
$ gcc-11 -I ../src/ -flto test.c
during IPA pass: modref
test.c:8:1: internal compiler error: tree code ‘c_maybe_const_expr’ is not
supported in LTO streams
8 | }
| ^
0x7fa316e01209 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fa316e012bb __libc_start_main_impl
../csu/libc-start.c:389
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
-- System Information:
Debian Release: 11.4
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-16-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gcc-11 depends on:
ii binutils 2.38.90.20220713-2
ii cpp-11 11.3.0-5
ii gcc-11-base11.3.0-5
ii libc6 2.34-3
ii libcc1-0 12.1.0-8
ii libgcc-11-dev 11.3.0-5
ii libgcc-s1 12.1.0-8
ii libgmp10 2:6.2.1+dfsg1-1
ii libisl23 0.23-1
ii libmpc31.2.0-1
ii libmpfr6 4.1.0-3
ii libstdc++6 10.2.1-6
ii libzstd1 1.5.2+dfsg-1
ii zlib1g 1:1.2.11.dfsg-2+deb11u1
Versions of packages gcc-11 recommends:
ii libc6-dev 2.34-3
Versions of packages gcc-11 suggests:
pn gcc-11-doc
pn gcc-11-locales
pn gcc-11-multilib
-- no debconf information
Bug#1016625: bart-cuda: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'
I will look at this in a couple of days. I think it only needs a std=c++14 or something aded to the nvcc flags. Martin Am Sonntag, den 07.08.2022, 13:06 +0530 schrieb Nilesh Patra: > Hi Martin, > > [CC'ing both your email addresses since I don't know which one you use] > > Since this is your package, could you consider taking a look please? > > On Thu, 04 Aug 2022 04:31:30 +0200 Andreas Beckmann wrote: > > Source: bart-cuda > > Version: 0.7.00-5 > > Severity: serious > > Tags: ftbfs > > Justification: fails to build from source > > > > Hi, > > > > bart-cuda recently started to FTBFS in sid, while it still succeeds in > > testing. > > > > /usr//bin/nvcc -DUSE_CUDA -Xcompiler -fPIC -Xcompiler -fopenmp -O3 > > -I/build/bart-cuda- > > 0.7.00/src/ -m64 -ccbin gcc -c > > /build/bart-cuda-0.7.00/src/wavelet/wl3-cuda.cu -o /build/bart- > > cuda-0.7.00/src/wavelet/wl3-cuda.o > > /usr/include/c++/10/type_traits:71:52: error: redefinition of 'constexpr > > const _Tp > > std::integral_constant<_Tp, __v>::value' > >71 | template > > |^ > > > > /usr/include/c++/10/type_traits:59:29: note: 'constexpr const _Tp value' > > previously declared > > here > >59 | static constexpr _Tp value = __v; > > | ^ > > make[2]: *** [Makefile:332: /build/bart-cuda-0.7.00/src/wavelet/wl3-cuda.o] > > Error 1 > > > > Andreas
Bug#1001916: Info received (Bug#1001916: Info received (missing builds are due to compiler bugs))
GCC bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002505
Bug#1002505: Bug#1001916: Info received (missing builds are due to compiler bugs)
Minimal test case for armel:
# cat BUG.c
extern _Complex float g(int N, int dims[N]);
void f(void)
{
int dims[1];
_Complex float val = g(1, dims);
}
# arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Debian 11.2.0-9) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# arm-linux-gnueabi-gcc BUG.c
during RTL pass: expand
BUG.c: In function 'f':
BUG.c:10:30: internal compiler error: Segmentation fault
10 | _Complex float val = g(1, dims);
| ^~
0xb1393f crash_signal
../../src/gcc/toplev.c:327
0x708398 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1274
0x70c4d4 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1266
0x70c4d4 get_size_range(tree_node*, tree_node**, int)
../../src/gcc/calls.c:1401
0x70c4d4 maybe_warn_rdwr_sizes
../../src/gcc/calls.c:2034
0x70dcb1 initialize_argument_information
../../src/gcc/calls.c:2626
0x70dcb1 expand_call(tree_node*, rtx_def*, int)
../../src/gcc/calls.c:4010
0x8210ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:11287
0x82a9ce expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../src/gcc/expr.c:8519
0x82a9ce store_expr(tree_node*, rtx_def*, int, bool, bool)
../../src/gcc/expr.c:5886
0x82be69 expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5622
0x720bf9 expand_call_stmt
../../src/gcc/cfgexpand.c:2838
0x720bf9 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3871
0x720bf9 expand_gimple_stmt
../../src/gcc/cfgexpand.c:4035
0x726b97 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:6077
0x726b97 execute
../../src/gcc/cfgexpand.c:6761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Bug#1001916: Info received (missing builds are due to compiler bugs)
Minimal test case for armel:
# cat BUG.c
extern _Complex float g(int N, int dims[N]);
void f(void)
{
int dims[1];
_Complex float val = g(1, dims);
}
# arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Debian 11.2.0-9) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# arm-linux-gnueabi-gcc BUG.c
during RTL pass: expand
BUG.c: In function 'f':
BUG.c:10:30: internal compiler error: Segmentation fault
10 | _Complex float val = g(1, dims);
| ^~
0xb1393f crash_signal
../../src/gcc/toplev.c:327
0x708398 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1274
0x70c4d4 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1266
0x70c4d4 get_size_range(tree_node*, tree_node**, int)
../../src/gcc/calls.c:1401
0x70c4d4 maybe_warn_rdwr_sizes
../../src/gcc/calls.c:2034
0x70dcb1 initialize_argument_information
../../src/gcc/calls.c:2626
0x70dcb1 expand_call(tree_node*, rtx_def*, int)
../../src/gcc/calls.c:4010
0x8210ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:11287
0x82a9ce expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../src/gcc/expr.c:8519
0x82a9ce store_expr(tree_node*, rtx_def*, int, bool, bool)
../../src/gcc/expr.c:5886
0x82be69 expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5622
0x720bf9 expand_call_stmt
../../src/gcc/cfgexpand.c:2838
0x720bf9 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3871
0x720bf9 expand_gimple_stmt
../../src/gcc/cfgexpand.c:4035
0x726b97 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:6077
0x726b97 execute
../../src/gcc/cfgexpand.c:6761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Bug#1002505: gcc internal compiler error related to VLAs
Package: gcc-11 Version: 11.2.0-12 GCC 11 crashes on armel und s390x for certain code involving VLAs. Same code builds with older GCC: https://buildd.debian.org/status/package.php?p=bart-view This may also be related to a build failure on i386 for a different package: https://salsa.debian.org/med-team/bart/-/jobs/2121098 I recently filed an upstream bug for a problem which may also be related (but affects x86_64): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770 Best, Martin
Bug#1001916: missing builds are due to compiler bugs
For armel as s390x the compiler crashes due to an internal compiler error with gcc 11. Note, that the same souce code compiles fine on other architectures and did compile also on armel s390x with gcc 10. Martin
Bug#888581: tk8.6: crashes when used as untrusted X client (e.g. ssh -X)
Package: tk8.6 Version: 8.6.6-1+b1 Severity: important Tags: upstream Dear Maintainer, gitk (but affects all tk based programs) crashes when used over untrusted X connenctions. The root cause is a missing error handler for Xlib errors. I submitted an upstream bug with proposed patch 4 years ago, but it has not been adressed, see here: http://core.tcl.tk/tk/tktview?name=502e74e9ad198e5239092356333aceba5c6ab47a -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tk8.6 depends on: ii libc6 2.24-11+deb9u1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype62.6.3-3.2 ii libtcl8.6 8.6.6+dfsg-1+b1 ii libtk8.68.6.6-1+b1 ii libx11-62:1.6.4-3 ii libxext62:1.3.3-1+b2 ii libxft2 2.3.2-1+b2 ii libxss1 1:1.2.2-1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages tk8.6 recommends: ii gnome-terminal [x-terminal-emulator] 3.22.2-1 ii xfce4-terminal [x-terminal-emulator] 0.8.3-1 ii xterm [x-terminal-emulator] 327-2 tk8.6 suggests no packages. -- no debconf information
Bug#851431: ITP: bart-view -- Image viewer for multi-dimensional data (add-on to BART)
Package: wnpp Severity: wishlist Owner: Martin Uecker <martin.uec...@med.uni-goettingen.de> * Package name: bart-view Version : 0.0.01 Upstream Author : Martin Uecker <martin.uec...@med.uni-goettingen.de> * URL : https://github.com/mrirecon/view/ * License : BSD Programming Lang: C Description : Image viewer for multi-dimensional data (add-on to BART) This is a viewer for multi-dimensional complex-valued data. It is useful as an add-on to the Berkeley Advanced Reconstruction Toolbox (BART) for computational Magnetic Resonance Imaging which has been packaged for Debian already. This package will be maintained as part of the Debian Med team.
Bug#762839: bash without importing shell functions from the environment
Samuel Thibault: Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit : Samuel Thibault: Sounds crazy to me. Definitely. This is now out in the wild; exploits which simply replace echo or cat-without-/bin are going to happen. :-/ That's not so easy to exploit. You have to manage to inject those precise variable names. While everybody is looking at bash, isn't this the real the injection part? Why are there still programs which copy stuff from the network into environment without proper sanitation? This bash bug makes this easy to exploit, but it is not hard to imagine that this can confuse other programs in different ways. In fact, there were very similar bugs in the past: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0997 Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#440539: miredo seems to send malformed packages on arm
Package: miredo Version: 1.0.4-2 Severity: important I experimented with miredo on a my nslu2 (embedded arm) machine, but do not get an ipv6 address: [EMAIL PROTECTED]:~/src/miredo-1.0.4# miredo -f miredo[14322]: Starting... miredo[14329]: No reply from Teredo server This works perfectly on my notebook (running ubuntu) behind the same NAT and with the same miredo version. The miredo client seems to send malformed packages and there does not get a reply. Maybe this is an endianess problem? Attached is a small file with captured packages from the NAT. 192.168.1.105 is the NSLU2 and .108 my notebook. Greetings, Martin -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable'), (650, 'testing') Architecture: arm (armv5tel) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-ixp4xx Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages miredo depends on: ii adduser3.102 Add and remove users and groups ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libcap11:1.10-14 support for getting/setting POSIX. ii libjudydebian1 1.0.3-2 C library for creating and accessi ii makedev2.3.1-83 creates device files in /dev miredo recommends no packages. -- no debconf information miredo.cap Description: Binary data
