Bug#980723: [Pkg-rust-maintainers] Bug#980723: autopkgtests aren't being run for rust-sequoia-sqv or rust-sequoia-keyring-linter or rust-sequoia-sop
On Wed, Jan 20, 2021 at 08:14:45PM -0500, Daniel Kahn Gillmor wrote: > Package: rust-sequoia-sqv > Version: 1.0.0-1 > > Looks like the autopkgtests are not being run for rust-sequoia-sqv (or > for sq-keyring-linter or sqop). I think this is because some rust > packages needed specifically for testing are not available in the > archive. > > We should add them to the archive so that the autopkgtest suites get > run. (they do not appear to be run during the build) That starts with identifing those missing packages. Regards Geert Stappers Moral support on this issue. -- Silence is hard to parse
Bug#980658: pygame-sdl2: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
On 20/01/21 at 23:05 +, Simon McVittie wrote: > On Wed, 20 Jan 2021 at 22:01:14 +0100, Lucas Nussbaum wrote: > > > dpkg-source -b . > > Are you deliberately rebuilding the source package? That seems unusual > for testing whether packages FTBFS... Yes, it's not that much additional effort and catches some problems such as the one below from time to time. Lucas
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
On Thu, Jan 21, 2021 at 12:50 PM Sébastien Delafond wrote: > I'm not expecting upstream to fix it either, but it'd feel more > comfortable to close this bug on our side while still linking to an > existing upstream issue. Of course. Here it is: https://github.com/samwoods1/in-parallel/issues/8 Feel free to add more if I missed something. > Ideally we'd only skip this test in 2.x, while keeping it in 3.0 to see > if same race eventually pops up on debci. Yeah, but I'd rather keep it disabled now and then re-work it when working on the interpreter transition. That said, I am preparing an upload for this as we speak! :) Best, Utkarsh
Bug#980735: dput-ng: Please add ftps (RFC 4217, not sftp) support
Package: dput-ng Version: 1.31 Severity: wishlist Tags: patch Dear Maintainer(s), this adds a new method "ftps" following RFC 4217 with ftplib.FTP_TLS (py standard library). Patch is in this salsa merge request: https://salsa.debian.org/debian/dput-ng/-/merge_requests/14 Thanks for considering! Stephan -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages dput-ng depends on: ii python3 3.9.1-1 ii python3-dput 1.31 dput-ng recommends no packages. Versions of packages dput-ng suggests: pn dput-ng-doc pn python3-twitter -- no debconf information
Bug#972134: chromium: please, consider moving the package to team-maintenance to properly maintain it
Hi, In that case what does it take to become a maintainer for this package? Are there any docs on how the build process works? Regards,Patrick On Wed, 20 Jan 2021 18:00:45 +0100 Salvatore Bonaccorso < car...@debian.org> wrote:> Hi,> > On Mon, Jan 11, 2021 at 05:23:50PM +0100, Michel Le Bihan wrote:> [...]> > The window for getting in Bullseye will close soon and this issue is> > blocking. Will you be able to maintain Chromium in Bullseye? I can help> > with it if needed.> > Thanks for you both which were involved in the last two rounds of> updates for chromium.> > To make it supportable in bullseye the problem is still that due to> the hight flux of issues which appear in chromium, one person (with> uploading permissions) commiting either as part of the team or> commiting to regularly sponsor uploads, would not be enought. As said> there is a high and frequent flux of issues appering, that means if we> only have one such person, and the person temporarily have to step> from chromium maintenance we run in the same situation as we right now> had for buster.> > For redundancy there should be at least a second person available up> for doing so. The task is quite time consuming and so cannot fall back> at some point due to need to the security team members.> > it can be for instance Mike Gilbert (as member of the team) and Mattia> (not part of it, but commiting to sponsoring) to make this sort of> commitment.> > Continuing including chromium in bullseye might be the most desirable> option indeed, but running in the situation where in the stable> release is sitting a old version, would be worse than not having it> and users for instance just installing it from flathub.> > Hope this clarifies enough the security team perspective.> > Regards,> Salvatore
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
On 21/01 12:46, Utkarsh Gupta wrote: > I can create an issue in the original fork. However, just know that > this library is *not* being maintained at all. So there won't be much > help from anywhere. I'm not expecting upstream to fix it either, but it'd feel more comfortable to close this bug on our side while still linking to an existing upstream issue. > Either way, I'd also like to mention that we did a build for > ruby-in-parallel against ruby3.0 and everything seems to work, > including those tests as well. Ideally we'd only skip this test in 2.x, while keeping it in 3.0 to see if same race eventually pops up on debci. Cheers, -- Seb
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
Hi Sébastien, On Thu, Jan 21, 2021 at 12:42 PM Sébastien Delafond wrote: > > Aah, okay. So I ran sbuild + autopkgtest 10 times, all passed for me. > > But when I ran these tests locally with rake, it failed for me exactly > > like the report just for the first time. And then passed all 9 times > > afterward. > > I haven't been able to reproduce it here: local rake, autopkgtest+lxc, > autopkgtest+qemu. Aah. > > Then I tried to trace back the origin of this problem but couldn't > > find anything. I am not sure what's causing this (I haven't gone > > through the source thoroughly) but I am inclined towards skipping this > > test if that's OK with you? > > It definitely looks like a race, so I agree we can skip it if we create > an upstream bug documenting the issue. I can create an issue in the original fork. However, just know that this library is *not* being maintained at all. So there won't be much help from anywhere. Either way, I'd also like to mention that we did a build for ruby-in-parallel against ruby3.0 and everything seems to work, including those tests as well. See logs here: https://people.debian.org/~kanashiro/ruby3.0/builds/3/ruby-in-parallel/ruby-in-parallel_0.1.17-1.1+rebuild1610557786_amd64-2021-01-13T17:09:48Z.build Best, Utkarsh
Bug#980734: arc-theme is compiled for wrong gnome-shell version
Package: arc-theme Version: 20201013-1 Severity: minor Dear Maintainer, In debian/rules, dh_auto_configure -- --with-gnome-shell=3.36 --with-cinnamon=4.6 should be changed to dh_auto_configure -- --with-gnome-shell=3.38 --with-cinnamon=4.8 to match the versions of gnome-shell and cinnamon in bullseye.
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
On 21/01 12:31, Utkarsh Gupta wrote: > Aah, okay. So I ran sbuild + autopkgtest 10 times, all passed for me. > But when I ran these tests locally with rake, it failed for me exactly > like the report just for the first time. And then passed all 9 times > afterward. I haven't been able to reproduce it here: local rake, autopkgtest+lxc, autopkgtest+qemu. > Then I tried to trace back the origin of this problem but couldn't > find anything. I am not sure what's causing this (I haven't gone > through the source thoroughly) but I am inclined towards skipping this > test if that's OK with you? It definitely looks like a race, so I agree we can skip it if we create an upstream bug documenting the issue. Cheers, -- Seb
Bug#980733: ukui-panel: Please switch Build-Depends to libsensors-dev (from libsensors4-dev)
Package: ukui-panel Version: 3.0.3-1 Severity: wishlist User: aure...@debian.org Usertags: libsensors-dev-transition Dear maintainer, ukui-panel build-depends on libsensors4-dev, the development package from lm-sensors. For historical reasons the development package is versioned. Following the transition of the library to libsensors5, it made sense to rename the development package to libsensors-dev. In that regard a libsensors4-dev is now a transitional package depending on libsensors-dev. Your package therefore still builds fine. I plan to remove this transitional package a bit after the bullseye release, so there is no urgency (yet) to do the change, especially with the freeze coming. I however prefer to warn a bit in advance. The change should just be a matter of running: sed -i -e 's/libsensors4-dev/libsensors-dev/g' debian/control Thanks, Aurelien
Bug#980732: indicator-sensors: Please switch Build-Depends to libsensors-dev (from libsensors4-dev)
Package: indicator-sensors Version: 1.2-1 Severity: wishlist User: aure...@debian.org Usertags: libsensors-dev-transition Dear maintainer, ukui-panel build-depends on libsensors4-dev, the development package from lm-sensors. For historical reasons the development package is versioned. Following the transition of the library to libsensors5, it made sense to rename the development package to libsensors-dev. In that regard a libsensors4-dev is now a transitional package depending on libsensors-dev. Your package therefore still builds fine. I plan to remove this transitional package a bit after the bullseye release, so there is no urgency (yet) to do the change, especially with the freeze coming. I however prefer to warn a bit in advance. The change should just be a matter of running: sed -i -e 's/libsensors4-dev/libsensors-dev/g' debian/control Thanks, Aurelien
Bug#980731: htop: Please switch Build-Depends to libsensors-dev (from libsensors4-dev)
Package: htop Version: 3.0.3-2 Severity: wishlist User: aure...@debian.org Usertags: libsensors-dev-transition Dear maintainer, ukui-panel build-depends on libsensors4-dev, the development package from lm-sensors. For historical reasons the development package is versioned. Following the transition of the library to libsensors5, it made sense to rename the development package to libsensors-dev. In that regard a libsensors4-dev is now a transitional package depending on libsensors-dev. Your package therefore still builds fine. I plan to remove this transitional package a bit after the bullseye release, so there is no urgency (yet) to do the change, especially with the freeze coming. I however prefer to warn a bit in advance. The change should just be a matter of running: sed -i -e 's/libsensors4-dev/libsensors-dev/g' debian/control Thanks, Aurelien
Bug#979732: ticker FTCBFS: uses the build architecture compiler
Hi, If I make the change, will you upload it for me? Thank you for reporting. -- Cheers, Leandro Cunha Debian Contributor and developer.
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
Hi Sébastien, On Thu, Jan 21, 2021 at 11:51 AM Utkarsh Gupta wrote: > I've started to look into it already but I wasn't able to reproduce > it. All tests pass for me + autopkgtest (which is what I fixed last > time). So I am not sure what's going wrong here. Aah, okay. So I ran sbuild + autopkgtest 10 times, all passed for me. But when I ran these tests locally with rake, it failed for me exactly like the report just for the first time. And then passed all 9 times afterward. Then I tried to trace back the origin of this problem but couldn't find anything. I am not sure what's causing this (I haven't gone through the source thoroughly) but I am inclined towards skipping this test if that's OK with you? It'd be best if we fix it but I am not sure if it's worth a lot of time. Let me know what you think? Best, Utkarsh
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
Hi Sébastien, On Thu, Jan 21, 2021 at 11:37 AM Sébastien Delafond wrote: > since you took care of the last upload, do you also plan to fix this > FTBFS? If not, please let me know and I'll look into it. I've started to look into it already but I wasn't able to reproduce it. All tests pass for me + autopkgtest (which is what I fixed last time). So I am not sure what's going wrong here. If you have some time and can take a look as well, that'd be really helpful. If you find something, let me know. - u
Bug#980729: linux-source-5.9: 5.9.15 crashes regularly with memory/paging related messages
Package: linux-source-5.9 Version: 5.9.15-1~bpo10+1 Severity: important Tags: upstream Dear Maintainer, 5.9.15 crashes regularly with memory/paging related messages, like this: = Jan 15 17:25:09 host kernel: [125426.427889] BUG: unable to handle page fault for address: 2500 Jan 15 17:25:09 host kernel: [125426.427892] #PF: supervisor read access in kernel mode Jan 15 17:25:09 host kernel: [125426.427893] #PF: error_code(0x) - not-present page Jan 15 17:25:09 host kernel: [125426.427893] PGD 0 P4D 0 Jan 15 17:25:09 host kernel: [125426.427895] Oops: [#1] PREEMPT SMP PTI Jan 15 17:25:09 host kernel: [125426.427897] CPU: 7 PID: 29085 Comm: plasmashell Tainted: P OE 5.9.15-bootes0-p-1000 #1 Jan 15 17:25:09 host kernel: [125426.427898] Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD5H/Z87X-UD5H-CF, BIOS F9 03/18/2014 Jan 15 17:25:09 host kernel: [125426.427900] RIP: 0010:lock_page_memcg+0x2d/0x90 Jan 15 17:25:09 host kernel: [125426.427902] Code: 00 00 41 54 55 48 89 fd 53 48 8b 47 08 48 8d 50 ff a8 01 48 0f 45 ea e8 61 36 e7 ff 0f 1f 44 00 00 48 8b 5d 38 48 85 db 74 33 <8b> 83 00 05 00 00 85 c0 7e 2b 4c 8d a3 d8 04 00 00 4c 89 e7 e8 ca Jan 15 17:25:09 host kernel: [125426.427903] RSP: 0018:aaa212fffb40 EFLAGS: 00010206 Jan 15 17:25:09 host kernel: [125426.427904] RAX: 88a59cfa8f40 RBX: 2000 RCX: Jan 15 17:25:09 host kernel: [125426.427904] RDX: dead00ff RSI: RDI: e43c5defac80 Jan 15 17:25:09 host kernel: [125426.427905] RBP: e43c5defac80 R08: 88a5e48c9af0 R09: 7fd26efff000 Jan 15 17:25:09 host kernel: [125426.427906] R10: 000ff000 R11: R12: aaa212fffcb0 Jan 15 17:25:09 host kernel: [125426.427906] R13: 7fd26ee2e000 R14: 7fd26ee2d000 R15: 80077beb200f Jan 15 17:25:09 host kernel: [125426.427907] FS: () GS:88a61edc() knlGS: Jan 15 17:25:09 host kernel: [125426.427908] CS: 0010 DS: ES: CR0: 80050033 Jan 15 17:25:09 host kernel: [125426.427909] CR2: 2500 CR3: 000474682003 CR4: 001706e0 Jan 15 17:25:09 host kernel: [125426.427910] Call Trace: Jan 15 17:25:09 host kernel: [125426.427913] page_remove_rmap+0x15/0x460 Jan 15 17:25:09 host kernel: [125426.427915] unmap_page_range+0x53e/0xb10 Jan 15 17:25:09 host kernel: [125426.427918] unmap_vmas+0xbc/0xe0 Jan 15 17:25:09 host kernel: [125426.427920] exit_mmap+0xaa/0x180 Jan 15 17:25:09 host kernel: [125426.427922] mmput+0x4c/0x120 Jan 15 17:25:09 host kernel: [125426.427925] begin_new_exec+0x378/0x9f0 Jan 15 17:25:09 host kernel: [125426.427927] load_elf_binary+0x6b8/0x1500 Jan 15 17:25:09 host kernel: [125426.427930] ? tomoyo_find_next_domain+0x2d4/0x810 Jan 15 17:25:09 host kernel: [125426.427934] ? _raw_read_lock+0x13/0x30 Jan 15 17:25:09 host kernel: [125426.427936] bprm_execve+0x2a2/0x680 Jan 15 17:25:09 host kernel: [125426.427937] do_execveat_common.isra.42+0x1a1/0x1c0 Jan 15 17:25:09 host kernel: [125426.427939] __x64_sys_execve+0x32/0x40 Jan 15 17:25:09 host kernel: [125426.427941] do_syscall_64+0x33/0x80 Jan 15 17:25:09 host kernel: [125426.427943] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jan 15 17:25:09 host kernel: [125426.427944] RIP: 0033:0x7fd29ae95a07 Jan 15 17:25:09 host kernel: [125426.427947] Code: Unable to access opcode bytes at RIP 0x7fd29ae959dd. Jan 15 17:25:09 host kernel: [125426.427947] RSP: 002b:7fff75467538 EFLAGS: 0202 ORIG_RAX: 003b Jan 15 17:25:09 host kernel: [125426.427948] RAX: ffda RBX: 7fd296038780 RCX: 7fd29ae95a07 Jan 15 17:25:09 host kernel: [125426.427949] RDX: 563769fbf820 RSI: 56376fb30e40 RDI: 56376fe99190 Jan 15 17:25:09 host kernel: [125426.427950] RBP: 56376feaa3b0 R08: 7fff75467490 R09: 7fff754671c6 Jan 15 17:25:09 host kernel: [125426.427950] R10: f199 R11: 0202 R12: 56376fb30e40 Jan 15 17:25:09 host kernel: [125426.427951] R13: 56376fe99190 R14: 56376f8059a0 R15: Jan 15 17:25:09 host kernel: [125426.427952] Modules linked in: serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device cpufreq_powersave cpufreq_userspace cpufreq_conservative bnep bluetooth jitterentropy_rng drbg ansi_cprng ecdh_generic rfkill ecc binfmt_misc nft_counter xt_geoip(OE) nft_compat x_tables nf_tables nfnetlink nfsd auth_rpcgss nfs_acl nfs lockd grace nfs_ssc fscache sunrpc nls_ascii nls_cp437 vfat fat dm_cache_smq dm_cache dm_persistent_data dm_bio_prison dm_bufio raid1 dm_raid raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq md_mod libcrc32c drivetemp it87 hwmon_vid ddcci(OE) snd_aloop loop cpuid nls_utf8 cuse fuse nvidia_drm(POE) drm_kms_helper cec drm nvidia_modeset(POE) i2c_dev essiv authenc dm_crypt saa7134_alsa rc_pinnacle
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
Hi Utkarsh, since you took care of the last upload, do you also plan to fix this FTBFS? If not, please let me know and I'll look into it. Cheers, -- Seb
Bug#980727: RFS: grap/1.46-1 [QA] -- program for typesetting graphs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "grap": * Package name: grap Version : 1.46-1 Upstream Author : Ted Faber * URL : https://www.lunabase.org/~faber/Vault/software/grap/ * License : BSD-like * Vcs : [fill in URL of packaging vcs] Section : text It builds those binary packages: grap - program for typesetting graphs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/grap/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/grap/grap_1.46-1.dsc Changes since the last upload: grap (1.46-1) unstable; urgency=medium . * QA upload. * New upstream release. * Added debian/gbp.conf. * Added debian/upstream/metadata. * Added debian/docs. * debian/copyright: - Added Upstream-Contact optional field according DEP-5. Regards, -- Leandro Cunha
Bug#980595: libcheck made a breaking change
Hi, On Wed, Jan 20, 2021 at 10:23:30PM +, Thomas Habets wrote: > libcheck made a breaking change. > Patch for arping to make it build: > https://github.com/ThomasHabets/arping/commit/e0773bc26ae14d4a19825023307d1496d7c7d0f1 > > I aim to release 2.22 tomorrow with this change. > But there are no changes between 2.21 and 2.22, so you can just patch in > the commit, if you prefer. Thanks! > I see the tag is set to "serious". To be clear this is a failure of the > TEST to compile only. I agree that this should be seen as serious, but it's > just the test. I do agree, in context of Debian policy though serious is warranted as it makes the package fail to build. But yes, if there would not have a quick solution, and known that it is only the test which is broken, then we could not run the testsuite as workaround and fixing the issue. In any case, thanks for your fast bugfix, amazing :) Regards, Salvatore
Bug#980509: umap-learn: Binary package name should be python3-umap-learn
Hi Diane, On Wed, Jan 20, 2021 at 04:12:13PM -0800, Diane Trout wrote: > > While waiting for numba test cases on the super slow armhf architecture > to run I got the pynndescent autopkgtests to run (by replacing the > contents of run-unit-tests) and pushed them to the main packaging > repository. > > Would you like me to build the package and upload it to NEW? That's great. However, I've just uploaded yesterday (without autopkgtest)[1] and forgot to push my changes. I'll merge you change in and we can do so in a source-only upload. Please let me know if you want to be an additional Uploader for this package (which would be great). Kind regards Andreas. [1] https://ftp-master.debian.org/new/python-pynndescent_0.5.1-1.html -- http://fam-tille.de
Bug#980205: #980205 installation missing "non free" drivers.
Control: reassign -1 firmware-nonfree Control: retitle -1 firmware: missing txt file for brcm/brcmfmac43340-sdio.bin Dave Dyer wrote: > At 05:40 AM 1/18/2021, Holger Wansing wrote: > >> 3) in my particular case, the driver is brcm/brcmfmac43340-sdio.bin, which > >> *also* requires a text file, brcm/brcmfmac43340-sdio.txt. I know this > >> because > >> I figured out case 2B and got the installer to accept the .bin; it then > >> it mentions the need for the .txt file. (Again, thanks, it would have > >> been impossible to proceed without this key information). However, > >> there's apparently no way to get the installer to accept the .txt > >> file in the same way that it finds the .bin. > > > >Hmm, looking into the package firmware-brcm80211 > >(https://packages.debian.org/buster/firmware-brcm80211) > >there is no such txt file there. > >So I wonder where you found such file? > > Github + Google. And the file I found works. So this txt file will need to be added to firmware-brcm80211 package, too? Re-assigning there. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#980726: (no subject)
Seems all it needs is: sudo systemctl enable gpm Does that need to be added to the packaging?
Bug#980726: gpm.service does not automatically start
Package: gpm Version: 1.20.7-7 The gpm service does not automatically start on boot. $ systemctl status gpm ● gpm.service - Console Mouse manager Loaded: loaded (/lib/systemd/system/gpm.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:gpm(8) man:gpm.conf(5) man:gpm-types(7) I also don't get any crash reports. But starting it manually works every time: $ sudo systemctl start gpm https://bugs.launchpad.net/bugs/1912575
Bug#957055: bristol: ftbfs with GCC-10
Control: tags -1 patch Hi, In Ubuntu, the attached patch was applied to achieve the following: * d/p/04-gcc_10.patch: Fix FTBFS with GCC 10 by adjusting some variables. Thanks for considering the patch. Logan diff -Nru bristol-0.60.11/debian/patches/04-gcc_10.patch bristol-0.60.11/debian/patches/04-gcc_10.patch --- bristol-0.60.11/debian/patches/04-gcc_10.patch 1969-12-31 19:00:00.0 -0500 +++ bristol-0.60.11/debian/patches/04-gcc_10.patch 2021-01-20 22:48:15.0 -0500 @@ -0,0 +1,243 @@ +--- a/brighton/brightonCLI.c b/brighton/brightonCLI.c +@@ -136,7 +136,6 @@ + //if (RESOURCES->resources[btty.p].devlocn[btty.i].to == 1.0f) + //if (DEVICE(btty.i).to == 1.0f) + +-brightonEvent event; + extern void printBrightonHelp(int); + + typedef int (*clicom)(); +--- a/brighton/brightonMixerMenu.c b/brighton/brightonMixerMenu.c +@@ -1179,11 +1179,10 @@ + return(NULL); + } + +-brightonEvent event; +- + int + doAlarm() + { ++ brightonEvent event; + event.type = BRIGHTON_FLOAT; + event.value = 0.0; + +--- a/include/bristol/bristolblo.h b/include/bristol/bristolblo.h +@@ -39,7 +39,7 @@ + #define BLO_COSINE6 + #define BLO_PULSE 7 + +-struct { ++struct blo { + int flags; + int harmonics; + int cutin; +@@ -47,7 +47,8 @@ + int min; + float fraction; + float samplerate; +-} blo; ++}; ++extern struct blo blo; + + extern float blosine[BRISTOL_BLO_SIZE]; + extern float blosquare[BRISTOL_BLO_SIZE]; +--- a/bristol/blo.c b/bristol/blo.c +@@ -33,6 +33,8 @@ + + static int init = 1; + ++struct blo blo; ++ + float blosine[BRISTOL_BLO_SIZE]; + float blocosine[BRISTOL_BLO_SIZE]; + float blosquare[BRISTOL_BLO_SIZE]; +--- a/bristol/arpdco.c b/bristol/arpdco.c +@@ -39,7 +39,8 @@ + #include "bristolblo.h" + #include "arpdco.h" + +-float note_diff, *zbuf; ++static float note_diff; ++float *zbuf; + + #define BRISTOL_SQR 4 + +--- a/bristol/cs80osc.c b/bristol/cs80osc.c +@@ -41,8 +41,8 @@ + #include "cs80osc.h" + #include "bristolcs80.h" + +-float note_diff; +-int samplecount; ++static float note_diff; ++static int samplecount; + + static void fillWave(float *, int, int); + static void buildCs80Sound(bristolOP *, bristolOPParams *); +--- a/bristol/dco.c b/bristol/dco.c +@@ -39,7 +39,7 @@ + #include "bristolblo.h" + #include "dco.h" + +-float note_diff; ++static float note_diff; + + /* + * The name of this operator, IO count, and IO names. +--- a/bristol/expdco.c b/bristol/expdco.c +@@ -40,7 +40,7 @@ + #include "bristolblo.h" + #include "expdco.h" + +-float note_diff; ++static float note_diff; + + /* + * The name of this operator, IO count, and IO names. +--- a/bristol/filter2.c b/bristol/filter2.c +@@ -147,7 +147,6 @@ + } + + #define ROOT2 1.4142135623730950488 +-double pidsr; + + /* + * Reset any local memory information. +--- a/bristol/granulardco.c b/bristol/granulardco.c +@@ -38,8 +38,8 @@ + #include "bristol.h" + #include "granulardco.h" + +-float note_diff; +-float samplerate; ++static float note_diff; ++static float samplerate; + + #define BRISTOL_SQR 4 + +--- a/bristol/hammond.c b/bristol/hammond.c +@@ -45,8 +45,8 @@ + #include "bristol.h" + #include "hammond.h" + +-float note_diff; +-int samplecount; ++static float note_diff; ++static int samplecount; + + static void fillWave(float *, int, int); + static void buildHammondSound(bristolOP *, unsigned char); +@@ -70,8 +70,8 @@ + static int *waveindex; + static int *percussion; + +-float *wave1; +-float *wave2; ++static float *wave1; ++static float *wave2; + + /* + * This can be a single list, it is used to generate the different pipes. +--- a/bristol/junodco.c b/bristol/junodco.c +@@ -39,7 +39,7 @@ + #include "bristolblo.h" + #include "junodco.h" + +-float note_diff; ++static float note_diff; + + #define BRISTOL_SQR 8 + +--- a/bristol/lfo.c b/bristol/lfo.c +@@ -38,7 +38,7 @@ + #include "bristol.h" + #include "lfo.h" + +-float note_diff; ++static float note_diff; + + /* + * The name of this operator, IO count, and IO names. +--- a/bristol/midihandlers.c b/bristol/midihandlers.c +@@ -633,7 +633,7 @@ + *previous frequency * (2^^(1/12)) + * Since A is constand whole numbers we can calcuate each octave from A. + */ +-float samplerate; ++static float samplerate; + + int + initFrequencyTable(float rate) +--- a/bristol/prophetdco.c b/bristol/prophetdco.c +@@ -47,7 +47,7 @@ + #include "bristolblo.h" + #include "prophetdco.h" + +-float note_diff; ++static float note_diff; + + #define BRISTOL_SQR 4 + +--- a/bristol/sdco.c b/bristol/sdco.c +@@ -41,7 +41,7 @@ + #include "bristol.h" + #include "sdco.h" + +-float note_diff; ++static float note_diff; + + /* + * The name of this operator, IO count, and IO names. +--- a/bristol/trilogyosc.c b/bristol/trilogyosc.c +@@ -40,8 +40,8 @@ + #include "bristolblo.h" + #include "trilogyosc.h" + +-float note_diff; +-int samplecoun
Bug#980601: [Debian-on-mobile-maintainers] Bug#980601: Bug#980601: chatty: FTBFS: phonenumber.pb.h:47:51: error: ‘AuxiliaryParseTableField’ in namespace ‘google::protobuf::internal’ does not name a ty
On 1/21/21 4:00 AM, Evangelos Ribeiro Tzaras wrote: Hi, On 1/20/21 9:25 PM, Lucas Nussbaum wrote: Source: chatty Version: 0.2.0-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. thanks for your report! Relevant part (hopefully): c++ -Isrc/libchatty.so.p -Isrc -I../src -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpurple -I/usr/include/libhandy-1 -I/usr/include/evolution-data-server -I/usr/include/nss -I/usr/include/nspr -I/usr/include/libsecret-1 -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/gsettings-desktop-schemas -I/usr/include/libfeedback-0.0 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ src/libchatty.so.p/chatty-phone-utils.cpp.o -MF src/libchatty.so.p/chatty-phone-utils.cpp.o.d -o src/libchatty.so.p/chatty-phone-utils.cpp.o -c ../src/chatty-phone-utils.cpp In file included from /usr/include/phonenumbers/phonenumberutil.h:34, from ../src/chatty-phone-utils.cpp:18: /usr/include/phonenumbers/phonenumber.pb.h:47:51: error: ‘AuxiliaryParseTableField’ in namespace ‘google::protobuf::internal’ does not name a type; did you mean ‘AuxillaryParseTableField’? 47 | static const ::PROTOBUF_NAMESPACE_ID::internal::AuxiliaryParseTableField aux[] | ^~~~ | AuxillaryParseTableField In file included from /usr/include/phonenumbers/phonenumberutil.h:34, from ../src/chatty-phone-utils.cpp:18: /usr/include/phonenumbers/phonenumber.pb.h:88:30: error: ‘ConstStringParam’ is not a member of ‘google::protobuf’ 88 | ::PROTOBUF_NAMESPACE_ID::ConstStringParam name, PhoneNumber_CountryCodeSource* value); | ^~~~ /usr/include/phonenumbers/phonenumber.pb.h:88:82: error: expected primary-expression before ‘*’ token 88 | ::PROTOBUF_NAMESPACE_ID::ConstStringParam name, PhoneNumber_CountryCodeSource* value); | ^ /usr/include/phonenumbers/phonenumber.pb.h:88:84: error: ‘value’ was not declared in this scope 88 | ::PROTOBUF_NAMESPACE_ID::ConstStringParam name, PhoneNumber_CountryCodeSource* value); | ^ /usr/include/phonenumbers/phonenumber.pb.h:88:89: error: expression list treated as compound expression in initializer [-fpermissive] 88 | ::PROTOBUF_NAMESPACE_ID::ConstStringParam name, PhoneNumber_CountryCodeSource* value); | ^ /usr/include/phonenumbers/phonenumber.pb.h:218:71: error: ‘google::protobuf::ConstStringParam’ has not been declared 218 | static inline bool CountryCodeSource_Parse(::PROTOBUF_NAMESPACE_ID::ConstStringParam name, | ^~~~ /usr/include/phonenumbers/phonenumber.pb.h: In static member function ‘static bool i18n::phonenumbers::PhoneNumber::CountryCodeSource_Parse(int, i18n::phonenumbers::PhoneNumber::CountryCodeSource*)’: /usr/include/phonenumbers/phonenumber.pb.h:220:59: error: ‘i18n::phonenumbers::PhoneNumber_CountryCodeSource_Parse’ cannot be used as a function 220 | return PhoneNumber_CountryCodeSource_Parse(name, value); | ^ [36/65] cc -Isrc/chatty.p -Isrc -I../src -I../src/xeps/prpl/jabber -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-
Bug#973323: Boot failure triggered by USB on rockpro64-rk3399 and pinebook-pro-rk3399
Hi Vagrant, Do you know which version is the last version that works in this case? The firmware is from eMMC and it's wired for USB to affect the boot process. Thanks, - Kever On 2021/1/21 上午8:08, Vagrant Cascadian wrote: It seems rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot when usb is started. It hangs indefinitely at: ## Flattened Device Tree blob at 01f0 Booting using the fdt blob at 0x1f0 I have observed this also using 2020.10 on rockpro64-rk3399, though on pinebook-pro-rk3399 usb does not work and so it basically avoids triggering the issue. Setting CONFIG_USE_PREBOOT=n in the config works around the problem, though obviously by breaking usb keyboard support or booting from USB devices. Related bugs in Debian and manjaro: https://bugs.debian.org/973323 https://bugs.debian.org/980434 https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-rockpro64/-/issues/4 Boot log: U-Boot 2021.01+dfsg-1 (Jan 17 2021 - 03:50:13 +) SoC: Rockchip rk3399 Reset cause: POR Model: Pine64 RockPro64 v2.1 DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0 Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Model: Pine64 RockPro64 v2.1 Net: eth0: ethernet@fe30 starting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe3e: USB OHCI 1.0 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3a for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe3e for devices... 1 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 => printenv preboot preboot=usb start => usb reset resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe3e: USB OHCI 1.0 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3a for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe3e for devices... 1 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => boot Card did not respond to voltage select! : -110 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 144 bytes read in 5 ms (27.3 KiB/s) 1: Debian-Installer Retrieving file: /initrd.gz 28995285 bytes read in 1287 ms (21.5 MiB/s) Retrieving file: /vmlinuz 26922864 bytes read in 1195 ms (21.5 MiB/s) Retrieving file: /dtbs/rockchip/rk3399-rockpro64.dtb 56849 bytes read in 13 ms (4.2 MiB/s) Moving Image from 0x208 to 0x220, end=3c5 ## Flattened Device Tree blob at 01f0 Booting using the fdt blob at 0x1f0 live well, vagrant
Bug#957070: cde: ftbfs with GCC-10
Control: tags -1 patch Hi, In Ubuntu, the attached patch was applied to achieve the following: * d/p/gcc_10: Mark variables as extern to fix FTBFS with GCC 10. Thanks for considering the patch. Logan diff -Nru cde-0.1+git9-g551e54d/debian/patches/gcc_10 cde-0.1+git9-g551e54d/debian/patches/gcc_10 --- cde-0.1+git9-g551e54d/debian/patches/gcc_10 1969-12-31 19:00:00.0 -0500 +++ cde-0.1+git9-g551e54d/debian/patches/gcc_10 2021-01-20 22:27:38.0 -0500 @@ -0,0 +1,24 @@ +--- a/strace-4.6/defs.h b/strace-4.6/defs.h +@@ -34,8 +34,8 @@ + #define CDE_OPTIONS_VERSION_NUM "# cde.options v1" + #define CDE_ROOT_NAME "cde-root" + // pgbovine - these are both ABSOLUTE paths +-char* CDE_PACKAGE_DIR; +-char* CDE_ROOT_DIR; ++extern char* CDE_PACKAGE_DIR; ++extern char* CDE_ROOT_DIR; + + + #ifdef HAVE_CONFIG_H +--- a/readelf-mini/dwarf.c b/readelf-mini/dwarf.c +@@ -61,7 +61,7 @@ + int do_debug_macinfo; + int do_debug_str; + int do_debug_loc; +-int do_wide; ++extern int do_wide; + + /* Values for do_debug_lines. */ + #define FLAG_DEBUG_LINES_RAW 1 diff -Nru cde-0.1+git9-g551e54d/debian/patches/series cde-0.1+git9-g551e54d/debian/patches/series --- cde-0.1+git9-g551e54d/debian/patches/series 2013-11-17 20:49:30.0 -0500 +++ cde-0.1+git9-g551e54d/debian/patches/series 2021-01-20 22:27:16.0 -0500 @@ -1,2 +1,3 @@ up_ignore-noMakefile_on_clean deb_install_usr +gcc_10
Bug#980601: [Debian-on-mobile-maintainers] Bug#980601: chatty: FTBFS: phonenumber.pb.h:47:51: error: ‘AuxiliaryParseTableField’ in namespace ‘google::protobuf::internal’ does not name a type; did you
Hi, On 1/20/21 9:25 PM, Lucas Nussbaum wrote: Source: chatty Version: 0.2.0-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. thanks for your report! Relevant part (hopefully): c++ -Isrc/libchatty.so.p -Isrc -I../src -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpurple -I/usr/include/libhandy-1 -I/usr/include/evolution-data-server -I/usr/include/nss -I/usr/include/nspr -I/usr/include/libsecret-1 -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/gsettings-desktop-schemas -I/usr/include/libfeedback-0.0 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ src/libchatty.so.p/chatty-phone-utils.cpp.o -MF src/libchatty.so.p/chatty-phone-utils.cpp.o.d -o src/libchatty.so.p/chatty-phone-utils.cpp.o -c ../src/chatty-phone-utils.cpp In file included from /usr/include/phonenumbers/phonenumberutil.h:34, from ../src/chatty-phone-utils.cpp:18: /usr/include/phonenumbers/phonenumber.pb.h:47:51: error: ‘AuxiliaryParseTableField’ in namespace ‘google::protobuf::internal’ does not name a type; did you mean ‘AuxillaryParseTableField’? 47 | static const ::PROTOBUF_NAMESPACE_ID::internal::AuxiliaryParseTableField aux[] | ^~~~ | AuxillaryParseTableField In file included from /usr/include/phonenumbers/phonenumberutil.h:34, from ../src/chatty-phone-utils.cpp:18: /usr/include/phonenumbers/phonenumber.pb.h:88:30: error: ‘ConstStringParam’ is not a member of ‘google::protobuf’ 88 | ::PROTOBUF_NAMESPACE_ID::ConstStringParam name, PhoneNumber_CountryCodeSource* value); | ^~~~ /usr/include/phonenumbers/phonenumber.pb.h:88:82: error: expected primary-expression before ‘*’ token 88 | ::PROTOBUF_NAMESPACE_ID::ConstStringParam name, PhoneNumber_CountryCodeSource* value); | ^ /usr/include/phonenumbers/phonenumber.pb.h:88:84: error: ‘value’ was not declared in this scope 88 | ::PROTOBUF_NAMESPACE_ID::ConstStringParam name, PhoneNumber_CountryCodeSource* value); | ^ /usr/include/phonenumbers/phonenumber.pb.h:88:89: error: expression list treated as compound expression in initializer [-fpermissive] 88 | ::PROTOBUF_NAMESPACE_ID::ConstStringParam name, PhoneNumber_CountryCodeSource* value); | ^ /usr/include/phonenumbers/phonenumber.pb.h:218:71: error: ‘google::protobuf::ConstStringParam’ has not been declared 218 | static inline bool CountryCodeSource_Parse(::PROTOBUF_NAMESPACE_ID::ConstStringParam name, | ^~~~ /usr/include/phonenumbers/phonenumber.pb.h: In static member function ‘static bool i18n::phonenumbers::PhoneNumber::CountryCodeSource_Parse(int, i18n::phonenumbers::PhoneNumber::CountryCodeSource*)’: /usr/include/phonenumbers/phonenumber.pb.h:220:59: error: ‘i18n::phonenumbers::PhoneNumber_CountryCodeSource_Parse’ cannot be used as a function 220 | return PhoneNumber_CountryCodeSource_Parse(name, value); | ^ [36/65] cc -Isrc/chatty.p -Isrc -I../src -I../src/xeps/prpl/jabber -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpurple -I/usr/include/libhandy-1 -I/usr/i
Bug#731282: 731282 DIYLC
This can be closed completely as there is now a Flatpak for this software. Chris
Bug#980508: ntpsec: apparmor="DENIED" while trying to read /etc/ssl/openssl.cnf
On 1/19/21 6:09 PM, Diederik de Haas wrote: # journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"' jan 20 00:45:32 kernel: audit: type=1400 audit(1611099932.689:41): apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/etc/ssl/openssl.cnf" pid=43157 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Thanks for your report! I've uploaded a new version which includes the openssl abstraction and thus fixes this. -- Richard
Bug#731282: 731282 DIYLC
On Wed, Jan 20, 2021 at 11:03 PM Chris wrote: > This can be closed completely as there is now a Flatpak for this software. Please see the documentation about how to close Debian bugs: https://www.debian.org/Bugs/Developer#closing PS: Flatpak is quite different and IMO not a substitute for a proper Debian package. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#980554: lutris: Crash on first when opening ~/.local/share/lutris/runtime/dxvk/dxvk_versions.json
I have a suspicion, which is that this is due to the Lutris Runtime missing. Did you have an internet connection when you launched it the first time? I'll try it on a live image tomorrow as well. Regards Stephan
Bug#980725: python3-pylev: off-putting package description
Package: python3-pylev Severity: minor python3-pylev has an off-putting package description, please remove the phrase "that's not freaking GPL'd" from the long description. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#979187: 979187 is fixed-upstream
Control: tags -1 + fixed-upstream Self-compiled 5.10.9 does not show this reported symptom, and I assume this is fixed-upstream. Ryutaroh
Bug#980651: quaternion: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATE
On Wed, 20 Jan 2021 21:48:37 +0100, Lucas Nussbaum said: > During a rebuild of all packages in sid, your package failed to build > on amd64. This was due to the new libquotient package erroneously creating a libqmatrixclient-dev binary package. The latest libquotient package does not do this, but the bad binary package still remains. But I will be uploading a new version of quaternion soon, which will use libquotient instead of libqmatrixclient, so this will be fixed then. -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Bug#980724: memlockd: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Package: memlockd Version: 1.2.1 Severity: normal Usertags: warnings I get an update-rc.d warning when upgrading memlockd: ... Preparing to unpack .../memlockd_1.2.1_amd64.deb ... Unpacking memlockd (1.2.1) over (1.2+b1) ... Setting up memlockd (1.2.1) ... update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults Processing triggers for man-db (2.9.3-2) ... ... -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages memlockd depends on: ii adduser 3.118 ii libc62.31-9 memlockd recommends no packages. memlockd suggests no packages. -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#977645: 977642 is fixed in 5.10.5-1
Control: fixed -1 5.10.5-1 I verified that linux-image-arm64 5.10.5-1 at least boots on my raspi 4B 8GB model. On the other hand, vc4.ko gives completely garbled screen to my 4K HDMI display, and disable_fw_kms_setup=1 does not help unlike https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977642 Giving module_blacklist=vc4 to the kernel command line helps. On the other hand, vc4.ko in the upstream 5.10.9 with disable_fw_kms_setup=1 works well, and I expect it will get better with no extra packaging effort. Best regards, Ryutaroh Matsumoto
Bug#919348: many new releases since -- still "too buggy"?
Hi! Since your last report of a crash, there's been six new releases: five in the 0.1.* version series, and now one 4.16.0-1. As the new version claims a stable release, is there still a reason to keep xfce4-screensaver out of Bullseye? I've been using it happily all the time, with no borkage to report. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#980513: libgnutls30: _gnutls_sort_clist Assertion with openconnect GlobalProtect VPN
I've never used gnutls-cli before, and I'm not at all sure what openconnect is doing internally to match that behaviour, but it appears that I can reproduce w/ -cli $ gnutls-cli "" Processed 126 CA certificate(s). Resolving ':443'... Connecting to ':443'... - Certificate type: X.509 - Got a certificate list of 7 certificates. - Certificate[0] info: - subject `CN=,OU=,O=,street=,L=,ST=,postalCode=,C=US', issuer `CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US', serial , RSA key 2048 bits, signed using RSA-SHA256, activated `2020-08-07 00:00:00 UTC', expires `2021-08-07 23:59:59 UTC', pin-sha256="=" Public Key ID: Public Key PIN: - Certificate[1] info: - subject `CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US', issuer `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', serial , RSA key 2048 bits, signed using RSA-SHA384, activated `2014-10-06 00:00:00 UTC', expires `2024-10-05 23:59:59 UTC', pin-sha256="=" - Certificate[2] info: - subject `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', issuer `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial , RSA key 4096 bits, signed using RSA-SHA384, activated `2019-03-12 00:00:00 UTC', expires `2028-12-31 23:59:59 UTC', pin-sha256="" - Certificate[3] info: - subject `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', issuer `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x01, RSA key 2048 bits, signed using RSA-SHA1 (broken!), activated `2004-01-01 00:00:00 UTC', expires `2028-12-31 23:59:59 UTC', pin-sha256="" - Certificate[4] info: - subject `CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US', issuer `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', serial , RSA key 2048 bits, signed using RSA-SHA384, activated `2014-10-06 00:00:00 UTC', expires `2024-10-05 23:59:59 UTC', pin-sha256="" - Certificate[5] info: - subject `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', issuer `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial , RSA key 4096 bits, signed using RSA-SHA384, activated `2019-03-12 00:00:00 UTC', expires `2028-12-31 23:59:59 UTC', pin-sha256="" - Certificate[6] info: - subject `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', issuer `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x01, RSA key 2048 bits, signed using RSA-SHA1 (broken!), activated `2004-01-01 00:00:00 UTC', expires `2028-12-31 23:59:59 UTC', pin-sha256="" gnutls-cli: ../../../lib/x509/common.c:1794: _gnutls_sort_clist: Assertion `k == clist_size' failed. Aborted Let me know if you need this run with different arguments. On 1/20/21 3:12 AM, Andreas Metzler wrote: On 2021-01-20 Matt wrote: Package: libgnutls30 Version: 3.7.0-5 [...] After an upgrade to 3.7.0-5, I can no longer connect to a GlobalProtect VPN with openconnect. This is the output from a connection attempt (with identifying information removed): $ sudo openconnect --protocol gp -u POST https:///global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux Connected to :443 SSL negotiation with [...] Can this be reproduced with gnutls-cli? cu Andreas
Bug#980520: britney: excuses: reduce verbosity of autopkgtest results
On Wed, 2021-01-20 at 19:26 +0100, Paul Gevers wrote: > Passing packages that are still shown are those where an update > happened since the successful run, so they are more or less > "pending". I realize that probably nobody realizes this. It is very non-obvious from the output, I'd suggest putting Pending instead of Pass for the packages in that scenario. > I think we had other ideas on how to improve readability but IIRC, > those had to wait until jessie became EOL, as our ideas weren't > compatible with grep-excuses in jessie. This now happened so we could > pick that up. Good to hear, is there a bug about those ideas? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#980629: nheko: FTBFS: internal compiler error
On Wed, 20 Jan 2021 21:42:22 +0100, Lucas Nussbaum said: > During a rebuild of all packages in sid, your package failed to build > on amd64. This version of nheko was just rebuilt 18 days ago as a binNMU. https://buildd.debian.org/status/fetch.php?pkg=nheko&arch=amd64&ver=0.7.2-3%2Bb1&stamp=1609589163&raw=0 That build used gcc-10_10.2.1-3 instead of gcc-10_10.2.1-6. Given that the package was built successfully so recently, I suspect that there is a bug elsewhere, but aside from blindly reassigning this bug to gcc-10 and crossing my fingers, I'm not sure what's the best way to proceed. But I've Cc'ed doko, as gcc maintainer, on this email. Coincidentally, I uploaded nheko 0.8.0 today, and it also failed in the same spot (/usr/include/tweeny/easingresolve.h:62:27). In fact, I thought that this bug was about the newly-uploaded package, until I looked more closely at it. ;) It succeeded to build on my own machine, which was using an older version of gcc (9.3.0, apparently). > Relevant part (hopefully): [...trim...] >> [ 49%] Building CXX object CMakeFiles/nheko.dir/src/ui/Ripple.cpp.o >> /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK > -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_SYSTEM_DYN_LINK > -DBOOST_THREAD_DYN_LINK -DFMT_LOCALE -DFMT_SHARED > -DJSON_USE_IMPLICIT_CONVERSIONS=1 -DQAPPLICATION_CLASS=QApplication > -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB > -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_QMLMODELS_LIB > -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICKWIDGETS_LIB > -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DSPDLOG_COMPILED_LIB > -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB -I/<>/build > -I/<> -I/<>/src -I/<>/includes > -I/<>/third_party/blurhash > -I/<>/third_party/cpp-httplib-0.5.12 > -I/usr/include/tweeny > -I/<>/third_party/SingleApplication-3.1.3.1 -isystem > /usr/include/x86_64-linux-gnu/qt5 -isystem > /usr/include/x86_64-linux-gnu/qt5/QtDBus -isystem > /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem > /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem > /<>/mtxclient/include -isystem > /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem > /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem > /usr/include/x86_64-linux-gnu/qt5/QtSvg -isystem > /usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem > /usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem > /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem > /usr/include/x86_64-linux-gnu/qt5/QtQml -isystem > /usr/include/x86_64-linux-gnu/qt5/QtQuickControls2 -isystem > /usr/include/x86_64-linux-gnu/qt5/QtQuick -isystem > /usr/include/x86_64-linux-gnu/qt5/QtQmlModels -isystem > /usr/include/x86_64-linux-gnu/qt5/QtQuickWidgets -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time > -D_FORTIFY_SOURCE=2 -Wall -Wextra -pipe -pedantic -fsized-deallocation > -fdiagnostics-color=always -Wunreachable-code -std=c++17 -O2 -g > -DNDEBUG -fPIE -fPIC -pthread -std=gnu++17 -Winvalid-pch -include > /<>/build/CMakeFiles/nheko.dir/cmake_pch.hxx -o > CMakeFiles/nheko.dir/src/ui/Ripple.cpp.o -c > /<>/src/ui/Ripple.cpp >> In file included from /usr/include/tweeny/tween.h:595, from >> /usr/include/tweeny/tweeny.h:81, from >> /<>/src/ui/SnackBar.cpp:3: >> /usr/include/tweeny/tween.tcc:249:6: warning: > extra ‘;’ [-Wpedantic] >> 249 | }; | ^ /usr/include/tweeny/tween.tcc:257:6: warning: > extra ‘;’ [-Wpedantic] >> 257 | }; | ^ In file included from /usr/include/tweeny/tween.h:596, >> from /usr/include/tweeny/tweeny.h:81, from >> /<>/src/ui/SnackBar.cpp:3: >> /usr/include/tweeny/tweenone.tcc:246:4: > warning: extra ‘;’ [-Wpedantic] >> 246 | }; | ^ In file included from >> /usr/include/tweeny/tweenpoint.tcc:38, from >> /usr/include/tweeny/tweenpoint.h:80, from >> /usr/include/tweeny/tween.h:38, from /usr/include/tweeny/tweeny.h:81, >> from /<>/src/ui/SnackBar.cpp:3: >> /usr/include/tweeny/easingresolve.h: In substitution of > ‘template std::function& > std::function float)>::operator=<_Functor>(std::reference_wrapper<_Tp>) [with > _Functor = ]’: >> /usr/include/tweeny/easingresolve.h:62:27: required from > ‘static void tweeny::detail::easingresolve FunctionTuple, tweeny::easing::linearEasing, Fs > ...>::impl(FunctionTuple&, tweeny::easing::linearEasing, Fs ...) > [with int I = 0; TypeTuple = std::array; FunctionTuple = > std::tuple >; Fs = {}]’ >> /usr/include/tweeny/tweenpoint.tcc:49:75: required from > ‘void tweeny::detail::easingfill(EasingCollectionT&, EasingT, > tweeny::detail::int2type<0>) [with TypeTupleT = std::array; > EasingCollectionT = std::tuple float)> >; EasingT = tweeny::easing::linearEasing]’ >> /usr/include/tweeny/tweenpoint.tcc:101:52: required from > ‘void tweeny::detail::tweenpoint::via(F) [with F = > tweeny::easing::linearEasing; Ts = {float}]’ >> /usr/include/tweeny/tweenpoint.tcc:72:16: required from > ‘tweeny::detail::tweenpoint::tweenpoint(Ts ...) [with Ts = > {float}]’ >> /usr/include/c++/10/ext/new_allocator.h
Bug#980723: autopkgtests aren't being run for rust-sequoia-sqv or rust-sequoia-keyring-linter or rust-sequoia-sop
Package: rust-sequoia-sqv Version: 1.0.0-1 Looks like the autopkgtests are not being run for rust-sequoia-sqv (or for sq-keyring-linter or sqop). I think this is because some rust packages needed specifically for testing are not available in the archive. We should add them to the archive so that the autopkgtest suites get run. (they do not appear to be run during the build) --dkg
Bug#980509: umap-learn: Binary package name should be python3-umap-learn
On Wed, 2021-01-20 at 10:48 +0100, Andreas Tille wrote: > I've fixed this in Git for the new upstream version. Unfortunately > this > new version needs python-pynndescent (ITP #980537) but I need some > help > with the test suite there. > While waiting for numba test cases on the super slow armhf architecture to run I got the pynndescent autopkgtests to run (by replacing the contents of run-unit-tests) and pushed them to the main packaging repository. Would you like me to build the package and upload it to NEW? Diane
Bug#980722: RFS: filezilla/3.52.2-2 [Team] -- Full-featured graphical FTP/FTPS/SFTP client
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "filezilla": * Package name: filezilla Version : 3.52.2-2 Upstream Author : Tim Kosse * URL : https://filezilla-project.org/ * License : CC0-1.0, GPL-2+, MIT, permissive, BSD-like * Vcs : https://salsa.debian.org/debian/filezilla Section : net It builds those binary packages: filezilla-common - Architecture independent files for filezilla filezilla - Full-featured graphical FTP/FTPS/SFTP client To access further information about this package, please visit the following URL: https://mentors.debian.net/package/filezilla/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.52.2-2.dsc Changes since the last upload: filezilla (3.52.2-2) unstable; urgency=medium . * Team upload * Update of d/copyright * Made filezilla-common Multi-Arch: foreign - Suggested by multiarch hinter Regards Phil -- *** Playing the game for the games own sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#980205: #980205 installation missing "non free" drivers.
Yes. brcm/brcmfmac43340-sdio.bin is not currently part of the package either, and I think there's no logic to copy .txt files even if they are present. At 04:39 PM 1/20/2021, Holger Wansing wrote: >Control: reassign -1 firmware-nonfree >Control: retitle -1 firmware: missing txt file for brcm/brcmfmac43340-sdio.bin > >Dave Dyer wrote: >> At 05:40 AM 1/18/2021, Holger Wansing wrote: >> >> 3) in my particular case, the driver is brcm/brcmfmac43340-sdio.bin, which >> >> *also* requires a text file, brcm/brcmfmac43340-sdio.txt. I know this >> >> because >> >> I figured out case 2B and got the installer to accept the .bin; it then >> >> it mentions the need for the .txt file. (Again, thanks, it would have >> >> been impossible to proceed without this key information). However, >> >> there's apparently no way to get the installer to accept the .txt >> >> file in the same way that it finds the .bin. >> > >> >Hmm, looking into the package firmware-brcm80211 >> >(https://packages.debian.org/buster/firmware-brcm80211) >> >there is no such txt file there. >> >So I wonder where you found such file? >> >> Github + Google. And the file I found works. > >So this txt file will need to be added to firmware-brcm80211 package, too? > >Re-assigning there. > > >Holger > > >-- >Holger Wansing >PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#969971: Also affected by the bug
I appreciate your detailed explanation, era. Thank you. On 1/19/21 10:07 PM, era wrote: The following is based on my -- possibly limited -- understanding based on reading through the bug reports around this. On Wed, Jan 20, 2021, at 05:56, Deb-user wrote: Thank you for your reply. Yes, the workaround works, but I feel that this is still a bug in the package. I'm also not sure how safe it is to disable TLS 1.3. Your options at this point are then, in no particular order; * Live without ELPA (easy if you can live with base Emacs; hard if you need ELPA packages); * Find or create a backport of the TLS1.3 handling fix yourself, and use that instead of the Debian-packaged Emacs; * Turn off TLS1.3 and take steps to mitigate the risks (not sure what exactly that would look like in practice) I believe Emacs version 26.3 fixes this. I don't know how updating packages works in stable releases, or if it is even possible. I am new to Debian. In normal circumstances, the "stable" version does not get updates except for critical security fixes. However, there was already one attempt at fixing this particular bug which however doesn't seem to work satisfactorily, which is apparently what caused this bug to be submitted. There definitely won't be a 26.3 in Buster, but perhaps the maintainer would still like to take another stab at providing a backport for 26.1 which actually works, and release that fix to Buster. Perhaps see also the discussion in the linked original bug https://bugs.debian.org/942413 /* era */
Bug#973323: Boot failure triggered by USB on rockpro64-rk3399 and pinebook-pro-rk3399
It seems rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot when usb is started. It hangs indefinitely at: ## Flattened Device Tree blob at 01f0 Booting using the fdt blob at 0x1f0 I have observed this also using 2020.10 on rockpro64-rk3399, though on pinebook-pro-rk3399 usb does not work and so it basically avoids triggering the issue. Setting CONFIG_USE_PREBOOT=n in the config works around the problem, though obviously by breaking usb keyboard support or booting from USB devices. Related bugs in Debian and manjaro: https://bugs.debian.org/973323 https://bugs.debian.org/980434 https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-rockpro64/-/issues/4 Boot log: U-Boot 2021.01+dfsg-1 (Jan 17 2021 - 03:50:13 +) SoC: Rockchip rk3399 Reset cause: POR Model: Pine64 RockPro64 v2.1 DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0 Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Model: Pine64 RockPro64 v2.1 Net: eth0: ethernet@fe30 starting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe3e: USB OHCI 1.0 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3a for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe3e for devices... 1 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 => printenv preboot preboot=usb start => usb reset resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe3e: USB OHCI 1.0 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3a for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe3e for devices... 1 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => boot Card did not respond to voltage select! : -110 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 144 bytes read in 5 ms (27.3 KiB/s) 1: Debian-Installer Retrieving file: /initrd.gz 28995285 bytes read in 1287 ms (21.5 MiB/s) Retrieving file: /vmlinuz 26922864 bytes read in 1195 ms (21.5 MiB/s) Retrieving file: /dtbs/rockchip/rk3399-rockpro64.dtb 56849 bytes read in 13 ms (4.2 MiB/s) Moving Image from 0x208 to 0x220, end=3c5 ## Flattened Device Tree blob at 01f0 Booting using the fdt blob at 0x1f0 live well, vagrant signature.asc Description: PGP signature
Bug#890343: linux: make fq_codel default for default_qdisc
On Wed, 2021-01-20 at 14:46 -0800, Noah Meyerhans wrote: > On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote: > > > We could do that. However, in the past (earlier in this bug, > > > even) it's > > > been pointed out that other packages should not be responsible > > > for > > > setting kernel policies, so changes like this should be the > > > responsibility of the kernel packages. That seems like a > > > sensible > > > position to take. > > > > If this is the position of the kernel team, then fine. But some > > packages *do* > > tweak kernel parameters using the sysctl interface mechanism. So > > does the kernel > > team provides documention about what is acceptable? > > I think the distinction is that the other packages that tweak sysctl > values don't claim to be doing so on behalf of the kernel team. If > the > kernel team is responsible for the values being set, then the > settings > should come from a package that the kernel team owns, not some other > package. Right, maybe in linux-base? Although that might annoy derivatives that want different defaults. procps is the wrong place, not just because it's out of our hands, but because systemd applies sysctl configuration now and procps is optional. Ben. > AFAIK, there are no guidelines or policy anywhere in Debian about > whether or not a package can provide its own sysctl settings. > > noah > -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#980658: pygame-sdl2: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
On Wed, 20 Jan 2021 at 22:01:14 +0100, Lucas Nussbaum wrote: > > dpkg-source -b . Are you deliberately rebuilding the source package? That seems unusual for testing whether packages FTBFS... > > dpkg-source: info: local changes detected, the modified files are: > > pygame-sdl2-7.4.0/gen3/color_dict.html > > pygame-sdl2-7.4.0/gen3/controller.html > > pygame-sdl2-7.4.0/gen3/event_list.html > > pygame-sdl2-7.4.0/gen3/event_names.html > > pygame-sdl2-7.4.0/gen3/glattr.html > > pygame-sdl2-7.4.0/gen3/keycode_list.html > > pygame-sdl2-7.4.0/gen3/pygame_sdl2.color.c > > pygame-sdl2-7.4.0/gen3/pygame_sdl2.color.html (etc.) This seems to be because pygame-sdl2 rebuilds parts of itself during `debian/rules clean`, possibly triggered by being built with a newer version of SDL. That seems strange, and at least arguably a bug in its own right? Deleting these files in debian/clean would probably resolve this. smcv
Bug#980606: supertuxkart: FTBFS: gamepad_config.cpp:35:45: error: static assertion failed: non continous name
On Wed, 20 Jan 2021 at 21:30:37 +0100, Lucas Nussbaum wrote: > >35 | static_assert(SDL_CONTROLLER_BUTTON_MAX - 1 == > > SDL_CONTROLLER_BUTTON_DPAD_RIGHT, "non continous name"); I think this is caused by SDL 2.0.14 adding support for more controller buttons, and supertuxkart assuming that this would never happen. Upstream commit https://github.com/supertuxkart/stk-code/commit/61833c9c26da5520f2eaa02f2458971ba07f2aad seems relevant. smcv
Bug#890343: linux: make fq_codel default for default_qdisc
Le 2021-01-20 14:46, Noah Meyerhans a écrit : > On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote: > > > We could do that. However, in the past (earlier in this bug, even) it's > > > been pointed out that other packages should not be responsible for > > > setting kernel policies, so changes like this should be the > > > responsibility of the kernel packages. That seems like a sensible > > > position to take. > > > > If this is the position of the kernel team, then fine. But some packages > > *do* > > tweak kernel parameters using the sysctl interface mechanism. So does the > > kernel > > team provides documention about what is acceptable? > > I think the distinction is that the other packages that tweak sysctl > values don't claim to be doing so on behalf of the kernel team. If the > kernel team is responsible for the values being set, then the settings > should come from a package that the kernel team owns, not some other > package. Makes sense! > AFAIK, there are no guidelines or policy anywhere in Debian about > whether or not a package can provide its own sysctl settings. That would be nice to have a statement on this, though. > noah Cheers, Vincent signature.asc Description: PGP signature
Bug#912271: please provide a newlib source package
I would also like to see a package for Newlib sources. For my case I'm investigating packaging a cross toolchain to build free firmware (carl9170), which uses the SH-2 ISA and requires Newlib. If that is to be built by a new Debian source package instead of this one, then a newlib-source package is a necessary prerequisite. signature.asc Description: This is a digitally signed message part.
Bug#980721: graphicsmagick: reduce Build-Depends
Source: graphicsmagick Version: 1.4+really1.3.36+hg16442-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap graphicsmagick participates in a number of dependency cycles relevant to architecture bootstrap. Rather than looking into this difficult problem, I looked into easily droppable dependencies and found some. To that end, I compared the binary artifacts of a regular build with those of a nocheck build with the following dependencies turned into Build-Conflicts and notices that they were identical: * libexif-dev seems entirely unused. I couldn't find any mention of it anywhere. * uudecode from sharutils is only used in a d/rules block conditional to DEB_BUILD_OPTIONS not containing nocheck. * gsfonts was added to fix failing tests. As such it seems like a test-only dependency. * Since d/rules passes --without-frozenpaths, fig2dev is not needed during build. It can be dropped. * Since d/rules passes --without-modules, libltdl-dev is unused. Please consider applying the attached patch. Helmut diff --minimal -Nru graphicsmagick-1.4+really1.3.36+hg16442/debian/changelog graphicsmagick-1.4+really1.3.36+hg16442/debian/changelog --- graphicsmagick-1.4+really1.3.36+hg16442/debian/changelog2021-01-08 18:02:36.0 +0100 +++ graphicsmagick-1.4+really1.3.36+hg16442/debian/changelog2021-01-20 21:52:07.0 +0100 @@ -1,3 +1,16 @@ +graphicsmagick (1.4+really1.3.36+hg16442-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Reduce Build-Depends: (Closes: #-1) ++ Drop unused libexif-dev. ++ Annotate sharutils with as uudecode is conditionally used in + d/rules. ++ Annotate gsfonts with as it is only used in unit tests. ++ Drop unused transfig as d/rules passes --without-frozenpaths. ++ Drop unused libltdl-dev as d/rules passes --without-modules. + + -- Helmut Grohne Wed, 20 Jan 2021 21:52:07 +0100 + graphicsmagick (1.4+really1.3.36+hg16442-1) unstable; urgency=high * Mercurial snapshot, fixing the following security issues: diff --minimal -Nru graphicsmagick-1.4+really1.3.36+hg16442/debian/control graphicsmagick-1.4+really1.3.36+hg16442/debian/control --- graphicsmagick-1.4+really1.3.36+hg16442/debian/control 2020-12-12 20:44:16.0 +0100 +++ graphicsmagick-1.4+really1.3.36+hg16442/debian/control 2021-01-20 21:52:07.0 +0100 @@ -2,7 +2,7 @@ Section: graphics Priority: optional Maintainer: Laszlo Boszormenyi (GCS) -Build-Depends: debhelper-compat (= 13), pkg-config, libjpeg-dev, liblcms2-dev, libwmf-dev (>= 0.2.8.4), libx11-dev, libsm-dev, libice-dev, libxext-dev, x11proto-core-dev, libxml2-dev, libfreetype6-dev, libexif-dev, libbz2-dev, libtiff-dev (>= 4.0.10), libjbig-dev, zlib1g-dev | libz-dev, libpng-dev, libwebp-dev, libzstd-dev, perl (>= 5.20), ghostscript, gsfonts, transfig, sharutils, libltdl-dev +Build-Depends: debhelper-compat (= 13), pkg-config, libjpeg-dev, liblcms2-dev, libwmf-dev (>= 0.2.8.4), libx11-dev, libsm-dev, libice-dev, libxext-dev, x11proto-core-dev, libxml2-dev, libfreetype6-dev, libbz2-dev, libtiff-dev (>= 4.0.10), libjbig-dev, zlib1g-dev | libz-dev, libpng-dev, libwebp-dev, libzstd-dev, perl (>= 5.20), ghostscript, gsfonts , sharutils Standards-Version: 4.5.1 Homepage: http://www.graphicsmagick.org/
Bug#890343: linux: make fq_codel default for default_qdisc
On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote: > > We could do that. However, in the past (earlier in this bug, even) it's > > been pointed out that other packages should not be responsible for > > setting kernel policies, so changes like this should be the > > responsibility of the kernel packages. That seems like a sensible > > position to take. > > If this is the position of the kernel team, then fine. But some packages *do* > tweak kernel parameters using the sysctl interface mechanism. So does the > kernel > team provides documention about what is acceptable? I think the distinction is that the other packages that tweak sysctl values don't claim to be doing so on behalf of the kernel team. If the kernel team is responsible for the values being set, then the settings should come from a package that the kernel team owns, not some other package. AFAIK, there are no guidelines or policy anywhere in Debian about whether or not a package can provide its own sysctl settings. noah
Bug#980719: python-apt: reduce Build-Depends
Source: python-apt Version: 2.1.7 Tags: patch User: helm...@debian.org Usertags: rebootstrap python-apt participates in a number of dependency cycles relevant to architecture bootstrap. Rather than work on such a difficult problem, I looked into easily droppable dependencies. It turns out that a nocheck build with the following dependencies turned into Build-Conflicts exactly reproduces binary artifacts of a regular build: * apt-utils * distro-info-data * gnupg * dirmngr * pycodestyle * pyflakes3 As such I suggest annotating them . Please consider applying the attached patch. Helmut diff --minimal -Nru python-apt-2.1.7/debian/changelog python-apt-2.1.7+nmu1/debian/changelog --- python-apt-2.1.7/debian/changelog 2020-12-10 15:35:32.0 +0100 +++ python-apt-2.1.7+nmu1/debian/changelog 2021-01-20 23:22:50.0 +0100 @@ -1,3 +1,10 @@ +python-apt (2.1.7+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Annotate test dependencies with . (Closes: #-1) + + -- Helmut Grohne Wed, 20 Jan 2021 23:22:50 +0100 + python-apt (2.1.7) unstable; urgency=medium * SECURITY UPDATE: various memory and file descriptor leaks (LP: #1899193) diff --minimal -Nru python-apt-2.1.7/debian/control python-apt-2.1.7+nmu1/debian/control --- python-apt-2.1.7/debian/control 2020-12-10 15:35:32.0 +0100 +++ python-apt-2.1.7+nmu1/debian/control2021-01-20 23:22:48.0 +0100 @@ -6,10 +6,10 @@ Rules-Requires-Root: no Standards-Version: 4.5.0 Build-Depends: apt (>= 1.0.9.4), - apt-utils, + apt-utils , debhelper-compat (= 12), dh-python, - distro-info-data, + distro-info-data , fakeroot, libapt-pkg-dev (>= 1.9.11~), python3-all (>= 3.3), @@ -19,10 +19,10 @@ python3-distutils-extra (>= 2.0), python3-setuptools, python3-sphinx (>= 0.5), - gnupg, - dirmngr | gnupg (<< 2), - pycodestyle, - pyflakes3 + gnupg , + dirmngr | gnupg (<< 2) , + pycodestyle , + pyflakes3 , Vcs-Git: https://salsa.debian.org/apt-team/python-apt.git Vcs-Browser: https://salsa.debian.org/apt-team/python-apt
Bug#980720: mark libreadonly-perl Multi-Arch: foreign
Source: libreadonly-perl Version: 2.050-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability Control: affects -1 + src:enblend-enfuse src:krb5-strength src:krb5-sync src:lbcd src:libafs-pag-perl src:libapache2-mod-perl2 src:libdevel-cover-perl src:libgraphics-tiff-perl src:libimage-sane-perl src:libnet-rawip-perl src:libref-util-xs-perl src:os-autoinst src:plasmidid src:remctl src:webauth The affected packages cannot satisfy their cross Build-Depends, because their transitive dependency on libreadonly-perl is not satisfiable. In general, Architecture: all packages can never satisfy cross Build-Depends unless marked Multi-Arch: foreign or annotated :native. In this case, the foreign marking seems reasonable as libreadonly-perl is a pure perl module without any non-core dependencies. Please consider applying the attached patch. Helmut diff --minimal -Nru libreadonly-perl-2.050/debian/changelog libreadonly-perl-2.050/debian/changelog --- libreadonly-perl-2.050/debian/changelog 2019-07-15 15:41:02.0 +0200 +++ libreadonly-perl-2.050/debian/changelog 2021-01-20 23:43:05.0 +0100 @@ -1,3 +1,10 @@ +libreadonly-perl (2.050-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Mark libreadonly-perl Muli-Arch: foreign. (Closes: #-1) + + -- Helmut Grohne Wed, 20 Jan 2021 23:43:05 +0100 + libreadonly-perl (2.050-2) unstable; urgency=medium [ gregor herrmann ] diff --minimal -Nru libreadonly-perl-2.050/debian/control libreadonly-perl-2.050/debian/control --- libreadonly-perl-2.050/debian/control 2019-07-15 15:41:02.0 +0200 +++ libreadonly-perl-2.050/debian/control 2021-01-20 23:43:02.0 +0100 @@ -14,6 +14,7 @@ Package: libreadonly-perl Architecture: all +Multi-Arch: foreign Depends: ${misc:Depends}, ${perl:Depends} Provides: libreadonly-xs-perl
Bug#980617: racon: FTBFS: build-dependency not installable: libthread-pool-dev (>= 3.0.2)
On Wed, 20 Jan 2021 21:33:41 +0100 Lucas Nussbaum wrote: > Source: racon > Version: 1.4.20-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20210120 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > +--+ > > | Install package build dependencies | > > +--+ > > > > > > Setup apt archive > > - > > > > Merged Build-Depends: debhelper-compat (= 13), cmake, libgtest-dev, libbioparser-dev (>= 3.0.12), libcereal-dev, libedlib-dev, libspoa-dev, libthread-pool-dev (>= 3.0.2), rampler, build-essential, fakeroot > > Filtered Build-Depends: debhelper-compat (= 13), cmake, libgtest-dev, libbioparser-dev (>= 3.0.12), libcereal-dev, libedlib-dev, libspoa-dev, libthread-pool-dev (>= 3.0.2), rampler, build-essential, fakeroot > > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. > > Ign:1 copy:/<>/apt_archive ./ InRelease > > Get:2 copy:/<>/apt_archive ./ Release [957 B] > > Ign:3 copy:/<>/apt_archive ./ Release.gpg > > Get:4 copy:/<>/apt_archive ./ Sources [433 B] > > Get:5 copy:/<>/apt_archive ./ Packages [518 B] > > Fetched 1908 B in 0s (187 kB/s) > > Reading package lists... > > Reading package lists... > > > > Install main build dependencies (apt-based resolver) > > > > > > Installing build dependencies > > Reading package lists... > > Building dependency tree... > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > sbuild-build-depends-main-dummy : Depends: libthread-pool-dev (>= 3.0.2) but it is not installable > > E: Unable to correct problems, you have held broken packages. > > apt-get failed. https://packages.debian.org/sid/libthread-pool-dev 3.0.2 is indeed available. Racon built just fine on the buildds.. https://buildd.debian.org/status/package.php?p=racon https://buildd.debian.org/status/fetch.php?pkg=racon&arch=amd64&ver=1.4.20-1&stamp=1611053002&raw=0 -- Michael R. Crusoe
Bug#980718: RM: dkimproxy -- ROM; RC buggy, no upstream, better alternatives
Package: ftp.debian.org Severity: normal Hi, I'm failing my duties on this package, so it's probably time that it goes away from Debian. Also, see $subject: upstream has become non-responsive. There's also many alternative solutions that people are using with Postfix these days (which wasn't the case when I first packaged dkimproxy). Let's fix all of this by removing dkimproxy from the archive before Bullseye... Cheers, Thomas Goirand (zigo)
Bug#890343: linux: make fq_codel default for default_qdisc
Le 2021-01-20 13:58, Noah Meyerhans a écrit : > On Wed, Jan 20, 2021 at 10:22:16PM +0100, Vincent Blut wrote: > > My proposal would differ from yours though in that it would not touch the > > kernel > > configuration but would instead consist in patching procps to provide a > > configuration file (let's say default_qdisc.conf) to set the value of the > > net.core.default_qdisc variable to fq_codel via sysctl. > > This would allow to benefit from FQ_Codel without depending on a specific > > Linux > > version. > > We could do that. However, in the past (earlier in this bug, even) it's > been pointed out that other packages should not be responsible for > setting kernel policies, so changes like this should be the > responsibility of the kernel packages. That seems like a sensible > position to take. If this is the position of the kernel team, then fine. But some packages *do* tweak kernel parameters using the sysctl interface mechanism. So does the kernel team provides documention about what is acceptable? signature.asc Description: PGP signature
Bug#980610: Incompatibility of starjava-topcat and starjava-ttools with new starjava-table
Control: block -1 by 980153 The package starjava-table was recently updated; however it now has a split-off (source) package starjava-tjoin (ITP #980153). To fix the FTBFS, starjava-tjoin needs to be accepted, and the updated starjava-ttools resp. starjava-topcat packages must be uploaded with starjava-tjoin as a new dependency, Cheers Ole
Bug#980595: libcheck made a breaking change
libcheck made a breaking change. Patch for arping to make it build: https://github.com/ThomasHabets/arping/commit/e0773bc26ae14d4a19825023307d1496d7c7d0f1 I aim to release 2.22 tomorrow with this change. But there are no changes between 2.21 and 2.22, so you can just patch in the commit, if you prefer. I see the tag is set to "serious". To be clear this is a failure of the TEST to compile only. I agree that this should be seen as serious, but it's just the test. Tracking bug on arping (upstream) side: https://github.com/ThomasHabets/arping/issues/39 -- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "tho...@habets.se " }; char kernel[]= { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; }; char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t;
Bug#890343: linux: make fq_codel default for default_qdisc
Control: tags -1 + patch A proposed patch is at https://salsa.debian.org/kernel-team/linux/-/merge_requests/309
Bug#980717: kazocsaba-imageviewer FTBFS
Source: kazocsaba-imageviewer Version: 1.2.3-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=kazocsaba-imageviewer&arch=all&ver=1.2.3-2&stamp=1611094937&raw=0 ... --- Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/cli/UnrecognizedOptionException at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:278) at org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at org.apache.maven.cli.MavenCli.main(MavenCli.java:182) at org.debian.maven.Wrapper.main(Wrapper.java:89) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:321) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:234) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347) Caused by: java.lang.ClassNotFoundException: org.apache.commons.cli.UnrecognizedOptionException at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239) ... 12 more dh_auto_build: error: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1 make: *** [debian/rules:4: binary-indep] Error 25
Bug#980613: Incompatibility of starjava-topcat and starjava-ttools with new starjava-table
Control: block -1 by 980153 The package starjava-table was recently updated; however it now has a split-off (source) package starjava-tjoin (ITP #980153). To fix the FTBFS, starjava-tjoin needs to be accepted, and the updated starjava-ttools resp. starjava-topcat packages must be uploaded with starjava-tjoin as a new dependency, Cheers Ole
Bug#980423: 3.12.4 makes several packages FTBFS
Hi, * Sebastian Ramacher [2021-01-20 22:20]: On 2021-01-19 00:05:36 +0100, László Böszörményi wrote: On Mon, Jan 18, 2021 at 10:24 PM Laurent Bigonville wrote: > Several packages FTBFS since 3.12.4 > > The autopkgtest catched ignition-msgs and ignition-transport, see > https://packages.qa.debian.org/p/protobuf.html > > I can see that evolution-data-server also FTBFS [...] > This is a bit unfortunate that it's happening so late in the developpement cycle. Indeed, my fault. Investigating. Hope this can be resolved easily. The autopkgtest failures indicate that ignition-msgs' and ignition-transport's dependencies on libprotobuf-dev (>= X.Y), (< X.{Y+1}) is not enough. It will need to be (>= X.Y.Z), (< X.Y.{Z+1}) instead. I guess an other option would be to depend on the new API definition: Package: libprotobuf-dev Provides: protobuf-api-23-0 @László: would you agree? (We discussed this in #963247 before). Cheers Jochen signature.asc Description: PGP signature
Bug#967010: (no subject)
Sorry not sorry~HM King MBS -- Sent from King Philps' NETWORKS & MORE 77
Bug#980716: ITP: luma.core -- component library providing a Pillow-compatible drawing canvas
Package: wnpp Severity: wishlist Owner: Anton Gladky X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: luma.core Version : 2.2.0 Upstream Author : Richard Hull and contributors * URL : https://github.com/rm-hull/luma.core/ * License : MIT Programming Lang: Python Description : component library providing a Pillow-compatible drawing canvas component library providing a Pillow-compatible drawing canvas other functionality to support drawing primitives and text-rendering capabilities for small displays on the Raspberry Pi and other single board computers: * scrolling/panning capability, * terminal-style printing, * state management, * color/greyscale (where supported), * dithering to monochrome, * sprite animation, * flexible framebuffering (depending on device capabilities)
Bug#890343: linux: make fq_codel default for default_qdisc
On Wed, Jan 20, 2021 at 10:22:16PM +0100, Vincent Blut wrote: > My proposal would differ from yours though in that it would not touch the > kernel > configuration but would instead consist in patching procps to provide a > configuration file (let's say default_qdisc.conf) to set the value of the > net.core.default_qdisc variable to fq_codel via sysctl. > This would allow to benefit from FQ_Codel without depending on a specific > Linux > version. We could do that. However, in the past (earlier in this bug, even) it's been pointed out that other packages should not be responsible for setting kernel policies, so changes like this should be the responsibility of the kernel packages. That seems like a sensible position to take. One possible way for the kernel team to take ownership of this would be for it to introduce a new "debian-kernel-sysctl" package or something like that to provide some sysctl.d drop-in files. It could then set net.core.default_qdisc, and potentially others in various scenarios. Such a package can be installed indepdendently of whether the user is running a Debian-provided kernel package. The other alternative is the one I've proposed, which involves changing the compile-time defaults in Debian's kernel packages. This obviously only affects users of those packages. However, I think that's fine; people who are building their own packages may very well be starting from Debian's config, in which case they'll still get this change, or may be constructing their own configuration from scratch, in which case they're assuming ownership of all the parameters. noah
Bug#890343: linux: make fq_codel default for default_qdisc
On Sun, Jan 17, 2021 at 10:29:44PM -0300, Ivan Baldo wrote: > I think we want the mq qdisc to distribute the load between cores, to > support very high speed network cards or too slow CPUs. Yep, you're right. Though it's not about CPU cores, but about tx queues on the NIC hardware. > Also, if net.core.default_qdisc = fq_codel is used, it also has the mq > qdisc and fq_codel childs for each CPU core, so that's the default behavior > in other distros. Yep, so I think the behavior when we set the default qdisc to fq_codel in the kernel config has the effect we're looking for, after all. noah
Bug#980595: arping: FTBFS: arping_test.c:239:8: error: ‘test_mkpacket’ redeclared as different kind of symbol
Hi, On Wed, Jan 20, 2021 at 09:25:15PM +0100, Lucas Nussbaum wrote: > Source: arping > Version: 2.21-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20210120 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 > > -D_DEFAULT_SOURCE=1 -g -O2 -ffile-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -c -o > > arping_test.o arping_test.c > > In file included from arping_test.c:29: > > arping_test.c:239:8: error: ‘test_mkpacket’ redeclared as different kind of > > symbol > > 239 | MYTEST(test_mkpacket) > > |^ > > arping_test.c:239:1: note: in expansion of macro ‘MYTEST’ > > 239 | MYTEST(test_mkpacket) > > | ^~ > > arping_test.c:239:8: note: previous declaration of ‘test_mkpacket’ was here > > 239 | MYTEST(test_mkpacket) > > |^ > > arping_test.c:58:31: note: in definition of macro ‘MYTEST’ > >58 | #define MYTEST(a) static void a(int);__attribute__((constructor)) \ > > | ^ > > In file included from arping_test.c:29: > > arping_test.c:264:8: error: ‘pingip_uninteresting_packet’ redeclared as > > different kind of symbol > > 264 | MYTEST(pingip_uninteresting_packet) > > |^~~ > > arping_test.c:264:1: note: in expansion of macro ‘MYTEST’ > > 264 | MYTEST(pingip_uninteresting_packet) > > | ^~ > > arping_test.c:264:8: note: previous declaration of > > ‘pingip_uninteresting_packet’ was here > > 264 | MYTEST(pingip_uninteresting_packet) > > |^~~ > > arping_test.c:58:31: note: in definition of macro ‘MYTEST’ > >58 | #define MYTEST(a) static void a(int);__attribute__((constructor)) \ > > | ^ > > In file included from arping_test.c:29: > > arping_test.c:392:8: error: ‘pingip_interesting_packet’ redeclared as > > different kind of symbol > > 392 | MYTEST(pingip_interesting_packet) > > |^ > > arping_test.c:392:1: note: in expansion of macro ‘MYTEST’ > > 392 | MYTEST(pingip_interesting_packet) > > | ^~ > > arping_test.c:392:8: note: previous declaration of > > ‘pingip_interesting_packet’ was here > > 392 | MYTEST(pingip_interesting_packet) > > |^ > > arping_test.c:58:31: note: in definition of macro ‘MYTEST’ > >58 | #define MYTEST(a) static void a(int);__attribute__((constructor)) \ > > | ^ > > In file included from arping_test.c:29: > > arping_test.c: In function ‘pingip_interesting_packet_fn’: > > arping_test.c:445:21: warning: too many arguments for format > > [-Wformat-extra-args] > > 445 | "numrecvd not incremented"); > > | ^~ > > arping_test.c:449:21: warning: too many arguments for format > > [-Wformat-extra-args] > > 449 | "numrecvd not incremented second time"); > > | ^~ > > arping_test.c: At top level: > > arping_test.c:452:8: error: ‘strip_newline_test’ redeclared as different > > kind of symbol > > 452 | MYTEST(strip_newline_test) > > |^~ > > arping_test.c:452:1: note: in expansion of macro ‘MYTEST’ > > 452 | MYTEST(strip_newline_test) > > | ^~ > > arping_test.c:452:8: note: previous declaration of ‘strip_newline_test’ was > > here > > 452 | MYTEST(strip_newline_test) > > |^~ > > arping_test.c:58:31: note: in definition of macro ‘MYTEST’ > >58 | #define MYTEST(a) static void a(int);__attribute__((constructor)) \ > > | ^ > > In file included from arping_test.c:29: > > arping_test.c:472:8: error: ‘get_mac_addr_success’ redeclared as different > > kind of symbol > > 472 | MYTEST(get_mac_addr_success) > > |^~~~ > > arping_test.c:472:1: note: in expansion of macro ‘MYTEST’ > > 472 | MYTEST(get_mac_addr_success) > > | ^~ > > arping_test.c:472:8: note: previous declaration of ‘get_mac_addr_success’ > > was here > > 472 |
Bug#980326: mutt: diff for NMU version 2.0.2-1.1
On Wed, Jan 20, 2021 at 10:31:54AM -0800, Kevin J. McCarthy wrote: > On Tue, Jan 19, 2021 at 08:47:01PM +0100, Antonio Radici wrote: > > Thanks for the patch, I will upgrade to the latest upstream version by > > Sunday > > this week > > Antonio, if it helps, I can try to get a 2.0.5 release out before the > weekend. Hi Kevin, yes that will definitely help so we will get additional commits that are not yet in 2.0.4. If you can't make it by the weekend I should be able to find some time on Mon/Tue to do the upload!
Bug#980645: leiningen-clojure: FTBFS: Cannot access central (https://repo1.maven.org/maven2/) in offline mode and the artifact org.slf4j:slf4j-nop:jar:1.7.25 has not been downloaded from it before.
On 2021-01-20 12:58, Lucas Nussbaum wrote: Source: leiningen-clojure Version: 2.9.1-3 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): make[1]: Entering directory '/<>' cd leiningen-core && lein bootstrap Leiningen's classpath: :/usr/share/java/leiningen-2.9.1.jar Applying task [with-profile base do install, classpath .lein-bootstrap] to [] Applying task do to (install, classpath .lein-bootstrap) Applying task install to [] Cannot access central (https://repo1.maven.org/maven2/) in offline mode and the artifact org.slf4j:slf4j-nop:jar:1.7.25 has not been downloaded from it before. Cannot access clojars (https://repo.clojars.org/) in offline mode and the artifact org.slf4j:slf4j-nop:jar:1.7.25 has not been downloaded from it before. Thanks, I'll TAL, probably this weekend at the latest... - e
Bug#980423: 3.12.4 makes several packages FTBFS
Control: clone -1 -2 -3 Control: reassign -2 src:ignition-msgs 5.1.0+dfsg-6 Control: retitle -2 tighten dependencies on libprotobuf-dev Control: reassign -3 src:ignition-transport 8.0.0+dfsg-3 Control: retitle -3 tighten dependencies on libprotobuf-dev On 2021-01-19 00:05:36 +0100, László Böszörményi wrote: > On Mon, Jan 18, 2021 at 10:24 PM Laurent Bigonville wrote: > > Several packages FTBFS since 3.12.4 > > > > The autopkgtest catched ignition-msgs and ignition-transport, see > > https://packages.qa.debian.org/p/protobuf.html > > > > I can see that evolution-data-server also FTBFS > [...] > > This is a bit unfortunate that it's happening so late in the developpement > > cycle. > Indeed, my fault. Investigating. Hope this can be resolved easily. The autopkgtest failures indicate that ignition-msgs' and ignition-transport's dependencies on libprotobuf-dev (>= X.Y), (< X.{Y+1}) is not enough. It will need to be (>= X.Y.Z), (< X.Y.{Z+1}) instead. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#890343: linux: make fq_codel default for default_qdisc
Hi Noah, Le 2021-01-07 16:12, Noah Meyerhans a écrit : > On Thu, Apr 23, 2020 at 03:34:06PM -0700, Matt Taggart wrote: > > #890343 was originally opened against systemd asking to install the upstream > > systemd sysctl.d/50-default.conf file that sets: > > > > net.core.default_qdisc = fq_codel > > > > As explained in #950701 (and the systemd debian changelog) the debian > > systemd maintainers felt that systemd in debian should not be changing > > kernel policies (and I agree). > > So #890343 was reassigned to linux to consider changing the default. > > > > fq_codel is better in every way than pfifo_fast and I am unaware of any > > reason why it would not be a better default. (but don't trust me, ask the > > kernel networking experts) > > > > Can we change it? > > I strongly agree that we should make this change for the bullseye > release. > > I'm looking into provding a patch to implement the switch to fq_codel by > default, but it appears to require something more than just a kernel > config change. I have tried the following with the 5.10 kernel from the > current sid branch: > > CONFIG_NET_SCH_FQ_CODEL=m > CONFIG_DEFAULT_FQ_CODEL=y > CONFIG_DEFAULT_NET_SCH="fq_codel" > > Then we don't see any change at all to the qdisc in use: > > admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r) > CONFIG_NET_SCH_FQ_CODEL=m > CONFIG_DEFAULT_FQ_CODEL=y > CONFIG_DEFAULT_NET_SCH="fq_codel" > admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc > net.core.default_qdisc = pfifo_fast > admin@ip-10-0-0-162:~$ tc qdisc show dev ens5 > qdisc mq 0: root > qdisc pfifo_fast 0: parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 > qdisc pfifo_fast 0: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 > admin@ip-10-0-0-162:~$ ip link show dev ens5 > 2: ens5: mtu 9001 qdisc mq state UP mode > DEFAULT group default qlen 1000 > link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff > altname enp0s5 > > If we statically link the fq_codel module into the kernel, then we see: > > admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r) > CONFIG_NET_SCH_FQ_CODEL=y > CONFIG_DEFAULT_FQ_CODEL=y > CONFIG_DEFAULT_NET_SCH="fq_codel" > admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc > net.core.default_qdisc = fq_codel > admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5 > qdisc mq 0: root > qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms > interval 100ms memory_limit 32Mb ecn drop_batch 64 > qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms > interval 100ms memory_limit 32Mb ecn drop_batch 64 > admin@ip-10-0-0-162:~$ ip link show dev ens5 > 2: ens5: mtu 9001 qdisc mq state UP mode > DEFAULT group default qlen 1000 > link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff > altname enp0s5 > > So in this case, we have fq_codel configured, but not as the root > qdisc for the interface. If we manually set it: > > admin@ip-10-0-0-162:~$ sudo /sbin/tc qdisc add root dev ens5 fq_codel > > Then we get the following configuration: > > admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5 > qdisc fq_codel 8001: root refcnt 3 limit 10240p flows 1024 quantum 9015 > target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 > admin@ip-10-0-0-162:~$ ip link show dev ens5 > 2: ens5: mtu 9001 qdisc fq_codel state UP > mode DEFAULT group default qlen 1000 > link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff > altname enp0s5 > > I believe that this is what we want. Is that accurate? > > The recent thread at > https://www.mail-archive.com/netdev@vger.kernel.org/msg380410.html > also seems relevant. I was about to start a thread on the debian-kernel ML about switching from pfifo_fast to FQ_Codel when I stumble across this bug report. My proposal would differ from yours though in that it would not touch the kernel configuration but would instead consist in patching procps to provide a configuration file (let's say default_qdisc.conf) to set the value of the net.core.default_qdisc variable to fq_codel via sysctl. This would allow to benefit from FQ_Codel without depending on a specific Linux version. Opinion? > noah Cheers, Vincent signature.asc Description: PGP signature
Bug#979153: usbutils: No information about hardware database in manpage or documentation
On 2021-01-03 16:23, Peter Rohrer wrote: > Package: usbutils > Version: 1:010-3 > Severity: minor > > Dear Maintainer, > > I recently figured out that updating the usb.ids database does not have any > effect on lsusb, and I realizied that the manpage does no longer refer to the > usb.ids file. > Unfortunately, I could not find any information how to update the database, > other than the information that udev is now used. > After some stracing and grepping I found /lib/udev/hwdb.d/20-usb-vendor- > model.hwdb to be the file most likely used and upgraded udev with the version > from backports. > This solved the problem. > > It would have helped me a lot if there would have been a hint in the manpage > or > in the files in /usr/share/doc/usbutils to update udev to get a more actual > hardware database. This is explained in /usr/share/bug/usbutils/presubj and displayed when using reportbug, but admittedly this is not the usual place where people get a look. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#980713: node-jest: please embed Node.js module jest-tobetype
Source: node-jest Version: 26.6.3+repack+~cs61.38.35-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Upcoming package mediasoup needs jest-tobetype for its testsuite. Please consider embedding jest-tobetype with jest. Severity raised due to the benefits for the upcoming mediasoup package. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmAInrUACgkQLHwxRsGg ASFXpw//QLJgfU5OQc+5BXr9YTDzqAegsoKYW6vsx+BC45Exgzv9cbm1YwWIfWGD YTjUF5aOTa9PgizGZkw4bOHWV9AegmxDxqTp4oQ064Uk2vqX1js+kngHSLBXfsLG tqEyGvmPIUApLacQ4Bjq3XCDe4lT1jliHi564pZanPkI/zkvWLXad5gvYZpgZTxs cnBmBQ9WP4RkZh753x5oeiZsMoey+aAqz/AHyKX60aFdi7NQ7JKP99uP6KUM+rR5 7WT9sXNjceSKYAmxXNAN9JguhiRfsYJtrJKVfii+aDUWrFUdSAathPuNKpBSKmhQ Jlg8283cTt8ZVIX4cCXS/1s9+wb1mMRUJRU4bF4MDRaUpDVxY34Eh0VeHhA/jCzd VW2QH9PociLaeYg0bXXnd0PE0f7Hik9m27AYd7Ar4wd4wft226EW+X3s+BztJ9rd LkbmbmFsH2ptySCygQJzOX2hSd3NjYxhQCOh4sZ5Ibm1+c6VjD1DzBSxhy4BWCCv WCYT/1MOKn5vQ4TsDy0jLecqF3qvVDW/+7Q1VgcOjqcLK8Aa3noos0NtUIi/v00s YRNLzrCpjsCY7LzXIi+CPchHlWdgog6ogC//VnPaPh1CkXcExX8GxUe+TN5STbIA RAsH8cls6XdHBF7XfO+FqtdBGRdsRgIiEv9bxb+48SHJfBzCNmQ= =TpD8 -END PGP SIGNATURE-
Bug#980712: golang-github-dvsekhvalnov-jose2go: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/dvsekhvalnov/jose2go github.com/dvsekhvalnov/jose2go/aes gith
Source: golang-github-dvsekhvalnov-jose2go Version: 1.3-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > debian/rules build > dh build --buildsystem=golang --with=golang > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) >dh_update_autotools_config -O--buildsystem=golang >dh_auto_configure -O--buildsystem=golang > dh_auto_configure: warning: Compatibility levels before 10 are deprecated > (level 9 in use) >dh_auto_build -O--buildsystem=golang > dh_auto_build: warning: Compatibility levels before 10 are deprecated (level > 9 in use) > cd obj-x86_64-linux-gnu && go install -trimpath -v -p 1 > github.com/dvsekhvalnov/jose2go github.com/dvsekhvalnov/jose2go/aes > github.com/dvsekhvalnov/jose2go/arrays > github.com/dvsekhvalnov/jose2go/base64url > github.com/dvsekhvalnov/jose2go/compact github.com/dvsekhvalnov/jose2go/kdf > github.com/dvsekhvalnov/jose2go/keys/ecc > github.com/dvsekhvalnov/jose2go/keys/rsa > github.com/dvsekhvalnov/jose2go/padding > internal/unsafeheader > internal/cpu > internal/bytealg > runtime/internal/atomic > runtime/internal/sys > runtime/internal/math > runtime > internal/reflectlite > errors > internal/race > sync/atomic > sync > io > unicode > unicode/utf8 > bytes > strings > bufio > math/bits > math > strconv > reflect > sort > internal/fmtsort > internal/oserror > syscall > internal/syscall/unix > time > internal/poll > internal/syscall/execenv > internal/testlog > os > fmt > compress/flate > hash > crypto > crypto/internal/subtle > crypto/subtle > encoding/binary > crypto/cipher > crypto/aes > math/rand > math/big > crypto/elliptic > crypto/internal/randutil > crypto/sha512 > unicode/utf16 > encoding/asn1 > vendor/golang.org/x/crypto/cryptobyte/asn1 > vendor/golang.org/x/crypto/cryptobyte > crypto/ecdsa > crypto/hmac > crypto/rand > crypto/rsa > crypto/sha1 > crypto/sha256 > encoding > encoding/base64 > encoding/json > github.com/dvsekhvalnov/jose2go/base64url > github.com/dvsekhvalnov/jose2go/arrays > github.com/dvsekhvalnov/jose2go/aes > github.com/dvsekhvalnov/jose2go/compact > github.com/dvsekhvalnov/jose2go/kdf > crypto/des > crypto/dsa > crypto/ed25519/internal/edwards25519 > crypto/ed25519 > crypto/md5 > encoding/hex > crypto/x509/pkix > encoding/pem > path/filepath > io/ioutil > context > vendor/golang.org/x/net/dns/dnsmessage > internal/nettrace > internal/singleflight > runtime/cgo > net > net/url > crypto/x509 > github.com/dvsekhvalnov/jose2go/keys/ecc > github.com/dvsekhvalnov/jose2go/padding > github.com/dvsekhvalnov/jose2go > github.com/dvsekhvalnov/jose2go/keys/rsa >dh_auto_test -O--buildsystem=golang > dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 > in use) > cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 > github.com/dvsekhvalnov/jose2go github.com/dvsekhvalnov/jose2go/aes > github.com/dvsekhvalnov/jose2go/arrays > github.com/dvsekhvalnov/jose2go/base64url > github.com/dvsekhvalnov/jose2go/compact github.com/dvsekhvalnov/jose2go/kdf > github.com/dvsekhvalnov/jose2go/keys/ecc > github.com/dvsekhvalnov/jose2go/keys/rsa > github.com/dvsekhvalnov/jose2go/padding > === RUN Test > > invalid sign 'alg' header err= jwt.Decode(): required 'alg' header is missing > or of invalid type > > missing sign 'alg' header err= jwt.Decode(): required 'alg' header is missing > or of invalid type > > two phased err= Test error > > invalid encrypt 'alg' header err= jwt.Decode(): required 'alg' header is > missing or of invalid type > > invalid encrypt 'enc' header err= jwt.Decode(): required 'enc' header is > missing or of invalid type > > missing encrypt 'alg' header err= jwt.Decode(): required 'alg' header is > missing or of invalid type > > missing encrypt 'enc' header err= jwt.Decode(): required 'enc' header is > missing or of invalid type > > -- > FAIL: jose_test.go:1588: > TestSuite.TestDecrypt_PBSE2_HS256_A128KW_A128CBC_HS256 > > jose_test.go:1596: > //then > c.Assert(err, IsNil) > ... value *errors.errorString = &errors.errorString{s:"aes.KeyUnwrap(): > integrity check failed."} ("aes.KeyUnwrap(): integrity
Bug#980558: libqmi: A source-only upload is needed for testing migration
On 2021-01-20 09:42, Boyuan Yang wrote: > According to https://tracker.debian.org/pkg/libqmi , the latest upload > of package libqmi was not a source-only upload. That was accidental. Thanks for noticing!
Bug#980711: gpaw: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 --test-pytest "--test-args=-v -m ci" returned exit code 13
Source: gpaw Version: 20.10.0-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_auto_test -- --test-pytest --test-args="-v -m ci" > I: pybuild base:232: cd /<>/.pybuild/cpython3_3.9/build; > python3.9 -m pytest -v -m ci > = test session starts > == > platform linux -- Python 3.9.1+, pytest-6.0.2, py-1.10.0, pluggy-0.13.0 -- > /usr/bin/python3.9 > cachedir: .pytest_cache > rootdir: /<>, configfile: pytest.ini > collecting ... collected 0 items / 1 error > > ERRORS > > ERROR collecting test session > _ > /usr/lib/python3.9/importlib/__init__.py:127: in import_module > return _bootstrap._gcd_import(name[level:], package, level) > :1030: in _gcd_import > ??? > :1007: in _find_and_load > ??? > :972: in _find_and_load_unlocked > ??? > :228: in _call_with_frames_removed > ??? > :1030: in _gcd_import > ??? > :1007: in _find_and_load > ??? > :972: in _find_and_load_unlocked > ??? > :228: in _call_with_frames_removed > ??? > :1030: in _gcd_import > ??? > :1007: in _find_and_load > ??? > :986: in _find_and_load_unlocked > ??? > :680: in _load_unlocked > ??? > :790: in exec_module > ??? > :228: in _call_with_frames_removed > ??? > gpaw/__init__.py:35: in > from ase.cli.run import str2dict > gpaw/broadcast_imports.py:77: in load_module > return self.load_from_cache(fullname) > gpaw/broadcast_imports.py:87: in load_from_cache > exec(code, module.__dict__) > /usr/lib/python3/dist-packages/ase/cli/run.py:9: in > from ase.eos import EquationOfState > gpaw/broadcast_imports.py:77: in load_module > return self.load_from_cache(fullname) > gpaw/broadcast_imports.py:87: in load_from_cache > exec(code, module.__dict__) > /usr/lib/python3/dist-packages/ase/eos.py:7: in > from scipy.optimize import curve_fit > gpaw/broadcast_imports.py:77: in load_module > return self.load_from_cache(fullname) > gpaw/broadcast_imports.py:87: in load_from_cache > exec(code, module.__dict__) > /usr/lib/python3/dist-packages/scipy/optimize/__init__.py:413: in > from ._linprog import linprog, linprog_verbose_callback > gpaw/broadcast_imports.py:77: in load_module > return self.load_from_cache(fullname) > gpaw/broadcast_imports.py:87: in load_from_cache > exec(code, module.__dict__) > /usr/lib/python3/dist-packages/scipy/optimize/_linprog.py:25: in > from ._linprog_highs import _linprog_highs > gpaw/broadcast_imports.py:77: in load_module > return self.load_from_cache(fullname) > gpaw/broadcast_imports.py:87: in load_from_cache > exec(code, module.__dict__) > /usr/lib/python3/dist-packages/scipy/optimize/_linprog_highs.py:20: in > > from ._highs.highs_wrapper import highs_wrapper > gpaw/broadcast_imports.py:109: in find_spec > raise ImportError > E ImportError > === short test summary info > > ERROR ../../.. - ImportError > Interrupted: 1 error during collection > > === 1 error in 0.58s > === > E: pybuild pybuild:353: test: plugin distutils failed with: exit code=2: cd > /<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest -v -m ci > dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 > --test-pytest "--test-args=-v -m ci" returned exit code 13 The full build log is available from: http://qa-logs.debian.net/2021/01/20/gpaw_20.10.0-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980709: dolfin: FTBFS: tests failed
Source: dolfin Version: 2019.2.0~git20200629.946dbd3+lfs-4 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[8]: Entering directory '/<>/obj-x86_64-linux-gnu' > [ 98%] Building CXX object > demo/undocumented/waveguide/cpp/CMakeFiles/demo_waveguide.dir/main.cpp.o > cd "/<>/obj-x86_64-linux-gnu/demo/undocumented/waveguide/cpp" && > /usr/bin/c++ -DDOLFIN_VERSION=\"2019.2.0.dev0\" -DHAS_CHOLMOD -DHAS_HDF5 > -DHAS_MPI -DHAS_PETSC -DHAS_SCOTCH -DHAS_UMFPACK -DHAS_ZLIB -DNDEBUG > -I"/<>" -I"/<>/dolfin" > -I"/<>/obj-x86_64-linux-gnu" -isystem > /usr/lib/python3/dist-packages/ffc/backends/ufc -isystem /usr/include/eigen3 > -isystem /usr/include/hdf5/openmpi -isystem > /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem > /usr/lib/x86_64-linux-gnu/openmpi/include -isystem > /usr/lib/petscdir/petsc3.14/x86_64-linux-gnu-real/include -Wno-comment > -fpermissive -O2 -g -DNDEBUG -std=c++11 -o > CMakeFiles/demo_waveguide.dir/main.cpp.o -c > "/<>/demo/undocumented/waveguide/cpp/main.cpp" > [ 98%] Linking CXX executable demo_spatial-coordinates > cd > "/<>/obj-x86_64-linux-gnu/demo/undocumented/spatial-coordinates/cpp" > && /usr/bin/cmake -E cmake_link_script > CMakeFiles/demo_spatial-coordinates.dir/link.txt --verbose=1 > /usr/bin/c++ -Wno-comment -fpermissive -O2 -g -DNDEBUG -Wl,-z,relro > CMakeFiles/demo_spatial-coordinates.dir/main.cpp.o -o > demo_spatial-coordinates ../../../../dolfin/libdolfin.so.2019.2.0.dev0 > /usr/lib/x86_64-linux-gnu/libboost_timer.so > /usr/lib/x86_64-linux-gnu/libboost_chrono.so > /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so > /usr/lib/x86_64-linux-gnu/libsz.so /usr/lib/x86_64-linux-gnu/libz.so > /usr/lib/x86_64-linux-gnu/libdl.so -lm > /usr/lib/petscdir/petsc3.14/x86_64-linux-gnu-real/lib/libpetsc_real.so > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so > make[8]: Leaving directory '/<>/obj-x86_64-linux-gnu' > [ 98%] Built target demo_spatial-coordinates > [ 98%] Linking CXX executable demo_waveguide > cd "/<>/obj-x86_64-linux-gnu/demo/undocumented/waveguide/cpp" && > /usr/bin/cmake -E cmake_link_script CMakeFiles/demo_waveguide.dir/link.txt > --verbose=1 > /usr/bin/c++ -Wno-comment -fpermissive -O2 -g -DNDEBUG -Wl,-z,relro > CMakeFiles/demo_waveguide.dir/main.cpp.o -o demo_waveguide > ../../../../dolfin/libdolfin.so.2019.2.0.dev0 > /usr/lib/x86_64-linux-gnu/libboost_timer.so > /usr/lib/x86_64-linux-gnu/libboost_chrono.so > /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so > /usr/lib/x86_64-linux-gnu/libsz.so /usr/lib/x86_64-linux-gnu/libz.so > /usr/lib/x86_64-linux-gnu/libdl.so -lm > /usr/lib/petscdir/petsc3.14/x86_64-linux-gnu-real/lib/libpetsc_real.so > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so > make[8]: Leaving directory '/<>/obj-x86_64-linux-gnu' > [ 98%] Built target demo_waveguide > [100%] Linking CXX executable demo_sym-dirichlet-bc > cd > "/<>/obj-x86_64-linux-gnu/demo/undocumented/sym-dirichlet-bc/cpp" > && /usr/bin/cmake -E cmake_link_script > CMakeFiles/demo_sym-dirichlet-bc.dir/link.txt --verbose=1 > /usr/bin/c++ -Wno-comment -fpermissive -O2 -g -DNDEBUG -Wl,-z,relro > CMakeFiles/demo_sym-dirichlet-bc.dir/main.cpp.o -o demo_sym-dirichlet-bc > ../../../../dolfin/libdolfin.so.2019.2.0.dev0 > /usr/lib/x86_64-linux-gnu/libboost_timer.so > /usr/lib/x86_64-linux-gnu/libboost_chrono.so > /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so > /usr/lib/x86_64-linux-gnu/libsz.so /usr/lib/x86_64-linux-gnu/libz.so > /usr/lib/x86_64-linux-gnu/libdl.so -lm > /usr/lib/petscdir/petsc3.14/x86_64-linux-gnu-real/lib/libpetsc_real.so > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so > /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so > make[8]: Leaving directory '/<>/obj-x86_64-linux-gnu' > [100%] Built target demo_sym-dirichlet-bc > [100%] Linking CXX executable demo_time-series > cd "/<>/obj-x86_64-linux-gnu/demo/undocumented/time-series/cpp" > && /usr/bin/cmake -E cmake_link_script > CMakeFiles/demo_time-series.dir/link.txt --verbose=1 > /usr/bin/c++ -Wno-comment -fpermissive -O2 -g -DNDEBUG -Wl,-z,relro > CMakeFiles/demo_time-series.dir/main.cpp.o -o demo_time-series > ../../../../dolfin/libdolfin.so.2019.2.0.dev0 > /usr/lib/x86_64-linux-gnu/li
Bug#980710: mpi4py: FTBFS: ld: cannot find -llmpe
Source: mpi4py Version: 3.0.3-7 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_auto_build override_dh_auto_build-arch -- \ > --build-args "--mpicc=/usr/bin/mpicc --mpicxx=/usr/bin/mpicxx" > I: pybuild base:232: /usr/bin/python3 setup.py build --mpicc=/usr/bin/mpicc > --mpicxx=/usr/bin/mpicxx > running build > running build_src > running build_py > creating /<>/.pybuild/cpython3_3.9/build/mpi4py > copying src/mpi4py/bench.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py > copying src/mpi4py/__init__.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py > copying src/mpi4py/__main__.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py > copying src/mpi4py/run.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py > creating /<>/.pybuild/cpython3_3.9/build/mpi4py/futures > copying src/mpi4py/futures/__init__.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/futures > copying src/mpi4py/futures/__main__.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/futures > copying src/mpi4py/futures/_base.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/futures > copying src/mpi4py/futures/pool.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/futures > copying src/mpi4py/futures/aplus.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/futures > copying src/mpi4py/futures/_lib.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/futures > copying src/mpi4py/futures/server.py -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/futures > copying src/mpi4py/libmpi.pxd -> > /<>/.pybuild/cpython3_3.9/build/mpi4py > copying src/mpi4py/__init__.pxd -> > /<>/.pybuild/cpython3_3.9/build/mpi4py > copying src/mpi4py/MPI.pxd -> > /<>/.pybuild/cpython3_3.9/build/mpi4py > creating /<>/.pybuild/cpython3_3.9/build/mpi4py/include > creating /<>/.pybuild/cpython3_3.9/build/mpi4py/include/mpi4py > copying src/mpi4py/include/mpi4py/mpi4py.h -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/include/mpi4py > copying src/mpi4py/include/mpi4py/mpi4py.MPI_api.h -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/include/mpi4py > copying src/mpi4py/include/mpi4py/mpi4py.MPI.h -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/include/mpi4py > copying src/mpi4py/include/mpi4py/mpi4py.i -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/include/mpi4py > copying src/mpi4py/include/mpi4py/mpi.pxi -> > /<>/.pybuild/cpython3_3.9/build/mpi4py/include/mpi4py > running build_clib > MPI configuration: [mpi] from 'mpi.cfg' > MPI C compiler:/usr/bin/mpicc > MPI C++ compiler: /usr/bin/mpicxx > checking for library 'lmpe' ... > /usr/bin/mpicc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv > -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g > -fwrapv -O2 -g -O2 -ffile-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -fPIC -c _configtest.c -o _configtest.o > /usr/bin/mpicc -pthread -Wl,-z,relro -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 _configtest.o -llmpe > -o _configtest > /usr/bin/ld: cannot find -llmpe > collect2: error: ld returned 1 exit status The full build log is available from: http://qa-logs.debian.net/2021/01/20/mpi4py_3.0.3-7_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980708: trapperkeeper-scheduler-clojure: FTBFS: Cannot access central (https://repo1.maven.org/maven2/) in offline mode and the artifact com.fasterxml.jackson.core:jackson-core:jar:debian has not
Source: trapperkeeper-scheduler-clojure Version: 1.1.3-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > lein pom debian/pom.xml > Cannot access central (https://repo1.maven.org/maven2/) in offline mode and > the artifact com.fasterxml.jackson.core:jackson-core:jar:debian has not been > downloaded from it before. > Cannot access clojars (https://repo.clojars.org/) in offline mode and the > artifact com.fasterxml.jackson.core:jackson-core:jar:debian has not been > downloaded from it before. > Cannot access central (https://repo1.maven.org/maven2/) in offline mode and > the artifact > com.fasterxml.jackson.dataformat:jackson-dataformat-smile:jar:debian has not > been downloaded from it before. > Cannot access clojars (https://repo.clojars.org/) in offline mode and the > artifact com.fasterxml.jackson.dataformat:jackson-dataformat-smile:jar:debian > has not been downloaded from it before. > Cannot access central (https://repo1.maven.org/maven2/) in offline mode and > the artifact > com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:jar:debian has not > been downloaded from it before. > Cannot access clojars (https://repo.clojars.org/) in offline mode and the > artifact com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:jar:debian > has not been downloaded from it before. > This could be due to a typo in :dependencies, file system permissions, or > network issues. > If you are behind a proxy, try setting the 'http_proxy' environment variable. > make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1 The full build log is available from: http://qa-logs.debian.net/2021/01/20/trapperkeeper-scheduler-clojure_1.1.3-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980706: golang-github-cznic-ql: FTBFS: expects import "modernc.org/mathutil"
Source: golang-github-cznic-ql Version: 1.0.6-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > debian/rules build > dh build --buildsystem=golang --with=golang --builddirectory=_build > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) >dh_update_autotools_config -O--buildsystem=golang -O--builddirectory=_build >dh_auto_configure -O--buildsystem=golang -O--builddirectory=_build > dh_auto_configure: warning: Compatibility levels before 10 are deprecated > (level 9 in use) >dh_auto_build -O--buildsystem=golang -O--builddirectory=_build > dh_auto_build: warning: Compatibility levels before 10 are deprecated (level > 9 in use) > cd _build && go install -trimpath -v -p 1 github.com/cznic/ql > github.com/cznic/ql/design github.com/cznic/ql/driver github.com/cznic/ql/ql > github.com/cznic/ql/vendored/github.com/camlistore/go4/lock > src/github.com/cznic/lldb/2pc.go:16:2: code in directory > /<>/_build/src/github.com/cznic/fileutil expects import > "modernc.org/fileutil" > src/github.com/cznic/lldb/2pc.go:17:2: code in directory > /<>/_build/src/github.com/cznic/mathutil expects import > "modernc.org/mathutil" > dh_auto_build: error: cd _build && go install -trimpath -v -p 1 > github.com/cznic/ql github.com/cznic/ql/design github.com/cznic/ql/driver > github.com/cznic/ql/ql > github.com/cznic/ql/vendored/github.com/camlistore/go4/lock returned exit > code 1 > make: *** [debian/rules:7: build] Error 25 The full build log is available from: http://qa-logs.debian.net/2021/01/20/golang-github-cznic-ql_1.0.6-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980699: grcompiler: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j4 test ARGS\+=-j4 returned exit code 2
Source: grcompiler Version: 5.2-2.1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>/obj-x86_64-linux-gnu' > Running tests... > /usr/bin/ctest --force-new-ctest-process -j4 > Test project /<>/obj-x86_64-linux-gnu > Start 1: compile_SchTest > Start 4: compile_CharisTest > Start 7: compile_PigLatinTest_v2 > Start 10: compile_PigLatinTest_v3 > 1/15 Test #7: compile_PigLatinTest_v2 . Passed0.03 sec > Start 13: compile_PadaukTest_v3 > 2/15 Test #10: compile_PigLatinTest_v3 . Passed0.03 sec > Start 8: GrcRegressionTest_PigLatinTest_v2 > 3/15 Test #8: GrcRegressionTest_PigLatinTest_v2 ... Passed0.00 sec > Start 9: compare_PigLatinTest_v2 > 4/15 Test #9: compare_PigLatinTest_v2 .***Failed0.01 sec > Files "PigLatinTest_v2.ttf" to > "/<>/test/GrcRegressionTest/fonts/PigLatinBenchmark_v2.ttf" are > different. > > Start 11: GrcRegressionTest_PigLatinTest_v3 > 5/15 Test #11: GrcRegressionTest_PigLatinTest_v3 ... Passed0.00 sec > Start 12: compare_PigLatinTest_v3 > 6/15 Test #12: compare_PigLatinTest_v3 . Passed0.01 sec > 7/15 Test #13: compile_PadaukTest_v3 ... Passed0.21 sec > Start 14: GrcRegressionTest_PadaukTest_v3 > Start 15: compare_PadaukTest_v3 > 8/15 Test #14: GrcRegressionTest_PadaukTest_v3 . Passed0.00 sec > 9/15 Test #15: compare_PadaukTest_v3 ... Passed0.01 sec > 10/15 Test #1: compile_SchTest . Passed0.31 sec > Start 2: GrcRegressionTest_SchTest > Start 3: compare_SchTest > 11/15 Test #2: GrcRegressionTest_SchTest ... Passed0.00 sec > 12/15 Test #3: compare_SchTest . Passed0.01 sec > 13/15 Test #4: compile_CharisTest .. Passed2.03 sec > Start 5: GrcRegressionTest_CharisTest > Start 6: compare_CharisTest > 14/15 Test #5: GrcRegressionTest_CharisTest Passed0.00 sec > 15/15 Test #6: compare_CharisTest .. Passed0.01 sec > > 93% tests passed, 1 tests failed out of 15 > > Total Test time (real) = 2.04 sec > > The following tests FAILED: > 9 - compare_PigLatinTest_v2 (Failed) > Errors while running CTest > make[1]: *** [Makefile:140: test] Error 8 > make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu' > dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j4 test ARGS\+=-j4 > returned exit code 2 The full build log is available from: http://qa-logs.debian.net/2021/01/20/grcompiler_5.2-2.1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980705: golang-github-cznic-strutil: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/cznic/strutil returned exit code 1
Source: golang-github-cznic-strutil Version: 0.0~git20150430.0.1eb03e3-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > debian/rules build > dh build --buildsystem=golang --with=golang > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) >dh_update_autotools_config -O--buildsystem=golang >dh_auto_configure -O--buildsystem=golang > dh_auto_configure: warning: Compatibility levels before 10 are deprecated > (level 9 in use) >dh_auto_build -O--buildsystem=golang > dh_auto_build: warning: Compatibility levels before 10 are deprecated (level > 9 in use) > cd obj-x86_64-linux-gnu && go install -trimpath -v -p 1 > github.com/cznic/strutil > internal/unsafeheader > internal/cpu > internal/bytealg > runtime/internal/atomic > runtime/internal/sys > runtime/internal/math > runtime > internal/reflectlite > errors > internal/race > sync/atomic > sync > io > unicode > unicode/utf8 > bytes > math/bits > math > strconv > encoding/base32 > reflect > encoding/binary > encoding/base64 > sort > internal/fmtsort > internal/oserror > syscall > internal/syscall/unix > time > internal/poll > internal/syscall/execenv > internal/testlog > os > fmt > strings > github.com/cznic/strutil >dh_auto_test -O--buildsystem=golang > dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 > in use) > cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 > github.com/cznic/strutil > # github.com/cznic/strutil > src/github.com/cznic/strutil/all_test.go:10:2: code in directory > /<>/obj-x86_64-linux-gnu/src/github.com/cznic/mathutil expects > import "modernc.org/mathutil" > FAIL github.com/cznic/strutil [setup failed] > FAIL > dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 > github.com/cznic/strutil returned exit code 1 The full build log is available from: http://qa-logs.debian.net/2021/01/20/golang-github-cznic-strutil_0.0~git20150430.0.1eb03e3-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980704: node-is-reference: FTBFS: Error: Cannot find module '@types/estree'
Source: node-is-reference Version: 1.2.1-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > dpkg-buildpackage > - > > Command: dpkg-buildpackage -us -uc -sa -rfakeroot > dpkg-buildpackage: info: source package node-is-reference > dpkg-buildpackage: info: source version 1.2.1-2 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by Xavier Guimard > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture amd64 > debian/rules clean > dh clean --with nodejs >dh_auto_clean --buildsystem=nodejs > rm -rf ./node_modules/.cache >dh_clean > dpkg-source -b . > dpkg-source: info: using source format '3.0 (quilt)' > dpkg-source: info: building node-is-reference using existing > ./node-is-reference_1.2.1.orig.tar.gz > dpkg-source: info: building node-is-reference in > node-is-reference_1.2.1-2.debian.tar.xz > dpkg-source: info: building node-is-reference in node-is-reference_1.2.1-2.dsc > debian/rules binary > dh binary --with nodejs >dh_update_autotools_config >dh_autoreconf >dh_auto_configure --buildsystem=nodejs > mkdir node_modules > internal/modules/cjs/loader.js:818 > throw err; > ^ > > Error: Cannot find module '@types/estree' > Require stack: > - /<>/[eval] > at Function.Module._resolveFilename > (internal/modules/cjs/loader.js:815:15) > at Function.resolve (internal/modules/cjs/helpers.js:80:19) > at [eval]:1:21 > at Script.runInThisContext (vm.js:120:18) > at Object.runInThisContext (vm.js:309:38) > at Object. ([eval]-wrapper:10:26) > at Module._compile (internal/modules/cjs/loader.js:999:30) > at evalScript (internal/process/execution.js:94:25) > at internal/main/eval_string.js:23:3 { > code: 'MODULE_NOT_FOUND', > requireStack: [ '/<>/[eval]' ] > } > ### @types/estree is required by debian/nodejs/./extlinks but not available > make: *** [debian/rules:4: binary] Error 1 The full build log is available from: http://qa-logs.debian.net/2021/01/20/node-is-reference_1.2.1-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980702: node-nodemailer: FTBFS: dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 3
Source: node-nodemailer Version: 6.4.17-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > dpkg-buildpackage > - > > Command: dpkg-buildpackage -us -uc -sa -rfakeroot > dpkg-buildpackage: info: source package node-nodemailer > dpkg-buildpackage: info: source version 6.4.17-1 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by Xavier Guimard > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture amd64 > debian/rules clean > dh clean >dh_auto_clean --buildsystem=nodejs > rm -rf ./node_modules/.cache >dh_clean > dpkg-source -b . > dpkg-source: info: using source format '3.0 (quilt)' > dpkg-source: info: building node-nodemailer using existing > ./node-nodemailer_6.4.17.orig.tar.gz > dpkg-source: info: building node-nodemailer in > node-nodemailer_6.4.17-1.debian.tar.xz > dpkg-source: info: building node-nodemailer in node-nodemailer_6.4.17-1.dsc > debian/rules binary > dh binary >dh_update_autotools_config >dh_autoreconf >dh_auto_configure --buildsystem=nodejs >dh_auto_build --buildsystem=nodejs > No build command found, searching known files > cd ./. && grunt > Can't exec "grunt": No such file or directory at > /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 522. > dh_auto_build: warning: ### Command "grunt" failed in . > > dh_auto_build: warning: > > 1 failures, unable to build automatically. > Install a debian/nodejs/./build or add a "override_dh_auto_build:" target > in debian/rules > > > dh_auto_build: warning: Aborting auto_build > > Command "grunt" succeeded in . >dh_auto_test --buildsystem=nodejs > mkdir -p node_modules > ln -s ../debian/tests/test_modules/libbase64 node_modules/libbase64 > ln -s ../debian/tests/test_modules/base32.js node_modules/base32.js > ln -s ../debian/tests/test_modules/libmime node_modules/libmime > ln -s ../debian/tests/test_modules/proxy-test-server > node_modules/proxy-test-server > ln -s ../debian/tests/test_modules/libqp node_modules/libqp > ln -s ../debian/tests/test_modules/safer-buffer > node_modules/safer-buffer > ln -s ../debian/tests/test_modules/proxy node_modules/proxy > ln -s ../debian/tests/test_modules/ipv6-normalize > node_modules/ipv6-normalize > ln -s ../debian/tests/test_modules/smtp-server node_modules/smtp-server > ln -s ../. node_modules/nodemailer > /bin/sh -ex debian/tests/pkg-js/test > + set -e > + ln -s .. node_modules/nodemailer > ln: failed to create symbolic link 'node_modules/nodemailer/..': File exists > + true > + mocha --timeout 5 test/addressparser/addressparser-test.js > test/base64/base64-test.js test/dkim/dkim-test.js > test/dkim/message-parser-test.js test/dkim/relaxed-body-test.js > test/dkim/sign-test.js test/fetch/cookies-test.js test/fetch/fetch-test.js > test/json-transport/json-transport-test.js > test/mail-composer/mail-composer-test.js test/mime-funcs/mime-funcs-test.js > test/mime-funcs/mime-types-test.js test/mime-node/mime-node-test.js > test/qp/qp-test.js test/sendmail/le-windows-test.js > test/sendmail/sendmail-test.js test/ses-transport/ses-transport-test.js > test/shared/shared-test.js test/smtp-connection/http-proxy-client-test.js > test/smtp-connection/smtp-connection-test.js test/smtp-pool/smtp-pool-test.js > test/smtp-transport/smtp-tranport-test.js > test/stream-transport/stream-transport-test.js > test/well-known/well-known-test.js test/xoauth2/xoauth2-test.js > > > #addressparser > ✓ should handle single address correctly > ✓ should handle multiple addresses correctly > ✓ should handle unquoted name correctly > ✓ should handle quoted name correctly > ✓ should handle quoted semicolons correctly > ✓ should handle unquoted name, unquoted address correctly > ✓ should handle emtpy group correctly > ✓ should handle address group correctly > ✓ should handle semicolon as a delimiter > ✓ should handle mixed group correctly > ✓ should flatten mixed group correctly > ✓ semicolon as delimiter should not break group parsing > ✓ should handle name from comment correctly > ✓ should handle skip comment correctly > ✓ should handle missing address correctly &
Bug#980697: borgmatic: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Source: borgmatic Version: 1.5.12-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_clean > rm -rf borgmatic.egg-info > for man in borgmatic generate-borgmatic-config upgrade-borgmatic-config > validate-borgmatic-config ; do \ > [ ! -f debian/$man.1 ] || rm debian/$man.1 ; \ > done > make[1]: Leaving directory '/<>' > dpkg-source -b . > dpkg-source: info: using source format '3.0 (quilt)' > dpkg-source: info: building borgmatic using existing > ./borgmatic_1.5.12.orig.tar.gz > dpkg-source: info: using patch list from debian/patches/series > dpkg-source: info: building borgmatic in borgmatic_1.5.12-1.debian.tar.xz > dpkg-source: info: building borgmatic in borgmatic_1.5.12-1.dsc > debian/rules binary > dh binary --with python3 --buildsystem=pybuild >dh_update_autotools_config -O--buildsystem=pybuild >dh_autoreconf -O--buildsystem=pybuild >dh_auto_configure -O--buildsystem=pybuild > I: pybuild base:232: python3.9 setup.py config > running config >dh_auto_build -O--buildsystem=pybuild > I: pybuild base:232: /usr/bin/python3 setup.py build > running build > running build_py > creating /<>/.pybuild/cpython3_3.9/build/borgmatic > copying borgmatic/execute.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic > copying borgmatic/__init__.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic > copying borgmatic/verbosity.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic > copying borgmatic/logger.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic > copying borgmatic/signals.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic > creating /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/healthchecks.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/__init__.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/cronitor.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/command.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/dispatch.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/postgresql.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/monitor.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/cronhub.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/mysql.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/pagerduty.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > copying borgmatic/hooks/dump.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/hooks > creating /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/validate.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/convert.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/__init__.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/override.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/load.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/legacy.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/normalize.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/collect.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/generate.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > copying borgmatic/config/checks.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/config > creating /<>/.pybuild/cpython3_3.9/build/borgmatic/commands > copying borgmatic/commands/__init__.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/commands > copying borgmatic/commands/borgmatic.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/commands > copying borgmatic/commands/generate_config.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/commands > copying borgmatic/commands/arguments.py -> > /<>/.pybuild/cpython3_3.9/build/borgmatic/commands > copying borgmatic/commands/validate_config.py -> > /<>/.pybuild/cp
Bug#980698: golang-github-cznic-sortutil: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/cznic/sortutil returned exit code 1
Source: golang-github-cznic-sortutil Version: 0.0~git20150617.0.4c73428-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > debian/rules build > dh build --buildsystem=golang --with=golang > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) >dh_update_autotools_config -O--buildsystem=golang >dh_auto_configure -O--buildsystem=golang > dh_auto_configure: warning: Compatibility levels before 10 are deprecated > (level 9 in use) >dh_auto_build -O--buildsystem=golang > dh_auto_build: warning: Compatibility levels before 10 are deprecated (level > 9 in use) > cd obj-x86_64-linux-gnu && go install -trimpath -v -p 1 > github.com/cznic/sortutil > internal/unsafeheader > internal/cpu > internal/bytealg > runtime/internal/atomic > runtime/internal/sys > runtime/internal/math > runtime > internal/reflectlite > errors > internal/race > sync/atomic > sync > io > unicode > unicode/utf8 > bytes > math/bits > math > strconv > reflect > encoding/binary > sort > internal/fmtsort > internal/oserror > syscall > internal/syscall/unix > time > internal/poll > internal/syscall/execenv > internal/testlog > os > fmt > math/rand > strings > math/big > github.com/cznic/sortutil >dh_auto_test -O--buildsystem=golang > dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 > in use) > cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 > github.com/cznic/sortutil > # github.com/cznic/sortutil > src/github.com/cznic/sortutil/all_test.go:17:2: code in directory > /<>/obj-x86_64-linux-gnu/src/github.com/cznic/mathutil expects > import "modernc.org/mathutil" > FAIL github.com/cznic/sortutil [setup failed] > FAIL > dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 > github.com/cznic/sortutil returned exit code 1 The full build log is available from: http://qa-logs.debian.net/2021/01/20/golang-github-cznic-sortutil_0.0~git20150617.0.4c73428-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980696: ceres-solver: FTBFS: make[3]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libunwind.so', needed by 'bin/visibility_based_preconditioner_test'. Stop.
Source: ceres-solver Version: 1.14.0-13 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[3]: Entering directory '/<>/obj-x86_64-linux-gnu' > make[3]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libunwind.so', > needed by 'bin/visibility_based_preconditioner_test'. Stop. > make[3]: *** Waiting for unfinished jobs > [ 39%] Building CXX object > internal/ceres/CMakeFiles/visibility_based_preconditioner_test.dir/visibility_based_preconditioner_test.cc.o > cd /<>/obj-x86_64-linux-gnu/internal/ceres && /usr/bin/c++ > -DCERES_CXSPARSE_VERSION=\"3.2.0\" -DCERES_GFLAGS_NAMESPACE=google > -DCERES_SUITESPARSE_VERSION=\"5.8.1\" -DGFLAGS_IS_A_DLL=0 > -DGOOGLE_GLOG_DLL_DECL="" -DGOOGLE_GLOG_DLL_DECL_FOR_UNITTESTS="" > -I/<>/obj-x86_64-linux-gnu/config -I/<>/include > -I/<>/internal -I/<>/internal/ceres > -I/usr/include/suitesparse -isystem /usr/include/eigen3 -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fopenmp > -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter > -Wno-missing-field-initializers -O3 -DNDEBUG -o > CMakeFiles/visibility_based_preconditioner_test.dir/visibility_based_preconditioner_test.cc.o > -c /<>/internal/ceres/visibility_based_preconditioner_test.cc > make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' > make[2]: *** [CMakeFiles/Makefile2:501: > internal/ceres/CMakeFiles/thread_pool_test.dir/all] Error 2 The full build log is available from: http://qa-logs.debian.net/2021/01/20/ceres-solver_1.14.0-13_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980694: sfepy: FTBFS: Signal: Aborted (6)
Source: sfepy Version: 2019.4-2.1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[3]: Entering directory '/<>/doc' > PYTHONPATH=.. sphinx-build -b html -d _build/doctrees . _build/html > Running Sphinx v3.4.3 > making output directory... done > building [mo]: targets for 0 po files that are out of date > building [html]: targets for 230 source files that are out of date > updating environment: [new config] 232 added, 0 changed, 0 removed > reading sources... [ 0%] archived_news > reading sources... [ 0%] archived_support > reading sources... [ 1%] developer_guide > reading sources... [ 1%] development > reading sources... [ 2%] downloads > reading sources... [ 2%] ebcs_implementation > reading sources... [ 3%] examples > reading sources... [ 3%] index > reading sources... [ 3%] installation > reading sources... [ 4%] introduction > reading sources... [ 4%] license > reading sources... [ 5%] linear_combination_bc > reading sources... [ 5%] manpages > reading sources... [ 6%] mat_optim > reading sources... [ 6%] mat_optim/homogenization_opt_src > reading sources... [ 6%] mat_optim/linear_elasticity_opt_src > reading sources... [ 7%] mat_optim/material_opt_src > reading sources... [ 7%] news > reading sources... [ 8%] preprocessing > reading sources... [ 8%] primer > reading sources... [ 9%] problem_desc_file_long > reading sources... [ 9%] release_notes > reading sources... [ 9%] release_tasks > reading sources... [ 10%] solver_table > reading sources... [ 10%] solving_pdes_by_fem > reading sources... [ 11%] splinebox > reading sources... [ 11%] src/build_helpers > reading sources... [ 12%] src/extractor > reading sources... [ 12%] src/homogen > reading sources... [ 12%] src/phonon > A process has executed an operation involving a call > to the fork() system call to create a child process. > > As a result, the libfabric EFA provider is operating in > a condition that could result in memory corruption or > other system errors. > > For the libfabric EFA provider to work safely when fork() > is called, you will need to set the following environment > variable: > RDMAV_FORK_SAFE > > However, setting this environment variable can result in > signficant performance impact to your application due to > increased cost of memory registration. > > You may want to check with your application vendor to see > if an application-level alternative (of not using fork) > exists. > > Your job will now abort. > [ip-172-31-13-40:07422] *** Process received signal *** > [ip-172-31-13-40:07422] Signal: Aborted (6) > [ip-172-31-13-40:07422] Signal code: (-6) > [ip-172-31-13-40:07422] [ 0] > /lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7fc5caa9e140] > [ip-172-31-13-40:07422] [ 1] > /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7fc5ca763ce1] > [ip-172-31-13-40:07422] [ 2] > /lib/x86_64-linux-gnu/libc.so.6(abort+0x123)[0x7fc5ca74d537] > [ip-172-31-13-40:07422] [ 3] > /usr/lib/x86_64-linux-gnu/libfabric.so.1(+0x7c14e)[0x7fc5b930314e] > [ip-172-31-13-40:07422] [ 4] > /lib/x86_64-linux-gnu/libc.so.6(+0x85228)[0x7fc5ca7ad228] > [ip-172-31-13-40:07422] [ 5] > /lib/x86_64-linux-gnu/libc.so.6(__libc_fork+0x20)[0x7fc5ca7f3490] > [ip-172-31-13-40:07422] [ 6] /usr/bin/python3[0x65306b] > [ip-172-31-13-40:07422] [ 7] /usr/bin/python3[0x53f65a] > [ip-172-31-13-40:07422] [ 8] > /usr/bin/python3(_PyObject_MakeTpCall+0x39b)[0x51db7b] > [ip-172-31-13-40:07422] [ 9] > /usr/bin/python3(_PyEval_EvalFrameDefault+0x5b10)[0x5177f0] > [ip-172-31-13-40:07422] [10] /usr/bin/python3[0x511237] > [ip-172-31-13-40:07422] [11] > /usr/bin/python3(_PyFunction_Vectorcall+0x361)[0x529051] > [ip-172-31-13-40:07422] [12] > /usr/bin/python3(_PyEval_EvalFrameDefault+0x701)[0x5123e1] > [ip-172-31-13-40:07422] [13] /usr/bin/python3[0x511237] > [ip-172-31-13-40:07422] [14] > /usr/bin/python3(_PyFunction_Vectorcall+0x361)[0x529051] > [ip-172-31-13-40:07422] [15] /usr/bin/python3[0x537a8e] > [ip-172-31-13-40:07422] [16] /usr/bin/python3[0x51e0bf] > [ip-172-31-13-40:07422] [17] /usr/bin/python3(PyObject_Call+0x129)[0x53c679] > [ip-172-31-13-40:07422] [18] > /usr/bin/python3(_PyEval_EvalFrameDefault+0x23ef)[0x5140cf] > [ip-172-31-13-40:07422] [19] /usr/bin/python3[0x511237] > [ip-172-31-13-40:07422] [20] > /usr/bin/python3(_PyFunction_Vectorcall+0x361)[0x529051] > [ip-172-31-13-40:07422] [21] /usr/bin/python3(PyObject_Call+0xc1)[0x53c611] > [ip-172-31-13-40:07422] [22] > /usr/bin/python3(_PyEval_EvalFrameDefault+0
Bug#980695: tellico: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j1 test XDG_DATA_DIRS=/<>/test_root/usr/share:/usr/local/share:/usr/share HOME=/tmp/tellico-home.OAHYcd T
Source: tellico Version: 3.3.4-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[2]: Entering directory '/<>/obj-x86_64-linux-gnu' > Running tests... > /usr/bin/ctest --force-new-ctest-process -j1 > Test project /<>/obj-x86_64-linux-gnu > Start 1: entitytest > 1/36 Test #1: entitytest ... Passed0.01 sec > Start 2: cuecattest > 2/36 Test #2: cuecattest ... Passed0.01 sec > Start 3: isbntest > 3/36 Test #3: isbntest . Passed0.01 sec > Start 4: lccntest > 4/36 Test #4: lccntest . Passed0.00 sec > Start 5: lcctest > 5/36 Test #5: lcctest .. Passed0.01 sec > Start 6: formattest > 6/36 Test #6: formattest ... Passed0.01 sec > Start 7: fieldtest > 7/36 Test #7: fieldtest Passed0.01 sec > Start 8: imagetest > 8/36 Test #8: imagetest Passed0.02 sec > Start 9: imagejobtest > 9/36 Test #9: imagejobtest . Passed0.03 sec > Start 10: iso6937test > 10/36 Test #10: iso6937test .. Passed0.00 sec > Start 11: iso5426test > 11/36 Test #11: iso5426test .. Passed0.01 sec > Start 12: collectiontest > 12/36 Test #12: collectiontest ... Passed0.61 sec > Start 13: comparisontest > 13/36 Test #13: comparisontest ...***Failed0.02 sec > * Start testing of ComparisonTest * > Config: Using QtTest library 5.15.2, Qt 5.15.2 (x86_64-little_endian-lp64 > shared (dynamic) release build; by GCC 10.2.1 20201207), debian unknown > PASS : ComparisonTest::initTestCase() > PASS : ComparisonTest::testNumber(null) > PASS : ComparisonTest::testNumber(< 0) > PASS : ComparisonTest::testNumber(> 0) > PASS : ComparisonTest::testNumber(=1 1) > PASS : ComparisonTest::testNumber(< 1) > PASS : ComparisonTest::testNumber(> 1) > PASS : ComparisonTest::testNumber(> -1) > PASS : ComparisonTest::testNumber(< -1) > PASS : ComparisonTest::testNumber(> 10) > PASS : ComparisonTest::testNumber(< 10) > PASS : ComparisonTest::testNumber(multiple1) > PASS : ComparisonTest::testNumber(multiple2) > PASS : ComparisonTest::testNumber(multiple3) > PASS : ComparisonTest::testNumber(multiple4) > PASS : ComparisonTest::testNumber(float1) > PASS : ComparisonTest::testNumber(float2) > PASS : ComparisonTest::testNumber(float3) > PASS : ComparisonTest::testNumber(float4) > PASS : ComparisonTest::testLCC(null) > PASS : ComparisonTest::testLCC(null1) > PASS : ComparisonTest::testLCC(null2) > PASS : ComparisonTest::testLCC(test1) > PASS : ComparisonTest::testLCC(test2) > PASS : ComparisonTest::testLCC(test3) > PASS : ComparisonTest::testDate(null) > PASS : ComparisonTest::testDate(null1) > PASS : ComparisonTest::testDate(null2) > PASS : ComparisonTest::testDate(test1) > PASS : ComparisonTest::testDate(test2) > PASS : ComparisonTest::testDate(test3) > PASS : ComparisonTest::testDate(test5) > PASS : ComparisonTest::testDate(words) > FAIL! : ComparisonTest::testDate(words) Compared values are not the same >Actual (comp.compare(string1, string2)): -1 >Expected (res) : 0 >Loc: [/<>/src/tests/comparisontest.cpp(105)] > PASS : ComparisonTest::testTitle(null) > PASS : ComparisonTest::testTitle(null1) > PASS : ComparisonTest::testTitle(null2) > PASS : ComparisonTest::testTitle(test3) > PASS : ComparisonTest::testTitle(test4) > PASS : ComparisonTest::testTitle(test5) > PASS : ComparisonTest::testTitle(test6) > PASS : ComparisonTest::testTitle(test7) > PASS : ComparisonTest::testString(null) > PASS : ComparisonTest::testString(null1) > PASS : ComparisonTest::testString(null2) > PASS : ComparisonTest::testString(test1) > PASS : ComparisonTest::testString(test2) > PASS : ComparisonTest::testBool(null) > PASS : ComparisonTest::testBool(null1) > PASS : ComparisonTest::testBool(null2) > PASS : ComparisonTest::testBool(truetrue) > PASS : ComparisonTest::testBool(truefalse) > PASS : ComparisonTest::testBool(falsetrue) > PASS : ComparisonTest::testChoiceField() > PASS : ComparisonTest::cleanupTestCase() > Totals: 54 passed, 1 failed, 0 skipped, 0 blacklisted, 3ms >
Bug#980692: dask: FTBFS: dh_sphinxdoc: error: debian/python-dask-doc/usr/share/doc/python-dask-doc/html/_static/js/html5shiv.min.js is missing
Source: dask Version: 2.11.0+dfsg-3 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > fakeroot debian/rules binary > dh binary --with python3,sphinxdoc --buildsystem=pybuild >dh_testroot -O--buildsystem=pybuild >dh_prep -O--buildsystem=pybuild >dh_auto_install -O--buildsystem=pybuild > I: pybuild base:232: /usr/bin/python3 setup.py install --root > /<>/debian/python3-dask > running install > running build > running build_py > running egg_info > writing dask.egg-info/PKG-INFO > writing dependency_links to dask.egg-info/dependency_links.txt > writing requirements to dask.egg-info/requires.txt > writing top-level names to dask.egg-info/top_level.txt > reading manifest file 'dask.egg-info/SOURCES.txt' > reading manifest template 'MANIFEST.in' > writing manifest file 'dask.egg-info/SOURCES.txt' > UPDATING /<>/.pybuild/cpython3_3.9_dask/build/dask/_version.py > set /<>/.pybuild/cpython3_3.9_dask/build/dask/_version.py to > '2.11.0+dfsg' > running install_lib > creating /<>/debian/python3-dask > creating /<>/debian/python3-dask/usr > creating /<>/debian/python3-dask/usr/lib > creating /<>/debian/python3-dask/usr/lib/python3.9 > creating /<>/debian/python3-dask/usr/lib/python3.9/dist-packages > creating > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask > copying /<>/.pybuild/cpython3_3.9_dask/build/dask/cache.py -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask > creating > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/diagnostics/profile_visualize.py > -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/diagnostics/profile.py > -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/diagnostics/progress.py > -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/diagnostics/__init__.py > -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics > creating > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics/tests > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/diagnostics/tests/__init__.py > -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics/tests > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/diagnostics/tests/test_progress.py > -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics/tests > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/diagnostics/tests/test_profiler.py > -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/diagnostics/tests > copying /<>/.pybuild/cpython3_3.9_dask/build/dask/distributed.py > -> /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/multiprocessing.py -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask > copying /<>/.pybuild/cpython3_3.9_dask/build/dask/callbacks.py > -> /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask > copying /<>/.pybuild/cpython3_3.9_dask/build/dask/core.py -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask > copying /<>/.pybuild/cpython3_3.9_dask/build/dask/__init__.py -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/compatibility.py -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask > creating > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/bag > copying /<>/.pybuild/cpython3_3.9_dask/build/dask/bag/avro.py -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/bag > copying /<>/.pybuild/cpython3_3.9_dask/build/dask/bag/text.py -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/bag > copying /<>/.pybuild/cpython3_3.9_dask/build/dask/bag/core.py -> > /<>/debian/python3-dask/usr/lib/python3.9/dist-packages/dask/bag > copying > /<>/.pybuild/cpython3_3.9_dask/build/dask/bag/__init__.py -> > /<>/debian/python3-
Bug#980693: felix-latin: FTBFS: latex error
Source: felix-latin Version: 2.0-11.1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[2]: Entering directory '/<>/TeX' > xelatex felix34.tex > This is XeTeX, Version 3.14159265-2.6-0.92 (TeX Live 2020/Debian) > (preloaded format=xelatex) > restricted \write18 enabled. > entering extended mode > (./felix34.tex > LaTeX2e <2020-10-01> patch level 4 > L3 programming layer <2021-01-09> xparse <2020-03-03> > (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls > Document Class: article 2020/04/10 v1.4m Standard LaTeX document class > (/usr/share/texlive/texmf-dist/tex/latex/base/size12.clo)) > (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty > (/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty > (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty > (/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xetex.def > (|extractbb --version)) > Runaway argument? > \q_stop <\__int_eval:w \c_zero_int \__int_eval_end: \exp_after:wN \use_ii:nnn > \ > ETC. > ! File ended while scanning use of \__sys_tmp:w. > > \par > l.148 { \sys_load_backend:n { } } > > ? > ! Emergency stop. > > \par > l.148 { \sys_load_backend:n { } } > > No pages of output. > Transcript written on felix34.log. > make[2]: *** [Makefile:3: tout] Error 1 The full build log is available from: http://qa-logs.debian.net/2021/01/20/felix-latin_2.0-11.1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#980691: gnome-software: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir
Source: gnome-software Version: 3.38.0-3 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_auto_configure -- -Dgnome_desktop=true -Dodrs=true -Dostree=false > -Dpackagekit=true -Dpackagekit_autoremove=true -Drpm_ostree=false > -Dubuntu_reviews=false -Dfwupd=false -Dflatpak=false -Dgudev=false > -Dmalcontent=false -Dvalgrind=false -Dflatpak=true -Dmalcontent=true > -Dgudev=true -Dfwupd=true -Dsnap=true -Dvalgrind=true > cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. > --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc > --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dgnome_desktop=true > -Dodrs=true -Dostree=false -Dpackagekit=true -Dpackagekit_autoremove=true > -Drpm_ostree=false -Dubuntu_reviews=false -Dfwupd=false -Dflatpak=false > -Dgudev=false -Dmalcontent=false -Dvalgrind=false -Dflatpak=true > -Dmalcontent=true -Dgudev=true -Dfwupd=true -Dsnap=true -Dvalgrind=true > The Meson build system > Version: 0.56.2 > Source dir: /<> > Build dir: /<>/obj-x86_64-linux-gnu > Build type: native build > WARNING: Unknown options: "ostree, ubuntu_reviews" > The value of new options can be set with: > meson setup --reconfigure -Dnew_option=new_value ... > Project name: gnome-software > Project version: 3.38.0 > Using 'CFLAGS' from environment with value: '-g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security' > Using 'LDFLAGS' from environment with value: '-Wl,-z,relro -Wl,-z,now -Wl,-O1 > -Wl,--as-needed' > Using 'CPPFLAGS' from environment with value: '-Wdate-time > -D_FORTIFY_SOURCE=2' > C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 > 20210110") > C linker for the host machine: cc ld.bfd 2.35.1 > Using 'CFLAGS' from environment with value: '-g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security' > Using 'LDFLAGS' from environment with value: '-Wl,-z,relro -Wl,-z,now -Wl,-O1 > -Wl,--as-needed' > Using 'CPPFLAGS' from environment with value: '-Wdate-time > -D_FORTIFY_SOURCE=2' > Host machine cpu family: x86_64 > Host machine cpu: x86_64 > Compiler for C supports arguments -fstack-protector-strong: YES > Compiler for C supports arguments -Waggregate-return: YES > Compiler for C supports arguments -Warray-bounds: YES > Compiler for C supports arguments -Wcast-align: YES > Compiler for C supports arguments -Wclobbered: YES > Compiler for C supports arguments -Wdeclaration-after-statement: YES > Compiler for C supports arguments -Wempty-body: YES > Compiler for C supports arguments -Wextra: YES > ../meson.build:73: WARNING: Consider using the built-in warning_level option > instead of using "-Wextra". > Compiler for C supports arguments -Wformat=2: YES > Compiler for C supports arguments -Wformat-nonliteral: YES > Compiler for C supports arguments -Wformat-security: YES > Compiler for C supports arguments -Wformat-signedness: YES > Compiler for C supports arguments -Wignored-qualifiers: YES > Compiler for C supports arguments -Wimplicit-function-declaration: YES > Compiler for C supports arguments -Werror=implicit-function-declaration: YES > Compiler for C supports arguments -Winit-self: YES > Compiler for C supports arguments -Winline: YES > Compiler for C supports arguments -Wmissing-declarations: YES > Compiler for C supports arguments -Wmissing-format-attribute: YES > Compiler for C supports arguments -Wmissing-include-dirs: YES > Compiler for C supports arguments -Wmissing-noreturn: YES > Compiler for C supports arguments -Wmissing-parameter-type: YES > Compiler for C supports arguments -Wmissing-prototypes: YES > Compiler for C supports arguments -Wnested-externs: YES > Compiler for C supports arguments -Werror=nested-externs: YES > Compiler for C supports arguments -Wno-discarded-qualifiers: YES > Compiler for C supports arguments -Wno-missing-field-initializers: YES > Compiler for C supports arguments -Wno-strict-aliasing: YES > Compiler for C supports arguments -Wno-suggest-attribute=format: YES > Compiler for C supports arguments -Wno-unused-parameter: YES > Compiler for C supports arguments -Wold-style-definition: YES > Compiler for C supports arguments -Woverride-init: YES > Compiler for C supports arguments -Wpacked: YES > Compiler for C supports arguments -Wpointer-a
Bug#980688: seaborn: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Source: seaborn Version: 0.10.1-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > xvfb-run --auto-servernum --server-num=20 dh_auto_test override_dh_auto_test > I: pybuild base:232: cd /<>/.pybuild/cpython3_3.9_seaborn/build; > python3.9 -m pytest > = test session starts > == > platform linux -- Python 3.9.1+, pytest-6.0.2, py-1.10.0, pluggy-0.13.0 > rootdir: /<>, configfile: pytest.ini > collected 591 items > > seaborn/tests/test_algorithms.py ss [ > 3%] > seaborn/tests/test_axisgrid.py . [ > 9%] > .[ > 18%] > seaborn/tests/test_categorical.py .. [ > 24%] > [ > 36%] > [ > 40%] > seaborn/tests/test_distributions.py s.ss..ss.. [ > 43%] > seaborn/tests/test_matrix.py ... [ > 50%] > ss...[ > 57%] > seaborn/tests/test_miscplot.py .s[ > 57%] > seaborn/tests/test_palettes.py [ > 63%] > seaborn/tests/test_rcmod.py ...s.s [ > 67%] > seaborn/tests/test_regression.py ss.ss.. [ > 74%] > .s.. [ > 76%] > seaborn/tests/test_relational.py ... [ > 82%] > [ > 92%] > seaborn/tests/test_utils.py F.ss [ > 99%] > s > [100%] > > === FAILURES > === > test_locator_to_legend_entries > > > def test_locator_to_legend_entries(): > > locator = mpl.ticker.MaxNLocator(nbins=3) > limits = (0.09, 0.4) > levels, str_levels = utils.locator_to_legend_entries( > locator, limits, float > ) > assert str_levels == ["0.00", "0.15", "0.30", "0.45"] > > limits = (0.8, 0.9) > levels, str_levels = utils.locator_to_legend_entries( > locator, limits, float > ) > assert str_levels == ["0.80", "0.84", "0.88", "0.92"] > > limits = (1, 6) > levels, str_levels = utils.locator_to_legend_entries(locator, limits, > int) > assert str_levels == ["0", "2", "4", "6"] > > locator = mpl.ticker.LogLocator(numticks=3) > limits = (5, 1425) > levels, str_levels = utils.locator_to_legend_entries(locator, limits, > int) > if LooseVersion(mpl.__version__) >= "3.1": > > assert str_levels == ['0', '1', '100', '1', '1e+06'] > E AssertionError: assert ['0', '1', '1... '1', ...] == ['0', > '1', '1...000', '1e+06'] > E At index 2 diff: '10' != '100' > E Left contains 2 more items, first extra item: '1' > E Use -v to get the full diff > > seaborn/tests/test_utils.py:395: AssertionError > === warnings summary > === > .pybuild/cpython3_3.9_seaborn/build/seaborn/tests/test_axisgrid.py::TestFacetGrid::test_set_ticklabels > > /<>/.pybuild/cpython3_3.9_seaborn/build/seaborn/axisgrid.py:936: > UserWarning: FixedFormatter should only be used together with FixedLocator > ax.set_yticklabels(labels, **kwargs) > > .pybuild/cpython3_3.9_seaborn/build/seaborn/tests/test_axisgrid.py::TestFacetGrid::test_set_ticklabels > > /<>/.pybuild/cpython3_3.9_seaborn/build/seaborn/axisgrid.py:924: > UserWarning: FixedFormatter should only be used together with FixedLocator > ax.se
Bug#980686: ldc: FTBFS: dh_auto_configure: error: cd bootstrap-stage2 && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -D
Source: ldc Version: 1:1.24.0-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[4]: Entering directory '/<>/bootstrap-stage1' > [ 93%] Linking C shared library ../lib/libphobos2-ldc-shared.so > cd /<>/bootstrap-stage1/runtime && /usr/bin/cmake -E > cmake_link_script CMakeFiles/phobos2-ldc-shared.dir/link.txt --verbose=1 > /usr/bin/cc -fPIC -g -O2 -ffile-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_UNISTD_H > -Wl,-z,relro -shared -Wl,-soname,libphobos2-ldc-shared.so.94 -o > ../lib/libphobos2-ldc-shared.so.2.0.94 objects/etc/c/curl.o > objects/etc/c/odbc/sql.o objects/etc/c/odbc/sqlext.o > objects/etc/c/odbc/sqltypes.o objects/etc/c/odbc/sqlucode.o > objects/etc/c/sqlite3.o objects/etc/c/zlib.o > objects/std/algorithm/comparison.o objects/std/algorithm/internal.o > objects/std/algorithm/iteration.o objects/std/algorithm/mutation.o > objects/std/algorithm/package.o objects/std/algorithm/searching.o > objects/std/algorithm/setops.o objects/std/algorithm/sorting.o > objects/std/array.o objects/std/ascii.o objects/std/base64.o > objects/std/bigint.o objects/std/bitmanip.o objects/std/compiler.o > objects/std/complex.o objects/std/concurrency.o objects/std/container/array.o > objects/std/container/binaryheap.o objects/std/container/dlist.o > objects/std/container/package.o objects/std/container/rbtree.o > objects/std/container/slist.o objects/std/container/util.o objects/std/conv.o > objects/std/csv.o objects/std/datetime/date.o objects/std/datetime/interval.o > objects/std/datetime/package.o objects/std/datetime/stopwatch.o > objects/std/datetime/systime.o objects/std/datetime/timezone.o > objects/std/demangle.o objects/std/digest/crc.o objects/std/digest/digest.o > objects/std/digest/hmac.o objects/std/digest/md.o > objects/std/digest/murmurhash.o objects/std/digest/package.o > objects/std/digest/ripemd.o objects/std/digest/sha.o objects/std/encoding.o > objects/std/exception.o > objects/std/experimental/allocator/building_blocks/affix_allocator.o > objects/std/experimental/allocator/building_blocks/aligned_block_list.o > objects/std/experimental/allocator/building_blocks/allocator_list.o > objects/std/experimental/allocator/building_blocks/ascending_page_allocator.o > objects/std/experimental/allocator/building_blocks/bitmapped_block.o > objects/std/experimental/allocator/building_blocks/bucketizer.o > objects/std/experimental/allocator/building_blocks/fallback_allocator.o > objects/std/experimental/allocator/building_blocks/free_list.o > objects/std/experimental/allocator/building_blocks/free_tree.o > objects/std/experimental/allocator/building_blocks/kernighan_ritchie.o > objects/std/experimental/allocator/building_blocks/null_allocator.o > objects/std/experimental/allocator/building_blocks/package.o > objects/std/experimental/allocator/building_blocks/quantizer.o > objects/std/experimental/allocator/building_blocks/region.o > objects/std/experimental/allocator/building_blocks/scoped_allocator.o > objects/std/experimental/allocator/building_blocks/segregator.o > objects/std/experimental/allocator/building_blocks/stats_collector.o > objects/std/experimental/allocator/common.o > objects/std/experimental/allocator/gc_allocator.o > objects/std/experimental/allocator/mallocator.o > objects/std/experimental/allocator/mmap_allocator.o > objects/std/experimental/allocator/package.o > objects/std/experimental/allocator/showcase.o > objects/std/experimental/allocator/typed.o > objects/std/experimental/checkedint.o objects/std/experimental/logger/core.o > objects/std/experimental/logger/filelogger.o > objects/std/experimental/logger/multilogger.o > objects/std/experimental/logger/nulllogger.o > objects/std/experimental/logger/package.o objects/std/experimental/typecons.o > objects/std/file.o objects/std/format.o objects/std/functional.o > objects/std/getopt.o objects/std/internal/attributes.o > objects/std/internal/cstring.o objects/std/internal/digest/sha_SSSE3.o > objects/std/internal/math/biguintarm.o > objects/std/internal/math/biguintcore.o > objects/std/internal/math/biguintnoasm.o > objects/std/internal/math/biguintx86.o > objects/std/internal/math/errorfunction.o > objects/std/internal/math/gammafunction.o objects/std/internal/memory.o > objects/std/internal/scopebuffer.o objects/std/internal/test/dummyrange.o > objects/std/internal/test/range.o objects/std/internal/test/uda.o > objects/std/internal/unicode_comp
Bug#980687: checkstyle: FTBFS: Failed to execute goal org.antlr:antlr4-maven-plugin:4.7.2:antlr4
Source: checkstyle Version: 8.34-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_auto_build > /usr/lib/jvm/default-java/bin/java -noverify -cp > /usr/share/maven/boot/plexus-classworlds-2.x.jar > -Dmaven.home=/usr/share/maven > -Dmaven.multiModuleProjectDirectory=/<> > -Dclassworlds.conf=/etc/maven/m2-debian.conf > -Dproperties.file.manual=/<>/debian/maven.properties > org.codehaus.plexus.classworlds.launcher.Launcher > -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian > -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package > javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US > [INFO] Scanning for projects... > [WARNING] The POM for > org.apache.maven.plugins:maven-checkstyle-plugin:jar:3.1.1 is missing, no > dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.1: Plugin > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.1 or one of its > dependencies could not be resolved: Cannot access nexus-codehaus-snapshot > (https://oss.sonatype.org/content/repositories/codehaus-snapshots/) in > offline mode and the artifact > org.apache.maven.plugins:maven-checkstyle-plugin:jar:3.1.1 has not been > downloaded from it before. > [WARNING] The POM for org.apache.maven.plugins:maven-install-plugin:jar:2.4 > is missing, no dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.apache.maven.plugins:maven-install-plugin:2.4: Plugin > org.apache.maven.plugins:maven-install-plugin:2.4 or one of its dependencies > could not be resolved: Cannot access nexus-codehaus-snapshot > (https://oss.sonatype.org/content/repositories/codehaus-snapshots/) in > offline mode and the artifact > org.apache.maven.plugins:maven-install-plugin:jar:2.4 has not been downloaded > from it before. > [WARNING] The POM for org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 is > missing, no dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.apache.maven.plugins:maven-deploy-plugin:2.7: Plugin > org.apache.maven.plugins:maven-deploy-plugin:2.7 or one of its dependencies > could not be resolved: Cannot access nexus-codehaus-snapshot > (https://oss.sonatype.org/content/repositories/codehaus-snapshots/) in > offline mode and the artifact > org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 has not been downloaded > from it before. > [WARNING] The POM for > org.apache.maven.plugins:maven-assembly-plugin:jar:3.3.0 is missing, no > dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.apache.maven.plugins:maven-assembly-plugin:3.3.0: Plugin > org.apache.maven.plugins:maven-assembly-plugin:3.3.0 or one of its > dependencies could not be resolved: Cannot access nexus-codehaus-snapshot > (https://oss.sonatype.org/content/repositories/codehaus-snapshots/) in > offline mode and the artifact > org.apache.maven.plugins:maven-assembly-plugin:jar:3.3.0 has not been > downloaded from it before. > [WARNING] The POM for > org.apache.maven.plugins:maven-dependency-plugin:jar:3.1.2 is missing, no > dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.apache.maven.plugins:maven-dependency-plugin:3.1.2: Plugin > org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its > dependencies could not be resolved: Cannot access nexus-codehaus-snapshot > (https://oss.sonatype.org/content/repositories/codehaus-snapshots/) in > offline mode and the artifact > org.apache.maven.plugins:maven-dependency-plugin:jar:3.1.2 has not been > downloaded from it before. > [WARNING] The POM for org.apache.maven.plugins:maven-release-plugin:jar:2.1 > is missing, no dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.apache.maven.plugins:maven-release-plugin:2.1: Plugin > org.apache.maven.plugins:maven-release-plugin:2.1 or one of its dependencies > could not be resolved: Cannot access nexus-codehaus-snapshot > (https://oss.sonatype.org/content/repositories/codehaus-snapshots/) in > offline mode and the artifact > org.apache.maven.plugins:maven-release-plugin:jar:2.1 has not been downloaded > from it before. > [WARNING] The POM for org.codehaus.mojo:sonar-maven-plugin:jar:3.7.0.1746 is > missing, no dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.codehaus.mo
Bug#980685: seqan: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j4 test ARGS\+=-j4 returned exit code 2
Source: seqan Version: 1.4.2+dfsg-4 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[2]: Entering directory '/<>/obj-x86_64-linux-gnu' > Running tests... > /usr/bin/ctest --force-new-ctest-process -j4 > Test project /<>/obj-x86_64-linux-gnu > Start 1: test_demo_align_align > Start 2: test_demo_align_compute_alignment_stats > Start 3: test_demo_align_gaps_example > Start 4: test_demo_align_global_alignment_banded > 1/93 Test #1: test_demo_align_align > .. Passed0.05 sec > Start 5: test_demo_align_global_alignment_unbanded > 2/93 Test #2: test_demo_align_compute_alignment_stats > Passed0.05 sec > Start 6: test_demo_align_integrate_align > 3/93 Test #4: test_demo_align_global_alignment_banded > Passed0.05 sec > Start 7: test_demo_bam_io_bam_stream > 4/93 Test #3: test_demo_align_gaps_example > ... Passed0.05 sec > Start 8: test_demo_find_finder_index > 5/93 Test #5: test_demo_align_global_alignment_unbanded > .. Passed0.05 sec > Start 9: test_demo_find_finder_online > 6/93 Test #6: test_demo_align_integrate_align > Passed0.05 sec > Start 10: test_demo_graph_graph_algo_dijkstra > 7/93 Test #7: test_demo_bam_io_bam_stream > ***Failed0.05 sec > Loading files "/<>/core/demos/bam_io/bam_stream.cpp.stdout", > "None". > Running /<>/obj-x86_64-linux-gnu/bin/demo_bam_io_bam_stream. > ERROR: Return code of > /<>/obj-x86_64-linux-gnu/bin/demo_bam_io_bam_stream was 1. > > Start 11: test_demo_graph_algorithms_all_pairs_shortest_path > 8/93 Test #8: test_demo_find_finder_index > Passed0.05 sec > Start 12: test_demo_graph_algorithms_bellman_ford_algorithm > 9/93 Test #9: test_demo_find_finder_online > ... Passed0.05 sec > Start 13: test_demo_graph_algorithms_breadth_first_search > 10/93 Test #10: test_demo_graph_graph_algo_dijkstra > Passed0.05 sec > Start 14: test_demo_graph_algorithms_dag_shortest_path > 11/93 Test #11: test_demo_graph_algorithms_all_pairs_shortest_path > . Passed0.05 sec > Start 15: test_demo_graph_algorithms_depth_first_search > 12/93 Test #12: test_demo_graph_algorithms_bellman_ford_algorithm > .. Passed0.05 sec > Start 16: test_demo_graph_algorithms_dijkstra > 13/93 Test #13: test_demo_graph_algorithms_breadth_first_search > Passed0.05 sec > Start 17: test_demo_graph_algorithms_floyd_warshall_algorithm > 14/93 Test #14: test_demo_graph_algorithms_dag_shortest_path > ... Passed0.05 sec > Start 18: test_demo_graph_algorithms_ford_fulkerson_algorithm > 15/93 Test #15: test_demo_graph_algorithms_depth_first_search > .. Passed0.05 sec > Start 19: test_demo_graph_algorithms_kruskals_algorithm > 16/93 Test #16: test_demo_graph_algorithms_dijkstra > Passed0.05 sec > Start 20: test_demo_graph_algorithms_prims_algorithm > 17/93 Test #17: test_demo_graph_algorithms_floyd_warshall_algorithm > Passed0.05 sec > Start 21: test_demo_graph_algorithms_strongly_connected_components > 18/93 Test #18: test_demo_graph_algorithms_ford_fulkerson_algorithm > Passed0.05 sec > Start 22: test_demo_graph_algorithms_topological_sort > 19/93 Test #19: test_demo_graph_algorithms_kruskals_algorithm > .. Passed0.05 sec > Start 23: test_demo_graph_algorithms_transitive_closure > 20/93 Test #20: test_demo_graph_algorithms_prims_algorithm > . Passed0.05 sec > Start 24: test_demo_index_index_begin_atEnd_representative > 21/93 Test #21: test_demo_graph_algorithms_strongly_connected_components > ... Passed0.05 sec > Start 25: test_demo_index_index_counting > 22/93 Test #22: test_demo_graph_algorithms_topological_sort > Passed0.05 sec > Start 26: test_demo_index_index_finder > 23/93 Test #23: test_demo_graph_algorithms_transitive_closure >
Bug#980682: liblist-objects-withutils-perl: FTBFS: dh_auto_test: error: make -j1 test TEST_VERBOSE=1 returned exit code 2
Source: liblist-objects-withutils-perl Version: 2.028003-1.1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20210120 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" > "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', > 'blib/arch')" t/*.t t/00_load/*.t t/01_array/*.t t/02_hash/*.t > t/03_junctions/*.t t/04_immutable/*.t t/05_typed/*.t t/06_immutable_typed/*.t > t/07_json/*.t t/08_zpl/*.t t/09_autobox_array/*.t t/09_autobox_hash/*.t > # > # Versions for all modules listed in MYMETA.json (including optional ones): > # > # === Configure Requires === > # > # Module Want Have > # --- > # ExtUtils::MakeMaker any 7.44 > # > # === Build Requires === > # > # Module Want Have > # --- > # ExtUtils::MakeMaker any 7.44 > # > # === Test Requires === > # > # Module Want Have > # --- > # ExtUtils::MakeMaker any 7.44 > # File::Spec any 3.78 > # Test::More 0.88 1.302175 > # > # === Test Recommends === > # > # ModuleWant Have > # - > # CPAN::Meta2.120900 2.150010 > # JSON::PP any 4.04 > # Test::Without::Module any 0.20 > # > # === Runtime Requires === > # > # ModuleWant Have > # - > # Carp any 1.50 > # Class::Method::Modifiers any 2.13 > # Exporter any 5.74 > # List::Util1.33 1.55 > # List::UtilsBy 0.09 0.11 > # Module::Runtime 0.0130.016 > # Role::Tiny 1.003 2.002003 > # Scalar::Util any 1.55 > # Type::Tie0.0040.014 > # autoboxany v3.0.1 > # overload any 1.31 > # parent any0.238 > # strictures 2 2.06 > # > # === Runtime Recommends === > # > # Module Want Have > # - - > # List::UtilsBy::XS 0.03 missing > # Type::Tiny0.022 1.012000 > # > t/00-report-prereqs.t ... > 1..1 > ok 1 > ok > t/00_load/all.t . > ok 1 - array ok > ok 2 - immarray ok > ok 3 - array_of ok > ok 4 - immarray_of ok > ok 5 - hash ok > ok 6 - immhash ok > ok 7 - hash_of ok > ok 8 - immhash_of ok > ok 9 - autobox ok > 1..9 > ok > t/00_load/all_typetinyish.t . > ok 1 - array ok > ok 2 - immarray ok > ok 3 - array_of ok > ok 4 - immarray_of ok > ok 5 - hash ok > ok 6 - immhash ok > ok 7 - hash_of ok > ok 8 - immhash_of ok > ok 9 - autobox ok > 1..9 > ok > t/00_load/autobox.t . > ok 1 - autobox import ok > ok 2 - -autobox import ok > 1..2 > ok > t/00_load/autobox_subclass.t > ok 1 - autoboxed array ok > ok 2 - autoboxed hash ok > 1..2 > ok > t/00_load/badopts.t . > ok 1 - bad import croaks ok > ok 2 - bad function croaks ok > 1..2 > ok > List::Objects::WithUtils::Role::Array::WithJunctions is not a Role::Tiny at > /<>/blib/lib/List/Objects/WithUtils/Array.pm line 6. > Compilation failed in require at > /usr/lib/x86_64-linux-gnu/perl-base/parent.pm line 16. > BEGIN failed--compilation aborted at > /<>/blib/lib/List/Objects/WithUtils/Array/Junction.pm line 8. > Compilation failed in require at > /<>/blib/lib/List/Objects/WithUtils/Role/Array/WithJunctions.pm > line 5. > BEGIN failed--compilation aborted at > /<>/blib/lib/List/Objects/WithUtils/Role/Array/WithJunctions.pm > line 5. > Compilation failed in require at /usr/share/perl5/Role/Tiny.pm line 51. > Compilation failed in require at (eval 21) line 1. > BEGIN failed--compilation aborted at (eval 21) line 1. > at t/00_load/bare.t line 4. > List::Objects::WithUtils::Role::Array::WithJunctions is not a Role::Tiny at > /<>/blib/lib/List/Objects/WithUtils/Array/Immutable/Typed.pm > line 6. > Compilation failed in require at (eval 57) line 1. > BEGIN failed--compilation aborted at (eval 57) line 1