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

2021-01-20 Thread Geert Stappers
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

2021-01-20 Thread Lucas Nussbaum
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)

2021-01-20 Thread Utkarsh Gupta
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

2021-01-20 Thread Stephan Sürken
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

2021-01-20 Thread Patrick Holthuizen
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)

2021-01-20 Thread Sébastien Delafond
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)

2021-01-20 Thread Utkarsh Gupta
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

2021-01-20 Thread chaosmonk
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)

2021-01-20 Thread Sébastien Delafond
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)

2021-01-20 Thread Aurelien Jarno
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)

2021-01-20 Thread Aurelien Jarno
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)

2021-01-20 Thread Aurelien Jarno
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

2021-01-20 Thread Leandro Cunha
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)

2021-01-20 Thread Utkarsh Gupta
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)

2021-01-20 Thread Utkarsh Gupta
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

2021-01-20 Thread Alex Volkov
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 

Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)

2021-01-20 Thread Sébastien Delafond
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

2021-01-20 Thread Leandro Cunha
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

2021-01-20 Thread Salvatore Bonaccorso
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

2021-01-20 Thread Andreas Tille
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.

2021-01-20 Thread Holger Wansing
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)

2021-01-20 Thread Daniel van Vugt

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

2021-01-20 Thread Daniel van Vugt

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

2021-01-20 Thread Logan Rosen
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 

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

2021-01-20 Thread Evangelos Ribeiro Tzaras




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

2021-01-20 Thread Kever Yang

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

2021-01-20 Thread Logan Rosen
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

2021-01-20 Thread Evangelos Ribeiro Tzaras

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

2021-01-20 Thread Chris

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

2021-01-20 Thread Richard Laager

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

2021-01-20 Thread Paul Wise
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

2021-01-20 Thread Stephan Lachnit
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

2021-01-20 Thread Paul Wise
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

2021-01-20 Thread Ryutaroh Matsumoto
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

2021-01-20 Thread Hubert Chathi
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

2021-01-20 Thread Paul Wise
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

2021-01-20 Thread Ryutaroh Matsumoto
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"?

2021-01-20 Thread Adam Borowski
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

2021-01-20 Thread Matthew Chandler
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=4100=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

2021-01-20 Thread Paul Wise
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

2021-01-20 Thread Hubert Chathi
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=amd64=0.7.2-3%2Bb1=1609589163=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:150:4: required
> 

Bug#980723: autopkgtests aren't being run for rust-sequoia-sqv or rust-sequoia-keyring-linter or rust-sequoia-sop

2021-01-20 Thread Daniel Kahn Gillmor
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

2021-01-20 Thread Diane Trout
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

2021-01-20 Thread Philip Wyett
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.

2021-01-20 Thread Dave Dyer


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

2021-01-20 Thread Deb-user

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

2021-01-20 Thread Vagrant Cascadian
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

2021-01-20 Thread Ben Hutchings
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

2021-01-20 Thread Simon McVittie
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

2021-01-20 Thread Simon McVittie
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

2021-01-20 Thread Vincent Blut
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

2021-01-20 Thread John Scott
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

2021-01-20 Thread Helmut Grohne
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

2021-01-20 Thread Noah Meyerhans
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

2021-01-20 Thread Helmut Grohne
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

2021-01-20 Thread Helmut Grohne
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)

2021-01-20 Thread Michael R. Crusoe
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=amd64=1.4.20-1=1611053002=0


--
Michael R. Crusoe


Bug#980718: RM: dkimproxy -- ROM; RC buggy, no upstream, better alternatives

2021-01-20 Thread Thomas Goirand
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

2021-01-20 Thread Vincent Blut
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

2021-01-20 Thread Ole Streicher

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

2021-01-20 Thread Thomas Habets
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

2021-01-20 Thread Noah Meyerhans
Control: tags -1 + patch

A proposed patch is at
https://salsa.debian.org/kernel-team/linux/-/merge_requests/309



Bug#980717: kazocsaba-imageviewer FTBFS

2021-01-20 Thread Adrian Bunk
Source: kazocsaba-imageviewer
Version: 1.2.3-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=kazocsaba-imageviewer=all=1.2.3-2=1611094937=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

2021-01-20 Thread Ole Streicher

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

2021-01-20 Thread Jochen Sprickerhof

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)

2021-01-20 Thread david mountbatten
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

2021-01-20 Thread Anton Gladky
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

2021-01-20 Thread Noah Meyerhans
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

2021-01-20 Thread Noah Meyerhans
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

2021-01-20 Thread Salvatore Bonaccorso
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

2021-01-20 Thread Antonio Radici
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.

2021-01-20 Thread Elana Hashman

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

2021-01-20 Thread Sebastian Ramacher
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

2021-01-20 Thread Vincent Blut
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

2021-01-20 Thread Aurelien Jarno
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

2021-01-20 Thread Jonas Smedegaard
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

2021-01-20 Thread Lucas Nussbaum
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 = {s:"aes.KeyUnwrap(): 
> integrity check failed."} ("aes.KeyUnwrap(): integrity check failed.")
> 
> 
> --
> FAIL: jose_test.go:1600: 
>

Bug#980558: libqmi: A source-only upload is needed for testing migration

2021-01-20 Thread Martin
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

2021-01-20 Thread Lucas Nussbaum
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

2021-01-20 Thread Lucas Nussbaum
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/libboost_timer.so 
> /usr/lib/x86_64-li

Bug#980710: mpi4py: FTBFS: ld: cannot find -llmpe

2021-01-20 Thread Lucas Nussbaum
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

2021-01-20 Thread Lucas Nussbaum
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"

2021-01-20 Thread Lucas Nussbaum
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

2021-01-20 Thread Lucas Nussbaum
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

2021-01-20 Thread Lucas Nussbaum
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'

2021-01-20 Thread Lucas Nussbaum
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

2021-01-20 Thread Lucas Nussbaum
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
> ✓ should handle a

Bug#980697: borgmatic: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

2021-01-20 Thread Lucas Nussbaum
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/cpython3_3.9/build/borgmatic/com

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

2021-01-20 Thread Lucas Nussbaum
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.

2021-01-20 Thread Lucas Nussbaum
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)

2021-01-20 Thread Lucas Nussbaum
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+0x23ef)[0x5

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

2021-01-20 Thread Lucas Nussbaum
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
> * Fini

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

2021-01-20 Thread Lucas Nussbaum
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-dask/usr/lib/python3.9/dist-packages/das

Bug#980693: felix-latin: FTBFS: latex error

2021-01-20 Thread Lucas Nussbaum
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

2021-01-20 Thread Lucas Nussbaum
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-arith: YES 
> Compiler for C supports arguments -Wredundant-decls: YES 
> Compiler for C supports arguments -Wreturn-type: YE

Bug#980688: seaborn: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

2021-01-20 Thread Lucas Nussbaum
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.set_xticklabels(curr_labels, **kwargs)
> 
> .pybuild/cpython3_3.9_seaborn/build/seaborn/tests/test_axisgrid.py::TestFacetGrid::test_set_ticklabels
>   
> /

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

2021-01-20 Thread Lucas Nussbaum
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.o objects

Bug#980687: checkstyle: FTBFS: Failed to execute goal org.antlr:antlr4-maven-plugin:4.7.2:antlr4

2021-01-20 Thread Lucas Nussbaum
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.mojo

Bug#980685: seqan: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j4 test ARGS\+=-j4 returned exit code 2

2021-01-20 Thread Lucas Nussbaum
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

2021-01-20 Thread Lucas Nussbaum
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.
>  at t/00_load/ba

  1   2   3   4   >