Bug#1071849: src:creduce: fails to migrate to testing for too long: blocked by Build-Depends
Source: creduce Version: 2.11.0~20231125-2 Severity: serious Control: close -1 2.11.0~20240312-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:creduce has been trying to migrate for 74 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on src:llvm-toolchain-18 which isn't ready to migrate to testing yet. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=creduce OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071846: src:cvise: fails to migrate to testing for too long: blocked by Build-Depends
Source: cvise Version: 2.9.0-2 Severity: serious Control: close -1 2.10.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:cvise has been trying to migrate for 74 days [2]. Hence, I am filing this bug. The version in unstable build depends on src:llvm-toolchain-18 which isn't ready to migrate to testing yet. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=cvise OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061633: libtemplates-parser: autopkgtest needs update for new version of gcc-12
Source: libtemplates-parser
Version: 23.0.0-3
Severity: serious
X-Debbugs-CC: gcc...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-12
Dear maintainer(s),
With a recent upload of gcc-12 the autopkgtest of libtemplates-parser
fails in testing when that autopkgtest is run with the binary packages
of gcc-12 from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
gcc-12 from testing12.3.0-14
libtemplates-parserfrom testing23.0.0-3
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of gcc-12 to testing
[1]. Of course, gcc-12 shouldn't just break your autopkgtest (or even
worse, your package), so please investigate.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from gcc-12 should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=gcc-12
https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtemplates-parser/42388674/log.gz
30s Changing to object directory of "P":
"/tmp/autopkgtest-lxc.xtf31hge/downtmp/autopkgtest_tmp/"
30s /usr/bin/gcc-12 -c -x ada -gnatA -gnatec=/tmp/GNAT-TEMP-03.TMP
-gnatem=/tmp/GNAT-TEMP-04.TMP
/tmp/autopkgtest-lxc.xtf31hge/downtmp/build.69k/src/docs/src/demo.adb
30s /usr/libexec/gprbuild/gprbind demo.bexch
30s /usr/bin/gnatbind -shared -o b__demo.adb
/tmp/autopkgtest-lxc.xtf31hge/downtmp/autopkgtest_tmp/demo.ali -x
-F=/tmp/GNAT-TEMP-05.TMP -O=/tmp/GNAT-TEMP-07.TMP
30s error: "templates_parser_tasking__standard_tasking.adb" must be
compiled
30s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/templates_parser/templates_parser_tasking__standard_tasking.ali"
is obsolete and read-only)
30s gprbind: invocation of gnatbind failed
30s gprbuild: unable to bind demo.adb
30s autopkgtest [11:05:41]: test link-with-shared
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1061631: libgnatcoll: autopkgtest needs update for new version of gcc-12
Source: libgnatcoll
Version: 23.0.0-3
Severity: serious
X-Debbugs-CC: gcc...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-12
Dear maintainer(s),
With a recent upload of gcc-12 the autopkgtest of libgnatcoll fails in
testing when that autopkgtest is run with the binary packages of gcc-12
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
gcc-12 from testing12.3.0-14
libgnatcollfrom testing23.0.0-3
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of gcc-12 to testing
[1]. Of course, gcc-12 shouldn't just break your autopkgtest (or even
worse, your package), so please investigate.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from gcc-12 should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=gcc-12
https://ci.debian.net/data/autopkgtest/testing/amd64/libg/libgnatcoll/42388673/log.gz
30s Changing to object directory of "proj":
"/tmp/autopkgtest-lxc.mdq8ugbr/downtmp/autopkgtest_tmp/"
30s /usr/bin/gcc-12 -c -x ada -gnatA -gnata
-gnatec=/tmp/GNAT-TEMP-03.TMP -gnatem=/tmp/GNAT-TEMP-04.TMP
/tmp/autopkgtest-lxc.mdq8ugbr/downtmp/autopkgtest_tmp/exec.adb
31s /usr/libexec/gprbuild/gprbind exec.bexch
31s /usr/bin/gnatbind -shared -o b__exec.adb
/tmp/autopkgtest-lxc.mdq8ugbr/downtmp/autopkgtest_tmp/exec.ali -x
-F=/tmp/GNAT-TEMP-05.TMP -O=/tmp/GNAT-TEMP-07.TMP
31s error: "gnatcoll-projects.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatcoll/gnatcoll-projects.ali"
is obsolete and read-only)
31s error: "gnatcoll-projects-krunch.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatcoll/gnatcoll-projects-krunch.ali"
is obsolete and read-only)
31s error: "gnatcoll-projects-normalize.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatcoll/gnatcoll-projects-normalize.ali"
is obsolete and read-only)
31s error: "gpr-tree.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-tree.ali" is obsolete
and read-only)
31s error: "gpr-env.adb" must be compiled
31s error: ("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-env.ali"
is obsolete and read-only)
31s error: "gpr-util.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-util.ali" is obsolete
and read-only)
31s error: "gpr-ali.adb" must be compiled
31s error: ("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-ali.ali"
is obsolete and read-only)
31s error: "gpr-conf.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-conf.ali" is obsolete
and read-only)
31s error: "gpr-nmsc.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-nmsc.ali" is obsolete
and read-only)
31s error: "gpr-part.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-part.ali" is obsolete
and read-only)
31s error: "gpr-dect.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-dect.ali" is obsolete
and read-only)
31s error: "gpr-strt.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-strt.ali" is obsolete
and read-only)
31s error: "gpr-proc.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-proc.ali" is obsolete
and read-only)
31s error: "gpr-knowledge.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-knowledge.ali" is
obsolete and read-only)
31s error: "gpr-sdefault.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-sdefault.ali" is
obsolete and read-only)
31s error: "gpr_build_util.adb" must be compiled
31s error:
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr_build_util.ali" is
obsolete and read-only)
31s error: "gpr-pp.adb" must be compiled
31s error: ("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-pp.ali"
is obsolete and read-only)
31s gprbind: invocation of gnatbind failed
31s gprbuild: unable to bind exec.adb
31s autopkgtest [11:05:42]: test projects
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1050063: src:gcc-11-cross-mipsen: fails to migrate to testing for too long: uploader built arch:all binaries
Source: gcc-11-cross-mipsen Version: 5+c3 Severity: serious Control: close -1 6+c1 Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gcc-11-cross-mipsen has been trying to migrate for 35 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gcc-11-cross-mipsen OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1049444: src:gcc-12-cross-mipsen: fails to migrate to testing for too long: blocked by gcc-13-cross-mipsen
Source: gcc-12-cross-mipsen Version: 3+c3 Severity: serious Control: close -1 4+c1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gcc-12-cross-mipsen has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable has build dependencies on packages from src:gcc-13-cross-mipsen which has build dependencies that are not satisfied. gcc-13-cross-mipsen can't migrate. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gcc-12-cross-mipsen OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1004184: gcc-11: generate bad code for matplotlib with -O1/-O2 on mips64el
Hi YunQiang, mips porters, On 28-04-2023 15:51, YunQiang Su wrote: Paul Gevers 于2023年4月27日周四 04:26写道： On Fri, 24 Feb 2023 23:10:29 + James Addison wrote: Hi Frederic: I'm linking a forwarded GCC GNU bug report that I _think_ is the upstream report matching this bug. I found it from a related GitHub issue[1] for matplotlib. The GCC bug reporter has done some work to create a minimal reproducer case. Could you check whether the issue reported there is the same one as here? (I will do eventually, but am not familiar with C and do not have mips hardware available so it may take some time) [1] - https://github.com/matplotlib/matplotlib/issues/21789 We're you ever made aware of this bug in gcc-11 and gcc-12? Maybe a bit of your help is appropriate. Sorry about that I forget this bug... I will dig it. Did anything happen here? Lagging progress (reporting) on bugs like this isn't great for architectures in the the architecture qualification. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1004184: gcc-11: generate bad code for matplotlib with -O1/-O2 on mips64el
Hi mips porters, On Fri, 24 Feb 2023 23:10:29 + James Addison wrote: Source: gcc-11 Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 Hi Frederic: I'm linking a forwarded GCC GNU bug report that I _think_ is the upstream report matching this bug. I found it from a related GitHub issue[1] for matplotlib. The GCC bug reporter has done some work to create a minimal reproducer case. Could you check whether the issue reported there is the same one as here? (I will do eventually, but am not familiar with C and do not have mips hardware available so it may take some time) [1] - https://github.com/matplotlib/matplotlib/issues/21789 We're you ever made aware of this bug in gcc-11 and gcc-12? Maybe a bit of your help is appropriate. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1029044: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1029044: fixed in gcc-12-cross-mipsen 3+c2)
control: reopen -1 control: found -1 3+c2 Hi, The version chosen in version 3+c2 is lower than what's in the archive. Version 12.2.0-14cross2 is still available in unstable while this upload only built version 12.2.0-14cross1. Paul elbrus@coccia:~$ cat /srv/ftp-master.debian.org/queue/reject/gcc-12-cross-mipsen_3+c2_mips64el-buildd. gcc-12-cross-mipsen_3+c2_mips64el-buildd.buildinfo gcc-12-cross-mipsen_3+c2_mips64el-buildd.changes gcc-12-cross-mipsen_3+c2_mips64el-buildd.changes.reason elbrus@coccia:~$ cat /srv/ftp-master.debian.org/queue/reject/gcc-12-cross-mipsen_3+c2_mips64el-buildd.changes.reason Version check failed: Your upload included the binary package cpp-12-mips-linux-gnu, version 12.2.0-14cross1, for mips64el, however unstable already has version 12.2.0-14cross2. Uploads to unstable must have a higher version than present in unstable. OpenPGP_signature Description: OpenPGP digital signature
Bug#1029044: gcc-12-cross-mipsen: source and binary version go out of sync
Source: gcc-12-cross-mipsen Version: 1+c2 Severity: serious Dear maintainer, The current version in unstable is stuck, because the mips64el build is kept in Uploaded state. Asking around on #d-buildd, I got the following discussion: [20:09:34] mips64el 3days in uploaded state feels like an issue, right? https://buildd.debian.org/status/package.php?p=gcc-12-cross-mipsen [20:18:32] probably means dak rejected it [20:18:45] Your upload included the binary package cpp-12-mips-linux-gnu, version 12.2.0-13cross1, for mips64el, [20:18:48] however unstable already has version 12.2.0-14cross2. [20:19:09] coccia:/srv/ftp-master.debian.org/queue/reject/gcc-12-cross-mipsen_3+c1_mips64el-buildd.changes.reason [20:29:57] the higher version is [20:29:57] Source: gcc-12-cross-mipsen (2+c1) [20:30:23] so the generated version numbers are broken [20:32:07] not for the first time afair [[21:04:30] adsb: thanks for looking; but the source is 3+c1, no? or did the older one generate a newer binary? You may want to check your logic. Paul
Bug#1028984: dh-ada-library: autopkgtest needs update for new version of gcc-10: deprecation warning on stderr
Source: dh-ada-library Version: 8.5 Severity: serious X-Debbugs-CC: gcc...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:gcc-10 Dear maintainer(s), With a recent upload of gcc-10 the autopkgtest of dh-ada-library fails in testing when that autopkgtest is run with the binary packages of gcc-10 from unstable. It passes when run with only packages from testing. In tabular form: passfail gcc-10 from testing10.4.0-7 dh-ada-library from testing8.5 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. The actual tests seem to pass but the autopkgtest fails because there are deprecation warnings on stderr. Without the allow-stderr restriction, autopkgtest errors out on output to stderr. Currently this regression is blocking the migration of gcc-10 to testing [1]. Of course, gcc-10 shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in gcc-10 was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from gcc-10 should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from gcc-10/10.4.0-7. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=gcc-10 https://ci.debian.net/data/autopkgtest/testing/amd64/d/dh-ada-library/30391876/log.gz Running Makefile dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) dpkg-buildflags: warning: cannot determine CC system type, falling back to default (native compilation) ADAFLAGS=-g -O0 -ffile-prefix-map=/tmp/autopkgtest-lxc.yefsn1ti/downtmp/autopkgtest_tmp/pkg=. -fstack-protector-strong canary -gno-record-gcc-switches -Wformat cflag -O0 canary -gno-record-gcc-switches OK autopkgtest [02:16:18]: test adaflags OpenPGP_signature Description: OpenPGP digital signature
Bug#1026129: src:gcc-12-cross-mipsen: fails to migrate to testing for too long: FTBFS on mips64el
Hi YunQiang, On Thu, 15 Dec 2022 09:07:51 +0100 Paul Gevers wrote: Source: gcc-12-cross-mipsen Your package failed to build on mips64el while it built there successfully in the past. Can you please look into this issue? It's blocking the migration of several RC bug fixes. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1020327: filezilla - fails to build from source (but built successfully in the past) - Forwarded upstream
Control: reassign -1 filezilla Control: retitle -1 filezilla must not target sse2 on i386 Control: severity -1 normal Hi Philip, On Wed, 21 Sep 2022 15:41:33 +0100 Philip Wyett wrote: The compiler does support SSE2 if you enable it, e.g. with the #pragma in the snippet. Sure it does. But the Debian baseline on i386 doesn't support sse2. So this is an issue in filezilla. If you still want to build on i386 (which apparently you don't), you must ensure that filezilla builds without the sse2 pieces. Paul PS: if you want filezilla to be part of bookworm, you need to ensure it migrates in time. Currently it's blocked on out-of-date binaries on arch:all and arch:i386. You need to request removal by filing a bug against ftp.debian.org if those need to be removed from the archive. OpenPGP_signature Description: OpenPGP digital signature
Bug#1026909: src:cvise: fails to migrate to testing for too long: FTBFS on mipsel
Source: cvise Version: 2.5.0-1 Severity: serious Control: close -1 2.6.0-1 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:cvise has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package failed to build from source on mipsel, where it successfully built in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=cvise OpenPGP_signature Description: OpenPGP digital signature
Bug#1026129: src:gcc-12-cross-mipsen: fails to migrate to testing for too long: FTBFS on mips64el
Source: gcc-12-cross-mipsen Version: 1+c2 Severity: serious Control: close -1 2+c1 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:gcc-12-cross-mipsen has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package failed to build on mips64el while it built there successfully in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=gcc-12-cross-mipsen OpenPGP_signature Description: OpenPGP digital signature
Bug#1026128: src:gcc-11-cross-mipsen: fails to migrate to testing for too long: dependency doesn't migrate
Source: gcc-11-cross-mipsen Version: 5+c1 Severity: serious Control: close -1 5+c3 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:gcc-11-cross-mipsen has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=gcc-11-cross-mipsen OpenPGP_signature Description: OpenPGP digital signature
Bug#1021735: libffi breaks python3.10 autopkgtest on arm64 (and 5 other packages)
Source: libffi Control: found -1 libffi/3.4.3-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks Dear maintainer(s), With a recent upload of libffi the autopkgtest of python3.10 fails in testing when that autopkgtest is run with the binary packages of libffi from unstable on arm64. 5 other packages also fail their test on arm64. It passes when run with only packages from testing. In tabular form: passfail libffi from testing3.4.3-2 python3.10 from testing3.10.7-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of libffi to testing [1]. Can you please investigate the situation? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=libffi https://ci.debian.net/data/autopkgtest/testing/arm64/p/python3.10/27000260/log.gz == Tests result: FAILURE == 397 tests OK. 1 test failed: test_ctypes 20 tests skipped: test_asdl_parser test_check_c_globals test_clinic test_devpoll test_gdb test_ioctl test_kqueue test_msilib test_smtpnet test_socketserver test_startfile test_tix test_tk test_urllib2net test_urllibnet test_winconsoleio test_winreg test_winsound test_xmlrpc_net test_zipfile64 0:17:53 load avg: 1.44 0:17:53 load avg: 1.44 Re-running failed tests in verbose mode 0:17:53 load avg: 1.44 Re-running test_ctypes in verbose mode (matching: test_struct_return_8H, test_struct_return_8H, test_struct_return_8H, test_callback_large_struct, test_struct_return_8H, test_struct_by_value) test_struct_return_8H (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ... FAIL test_struct_return_8H (ctypes.test.test_as_parameter.AsParamWrapperTestCase) ... FAIL test_struct_return_8H (ctypes.test.test_as_parameter.BasicWrapTestCase) ... FAIL test_callback_large_struct (ctypes.test.test_callbacks.SampleCallbacksTestCase) ... FAIL test_struct_return_8H (ctypes.test.test_functions.FunctionTestCase) ... FAIL test_struct_by_value (ctypes.test.test_win32.Structures) ... FAIL == FAIL: test_struct_return_8H (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) -- Traceback (most recent call last): File "/usr/lib/python3.10/ctypes/test/test_as_parameter.py", line 190, in test_struct_return_8H self.assertEqual((s8i.a, s8i.b, s8i.c, s8i.d, s8i.e, s8i.f, s8i.g, s8i.h), AssertionError: Tuples differ: (849208960, 196605, 4, 0, -1675480192, 458745, 8, 0) != (18, 24, 28, 30, 30, 28, 24, 18) First differing element 0: 849208960 18 - (849208960, 196605, 4, 0, -1675480192, 458745, 8, 0) + (18, 24, 28, 30, 30, 28, 24, 18) == FAIL: test_struct_return_8H (ctypes.test.test_as_parameter.AsParamWrapperTestCase) -- Traceback (most recent call last): File "/usr/lib/python3.10/ctypes/test/test_as_parameter.py", line 190, in test_struct_return_8H self.assertEqual((s8i.a, s8i.b, s8i.c, s8i.d, s8i.e, s8i.f, s8i.g, s8i.h), AssertionError: Tuples differ: (849208960, 196605, 4, 0, -1806091264, 458745, 8, 0) != (18, 24, 28, 30, 30, 28, 24, 18) First differing element 0: 849208960 18 - (849208960, 196605, 4, 0, -1806091264, 458745, 8, 0) + (18, 24, 28, 30, 30, 28, 24, 18) == FAIL: test_struct_return_8H (ctypes.test.test_as_parameter.BasicWrapTestCase) -- Traceback (most recent call last): File "/usr/lib/python3.10/ctypes/test/test_as_parameter.py", line 190, in test_struct_return_8H self.assertEqual((s8i.a, s8i.b, s8i.c, s8i.d, s8i.e, s8i.f, s8i.g, s8i.h), AssertionError: Tuples differ: (849208960, 196605, 4, 0, -1806094720, 458745, 8, 0) != (18, 24, 28, 30, 30, 28, 24, 18) First differing element 0: 849208960 18 - (849208960, 196605, 4, 0, -1806094720, 458745, 8, 0) + (18, 24, 28, 30, 30, 28, 24, 18) == FAIL: test_callback_large_struct (ctypes.test.test_callbacks.SampleCallbacksTestCase) -- Traceback (most recent call last): File "/usr/lib/python3.10/ctypes/test/test_callbacks.py", line 280, in test_callback_large_struct self.assertEqual(check.first, s.first) AssertionError: 281473275965456 != 3735928559 == FAIL: test_struct_return_8H (ctypes.test.test_functions.FunctionTestCase)
Bug#1020441: linux: autopkgtest needs update for new version of gcc-11
Source: linux Version: 5.19.6-1 Severity: serious X-Debbugs-CC: gcc...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:gcc-11 Dear maintainer(s), With a recent upload of gcc-11 the autopkgtest of linux fails in testing when that autopkgtest is run with the binary packages of gcc-11 from unstable. It passes when run with only packages from testing (it also fails in testing). In tabular form: passfail gcc-11 from testing11.3.0-6 linux from testing5.19.6-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of gcc-11 to testing [1]. Of course, gcc-11 shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the test "only" fails on "Unexpected warning" and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from gcc-11 should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gcc-11 https://ci.debian.net/data/autopkgtest/testing/amd64/l/linux/26272813/log.gz I: Found quick flavour cloud-amd64 I: Build for 5.19.0-1-cloud-amd64 make: Entering directory '/usr/src/linux-headers-5.19.0-1-cloud-amd64' test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2;\ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) warning: the compiler differs from the one used to build the kernel The kernel was built by: gcc-11 (Debian 11.3.0-5) 11.3.0 You are using: gcc-11 (Debian 11.3.0-6) 11.3.0 make -f /usr/src/linux-headers-5.19.0-1-common/scripts/Makefile.build obj=/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo \ single-build= \ need-builtin=1 need-modorder=1 gcc-11 -Wp,-MMD,/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo/.foo.o.d -nostdinc -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include -I./arch/x86/include/generated -I/usr/src/linux-headers-5.19.0-1-common/include -I./include -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/usr/src/linux-headers-5.19.0-1-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-5.19.0-1-common/include/linux/compiler-version.h -include /usr/src/linux-headers-5.19.0-1-common/include/linux/kconfig.h -include /usr/src/linux-headers-5.19.0-1-common/include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-5.19.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 -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -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 -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 -Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -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"' -DKBUILD_MODNAME='"foo"' -D__KBUILD_MODNAME=kmod_foo -c -o /tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo/foo.o
Bug#1005473: gcc-11-cross-ports: FTBFS: s-tsmona.adb:160: undefined reference to `dladdr'
Hi, On Sun, 13 Feb 2022 08:00:39 +0100 Lucas Nussbaum wrote: Source: gcc-11-cross-ports During a rebuild of all packages in sid, your package failed to build on amd64. Ping. gcc-11-cross-ports hasn't built since 1 February 2022. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1016156: xtl: autopkgtest needs update on i386 for gcc-12 as default: 2 failures
Source: xtl Version: 0.7.2-2 Severity: serious X-Debbugs-CC: gcc-defau...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:gcc-defaults Dear maintainer(s), With a recent upload of gcc-defaults the autopkgtest of xtl fails in testing on i386 when that autopkgtest is run with the binary packages of gcc-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail gcc-defaults from testing1.200 xtlfrom testing0.7.2-2 all others from testingfrom testing I copied some of the output at the bottom of this report. (Maybe you want to enable --output-on-failure such that info is available in the log). Currently this regression is blocking the migration of gcc-defaults to testing [1]. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gcc-defaults https://ci.debian.net/data/autopkgtest/testing/i386/x/xtl/24112985/log.gz Running tests... Test project /tmp/autopkgtest-lxc.yj53u3hj/downtmp/build.sSz/src/test Start 1: test_xbase64 1/23 Test #1: test_xbase64 . Passed0.00 sec Start 2: test_xbasic_fixed_string 2/23 Test #2: test_xbasic_fixed_string . Passed0.00 sec Start 3: test_xcomplex 3/23 Test #3: test_xcomplex Passed0.00 sec Start 4: test_xcomplex_sequence 4/23 Test #4: test_xcomplex_sequence ... Passed0.00 sec Start 5: test_xclosure 5/23 Test #5: test_xclosure Passed0.00 sec Start 6: test_xdynamic_bitset 6/23 Test #6: test_xdynamic_bitset . Passed0.00 sec Start 7: test_xfunctional 7/23 Test #7: test_xfunctional . Passed0.00 sec Start 8: test_xhalf_float 8/23 Test #8: test_xhalf_float . Passed0.00 sec Start 9: test_xhash 9/23 Test #9: test_xhash ... Passed6.46 sec Start 10: test_xhierarchy_generator 10/23 Test #10: test_xhierarchy_generator Passed0.00 sec Start 11: test_xiterator_base 11/23 Test #11: test_xiterator_base .. Passed0.00 sec Start 12: test_xmasked_value 12/23 Test #12: test_xmasked_value ...***Failed0.00 sec Start 13: test_xmeta_utils 13/23 Test #13: test_xmeta_utils . Passed0.00 sec Start 14: test_xmultimethods 14/23 Test #14: test_xmultimethods ... Passed0.00 sec Start 15: test_xoptional 15/23 Test #15: test_xoptional ... Passed0.00 sec Start 16: test_xsequence 16/23 Test #16: test_xsequence ... Passed0.00 sec Start 17: test_xtype_traits 17/23 Test #17: test_xtype_traits Passed0.00 sec Start 18: test_xplatform 18/23 Test #18: test_xplatform ... Passed0.00 sec Start 19: test_xproxy_wrapper 19/23 Test #19: test_xproxy_wrapper .. Passed0.00 sec Start 20: test_xsystem 20/23 Test #20: test_xsystem . Passed0.00 sec Start 21: test_xvariant 21/23 Test #21: test_xvariant Passed0.00 sec Start 22: test_xvisitor 22/23 Test #22: test_xvisitor Passed0.00 sec Start 23: xtest 23/23 Test #23: xtest ***Failed6.43 sec 91% tests passed, 2 tests failed out of 23 Total Test time (real) = 12.95 sec The following tests FAILED: 12 - test_xmasked_value (Failed) 23 - xtest (Failed) Errors while running CTest Output from these tests are in: /tmp/autopkgtest-lxc.yj53u3hj/downtmp/build.sSz/src/test/Testing/Temporary/LastTest.log Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely. make: *** [Makefile:71: test] Error 8 autopkgtest [12:17:15]: test command1 OpenPGP_signature Description: OpenPGP digital signature
Bug#1014109: gcc-12 breaks glibc autopkgtest on arm64: XFAIL: posix/annexc
Source: gcc-12, glibc
Control: found -1 gcc-12/12.1.0-5
Control: found -1 glibc/2.33-7
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of gcc-12 the autopkgtest of glibc fails in testing
on arm64 when that autopkgtest is run with the binary packages of gcc-12
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
gcc-12 from testing12.1.0-5
glibc from testing2.33-7
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of gcc-12 to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=gcc-12
https://ci.debian.net/data/autopkgtest/testing/arm64/g/glibc/23190432/log.gz
'GCONV_PATH=/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/iconvdata
LOCPATH=/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/localedata
LC_ALL=C' '
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/elf/ld-linux-aarch64.so.1
--library-path
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/math:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/elf:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/dlfcn:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/nss:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/nis:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/rt:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/resolv:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/mathvec:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/support:/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/nptl';
\
../scripts/evaluate-test.sh posix/wordexp-tst $? false false >
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/wordexp-tst.test-result
$* test failed
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/annexc
'aarch64-linux-gnu-gcc-10' \
'-I../csu -I../iconv -I../locale -I../localedata -I../iconvdata
-I../assert -I../ctype -I../intl -I../catgets -I../math -I../setjmp
-I../signal -I../stdlib -I../stdio-common -I../libio -I../dlfcn
-I../nptl -I../malloc -I../string -I../wcsmbs -I../timezone -I../time
-I../dirent -I../grp -I../pwd -I../posix -I../io -I../termios
-I../resource -I../misc -I../socket -I../sysvipc -I../gmon -I../gnulib
-I../wctype -I../manual -I../shadow -I../gshadow -I../po -I../argp
-I../rt -I../conform -I../debug -I../mathvec -I../support -I../nptl_db
-I../inet -I../resolv -I../nss -I../hesiod -I../sunrpc -I../nis
-I../nscd -I../login -I../elf -I../include
-I/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc
-I../sysdeps/unix/sysv/linux/aarch64 -I../sysdeps/aarch64/nptl
-I../sysdeps/unix/sysv/linux/generic
-I../sysdeps/unix/sysv/linux/wordsize-64
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
-I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/aarch64/fpu
-I../sysdeps/aarch64/multiarch -I../sysdeps/aarch64
-I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-128
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754 -I../sysdeps/generic -nostdinc -isystem
/usr/lib/gcc/aarch64-linux-gnu/10/include -isystem
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/debian/include -I..'
>
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/annexc.out;
\
../scripts/evaluate-test.sh posix/annexc $? true false >
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/annexc.test-result
${*} test failed
$@ test failed
$* quoted test failed
$@ quoted test failed
$# test failed
$2 ${3} $4 test failed
${11} test failed
"a $@ b" test failed
-
/tmp/autopkgtest-lxc.s8o48hbj/downtmp/build.Y8r/src/build-tree/arm64-libc/posix/wordexp-test-result10
differ: char 1, line 1
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1009923: src:cvise: fails to migrate to testing for too long: build depends on package that fails to migrate
Source: cvise Version: 2.4.0-2.1 Severity: serious Control: close -1 2.4.0-3 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:cvise has been trying to migrate for 61 days [2]. Hence, I am filing this bug. In the last upload you switch to use llvm-toolchain-14 for the build, but that's not ready to migrate to testing yet. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=cvise OpenPGP_signature Description: OpenPGP digital signature
Bug#1008869: src:gcc-11-cross-ports: fails to migrate to testing for too long: FTBFS
Source: gcc-11-cross-ports Version: 7 Severity: serious Control: close -1 8 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1005473 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:gcc-11-cross-ports has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=gcc-11-cross-ports OpenPGP_signature Description: OpenPGP digital signature
Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long
Hi YunQiang, On 24-03-2022 12:29, YunQiang Su wrote: Yes. I am aware of it. And I am waiting for gcc-12-cross-mipsen to finish building on all of these architectures. Although not clear to me why you wanted to wait, this happened 3.5 days ago. Will you do the source only upload soon? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long
Hi YunQiang, On 22-03-2022 07:06, YunQiang Su wrote: Paul Gevers 于2022年3月22日周二 04:04写道： On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers wrote: The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:gcc-defaults-mipsen has been trying to migrate for 62 days [2]. It's been 161 days now. We expect from you to solve these kind of issues, especially if they have been brought to your attention. ohh. sorry for it. I upload gcc-11-cross-mipsen some days ago. I thought that gcc-defaults-mipsen will migrate ok. I will fix it just now. You are aware that gcc-12-cross-mipsen needs another source-only upload because it's new and you needed to upload all binaries but non-buildd built binaries are not allowed to migrate. Unfortunately on the current infrastructure binNMU's of arch:all binaries don't work. gcc-12-cross-mipsen needs to be able to migrate together with gcc-11-cross-mipsen (and gcc-defaults-mipsen). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long
Hi mips porters, On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers wrote: The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:gcc-defaults-mipsen has been trying to migrate for 62 days [2]. It's been 161 days now. We expect from you to solve these kind of issues, especially if they have been brought to your attention. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1006948: gcc-12: FTBFS on mips64el
Source: gcc-12 Version: 12-20220222-1 Severity: serious Tags: ftbfs Dear Matthias, GCC maintainers, gcc-12 fails to build from source on mips64el in unstable. Normally this isn't an issue, but it builds a Build-Depends of gcc-11 which now can't migrate because it can't be build on mips64el. Paul
Bug#1006780: gcc-11-cross-mipsen: rebuild results in packages with unsatifiable dependencies
Source: gcc-11-cross-mipsen Version: 4+c1 Severity: serious Dear maintainer, Your package failed to migrate to testing because some binaries were built by the uploader instead of on the buildds. I tried to help and did a no-change source-only upload. However, this package seems to be complicated because the build succeeded, but the binaries are not installable [1]. Can you please fix your package and do a source-only upload such that it can migrate to testing? [1] https://qa.debian.org/excuses.php?package=gcc-11-cross-mipsen Paul
checking on bookworm freeze dates proposal
Dear colleagues, The Release Team would like to propose a bookworm freeze timeline. Don't worry, the timeline is a plan, if serious (timing) issues come up we will adapt. However, before making the plan public in a wider audience, we'd like to know from you if you already foresee clashes in timing from the kernel, gcc, binutils and glibc that we should take into account. Does the following timeline seem reasonable to you considering plans of your upstream? (the bullseye schedule + 2 years): 2023-01-12 - Milestone 1 - Transition and Toolchain freeze 2023-02-12 - Milestone 2 - Soft Freeze 2023-03-12 - Milestone 3 - Hard Freeze TBA- Milestone 4 - Full Freeze On behalf of the Release Team, Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long
Hi YunQiang, On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers wrote: Your package src:gcc-defaults-mipsen has been trying to migrate for 62 days [2]. Hence, I am filing this bug. Any progress? It has been 1.5 months and I haven't seen anything happening. This is NOK. gcc-defaults-mipsen is a key package, so I can't just remove it. Please ensure the package can migrate. It seems to me that your failing to build all kind of required packages, although it's not clear if those should come from e.g. gcc-11 (which apparently started to build again itself on mipsel and mips64el. I'm not versed enough in how this piece of toolchain should work. If you need my help as a Release Team member, don't hesitate to reach out, but I don't want to spend time on reverse engineering this *. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long
Source: gcc-defaults-mipsen Version: 1.189 Severity: serious Control: close -1 1.194 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:gcc-defaults-mipsen has been trying to migrate for 62 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=gcc-defaults-mipsen OpenPGP_signature Description: OpenPGP digital signature
Bug#996281: simde: autopkgtest needs update for new version of gcc-defaults: x86/sse2/native/c(pp|) failed
Source: simde Version: 0.7.2-4 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:gcc-defaults [X-Debbugs-CC: debian...@lists.debian.org, gcc-defau...@packages.debian.org] Dear maintainer(s), With a recent upload of gcc-defaults the autopkgtest of simde fails in testing when that autopkgtest is run with the binary packages of gcc-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail gcc-defaults from testing1.194 simde from testing0.7.2-4 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of gcc-defaults to testing [1]. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from gcc-defaults should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gcc-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/s/simde/15914134/log.gz 289/874 x86/sse2/native/c ERROR 0.59s exit status 1 >>> MALLOC_PERTURB_=93 /tmp/autopkgtest-lxc.vneo8tix/downtmp/autopkgtest_tmp/build-gcc/test/x86/sse2-native-c ― ✀ ― stderr: ../test/x86/sse2.c:4432: assertion failed: r[0] == simde_x_mm_loadu_epi16(test_vec[i].r)[0] (0 == -11138) ../test/x86/sse2.c:4465: assertion failed: r[0] == simde_x_mm_loadu_epi32(test_vec[i].r)[0] (0 == 418822831) (test program exited with status code 1) ―― 290/874 x86/sse2/native/cppERROR 0.59s exit status 1 >>> MALLOC_PERTURB_=239 /tmp/autopkgtest-lxc.vneo8tix/downtmp/autopkgtest_tmp/build-gcc/test/x86/sse2-native-cpp ― ✀ ― stderr: test/x86/sse2.cpp:4432: assertion failed: r[0] == simde_x_mm_loadu_epi16(test_vec[i].r)[0] (0 == -11138) test/x86/sse2.cpp:4465: assertion failed: r[0] == simde_x_mm_loadu_epi32(test_vec[i].r)[0] (0 == 418822831) (test program exited with status code 1) ―― OpenPGP_signature Description: OpenPGP digital signature
Bug#996280: seqan3: autopkgtest needs update for new version of gcc-defaults
Source: seqan3
Version: 3.0.2+ds-9
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-defaults
[X-Debbugs-CC: debian...@lists.debian.org, gcc-defau...@packages.debian.org]
Dear maintainer(s),
With a recent upload of gcc-defaults the autopkgtest of seqan3 fails in
testing when that autopkgtest is run with the binary packages of
gcc-defaults from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
gcc-defaults from testing1.194
seqan3 from testing3.0.2+ds-9
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of gcc-defaults to
testing [1].
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from gcc-defaults should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=gcc-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/s/seqan3/15914132/log.gz
/tmp/autopkgtest-lxc.yel9kndg/downtmp/autopkgtest_tmp/unit/alignment/pairwise/pairwise_alignment_single_test_template.hpp:101:48:
required from ‘void
gtest_suite_pairwise_alignment_test_::alignment::TestBody()
[with gtest_TypeParam_ = pairwise_alignment_fixture<(&
seqan3::test::alignment::fixture::global::affine::banded::dna4_single_diagonal)>]’
/tmp/autopkgtest-lxc.yel9kndg/downtmp/autopkgtest_tmp/unit/alignment/pairwise/pairwise_alignment_single_test_template.hpp:89:1:
required from here
/usr/include/seqan3/alignment/pairwise/edit_distance_unbanded.hpp:946:19: error:
‘struct
seqan3::detail::edit_distance_unbanded&,
std::vector&,
seqan3::configuration >, seqan3::align_cfg::output_score,
seqan3::align_cfg::output_end_position,
seqan3::align_cfg::output_begin_position,
seqan3::align_cfg::output_alignment,
seqan3::detail::debug_mode >,
seqan3::align_cfg::detail::result_type >, seqan3::gap_decorator > >,
seqan3::detail::two_dimensional_matrix,
std::allocator >,
seqan3::detail::matrix_major_order::column>,
seqan3::detail::two_dimensional_matrix,
std::allocator >,
seqan3::detail::matrix_major_order::column> > > > >,
seqan3::detail::default_edit_distance_trait_type&,
std::vector&,
seqan3::configuration >, seqan3::align_cfg::output_score,
seqan3::align_cfg::output_end_position,
seqan3::align_cfg::output_begin_position,
seqan3::align_cfg::output_alignment,
seqan3::detail::debug_mode >,
seqan3::align_cfg::detail::result_type >, seqan3::gap_decorator > >,
seqan3::detail::two_dimensional_matrix,
std::allocator >,
seqan3::detail::matrix_major_order::column>,
seqan3::detail::two_dimensional_matrix,
std::allocator >,
seqan3::detail::matrix_major_order::column> > > > >,
std::integral_constant, long unsigned int>
>::compute_state’ has no member named ‘db’; did you mean ‘b’?
946 | state.db =
proxy_reference{this->db[current_block]};
| ~~^~
| b
/usr/include/seqan3/alignment/pairwise/edit_distance_unbanded.hpp:952:19: error:
‘struct
seqan3::detail::edit_distance_unbanded&,
std::vector&,
seqan3::configuration >, seqan3::align_cfg::output_score,
seqan3::align_cfg::output_end_position,
seqan3::align_cfg::output_begin_position,
seqan3::align_cfg::output_alignment,
seqan3::detail::debug_mode >,
seqan3::align_cfg::detail::result_type >, seqan3::gap_decorator > >,
seqan3::detail::two_dimensional_matrix,
std::allocator >,
seqan3::detail::matrix_major_order::column>,
seqan3::detail::two_dimensional_matrix,
std::allocator >,
seqan3::detail::matrix_major_order::column> > > > >,
seqan3::detail::default_edit_distance_trait_type&,
std::vector&,
seqan3::configuration >, seqan3::align_cfg::output_score,
seqan3::align_cfg::output_end_position,
seqan3::align_cfg::output_begin_position,
seqan3::align_cfg::output_alignment,
seqan3::detail::debug_mode >,
seqan3::align_cfg::detail::result_type >, seqan3::gap_decorator > >,
seqan3::detail::two_dimensional_matrix,
std::allocator >,
seqan3::detail::matrix_major_order::column>,
seqan3::detail::two_dimensional_matrix,
std::allocator >,
seqan3::detail::matrix_major_order::column> > > > >,
std::integral_constant, long unsigned int>
>::compute_state’ has no member named ‘db’; did you mean ‘b’?
952 | state.db = ~(state.b ^ state.d0);
| ~~^~
| b
make[2]: ***
[alignment/pairwise/CMakeFiles/global_affine_banded_test.dir/build.make:79:
Bug#996279: xmds2: autopkgtest needs update for new version of gcc-defaults: 5 tests fail to build
Source: xmds2
Version: 3.0.0+dfsg-5
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-defaults
[X-Debbugs-CC: debian...@lists.debian.org, gcc-defau...@packages.debian.org]
Dear maintainer(s),
With a recent upload of gcc-defaults the autopkgtest of xmds2 fails in
testing on the releases where it's not blocked when that autopkgtest is
run with the binary packages of gcc-defaults from unstable. It passes
when run with only packages from testing. In tabular form:
passfail
gcc-defaults from testing1.194
xmds2 from testing3.0.0+dfsg-5
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of gcc-defaults to
testing [1].
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from gcc-defaults should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=gcc-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/x/xmds2/15914167/log.gz
==
FAIL: test_fibre_integer_dimensions_mpi
(__main__.main..ScriptTestCase)
mpi/fibre_integer_dimensions_mpi.xmds
--
Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.ekv9ekvw/downtmp/build.mTv/src/./run_tests.py",
line 328, in newfunc
return func(*(args + fargs), **newkeywords)
File
"/tmp/autopkgtest-lxc.ekv9ekvw/downtmp/build.mTv/src/./run_tests.py",
line 106, in scriptTestingFunction
self.assertTrue(returnCode == 0, ("Failed to compile." % locals()) +
message)
AssertionError: False is not true : Failed to compile.
stdout:
b'xmds2 version 3.0.0 "Release the Kraken" (Debian package
3.0.0+dfsg-5)\nCopyright 2000-2019 Graham Dennis, Joseph Hope, Mattias
Johnsson\nand the xmds team\nGenerating source
code...\n... done\nCompiling simulation...\n\n\nFATAL ERROR: Failed to
compile. Check warnings and errors. The most important will be first.\n'
stderr:
b'In file included from
/usr/lib/python3/dist-packages/xpdeint/includes/solirte/randpool.h:19,\n
from
/usr/lib/python3/dist-packages/xpdeint/includes/solirte/prng.h:13,\n
from
fibre_integer_dimensions_mpi.cc:96:\n/usr/lib/python3/dist-packages/xpdeint/includes/solirte/u128simd.h:
In function \xe2\x80\x98uint128_t SIMDOps::AndNot(const uint128_t&,
const
uint128_t&)\xe2\x80\x99:\n/usr/lib/python3/dist-packages/xpdeint/includes/solirte/u128simd.h:402:32:
warning: narrowing conversion of
\xe2\x80\x98SIMDOps::AndNot(((uint64_t)((int64_t)LHS.uint128_t::VecData[0])),
((uint64_t)((int64_t)RHS.uint128_t::VecData[0])))\xe2\x80\x99 from
\xe2\x80\x98uint64_t\xe2\x80\x99 {aka \xe2\x80\x98long unsigned
int\xe2\x80\x99} to \xe2\x80\x98int64_t\xe2\x80\x99 {aka
\xe2\x80\x98long int\xe2\x80\x99} [-Wnarrowing]\n 402 | uint128_t
RetVal = {{AndNot(LHS.VecData[0], RHS.VecData[0]),
AndNot(LHS.VecData[1], RHS.VecData[1])}};\n |
~~^~~~\n/usr/lib/python3/dist-packages/xpdeint/includes/solirte/u128simd.h:402:72:
warning: narrowing conversion of
\xe2\x80\x98SIMDOps::AndNot(((uint64_t)((int64_t)LHS.uint128_t::VecData[1])),
((uint64_t)((int64_t)RHS.uint128_t::VecData[1])))\xe2\x80\x99 from
\xe2\x80\x98uint64_t\xe2\x80\x99 {aka \xe2\x80\x98long unsigned
int\xe2\x80\x99} to \xe2\x80\x98int64_t\xe2\x80\x99 {aka
\xe2\x80\x98long int\xe2\x80\x99} [-Wnarrowing]\n 402 | uint128_t
RetVal = {{AndNot(LHS.VecData[0], RHS.VecData[0]),
AndNot(LHS.VecData[1], RHS.VecData[1])}};\n |
~~^~~~\n/usr/lib/python3/dist-packages/xpdeint/includes/solirte/u128simd.h:
In function \xe2\x80\x98uint128_t SIMDOps::Parity(const
uint128_t&)\xe2\x80\x99:\n/usr/lib/python3/dist-packages/xpdeint/includes/solirte/u128simd.h:468:26:
warning: narrowing conversion of \xe2\x80\x98x\xe2\x80\x99 from
\xe2\x80\x98uint64_t\xe2\x80\x99 {aka \xe2\x80\x98long unsigned
int\xe2\x80\x99} to \xe2\x80\x98int64_t\xe2\x80\x99 {aka
\xe2\x80\x98long int\xe2\x80\x99} [-Wnarrowing]\n 468 | uint128_t
RetVal = {{x, x}};\n |
^\n/usr/lib/python3/dist-packages/xpdeint/includes/solirte/u128simd.h:468:29:
warning: narrowing conversion of \xe2\x80\x98x\xe2\x80\x99 from
\xe2\x80\x98uint64_t\xe2\x80\x99 {aka \xe2\x80\x98long unsigned
int\xe2\x80\x99} to \xe2\x80\x98int64_t\xe2\x80\x99 {aka
\xe2\x80\x98long int\xe2\x80\x99} [-Wnarrowing]\n
Bug#996278: open3d: autopkgtest needs update for new version of gcc-defaults: output on stderr
Source: open3d
Version: 0.9.0+ds-6
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-defaults
[X-Debbugs-CC: debian...@lists.debian.org, gcc-defau...@packages.debian.org]
Dear maintainer(s),
With a recent upload of gcc-defaults the autopkgtest of open3d fails in
testing on arm64, armhf and ppc64el when that autopkgtest is run with
the binary packages of gcc-defaults from unstable. It passes when run
with only packages from testing. In tabular form:
passfail
gcc-defaults from testing1.194
open3d from testing0.9.0+ds-6
all others from testingfrom testing
I copied some of the output at the bottom of this report. The failure is
due to output on stderr. Output to stderr is by default considered by
autopkgtest as a failure of the test. If you want to have test fail on
output to stderr, please fix the reason of the output. If you don't care
you can add the allow-stderr restriction to have autopkgtest ignore the
output.
Currently this regression is blocking the migration of gcc-defaults to
testing [1]. Of course, gcc-defaults shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in gcc-defaults was intended and your package needs to update to
the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from gcc-defaults should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=gcc-defaults
https://ci.debian.net/data/autopkgtest/testing/arm64/o/open3d/15926028/log.gz
autopkgtest [01:10:43]: test test-cpp: [---
$ cmake .
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found GLEW: /usr/include (found version "2.2.0")
-- Found Open3D:
/usr/lib/aarch64-linux-gnu/cmake/Open3D/Open3DConfig.cmake (found
version "0.9.0")
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/tmp.HsneE5NHLQ
$ make VERBOSE=ON
/usr/bin/cmake -S/tmp/tmp.HsneE5NHLQ -B/tmp/tmp.HsneE5NHLQ
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /tmp/tmp.HsneE5NHLQ/CMakeFiles
/tmp/tmp.HsneE5NHLQ//CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/tmp/tmp.HsneE5NHLQ'
make -f CMakeFiles/open3d_test.dir/build.make
CMakeFiles/open3d_test.dir/depend
make[2]: Entering directory '/tmp/tmp.HsneE5NHLQ'
cd /tmp/tmp.HsneE5NHLQ && /usr/bin/cmake -E cmake_depends "Unix
Makefiles" /tmp/tmp.HsneE5NHLQ /tmp/tmp.HsneE5NHLQ /tmp/tmp.HsneE5NHLQ
/tmp/tmp.HsneE5NHLQ
/tmp/tmp.HsneE5NHLQ/CMakeFiles/open3d_test.dir/DependInfo.cmake --color=
make[2]: Leaving directory '/tmp/tmp.HsneE5NHLQ'
make -f CMakeFiles/open3d_test.dir/build.make
CMakeFiles/open3d_test.dir/build
make[2]: Entering directory '/tmp/tmp.HsneE5NHLQ'
[ 50%] Building CXX object CMakeFiles/open3d_test.dir/open3d_test.cpp.o
/usr/bin/c++ -DFMT_LOCALE -DFMT_SHARED -isystem /usr/include/eigen3 -MD
-MT CMakeFiles/open3d_test.dir/open3d_test.cpp.o -MF
CMakeFiles/open3d_test.dir/open3d_test.cpp.o.d -o
CMakeFiles/open3d_test.dir/open3d_test.cpp.o -c
/tmp/tmp.HsneE5NHLQ/open3d_test.cpp
In file included from /usr/include/Open3D/Open3D.h:30,
from /tmp/tmp.HsneE5NHLQ/open3d_test.cpp:1:
/usr/include/Open3D/Camera/PinholeCameraIntrinsic.h: In member function
‘std::pair
open3d::camera::PinholeCameraIntrinsic::GetFocalLength() const’:
/usr/include/Open3D/Camera/PinholeCameraIntrinsic.h:93:54: note:
parameter passing for argument of type ‘std::pair’ when
C++17 is enabled changed to match C++14 in GCC 10.1
93 | std::pair GetFocalLength() const {
| ^
[100%] Linking CXX executable open3d_test
/usr/bin/cmake -E cmake_link_script CMakeFiles/open3d_test.dir/link.txt
--verbose=ON
/usr/bin/c++ CMakeFiles/open3d_test.dir/open3d_test.cpp.o -o open3d_test
/usr/lib/aarch64-linux-gnu/libOpen3D.so.0d
make[2]: Leaving directory '/tmp/tmp.HsneE5NHLQ'
[100%] Built target open3d_test
make[1]: Leaving directory
Bug#996277: deal.ii: autopkgtest needs update for new version of gcc-defaults: An error occurred in line <1048> of file <./source/fe/mapping_q_generic.cc> in function
Source: deal.ii
Version: 9.3.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-defaults
[X-Debbugs-CC: debian...@lists.debian.org, gcc-defau...@packages.debian.org]
Dear maintainer(s),
With a recent upload of gcc-defaults the autopkgtest of deal.ii fails in
testing on amd64 and ppc64el when that autopkgtest is run with the
binary packages of gcc-defaults from unstable. It passes when run with
only packages from testing. In tabular form:
passfail
gcc-defaults from testing1.194
deal.iifrom testing9.3.0-1
all others from testingfrom testing
I copied some of the output on amd64 at the bottom of this report;
ppc64el fails in a different way.
Currently this regression is blocking the migration of gcc-defaults to
testing [1]. Of course, gcc-defaults shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in gcc-defaults was intended and your package needs to update to
the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from gcc-defaults should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=gcc-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/d/deal.ii/15913694/log.gz
-- Build files have been written to:
/tmp/autopkgtest-lxc.hp8op3fo/downtmp/autopkgtest_tmp/examples/step-50
make
[ 50%] Building CXX object CMakeFiles/step-50.dir/step-50.cc.o
In file included from
/usr/include/boost/smart_ptr/detail/sp_thread_sleep.hpp:22,
from /usr/include/boost/smart_ptr/detail/yield_k.hpp:23,
from
/usr/include/boost/smart_ptr/detail/spinlock_gcc_atomic.hpp:14,
from /usr/include/boost/smart_ptr/detail/spinlock.hpp:42,
from
/usr/include/boost/smart_ptr/detail/spinlock_pool.hpp:25,
from /usr/include/boost/smart_ptr/shared_ptr.hpp:29,
from
/usr/include/boost/archive/detail/helper_collection.hpp:27,
from
/usr/include/boost/archive/detail/basic_iarchive.hpp:28,
from
/usr/include/boost/archive/detail/common_iarchive.hpp:21,
from
/usr/include/boost/archive/basic_binary_iarchive.hpp:30,
from
/usr/include/boost/archive/binary_iarchive_impl.hpp:21,
from /usr/include/boost/archive/binary_iarchive.hpp:20,
from /usr/include/deal.II/base/utilities.h:45,
from /usr/include/deal.II/base/tensor.h:26,
from /usr/include/deal.II/base/point.h:23,
from /usr/include/deal.II/base/geometry_info.h:24,
from /usr/include/deal.II/base/data_out_base.h:22,
from
/tmp/autopkgtest-lxc.hp8op3fo/downtmp/autopkgtest_tmp/examples/step-50/step-50.cc:29:
/usr/include/boost/detail/no_exceptions_support.hpp:17:1: note: ‘#pragma
message: This header is deprecated. Use
instead.’
17 | BOOST_HEADER_DEPRECATED("")
| ^~~
[100%] Linking CXX executable step-50
[100%] Built target step-50
./step-50 gmg_mb_2d.prm
Cycle 0:
Number of active cells: 12 (2 global levels)
Partition efficiency: 1
Number of degrees of freedom: 65 (by level: 21, 65)
An error occurred in line <1048> of file
<./source/fe/mapping_q_generic.cc> in function
dealii::CellSimilarity::Similarity dealii::MappingQGeneric::fill_fe_values(const typename dealii::Triangulation::cell_iterator&, dealii::CellSimilarity::Similarity, const
dealii::Quadrature&, const typename dealii::Mapping::InternalDataBase&,
dealii::internal::FEValuesImplementation::MappingRelatedData&) const [with int dim = 2; int spacedim = 2; typename
dealii::Triangulation::cell_iterator =
dealii::TriaIterator >; typename
dealii::Mapping::InternalDataBase = dealii::Mapping<2,
2>::InternalDataBase]
The violated condition was:
det > 1e-12 * Utilities::fixed_power( cell->diameter() /
std::sqrt(double(dim)))
Additional information:
The image of the mapping applied to cell with center [-1 -0.125] is
distorted. The cell geometry or the mapping are invalid, giving a
non-positive volume fraction of -0.221825 in quadrature point 0.
Stacktrace:
---
#0 /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.3.0:
dealii::MappingQGeneric<2,
2>::fill_fe_values(dealii::TriaIterator >
const&, dealii::CellSimilarity::Similarity, dealii::Quadrature<2>
const&,
Bug#974875: src:gcc-9-cross: fails to migrate to testing for too long: FTBFS on i386
Source: gcc-9-cross Version: 22 Severity: serious Control: close -1 23 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:gcc-9-cross in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=gcc-9-cross signature.asc Description: OpenPGP digital signature
Arch qualification for buster: call for DSA, Security, toolchain concerns
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) * 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) 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 signature.asc Description: OpenPGP digital signature
Bug#961397: src:gcc-9-cross-ports: fails to migrate to testing for too long: not installable on arm64
Source: gcc-9-cross-ports Version: 16 Severity: serious Control: close -1 18 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:gcc-9-cross-ports in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=gcc-9-cross-ports signature.asc Description: OpenPGP digital signature
Bug#960214: gcc-9 breaks libalien-wxwidgets-perl autopkgtest: Can't exec "gcc": No such file or directory
Source: gcc-9, libalien-wxwidgets-perl Control: found -1 gcc-9/9.3.0-12 Control: found -1 libalien-wxwidgets-perl/0.69+dfsg-2 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), [This looks very similar to bug #960212 which will be a duplicate if really gcc-9 is at fault here.] With a recent upload of gcc-9 the autopkgtest of libalien-wxwidgets-perl fails in testing when that autopkgtest is run with the binary packages of gcc-9 from unstable. It passes when run with only packages from testing. In tabular form: passfail gcc-9 from testing9.3.0-12 libalien-wxwidgets-perl from testing0.69+dfsg-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of gcc-9 to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gcc-9 https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libalien-wxwidgets-perl/5415612/log.gz autopkgtest [05:08:43]: test autodep8-perl: /usr/share/pkg-perl-autopkgtest/runner runtime-deps autopkgtest [05:08:43]: test autodep8-perl: [--- # Failed test ' /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 exited successfully' # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 106. # Failed test ' /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 produced no (non-whitelisted) output' # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108. # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 exited successfully' # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 106. # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 produced no (non-whitelisted) output' # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108. # Looks like you failed 4 tests of 4. /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 1..4 # Can't exec "gcc": No such file or directory at /usr/share/perl/5.30/ExtUtils/CBuilder/Base.pm line 342. # # ATTENTION: It apperars 'gcc' is not a working compiler, please make # sure all necessary packages are installed. # # Searching configuration for: # wxWidgets (any version) for (any toolkit); compiler compatibility: nc (any version); # # Available configurations: # wxWidgets 3.04 for gtk; compiler compatibility: gcc 3.4; options: no debug, unicode, no mslu # BEGIN failed--compilation aborted. not ok 1 - /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 exited successfully not ok 2 - /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 produced no (non-whitelisted) output # Can't exec "gcc": No such file or directory at /usr/share/perl/5.30/ExtUtils/CBuilder/Base.pm line 342. # # ATTENTION: It apperars 'gcc' is not a working compiler, please make # sure all necessary packages are installed. # # Searching configuration for: # wxWidgets (any version) for (any toolkit); compiler compatibility: nc (any version); # # Available configurations: # wxWidgets 3.04 for gtk; compiler compatibility: gcc 3.4; options: no debug, unicode, no mslu # BEGIN failed--compilation aborted. not ok 3 - env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 exited successfully not ok 4 - env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 produced no (non-whitelisted) output Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/4 subtests Test Summary Report --- /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t (Wstat: 1024 Tests: 4 Failed: 4) Failed tests: 1-4 Non-zero exit status: 4 Files=1, Tests=4, 11 wallclock secs ( 0.03 usr 0.00 sys + 0.36 cusr 0.07 csys = 0.46 CPU) Result: FAIL signature.asc Description: OpenPGP digital signature
Bug#960212: gcc-9 breaks iraf autopkgtest: gcc: not found
Source: gcc-9, iraf Control: found -1 gcc-9/9.3.0-12 Control: found -1 iraf/2.16.1+2018.11.01-3 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of gcc-9 the autopkgtest of iraf fails in testing when that autopkgtest is run with the binary packages of gcc-9 from unstable. It passes when run with only packages from testing. In tabular form: passfail gcc-9 from testing9.3.0-12 iraf from testing2.16.1+2018.11.01-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of gcc-9 to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gcc-9 https://ci.debian.net/data/autopkgtest/testing/amd64/i/iraf/5415611/log.gz === Failure in programming.md:323 with ecl.e === Expected cl> softools cl> xc -w jmptest.x cl> task $jmptest = jmptest.e cl> jmptest status = 0, step = 0 Calling zdojmp status = 1, step = 1 All OK Output == cl> softools cl> xc -w jmptest.x /usr/lib/iraf/unix/hlib/f77.sh: 208: gcc: not found cl> task $jmptest = jmptest.e cl> jmptest ERROR: Cannot open connected subprocess (./jmptest.e) called as: `cl ()' Error while reading login.cl file - may need to rebuild with mkiraf Fatal startup error. CL dies. Diff @@ -1,8 +1,9 @@ cl> softools cl> xc -w jmptest.x +/usr/lib/iraf/unix/hlib/f77.sh: 208: gcc: not found cl> task $jmptest = jmptest.e cl> jmptest -status = 0, step = 0 -Calling zdojmp -status = 1, step = 1 -All OK +ERROR: Cannot open connected subprocess (./jmptest.e) + called as: `cl ()' +Error while reading login.cl file - may need to rebuild with mkiraf +Fatal startup error. CL dies. autopkgtest [05:07:20]: test command1: ---] signature.asc Description: OpenPGP digital signature
Bug#953711: src:autofdo: fails to migrate to testing for too long
Source: autofdo Version: 0.18-2 Severity: serious Control: fixed -1 0.19-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:autofdo in its current version in unstable has been trying to migrate for 136 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have marked the version in unstable as fixing this bug, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=autofdo signature.asc Description: OpenPGP digital signature
Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
Control: retitle -1 libgcc1 should add a Breaks on cryptsetup-initramfs Hi Matthias, initramfs-tools maintainers, > Am Montag, den 03.02.2020, 18:59 +0100 schrieb Matthias Klose: > > I'm fine to add some breaks if required. cryptsetup-initramfs version 2:2.2.2-3 already worked around the issue and has migrated to testing. Adding a Breaks on cryptsetup-initramfs << 2:2.2.2-3~ (IIAC) will prevent this specific issue. > This gets now fixed directly in initramfs-tools: > > https://salsa.debian.org/kernel-team/initramfs-tools/commit/f2ac13e8881f975b062a56050ceda85ef9ccc015 > > See also #950254 > > So I guess as soon as that is uploaded, libgcc1 should then Breaks: the > older versions. I think it makes sense to add that Breaks for safety as well, once that fix gets uploaded, but do we need to block the migration of gcc-10 until that happens? If so, can that upload happen soon? Paul signature.asc Description: OpenPGP digital signature
Re: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Dear all, The visible progress on this bug report stopped several days ago. I'd like to try an get it a bit further. I'm expecting frustration on all sides, but let's try to work together to fix the current situation. In case you aren't aware, the fact that gcc-9 hasn't migrated to testing in the last couple of weeks is starting to impact quite some uploads and transitions (search for "gcc-9 (not considered)" in https://release.debian.org/britney/update_excuses.html) Rene, I really appreciate the fact that libreoffice has an extensive test suite. But just to get options on the table can you please tell us how severe this particular failure is? In other words, how much is this telling you about libreoffice? I think the failure is "just" that you can't compile a test that used to be able to compile. And you suspect that the libreoffice test may not be the only code that breaks. Matthias, did you have time to look into the issue? Have you discovered anything that is worth knowing already? If not, do you intent to work on this soon. I noticed you uploaded a new version that doesn't address this RC bug, for the reason I mentioned above, could you please refrain from uploading new versions unless critical issues that aren't present in testing are fixed in those uploads until a version of gcc-9 migrates? Paul signature.asc Description: OpenPGP digital signature
Re: Bug#907277: autoconf: AC_SEARCH_LIBS for __atomic_foo fails with AC_LANG([C++]) and g++-8
Hi all, On 10-03-2019 13:41, Simon McVittie wrote: > On Thu, 17 Jan 2019 at 11:00:40 -0500, Nick Bowler wrote: >> I'm not familiar with the library in question but the problem >> appears to be specific to these __atomic_xyz builtins which seem >> to get special treatment in g++. Other builtins I tested do not >> exhibit such failures. > > Retitling to reflect the scope of the bug. Does anybody know why gcc got more picky, but ONLY for __atomic_foo? If it is only __atomic_foo that is failing, can't we special case that? I.e. if testing for __atomic_foo, pass the test? Maybe only in Debian and not upstream, albeit I rather have a generic solution, but then it shouldn't be Debian pulling the boat. Or is this a ridiculous proposal? I fear that although this may have limited impact on packages in the archive, I don't know how many private builds are impacted by this. Paul signature.asc Description: OpenPGP digital signature
Re: autoconf: AC_SEARCH_LIBS with AC_LANG([C++]) broken when using gcc 8
Hi Doko, Thanks for your reply. On 14-01-2019 11:57, Matthias Klose wrote: > On 12.01.19 21:37, Chaim Zax wrote: >> Because autoconf can be used outside a Debian environment this solution >> might not work for everyone. Perhaps the AC_SEARCH_LIBS function should >> be extended so function arguments needed to check a library could be >> provided as well, or perhaps there is an other way to make it compatible >> with g++ 8. > > g++ 8 got more strict. You could check if that's the case for g++ 9 as well > (or > gcc-snapshot). In any case, autoconf should be adjusted to avoid the > warning/error. Do you happen to know why g++ 8 happens to fail on this library and doesn't fail on other libraries we checked? Does g++ know which libraries it includes and is it pickier on those? Paul signature.asc Description: OpenPGP digital signature
Bug#751532: Bug#750811: brltty: FTBFS on kfreebsd*
On 15-06-14 17:31, Samuel Thibault wrote: This is most probably similar to #714559 which had the same issue. Yes, I agree. But interestingly enough, building liblouisutdml already failed in gcc-4.8 while brltty (and libbluray) only now start to fail with gcc-4.9, so something must have changed. Shouldn't the package for kfreebsd* have the files in a different sub-directory? linux just feels wrong on kfreebsd. I expect (but don't know for sure) that the resolver is smart enough to look in a sub-directory matching the os, but as I would expect not look in the directory named by a different os. Paul signature.asc Description: OpenPGP digital signature
