Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On 21.03.24 07:58, Bastian Blank wrote: On Wed, Mar 20, 2024 at 09:59:31PM +0100, Matthias Klose wrote: Independent of any technical issues, this is a hijacking of a package name. Please revert that change. Okay. Please prepare to take over linux-libc-dev alltogether then, there can be only one copy. please drop the provides: linux-libc-dev-alpha-cross (= 6.7.9-2), linux-libc-dev-amd64-cross (= 6.7.9-2), linux-libc-dev-arm64-cross (= 6.7.9-2), linux-libc-dev-armel-cross (= 6.7.9-2), linux-libc-dev-armhf-cross (= 6.7.9-2), linux-libc-dev-hppa-cross (= 6.7.9-2), linux-libc-dev-i386-cross (= 6.7.9-2), linux-libc-dev-loong64-cross (= 6.7.9-2), linux-libc-dev-m68k-cross (= 6.7.9-2), linux-libc-dev-mips-cross (= 6.7.9-2), linux-libc-dev-mips64-cross (= 6.7.9-2), linux-libc-dev-mips64el-cross (= 6.7.9-2), linux-libc-dev-mips64r6el-cross (= 6.7.9-2), linux-libc-dev-mipsel-cross (= 6.7.9-2), linux-libc-dev-powerpc-cross (= 6.7.9-2), linux-libc-dev-ppc64-cross (= 6.7.9-2), linux-libc-dev-ppc64el-cross (= 6.7.9-2), linux-libc-dev-riscv64-cross (= 6.7.9-2), linux-libc-dev-s390x-cross (= 6.7.9-2), linux-libc-dev-sh4-cross (= 6.7.9-2), linux-libc-dev-sparc64-cross (= 6.7.9-2), linux-libc-dev-x32-cross (= 6.7.9-2)
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Control: reopen -1 On 20.03.24 21:48, Bastian Blank wrote: Hi Not a single piece of evidence of a breakage showed up within the last weeks. I'm therefor closing this bug report. Bastian, sorry for being quiet in the time of the time_t64 transitions. I am re-opening, and CCing lea...@debian.org. Independent of any technical issues, this is a hijacking of a package name. Please revert that change. Matthias
Bug#1059786: cross-toolchain-base: Migrating linux-libc-dev
Control: tags -1 - patch The headers have to be provided in the /usr//include location. Currently, that is not possible, because linux-libc-dev provides the linux-libc-dev-cross-* packages, without providing these headers in the old locations. The assumption to include the headers for the target from the header location of the host is wrong.
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Package: linux-libc-dev Version: 6.7.7-1 Severity: serious Tags: sid trixie linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Provides: linux-libc-dev-amd64-cross (= 6.7.7-1), ... However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. Please stop providing the cross-packages, you don't even need a breaks, because the current cross packages continue to work. Once that is done, I'll reduce the cross packages to some symlinks.
Bug#1041338: linux autopkg test blocks gcc-12 migration
Package: src:linux Version: 6.3.7-1 Severity: serious Tags: sid trixie seen on amd64, the issue doesn't look related to gcc-12. see https://ci.debian.net/data/autopkgtest/testing/amd64/l/linux/35917919/log.gz [...] 56sgcc-12 -Wp,-MMD,/tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/.foo.mod.o.d -nostdinc -I/usr/src/linux-headers-6.3.0-1-common/arch/x86/include -I./arch/x86/include/generated -I/usr/src/linux-headers-6.3.0-1-common/include -I./include -I/usr/src/linux-headers-6.3.0-1-common/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/usr/src/linux-headers-6.3.0-1-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-6.3.0-1-common/include/linux/compiler-version.h -include /usr/src/linux-headers-6.3.0-1-common/include/linux/kconfig.h -include /usr/src/linux-headers-6.3.0-1-common/include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-6.3.0-1-common/= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -funsigned-char -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=branch -fno-jump-tables -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all -fpatchable-function-entry=16,16 -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -falign-functions=16 -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-array-bounds -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -g -DMODULE -DKBUILD_BASENAME='"foo.mod"' -DKBUILD_MODNAME='"foo"' -D__KBUILD_MODNAME=kmod_foo -c -o /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/foo.mod.o /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/foo.mod.c 57s /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/foo.mod.c:10:10: fatal error: asm/orc_header.h: No such file or directory 57s10 | #include 57s | ^~ 57s compilation terminated. 57s make[1]: *** [/usr/src/linux-headers-6.3.0-1-common/scripts/Makefile.modfinal:29: /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/foo.mod.o] Error 1 57s make: Leaving directory '/usr/src/linux-headers-6.3.0-1-cloud-amd64' 57s make: *** [/usr/src/linux-headers-6.3.0-1-common/Makefile:1967: modules] Error 2 57s I: Clean 57s E: Unexpected warning/error messages 57s make: Entering directory '/usr/src/linux-headers-6.3.0-1-cloud-amd64' 57s make -f /usr/src/linux-headers-6.3.0-1-common/scripts/Makefile.clean obj=/tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo 57s # CLEAN /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/Module.symvers 57s rm -rf /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/Module.symvers /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/modules.nsdeps /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/compile_commands.json /tmp/autopkgtest-lxc.f52ni744/downtmp/autopkgtest_tmp/foo/.thinlto-cache 57s make: Leaving directory '/usr/src/linux-headers-6.3.0-1-cloud-amd64' 57s autopkgtest [03:20:42]: test kbuild: ---] 57s autopkgtest [03:20:42]: test kbuild: - - - - - - - - - - results - - - - - - - - - - 57s kbuild FAIL stderr: E: Unexpected warning/error messages
Bug#1019749: linux autopkg tests fail with stderr output, blocking gcc-11
Package: src:linux Version: 5.19.6-1 Severity: serious Tags: sid bookworm linux autopkg tests fail with stderr output, blocking gcc-11 [...] E: Unexpected warning/error messages autopkgtest [14:13:45]: summary selftestsSKIP Test restriction "isolation-machine" requires testbed capability "isolation-machine" selftestsSKIP Test restriction "isolation-machine" requires testbed capability "isolation-machine" python PASS (superficial) kbuild FAIL stderr: E: Unexpected warning/error messages
Bug#1015534: linux: ftbfs with LTO (link time optimization) enabled
Package: src:linux Version: 5.18.2-1 Severity: minor Tags: sid bookworm User: debian-...@lists.debian.org Usertags: ftbfs-lto This package currently fails to build (at least on the amd64 architecture) with link time optimizations enabled. For a background for LTO please see https://wiki.debian.org/ToolChain/LTO The goal is to enable this optimization by default in an upcoming Debian release in dpkg-buildflags for 64bit architectures. The goal is to get this package to build with link time optimizations, or to explicitly disable link time optimizations for this package build. To reproduce the build failure, enable the lto optimization in testing/unstable by adding "optimize=+lto" to DEB_BUILD_MAINT_OPTIONS in the debian/rules file, or if this macro is unset, just set it: export DEB_BUILD_MAINT_OPTIONS = optimize=+lto Please try to fix the build with lto enabled, fixing the packaging or forwarding the issue upstream. If the issue cannot be fixed, explicitly disallow building the package with lto by adding to your rules file: export DEB_BUILD_MAINT_OPTIONS = optimize=-lto or adding that string to your existing setting of DEB_BUILD_MAINT_OPTIONS. The full build log can be found at: http://qa-logs.debian.net/2022/06/09/dpkglto/linux_5.18.2-1_unstable_dpkglto.log The last lines of the build log are at the end of this report. [...] util/parse-events.c:1519:30: warning: ‘MEM [(struct perf_pmu_info *) + 32B]’ may be used uninitialized in this function [-Wmaybe-uninitialized] util/parse-events.c:1638:22: warning: ‘info.scale’ may be used uninitialized in this function [-Wmaybe-uninitialized] 1638 | evsel->scale = info.scale; | ^ util/parse-events.c:1519:30: note: ‘info.scale’ was declared here 1519 | struct perf_pmu_info info; | ^ util/parse-events.c:1637:23: warning: ‘info.unit’ may be used uninitialized in this function [-Wmaybe-uninitialized] 1637 | evsel->unit = strdup(info.unit); | ^ util/parse-events.c:1519:30: note: ‘info.unit’ was declared here 1519 | struct perf_pmu_info info; | ^ util/parse-events.c: In function ‘parse_events_load_bpf_obj’: ../lib/bpf/libbpf.c:11973:18: warning: ‘n’ may be used uninitialized in this function [-Wmaybe-uninitialized] 11973 | int err, n, i, tmp_cpus; | ^ util/parse-events.c: In function ‘parse_events_load_bpf’: util/parse-events.c:821:37: warning: ‘error_pos’ may be used uninitialized in this function [-Wmaybe-uninitialized] 821 | idx = term->err_term + error_pos; | ^ util/parse-events.c:794:13: note: ‘error_pos’ was declared here 794 | int error_pos; | ^ util/trace-event-parse.c: In function ‘raw_field_value.constprop’: util/trace-event-parse.c:84:28: warning: ‘val’ may be used uninitialized in this function [-Wmaybe-uninitialized] 84 | unsigned long long val; |^ util/bpf-event.c: In function ‘perf_env__fetch_btf.isra’: util/bpf-event.c:156:16: warning: ‘data_size’ may be used uninitialized in this function [-Wmaybe-uninitialized] 156 | node = malloc(data_size + sizeof(struct btf_node)); |^ util/bpf-event.c:151:13: note: ‘data_size’ was declared here 151 | u32 data_size; | ^ util/stat.c: In function ‘perf_event__fprintf_stat_config.isra’: util/stat.c:538:52: warning: ‘MEM [(struct perf_stat_config *) + 4B]’ may be used uninitialized in this function [-Wmaybe-uninitialized] 538 | ret += fprintf(fp, "... scale %d\n", sc.scale); |^ util/stat.c:531:33: note: ‘MEM [(struct perf_stat_config *) + 4B]’ was declared here 531 | struct perf_stat_config sc; | ^ util/scripting-engines/trace-event-python.c: In function ‘python_process_event’: util/scripting-engines/trace-event-python.c:884:13: warning: ‘val’ may be used uninitialized [-Wmaybe-uninitialized] 884 | pid = raw_field_value(event, "common_pid", data); | ^ util/trace-event-parse.c:84:28: note: ‘val’ was declared here 84 | unsigned long long val; |^ /usr/bin/ld: /tmp/ccct67DD.ltrans17.ltrans.o: in function `test_dwarf_unwind__thread': /<>/tools/perf/arch/x86/tests/dwarf-unwind.c:72: undefined reference to `perf_regs_load' /usr/bin/ld: /tmp/ccct67DD.ltrans10.ltrans.o:(.data.rel.ro+0x28): undefined reference to `memset_orig' /usr/bin/ld: /tmp/ccct67DD.ltrans10.ltrans.o:(.data.rel.ro+0x40): undefined reference to `__memset' /usr/bin/ld: /tmp/ccct67DD.ltrans10.ltrans.o:(.data.rel.ro+0x58): undefined reference to `memset_erms' /usr/bin/ld: /tmp/ccct67DD.ltrans10.ltrans.o:(.data.rel+0x28): undefined reference to
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 7/8/20 9:21 PM, Paul Gevers wrote: > Hi, > > [Note, this e-mail may look familiar as it is mostly copied over from > the buster call, not much has changed, AFAICT]. > > As part of the interim architecture qualification for bullseye, we > request that DSA, the security team, Wanna build, and the toolchain > maintainers review and update their list of known concerns for bullseye > release architectures. > > Summary of the current concerns and issues: > * DSA have announced a blocking issue for armel and armhf (see below) > * Concerns from DSA about ppc64el and s390x have been carried over from >(stretch and) buster. > * Concerns from the GCC maintainers about i386, armel, armhf, mips64el >and mipsel have been carried over from (stretch and) buster. > > If the issues and concerns from you or your team are not up to date, > then please follow up to this email (keeping debian-release@l.d.o in CC > to ensure we are notified). > > Whilst porters remain ultimately responsible for ensuring the > architectures are ready for release, we do expect that you / your team > are willing to assist with clarifications of the concerns and to apply > patches/changes in a timely manner to resolve the concerns. > > > List of blocking issues by architecture > === > > The following is a summary from the current architecture qualification > table. > > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] >- I was under the impression that this issue has been resolved (at > least for armhf) by now, but we like a fresh statement on this. > > > [DSA Sprint report]: > https://lists.debian.org/debian-project/2018/02/msg4.html > > > List of concerns for architectures > == > > The following is a summary from the current architecture qualification > table. > > * Concern for ppc64el and s390x: we are dependent on sponsors for >hardware. >(Raised by DSA; carried over from stretch and buster) > > * Concern for armel and armhf: only secondary upstream support in GCC >(Raised by the GCC maintainer; carried over from stretch and buster) this was wrong, and still is wrong. See https://gcc.gnu.org/gcc-10/criteria.html. arm-linux-gnueabi is listed as a primary platform. The arm-linux-gnueabihf triplet never gained much traction outside of Debian/Ubuntu, so should be included. armel might be special because the use of the libatomics library is mandatory. > * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >in GCC; Debian carries patches in binutils and GCC that haven't been >integrated upstream even after a long time. >(Raised by the GCC maintainer; carried over from stretch and buster) this is wrong for ppc64el (at least I didn't raise that). powerpc64-unknown-linux-gnu is listed as a primary platform. https://gcc.gnu.org/gcc-8/criteria.html explicitly lists the little endian variant, and after checking with upstream it looks like an omission to document that for GCC 9 and GCC 10 as well. A concern that appears to get ignored by the release team is that both mipsel and mips64el are neither a primary or a secondary release architecture. You seem to mention it in the summary, but don't have it in the list of concerns. GCC upstream only lists the bare metal mips*elf target, plus I don't see any other test results getting posted to the gcc-testresults ML besides for the Debian builds. Please also note the 100+ test failures for mips* in binutils, which are not addressed for years. See https://sourceware.org/pipermail/binutils/2020-July/112201.html mipsel now adds another work around to build 64bit compilers to be able to build larger projects (see e.g. binutils64). > Architecture status > === > > These are the architectures currently being built for bullseye: > > * Intel/AMD-based: amd64, i386 > * ARM-based: arm64, armel, armhf > * MIPS-based: mipsel, mips64el > * Other: ppc64el, s390x > > If the blocking issues cannot be resolved, affected architectures are at > risk of removal from testing before bullseye is frozen. > > We are currently unaware of any new architectures likely to be ready in > time for inclusion in bullseye. > > On behalf of the release team, > Paul Gevers >
Bug#957608: nfs-utils: ftbfs with GCC-10
Package: src:nfs-utils
Version: 1:1.3.4-2.5
Severity: normal
Tags: sid bullseye
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-10
Please keep this issue open in the bug tracker for the package it
was filed for. If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.
The package fails to build in a test rebuild on at least amd64 with
gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
severity of this report will be raised before the bullseye release,
so nothing has to be done for the buster release.
The full build log can be found at:
http://people.debian.org/~doko/logs/gcc10-20200225/nfs-utils_1.3.4-2.5_unstable_gcc10.log
The last lines of the build log are at the end of this report.
To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.
apt-get -t=experimental install g++
Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-10/porting_to.html
[...]
51 | dtable_ent(mount_dump,1,void,mountlist), /* DUMP */
| ^~
../../support/include/rpcmisc.h:41:3: warning: cast between incompatible
function types from ‘bool_t (*)(void)’ {aka ‘int (*)(void)’} to ‘bool_t (*)(XDR
*, ...)’ {aka ‘int (*)(struct __rpc_xdr *, ...)’} [-Wcast-function-type]
41 | (xdrproc_t)xdr_##res_type, sizeof(res_type), \
| ^
mount_dispatch.c:52:2: note: in expansion of macro ‘dtable_ent’
52 | dtable_ent(mount_umnt,1,dirpath,void), /* UMNT */
| ^~
../../support/include/rpcmisc.h:40:3: warning: cast between incompatible
function types from ‘bool_t (*)(void)’ {aka ‘int (*)(void)’} to ‘bool_t (*)(XDR
*, ...)’ {aka ‘int (*)(struct __rpc_xdr *, ...)’} [-Wcast-function-type]
40 | (xdrproc_t)xdr_##arg_type, sizeof(arg_type), \
| ^
mount_dispatch.c:53:2: note: in expansion of macro ‘dtable_ent’
53 | dtable_ent(mount_umntall,1,void,void), /* UMNTALL */
| ^~
../../support/include/rpcmisc.h:41:3: warning: cast between incompatible
function types from ‘bool_t (*)(void)’ {aka ‘int (*)(void)’} to ‘bool_t (*)(XDR
*, ...)’ {aka ‘int (*)(struct __rpc_xdr *, ...)’} [-Wcast-function-type]
41 | (xdrproc_t)xdr_##res_type, sizeof(res_type), \
| ^
mount_dispatch.c:53:2: note: in expansion of macro ‘dtable_ent’
53 | dtable_ent(mount_umntall,1,void,void), /* UMNTALL */
| ^~
../../support/include/rpcmisc.h:40:3: warning: cast between incompatible
function types from ‘bool_t (*)(void)’ {aka ‘int (*)(void)’} to ‘bool_t (*)(XDR
*, ...)’ {aka ‘int (*)(struct __rpc_xdr *, ...)’} [-Wcast-function-type]
40 | (xdrproc_t)xdr_##arg_type, sizeof(arg_type), \
| ^
mount_dispatch.c:54:2: note: in expansion of macro ‘dtable_ent’
54 | dtable_ent(mount_export,1,void,exports), /* EXPORT */
| ^~
gcc -DHAVE_CONFIG_H -I. -I../../support/include -I/usr/include/tirpc
-Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I../../support/include
-I../../support/export -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -Wall
-Wextra -Wstrict-prototypes -pipe -g -Wall -DPIPEFS_DIR=\"/run/rpc_pipefs\"
-DGSSD_PIPEFS_DIR=\"/run/rpc_pipefs\" -O2 -c -o mountd-cache.o `test -f
'cache.c' || echo './'`cache.c
gcc -DHAVE_CONFIG_H -I. -I../../support/include -I/usr/include/tirpc
-Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I../../support/include
-I../../support/export -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -Wall
-Wextra -Wstrict-prototypes -pipe -g -Wall -DPIPEFS_DIR=\"/run/rpc_pipefs\"
-DGSSD_PIPEFS_DIR=\"/run/rpc_pipefs\" -O2 -c -o mountd-svc_run.o `test -f
'svc_run.c' || echo './'`svc_run.c
gcc -DHAVE_CONFIG_H -I. -I../../support/include -I/usr/include/tirpc
-Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I../../support/include
-I../../support/export -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -Wall
-Wextra -Wstrict-prototypes -pipe -g -Wall -DPIPEFS_DIR=\"/run/rpc_pipefs\"
-DGSSD_PIPEFS_DIR=\"/run/rpc_pipefs\" -O2 -c -o mountd-fsloc.o `test -f
'fsloc.c' || echo './'`fsloc.c
gcc -DHAVE_CONFIG_H -I. -I../../support/include -I/usr/include/tirpc
-Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I../../support/include
-I../../support/export -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -Wall
-Wextra -Wstrict-prototypes -pipe -g -Wall -DPIPEFS_DIR=\"/run/rpc_pipefs\"
-DGSSD_PIPEFS_DIR=\"/run/rpc_pipefs\" -O2 -c -o mountd-v4root.o `test -f
'v4root.c' || echo './'`v4root.c
In file included from /usr/include/string.h:495,
from ../../support/include/exportfs.h:13,
from v4root.c:25:
In function ‘strncpy’,
inlined from ‘v4root_create’ at v4root.c:95:2:
Bug#957491: linux: ftbfs with GCC-10
Package: src:linux Version: 5.4.19-1 Severity: normal Tags: sid bullseye User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The severity of this report will be raised before the bullseye release, so nothing has to be done for the buster release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc10-20200225/linux_5.4.19-1_unstable_gcc10.log The last lines of the build log are at the end of this report. To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-10/porting_to.html [...] gcc -Wp,-MD,/<>/debian/build/build-tools/tools/perf/util/.probe-finder.o.d -Wp,-MT,/<>/debian/build/build-tools/tools/perf/util/probe-finder.o -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -I/<>/tools/perf -I/<>/debian/build/build-tools/tools/perf -isystem /<>/debian/build/build-tools/include -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Wshadow -DHAVE_ARCH_X86_64_SUPPORT -I/<>/debian/build/build-tools/tools/perf/arch/x86/include/generated -DHAVE_SYSCALL_TABLE_SUPPORT -DHAVE_PERF_REGS_SUPPORT -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET -O6 -fno-omit-frame-pointer -ggdb3 -funwi nd-tables -Wall -Wextra -std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2 -I/<>/tools/perf/lib/include -I/<>/tools/perf/util/include -I/<>/tools/perf/arch/x86/include -I/<>/tools/include/ -I/<>/tools/arch/x86/include/uapi -I/<>/tools/include/uapi -I/<>/tools/arch/x86/include/ -I/<>/tools/arch/x86/ -I/<>/debian/build/build-tools/tools/perf//util -I/<>/debian/build/build-tools/tools/perf/ -I/<>/tools/perf/util -I/<>/tools/perf -I/<>/tools/lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER -DHAVE_EVENTFD -DHAVE_GET_CURRENT_DIR_NAME -DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT -DHAVE_AIO_SUPPORT -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DHAVE_CSTRACE_SUPPORT -DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_ MMAP_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_GELF_GETNOTE_SUPPORT -DHAVE_ELF_GETSHDRSTRNDX_SUPPORT -DHAVE_DWARF_SUPPORT -DHAVE_LIBBPF_SUPPORT -DHAVE_BPF_PROLOGUE -DHAVE_JITDUMP -DHAVE_DWARF_UNWIND_SUPPORT -DNO_LIBUNWIND_DEBUG_FRAME -DHAVE_LIBUNWIND_SUPPORT -DHAVE_SLANG_SUPPORT -DHAVE_LIBPERL_SUPPORT -DHAVE_TIMERFD_SUPPORT -DHAVE_LIBPYTHON_SUPPORT -DHAVE_CPLUS_DEMANGLE_SUPPORT -DHAVE_ZLIB_SUPPORT -DHAVE_LZMA_SUPPORT -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT -DHAVE_KVM_STAT_SUPPORT -DHAVE_PERF_READ_VDSO32 -DHAVE_PERF_READ_VDSOX32 -DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_AUXTRACE_SUPPORT -I/<>/debian/build/build-tools/tools/perf/ -D"BUILD_STR(s)=#s" -c -o /<>/debian/build/build-tools/tools/perf/util/probe-finder.o util/probe-finder.c gcc -Wp,-MD,/<>/debian/build/build-tools/tools/perf/util/.dwarf-aux.o.d -Wp,-MT,/<>/debian/build/build-tools/tools/perf/util/dwarf-aux.o -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -I/<>/tools/perf -I/<>/debian/build/build-tools/tools/perf -isystem /<>/debian/build/build-tools/include -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Wshadow -DHAVE_ARCH_X86_64_SUPPORT -I/<>/debian/build/build-tools/tools/perf/arch/x86/include/generated -DHAVE_SYSCALL_TABLE_SUPPORT -DHAVE_PERF_REGS_SUPPORT -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET -O6 -fno-omit-frame-pointer -ggdb3 -funwind-tab les -Wall -Wextra -std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2 -I/<>/tools/perf/lib/include -I/<>/tools/perf/util/include -I/<>/tools/perf/arch/x86/include -I/<>/tools/include/ -I/<>/tools/arch/x86/include/uapi
Bug#957405: klibc: ftbfs with GCC-10
Package: src:klibc Version: 2.0.7-1 Severity: normal Tags: sid bullseye User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The severity of this report will be raised before the bullseye release, so nothing has to be done for the buster release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc10-20200225/klibc_2.0.7-1_unstable_gcc10.log The last lines of the build log are at the end of this report. To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-10/porting_to.html [...] EDESTADDRREQ (89) => "Destination address required" EMSGSIZE (90) => "Message too long" EPROTOTYPE (91) => "Protocol wrong type for socket" ENOPROTOOPT (92) => "Protocol not available" EPROTONOSUPPORT (93) => "Protocol not supported" ESOCKTNOSUPPORT (94) => "Socket type not supported" EOPNOTSUPP (95) => "Operation not supported on transport endpoint" EPFNOSUPPORT (96) => "Protocol family not supported" EAFNOSUPPORT (97) => "Address family not supported by protocol" EADDRINUSE (98) => "Address already in use" EADDRNOTAVAIL (99) => "Cannot assign requested address" ENETDOWN (100) => "Network is down" ENETUNREACH (101) => "Network is unreachable" ENETRESET (102) => "Network dropped connection because of reset" ECONNABORTED (103) => "Software caused connection abort" ECONNRESET (104) => "Connection reset by peer" ENOBUFS (105) => "No buffer space available" EISCONN (106) => "Transport endpoint is already connected" ENOTCONN (107) => "Transport endpoint is not connected" ESHUTDOWN (108) => "Cannot send after transport endpoint shutdown" ETOOMANYREFS (109) => "Too many references: cannot splice" ETIMEDOUT (110) => "Connection timed out" ECONNREFUSED (111) => "Connection refused" EHOSTDOWN (112) => "Host is down" EHOSTUNREACH (113) => "No route to host" EALREADY (114) => "Operation already in progress" EINPROGRESS (115) => "Operation now in progress" ESTALE (116) => "Stale file handle" EUCLEAN (117) => "Structure needs cleaning" ENOTNAM (118) => "Not a XENIX named type file" ENAVAIL (119) => "No XENIX semaphores available" EISNAM (120) => "Is a named type file" EREMOTEIO (121) => "Remote I/O error" EDQUOT (122) => "Quota exceeded" ENOMEDIUM (123) => "No medium found" EMEDIUMTYPE (124) => "Wrong medium type" ECANCELED (125) => "Operation Canceled" ENOKEY (126) => "Required key not available" EKEYEXPIRED (127) => "Key has expired" EKEYREVOKED (128) => "Key has been revoked" EKEYREJECTED (129) => "Key was rejected by service" EOWNERDEAD (130) => "Owner died" ENOTRECOVERABLE (131) => "State not recoverable" ERFKILL (132) => "Operation not possible due to RF-kill" EHWPOISON (133) => "Memory page has hardware error" closing asm-generic/errno.h closing asm/errno.h closing linux/errno.h gcc -Wp,-MD,usr/klibc/.errlist.o.d -nostdinc -iwithprefix include -I/<>/usr/include/arch/x86_64 -Iusr/include/arch/x86_64 -I/<>/usr/include/bits64 -Iusr/include/bits64 -I/<>/usr/klibc/../include -Iusr/klibc/../include -I/<>/usr/include -Iusr/include -I/<>/linux/include -Ilinux/include -D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=64 -fno-stack-protector -fwrapv -fno-PIE -ggdb -m64 -Os -fomit-frame-pointer -mno-sse -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fno-asynchronous-unwind-tables -W -Wall -Wno-sign-compare -Wno-unused-parameter -c -o usr/klibc/errlist.o usr/klibc/errlist.c echo usr/klibc/vsnprintf.o usr/klibc/snprintf.o usr/klibc/vsprintf.o usr/klibc/sprintf.o usr/klibc/asprintf.o usr/klibc/vasprintf.o usr/klibc/vsscanf.o usr/klibc/sscanf.o usr/klibc/ctypes.o usr/klibc/strntoumax.o usr/klibc/strntoimax.o usr/klibc/atoi.o usr/klibc/atol.o usr/klibc/atoll.o usr/klibc/strtol.o usr/klibc/strtoll.o usr/klibc/strtoul.o usr/klibc/strtoull.o usr/klibc/strtoimax.o usr/klibc/strtoumax.o usr/klibc/globals.o usr/klibc/exit.o usr/klibc/atexit.o usr/klibc/onexit.o usr/klibc/execl.o usr/klibc/execle.o usr/klibc/execv.o usr/klibc/execvpe.o usr/klibc/execvp.o usr/klibc/execlp.o usr/klibc/execlpe.o usr/klibc/fork.o usr/klibc/vfork.o usr/klibc/wait.o usr/klibc/wait3.o usr/klibc/waitpid.o usr/klibc/system.o usr/klibc/setpgrp.o usr/klibc/getpgrp.o usr/klibc/daemon.o usr/klibc/printf.o usr/klibc/vprintf.o usr/klibc/fprintf.o usr/klibc/vfprintf.o
Bug#940550: linux 5.3 breaks building glibc for riscv64
Package: src:linux Severity: important Tags: sid bullseye patch linux 5.3 breaks building glibc for riscv64, discussion and patch at https://bugs.launchpad.net/ubuntu/+source/cross-toolchain-base-ports/+bug/1843458
Re: [Cross-toolchain-base-devs] Testing migration of linux
On 23.08.19 17:41, Ben Hutchings wrote: > We now have a version of linux (5.2.9-2) that builds on all release > architectures and doesn't seem to cause build regressions for other > packages. I think that this should migrate to testing soon, as the > version in testing is missing important security fixes. > > I'm aware of autopkgtest regressions for two packages: > > * cross-toolchain-base 36: This appears to be a bug in that version of > the package. cross-toolchain-base version 39 seems to be compatible > with Linux 5.2 and would need to migrate at the same time. > > * glibc 2.28-10: This is a minor regression in the kernel uAPI headers, > which could *possibly* lead to build failures if programs define > conflicting macros. (I fixed the larger regression which did cause > build failures.) glibc 2.29 as packaged in experimental will stop > using these uAPI headers. > > The excuses file mentions "new bug" #934483, but that was a bug in > virtualbox-guest-dkms which has now been fixed. virtualbox is not in > testing. > > So these packages should migrate to testing together: > > cross-toolchain-base 39 > linux 5.2.9-2 > linux-latest 106 > linux-signed-amd64 5.2.9+2 > linux-signed-arm64 5.2.9+2 > linux-signed-i386 5.2.9+2 > > cross-toolchain-base seems to be dependent on these packages, which > also inter-depend on each other, so that they'll also need to migrate > at the same time: > > binutils > gcc-8 > gcc-9-cross-ports > gcc-defaults-ports due to the removal of the mips packages, binutils, cross-toolchain-base, gcc-8-cross, gcc-9-cross and gcc-defaults need to migrate together. The combination of linux-libc-dev (<< 5.2) and linux-libc-dev (>= 5.2) leads to build failures for some cross compilers, so all the -ports packages should migrate as well. Blockers: https://piuparts.debian.org/sid/source/g/gcc-9-cross.html why? Matthias
Bug#925766: linux: ftbfs with GCC-9
Package: src:linux Version: 4.19.28-2 Severity: normal Tags: sid bullseye User: debian-...@lists.debian.org Usertags: ftbfs-gcc-9 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The severity of this report will be raised before the bullseye release, so nothing has to be done for the buster release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc9-20190321/linux_4.19.28-2_unstable_gcc9.log The last lines of the build log are at the end of this report. To build with GCC 9, either set CC=gcc-9 CXX=g++-9 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-9/porting_to.html GCC 9 also passes the linker option --as-needed by default; typical build issues are passing libraries before object files to the linker, or underlinking of convenience libraries built from the same source. [...] -a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a manmanual="perf Manual" -a revdate=2019-03-15 -aperf_version= -o /<>/debian/build/build-tools/tools/perf/perf-sched.1+ perf-sched.txt && \ mv /<>/debian/build/build-tools/tools/perf/perf-sched.1+ /<>/debian/build/build-tools/tools/perf/perf-sched.1 rm -f /<>/debian/build/build-tools/tools/perf/perf-kvm.1+ /<>/debian/build/build-tools/tools/perf/perf-kvm.1 && \ asciidoctor -b manpage -d manpage \ -a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a manmanual="perf Manual" -a revdate=2019-03-15 -aperf_version= -o /<>/debian/build/build-tools/tools/perf/perf-kvm.1+ perf-kvm.txt && \ mv /<>/debian/build/build-tools/tools/perf/perf-kvm.1+ /<>/debian/build/build-tools/tools/perf/perf-kvm.1 rm -f /<>/debian/build/build-tools/tools/perf/perf-annotate.1+ /<>/debian/build/build-tools/tools/perf/perf-annotate.1 && \ asciidoctor -b manpage -d manpage \ -a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a manmanual="perf Manual" -a revdate=2019-03-15 -aperf_version= -o /<>/debian/build/build-tools/tools/perf/perf-annotate.1+ perf-annotate.txt && \ mv /<>/debian/build/build-tools/tools/perf/perf-annotate.1+ /<>/debian/build/build-tools/tools/perf/perf-annotate.1 rm -f /<>/debian/build/build-tools/tools/perf/perf-top.1+ /<>/debian/build/build-tools/tools/perf/perf-top.1 && \ asciidoctor -b manpage -d manpage \ -a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a manmanual="perf Manual" -a revdate=2019-03-15 -aperf_version= -o /<>/debian/build/build-tools/tools/perf/perf-top.1+ perf-top.txt && \ mv /<>/debian/build/build-tools/tools/perf/perf-top.1+ /<>/debian/build/build-tools/tools/perf/perf-top.1 rm -f /<>/debian/build/build-tools/tools/perf/perf-stat.1+ /<>/debian/build/build-tools/tools/perf/perf-stat.1 && \ asciidoctor -b manpage -d manpage \ -a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a manmanual="perf Manual" -a revdate=2019-03-15 -aperf_version= -o /<>/debian/build/build-tools/tools/perf/perf-stat.1+ perf-stat.txt && \ mv /<>/debian/build/build-tools/tools/perf/perf-stat.1+ /<>/debian/build/build-tools/tools/perf/perf-stat.1 rm -f /<>/debian/build/build-tools/tools/perf/perf-ftrace.1+ /<>/debian/build/build-tools/tools/perf/perf-ftrace.1 && \ asciidoctor -b manpage -d manpage \ -a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a manmanual="perf Manual" -a revdate=2019-03-15 -aperf_version= -o /<>/debian/build/build-tools/tools/perf/perf-ftrace.1+ perf-ftrace.txt && \ mv /<>/debian/build/build-tools/tools/perf/perf-ftrace.1+ /<>/debian/build/build-tools/tools/perf/perf-ftrace.1 rm -f /<>/debian/build/build-tools/tools/perf/perf-script-perl.1+ /<>/debian/build/build-tools/tools/perf/perf-script-perl.1 && \ asciidoctor -b manpage -d manpage \ -a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a manmanual="perf Manual" -a revdate=2019-03-15 -aperf_version= -o /<>/debian/build/build-tools/tools/perf/perf-script-perl.1+ perf-script-perl.txt && \ mv /<>/debian/build/build-tools/tools/perf/perf-script-perl.1+ /<>/debian/build/build-tools/tools/perf/perf-script-perl.1 rm -f /<>/debian/build/build-tools/tools/perf/perf-report.1+ /<>/debian/build/build-tools/tools/perf/perf-report.1 && \ asciidoctor -b manpage -d manpage \ -a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a manmanual="perf Manual"
Bug#897802: linux: ftbfs with GCC-8
Package: src:linux Version: 4.15.17-1 Severity: normal Tags: sid buster User: debian-...@lists.debian.org Usertags: ftbfs-gcc-8 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-8/g++-8, but succeeds to build with gcc-7/g++-7. The severity of this report will be raised before the buster release. The full build log can be found at: http://aws-logs.debian.net/2018/05/01/gcc8/linux_4.15.17-1_unstable_gcc8.log.gz The last lines of the build log are at the end of this report. To build with GCC 8, either set CC=gcc-8 CXX=g++-8 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-8/porting_to.html [...] WRAParch/x86/include/generated/asm/mm-arch-hooks.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h HOSTLD arch/x86/tools/relocs HOSTCC scripts/genksyms/genksyms.o SHIPPED scripts/genksyms/parse.tab.c SHIPPED scripts/genksyms/lex.lex.c SHIPPED scripts/genksyms/parse.tab.h HOSTCC scripts/genksyms/parse.tab.o HOSTCC scripts/genksyms/lex.lex.o CC scripts/mod/empty.o HOSTCC scripts/selinux/genheaders/genheaders HOSTCC scripts/mod/mk_elfconfig CC scripts/mod/devicetable-offsets.s CHK scripts/mod/devicetable-offsets.h UPD scripts/mod/devicetable-offsets.h MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/modpost.o HOSTCC scripts/selinux/mdp/mdp CC arch/x86/purgatory/purgatory.o AS arch/x86/purgatory/stack.o AS arch/x86/purgatory/setup-x86_64.o CC arch/x86/purgatory/sha256.o AS arch/x86/purgatory/entry64.o make[7]: *** [Makefile:46: /<>/debian/build/build_amd64_none_amd64/tools/objtool/objtool-in.o] Error 2 make[6]: *** [Makefile:63: objtool] Error 2 make[5]: *** [/<>/Makefile:1663: tools/objtool] Error 2 make[5]: *** Waiting for unfinished jobs CC arch/x86/purgatory/string.o HOSTCC scripts/mod/file2alias.o HOSTCC scripts/kallsyms HOSTCC scripts/mod/sumversion.o HOSTCC scripts/conmakehash HOSTCC scripts/recordmcount HOSTCC scripts/sortextable HOSTCC scripts/asn1_compiler HOSTCC scripts/extract-cert LD arch/x86/purgatory/purgatory.ro BIN2C arch/x86/purgatory/kexec-purgatory.c HOSTLD scripts/genksyms/genksyms HOSTLD scripts/mod/modpost make[4]: *** [Makefile:146: sub-make] Error 2 make[3]: *** [Makefile:24: __sub-make] Error 2 make[3]: Leaving directory '/<>/debian/build/build_amd64_none_amd64' make[2]: *** [debian/rules.real:190: debian/stamps/build_amd64_none_amd64] Error 2 make[2]: Leaving directory '/<>' make[1]: *** [debian/rules.gen:453: build-arch_amd64_none_amd64_real] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:37: build-arch] Error 2 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2
Bug#883194: please convert mountstats and nfsiostat scripts to Python3
Package: nfs-utils Version: 1:1.3.4-2.1 User: debian-pyt...@lists.debian.org Usertags: py2-removal the changelog reads: - nfs-common: Add Recommends python for mountstats and nfsiostat Please convert these scripts to python3, and recommend Python3 instead.
Bug#853519: linux: ftbfs with GCC-7
Package: src:linux Version: 4.9.2-2 Severity: normal Tags: sid buster User: debian-...@lists.debian.org Usertags: ftbfs-gcc-7 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The severity of this report may be raised before the buster release. There is no need to fix this issue in time for the stretch release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc7-20170126/linux_4.9.2-2_unstable_gcc7.log The last lines of the build log are at the end of this report. To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-7/porting_to.html [...] make[8]: Leaving directory '/<>/tools/perf' /<>/tools/build/Makefile.build:134: recipe for target 'util' failed make[7]: *** [util] Error 2 make[7]: *** Waiting for unfinished jobs make[7]: Leaving directory '/<>/tools/perf' Makefile.perf:365: recipe for target '/<>/debian/build/build-tools/tools/perf/perf-in.o' failed make[6]: *** [/<>/debian/build/build-tools/tools/perf/perf-in.o] Error 2 make[6]: *** Waiting for unfinished jobs ld -r -o /<>/debian/build/build-tools/tools/perf/ui/browsers/libperf-in.o /<>/debian/build/build-tools/tools/perf/ui/browsers/annotate.o /<>/debian/build/build-tools/tools/perf/ui/browsers/hists.o /<>/debian/build/build-tools/tools/perf/ui/browsers/map.o /<>/debian/build/build-tools/tools/perf/ui/browsers/scripts.o /<>/debian/build/build-tools/tools/perf/ui/browsers/header.o make[9]: Leaving directory '/<>/tools/perf' ld -r -o /<>/debian/build/build-tools/tools/perf/ui/libperf-in.o /<>/debian/build/build-tools/tools/perf/ui/setup.o /<>/debian/build/build-tools/tools/perf/ui/helpline.o /<>/debian/build/build-tools/tools/perf/ui/progress.o /<>/debian/build/build-tools/tools/perf/ui/util.o /<>/debian/build/build-tools/tools/perf/ui/hist.o /<>/debian/build/build-tools/tools/perf/ui/stdio/hist.o /<>/debian/build/build-tools/tools/perf/ui/browser.o /<>/debian/build/build-tools/tools/perf/ui/browsers/libperf-in.o /<>/debian/build/build-tools/tools/perf/ui/tui/libperf-in.o make[8]: Leaving directory '/<>/tools/perf' make[7]: Leaving directory '/<>/tools/perf' Makefile.perf:559: recipe for target '/<>/debian/build/build-tools/tools/perf/libperf-in.o' failed make[6]: *** [/<>/debian/build/build-tools/tools/perf/libperf-in.o] Error 2 /<>/tools/perf/util/thread_map.c: In function 'thread_map__new_by_uid': /<>/tools/perf/util/thread_map.c:119:39: error: '%s' directive output may be truncated writing between 0 and 255 bytes into a region of size 250 [-Werror=format-truncation=] snprintf(path, sizeof(path), "/proc/%s", dirent->d_name); ^~ In file included from /usr/include/stdio.h:938:0, from /<>/tools/perf/util/thread_map.c:5: /usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: note: format output between 7 and 262 bytes into a destination of size 256 return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~ __bos (__s), __fmt, __va_arg_pack ()); ~ cc1: all warnings being treated as errors error: command 'gcc' failed with exit status 1 cp: cannot stat '/<>/debian/build/build-tools/tools/perf/python_ext_build/lib/perf.so': No such file or directory Makefile.perf:264: recipe for target '/<>/debian/build/build-tools/tools/perf/python/perf.so' failed make[6]: *** [/<>/debian/build/build-tools/tools/perf/python/perf.so] Error 1 make[6]: Leaving directory '/<>/tools/perf' /<>/debian/rules.d/tools/perf/Makefile:59: recipe for target 'all' failed make[5]: *** [all] Error 2 make[5]: Leaving directory '/<>/debian/build/build-tools/tools/perf' /<>/debian/rules.d/Makefile.inc:25: recipe for target 'all-recursive' failed make[4]: *** [all-recursive] Error 2 make[4]: Leaving directory '/<>/debian/build/build-tools/tools' /<>/debian/rules.d/Makefile.inc:25: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 2 make[3]: Leaving directory '/<>/debian/build/build-tools' debian/rules.real:534: recipe for target 'debian/stamps/build-tools' failed make[2]: *** [debian/stamps/build-tools] Error 2 make[2]: Leaving directory '/<>' debian/rules.gen:396: recipe for target
Re: Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64
On 27.11.2016 19:27, Sven Joachim wrote: > On 2016-11-27 18:34 +0100, Matthias Klose wrote: > >> On 27.11.2016 16:51, Sven Joachim wrote: >>> On 2016-11-27 13:39 +0100, Matthias Klose wrote: >>> >>>> Control: tags -1 + help moreinfo >>>> Control: severity -1 important >>>> >>>> On 27.11.2016 08:38, Sven Joachim wrote: >>>>> Control: reassign -1 binutils 2.27.51.20161124-1 >>>>> Control: retitle -1 binutils: creates unbootable kernel on x86-64 >>>>> Control: severity -1 grave >>>>> >>>>> On 2016-11-26 15:13 +0100, Damien Wyart wrote: >>>>> >>>>>> After running further tests today, I think this is in fact *not* >>>>>> related to gcc but to the kernel itself. >>>>>> >>>>>> I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the >>>>>> kernels fail to boot (balck screen just after grub and nothing in the >>>>>> logs). >>>>> >>>>> Same here, downgrading binutils to 2.27.51.20161118-2 helped. I'm >>>>> reassigning the bug and bumping the severity, since several people have >>>>> observed the problem. >>>> >>>> The original report talks about a 4.4 problem on , which afaik is >>>> superseded in >>>> unstable by newever versions released after the GCC 6 release. This is >>>> now made >>>> a binutils RC issue for building a kernel which is not in the archive >>>> anymore. >>>> Please could you validate that the issue exists with the linux package in >>>> unstable as well? >>> >>> I have noticed the problem with vanilla Linux 4.8.11 from kernel.org, so >>> I suspect the Debian kernel is affected as well. There is no console >>> output at all, the system freezes right when uncompressing the kernel. >>> >>> It should be noted that I haven't noticed the problem on my desktop >>> (which has a 32-bit userland but a 64-bit kernel) where I have >>> CONFIG_KERNEL_GZIP=y, but on my laptop which uses the default >>> CONFIG_KERNEL_XZ=y it is reproducible. >> >> if it's really binutils, I prepared a package reverting the fix for PR >> ld/20815. >> Would be nice if somebody could check that out: >> https://people.debian.org/~doko/tmp/binutils_2.27.51.20161124-1.1_amd64.deb > > Thanks, that binutils package produces a working kernel here. please could you check again with https://people.debian.org/~doko/tmp/binutils_2.27.51.20161127-1.1_amd64.deb having the suggested fix proposed at https://sourceware.org/ml/binutils/2016-11/msg00348.html
Re: Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64
On 27.11.2016 16:51, Sven Joachim wrote: > On 2016-11-27 13:39 +0100, Matthias Klose wrote: > >> Control: tags -1 + help moreinfo >> Control: severity -1 important >> >> On 27.11.2016 08:38, Sven Joachim wrote: >>> Control: reassign -1 binutils 2.27.51.20161124-1 >>> Control: retitle -1 binutils: creates unbootable kernel on x86-64 >>> Control: severity -1 grave >>> >>> On 2016-11-26 15:13 +0100, Damien Wyart wrote: >>> >>>> After running further tests today, I think this is in fact *not* >>>> related to gcc but to the kernel itself. >>>> >>>> I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the >>>> kernels fail to boot (balck screen just after grub and nothing in the >>>> logs). >>> >>> Same here, downgrading binutils to 2.27.51.20161118-2 helped. I'm >>> reassigning the bug and bumping the severity, since several people have >>> observed the problem. >> >> The original report talks about a 4.4 problem on , which afaik is superseded >> in >> unstable by newever versions released after the GCC 6 release. This is now >> made >> a binutils RC issue for building a kernel which is not in the archive >> anymore. >> Please could you validate that the issue exists with the linux package in >> unstable as well? > > I have noticed the problem with vanilla Linux 4.8.11 from kernel.org, so > I suspect the Debian kernel is affected as well. There is no console > output at all, the system freezes right when uncompressing the kernel. > > It should be noted that I haven't noticed the problem on my desktop > (which has a 32-bit userland but a 64-bit kernel) where I have > CONFIG_KERNEL_GZIP=y, but on my laptop which uses the default > CONFIG_KERNEL_XZ=y it is reproducible. if it's really binutils, I prepared a package reverting the fix for PR ld/20815. Would be nice if somebody could check that out: https://people.debian.org/~doko/tmp/binutils_2.27.51.20161124-1.1_amd64.deb
Re: Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64
Control: tags -1 + help moreinfo Control: severity -1 important On 27.11.2016 08:38, Sven Joachim wrote: > Control: reassign -1 binutils 2.27.51.20161124-1 > Control: retitle -1 binutils: creates unbootable kernel on x86-64 > Control: severity -1 grave > > On 2016-11-26 15:13 +0100, Damien Wyart wrote: > >> After running further tests today, I think this is in fact *not* >> related to gcc but to the kernel itself. >> >> I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the >> kernels fail to boot (balck screen just after grub and nothing in the >> logs). > > Same here, downgrading binutils to 2.27.51.20161118-2 helped. I'm > reassigning the bug and bumping the severity, since several people have > observed the problem. The original report talks about a 4.4 problem on , which afaik is superseded in unstable by newever versions released after the GCC 6 release. This is now made a binutils RC issue for building a kernel which is not in the archive anymore. Please could you validate that the issue exists with the linux package in unstable as well?
Bug#835957: linux: non-standard gcc/g++ used for build (gcc-5)
Package: linux Version: 4.7.2-1 Severity: important Tags: sid stretch User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-5, gcc-5-legacy This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-6/g++-6. Please keep this report open until the package uses the default compiler version (or gcc-6) for the package build. If the package cannot be built anymore, please file a bug report for ftp.debian.org, asking for the removal of the package. The severity of this report is likely to be raised before the release, so that the gcc-5 package can be removed for the release.
Bug#818776: linux: non-standard gcc/g++ used for build (gcc-4.9)
Package: linux Version: 4.4.6-1 Severity: important Tags: sid stretch User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.9, gcc-4.9-legacy This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-5/g++-5. Please keep this report open until the package uses the default compiler version (or gcc-5) for the package build. If the package cannot be built anymore, please file a bug report for ftp.debian.org, asking for the removal of the package. The severity of this report is likely to be raised before the release, so that the gcc-4.9 package can be removed for the release.
Bug#785065: vdso32 fails to built on ppc64el
that should be fixed on the kernel side by removing this code. there never was a powerpcle userland support. If this is not possible in the short term, then we can re-enable this for unstable for some time. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55520648.6090...@debian.org
Re: Bug#765380: don't ship gcc-4.8 with jessie
Am 17.10.2014 um 19:44 schrieb Steve Cotton: On Tue, Oct 14, 2014 at 05:25:13PM +0200, Matthias Klose wrote: Package: src:gcc-4.8 Version: 4.8.3-11 Severity: serious Tags: sid jessie The current default for GCC (4.9) is good enough for jessie. Don't ship legacy compilers with jessie. Hi Matthias, Removing GCC 4.8 will need Linux kernel ABI transitions. I haven't seen any discussion on the debian-kernel list, and the latest of the Linux package (uploaded to sid this week) still has it generating linux-compiler-* packages depending on gcc-4.8, so I think the Linux maintainers are expecting GCC 4.8 to be in Jessie. This was communicated to Ben Hutching at DebConf, so plenty of time to prepare the change. Are there known showstoppers? Matthias -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54415eca.6030...@debian.org
Bug#757835: nfs-kernel-server: after update 1.2.8-6-1.2.8-8 rpc.mountd starts crashing
Am 12.08.2014 um 18:05 schrieb Steve Langasek:
Control: reassign -1 gcc-4.9,nfs-kernel-server
Control: found -1 nfs-kernel-server/1.2.8-8
Control: found -1 gcc-4.9/4.9.1
On Mon, Aug 11, 2014 at 12:54:00PM -0700, Petr Vandrovec wrote:
amd64. I think it affects all architectures. In case you want to
follow-up, attached is minimum testcase I could come up with. It
crashes with gcc-4.9 and -O2. No crash with gcc-4.8, or at -O1.
$gcc-4.9 -W -Wall -O2 client.c ./a.out
Segmentation fault
$gcc-4.8 -W -Wall -O2 client.c ./a.out
$gcc-4.9 -W -Wall -O1 client.c ./a.out
$
Thanks.
Matthias, could you please have a look at the below test case? We have a
regression in the latest nfs-kernel-server build, which appears to be caused
by a gcc-4.9 bug.
Should I work around this in nfs-utils, or is a quick fix possible in
gcc-4.9?
char buf[100];
void
add_name(char *old)
{
char *cp = old;
while (cp *cp) {
cp++;
}
if (old)
__builtin_strncpy(buf, old, cp-old);
if (cp != old) {
buf[0] = 'Q';
}
if (cp *cp) {
buf[0] = 'Q';
}
}
int main(void) {
add_name(0);
return 0;
}
guard the strncpy. I did see a similar issue like this (can't find it anymore),
and the recommendation was to guard the strncpy.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ea45ae.3030...@debian.org
Bug#747987: linux: non-standard gcc/g++ used for build (gcc-4.6)
Package: linux Version: 3.14.2-1 Severity: important Tags: sid jessie User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.6, gcc-4.6-legacy This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-4.9/g++-4.9. Please drop build dependencies of the form libstdc++6-4.6-dev, these are not needed and fulfilled by build-essential. Please keep this report open until the package uses the default compiler version (or gcc-4.9) for the package build. The severity of this report is likely to be raised before the release, so that the gcc-4.6 package can be removed for the release. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wkbou-0002zf...@ravel.debian.org
Bug#748002: linux: non-standard gcc/g++ used for build (gcc-4.7)
Package: linux Version: 3.14.2-1 Severity: important Tags: sid jessie User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.7, gcc-4.7-legacy This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-4.9/g++-4.9. Please drop build dependencies of the form libstdc++6-4.7-dev, these are not needed and fulfilled by build-essential. Please keep this report open until the package uses the default compiler version (or gcc-4.9) for the package build. The severity of this report is likely to be raised before the release, so that the gcc-4.7 package can be removed for the release. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wkbsj-0003kz...@ravel.debian.org
Bug#708070: enable x32 support for the amd64 kernels
Package: linux Severity: wishlist Please enable support for the x32 syscalls, so that it becomes possible to run a x32 chroot on such a kernel. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51900d72.7030...@debian.org
Bug#701441: linux-tools: ftbfs with eglibc-2.17
Package: src:linux-tools Version: 3.2.17-1 Severity: important Tags: sid jessie User: debian-gl...@lists.debian.org Usertags: ftbfs-glibc-2.17 The package fails to build in a test rebuild on at least amd64 with eglibc-2.17, but succeeds to build with eglibc-2.13. The severity of this report may be raised before the jessie release. The test rebuild was done together with GCC-4.8, so some issues might be caused by the updated GCC as well. builtin-sched.c:396:16: error: storage size of 'ru' isn't known The full build log can be found at: http://people.debian.org/~doko/logs-20130217/gcc48/linux-tools_3.2.17-1_unstable_gcc48.log The last lines of the build log are at the end of this report. To install eglibc from experimental, apt-get -t experimental install libc6-dev To build with GCC 4.8, either set CC=gcc-4.8 CXX=g++-4.8 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t experimental install g++ g++-4.7 g++-4.8 libc6-dev [...] mkdir -p /«PKGBUILDDIR»/debian/build/tools/perf/out/util/ui 2/dev/null mkdir -p /«PKGBUILDDIR»/debian/build/tools/perf/out/util/ui/browsers 2/dev/null PERF_VERSION = 3.2.17 make[6]: Leaving directory `/«PKGBUILDDIR»/tools/perf' make[6]: Entering directory `/«PKGBUILDDIR»/tools/perf' . util/generate-cmdlist.sh /«PKGBUILDDIR»/debian/build/tools/perf/out/common-cmds.h+ mv /«PKGBUILDDIR»/debian/build/tools/perf/out/common-cmds.h+ /«PKGBUILDDIR»/debian/build/tools/perf/out/common-cmds.h * new build flags or prefix gcc -DPERF_VERSION='3.2.17' \ '-DPERF_HTML_PATH=share/doc/perf-doc' \ -fno-omit-frame-pointer -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wno-error -fstack-protector-all -Wstack-protector -Wvolatile-register-var -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I/«PKGBUILDDIR»/debian/build/tools/perf/out/ -DLIBELF_NO_MMAP -DDWARF_SUPPORT -I/usr/include/slang -DHAVE_CPLUS_DEMANGLE -DNO_STRLCPY -c perf.c -o /«PKGBUILDDIR»/debian/build/tools/perf/out/perf.o gcc -o /«PKGBUILDDIR»/debian/build/tools/perf/out/builtin-annotate.o -c -fno-omit-frame-pointer -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wno-error -fstack-protector-all -Wstack-protector -Wvolatile-register-var -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I/«PKGBUILDDIR»/debian/build/tools/perf/out/ -DLIBELF_NO_MMAP -DDWARF_SUPPORT -I/usr/include/slang -DHAVE_CPLUS_DEMANGLE -DNO_STRLCPY builtin-annotate.c gcc -o /«PKGBUILDDIR»/debian/build/tools/perf/out/builtin-bench.o -c -fno-omit-frame-pointer -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wno-error -fstack-protector-all -Wstack-protector -Wvolatile-register-var -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I/«PKGBUILDDIR»/debian/build/tools/perf/out/ -DLIBELF_NO_MMAP -DDWARF_SUPPORT -I/usr/include/slang -DHAVE_CPLUS_DEMANGLE -DNO_STRLCPY builtin-bench.c gcc -o /«PKGBUILDDIR»/debian/build/tools/perf/out/bench/sched-messaging.o -c -fno-omit-frame-pointer -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wno-error -fstack-protector-all -Wstack-protector -Wvolatile-register-var -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I/«PKGBUILDDIR»/debian/build/tools/perf/out/ -DLIBELF_NO_MMAP -DDWARF_SUPPORT -I/usr/include/slang -DHAVE_CPLUS_DEMANGLE -DNO_STRLCPY bench/sched-messaging.c gcc -o /«PKGBUILDDIR»/debian/build/tools/perf/out/bench/sched-pipe.o -c -fno-omit-frame-pointer -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wno-error -fstack-protector-all -Wstack-protector -Wvolatile-register-var -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I/«PKGBUILDDIR»/debian/build/tools/perf/out/ -DLIBELF_NO_MMAP -DDWARF_SUPPORT -I/usr/include/slang -DHAVE_CPLUS_DEMANGLE -DNO_STRLCPY bench/sched-pipe.c gcc -o /«PKGBUILDDIR»/debian/build/tools/perf/out/bench/mem-memcpy.o -c -fno-omit-frame-pointer -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wno-error -fstack-protector-all -Wstack-protector -Wvolatile-register-var -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I/«PKGBUILDDIR»/debian/build/tools/perf/out/ -DLIBELF_NO_MMAP -DDWARF_SUPPORT -I/usr/include/slang -DHAVE_CPLUS_DEMANGLE -DNO_STRLCPY bench/mem-memcpy.c gcc -o /«PKGBUILDDIR»/debian/build/tools/perf/out/builtin-diff.o -c -fno-omit-frame-pointer -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wno-error -fstack-protector-all -Wstack-protector -Wvolatile-register-var -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I/«PKGBUILDDIR»/debian/build/tools/perf/out/ -DLIBELF_NO_MMAP -DDWARF_SUPPORT -I/usr/include/slang -DHAVE_CPLUS_DEMANGLE -DNO_STRLCPY builtin-diff.c gcc -o
Bug#654740: linux-2.6: non-standard gcc/g++ used for build (gcc-4.4)
Package: linux-2.6 Version: 3.1.6-1 Severity: important User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.4 This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-4.6/g++-4.6. Please keep this report open until the package uses the default compiler version (or gcc-4.6) for the package build. The severity of this report is likely to be raised before the release, so that the gcc-4.4 package can be removed for the release. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1riobz-0001mi...@ravel.debian.org
Re: RFS: eclipse (new upstream release with Java 7 support)
On 12/30/2011 11:23 PM, Jakub Adam wrote: on which platforms? i.e. are the architecture templates updated to build on more than amd64 and i386? There are arm, ia64, mips, ppc and sparc in the additional architectures - see contents of debian/eclipse-build-additionalArchs.tar.bz2. I tried to build the armel variant and successfully compiled org.eclipse.swt.gtk.linux.arm plugin, which failed in previous 3.7.0-1 version[1], though I wasn't able to finish the complete build because of insufficient amount of RAM (seems it's not possible to use more than 256MB with arm in qemu). currently the heap of a process on ARM is limited to 2GB (which is still not enough to build eclipse). There is a fix submitted upstream which should help with this (https://launchpad.net/bugs/861296), although it needs deployment on the armel and armhf builders as well. This will allow building some more haskell packages as well. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4efe64ba.2070...@debian.org
Re: Increasing minimum 'i386' processor
On 11/19/2011 11:42 PM, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. note that squeeze is built this way, and single packages like openjdk only build for 586. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. could you give numbers what kind of improvements you would expect? The biggest burden for i386 is the register pressure, which you won't fix with targeting a newer processor. The better approach would be a new port, the x32 architecture; I don't know if anybody did look into building a distribution for this architecture yet. The next thing could be to default to sse2 math instead of x87 (didn't look if this is already the default for x32). Matthias -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ecc33cd.7040...@debian.org
Re: Increasing minimum 'i386' processor
On 11/20/2011 01:08 AM, Guillem Jover wrote: Hi! On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. It seems gcc has been targetting i586 instruction set by default since gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the discussion regarding multiarch tuples I proposed we should switch the triplet back to i386-linux-gnu to avoid this kind of confusion, fix the internal inconsistency and the one with other architectures (which do not track the base instruction set in the triplet) and so that we can use them directly as the multiarch tuples. For more details please see: http://lists.debian.org/debian-dpkg/2011/02/msg00061.html http://lists.debian.org/debian-dpkg/2011/02/msg00039.html No, that's wrong. i386-linux-gnu has a different ABI for at least some libraries (libstdc++) than i486-linux-gnu. Unfortunately the proposal to use ix86-linux-gnu for the i386 multiarch triplet didn't find a consensus. Matthias -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ecc34e9.6090...@debian.org
Bug#594289: linux-2.6: non-standard gcc/g++ used for build (gcc-4.3)
Package: linux-2.6 Version: 2.6.32-20 Severity: normal User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.3 This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++. Please keep this report open until the package uses the default compiler version for the package build. The severity of this report is likely to be raised before the release. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oo90r-qu...@ravel.debian.org
Bug#500956: unable to boot on a500 (hppa)
Package: linux-image-2.6.26-1-parisc64 Version: 2.6.26-6 Severity: serious the lenny installer does work, the kernel installed by the installer fails to boot. The etch kernel does boot. Command line for kernel: 'root=/dev/sda3 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux' Selected kernel: /vmlinux from partition 2 Selected ramdisk: /initrd.img from partition 2 ELF64 executable Entry 0010 first 0010 n 3 Segment 0 load 0010 size 3866624 mediaptr 0x1000 Segment 1 load 0050c000 size 354080 mediaptr 0x3b1000 Segment 2 load 00564000 size 274566 mediaptr 0x408000 Loading ramdisk 7068216 bytes @ 3f931000... Branching to kernel entry point 0x0010. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org * SYSTEM ALERT ** SYSTEM NAME: gsphppa DATE: 10/02/2008 TIME: 22:26:00 ALERT LEVEL: 7 = reserved REASON FOR ALERT SOURCE: 0 = unknown, no source stated SOURCE DETAIL: 0 = unknown, no source stated SOURCE ID: FF PROBLEM DETAIL: 0 = no problem detail LEDs: RUN ATTENTION FAULT REMOTE POWER FLASHFLASH OFF ON ON LED State: Running non-OS code. Non-critical error detected. Check Chassis and Console Logs for error messages. 0x007000FF6292 00F0 F000 - type 0 = Data Field Unused 0x5800087000FF6292 6C09 02161A00 - type 11 = Timestamp 10/02/2008 22:26:00 A: ack read of this entry - X: Disable all future alert messages Anything else skip redisplay the log entry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463295: linux-2.6: non-standard gcc/g++ used for build (gcc-4.1)
Package: linux-2.6 Severity: important User: [EMAIL PROTECTED] Usertags: non-standard-compiler, gcc-4.1 This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++. Please keep this report open until the package uses the default compiler version for the package build. The severity of this report is likely to be raised before the release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.3: Kernel build fails
Jörg Sommer writes: Hi, I don't know if you are aware of this fact. Compiling the kernel release 2.6.24 on PowerPC with gcc-4.3 fails. LD [M] lib/zlib_inflate/zlib_inflate.o GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o: In function `getnstimeofday': (.text+0x24988): undefined reference to `__umoddi3' kernel/built-in.o: In function `getnstimeofday': (.text+0x249a8): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x24b08): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x24b28): undefined reference to `__umoddi3' kernel/built-in.o: In function `timekeeping_resume': timekeeping.c:(.text+0x24e04): undefined reference to `__umoddi3' timekeeping.c:(.text+0x24e24): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x25374): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x25394): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x257f0): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x25810): undefined reference to `__udivdi3' make: *** [.tmp_vmlinux1] Fehler 1 these are defined in libgcc.a (linking with -static-libgcc should resolve these symbols).
i386 biarch support for lenny
The i386 biarch toolchain is built as biarch toolchain; the value of this is currently doubtful, because you only can use it in an i386 chroot on a machine running a 64bit kernel in the host system. With newer compiler versions apparently more hacks are needed to even build the biarch GCC, it currently ftbfs on a 32bit kernel (snapshot) on i386 and powerpc (afaik all our powerpc and i386 buildds run 32bit kernels). Do we still want to support the i386 biarch toolchain? If yes, the minimum support for that would be an amd64 kernel for the i386 architecture which is used on the buildds. Please could the kernel team first check the possibility of such an kernel? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i386 biarch support for lenny
Bastian Blank writes: On Sun, Sep 02, 2007 at 11:11:37PM +0200, Matthias Klose wrote: Please could the kernel team first check the possibility of such an kernel? | linux-image-2.6.18-5-amd64 | 2.6.18.dfsg.1-13 |stable | amd64, i386 Available in etch and newer. nice, are all the i386 buildds runnig this kernel? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious issues with linux-2.6 (was: Re: Scheduling linux-2.6 2.6.18-3)
Steve Langasek writes: On Thu, Oct 12, 2006 at 01:58:53PM +0200, Andreas Barth wrote: * Bastian Blank ([EMAIL PROTECTED]) [061012 12:41]: On Tue, Oct 10, 2006 at 01:53:58PM +0200, Frederik Schueler wrote: Two big issues are still open: - hppa FTBFS - alpha gcc-4.0 build dependency What should we do with them? Finally disable alpha and hppa(64)? I don't think it is an option to ship Debian without hppa and alpha kernels. So, the only two options seem to me: a) someone fixes these issues, or b) we ship with what we have in etch now, that is 2.6.17. The gcc-4.0 build-dependency is not new in 2.6.18, the current kernel in testing has the same issue. And I can see no reason to treat this as RC. some weeks ago, I asked what compiler version would be used for kernel compiles; I got the impression that the kernel team did want to switch to 4.1. Even if the kernel cannot be built with 4.1, it would be nice to have bug reports. I'm not aware of any alpha related reports, although it's not my pet arch. I'm still planning not to build g++-4.0 from the 4.0 sources, now that all packages are built using 4.1 or using 3.4 as a fallback. We'll need the 4.0 source anyway to build libgcc2 on hppa and glibc on the hurd. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-2.6 build-depends on gcc-4.0 [alpha]
linux-2.6 build-depends on gcc-4.0 [alpha], will this b-d be dropped for etch? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
TLS support (Re: linux-2.4 deprecated)
Steve Langasek writes: On Wed, Apr 05, 2006 at 11:06:21PM +0200, Aurelien Jarno wrote: A few weeks ago, the 2.4 kernels have been declared deprecated [1]. I would like to know what does this exactly mean: - That users are advised not to use them? - That we could drop support for them in other packages? - That they will be removed from the archive soon? It means 1), and should mean 3) as well. In general, it does *not* imply 2) -- we need to be assured of having a clean upgrade path from sarge to etch, and since sarge shipped with a 2.4 kernel by default, this means that etch packages should at least be functional enough on 2.4 to allow a full upgrade and subsequent reboot to a new kernel. (That includes not breaking the system if the upgrade is interrupted and the system is rebooted again to a 2.4 kernel before the upgrade completes.) In light of #361024, what are our options? - configure gcc with --disable-tls (on which architectures would that be (not) needed?) - build a libstdc++6 with a gcc, configured with --disable-tls and ship two versions? Would that help the upgrade issue? Sheplyakov Alexei writes: Current glibc does not support TLS under 2.4 kernels (see #226716), so this is probalby glibc bug (some people call it feature). - provide TLS support for 2.4 kernels and an upgrade path? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#322723: 'ip route' kernel problem w/ gcc-4.0
severity 322723 important thanks there's a workaround, and gcc-3.4 is known to work as well. Is there any reason to use gcc-4.0 for kernel builds on all architectures? Frans Pop writes: I've reassigned this bug from the kernel to gcc-4.0 as we feel that the solution chosen in the kernel packaging is not really a fix, but a workaround. As tests have shown that the problem does not exist when the same kernel is compiled with gcc-3.3, the real bug is likely in gcc-4.0. I've found the bug for 4.0.1-3 after looking at the dates for relevant uploads, but as uploads were quite frequent, I could be off by a version either way. Please see the bug history for details. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
