Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Ryan Thoryk]

I tried force-downgrading the libglibmm package to the Debian Bullseye 
version (2.66 back to 2.64), the crash goes away, and my audio hardware 
works again with Jack.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Ryan Thoryk]

I wanted to chime in on this bug, since I'm getting basically the same 
issue.  I'm running Debian Testing.


My situation is a little different, because I'm using an M-Audio 
firewire device with Jack2 on a VIA VT6315 card, and so I need the 
firewire module.  I recently swapped out the firewire card but couldn't 
get the audio device to work, since Jack kept segfaulting on startup. 
Tonight I booted a Debian 11 live cd, and the device and Jack work 
flawlessly on it.  The device has trouble working with ALSA, so I use 
the FFADO system instead.


This is what it looks like when running:

ryan@andromeda:~$ jackd -d firewire
jackdmp 1.9.19
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2021 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
Segmentation fault (core dumped)


I downloaded the Jack source code and did some GDB debugging, and found 
that it's segfaulting when doing a dlopen() on the jack_firewire.so 
module.  Jack appears to run fine with the ALSA module instead, but not 
firewire.


I attached the backtrace from GDB.  I had been going over my system's 
linker configuration to see if there was something wrong, and then I 
found this bug report.  Since glib is crashing during a string 
comparison, the culprit appears to be the glibmm frontend's constructor. 
 I didn't set up an environment to debug glibmm yet, but let me know if 
there's something you'd like me to try out.  I was wanting to find out 
details on that string comparison.  You might be able to reproduce it if 
you try to use the firewire device module like I did.


This is the output when running Valgrind on Jack:

==8689==
==8689== Process terminating with default action of signal 11 (SIGSEGV): 
dumping core

==8689==  Bad permissions for mapped region at address 0x6594034
==8689==at 0x4D09370: __strcmp_sse2_unaligned 
(strcmp-sse2-unaligned.S:24)
==8689==by 0x6800F58: g_str_equal (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x67FF9E1: g_hash_table_lookup (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x6822C99: g_quark_from_static_string (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x6938BAF: ??? (in 
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1.3.0)

==8689==by 0x401010D: call_init.part.0 (dl-init.c:74)
==8689==by 0x40101EF: call_init (dl-init.c:37)
==8689==by 0x40101EF: _dl_init (dl-init.c:121)
==8689==by 0x4DAAB6C: _dl_catch_exception (dl-error-skeleton.c:182)
==8689==by 0x4014483: dl_open_worker (dl-open.c:783)
==8689==by 0x4DAAB0F: _dl_catch_exception (dl-error-skeleton.c:208)
==8689==by 0x4013D09: _dl_open (dl-open.c:864)
==8689==by 0x5025257: dlopen_doit (dlopen.c:66)

--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x7f7abc466f59 in g_str_equal () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f7abc4659e2 in g_hash_table_lookup () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f7abc488c9a in g_quark_from_static_string () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f7abc3dbbb0 in  () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#5  0x7f7abe0df10e in call_init
(l=, argc=argc@entry=3, argv=argv@entry=0x7ffca09e2288, 
env=env@entry=0x7ffca09e22a8) at dl-init.c:74
#6  0x7f7abe0df1f0 in call_init (env=0x7ffca09e22a8, argv=0x7ffca09e2288, 
argc=3, l=) at dl-init.c:37
#7  _dl_init (main_map=0x55dd66345d90, argc=3, argv=0x7ffca09e2288, 
env=0x7ffca09e22a8) at dl-init.c:121
#8  0x7f7abdc19b6d in __GI__dl_catch_exception
(exception=exception@entry=0x0, operate=operate@entry=0x7f7abe0e2a00 
, args=args@entry=0x7ffca09e1800)
at dl-error-skeleton.c:182
#9  0x7f7abe0e3484 in dl_open_worker (a=a@entry=0x7ffca09e19a0) at 
dl-open.c:783
#10 0x7f7abdc19b10 in __GI__dl_catch_exception
(exception=exception@entry=0x7ffca09e1980, 
operate=operate@entry=0x7f7abe0e30e0 , 
args=args@entry=0x7ffca09e19a0) at dl-error-skeleton.c:208
#11 0x7f7abe0e2d0a in _dl_open
(file=0x7ffca09e1980 "", mode=-2147483390, caller_dlopen=0x7f7abe038bee 
, nsid=-2, argc=3, 
argv=0x7ffca09e2288, env=0x7ffca09e22a8)
at dl-open.c:864
#12 0x7f7abd8ef258 in dlopen_doit (a=a@entry=0x7ffca09e1bd0) at dlopen.c:66
#13 0x7f7abdc19b10 in __GI__dl_catch_exception
(exception=exception@entry=0x7ffca09e1b70, 
operate=operate@entry=0x7f7abd8ef200 , 
args=args@entry=0x7ffca09e1bd0) at dl-error-skeleton.c:208
#14 0x7f7abdc19bcf in __GI__dl_catch_error
(objname=objname@entry=0x55dd662d70b0, 

Bug#995282: marked as done (amule crashes on start)

[Debian Bug Tracking System]

Your message dated Fri, 01 Oct 2021 04:04:43 +
with message-id 
and subject line Bug#995282: fixed in amule 1:2.3.3-2
has caused the Debian Bug report #995282,
regarding amule crashes on start
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995282: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995282
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: amule
Version: 1:2.3.3-1
Severity: grave

(gdb) run
Starting program: /usr/bin/amule
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 7263]
 2021-09-29 07:08:05: Initialising aMule 2.3.3 compiled with wxGTK2 v3.0.5 and
Boost 1.74
 2021-09-29 07:08:05: Checking if there is an instance already running...
 2021-09-29 07:08:05: No other instances are running.

Program received signal SIGSEGV, Segmentation fault.
0x77ca062c in CryptoPP::SecureWipeBuffer
(n=2305843009213693951, buf=0x2) at misc.h:1442
1442misc.h: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x77ca062c in CryptoPP::SecureWipeBuffer
(n=2305843009213693951, buf=0x2) at misc.h:1442
#1  CryptoPP::SecureWipeArray (n=2305843009213693951, buf=0x2)
at misc.h:1493
#2  CryptoPP::AllocatorWithCleanup::deallocate
(size=2305843009213693951, ptr=0x2, this=) at secblock.h:235
#3  CryptoPP::StandardReallocate > (oldPtr=0x2,
oldSize=2305843009213693951, newSize=8, preserve=, alloc=...) at
secblock.h:172
#4  0x77ca350a in CryptoPP::AllocatorWithCleanup::reallocate (preserve=false, newSize=8, oldSize=,
oldPtr=, this=) at secblock.h:259
#5  CryptoPP::SecBlock >::New (newSize=8, this=) at secblock.h:1128
#6  CryptoPP::SecBlock >::CleanNew (newSize=8, this=) at secblock.h:1145
#7  CryptoPP::Integer::Decode (this=0x56c4ee20, bt=..., inputLen=, s=) at integer.cpp:3397
#8  0x77caae4e in CryptoPP::Integer::BERDecode
(this=this@entry=0x56c4ee20, bt=...) at asn.h:405
#9  0x77dfea1b in CryptoPP::InvertibleRSAFunction::BERDecodePrivateKey
(this=0x56c4ed48, bt=...) at rsa.cpp:211
#10 0x77cb6e98 in CryptoPP::PKCS8PrivateKey::BERDecode
(this=this@entry=0x56c4edc8, bt=...) at asn.cpp:679
#11 0x5575e7fb in CryptoPP::InvertibleRSAFunction::BERDecode (bt=...,
this=0x56c4ed48) at /usr/include/cryptopp/rsa.h:100
#12
CryptoPP::PK_FinalTemplate, CryptoPP::RSA,
CryptoPP::PKCS1v15_SignatureMessageEncodingMethod, CryptoPP::SHA1> >
>::PK_FinalTemplate (
bt=..., this=0x56c4ed30) at /usr/include/cryptopp/pubkey.h:2196
#13 CClientCreditsList::InitalizeCrypting (this=0x56ddd230) at
../../src/ClientCreditsList.cpp:311
#14 0x5575fa24 in CClientCreditsList::CClientCreditsList
(this=0x56ddd230) at ../../src/ClientCreditsList.cpp:54
#15 0x55745ffe in CamuleApp::OnInit (this=this@entry=0x55c3bc20) at
../../src/amule.cpp:513
#16 0x558079f7 in CamuleGuiApp::OnInit (this=0x55c3bc20) at
../../src/amule-gui.cpp:288
#17 0x770093aa in wxEntry (argc=, argv=)
at ../src/common/init.cpp:490
#18 0x5571b562 in main (argc=, argv=) at
../../src/amule-gui.cpp:95

(gdb) bt full
#0  0x77ca062c in CryptoPP::SecureWipeBuffer
(n=2305843009213693951, buf=0x2) at misc.h:1442
p = 0x2
#1  CryptoPP::SecureWipeArray (n=2305843009213693951, buf=0x2)
at misc.h:1493
No locals.
#2  CryptoPP::AllocatorWithCleanup::deallocate
(size=2305843009213693951, ptr=0x2, this=) at secblock.h:235
No locals.
#3  CryptoPP::StandardReallocate > (oldPtr=0x2,
oldSize=2305843009213693951, newSize=8, preserve=, alloc=...) at
secblock.h:172
No locals.
#4  0x77ca350a in CryptoPP::AllocatorWithCleanup::reallocate (preserve=false, newSize=8, oldSize=,
oldPtr=, this=) at secblock.h:259
No locals.
#5  CryptoPP::SecBlock >::New (newSize=8, this=) at secblock.h:1128
No locals.
#6  CryptoPP::SecBlock >::CleanNew (newSize=8, this=) at secblock.h:1145
No locals.
#7  CryptoPP::Integer::Decode (this=0x56c4ee20, bt=..., inputLen=, s=) at integer.cpp:3397
b = 30 '\036'
#8  0x77caae4e in CryptoPP::Integer::BERDecode
(this=this@entry=0x56c4ee20, bt=...) at asn.h:405
dec = { =
{
>> = {> =
{ = { =
{ = {_vptr.Clonable = 0x77f1fed8 }, },  =
{_vptr.Waitable = 0x77f20070 },
m_buf = "\001\000\000\000\000\000\000"}, },
  m_autoSignalPropagation = -1}, m_messageEnd = false}, m_inQueue =
@0x7fffd640, m_length = 48, m_finished = false, m_definiteLength = true}
#9  0x77dfea1b in CryptoPP::InvertibleRSAFunction::BERDecodePrivateKey

Bug#995349: ncbi-entrez-direct: FTBFS: no required module provides package github.com/fiam/gounidecode/unidecode

[Aaron M. Ucko]

Steve Langasek  writes:

> rchive.go:40:2: no required module provides package 
> github.com/fiam/gounidecode/unidecode: go.mod file not found in current 
> directory or any parent directory; see 'go help modules'
[etc.]

Thanks for the report!  AFAICT, my approach to go.mod and go.sum (moving
both aside) ran afoul of https://go.dev/blog/go116-module-changes, and
the "GO111MODULE=off" workaround noted there won't work for Impish
(which rmadison tells me already has 1.17) or likely long for Debian.

I have some thoughts about how to craft a proper fix, and will look into
doing so when I get a chance.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Processed: Re: Bug#995392: ghostscript: ps2pdf trashes some characters

[Debian Bug Tracking System]

Processing control commands:

> tags -1 upstream
Bug #995392 [ghostscript] ghostscript: ps2pdf trashes some characters
Added tag(s) upstream.
> forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704478
Bug #995392 [ghostscript] ghostscript: ps2pdf trashes some characters
Set Bug forwarded-to-address to 
'https://bugs.ghostscript.com/show_bug.cgi?id=704478'.

-- 
995392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995392
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704478

On 2021-09-30 18:49:02 +0200, Jonas Smedegaard wrote:
> Quoting Vincent Lefevre (2021-09-30 18:28:51)
> > On 2021-09-30 17:18:46 +0200, Jonas Smedegaard wrote:
> > > This seems an upstream bug, and it would be helpful if you report it 
> > > upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/
> > 
> > OK. I'll do it tonight (I could also try to find the cause).

I've identified the commit that introduced the issue (though I'm not
sure whether the bug could be already present on other kinds of text)
and reported the bug upstream with the details (see above URL).

> Also, you could test against the newer pre-release in experimental.

Not tried, but the issue is still present in master.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614

[John Scott]

On Thu, 2021-09-30 at 09:18 -0400, John Scott wrote:
> Outside a minimal chroot, on my desktop system, zbarimg seems to
> process SVGs just fine. So this may be a case of a Recommends
> (somewhere) not being installed wreaking havok, but in my opinion
> zbarimg should still not behave this way when a Recommends is
> missing.

I've found the culprit: if libmagickcore-6.q16-6-extra is not
installed, then this cryptic error occurs. I've reported this issue
(the lack of a helpful error message) at
https://github.com/mchehab/zbar/issues/202 .

I'll leave it to the maintainer to decide what they'd like to do:
either hardcode a dependency on libmagickcore-6.q16-6-extra, or switch
zint's output format to PNG (I personally would prefer the latter).


signature.asc
Description: This is a digitally signed message part

Bug#974792: beignet FTBFS with llvm-toolchain-11

[Rebecca N. Palmer]

I'm not aware of a fix for this, and beignet is abandoned upstream and 
mostly useful for old hardware (on newer hardware it is replaced by 
intel-opencl-icd).  However, I may look at it more later (and at least 
try llvm-toolchain-12, though I'd expect that to be worse if anything).


Hence, I'm fine with you removing llvm-toolchain-9 and intentionally 
making beignet unbuildable, but please do *not* remove beignet from 
unstable for the time being.  (It can be removed from testing.)

Bug#986709: rsnapshot is stable, not dead

[John Brooks]

On 2021-09-30 6:13 p.m., Michael Lustfield wrote:

On Sun, 26 Sep 2021 13:49:36 -0400
John Brooks  wrote:


[...]


So... My first response was a wordier version of the message you replied to,
emphasizing the bit where my opinion is moot. What's written below is as much
as I'm willing to dip back into #debiandrama. While reading, please remember
this point (and don't expect further response).


My original request was for a removal, which is a stance I whole-heartedly
still stand by, and which draws from experiences after adopting the package. A
removal like this is basically orphan++ ("I'm afk4eva" vs. "bad package"). That
changed slightly with zeha's bug modifications, but the effect is still largely
the same, with a touch of stability added. (Thanks zeha!)

(sensible action, but likely helps with that "limbo" perception?)
   ^ https://tracker.debian.org/pkg/rsnapshot

side note --

   > Additionally, in response to this very bug, a new upstream release has
   > now been issued. In light of this, do you plan to upload the new version

   You very correctly point out that a number of fixes and a new release came
   directly in response to certain actions. Unfortunately, we draw very 
different
   conclusions. (a hint, perhaps?)


I appreciate that you responded to that particular (#30) message of mine, where
I say that I don't intend to stand in anyone's way, and offered to help anyone
interested in package maintenance, while also maintaining my position. This is
important to me because some people have indeed taken a stab at rsnapshot
maintenance; however, they very quickly disappeared when they learned that it
would require more effort than just slapping an updated tarball onto the
packaging.


and continue to fill the role of maintainer for the rsnapshot Debian
package, or is another maintainer still needed going forward?


^ "continue" stopped at the RM-RoQA (note: this tag was not an accident)

The root of why I claim how I feel does not matter is because the end result is
the same. The only thing that's required to override my (strong) opinion is for
someone to pick it up, understand it well enough to confidently claim it's
ready for release (start w/ debian bugs), and that'll be the end of this thread.



Thank you for your reply. I admit I'm rather a dilettante in this area. 
I'm only a user and have had little or no exposure to the Debian 
development process. I didn't even see "RoQA" until you pointed it out, 
and then had to look up what it means — "Requested by the QA team".


And that's about where my ability to contribute usefully ends. My belief 
that the Debian organization and its contributors are generally 
intelligent and sensible leads me to believe that you and the QA team 
have good reasons for removing the package, even if I don't understand them.


I don't know precisely what criteria of stability and quality are used 
to judge whether a package is suitable for inclusion; my outside view is 
that this package is no more broken or unmaintained than the average 
Debian package. The only bug of "serious" severity classification is 
this one. But when my uninformed assessment is at odds with an actual 
Debian maintainer, I have no choice but to assume that there is an 
important factor which I am blind to. I understand that it's not your 
responsibility to teach me just to satisfy my idle curiosity, so we can 
leave it at that.


Thank you for your service.

John Brooks

Processed: reassign 994697 to git-annex, found 994697 in git-annex/8.20210903-1, affects 994697

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 994697 git-annex
Bug #994697 [libgit-annex-perl] libgit-annex-perl: Test failure - autopkgtest 
and build
Bug reassigned from package 'libgit-annex-perl' to 'git-annex'.
No longer marked as found in versions libgit-annex-perl/0.007-1.
Ignoring request to alter fixed versions of bug #994697 to the same values 
previously set
> found 994697 git-annex/8.20210903-1
Bug #994697 [git-annex] libgit-annex-perl: Test failure - autopkgtest and build
Marked as found in versions git-annex/8.20210903-1.
> affects 994697 libgit-annex-perl
Bug #994697 [git-annex] libgit-annex-perl: Test failure - autopkgtest and build
Added indication that 994697 affects libgit-annex-perl
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
994697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994697
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995424: libgmsh4: SONAME bump without package rename

[Sebastian Ramacher]

Package: libgmsh4
Version: 4.8.4+ds1-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org, elb...@debian.org

The package name of shared libraries is supposed to follow the SONAME of
the library. In the case of libgmsh, the SONAME in testing is
libgmsh.so.4.7 and the package should have been named libgmsh4.7. But
now, the SONAME changed to libgmsh.so.4.8 and the package name should
have been changed accorindgly.

This broke every user outside of the gmsh source package of libgmsh4.
See for example
https://ci.debian.net/data/autopkgtest/testing/amd64/d/deal.ii/15628998/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#986709: rsnapshot is stable, not dead

[Michael Lustfield]

On Sun, 26 Sep 2021 13:49:36 -0400
John Brooks  wrote:

> [...]
> Michael,
> 
> I think it is important that you clarify or modify your stance given 
> that upon further inspection by others here, there are no serious 
> outstanding functional or security issues with the program. Even 
> self-asserted justification (i.e. "I just don't want to maintain it 
> anymore, so find someone else") is acceptable; that is your right as a 
> volunteer. But it would have been prudent to either defend your initial 
> assessment of the program as no longer suitable for inclusion, or 
> acknowledge that you may have been incorrect. Otherwise the issue is 
> just stuck in limbo.
> 
> Additionally, in response to this very bug, a new upstream release has 
> now been issued. In light of this, do you plan to upload the new version 
> and continue to fill the role of maintainer for the rsnapshot Debian 
> package, or is another maintainer still needed going forward?
> 
> I don't seek to impose anything upon you, I just want to see that this 
> doesn't fall through the cracks.
> 
> Thanks
> John Brooks

So... My first response was a wordier version of the message you replied to,
emphasizing the bit where my opinion is moot. What's written below is as much
as I'm willing to dip back into #debiandrama. While reading, please remember
this point (and don't expect further response).


My original request was for a removal, which is a stance I whole-heartedly
still stand by, and which draws from experiences after adopting the package. A
removal like this is basically orphan++ ("I'm afk4eva" vs. "bad package"). That
changed slightly with zeha's bug modifications, but the effect is still largely
the same, with a touch of stability added. (Thanks zeha!)

(sensible action, but likely helps with that "limbo" perception?)
  ^ https://tracker.debian.org/pkg/rsnapshot

side note --

  > Additionally, in response to this very bug, a new upstream release has 
  > now been issued. In light of this, do you plan to upload the new version 

  You very correctly point out that a number of fixes and a new release came
  directly in response to certain actions. Unfortunately, we draw very different
  conclusions. (a hint, perhaps?)


I appreciate that you responded to that particular (#30) message of mine, where
I say that I don't intend to stand in anyone's way, and offered to help anyone
interested in package maintenance, while also maintaining my position. This is
important to me because some people have indeed taken a stab at rsnapshot
maintenance; however, they very quickly disappeared when they learned that it
would require more effort than just slapping an updated tarball onto the
packaging.

> and continue to fill the role of maintainer for the rsnapshot Debian 
> package, or is another maintainer still needed going forward?

^ "continue" stopped at the RM-RoQA (note: this tag was not an accident)

The root of why I claim how I feel does not matter is because the end result is
the same. The only thing that's required to override my (strong) opinion is for
someone to pick it up, understand it well enough to confidently claim it's
ready for release (start w/ debian bugs), and that'll be the end of this thread.

Bug#995419: rust-utf-8: autopkgtest regression: crate directory not found: /usr/share/cargo/registry/utf-8-0.7.6

[peter green]

It passes when run with only packages from testing.


This is not entirely correct, the version of rust-utf-8 in testing
has no autopkgtests at all. So this is a case of a newly added
(by a newer version of debcargo) test failing, not a case of an
existing test regressing.

Investigating, it seems the reason for the failure is that
the crate is installed in the wrong place. It is installed
in /usr/share/cargo/registry/utf-0.7.6/ when it should be
installed in /usr/share/cargo/registry/utf-8-0.7.6/

The reason it's installed in the wrong place is that
dh-cargo by default determines the crate name from the
source package name, but source package names are ambiguous
"rust-utf-8" could mean a crate called "utf" with a major
version of 8 or it could (and actually does in this case)
mean a crate called utf-8.

dh-cargo allows a package to specify an explicit crate name
through X-Cargo-Crate in the source section of the control
file but debcargo seems to offer no way to set this other
than overriding the complete control file. There is no mention
of X-Cargo-Crate in the debcargo source and the mechanism
for adding arbitrary lines to the generated control file only
applies to binary package sections.

This also affects rust-md-5 and rust-sha-1, though neither
of those packages are currently in testing and rust-sha-1
has not had an upload since debcargo started doing
autopkgtests

I see a number of possible ways of solving the issue.

1. Just override the whole control file
   (debcargo rightly discourages this due to the maintenance
   burden it creates, but OTOH this issue only affects
   three crates)
2. Add support for adding arbitrary lines to the source
   section of debian/control in debcargo and use it to
   manually add X-Cargo-Crate
3. Modify dh-cargo to obtain the crate name from Cargo.toml
   instead of the package name.
   (would presumablly mean dragging in a perl toml parser
   which may not be desirable)
4. Modify debcargo to generate X-Cargo-Crate lines in
   cases where dh-cargo would otherwise get the wrong
   crate name.
5. Modify debcargo to generate X-Cargo-Crate lines
   unconditionally

Bug#995392: ghostscript: ps2pdf trashes some characters

[JustAnotherArchivist]

Control: notfound -1 9.53.3~dfsg-8

Apologies, I somehow missed the part about pdftotext and the glyph's 
normal appearance in your original message. I can reproduce that with 
both files produced by 9.54.0~dfsg-5 but *not* the one produced by 
9.53.3~dfsg-8 (attached for reference), using the same pdftotext version 
(poppler-utils 20.09.0-3.1) for all files.




chartest-gs-jaa-9.53.3.pdf
Description: Adobe PDF document

Processed: Re: ghostscript: ps2pdf trashes some characters

[Debian Bug Tracking System]

Processing control commands:

> notfound -1 9.53.3~dfsg-8
Bug #995392 [ghostscript] ghostscript: ps2pdf trashes some characters
Ignoring request to alter found versions of bug #995392 to the same values 
previously set

-- 
995392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995392
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: bug 994697 is forwarded to https://git-annex.branchable.com/todo/recent_change_to_fileRef_breaks_reinject_--known/

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 994697 
> https://git-annex.branchable.com/todo/recent_change_to_fileRef_breaks_reinject_--known/
Bug #994697 [libgit-annex-perl] libgit-annex-perl: Test failure - autopkgtest 
and build
Changed Bug forwarded-to-address to 
'https://git-annex.branchable.com/todo/recent_change_to_fileRef_breaks_reinject_--known/'
 from 
'https://git-annex.branchable.com/todo/recent_change_to_fileRef_breaks_reinject_--known/?updated'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
994697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994697
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: bug 994697 is forwarded to https://git-annex.branchable.com/todo/recent_change_to_fileRef_breaks_reinject_--known/?updated

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 994697 
> https://git-annex.branchable.com/todo/recent_change_to_fileRef_breaks_reinject_--known/?updated
Bug #994697 [libgit-annex-perl] libgit-annex-perl: Test failure - autopkgtest 
and build
Set Bug forwarded-to-address to 
'https://git-annex.branchable.com/todo/recent_change_to_fileRef_breaks_reinject_--known/?updated'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
994697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994697
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995392: ghostscript: ps2pdf trashes some characters

[JustAnotherArchivist]

Hi Vincent,

For what it's worth, I do not see the corruption you're describing with 
`gv chartest-gs.pdf` nor when converting it myself from your input file 
using versions 9.53.3~dfsg-8 or 9.54.0~dfsg-5.


I noticed that your file used a different internal conversion command 
compared to when I try it with ps2pdf 9.54.0~dfsg-5:


Yours: %%Invocation: path/gs -dPrinted=false -P- -dSAFER 
-dCompatibilityLevel=1.5 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite 
-sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.5 ?
Mine: %%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- 
-dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- 
-dSAFER -dCompatibilityLevel=1.4 ?


Invoking it like your command manually did not make a difference for me 
though, with the output file being identical except for the expected 
differences in the version string, timestamps, and UUIDs.


I have attached my `ps2pdf chartest.pdf chartest-gs-jaa.pdf` output file 
(created with 9.54.0~dfsg-5).


Cheers,
JustAnotherArchivist



chartest-gs-jaa.pdf
Description: Adobe PDF document

Processed: Re: Bug#994697: libgit-annex-perl: Test failure - autopkgtest and build

[Debian Bug Tracking System]

Processing control commands:

> tag -1 + confirmed
Bug #994697 [libgit-annex-perl] libgit-annex-perl: Test failure - autopkgtest 
and build
Added tag(s) confirmed.

-- 
994697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994697
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#994697: libgit-annex-perl: Test failure - autopkgtest and build

[Sean Whitton]

control: tag -1 + confirmed

Hello,

On Sun 19 Sep 2021 at 05:30PM +02, gregor herrmann wrote:

> Package: libgit-annex-perl
> Version: 0.007-1
> Severity: serious
> Tags: ftbfs sid bookworm
> Justification: fails to build from source (but built successfully in the past)
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> As first seen at ci.debian.net [0], libgit-annex-perl recently
> started to fail its testsuite. I note that this started to happen
> after the last git-annex upload (8.20210903-1).
>
> The same test failure also happens at buildtime:
>
> #   Failed test 'other is reinjected'
> #   at t/23_annex-to-annex-reinject.t line 33.
> # Looks like you failed 1 test of 2.
> t/23_annex-to-annex-reinject.t 
> ok 1 - other is initially present
> not ok 2 - other is reinjected
> 1..2
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/2 subtests

Bisection has determined that git-annex commit
4bf7940d6b912fbf692b268f621ebd41ed871125 is responsible for this bug.
Haven't come up with a minimal test case yet.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#995421: rust-bumpalo: autopkgtest armhf regression: oom_instead_of_bump_pointer_overflow

[Paul Gevers]

Source: rust-bumpalo
Version: 3.7.0-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of rust-bumpalo the autopkgtest of rust-bumpalo
fails in testing when that autopkgtest is run with the binary packages
of rust-bumpalo from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
rust-bumpalo   from testing3.7.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
name of the test *and* the resources of our armhf worker (250GB RAM) I
wonder if the test is assuming stuff that's not true.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rust-bumpalo

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-bumpalo/15635904/log.gz

running 10 tests
test alloc_slice_clone ... ok
test alloc_slice_copy ... ok
test alloc_with_strong_alignment ... ok
test force_new_chunk_fits_well ... ok
test oom_instead_of_bump_pointer_overflow ... FAILED
test small_size_and_large_align ... ok
test test_alignment ... ok
test test_reset ... ok
test can_iterate_over_allocated_things ... ok
test with_capacity_test ... ok

failures:

failures:
oom_instead_of_bump_pointer_overflow

test result: FAILED. 9 passed; 1 failed; 0 ignored; 0 measured; 0
filtered out; finished in 0.09s

error: test failed, to rerun pass '--test tests'
autopkgtest [16:03:45]: test librust-bumpalo-dev:: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995419: rust-utf-8: autopkgtest regression: crate directory not found: /usr/share/cargo/registry/utf-8-0.7.6

[Paul Gevers]

Source: rust-utf-8
Version: 0.7.6-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of rust-utf-8 the autopkgtest of rust-utf-8 fails
in testing when that autopkgtest is run with the binary packages of
rust-utf-8 from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
rust-utf-8 from testing0.7.6-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Indeed the
cargo/registry only has /usr/share/cargo/registry/utf-0.7.6/

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rust-utf-8

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-utf-8/14941578/log.gz

autopkgtest [09:19:25]: test rust-utf-8:@:
/usr/share/cargo/bin/cargo-auto-test utf-8 0.7.6 --all-targets
--all-features
autopkgtest [09:19:25]: test rust-utf-8:@: [---
crate directory not found: /usr/share/cargo/registry/utf-8-0.7.6
autopkgtest [09:19:25]: test rust-utf-8:@: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978773: marked as done (bmake: ftbfs with autoconf 2.70)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 20:34:48 +
with message-id 
and subject line Bug#978773: fixed in bmake 20200710-15
has caused the Debian Bug report #978773,
regarding bmake: ftbfs with autoconf 2.70
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
978773: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978773
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:bmake
Version: 20200710-5
Severity: normal
Tags: sid bookworm
User: d...@debian.org
Usertags: ftbfs-ac270

[This bug report is not targeted to the upcoming bullseye release]

The package fails to build in a test rebuild on at least amd64 with
autoconf 2.70, but succeeds to build with autoconf 2.69. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://qa-logs.debian.net/2020/09/26.ac270/bmake_20200710-5_unstable_ac270.log
The last lines of the build log are at the end of this report.

To build with autoconf 2.70, please install the autoconf package from
experimental:  apt-get -t=experimental install autoconf 

[...]
prefix='/usr'
program_transform_name='s,x,x,'
psdir='${docdir}'
runstatedir='/run'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='/etc'
target_alias=''
use_filemon='no'
use_meta='yes'

## --- ##
## confdefs.h. ##
## --- ##

/* confdefs.h */
#define PACKAGE_NAME "bmake"
#define PACKAGE_TARNAME "bmake"
#define PACKAGE_VERSION "20200710"
#define PACKAGE_STRING "bmake 20200710"
#define PACKAGE_BUGREPORT "s...@netbsd.org"
#define PACKAGE_URL ""
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define STDC_HEADERS 1
#define __EXTENSIONS__ 1
#define _ALL_SOURCE 1
#define _DARWIN_C_SOURCE 1
#define _GNU_SOURCE 1
#define _POSIX_PTHREAD_SEMANTICS 1
#define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
#define __STDC_WANT_IEC_60559_BFP_EXT__ 1
#define __STDC_WANT_IEC_60559_DFP_EXT__ 1
#define __STDC_WANT_IEC_60559_FUNCS_EXT__ 1
#define __STDC_WANT_IEC_60559_TYPES_EXT__ 1
#define __STDC_WANT_LIB_EXT2__ 1
#define __STDC_WANT_MATH_SPEC_FUNCS__ 1
#define _TANDEM_SOURCE 1
#define HAVE_SYS_WAIT_H 1
#define HAVE_DIRENT_H 1
#define HAVE_SYS_PARAM_H 1
#define HAVE_SYS_SYSCTL_H 1
#define HAVE_AR_H 1
#define HAVE_ERR_H 1
#define HAVE_FCNTL_H 1
#define HAVE_LIBGEN_H 1
#define HAVE_LIMITS_H 1
#define HAVE_PATHS_H 1
#define HAVE_POLL_H 1
#define HAVE_RANLIB_H 1
#define HAVE_SYS_MMAN_H 1
#define HAVE_SYS_SELECT_H 1
#define HAVE_SYS_SOCKET_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_SYS_UIO_H 1
#define HAVE_UTIME_H 1

configure: exit 2
dh_auto_configure: error: ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --with-machine=debian 
returned exit code 2
make[1]: *** [debian/rules:30: override_dh_auto_configure] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:26: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
--- End Message ---
--- Begin Message ---
Source: bmake
Source-Version: 20200710-15
Done: Andrej Shadura 

We believe that the bug you reported is fixed in the latest version of
bmake, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 978...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andrej Shadura  (supplier of updated bmake package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 30 Sep 2021 22:30:38 +0200
Source: bmake
Architecture: source
Version: 20200710-15
Distribution: unstable
Urgency: medium
Maintainer: Andrej Shadura 
Changed-By: Andrej Shadura 
Closes: 978773
Changes:
 bmake (20200710-15) unstable; urgency=medium
 .
   [ Boyuan Yang ]
   

Bug#995308: libcrypt1: symlink points to libpthread

[shichimohedron]

On Thursday, September 30th, 2021 at 12:08 PM, Aurelien Jarno 
 wrote:

> It could be that this libpthread.so.1 file is actually a copy of an old
>
> libcrypt.so.1. It's something you can check with:
>
> readelf --dynamic /lib/x86_64-linux-gnu/libpthread.so.1 | grep SONAME

And it actually is:

~# readelf --dynamic /lib/x86_64-linux-gnu/libpthread.so.1 | grep SONAME
 0x000e (SONAME) Library soname: [libcrypt.so.1]

Bug#978773: bmake: ftbfs with autoconf 2.70

[Andrej Shadura]

Hi,

On Thu, 30 Sep 2021, at 22:18, Boyuan Yang wrote:
> On Thu, 31 Dec 2020 14:26:45 + Matthias Klose  wrote:
>> Package: src:bmake
>> Version: 20200710-5
>> Severity: normal
>> Tags: sid bookworm
>> User: d...@debian.org
>> Usertags: ftbfs-ac270
>> 
>> [This bug report is not targeted to the upcoming bullseye release]
>> 
>> The package fails to build in a test rebuild on at least amd64 with
>> autoconf 2.70, but succeeds to build with autoconf 2.69.
>
> The build error is caused by upstream using autotools macros without proper
> escaping. I am attaching a patch that corrects the syntax and makes the build
> pass. (Simply place it into debian/patches dir.)

Thanks a lot, applied :)

-- 
Cheers,
  Andrej

Bug#995418: python-colorlog breaks macsyfinder autopkgtest: module 'colorlog' has no attribute 'logging'

[Paul Gevers]

Source: python-colorlog, macsyfinder
Control: found -1 python-colorlog/6.4.1-1
Control: found -1 macsyfinder/2.0~rc1-3
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of python-colorlog the autopkgtest of macsyfinder
fails in testing when that autopkgtest is run with the binary packages
of python-colorlog from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
python-colorlogfrom testing6.4.1-1
macsyfinderfrom testing2.0~rc1-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python-colorlog
to testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-colorlog

https://ci.debian.net/data/autopkgtest/testing/amd64/m/macsyfinder/15629571/log.gz

==
ERROR: test_gembase (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 77, in test_gembase
self._macsyfinder_run(args)
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 417, in _macsyfinder_run
macsyfinder.main(args=args.split(),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/scripts/macsyfinder.py",
line 799, in main
macsypy.init_logger(log_file=os.path.join(config.working_dir(),
config.log_file()),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/__init__.py",
line 48, in init_logger
logging = colorlog.logging.logging
AttributeError: module 'colorlog' has no attribute 'logging'

==
ERROR: test_model_unknown (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 403, in test_model_unknown
macsyfinder.main(args=args.split(), loglevel='ERROR')
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/scripts/macsyfinder.py",
line 799, in main
macsypy.init_logger(log_file=os.path.join(config.working_dir(),
config.log_file()),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/__init__.py",
line 48, in init_logger
logging = colorlog.logging.logging
AttributeError: module 'colorlog' has no attribute 'logging'

==
ERROR: test_no_db_type (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 387, in test_no_db_type
macsyfinder.main(args=args.split(), loglevel='ERROR')
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/scripts/macsyfinder.py",
line 799, in main
macsypy.init_logger(log_file=os.path.join(config.working_dir(),
config.log_file()),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/__init__.py",
line 48, in init_logger
logging = colorlog.logging.logging
AttributeError: module 'colorlog' has no attribute 'logging'

==
ERROR: test_no_models (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 358, in test_no_models
macsyfinder.main(args=args.split(), loglevel='ERROR')
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/scripts/macsyfinder.py",
line 799, in main
macsypy.init_logger(log_file=os.path.join(config.working_dir(),
config.log_file()),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/__init__.py",
line 48, in init_logger
logging = colorlog.logging.logging
AttributeError: module 'colorlog' has no attribute 'logging'

==
ERROR: test_no_seq_db (test_functional_test.Test)
--
Traceback (most recent call last):
  File

Bug#978773: bmake: ftbfs with autoconf 2.70

[Boyuan Yang]

Control: tags -1 +patch
X-Debbugs-CC: andre...@debian.org

Hi,

On Thu, 31 Dec 2020 14:26:45 + Matthias Klose  wrote:
> Package: src:bmake
> Version: 20200710-5
> Severity: normal
> Tags: sid bookworm
> User: d...@debian.org
> Usertags: ftbfs-ac270
> 
> [This bug report is not targeted to the upcoming bullseye release]
> 
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69.

The build error is caused by upstream using autotools macros without proper
escaping. I am attaching a patch that corrects the syntax and makes the build
pass. (Simply place it into debian/patches dir.)

-- 
Regards,
Boyuan Yang
From: Boyuan Yang 
Date: Thu, 30 Sep 2021 16:07:03 -0400
Subject: autoconf2.70 fix

---
 configure.in | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/configure.in b/configure.in
index 5b45329..c945a96 100644
--- a/configure.in
+++ b/configure.in
@@ -122,17 +122,16 @@ if test $bmake_path_max -gt 1024; then
bmake_path_max=1024
 fi
 echo "Using: BMAKE_PATH_MAX=$bmake_path_max" >&6
-AC_SUBST(bmake_path_max)dnl
+AC_SUBST([bmake_path_max])dnl
 dnl
 dnl AC_C_CROSS
 dnl
 
 dnl Checks for header files.
-AC_INCLUDES_DEFAULT
 AC_HEADER_SYS_WAIT
 AC_HEADER_DIRENT
 dnl Keep this list sorted
-AC_CHECK_HEADERS(sys/param.h)
+AC_CHECK_HEADERS([sys/param.h])
 dnl On BSDi at least we really need sys/param.h for sys/sysctl.h
 AC_CHECK_HEADERS([sys/sysctl.h], [], [],
 [#ifdef HAVE_SYS_PARAM_H
@@ -161,17 +160,17 @@ dnl Both *BSD and Linux have sys/cdefs.h, most do not.
 dnl If it is missing, we add -I${srcdir}/missing to CFLAGS
 dnl also if sys/cdefs.h does not have __RCSID we need to use ours
 dnl but we need to include the host's one too *sigh*
-AC_CHECK_HEADER(sys/cdefs.h,
-echo $ECHO_N "checking whether sys/cdefs.h is compatible... $ECHO_C" >&6
+AC_CHECK_HEADER([sys/cdefs.h],
+[echo $ECHO_N "checking whether sys/cdefs.h is compatible... $ECHO_C" >&6
 AC_EGREP_CPP(yes,
 [#include 
 #ifdef __RCSID
 yes
 #endif
 ],
-echo yes  >&6,
-echo no  >&6; CPPFLAGS="${CPPFLAGS} -I`cd ${srcdir}/missing && pwd` -DNEED_HOST_CDEFS_H"),
-CPPFLAGS="${CPPFLAGS} -I`cd ${srcdir}/missing && pwd`")
+[echo yes  >&6,
+echo no  >&6; CPPFLAGS="${CPPFLAGS} -I`cd ${srcdir}/missing && pwd` -DNEED_HOST_CDEFS_H"])],
+[CPPFLAGS="${CPPFLAGS} -I`cd ${srcdir}/missing && pwd`"])
 
 dnl Checks for typedefs, structures, and compiler characteristics.
 AC_C___ATTRIBUTE__


signature.asc
Description: This is a digitally signed message part

Processed: python-colorlog breaks macsyfinder autopkgtest: module 'colorlog' has no attribute 'logging'

[Debian Bug Tracking System]

Processing control commands:

> found -1 python-colorlog/6.4.1-1
Bug #995418 [src:python-colorlog, src:macsyfinder] python-colorlog breaks 
macsyfinder autopkgtest: module 'colorlog' has no attribute 'logging'
Marked as found in versions python-colorlog/6.4.1-1.
> found -1 macsyfinder/2.0~rc1-3
Bug #995418 [src:python-colorlog, src:macsyfinder] python-colorlog breaks 
macsyfinder autopkgtest: module 'colorlog' has no attribute 'logging'
Marked as found in versions macsyfinder/2.0~rc1-3.

-- 
995418: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995418
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: bmake: ftbfs with autoconf 2.70

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +patch
Bug #978773 [src:bmake] bmake: ftbfs with autoconf 2.70
Added tag(s) patch.

-- 
978773: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978773
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995162: cannot install together with i386

[Mattia Rizzolo]

On Thu, Sep 30, 2021 at 09:27:50PM +0200, Giovanni Mascellani wrote:
> Thanks for the info. Unless I am mistaken, this means that any package which
> installs a shared PNG breaks at every binNMU, unless the binNMU is for all
> architectures. Wouldn't it be better if dh_strip_nondeterminism used the
> last sourceful upload as reference timestamp? Was this option considered?

It has been considered, but I can tell you that it's _much_ more complex
than just that.  For starters, there would be a huge layer violation in
doing so: the timestamp to use in the normalization comes from dpkg.
Also, normalizing to the previous sourceful upload date is quite likely
to resurface other bugs such what https://bugs.debian.org/843773 tried to fix.

I can add that there are quite many other packages affected by this
(currently 58 binaries), and regularly they cycle as they are binNMUed
and then re-uploaded.  Fortunately this pretty much only affects -dev
and some perl-* packages, and not many people try to cross-coinstall
those packages (as opposed to pure libraries), so the bug doesn't
resurface too often.

I'll leave with the relevant "toolchain" bug: https://bugs.debian.org/969501
(which is what I consider a very valid technical non-full solution of
the problem), and what realistically is the one final solution:
https://bugs.debian.org/894441

Realistically, package-wise, I think they would good by not placing PNGs
in arch:any packages, that would side-step this issue.  And it's the
proper thing to do anyway so why not.  More than that, I don't think
they should bother excessively unless somebody reports them.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#995412: libstring-copyright-perl breaks licensecheck autopkgtest: lots of different outputs

[Jonas Smedegaard]

Quoting Paul Gevers (2021-09-30 21:34:54)
> With a recent upload of libstring-copyright-perl the autopkgtest of 
> licensecheck fails in testing when that autopkgtest is run with the 
> binary packages of libstring-copyright-perl from unstable. It passes 
> when run with only packages from testing. In tabular form:
> 
>  passfail
> libstring-copyright-perl from testing0.003011-1
> licensecheck from testing3.2.11-1
> all others from testingfrom testing

Thanks for filing this, Paul.

It is caused by changes to String::Copyright affecting how wrongly coded 
data is handled.  String::Copyright is documented to take strings as 
input, not raw data, yet its testsuite tests cases of feeding it 
misencoded data - and App::Licensecheck tests even more.

I'll get around to fixing this.  Thanks again,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#995308: libcrypt1: symlink points to libpthread

[shichimohedron]

>Can you please try to call /usr/sbin/ldconfig.old to check if the wrong
link is recreated? That's needed to confirm if ldconfig is the culprit
here.
>Can you confirm it's libpthread.so.1 and not libpthread.so.0? If so can
you please tell how did you install that file?

Here is a shell log, literally

~# ls -l /lib/x86_64-linux-gnu/ | grep libcrypt
-rw-r--r--  1 root root266262 Apr 18 20:46 libcrypt.a
lrwxrwxrwx  1 root root35 Apr 18 20:46 libcrypt.so -> 
/lib/x86_64-linux-gnu/libcrypt.so.1
lrwxrwxrwx  1 root root17 Apr 18 20:46 libcrypt.so.1 -> 
libcrypt.so.1.1.0
-rw-r--r--  1 root root202680 Apr 18 20:46 libcrypt.so.1.1.0
~# /usr/sbin/ldconfig.old
~# ls -l /lib/x86_64-linux-gnu/ | grep libcrypt
-rw-r--r--  1 root root266262 Apr 18 20:46 libcrypt.a
lrwxrwxrwx  1 root root35 Apr 18 20:46 libcrypt.so -> 
/lib/x86_64-linux-gnu/libcrypt.so.1
lrwxrwxrwx  1 root root15 Sep 30 07:53 libcrypt.so.1 -> libpthread.so.1
-rw-r--r--  1 root root202680 Apr 18 20:46 libcrypt.so.1.1.0

I struggle to reveal the origins of libpthread.so.1. It can easily be a result 
of unqualified experimentation, but not necessarily. Of course, if this is the 
case its presence in the system is completely my fault and not in any sense 
yours. Anyway, dpkg -S doesn't match it with any of packages currently 
installed, and another attempts to guess where the library comes from didn't 
lead to any answer.

Processed: tiff is now in unstable

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 989951 serious
Bug #989951 [pylibtiff] The autopkgtests are failing with the new tiff version
Severity set to 'serious' from 'normal'
> affects 989951 src:tiff
Bug #989951 [pylibtiff] The autopkgtests are failing with the new tiff version
Added indication that 989951 affects src:tiff
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
989951: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989951
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995162: cannot install together with i386

[Giovanni Mascellani]

Hi Mattia,

Il 29/09/21 19:28, Mattia Rizzolo ha scritto:

This is triggered by the binNMU, which varies the date of the changelog,
so that dh_strip_nondeterminism will normalize the metadata of the .png
to the binNMU build time instead of the time of the source upload as it
was before.


Thanks for the info. Unless I am mistaken, this means that any package 
which installs a shared PNG breaks at every binNMU, unless the binNMU is 
for all architectures. Wouldn't it be better if dh_strip_nondeterminism 
used the last sourceful upload as reference timestamp? Was this option 
considered?


Thanks, Giovanni.
--
Giovanni Mascellani 

Bug#995412: libstring-copyright-perl breaks licensecheck autopkgtest: lots of different outputs

[Paul Gevers]

cess terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
t/devscripts/gpl-2' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 9 - Fortran comments {
ok 1 - Can run '/usr/bin/licensecheck t/devscripts/bsd.f'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck t/devscripts/bsd.f' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 10 - comments; C++ inline style {
ok 1 - Can run '/usr/bin/licensecheck t/devscripts/comments-detection.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck
t/devscripts/comments-detection.h' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 11 - comments; hash style {
ok 1 - Can run '/usr/bin/licensecheck
t/devscripts/comments-detection.txt'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck
t/devscripts/comments-detection.txt' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 12 - false positives {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright
t/devscripts/false-positives'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
t/devscripts/false-positives' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 13 - regexp killer {
ok 1 - Can run '/usr/bin/licensecheck t/devscripts/regexp-killer.c'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck
t/devscripts/regexp-killer.c' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 14 - info at end {
ok 1 - Can run '/usr/bin/licensecheck -m --shortname-scheme=debian
--copyright --lines 0 t/devscripts/info-at-eof.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m
--shortname-scheme=debian --copyright --lines 0
t/devscripts/info-at-eof.h' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok
t/encoding.t .
# Seeded srand with seed '20210930' from local date.
1..13
# locale encoding: UTF-8
ok 1 - Latin-1 in UTF-8 parsed as UTF-8 returns chars {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright --encoding utf8
t/encoding/copr-utf8.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
--encoding utf8 t/encoding/copr-utf8.h' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
not ok 2 - Latin-1 in UTF-8 parsed by default returns mojibake {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright
t/encoding/copr-utf8.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
t/encoding/copr-utf8.h' is 0
not ok 4 - Testing stdout
# Failed test 'Testing stdout'
# at t/encoding.t line 55.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/copr-utf8.h\tGNU G | eq | t/encoding/copr-utf8.h\tGNU G |
# | eneral Public License v2.0 or || eneral Public License v2.0 or |
# |  later\t2004-2015 Oliva 'f00' ||  later\t2004-2015 Oliva 'f00' |
# |  Oberto / 2001-2010 Paul 'bar ||  Oberto / 2001-2010 Paul 'bar |
# | ' Stevénsön\n   || ' Stev�\N{U+83}©ns�\N{U+83}� |
# |   || �n\n  |
# +---++---+
ok 5 - No stderr
1..5
}

# Failed test 'Latin-1 in UTF-8 parsed by default returns mojibake'
# at t/encoding.t line 57.
not ok 3 - Latin-1 in UTF-8 parsed by guessing returns chars {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright --encoding
Guess t/encoding/copr-utf8.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
--encoding Guess t/encoding/copr-utf8.h' is 0
not ok 4 - Testing stdout
# Failed test 'Testing stdout'
# at t/encoding.t line 60.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/copr-utf8.h\tGNU G | eq | t/encoding/copr-utf8.h\tGNU G |
# | eneral Public License v2.0 or || eneral Public License v2.0 or |
# |  later\t2004-2015 Oliva 'f00' ||  later\t2004-2015 Oliva 'f00' |
# |  Oberto / 2001-2010 Paul 'bar ||  Oberto / 2001-2010 Paul 'bar |
# | ' Stevénsön\n   || ' Stev�\N{U+83}©ns�\N{U+83}� |
# |   || 

Processed: libstring-copyright-perl breaks licensecheck autopkgtest: lots of different outputs

[Debian Bug Tracking System]

Processing control commands:

> found -1 libstring-copyright-perl/0.003011-1
Bug #995412 [src:libstring-copyright-perl, src:licensecheck] 
libstring-copyright-perl breaks licensecheck autopkgtest: lots of different 
outputs
Marked as found in versions libstring-copyright-perl/0.003011-1.
> found -1 licensecheck/3.2.11-1
Bug #995412 [src:libstring-copyright-perl, src:licensecheck] 
libstring-copyright-perl breaks licensecheck autopkgtest: lots of different 
outputs
Marked as found in versions licensecheck/3.2.11-1.

-- 
995412: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995412
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995411: ruby-omniauth-ultraauth: autopkgtest needs update for new version of ruby-omniauth-openid-connect: Could not find 'omniauth_openid_connect' (~> 0.3.0)

[Paul Gevers]

Source: ruby-omniauth-ultraauth
Version: 0.0.2-1.1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, 
ruby-omniauth-openid-conn...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ruby-omniauth-openid-connect

Dear maintainer(s),

With a recent upload of ruby-omniauth-openid-connect the autopkgtest of
ruby-omniauth-ultraauth fails in testing when that autopkgtest is run
with the binary packages of ruby-omniauth-openid-connect from unstable.
It passes when run with only packages from testing. In tabular form:

 passfail
ruby-omniauth-openid-connect from testing0.4.0-2
ruby-omniauth-ultraauth  from testing0.0.2-1.1
all others   from testingfrom testing

I copied some of the output at the bottom of this report. It looks to me
that you have to make your package compatible with the next version of
ruby-omniauth-openid-connect.

Currently this regression is blocking the migration of
ruby-omniauth-openid-connect to testing [1]. Of course,
ruby-omniauth-openid-connect shouldn't just break your autopkgtest (or
even worse, your package), but it seems to me that the change in
ruby-omniauth-openid-connect was intended and your package needs to
update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from
ruby-omniauth-openid-connect should really add a versioned Breaks on the
unfixed version of (one of your) package(s). Note: the Breaks is nice
even if the issue is only in the autopkgtest as it helps the migration
software to figure out the right versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-omniauth-openid-connect

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-omniauth-ultraauth/15624243/log.gz


┌──┐
│ Checking Rubygems dependency resolution on ruby2.7
   │
└──┘

GEM_PATH= ruby2.7 -e gem\ \"omniauth-ultraauth\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in
block in activate_dependencies': Could not find
'omniauth_openid_connect' (~> 0.3.0) among 90 total gem(s)
(Gem::MissingSpecError)
Checked in
'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
at:
/usr/share/rubygems-integration/all/specifications/omniauth-ultraauth-0.0.2.gemspec,
execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:311:in `to_specs':
Could not find 'omniauth_openid_connect' (~> 0.3.0) among 90 total
gem(s) (Gem::MissingSpecError)
Checked in
'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
, execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'





OpenPGP_signature
Description: OpenPGP digital signature

Processed: ruby-omniauth-ultraauth: autopkgtest needs update for new version of ruby-omniauth-openid-connect: Could not find 'omniauth_openid_connect' (~> 0.3.0)

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:ruby-omniauth-openid-connect
Bug #995411 [src:ruby-omniauth-ultraauth] ruby-omniauth-ultraauth: autopkgtest 
needs update for new version of ruby-omniauth-openid-connect: Could not find 
'omniauth_openid_connect' (~> 0.3.0)
Added indication that 995411 affects src:ruby-omniauth-openid-connect

-- 
995411: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995411
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995410: breezy: FTBFS:

[Steve Langasek]

Source: breezy
Version: 3.2.1-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish

Hi Jelmer,

While tracking a build failure of breezy 3.2.1 in Ubuntu, I found that it is
currently also reproducible in Debian unstable:

[...]
==
ERROR: 
breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)
--
Traceback (most recent call last):
testtools.testresult.real._StringException: log: {{{
763.552  creating repository in 
file:///tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path%28WorkingTreeFormat4%29/work/tree/.bzr/.
763.553  creating branch  in 
file:///tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path%28WorkingTreeFormat4%29/work/tree/
763.558  trying to create missing lock 
'/tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)/work/tree/.bzr/checkout/dirstate'
763.558  opening working tree 
'/tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)/work/tree'
}}}

Traceback (most recent call last):
  File "/tmp/breezy-3.2.1/breezy/tests/per_workingtree/test_workingtree.py", 
line 1253, in test_bad_fs_path
with open(b'tree/subdir/m\xb5', 'wb') as f:
OSError: [Errno 84] Invalid or incomplete multibyte or wide character: 
b'tree/subdir/m\xb5'

[...]
==
ERROR: 
breezy.tests.test_plugins.TestPlugins.test_1_2_3__version__with_version_info
--
Traceback (most recent call last):
testtools.testresult.real._StringException: log: {{{
853.935  loading plugins!
853.935  using _Path('breezy.testingplugins', [], [], ['.'])
853.935  Traceback (most recent call last):
  File "/tmp/breezy-3.2.1/breezy/plugin.py", line 429, in _load_plugin_module
__import__(_MODULE_PREFIX + name)
ModuleNotFoundError: No module named 'breezy.testingplugins.plugin'

853.935  Unable to load plugin 'plugin' from '.': No module named 
'breezy.testingplugins.plugin'
 WARNING  Unable to load plugin 'plugin' from '.': No module named 
'breezy.testingplugins.plugin'
853.936  removed breezy.testingplugins from sys.modules
}}}

Traceback (most recent call last):
  File "/tmp/breezy-3.2.1/breezy/tests/test_plugins.py", line 468, in 
test_1_2_3__version__with_version_info
plugin = breezy.plugin.plugins()['plugin']
KeyError: 'plugin'

[...]

(There are multiple errors of these two classes in the log, but this seems to
be the gist of it.)

I don't have capacity to dig into these failures and figure them out, but I
look forward to a resolution so the set of breezy-related packages can be
unstuck in Ubuntu again.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#994285: libseccomp: FTBFS on arm64, armhf, mips64el and mipsel

[Felix Geyer]

Hi,

On 30.09.21 08:40, Johannes Schauer Marin Rodrigues wrote:

Hi Felix,

On Fri, 17 Sep 2021 07:15:16 +0200 Johannes Schauer Marin Rodrigues 
 wrote:

you set the upstream bug to https://github.com/seccomp/libseccomp/issues/336
but I don't think that is correct. The failures is not the same for the
different architectures. mipsel fails different than arm64. I bisected
upstream git on both architectures and found out that the arm64 failure was
introduced in aa0f858 and the mipsel failure comes from e976080.

I contacted upstream about that here:
https://github.com/seccomp/libseccomp/issues/338


the problem has no been present in unstable for three weeks. This is blocking
my work. Could we revert the offending commits or at least set a deadline up to
how long we want to wait for upstream to fix this issue?

I'm willing to put work into an NMU in case you don't have the time right now.


I've prepared a revert of the problematic commits in the git repo.

So far I've tested amd64 build+autopkgtest and mipsel build, no issues yet.

Cheers,
Felix

Bug#978830: https://gitlab.com/kalilinux/packages/gtkhash

[Arnaud Rebillout]

Dear maintainer,

I had to update this package for Kali Linux. I updated it to latest 
upstream version 1.4, and cherry-picked an upstream patch to fix this FTBFS.


You can find this package at 
https://gitlab.com/kalilinux/packages/gtkhash. Please feel free to 
cherry-pick all the commits you need from there.


Alternatively, if you're not willing to maintain this package anymore, 
I'm OK to maintain it.


Cheers,

--
Arnaud Rebillout

Bug#993562: marked as done (dlt-viewer: missing .h files in dev package)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 19:02:07 +
with message-id 
and subject line Bug#993562: fixed in dlt-viewer 2.21.2+dfsg-2+deb11u1
has caused the Debian Bug report #993562,
regarding dlt-viewer: missing .h files in dev package
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
993562: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993562
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: dlt-viewer
version: 2.21.2+dfsg-2
severity: serious
tags: patch

Hello, looks like the version -2 of the package was missing lots of .h header 
files leading to an
impossibility to compile any plugin with it.
I fixed this in the -3 version in sid, and I would like to propose a 
stable-update

Gianfranco
--- End Message ---
--- Begin Message ---
Source: dlt-viewer
Source-Version: 2.21.2+dfsg-2+deb11u1
Done: Gianfranco Costamagna 

We believe that the bug you reported is fixed in the latest version of
dlt-viewer, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 993...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gianfranco Costamagna  (supplier of updated 
dlt-viewer package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 01 Sep 2021 11:42:30 +0200
Source: dlt-viewer
Architecture: source
Version: 2.21.2+dfsg-2+deb11u1
Distribution: bullseye
Urgency: medium
Maintainer: Stefan Potyra 
Changed-By: Gianfranco Costamagna 
Closes: 993562
Changes:
 dlt-viewer (2.21.2+dfsg-2+deb11u1) bullseye; urgency=medium
 .
   * Add missing qdlt/qdlt*.h header files to dev package (Closes: #993562)
Checksums-Sha1:
 29a363e509dc06968f7bb513c615dbe4733045ee 2271 
dlt-viewer_2.21.2+dfsg-2+deb11u1.dsc
 e56d1c7b22eb84d2b47846ed23f8e276fd1fd5ea 3604 
dlt-viewer_2.21.2+dfsg-2+deb11u1.debian.tar.xz
 cdd9f2cb227508b8951add733ec08a49a08b1677 15956 
dlt-viewer_2.21.2+dfsg-2+deb11u1_source.buildinfo
Checksums-Sha256:
 dd64fc9036cabb79611f46bbe417e10cc447e7b4590cba870bf90d709cb6ef1c 2271 
dlt-viewer_2.21.2+dfsg-2+deb11u1.dsc
 1bd2981ac478c95563a5bf5f122cbc6b337dc040f77a7819fae853185ca4d989 3604 
dlt-viewer_2.21.2+dfsg-2+deb11u1.debian.tar.xz
 dc4597e59467fd82a8d3ed83d8ece8e1f029523e52af5e61a58470ed6054 15956 
dlt-viewer_2.21.2+dfsg-2+deb11u1_source.buildinfo
Files:
 46e2a4a4b0fa97f39602188b1d9fd8e8 2271 devel optional 
dlt-viewer_2.21.2+dfsg-2+deb11u1.dsc
 c4eb4d4ed9e225ac2c1b860818532d24 3604 devel optional 
dlt-viewer_2.21.2+dfsg-2+deb11u1.debian.tar.xz
 b8eef76e70b277c198ef1cad42381dc3 15956 devel optional 
dlt-viewer_2.21.2+dfsg-2+deb11u1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAmFPhacACgkQ808JdE6f
Xdn5mQ//cyD4//yzBw1l9IpODS0/EpyTQ3hft/19uSukGKdMLbUSbZGMQTQaZ7DT
5PdjrsNx0BQ0KyGqCbG7hyGyyHYU7bM3ynUlxdSIaGxDKchbzXtnBIjtrFB5Fwhv
J7RiYmq2x2kcEhR8Mw8hwxaH3axYoePlMjHJeEuvyMZs82N9UEq104qvOnZdXgRN
Wu6uIKf+pBr2tZRCz8TOn0qImhx70LnDjXFIJ57F7bGxVzey+dPWieKhNKsg4cHl
pbLS6uu62Xq/rX7KLox1AH1RUCzmPNvF4QHp8m6+IeKzd64tG3B+mS+YTP8xrqZ6
pjSSkiMlBTqrVSbjtFWjdts/pZgtwH9/JRkGrFZ7rfAu6D4yc0j4TJXFShn1vGOd
T0kg4jjjgEMSPm/332FmVtn+7LBZkFg7VAZpxKe1lKtZWVmXWXnrZDZofyrYAWdD
F65uyN9fLpO+Uowjs2PALL/1S6Zu6zLv++7ndiHbuQ0Y7rw1IqXlOs09lSgzXatC
HpGAncVjFhYhbdjEn8u0LXbY0O5nvoyetZMVY6bCxwvQi6VGd2Tu/90uDs1d/rok
iIMHp28vmyT6tArj2dyPC2ogsFHPjplUqM8UjsXUrRPPoCO0iT1cN9PUvKs1SMsh
8p5EE9GAdu7tPF6RXNhunloRUsKZbvx9owILVC2V0pyNPcS0I9g=
=OHCQ
-END PGP SIGNATURE End Message ---

Bug#993935: marked as done (debian-edu-ltsp-install: Netboot image exposes private data and crypto keys)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 18:47:07 +
with message-id 
and subject line Bug#993935: fixed in debian-edu-config 2.11.56+deb11u1
has caused the Debian Bug report #993935,
regarding debian-edu-ltsp-install: Netboot image exposes private data and 
crypto keys
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
993935: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993935
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-edu-config
Version: 2.11.56
Severity: critical
Tags: security
Justification: root security hole
X-Debbugs-Cc: Debian Security Team 

The LTSP netboot image produced by debian-edu-ltsp-install includes full copies
of files that should never leave the Debian Edu main server, if run on a 
so-called
"combined server" (a system using the Main Server and Terminal Server profiles,
as done in small installations).

Among these files are full copies of, among others:

 - /var/lib/ldap, containing the full, unencrypted LDAP database with all
   private information on all users, password hashes, and Kerberos keys
 - /etc/krb5-kdc, containing information on decrypting Kerberos data in the
   LDAP database
 - /etc/gosa, containing the (encrypted) LDAP manager credentials, plus the
   key to decrypt it

Any user with access to the local terminal server network can acquire the 
netboot
image, unauthenticated, and extract the listed information from it.

The issue is caused by the new LTSP system using the LTSP PnP system now in all
cases, thus packing the entire mai nserver filesystem in squashfs image. The
debian-edu-ltsp-install script produces a list of files to exclude from the 
image,
which is not sufficient, most probably because it was tailored to the use case 
where
the image is produced from a dedicated Terminal Server instead of a combined 
server.

IMHO, the use case of the combined server cannot be fixed. The new LTSP system 
de facto
disallows any use of a combiend server – even if we make a very carefully 
curated list
of excluded files, any administrator would have to take care to add their own 
excludes
for just about any file they place on the main server that was not palced there 
by the
Debian Edu software. In fact, the whole new LTSP system seems unfit to be used 
on any
server that is not limited to producing LTSP images, and supporting netbooting 
them.

For now, the issue should be mitigated by carefully adding all relevant paths 
that
are known to exist only on the main server to the exclude list, but I do not 
think
that is a viable fix in the long term.
--- End Message ---
--- Begin Message ---
Source: debian-edu-config
Source-Version: 2.11.56+deb11u1
Done: Holger Levsen 

We believe that the bug you reported is fixed in the latest version of
debian-edu-config, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 993...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Holger Levsen  (supplier of updated debian-edu-config 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 28 Sep 2021 16:32:20 +0200
Source: debian-edu-config
Architecture: source
Version: 2.11.56+deb11u1
Distribution: bullseye
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Closes: 993935
Changes:
 debian-edu-config (2.11.56+deb11u1) bullseye; urgency=medium
 .
   [ Wolfgang Schweer ]
   * Adjust sbin/debian-edu-ltsp-install. (Closes: #993935)
 Thanks to Dominik George for spotting and reporting the issue.
 - Extend main server related exclude list.
 - Add slapd and xrdp-sesman to the list of masked services.
 - Ensure home directory access after above changes.
Checksums-Sha1:
 8bff85b5ab93948a087438b50d29d727463c4f8d 1958 
debian-edu-config_2.11.56+deb11u1.dsc
 1f62b24876e5a1f8694ab05cc08577e57d46903d 342544 
debian-edu-config_2.11.56+deb11u1.tar.xz
 3ec9bf7f7b1a33f3d79dd1d79bedeb68fe6953ca 5668 
debian-edu-config_2.11.56+deb11u1_source.buildinfo
Checksums-Sha256:
 1fa4102ff6af3b1cc828d34b1956b148fd901f589e7cc29601bde7d00177ea49 1958 
debian-edu-config_2.11.56+deb11u1.dsc
 3a9e0069a0d2afda2c924b7ee6b42f3e6a9fd1017a5b07c3d8fc02c5616ce523 

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

[Diane Trout]

On Thu, 2021-09-30 at 17:43 +0200, Drew Parsons wrote:
> Can anyone say why this Bug#980692 is still holding up the dask 
> migration?
> 
> The bug is fully marked fixed and closed now, it shouldn't be in the
> way 
> any more.


I tried closing the bug again with the currently available version.
Maybe that'll help?

Diane

Processed: closing 980692

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 980692 2021.08.1+dfsg-3
Bug #980692 {Done: Diane Trout } [src:dask] dask: FTBFS: 
dh_sphinxdoc: error: 
debian/python-dask-doc/usr/share/doc/python-dask-doc/html/_static/js/html5shiv.min.js
 is missing
Marked as fixed in versions dask/2021.08.1+dfsg-3.
Bug #980692 {Done: Diane Trout } [src:dask] dask: FTBFS: 
dh_sphinxdoc: error: 
debian/python-dask-doc/usr/share/doc/python-dask-doc/html/_static/js/html5shiv.min.js
 is missing
Bug 980692 is already marked as done; not doing anything.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
980692: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980692
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#994971: marked as done (OpenCL not working with latest Nvidia driver)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 17:37:31 +
with message-id 
and subject line Bug#994971: fixed in nvidia-graphics-drivers 470.63.01-1
has caused the Debian Bug report #994971,
regarding OpenCL not working with latest Nvidia driver
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
994971: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994971
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: nvidia-driver
Version: 470.57.02-3
Severity: grave

I'm currently using GNU/Debian sid. The current NVidia driver is
470.57.02-2 and OpenCL is working fine.

$ clinfo 

Number of platforms   1
  Platform Name   NVIDIA CUDA
  Platform Vendor NVIDIA Corporation
  Platform Version    OpenCL 3.0 CUDA
11.4.94
  ...

There is a new version available 470.57.02-3 and when installed OpenCL
is not supported. clinfo report that there is 0 platform
supported/detected.

I have this issue with kernel 5.10.0-8-amd64 and new 5.14. The only
solution I have found at this point is to revert the NVidia driver to
470.57.02-3 and kernel 5.10.

I cannot tell if this is a kernel issue or an NVidia driver one. Maybe
someone with more knowledge on this area could help finding out.

Thanks,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B
--- End Message ---
--- Begin Message ---
Source: nvidia-graphics-drivers
Source-Version: 470.63.01-1
Done: Andreas Beckmann 

We believe that the bug you reported is fixed in the latest version of
nvidia-graphics-drivers, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 994...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Beckmann  (supplier of updated nvidia-graphics-drivers 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 30 Sep 2021 18:55:41 +0200
Source: nvidia-graphics-drivers
Architecture: source
Version: 470.63.01-1
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Closes: 994633 994971
Changes:
 nvidia-graphics-drivers (470.63.01-1) unstable; urgency=medium
 .
   * New upstream production branch release 470.63.01 (2021-08-10).
 - Added an application profile to disable FXAA for Firefox to prevent
   visual corruption.
 - Added support for the VK_KHR_wayland_surface extension.
 - Fixed a Vulkan performance regression that affected rFactor2.
 (Closes: #994633)
 .
   [ Andreas Beckmann ]
   * libegl-nvidia0: Ship new library libnvidia-vulkan-producer.so.#VERSION#
 but do not provide alternatives since it is unclear how this undocumented
 SONAME-less library is supposed to be used.
   * Add Build-Depends: libnvidia-egl-wayland-dev.
   * nvidia-kernel-support: Restore nvidia-modprobe.conf which might have gone
 missing due to bugs in debhelper (#994919) and dpkg (#995387).
 (Closes: #994971)
Checksums-Sha1:
 5e86ff07d3b3b9b79879e50a38e4b7a3f5067834 6809 
nvidia-graphics-drivers_470.63.01-1.dsc
 e7451516e383c1d4231e7f90e5b3859eef3e0035 271471341 
nvidia-graphics-drivers_470.63.01.orig-amd64.tar.gz
 712087f4ad016a0f88feb6d13680c6984ce54432 184115736 
nvidia-graphics-drivers_470.63.01.orig-arm64.tar.gz
 a78cf61b4f7a1c8d36ddb35392213ad56fb6c4c2 139 
nvidia-graphics-drivers_470.63.01.orig.tar.gz
 e510ec74105e0539f2c97639195f6419e97b5bea 203912 
nvidia-graphics-drivers_470.63.01-1.debian.tar.xz
 12c829fad9bdebffa0edfc6b5d5fdca8e10a1eda 8094 
nvidia-graphics-drivers_470.63.01-1_source.buildinfo
Checksums-Sha256:
 63f82f075f4c66686d9392c781823da182423f809d8bed18306f3425907d7228 6809 
nvidia-graphics-drivers_470.63.01-1.dsc
 4e6bf59180f2b56f4bcf90623809dacc3775ee414df9fde8b8fc76d238366659 271471341 
nvidia-graphics-drivers_470.63.01.orig-amd64.tar.gz
 b6906d2b589cac15a400e8177dc75bd1a2757f0ba4be43035cbf14d9449b2e37 184115736 
nvidia-graphics-drivers_470.63.01.orig-arm64.tar.gz
 

Bug#995038: marked as done (ddccontrol FTBFS: autoreconf: error: intltoolize failed with exit status: 1)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 16:49:16 +
with message-id 
and subject line Bug#995038: fixed in ddccontrol 0.5.2-2
has caused the Debian Bug report #995038,
regarding ddccontrol FTBFS: autoreconf: error: intltoolize failed with exit 
status: 1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995038: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995038
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: ddccontrol
Version: 0.4.4-1.2
Severity: serious
Tags: ftbfs

ddccontrol fails to build from source in unstable on amd64. A build ends
as follows:

|debian/rules override_dh_autoreconf
| make[1]: Entering directory '/<>'
| ./autogen.sh
| Running autoreconf...
| Copying file ABOUT-NLS
| Copying file config.rpath
| Creating directory m4
| Copying file m4/codeset.m4
| Copying file m4/fcntl-o.m4
| Copying file m4/gettext.m4
| Copying file m4/glibc2.m4
| Copying file m4/glibc21.m4
| Copying file m4/iconv.m4
| Copying file m4/intdiv0.m4
| Copying file m4/intl.m4
| Copying file m4/intldir.m4
| Copying file m4/intlmacosx.m4
| Copying file m4/intmax.m4
| Copying file m4/inttypes-pri.m4
| Copying file m4/inttypes_h.m4
| Copying file m4/lcmessage.m4
| Copying file m4/lib-ld.m4
| Copying file m4/lib-link.m4
| Copying file m4/lib-prefix.m4
| Copying file m4/lock.m4
| Copying file m4/longlong.m4
| Copying file m4/nls.m4
| Copying file m4/po.m4
| Copying file m4/printf-posix.m4
| Copying file m4/progtest.m4
| Copying file m4/size_max.m4
| Copying file m4/stdint_h.m4
| Copying file m4/threadlib.m4
| Copying file m4/uintmax_t.m4
| Copying file m4/visibility.m4
| Copying file m4/wchar_t.m4
| Copying file m4/wint_t.m4
| Copying file m4/xsize.m4
| Copying file po/Makefile.in.in
| Copying file po/Makevars.template
| Copying file po/Rules-quot
| libtoolize: putting auxiliary files in '.'.
| libtoolize: copying file './ltmain.sh'
| libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
| libtoolize: copying file 'm4/libtool.m4'
| libtoolize: copying file 'm4/ltoptions.m4'
| libtoolize: copying file 'm4/ltsugar.m4'
| libtoolize: copying file 'm4/ltversion.m4'
| libtoolize: copying file 'm4/lt~obsolete.m4'
| intltoolize: 'po/Makefile.in.in' exists: use '--force' to overwrite
| intltoolize: 'po/Makefile.in.in' is out of date: use '--force' to overwrite
| autoreconf: error: intltoolize failed with exit status: 1
| make[1]: *** [debian/rules:12: override_dh_autoreconf] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:9: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut
--- End Message ---
--- Begin Message ---
Source: ddccontrol
Source-Version: 0.5.2-2
Done: Barak A. Pearlmutter 

We believe that the bug you reported is fixed in the latest version of
ddccontrol, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 995...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Barak A. Pearlmutter  (supplier of updated ddccontrol package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 30 Sep 2021 15:57:53 +0100
Source: ddccontrol
Architecture: source
Version: 0.5.2-2
Distribution: unstable
Urgency: medium
Maintainer: Barak A. Pearlmutter 
Changed-By: Barak A. Pearlmutter 
Closes: 757268 931145 949090 988113 995038
Changes:
 ddccontrol (0.5.2-2) unstable; urgency=medium
 .
   * The new upstream release (closes: #988113) fixes a bunch of issues
 - Can run GUI client gddccontrol as regular user, since the system now
   uses dbus (closes: #931145)
 - autotools fixes (closes: #995038)
 - 퐬퐭퐚퐭퐢퐜 inline int readbytes (closes: #757268)
   * Patch autoconf: xml2-config to pkg-config (closes: #949090)
Checksums-Sha1:
 7d8a9e0dc0f258c79e941049303db9d33a51379c 2344 ddccontrol_0.5.2-2.dsc
 3bb0113db06668fd35e8d24651f390eeb2026dda 8736 ddccontrol_0.5.2-2.debian.tar.xz
 2687e84d14f85d1acbf86bb8c1a115995b6f54cf 12977 
ddccontrol_0.5.2-2_source.buildinfo
Checksums-Sha256:
 796daeae063bba7c305136129a5f644d3490ee57cfd78d2844ef138ab22857d5 2344 
ddccontrol_0.5.2-2.dsc
 1b1282ee4675c9faa705fb475bf6915b9f7237a4cf3d57763ccd2a316ee8851b 8736 

Bug#995392: ghostscript: ps2pdf trashes some characters

[Jonas Smedegaard]

Quoting Vincent Lefevre (2021-09-30 18:28:51)
> On 2021-09-30 17:18:46 +0200, Jonas Smedegaard wrote:
> > This seems an upstream bug, and it would be helpful if you report it 
> > upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/
> 
> OK. I'll do it tonight (I could also try to find the cause).

Great. Thanks!

Also, you could test against the newer pre-release in experimental.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#995402: FTBFS: test failure

[gregor herrmann]

Source: libclass-dbi-sweet-perl
Version: 0.11-1.1
Severity: serious
Tags: ftbfs sid bookworm upstream
Justification: fails to build from source
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=134150

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package fails it's test suite with the newer SQL::Abstract:

DBD::SQLite::db prepare_cached failed: no such column: cds.tags.tag [for 
Statement "SELECT me.artistid, me.name
FROM   artist me, cd cds, tags tags
WHERE  cds.tags.tag = ? AND me.artistid = cds.artist AND cds.cdid = tags.cd
"] at /usr/share/perl5/Ima/DBI.pm line 398.
# Looks like your test exited with 2 just after 16.
t/04join.t ...
1..17
ok 1 - use SweetTest;
ok 2 - Artist retrieved by name
ok 3 - Correct number of CDs returned
ok 4 - Correct CD returned first
ok 5 - next_by operating correctly
ok 6 - FROM statement ok
ok 7 - WHERE clause ok
ok 8 - Last CD returned correctly
ok 9 - Join search by object ok
ok 10 - Tag retrieved
ok 11 - Retrieve previous by has_many works
ok 12 - Single CD retrieved via might_have
ok 13 - Correct CD retrieved
ok 14 - Order by might_have ok
ok 15 - retrieve_previous ok
ok 16 - search_like ok
Dubious, test returned 2 (wstat 512, 0x200)
Failed 1/17 subtests


cf. also
https://rt.cpan.org/Public/Bug/Display.html?id=134150

and

https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libclass-dbi-sweet-perl/15623876/log.gz


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmFV6ghfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ/nw//eZ5cN+xu0B9K9jy3ZR05U97WqFEOvEZb4ZHbuf+MoL9Xvg2kWZ6dVoku
gWl6WphLQoRXjCLIxgk2kIokfS7n8MLQuCBVQz/o6+VOV2csrE70wgkUnMfiT862
RZf5A8Q9aLLWLsFRVPeEOxZJENwM9L8jiA90q9ExyPYlluMoYC03sVJEozp+pB4L
i8xjClN2Br9oN8AxyPhsgn5lcm5w51FoIwnz6wsBmNO1y0KfTuYB5dQ9JWZvrtCY
0nqB4fdBwNdm64w1UkWCPF3zXN1SjaAnFEt0iGFZQ3P1RXi5X4vQOTbCvV6LnB7+
UHL+jQmkksL5RNOh9FUx27DNLrc5csuQ4C01VhWxPVSYzBOtArlBrIfPeSMvXnmU
4sCZ5r7MFiw3Ub08AQtEPeVCrpIdfmio3ATmjVtpy/mbxsW8xJ1LoRSBecYfdAVj
NeSXYYZkxRJKUk1TpMfyDa3FExqcbnAqUKjnJdlXK8osbbNzRbdkc9OrJTSTumvO
bEhGB10t1CgujRP+fZVliGRvAdOltOfsrAxoLEH8yo0v2GJmgzuwA1tuOXUZqWvP
c+HRTmpsznM3x47ctmA/GbC/lZbKW7spqVUWy/qae8HsTUAf7OGAq4B8l6rRID/1
yrZlc7PLfmllrGzngl5JyOji4r5nEzvVo8PPZqKjOGCWgV67J6s=
=xDHP
-END PGP SIGNATURE-

Bug#995308: marked as done (libcrypt1: symlink points to libpthread)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 18:34:35 +0200
with message-id 
and subject line Re: libcrypt1: symlink points to libpthread
has caused the Debian Bug report #995308,
regarding libcrypt1: symlink points to libpthread
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995308: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995308
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libcrypt1
Version: 1:4.4.18-4
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: shichimohed...@protonmail.com

Dear Maintainer,

Recently I have upgraded from Buster to Bullseye and, among other things, have 
installed libcrypt1 package.
Curiuosly enough, I found out that the symlink that should have been pointing 
to crypto library (/lib/x86_64-linux-gnu/libcrypto.so.1 -> libcrypto.so.1.1.0) 
pointed to libpthread.so.1 instead since upgrade.
Consequently, no binary linked to libcrypt was able to load; specifically, 
/sbin/sulogin crashed with "/lib/x86_64-linux-gnu/libcrypto.so.1: version 
`XCRYPT_2.0' not found", and so /bin/login service was unable to operate,
and I basically could not log into my system. I managed to find a way around 
the issue by deleting the symlink by hands and re-linking it properly, but I 
guess that a stable distribution should not behave like that.
When I run apt-get reinstall libcrypt1 the link changes to libpthread.so.1 
again, so it is clearly this package that causes trouble. As for now 
(09/29/2021 2:30 PM GMT) the bug keeps reappearing.

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcrypt1 depends on:
ii  libc6  2.31-13

libcrypt1 recommends no packages.

libcrypt1 suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Thank you Aurelien for your help, so this is user error.

On Sep 30, shichimohedron  wrote:

> 
> On Thursday, September 30th, 2021 at 12:08 PM, Aurelien Jarno 
>  wrote:
> 
> > It could be that this libpthread.so.1 file is actually a copy of an old
> >
> > libcrypt.so.1. It's something you can check with:
> >
> > readelf --dynamic /lib/x86_64-linux-gnu/libpthread.so.1 | grep SONAME
> 
> And it actually is:
> 
> ~# readelf --dynamic /lib/x86_64-linux-gnu/libpthread.so.1 | grep SONAME
>  0x000e (SONAME) Library soname: [libcrypt.so.1]

-- 
ciao,
Marco


signature.asc
Description: PGP signature
--- End Message ---

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

On 2021-09-30 17:18:46 +0200, Jonas Smedegaard wrote:
> This seems an upstream bug, and it would be helpful if you report it 
> upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/

OK. I'll do it tonight (I could also try to find the cause).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#994860: nvidia-driver: Does not build against new kernel 5.14.0-1-amd64

[Raphael Robatsch]

I hit this on Debian testing. Use the following patch at your own peril, it 
"works for me". Thanks for not upstreaming your driver nvidia, can't wait for 
GPU prices to crash so I can replace it with a card from a sane vendor.

Raphael

Fixes build on 5.14.6 kernels.
Index: nvidia-current-470.57.02/common/inc/nv-time.h
===
--- nvidia-current-470.57.02.orig/common/inc/nv-time.h
+++ nvidia-current-470.57.02/common/inc/nv-time.h
@@ -214,7 +214,7 @@ static inline NV_STATUS nv_sleep_ms(unsi
 // the requested timeout has expired, loop until less
 // than a jiffie of the desired delay remains.
 //
-current->state = TASK_INTERRUPTIBLE;
+current->__state = TASK_INTERRUPTIBLE;
 do
 {
 schedule_timeout(jiffies);
Index: nvidia-current-470.57.02/nvidia-drm/nvidia-drm-drv.c
===
--- nvidia-current-470.57.02.orig/nvidia-drm/nvidia-drm-drv.c
+++ nvidia-current-470.57.02/nvidia-drm/nvidia-drm-drv.c
@@ -922,7 +922,7 @@ static void nv_drm_register_drm_device(c
 dev->dev_private = nv_dev;
 nv_dev->dev = dev;
 if (device->bus == _bus_type) {
-dev->pdev = to_pci_dev(device);
+dev->dev = device;
 }

 /* Register DRM device to DRM sub-system */

Bug#995308: libcrypt1: symlink points to libpthread

[Aurelien Jarno]

On 2021-09-30 15:46, shichimohedron wrote:
> >Can you please try to call /usr/sbin/ldconfig.old to check if the wrong
> link is recreated? That's needed to confirm if ldconfig is the culprit
> here.
> >Can you confirm it's libpthread.so.1 and not libpthread.so.0? If so can
> you please tell how did you install that file?
> 
> Here is a shell log, literally
> 
> ~# ls -l /lib/x86_64-linux-gnu/ | grep libcrypt
> -rw-r--r--  1 root root266262 Apr 18 20:46 libcrypt.a
> lrwxrwxrwx  1 root root35 Apr 18 20:46 libcrypt.so -> 
> /lib/x86_64-linux-gnu/libcrypt.so.1
> lrwxrwxrwx  1 root root17 Apr 18 20:46 libcrypt.so.1 -> 
> libcrypt.so.1.1.0
> -rw-r--r--  1 root root202680 Apr 18 20:46 libcrypt.so.1.1.0
> ~# /usr/sbin/ldconfig.old
> ~# ls -l /lib/x86_64-linux-gnu/ | grep libcrypt
> -rw-r--r--  1 root root266262 Apr 18 20:46 libcrypt.a
> lrwxrwxrwx  1 root root35 Apr 18 20:46 libcrypt.so -> 
> /lib/x86_64-linux-gnu/libcrypt.so.1
> lrwxrwxrwx  1 root root15 Sep 30 07:53 libcrypt.so.1 -> 
> libpthread.so.1
> -rw-r--r--  1 root root202680 Apr 18 20:46 libcrypt.so.1.1.0

Thanks for this log, it confirms that the wrong link is created by
ldconfig.
 
> I struggle to reveal the origins of libpthread.so.1. It can easily be a 
> result of unqualified experimentation, but not necessarily. Of course, if 
> this is the case its presence in the system is completely my fault and not in 
> any sense yours. Anyway, dpkg -S doesn't match it with any of packages 
> currently installed, and another attempts to guess where the library comes 
> from didn't lead to any answer.

It could be that this libpthread.so.1 file is actually a copy of an old
libcrypt.so.1. It's something you can check with:

readelf --dynamic /lib/x86_64-linux-gnu/libpthread.so.1 | grep SONAME

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

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

[Drew Parsons]

Can anyone say why this Bug#980692 is still holding up the dask 
migration?


The bug is fully marked fixed and closed now, it shouldn't be in the way 
any more.


Drew

Bug#995392: ghostscript: ps2pdf trashes some characters

[Jonas Smedegaard]

Hi Vincent,

Quoting Vincent Lefevre (2021-09-30 16:53:01)
> The ps2pdf trashes some characters, making text non-searchable and 
> partly unreadable via pdftotext (even though the glyph appears to be 
> OK). There was no such issue in the recent past.

Thanks for reporting this!

This seems an upstream bug, and it would be helpful if you report it 
upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

Package: ghostscript
Version: 9.54.0~dfsg-5
Severity: grave
Justification: causes non-serious data loss

The ps2pdf trashes some characters, making text non-searchable and
partly unreadable via pdftotext (even though the glyph appears to
be OK). There was no such issue in the recent past.

LaTeX source to generate the PDF testcase:

\documentclass[12pt]{article}
\usepackage[T1]{fontenc}
\begin{document}
\thispagestyle{empty}
Test: float.
\end{document}

to be compiled with pdflatex.

I've attached 2 files:
  * chartest.pdf (testcase generated by pdflatex).
  * chartest-gs.pdf, which is the buggy result obtained with
"ps2pdf chartest.pdf chartest-gs.pdf".

chartest.pdf contains the text "Test: float." as expected.
But chartest-gs.pdf contains the text "Test: ŕoat.", which
is incorrect: "fl" has been replaced by "ŕ".

Removing "\usepackage[T1]{fontenc}" or the period after "float" makes
this issue disappear.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ghostscript depends on:
ii  libc6   2.32-4
ii  libgs9  9.54.0~dfsg-5

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.54.0~dfsg-5

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


chartest.pdf
Description: Adobe PDF document


chartest-gs.pdf
Description: Adobe PDF document

Bug#995387: dpkg: remove-on-upgrade deletes symlink targets owned by another package

[Andreas Beckmann]

Package: dpkg
Version: 1.20.6
Severity: grave
Justification: breaks unrelated packages by removing their conffiles

Hi Guillem,

attached is a small package demonstrating the misbehavior of
remove-on-upgrade which may delete symlink targets. It builds foo.deb
(which has 'remove-on-upgrade /etc/old-conffile') and bar.deb (which
has /etc/old-conffile -> /etc/new-conffile).

# dpkg -i /tmp/bar_1_all.deb
Selecting previously unselected package bar.
(Reading database ... 14303 files and directories currently installed.)
Preparing to unpack /tmp/bar_1_all.deb ...
Unpacking bar (1) ...
Setting up bar (1) ...
# dpkg --verify bar
# dpkg -i /tmp/foo_1_all.deb
Selecting previously unselected package foo.
(Reading database ... 14307 files and directories currently installed.)
Preparing to unpack /tmp/foo_1_all.deb ...
Unpacking foo (1) ...
Setting up foo (1) ...
Obsolete conffile '/etc/new-conffile' has been modified by you.
Saving as /etc/new-conffile.dpkg-old ...
# dpkg --verify bar
??5?? c /etc/new-conffile


The actual bug where I encountered this misbehavior is
  #994971: OpenCL not working with latest Nvidia driver
and it was an error of debhelper converting rm_conffile to remove-on-upgrade
but dpkg played its part by deleting the symlink target instead of the
symlink itself, but it should rather do nothing (or print a diagnostic) if
the to-be-removed file is not a plain file.

At least there is an error if it is a directory:

# mkdir /etc/old-conffile
# dpkg -i /tmp/foo_1_all.deb
Selecting previously unselected package foo.
(Reading database ... 14304 files and directories currently installed.)
Preparing to unpack /tmp/foo_1_all.deb ...
Unpacking foo (1) ...
Setting up foo (1) ...
dpkg: warning: foo: conffile '/etc/old-conffile' is not a plain file or symlink 
(= '/etc/old-conffile')


Simplified, the nvidia use case the following:

Long ago, /etc/conffile was a conffile
That was later removed with rm_conffile
and since then the different co-installable drivers ship 
/etc/conffile-$driver_version instead
and a slave alternative exists as /etc/conffile pointing to the corresponding 
file of
the activated driver variant.
(The different drivers may require slightly different conffile content.)

Andreas


dpkg-bug-remove-on-upgrade.tar.gz
Description: application/gzip

Bug#995185: Reported and fixed upstream

[Julien Puydt]

Hi,

I reported upstream, a fix was found -- 2.21.1 should be out in a few
days.

Cheers,

J.Puydt

Processed: Test does fail

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + confirmed
Bug #994785 [src:python-ase] python-ase: autopkgtest regression on 
arm64/ppc64el: TestSlab.test_vibration_on_surface
Added tag(s) confirmed.
> forwarded -1 https://gitlab.com/ase/ase/-/issues/976
Bug #994785 [src:python-ase] python-ase: autopkgtest regression on 
arm64/ppc64el: TestSlab.test_vibration_on_surface
Set Bug forwarded-to-address to 'https://gitlab.com/ase/ase/-/issues/976'.

-- 
994785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994785
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#994785: Test does fail

[Andrius Merkys]

Control: tags -1 + confirmed
Control: forwarded -1 https://gitlab.com/ase/ase/-/issues/976

OK, this test does reproducibly fail at least on arm64 both during build
time and autopkgtest. I have forwarded the issue upstream.

Andrius

Bug#994971: OpenCL not working with latest Nvidia driver

[Andreas Beckmann]

On 28/09/2021 23.28, Sebastian Ramacher wrote:

This smells like #994919 in debhelper, i.e, nvidia-driver needs to be
rebuilt with a fixed debhelper version.


Thanks. That sounds plausible, and explains my problems to reliably 
reproduce it elsewhere.


Can we quickly find out which packages have been built with the buggy 
debhelper versions? (Or which packages have the remove-on-upgrade flag 
in their .conffiles) and binNMU them?


Please don't binNMU nvidia-graphics-drivers, yet, I still need to find a 
way to recover from this bug by somehow restoring the conffile.



Andreas

Processed: Re: Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 zbar-tools
Bug #995362 [src:zint, src:zbar] zint breaks zbar autopkgtest: unable to open 
file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory 
@ error/constitute.c/ReadImage/614
Bug reassigned from package 'src:zint, src:zbar' to 'zbar-tools'.
No longer marked as found in versions zbar/0.23.92-3 and zint/2.10.0-1.
Ignoring request to alter fixed versions of bug #995362 to the same values 
previously set
> notfound -1 zint/2.10.0-1
Bug #995362 [zbar-tools] zint breaks zbar autopkgtest: unable to open file 
`/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ 
error/constitute.c/ReadImage/614
Ignoring request to alter found versions of bug #995362 to the same values 
previously set
> owner -1 !
Bug #995362 [zbar-tools] zint breaks zbar autopkgtest: unable to open file 
`/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ 
error/constitute.c/ReadImage/614
Owner recorded as John Scott .

-- 
995362: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995362
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614

[John Scott]

Control: reassign -1 zbar-tools
Control: notfound -1 zint/2.10.0-1
Control: owner -1 !


I think I've partially identified what is happening.

It turns out that the version of zint in testing, despite being passed
the --filetype=SVG flag, actually produces a PNG, which in the past has
been happily processed by zbar.

This bug in zint seems to have been fixed in the new version, so that
specifying --filetype=SVG actually produces an SVG now. And it appears
that the error is coming from zbarimg, which as a matter of fact gives
the same error in a minimal chroot trying to process any SVG.

Outside a minimal chroot, on my desktop system, zbarimg seems to
process SVGs just fine. So this may be a case of a Recommends
(somewhere) not being installed wreaking havok, but in my opinion
zbarimg should still not behave this way when a Recommends is missing.

I'll debug this more later, but for now I'm reassigning the bug to
zbar-tools, since I see this is not an issue in zint.


signature.asc
Description: This is a digitally signed message part

Bug#995164: marked as done (golang-github-skip2-go-qrcode-dev: missing Breaks+Replaces: go-qrcode (<< 0.0~git20200617.da1b656))

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 12:33:34 +
with message-id 
and subject line Bug#995164: fixed in go-qrcode 0.0~git20200617.da1b656-3
has caused the Debian Bug report #995164,
regarding golang-github-skip2-go-qrcode-dev: missing Breaks+Replaces: go-qrcode 
(<< 0.0~git20200617.da1b656)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995164: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995164
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: golang-github-skip2-go-qrcode-dev
Version: 0.0~git20200617.da1b656-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'bullseye'.
It installed fine in 'bullseye', then the upgrade to 'bookworm' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack 
.../golang-github-skip2-go-qrcode-dev_0.0~git20200617.da1b656-2_all.deb ...
  Unpacking golang-github-skip2-go-qrcode-dev (0.0~git20200617.da1b656-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-github-skip2-go-qrcode-dev_0.0~git20200617.da1b656-2_all.deb
 (--unpack):
   trying to overwrite 
'/usr/share/gocode/src/github.com/skip2/go-qrcode/bitset/bitset.go', which is 
also in package go-qrcode 0.0~git20190110.dc11ecd-2+b6
  Errors were encountered while processing:
   
/var/cache/apt/archives/golang-github-skip2-go-qrcode-dev_0.0~git20200617.da1b656-2_all.deb


cheers,

Andreas


go-qrcode=0.0~git20190110.dc11ecd-2+b6_golang-github-skip2-go-qrcode-dev=0.0~git20200617.da1b656-2.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: go-qrcode
Source-Version: 0.0~git20200617.da1b656-3
Done: Aloïs Micard 

We believe that the bug you reported is fixed in the latest version of
go-qrcode, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 995...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aloïs Micard  (supplier of updated go-qrcode package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 30 Sep 2021 14:07:28 +0200
Source: go-qrcode
Architecture: source
Version: 0.0~git20200617.da1b656-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 
Changed-By: Aloïs Micard 
Closes: 995164
Changes:
 go-qrcode (0.0~git20200617.da1b656-3) unstable; urgency=medium
 .
   * Team upload.
   * Add missing Breaks and Replaces. (Closes: #995164)
Checksums-Sha1:
 a4e51cb5e9cc9925d13128e4bd3b66ab4db069e1 2345 
go-qrcode_0.0~git20200617.da1b656-3.dsc
 7b443b272546aaf80f38c1d3148b8e7e12c3f65c 3560 
go-qrcode_0.0~git20200617.da1b656-3.debian.tar.xz
 f86bb8406572e5a2d4439b71f571c087e39b 6657 
go-qrcode_0.0~git20200617.da1b656-3_amd64.buildinfo
Checksums-Sha256:
 592135d26e30f168d894dac133396567adc4ed98b8269e19b71a7e7cf4a6c84b 2345 
go-qrcode_0.0~git20200617.da1b656-3.dsc
 b610f027205b4bf1b32d3494d45a27d46a3951339c58a604a14566382aaacd84 3560 
go-qrcode_0.0~git20200617.da1b656-3.debian.tar.xz
 1e4c637e5ff842da22dd2a4b7214bcbd12e91b5e0e6a56ac7921b9707be6c301 6657 
go-qrcode_0.0~git20200617.da1b656-3_amd64.buildinfo
Files:
 0387990cf4a8fa07c7a487f82d1d9f63 2345 golang optional 
go-qrcode_0.0~git20200617.da1b656-3.dsc
 0d8e685509db2ad5ba0aac9108330fef 3560 golang optional 
go-qrcode_0.0~git20200617.da1b656-3.debian.tar.xz
 726ddb469213e7743bdb8cd621b09390 6657 golang optional 
go-qrcode_0.0~git20200617.da1b656-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEECYc16JDXWgmzZBaOGg64LwcfXv4FAmFVqa0QHGFsb2lzQG1p
Y2FyZC5sdQAKCRAaDrgvBx9e/jw5D/wKe53lYvS6PBcpsRB0ho/OHhh6SMsnLwUE
PRCEfY8xf1MCJ84BZSQQ2gp8CbmJpCjtf4+byArCe67KuK8XU1nJ+N2IEfyIKW8d
ck7dyS4unHy8Bqp52jPQG+aWO+3Dh4nSOxqCL8oDjw6KCDmhLlLbeNyMCWaRr5sT
4bK+RDtLPNtmzoj2lFcV1TJppfiYSQw/wPZqxPLMQdb6Bvrkl5T7a1dYejHHl5z3
OZx3IDg1opNgYhPtlOi3nzvGid77vBEqVmgtHY3oc0aFGEXokIQ1aN6EfxvbMaye

Bug#995163: marked as done (golang-github-jessevdk-go-flags-dev: missing Breaks+Replaces: golang-go-flags-dev (<< 1.4.0-3~))

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 12:33:40 +
with message-id 
and subject line Bug#995163: fixed in golang-go-flags 1.4.0-5
has caused the Debian Bug report #995163,
regarding golang-github-jessevdk-go-flags-dev: missing Breaks+Replaces: 
golang-go-flags-dev (<< 1.4.0-3~)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995163: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995163
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: golang-github-jessevdk-go-flags-dev
Version: 1.4.0-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../golang-github-jessevdk-go-flags-dev_1.4.0-4_all.deb 
...
  Unpacking golang-github-jessevdk-go-flags-dev (1.4.0-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-github-jessevdk-go-flags-dev_1.4.0-4_all.deb 
(--unpack):
   trying to overwrite 
'/usr/share/gocode/src/github.com/jessevdk/go-flags/arg.go', which is also in 
package golang-go-flags-dev 1.4.0-2
  Errors were encountered while processing:
   /var/cache/apt/archives/golang-github-jessevdk-go-flags-dev_1.4.0-4_all.deb

The exising Breaks+Replaces are insufficiently versioned: (<< 1.4.0-2~)
they don't cover the last version (1.4.0-2) before the package rename.


cheers,

Andreas


golang-go-flags-dev=1.4.0-2_golang-github-jessevdk-go-flags-dev=1.4.0-4.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: golang-go-flags
Source-Version: 1.4.0-5
Done: Aloïs Micard 

We believe that the bug you reported is fixed in the latest version of
golang-go-flags, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 995...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aloïs Micard  (supplier of updated golang-go-flags 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 30 Sep 2021 14:18:02 +0200
Source: golang-go-flags
Architecture: source
Version: 1.4.0-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 
Changed-By: Aloïs Micard 
Closes: 995163
Changes:
 golang-go-flags (1.4.0-5) unstable; urgency=medium
 .
   * Team upload.
   * d/control: Fix Break+Replaces (Closes: #995163).
Checksums-Sha1:
 13dd3245e8d2e00ca45336384b9a44ed17672486 2391 golang-go-flags_1.4.0-5.dsc
 cd8d195da9f97643f23b692d8014b327a2202214 4808 
golang-go-flags_1.4.0-5.debian.tar.xz
 206f69154751d3e5aaabec9d275b8d9407c5f00e 6525 
golang-go-flags_1.4.0-5_amd64.buildinfo
Checksums-Sha256:
 57c3b23372c52a8045d78f0a1b8c5170fab76e06fe3910bb250ca7f60852a73d 2391 
golang-go-flags_1.4.0-5.dsc
 abd4ec22508e11dc2fe583ef79740bd8e409c2da3819917fd5d30222a8288b66 4808 
golang-go-flags_1.4.0-5.debian.tar.xz
 f3366a848cfce5b30b4174929efa2ef3445fc889303c00cbbc3934c688fbdfb1 6525 
golang-go-flags_1.4.0-5_amd64.buildinfo
Files:
 d6fb97bd2f2bebb0b415e6b40f62f80a 2391 golang optional 
golang-go-flags_1.4.0-5.dsc
 71de9ba7110ca8a37fb7d56b433a5f23 4808 golang optional 
golang-go-flags_1.4.0-5.debian.tar.xz
 04ed736058a33aef544ac4b9618f9ac6 6525 golang optional 
golang-go-flags_1.4.0-5_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEECYc16JDXWgmzZBaOGg64LwcfXv4FAmFVrC8QHGFsb2lzQG1p
Y2FyZC5sdQAKCRAaDrgvBx9e/mcED/9i1juPVwbo01DMczNtH0E814gaWwzyn8U6
6jR4gxLpTxpecK3Tzv+vkDdwtC5CQ2rBgI3J1LpruzWcitvqKCJkyj7eET2BTGkj
xtyTovE6CYM5Q1UQGcrThkTZYtCpqnxVpNtmgOjEDPQ7I7jNCOb4LpFsKWoW+lJy
uJrvNbQMDZv5WVsomxM0y6VvOtpct3O9WCLkVDPAtNGeei9t/Eiw7VbgufNN9FJt
fc27Y9hqmw9ntg/FMNWxY0ba7w5Ny/cF/UkKKu4WBkcwQQYT2xURX4qPbFP3taWA
L6FzC+pR6R9TyL1q0ITDmkl3ZvtSiER2uZ0Ysiu11VubYzmFaADpk1Vw4rSDJXJ5
eSH1wBCsluZ2waP5ArJZs3vGYs4mCIi9/iUTbFAslokwa0JqVyMXX2KboA/qCQh7
/rUHk3yC1LBh2SpAVaWBRteMAs8msGw2cDrl1t+YVS4hgNNLcboJ+2dCCFb2Y+2u

Bug#995163: marked as pending in golang-go-flags

[Aloïs Micard]

Control: tag -1 pending

Hello,

Bug #995163 in golang-go-flags reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-go-flags/-/commit/d5a7d497bed0292f251a8e29692d19ef1fd4b4ea


Fix Break+Replaces

Closes: #995163


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/995163

Processed: Bug#995163 marked as pending in golang-go-flags

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #995163 [golang-github-jessevdk-go-flags-dev] 
golang-github-jessevdk-go-flags-dev: missing Breaks+Replaces: 
golang-go-flags-dev (<< 1.4.0-3~)
Added tag(s) pending.

-- 
995163: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995163
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#993016: marked as done (libdap: Includes rpc/types.h which is no longer provided by libc6-dev)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 12:04:05 +
with message-id 
and subject line Bug#993016: fixed in libdap 3.20.8-2
has caused the Debian Bug report #993016,
regarding libdap: Includes rpc/types.h which is no longer provided by libc6-dev
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
993016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993016
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libdap
Version: 3.20.7-6
Severity: serious
Tags: upstream
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The recent changes in glibc break libdap and its rdeps:

 In file included from /usr/include/libdap/XDRUtils.h:37,
  from /usr/include/libdap/Sequence.h:50,
  from libdap_headers.h:52,
  from ogr_dods.h:44,
  from ogrdodsdriver.cpp:29:
 /usr/include/libdap/xdr-datatypes.h:16:10: fatal error: rpc/types.h: No such 
file or directory
16 | #include 
   |  ^

/usr/include/rpc/types.h was provided by libc6-dev in bullseye, but it is no 
longer included in libc6-dev (2.31-17).

Kind Regards,

Bas
--- End Message ---
--- Begin Message ---
Source: libdap
Source-Version: 3.20.8-2
Done: Alastair McKinstry 

We believe that the bug you reported is fixed in the latest version of
libdap, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 993...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alastair McKinstry  (supplier of updated libdap package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 30 Sep 2021 08:47:12 +0100
Source: libdap
Architecture: source
Version: 3.20.8-2
Distribution: unstable
Urgency: medium
Maintainer: Alastair McKinstry 
Changed-By: Alastair McKinstry 
Closes: 993016 995325
Changes:
 libdap (3.20.8-2) unstable; urgency=medium
 .
   * Ship dap-config, drop libdap-dev multi-arch, as it breaks
 gdal. Closes: #995325
   * Change d/tests/control to use pkg-config rather than dap-config
   * Acl we build with libtirpc-dev. Closes: #993016
Checksums-Sha1:
 2d2cbf13d7ee99b9cc32f0dae69573c85633558a 2436 libdap_3.20.8-2.dsc
 b93c5980d51ce9b7fc7f4b7b1dc03ec6d5c877c2 14076 libdap_3.20.8-2.debian.tar.xz
Checksums-Sha256:
 a59e40307db85f4c67683c93a851838ca50548fdd2375ab8cfa618bdc7143218 2436 
libdap_3.20.8-2.dsc
 5c981429e155eaeb2a58f9154fae0b5509b346919f3a9389aff282f5c3644854 14076 
libdap_3.20.8-2.debian.tar.xz
Files:
 33aec4d5a0cbcc8e1ac0d8227cd10edf 2436 utils optional libdap_3.20.8-2.dsc
 a6e75b00f2c5939824a806a8b1980175 14076 utils optional 
libdap_3.20.8-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmFVoukACgkQy+a7Tl2a
06Wf1hAAlE0r35J7fqIkoHfkUxPOO6Eeg+JBJfrdov7e+D+JEGwc9uDFnzPatnPP
9Mf9NoDlD3Hi8IXWa+Flsrzp5MrQRmnbQkVgV8DpOHTOEalItwGAfnJdounkW8A7
dH+u2vLR1FxYyVA/Q+Tk5G3nldmC4z4iyGXe4ZWOHlR3p/paaIPpcogtZncPdY3F
4Si4Gjc/SzCLe4fYklJHj6clmki3WxtNSUHEgAiMKNbsT3K6hTLzHMnlstO+4pEj
k4h8Bq4d1bEVdMNevkedDkMuc418niERdFim+mR31cWBZXR6jbDlQsUAly2EcfyA
h/uUUI9urcqHVuicdCEIHgQqDV35g95DngpdEWyTvqih16Qc20EX99uPMsIBVbf3
Ho3ana9PTcH2Hh2K+PaxGHqI0nxD3N4Hz40LQxiOO6xzpxPLcAXMiUJY4gI+DCMF
enkOfb3YvImcG01wq3r+tneCmhLS3iWl67vinhuJbE7Jg0IDo9Phmiw90wSV/SzT
B4aI6qu9QZs9DI9Jj5RnryXIcZ4YqCnQU71/JBX0JkdXzgGjExfdcNC0ABYFBqlF
Be5YO/YrCwHgK629REW+YgLpa6FTntZP5mdJ3p+Ow33eVPvyZneSq0gwVelWs41r
0d8J8MjHMuOkpincZhZKZfWTEqA9LJghDVdNNjmOXmfohbswO3A=
=JZPE
-END PGP SIGNATURE End Message ---

Bug#995325: marked as done (libdap: dap-config removal breaks autopkgtest and gdal build)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 12:04:05 +
with message-id 
and subject line Bug#995325: fixed in libdap 3.20.8-2
has caused the Debian Bug report #995325,
regarding libdap: dap-config removal breaks autopkgtest and gdal build
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995325: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995325
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libdap
Version: 3.20.8-1
Severity: serious
Justification: makes the package in question unusable or mostly so
Control: affects -1 src:gdal

Dear Maintainer,

Removal of dap-config broke the libdap autopkgtest:

 autopkgtest [06:50:51]: test command1: set -e ; dap-config --help 2> /dev/null
 autopkgtest [06:50:51]: test command1: [---
 autopkgtest [06:50:51]: test command1: ---]
 autopkgtest [06:50:51]: test command1:  - - - - - - - - - - results - - - - - 
- - - - -
 command1 FAIL non-zero exit status 127

https://ci.debian.net/data/autopkgtest/testing/amd64/libd/libdap/15607353/log.gz

This blocks testing migration.

The removal also broke the gdal build which uses dap-config to get the required 
flags:

 configure:40397: checking for qh_new_qhull in -lqhull
 configure:40420: gcc -o conftest -DHAVE_AVX_AT_COMPILE_TIME 
-DHAVE_SSSE3_AT_COMPILE_TIME -DHAVE_SSE_AT_COMPILE_TIME -g -O2 
-ffile-prefix-map=/build/gdal-3.3.2+dfsg=. -fstack-protector-strong -Wformat 
-Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now conftest.c -lqhull  -lgeos_c -lodbc -lodbcinst 
-lkmlbase -lkmldom -lkmlengine -lkmlxsd -lkmlregionator -lexpat -lxerces-c 
-lpthread -lopenjp2 -L/usr/lib/x86_64-linux-gnu/hdf5/serial -lnetcdf 
-L/usr/lib/x86_64-linux-gnu/hdf5/serial/lib -lhdf5  -lmfhdfalt -ldfalt -logdi 
-lgif -lcharls -lgeotiff -lpng -lcfitsio -lpq -lzstd -llzma  -lsqlite3 -lproj   
-lsqlite3 -ltiff -ljpeg -ldeflate -lz -lpthread -lm -lrt -ldl  -L/usr/lib 
-lspatialite -L/usr/lib -ldap++ -lpthread -lrx  -lcurl -lxml2 >&5
 /usr/bin/ld: cannot find -ldap++
 /usr/bin/ld: cannot find -lrx
 collect2: error: ld returned 1 exit status

#994670 suggested:

"
 a) Delete dap-config and go without it. Any dap-config users (e.g.
gadap) need to be converted to using pkg-config.
 b) Revert your change and drop Multi-Arch: same from libdap-dev. As bad
as this may sound, it doesn't actually break that many practical use
cases as coinstallability of -dev packages is rarely required.
"

Option a) implies that the dap-config users like gdal are adapted to use 
pkg-config before dap-config is removed.

Please consider re-instating dap-config.

Kind Regards,

Bas
--- End Message ---
--- Begin Message ---
Source: libdap
Source-Version: 3.20.8-2
Done: Alastair McKinstry 

We believe that the bug you reported is fixed in the latest version of
libdap, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 995...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alastair McKinstry  (supplier of updated libdap package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 30 Sep 2021 08:47:12 +0100
Source: libdap
Architecture: source
Version: 3.20.8-2
Distribution: unstable
Urgency: medium
Maintainer: Alastair McKinstry 
Changed-By: Alastair McKinstry 
Closes: 993016 995325
Changes:
 libdap (3.20.8-2) unstable; urgency=medium
 .
   * Ship dap-config, drop libdap-dev multi-arch, as it breaks
 gdal. Closes: #995325
   * Change d/tests/control to use pkg-config rather than dap-config
   * Acl we build with libtirpc-dev. Closes: #993016
Checksums-Sha1:
 2d2cbf13d7ee99b9cc32f0dae69573c85633558a 2436 libdap_3.20.8-2.dsc
 b93c5980d51ce9b7fc7f4b7b1dc03ec6d5c877c2 14076 libdap_3.20.8-2.debian.tar.xz
Checksums-Sha256:
 a59e40307db85f4c67683c93a851838ca50548fdd2375ab8cfa618bdc7143218 2436 
libdap_3.20.8-2.dsc
 5c981429e155eaeb2a58f9154fae0b5509b346919f3a9389aff282f5c3644854 14076 
libdap_3.20.8-2.debian.tar.xz
Files:
 33aec4d5a0cbcc8e1ac0d8227cd10edf 2436 utils optional libdap_3.20.8-2.dsc
 a6e75b00f2c5939824a806a8b1980175 14076 utils optional 

Bug#995308: libcrypt1: symlink points to libpthread

[Aurelien Jarno]

On 2021-09-29 10:33, Flying Sea Buckthorn wrote:
> Package: libcrypt1
> Version: 1:4.4.18-4
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: shichimohed...@protonmail.com
> 
> Dear Maintainer,
> 
> Recently I have upgraded from Buster to Bullseye and, among other things, 
> have installed libcrypt1 package.
> Curiuosly enough, I found out that the symlink that should have been pointing 
> to crypto library (/lib/x86_64-linux-gnu/libcrypto.so.1 -> 
> libcrypto.so.1.1.0) pointed to libpthread.so.1 instead since upgrade.

Can you confirm it's libpthread.so.1 and not libpthread.so.0? If so can
you please tell how did you install that file?

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#995308: libcrypt1: symlink points to libpthread

[Aurelien Jarno]

On 2021-09-30 02:45, Marco d'Itri wrote:
> Maybe then the glibc people know what could make ldconfig create a link 
> to the wrong library.

I don't see how that could happen. ldconfig uses the SONAME entry to
create the links. First we have to get confirmed that ldconfig is the
culprit.

> On Sep 30, shichimohedron  wrote:
> 
> > >Does it still happen after something like this?
> > 
> > > mv /usr/sbin/ldconfig /usr/sbin/ldconfig.old
> > > cp -a /bin/true /usr/sbin/ldconfig
> > > dpkg -i .../libcrypt1_*.deb
> > 
> > I tried this out, and it worked: the effect disappeared completely, 
> > reinstallation binds the links to proper files. Thank you and sorry for 
> > bothering!
> 
> -- 
> ciao,
> Marco



-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#995308: libcrypt1: symlink points to libpthread

[Aurelien Jarno]

On 2021-09-29 22:07, shichimohedron wrote:
> >Is this about libcrypto.so.1 or libcrypt.so.1?
> This is about libcrypt.so.1. Sorry for mistyping the filename.
> 
> >Does it still happen after something like this?
> 
> > mv /usr/sbin/ldconfig /usr/sbin/ldconfig.old
> > cp -a /bin/true /usr/sbin/ldconfig
> > dpkg -i .../libcrypt1_*.deb
> 
> I tried this out, and it worked: the effect disappeared completely, 
> reinstallation binds the links to proper files. Thank you and sorry for 
> bothering!

Can you please try to call /usr/sbin/ldconfig.old to check if the wrong
link is recreated? That's needed to confirm if ldconfig is the culprit
here.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#995215: marked as done (postgresql-semver: Wait for acceptance of backport)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 03:34:34 -0700
with message-id 

and subject line Version info added too late to prevent migration
has caused the Debian Bug report #995215,
regarding postgresql-semver: Wait for acceptance of backport
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995215: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995215
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postgresql-semver
Severity: serious

The sole purpose of this bug is to keep version 0.31.1-3 out of
testing until version 0.31.1-2~bpo11+1 is in backports.
--- End Message ---
--- Begin Message ---
Version info added too late to prevent migration.

Bug no longer needed. Glosing.--- End Message ---

Bug#981671: marked as done (golang-github-linkedin-goavro: autopkgtest failure on 32bit)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 10:34:04 +
with message-id 
and subject line Bug#981671: fixed in golang-github-linkedin-goavro 2.10.1-1
has caused the Debian Bug report #981671,
regarding golang-github-linkedin-goavro: autopkgtest failure on 32bit
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
981671: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981671
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: golang-github-linkedin-goavro
Version: 2.9.7-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/i386/g/golang-github-linkedin-goavro/9937378/log.gz

...
   debian/rules override_dh_auto_test
make[1]: Entering directory 
'/tmp/autopkgtest-lxc.5wjzm3kf/downtmp/autopkgtest_tmp'
cp -a fixtures obj*/src/github.com/linkedin/goavro/
dh_auto_test -O--buildsystem=golang
cd obj-i686-linux-gnu && go test -vet=off -v -p 2 
github.com/linkedin/goavro github.com/linkedin/goavro/examples/165 
github.com/linkedin/goavro/examples/ab2t 
github.com/linkedin/goavro/examples/arw 
github.com/linkedin/goavro/examples/avroheader 
github.com/linkedin/goavro/examples/nested 
github.com/linkedin/goavro/examples/soe 
github.com/linkedin/goavro/examples/splice
# github.com/linkedin/goavro [github.com/linkedin/goavro.test]
src/github.com/linkedin/goavro/binary_test.go:42:50: constant 
-9223372036854775808 overflows int
src/github.com/linkedin/goavro/integer_test.go:56:42: constant 
9223372036854775807 overflows int
src/github.com/linkedin/goavro/integer_test.go:57:35: constant 
-9223372036854775808 overflows int
src/github.com/linkedin/goavro/integer_test.go:63:35: constant 
1359702038045356208 overflows int
src/github.com/linkedin/goavro/integer_test.go:64:35: constant 138521149956 
overflows int
src/github.com/linkedin/goavro/integer_test.go:65:35: constant 17730707194372 
overflows int
src/github.com/linkedin/goavro/integer_test.go:67:35: constant 2269530520879620 
overflows int
src/github.com/linkedin/goavro/integer_test.go:69:35: constant 
5959107741628848600 overflows int
src/github.com/linkedin/goavro/integer_test.go:73:35: constant 
-5513458701470791632 overflows int
FAILgithub.com/linkedin/goavro [build failed]
?   github.com/linkedin/goavro/examples/165 [no test files]
?   github.com/linkedin/goavro/examples/ab2t[no test files]
?   github.com/linkedin/goavro/examples/arw [no test files]
?   github.com/linkedin/goavro/examples/avroheader  [no test files]
?   github.com/linkedin/goavro/examples/nested  [no test files]
?   github.com/linkedin/goavro/examples/soe [no test files]
?   github.com/linkedin/goavro/examples/splice  [no test files]
FAIL
dh_auto_test: error: cd obj-i686-linux-gnu && go test -vet=off -v -p 2 
github.com/linkedin/goavro github.com/linkedin/goavro/examples/165 
github.com/linkedin/goavro/examples/ab2t 
github.com/linkedin/goavro/examples/arw 
github.com/linkedin/goavro/examples/avroheader 
github.com/linkedin/goavro/examples/nested 
github.com/linkedin/goavro/examples/soe 
github.com/linkedin/goavro/examples/splice returned exit code 2
make[1]: *** [debian/rules:8: override_dh_auto_test] Error 25
--- End Message ---
--- Begin Message ---
Source: golang-github-linkedin-goavro
Source-Version: 2.10.1-1
Done: Aloïs Micard 

We believe that the bug you reported is fixed in the latest version of
golang-github-linkedin-goavro, which is due to be installed in the Debian FTP 
archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 981...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aloïs Micard  (supplier of updated 
golang-github-linkedin-goavro package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 30 Sep 2021 12:10:37 +0200
Source: golang-github-linkedin-goavro
Architecture: source
Version: 2.10.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 
Changed-By: Aloïs Micard 
Closes: 981671
Changes:
 golang-github-linkedin-goavro (2.10.1-1) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Debian Janitor ]
   * Bump debhelper from old 12 to 13.
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
 

Bug#995365: Cannot import module: ImportError: cannot import name 'ENOENT' from 'sphinx.util.osutil'

[Thomas Perret]

Package: python3-sphinxcontrib.plantuml
Version: 0.5-6
Severity: grave
Tags: fixed-upstream

Dear maintainer,

With the lastest sphinx update (>4.0), the plantuml contrib module fails
to import and render the package unusable:

$ python3 -c 'import sphinxcontrib.plantuml'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/sphinxcontrib/plantuml.py", line 23, in 

from sphinx.util.osutil import ensuredir, ENOENT
ImportError: cannot import name 'ENOENT' from 'sphinx.util.osutil' 
(/usr/lib/python3/dist-packages/sphinx/util/osutil.py)

This has been fixed upstream[0] and is available in upstream releases 0.21 and
0.22 (the latest at the moment).

Please package one of these. If you don't have time to package it, I'll
happily help you and create a merge request on salsa.

Cheers,
Thomas

[0]: 
https://github.com/sphinx-contrib/plantuml/commit/c5e56fb2b28366a37519a550de894bc55da4fec5


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-sphinxcontrib.plantuml depends on:
ii  plantuml  1:1.2020.2+ds-1
ii  python3   3.9.2-3
ii  python3-docutils  0.16+dfsg-4
ii  python3-sphinx4.2.0-2

python3-sphinxcontrib.plantuml recommends no packages.

python3-sphinxcontrib.plantuml suggests no packages.

-- debconf-show failed

Processed: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614

[Debian Bug Tracking System]

Processing control commands:

> found -1 zint/2.10.0-1
Bug #995362 [src:zint, src:zbar] zint breaks zbar autopkgtest: unable to open 
file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory 
@ error/constitute.c/ReadImage/614
Marked as found in versions zint/2.10.0-1.
> found -1 zbar/0.23.92-3
Bug #995362 [src:zint, src:zbar] zint breaks zbar autopkgtest: unable to open 
file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory 
@ error/constitute.c/ReadImage/614
Marked as found in versions zbar/0.23.92-3.

-- 
995362: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995362
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614

[Paul Gevers]

Source: zint, zbar
Control: found -1 zint/2.10.0-1
Control: found -1 zbar/0.23.92-3
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of zint the autopkgtest of zbar fails in testing
when that autopkgtest is run with the binary packages of zint from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
zint   from testing2.10.0-1
zbar   from testing0.23.92-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. As there isn't
much output in the log, I can't really see what's going wrong.

Currently this regression is blocking the migration of zint to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=zint

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zbar/15624264/log.gz

autopkgtest [00:22:52]: test command3: echo "test" | zint --direct
--filetype=SVG -i - | zbarimg -
autopkgtest [00:22:52]: test command3: [---
ERROR: unable to open file
`/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or
directory @ error/constitute.c/ReadImage/614
autopkgtest [00:22:53]: test command3: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995330: marked as done (ggcov: FTBFS)

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 09:48:40 +
with message-id 
and subject line Bug#995330: fixed in ggcov 0.10-4
has caused the Debian Bug report #995330,
regarding ggcov: FTBFS
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995330: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995330
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: ggcov
Version: 0.1.0-3
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish

Hi Alastair,

ggcov currently fails to build from source in Debian and Ubuntu because the
gcc version is disallowed by the tool:

[...]
g++ --version: "g++ (Debian 10.3.0-11) 10.3.0"
ERROR: (test000) testrunner failed, see log
ERROR: (test001) no output files from tggcov
ERROR: (test002) no output files from tggcov
ERROR: (test004) no output files from tggcov
ERROR: (test005.1) no output files from tggcov
ERROR: (test006) no output files from tggcov
ERROR: (test007) no output files from tggcov
ERROR: (test008.0) no output files from tggcov
ERROR: (test009) no output files from tggcov
ERROR: (test010) no output files from tggcov
ERROR: (test011.1) no output files from tggcov
ERROR: (test013) no output files from tggcov
ERROR: (test014) no output files from tggcov
ERROR: (test015.a001) no output files from tggcov
ERROR: (test016.1) no output files from tggcov
PASS: (test021) unit test for libpopt / fakepopt.c
ERROR: (test026) no output files from tggcov
ERROR: (test029) no output files from tggcov
ERROR: (test030) no output files from tggcov
ERROR: (test033) no output files from tggcov
ERROR: (test034) no output files from tggcov
Total: 1/21 tests passed
[...]

In Debian testing/unstable, this is 10.3.0.  In Ubuntu this is currently
11.2.0.

This is related to bug #835931.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: ggcov
Source-Version: 0.10-4
Done: Alastair McKinstry 

We believe that the bug you reported is fixed in the latest version of
ggcov, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 995...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alastair McKinstry  (supplier of updated ggcov package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 30 Sep 2021 10:33:13 +0100
Source: ggcov
Architecture: source
Version: 0.10-4
Distribution: unstable
Urgency: medium
Maintainer: Alastair McKinstry 
Changed-By: Alastair McKinstry 
Closes: 995330
Changes:
 ggcov (0.10-4) unstable; urgency=medium
 .
   * Standards-Version: 4.6.0; no changes needed
   * Move to debhelper-compat level 13
   * Update compilers patch for 10.3 / 11.2. CLoses: #995330
   * Point vcs-git to DEP-14 branches
   * Add debian/gbp.conf file
Checksums-Sha1:
 33f9781bb0bc97095bec3e5c16f0498aa0f2f165 1950 ggcov_0.10-4.dsc
 4578d17a8a2afa1b78c3a7dd1dd782910ea83422 19352 ggcov_0.10-4.debian.tar.xz
Checksums-Sha256:
 c393ef3f8ef1fc5372ef0351510eb1511fb957d378453f42895b092e570c3b72 1950 
ggcov_0.10-4.dsc
 d4059263db707a2314ca190872845d8873d40febb074cca2d834ea31cb50 19352 
ggcov_0.10-4.debian.tar.xz
Files:
 ebce40ee141ef5b221c2ee46dd125537 1950 devel optional ggcov_0.10-4.dsc
 a9e1996d73693bf3c771a7934876e2f9 19352 devel optional 
ggcov_0.10-4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmFVhYQACgkQy+a7Tl2a
06UaEw/+KW2v6MEgNFOzE07jzPxbSeh8JLPU/xiVyTX8YtIVRcFRD+oMn8Ei/pL1
aC4hUuX8oOihPv5uziazbIYGmPIrZTdIKdGJfBgwoRj7S6EdzUmeWwDhb0IjFRkl
3YfAtPLmIzXt1zkppVC5iuhxG2NwfZeVoCDA1t1Ryz/7ka97baGOneU2OfqmY45I
WLe1c64yNGGEdNFh0XVNVDdKY6oOvS6rFmVYQAGTaF/2NBQxQ5xsdF2MkeJNgm7j
3Jw9K1FOfJeqIV5rfyLa0/49YOaaMjiTujoDSTSwQi4yjL536qCrOpuyT8DUmZSA
SnMi9aXx1rNQ10OuZZe5K5oyYddDcLUMGCHfYJ3Xu2OPEtFJs6U/ONiV5UHm0sGw
OVkBamtD0fwiz8XYoD65CYv1dOxY/MWd6+srYOZ9XdxrZGtzzJAJCPFMJWeMkpoN

Bug#995361: rust-trybuild: autopkgtest needs update for new version of rust-dissimilar: failed to select a version for the requirement `dissimilar = "=1.0.1"`

[Paul Gevers]

Source: rust-trybuild
Version: 1.0.33-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, rust-dissimi...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:rust-dissimilar

Dear maintainer(s),

With a recent upload of rust-dissimilar the autopkgtest of rust-trybuild fails
in testing when that autopkgtest is run with the binary packages of
rust-dissimilar from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
rust-dissimilarfrom testing1.0.2-1
rust-trybuild  from testing1.0.33-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. To me it looks like
you have to update to the latest version of rust-dissimilar.

Currently this regression is blocking the migration of rust-dissimilar to
testing [1]. Of course, rust-dissimilar shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
rust-dissimilar was intended and your package needs to update to the new 
situation.

If this is a real problem in your package (and not only in your autopkgtest),
the right binary package(s) from rust-dissimilar should really add a versioned
Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is
nice even if the issue is only in the autopkgtest as it helps the migration
software to figure out the right versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rust-dissimilar

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-trybuild/15624246/log.gz

 Running 
`/tmp/tmp.KEOBX5QpBM/target/x86_64-unknown-linux-gnu/debug/deps/test-a66e232e07b24214`

running 1 test
error: failed to select a version for the requirement `dissimilar = "=1.0.1"`
candidate versions found which didn't match: 1.0.2
location searched: directory source `/tmp/tmp.KEOBX5QpBM/registry` (which is 
replacing registry `https://github.com/rust-lang/crates.io-index`)
required by package `trybuild v1.0.33 
(/usr/share/cargo/registry/trybuild-1.0.33)`
perhaps a crate was updated and forgotten to be re-vendored?
ERROR: failed to read cargo metadata: EOF while parsing a value at line 1 
column 0

test test ... FAILED

failures:

 test stdout 
thread 'test' panicked at 'tests failed', src/run.rs:38:13
stack backtrace:
   0: std::panicking::begin_panic
 at /usr/src/rustc-1.50.0/library/std/src/panicking.rs:519:12
   1: trybuild::runrun::{{closure}}
 at ./src/run.rs:38:13
   2: core::result::Result::unwrap_or_else
 at /usr/src/rustc-1.50.0/library/core/src/result.rs:825:23
   3: trybuild::runrun
 at ./src/run.rs:36:23
   4: ::drop
 at ./src/lib.rs:282:13
   5: core::ptr::drop_in_place
 at /usr/src/rustc-1.50.0/library/core/src/ptr/mod.rs:179:1
   6: test::test
 at ./tests/test.rs:22:1
   7: test::test::{{closure}}
 at ./tests/test.rs:2:1
   8: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.50.0/library/core/src/ops/function.rs:227:5
   9: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.50.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.


failures:
test

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; 
finished in 0.13s



OpenPGP_signature
Description: OpenPGP digital signature

Processed: rust-trybuild: autopkgtest needs update for new version of rust-dissimilar: failed to select a version for the requirement `dissimilar = "=1.0.1"`

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:rust-dissimilar
Bug #995361 [src:rust-trybuild] rust-trybuild: autopkgtest needs update for new 
version of rust-dissimilar: failed to select a version for the requirement 
`dissimilar = "=1.0.1"`
Added indication that 995361 affects src:rust-dissimilar

-- 
995361: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995361
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995360: pytorch: autopkgtest regression: fft: ATen not compiled with MKL support

[Paul Gevers]

Source: pytorch
Version: 1.8.1-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of pytorch the autopkgtest of pytorch fails in testing
when that autopkgtest is run with the binary packages of pytorch from
unstable. It passes when run with only packages from testing. In tabular form:

   passfail
pytorchfrom testing1.8.1-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can you 
please
investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log file
quoted below. The migration software adds source package from unstable to the
list if they are needed to install packages from pytorch/1.8.1-2. I.e. due to
versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=pytorch

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pytorch/15624807/log.gz

=== FAILURES ===
__ TestFFTCPU.test_stft_requires_complex_cpu ___

self = 
device = 'cpu'

def test_stft_requires_complex(self, device):
x = torch.rand(100)
>   y = x.stft(10, pad_mode='constant')

test_spectral_ops.py:939:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3/dist-packages/torch/tensor.py:453: in stft
return torch.stft(self, n_fft, hop_length, win_length, window, center,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

input = tensor([0., 0., 0., 0., 0., 0.0290, 0.4019, 0.2598, 
0.3666,
0.0583, 0.7006, 0.0518, 0.46810910, 0.2323,
0.7269, 0.1187, 0.3951, 0.7199, 0.7595, 0.5311, 0., 0., 0.,
0., 0.])
n_fft = 10, hop_length = None, win_length = None, window = None, center = True
pad_mode = 'constant', normalized = False, onesided = None
return_complex = None

def stft(input: Tensor, n_fft: int, hop_length: Optional[int] = None,
 win_length: Optional[int] = None, window: Optional[Tensor] = None,
 center: bool = True, pad_mode: str = 'reflect', normalized: bool = 
False,
 onesided: Optional[bool] = None,
 return_complex: Optional[bool] = None) -> Tensor:
r"""Short-time Fourier transform (STFT).

.. warning::
From version 1.8.0, :attr:`return_complex` must always be given
explicitly for real inputs and `return_complex=False` has been
deprecated. Strongly prefer `return_complex=True` as in a future
pytorch release, this function will only return complex tensors.

Note that :func:`torch.view_as_real` can be used to recover a real
tensor with an extra last dimension for real and imaginary 
components.

The STFT computes the Fourier transform of short overlapping windows of 
the
input. This giving frequency components of the signal as they change 
over
time. The interface of this function is modeled after the librosa_ stft 
function.

.. _librosa: https://librosa.org/doc/latest/generated/librosa.stft.html

Ignoring the optional batch dimension, this method computes the 
following
expression:

.. math::
X[m, \omega] = \sum_{k = 0}^{\text{win\_length-1}}%
\text{window}[k]\ \text{input}[m \times 
\text{hop\_length} + k]\ %
\exp\left(- j \frac{2 \pi \cdot \omega 
k}{\text{win\_length}}\right),

where :math:`m` is the index of the sliding window, and :math:`\omega` 
is
the frequency that :math:`0 \leq \omega < \text{n\_fft}`. When
:attr:`onesided` is the default value ``True``,

* :attr:`input` must be either a 1-D time sequence or a 2-D batch of 
time
  sequences.

* If :attr:`hop_length` is ``None`` (default), it is treated as equal to
  ``floor(n_fft / 4)``.

* If :attr:`win_length` is ``None`` (default), it is treated as equal to
  :attr:`n_fft`.

* :attr:`window` can be a 1-D tensor of size :attr:`win_length`, e.g., 
from
  :meth:`torch.hann_window`. If :attr:`window` is ``None`` (default), 
it is
  treated as if having :math:`1` everywhere in the window. If
  :math:`\text{win\_length} < \text{n\_fft}`, :attr:`window` will be 
padded on
  both sides to length :attr:`n_fft` before being applied.

* If :attr:`center` is ``True`` (default), 

Processed: ruby-gitlab-labkit: autopkgtest needs update for new version of ruby-jaeger-client: Could not find 'jaeger-client' (~> 0.10)

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:ruby-jaeger-client
Bug #995359 [src:ruby-gitlab-labkit] ruby-gitlab-labkit: autopkgtest needs 
update for new version of ruby-jaeger-client: Could not find 'jaeger-client' 
(~> 0.10)
Added indication that 995359 affects src:ruby-jaeger-client

-- 
995359: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995359
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995359: ruby-gitlab-labkit: autopkgtest needs update for new version of ruby-jaeger-client: Could not find 'jaeger-client' (~> 0.10)

[Paul Gevers]

Source: ruby-gitlab-labkit
Version: 0.12.2-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, ruby-jaeger-cli...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ruby-jaeger-client

Dear maintainer(s),

With a recent upload of ruby-jaeger-client the autopkgtest of
ruby-gitlab-labkit fails in testing when that autopkgtest is run with
the binary packages of ruby-jaeger-client from unstable. It passes when
run with only packages from testing. In tabular form:

   passfail
ruby-jaeger-client from testing1.1.0-2
ruby-gitlab-labkit from testing0.12.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It looks to me
that you have to make your package compatible with the next version of
ruby-jaeger-client.

Currently this regression is blocking the migration of
ruby-jaeger-client to testing [1]. Of course, ruby-jaeger-client
shouldn't just break your autopkgtest (or even worse, your package), but
it seems to me that the change in ruby-jaeger-client was intended and
your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from ruby-jaeger-client should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-jaeger-client

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-gitlab-labkit/15624242/log.gz


┌──┐
│ Checking Rubygems dependency resolution on ruby2.7
   │
└──┘

GEM_PATH= ruby2.7 -e gem\ \"gitlab-labkit\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in
block in activate_dependencies': Could not find 'jaeger-client' (~>
0.10) among 98 total gem(s) (Gem::MissingSpecError)
Checked in
'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
at:
/usr/share/rubygems-integration/all/specifications/gitlab-labkit-0.12.2.gemspec,
execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs':
Could not find 'jaeger-client' (~> 0.10) - did find:
[jaeger-client-1.1.0] (Gem::MissingSpecVersionError)
Checked in
'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
, execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'





OpenPGP_signature
Description: OpenPGP digital signature

Processed: ruby-graphql breaks ruby-batch-loader autopkgtest: uninitialized constant GraphQL::StaticValidation::Validator::Timeout

[Debian Bug Tracking System]

Processing control commands:

> found -1 ruby-graphql/1.11.8-2
Bug #995358 [src:ruby-graphql, src:ruby-batch-loader] ruby-graphql breaks 
ruby-batch-loader autopkgtest: uninitialized constant 
GraphQL::StaticValidation::Validator::Timeout
Marked as found in versions ruby-graphql/1.11.8-2.
> found -1 ruby-batch-loader/2.0.1+dfsg-2
Bug #995358 [src:ruby-graphql, src:ruby-batch-loader] ruby-graphql breaks 
ruby-batch-loader autopkgtest: uninitialized constant 
GraphQL::StaticValidation::Validator::Timeout
Marked as found in versions ruby-batch-loader/2.0.1+dfsg-2.

-- 
995358: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995358
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995358: ruby-graphql breaks ruby-batch-loader autopkgtest: uninitialized constant GraphQL::StaticValidation::Validator::Timeout

[Paul Gevers]

Source: ruby-graphql, ruby-batch-loader
Control: found -1 ruby-graphql/1.11.8-2
Control: found -1 ruby-batch-loader/2.0.1+dfsg-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of ruby-graphql the autopkgtest of
ruby-batch-loader fails in testing when that autopkgtest is run with the
binary packages of ruby-graphql from unstable. It passes when run with
only packages from testing. In tabular form:

   passfail
ruby-graphql   from testing1.11.8-2
ruby-batch-loader  from testing2.0.1+dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of ruby-graphql to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-graphql

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-batch-loader/15624241/log.gz


Failures:

  1) GraphQL integration resolves BatchLoader fields lazily with GraphQL
Interpreter
 Failure/Error: result = schema.execute(query)

 NameError:
   uninitialized constant GraphQL::StaticValidation::Validator::Timeout
 # ./spec/graphql_spec.rb:35:in `test'
 # ./spec/graphql_spec.rb:15:in `block (2 levels) in '
 # --
 # --- Caused by: ---
 # NameError:
 #   uninitialized constant
GraphQL::StaticValidation::Validator::Timeout
 #   ./spec/graphql_spec.rb:35:in `test'

  2) GraphQL integration resolves BatchLoader fields lazily
 Failure/Error: result = schema.execute(query)

 NameError:
   uninitialized constant GraphQL::StaticValidation::Validator::Timeout
 # ./spec/graphql_spec.rb:35:in `test'
 # ./spec/graphql_spec.rb:10:in `block (2 levels) in '
 # --
 # --- Caused by: ---
 # NameError:
 #   uninitialized constant
GraphQL::StaticValidation::Validator::Timeout
 #   ./spec/graphql_spec.rb:35:in `test'

Finished in 2.59 seconds (files took 0.62851 seconds to load)
31 examples, 2 failures

Failed examples:

rspec ./spec/graphql_spec.rb:14 # GraphQL integration resolves
BatchLoader fields lazily with GraphQL Interpreter
rspec ./spec/graphql_spec.rb:9 # GraphQL integration resolves
BatchLoader fields lazily



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995356: python-parameterized: autopkgtest regression: AssertionError in tearDownModule

[Paul Gevers]

Source: python-parameterized
Version: 0.8.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of python-parameterized the autopkgtest of
python-parameterized fails in testing when that autopkgtest is run with
the binary packages of python-parameterized from unstable. It passes
when run with only packages from testing. In tabular form:

   passfail
python-parameterized   from testing0.8.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-parameterized

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-parameterized/15609304/log.gz

 ERRORS

_ ERROR at teardown of
TestUnicodeDocstring.test_with_docstring_1_v_l_ _

def tearDownModule():
missing = sorted(list(missing_tests))
if not PY2:
>   assert_equal(missing, [])

/usr/lib/python3/dist-packages/parameterized/test.py:367:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3.9/unittest/case.py:829: in assertEqual
assertion_func(first, second, msg=msg)
/usr/lib/python3.9/unittest/case.py:1035: in assertListEqual
self.assertSequenceEqual(list1, list2, msg, seq_type=list)
/usr/lib/python3.9/unittest/case.py:1017: in assertSequenceEqual
self.fail(msg)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
msg = 'Lists differ: ["test_instance_method(\'foo0\', bar=None)",[461
chars]o\')"] != []\n\nFirst list contains 12 additiona...1, \'umask\',
\'getpid\')",\n-  "test_patch_no_expand(42, 51, \'umask\')",\n-
"test_wrapped_iterable_input(\'foo\')"]'

def fail(self, msg=None):
"""Fail immediately, with the given message."""
>   raise self.failureException(msg)
E   AssertionError: Lists differ: ["test_instance_method('foo0',
bar=None)",[461 chars]o')"] != []
E
E   First list contains 12 additional elements.
E   First extra element 0:
E   "test_instance_method('foo0', bar=None)"
E
E   + []
E   - ["test_instance_method('foo0', bar=None)",
E   -  "test_instance_method('foo1', bar=None)",
E   -  "test_instance_method('foo2', bar=42)",
E   -  'test_instance_method(42, bar=None)',
E   -  "test_mock_patch_standalone_function(42, 'umask')",
E   -  "test_naked_function('foo0', bar=None)",
E   -  "test_naked_function('foo1', bar=None)",
E   -  "test_naked_function('foo2', bar=42)",
E   -  'test_naked_function(42, bar=None)',
E   -  "test_patch_class_no_expand(42, 51, 'umask', 'getpid')",
E   -  "test_patch_no_expand(42, 51, 'umask')",
E   -  "test_wrapped_iterable_input('foo')"]

/usr/lib/python3.9/unittest/case.py:668: AssertionError




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995355: node-public-encrypt: autopkgtest regression: deprecation warning on stderr

[Paul Gevers]

Source: node-public-encrypt
Version: 4.0.0-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of node-public-encrypt the autopkgtest of
node-public-encrypt fails in testing when that autopkgtest is run with
the binary packages of node-public-encrypt from unstable. It passes when
run with only packages from testing. In tabular form:

   passfail
node-public-encryptfrom testing4.0.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. The test
itself passes, but it emits a deprecation warning on stderr. Currently
(I'm considering to change that), the default of autopkgtest is to fail
if there's output on stderr, you can opt-out by adding the allow-stderr
restriction. In my opinion (with release team member and ci-team member
hat on) deprecation warnings should *not* fail autopkgtests, so either
disable deprecation warnings (best solution) if you want to keep
autopkgtest failing on output to stderr or use the allow-stderr restriction.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=node-public-encrypt

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-public-encrypt/15629015/log.gz

command1 FAIL stderr: (node:4996) [DEP0005]
DeprecationWarning: Buffer() is deprecated due to security and usability
issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or
Buffer.from() methods instead.




OpenPGP_signature
Description: OpenPGP digital signature

Processed: ruby-async-http: autopkgtest needs update for new version of ruby-protocol-http: Could not find 'protocol-http' (~> 0.20.0)

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:ruby-protocol-http src:ruby-protocol-http1
Bug #995354 [src:ruby-async-http] ruby-async-http: autopkgtest needs update for 
new version of ruby-protocol-http: Could not find 'protocol-http' (~> 0.20.0)
Added indication that 995354 affects src:ruby-protocol-http and 
src:ruby-protocol-http1

-- 
995354: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995354
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995354: ruby-async-http: autopkgtest needs update for new version of ruby-protocol-http: Could not find 'protocol-http' (~> 0.20.0)

[Paul Gevers]

Source: ruby-async-http
Version: 0.52.5-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, 
ruby-protocol-h...@packages.debian.org, ruby-protocol-h...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ruby-protocol-http src:ruby-protocol-http1

Dear maintainer(s),

With a recent upload of ruby-protocol-http the autopkgtest of
ruby-async-http fails in testing when that autopkgtest is run with the
binary packages of ruby-protocol-http from unstable. It passes when run
with only packages from testing. In tabular form:

   passfail
ruby-protocol-http from testing0.22.5-1
ruby-async-httpfrom testing0.52.5-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. It looks to me
that you have to make your package compatible with the next version of
ruby-protocol-http

Currently this regression is blocking the migration of
ruby-protocol-http to testing [1]. Of course, ruby-protocol-http
shouldn't just break your autopkgtest (or even worse, your package), but
it seems to me that the change in ruby-protocol-http was intended and
your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from ruby-protocol-http should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
ruby-protocol-http/0.22.5-1. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=ruby-protocol-http

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-async-http/15624245/log.gz
autopkgtest [00:17:44]: test gem2deb-test-runner: [---

┌──┐
│ Checking Rubygems dependency resolution on ruby2.7
   │
└──┘

GEM_PATH= ruby2.7 -e gem\ \"async-http\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in
block in activate_dependencies': Could not find 'protocol-http' (~>
0.20.0) among 69 total gem(s) (Gem::MissingSpecError)
Checked in
'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
at:
/usr/share/rubygems-integration/all/specifications/async-http-0.52.5.gemspec,
execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs':
Could not find 'protocol-http' (~> 0.20.0) - did find:
[protocol-http-0.22.5] (Gem::MissingSpecVersionError)
Checked in
'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
, execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in

Bug#995353: ruby-protocol-http: autopkgtest regression on armhf and i386 (both 32 bits)

[Paul Gevers]

Source: ruby-protocol-http
Version: 0.22.5-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of ruby-protocol-http the autopkgtest of
ruby-protocol-http fails in testing when that autopkgtest is run with
the binary packages of ruby-protocol-http from unstable. It passes when
run with only packages from testing. I noticed that in testing, the test
is actually skipped, so your current test is sort of new. In tabular form:

   passfail
ruby-protocol-http from testing0.22.5-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. I notice that
the test that fails on armhf is about memory. The test *may* be fooled
by the shear amount of memory available on this system: 250 GB. However,
i386 also fails, so I suspect an issue with 32 bits in the test or binary.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-protocol-http

https://ci.debian.net/data/autopkgtest/testing/armhf/r/ruby-protocol-http/15629689/log.gz



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995328: marked as done (eccodes: FTBFS with CMake 3.21.x (Flow control statements are not properly nested))

[Debian Bug Tracking System]

Your message dated Thu, 30 Sep 2021 08:33:35 +
with message-id 
and subject line Bug#995328: fixed in eccodes 2.23.0-1.1
has caused the Debian Bug report #995328,
regarding eccodes: FTBFS with CMake 3.21.x (Flow control statements are not 
properly nested)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995328: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995328
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: eccodes
Version: 2.23.0-1
Severity: serious
Tags: ftbfs
Justification: makes the package in question unusable or mostly so
Control: block 994086 by -1

Dear Maintainer,

 -- [34mDEBUG - -[m
 -- ecbuild   3.6.1 /usr/share/ecbuild/cmake
 -- cmake 3.21.3/usr/bin/cmake
 -- -
 CMake Error at cmake/ecbuild_get_test_data.cmake:298 (endif):
   Flow control statements are not properly nested.
 Call Stack (most recent call first):
   cmake/ecbuild_system.cmake:194 (include)
   cmake/ecbuild_project.cmake:76 (include)
   CMakeLists.txt:24 (project)

https://buildd.debian.org/status/fetch.php?pkg=eccodes=amd64=2.23.0-1%2Bb1=1632933635=0

This seems to be caused by the recent update of cmake to 3.12.x.

Kind Regards,

Bas
--- End Message ---
--- Begin Message ---
Source: eccodes
Source-Version: 2.23.0-1.1
Done: Alastair McKinstry 

We believe that the bug you reported is fixed in the latest version of
eccodes, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 995...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alastair McKinstry  (supplier of updated eccodes package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 30 Sep 2021 08:52:35 +0100
Source: eccodes
Architecture: source
Version: 2.23.0-1.1
Distribution: unstable
Urgency: medium
Maintainer: Alastair McKinstry 
Changed-By: Alastair McKinstry 
Closes: 995328
Changes:
 eccodes (2.23.0-1.1) unstable; urgency=medium
 .
   [ Bas Couwenberg ]
   * Fix 'Flow control statements are not properly nested' error.
 (closes: #995328)
Checksums-Sha1:
 5a53c98913b54f834ffa1a3f22da962b7f4cefec 2703 eccodes_2.23.0-1.1.dsc
 9d4c52c2c7aa3d13b3941011a27ade87909145f5 14652 eccodes_2.23.0-1.1.debian.tar.xz
Checksums-Sha256:
 639e371ebc61a6d9641d4c1caff4cbd45b3ad7fc0ccbfaecda3aa3fcc72da9a1 2703 
eccodes_2.23.0-1.1.dsc
 e10b8d3ffce4df56d88c645f1e99e070a347cfc323c675f2b3b1b6812255bf10 14652 
eccodes_2.23.0-1.1.debian.tar.xz
Files:
 8ffcddce209fa3f7405aa3000f2abcff 2703 science optional eccodes_2.23.0-1.1.dsc
 f4ef59fd7128111d1722daf3ab0a943e 14652 science optional 
eccodes_2.23.0-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmFVcrAACgkQy+a7Tl2a
06XUEQ//fOktkJ5U4nTcWB/7H9vlu8zgUIw7Svtjhp5cfFpn8CsRcpzoiwyM1K1f
5rPC29lX4PiQQYlAOhLRb4E+IWiLViifnSIPT+e53wtH8ngaAvcU+CH0sXXoXVkT
VCwIwWCKfSeWwmnFVUEG8E9AJ30VZHOYOg8BsGDVSe9hpK3Jif4dWqDPMc0GNov7
WhxwbptaztDWOyveyZUjpH1JuH96Qqg+SGQafsAOOCnr/RJXsGmspu9jyDHOVfBP
qLhYf5/dxTZ6LZulf33Ir8M2pO1xC5V8m3g9DNe3MjkbMjSUGz4niR7uYfZLvtTq
e3aUz6BMq9lA3krCBiL42Aw00pNXgGzbIH4Zp8CWkZWCSiZKqXk4QIW1IBxlNkZv
+KFMu/yPRv/89Nwgky9OVtY1i+SoElmYhReih8z8vABe1gEpVfQOxV6jdRvTqaOW
e/nsVwAFqgPjJQgXXdeECV+ZAjpUFX9LtLOZgcaaUO7ykwe4s4daRD0QYDPbUB3p
1utne1unVbWvIqqlmrzLpuHJOWLcfopGB3bC2XF72I/uPd4HQtdvF3OHWI+RKDtM
GwXHzpvcdoeg9a2fbD/5aEsl8UTWjDG6tV2ml/arnlVoWRVXsrGpkibqJTJ5U4EU
OIy6uv8GwtMrrH9wWtoq5RMX9BAFmbcb4uV2KmlujcPGW8UlNOw=
=aGgX
-END PGP SIGNATURE End Message ---

Bug#995351: src:fonts-ipaexfont: fails to migrate to testing for too long: piuparts regression

[Paul Gevers]

Source: fonts-ipaexfont
Version: 00401-3
Severity: serious
Control: close -1 00401-4
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:fonts-ipaexfont has been trying to migrate
for 61 days [2] due to a piuparts regression which to my eye looks
genuine. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or its
(reverse-)dependencies. We expect maintainers to fix issues that hamper
the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=fonts-ipaexfont




OpenPGP_signature
Description: OpenPGP digital signature

Processed: src:fonts-ipaexfont: fails to migrate to testing for too long: piuparts regression

[Debian Bug Tracking System]

Processing control commands:

> close -1 00401-4
Bug #995351 [src:fonts-ipaexfont] src:fonts-ipaexfont: fails to migrate to 
testing for too long: piuparts regression
Marked as fixed in versions fonts-ipaexfont/00401-4.
Bug #995351 [src:fonts-ipaexfont] src:fonts-ipaexfont: fails to migrate to 
testing for too long: piuparts regression
Marked Bug as done

-- 
995351: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995351
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995349: ncbi-entrez-direct: FTBFS: no required module provides package github.com/fiam/gounidecode/unidecode

[Steve Langasek]

Source: ncbi-entrez-direct
Version: 14.6.20210224+dfsg-4
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish

Hi Aaron,

The ncbi-entrez-direct package currently fails to build in Debian unstable:

[...]
go build -v -gccgoflags '-g -O2 
-ffile-prefix-map=/tmp/ncbi-entrez-direct-14.6.20210224+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,-z,now -Wl,--as-needed' -o bin/rchive rchive.go common.go
rchive.go:40:2: no required module provides package 
github.com/fiam/gounidecode/unidecode: go.mod file not found in current 
directory or any parent directory; see 'go help modules'
rchive.go:41:2: no required module provides package github.com/klauspost/cpuid: 
go.mod file not found in current directory or any parent directory; see 'go 
help modules'
rchive.go:42:2: no required module provides package github.com/pbnjay/memory: 
go.mod file not found in current directory or any parent directory; see 'go 
help modules'
rchive.go:43:2: no required module provides package 
github.com/surgebase/porter2: go.mod file not found in current directory or any 
parent directory; see 'go help modules'
common.go:71:2: no required module provides package golang.org/x/text/runes: 
go.mod file not found in current directory or any parent directory; see 'go 
help modules'
common.go:72:2: no required module provides package 
golang.org/x/text/transform: go.mod file not found in current directory or any 
parent directory; see 'go help modules'
common.go:73:2: no required module provides package 
golang.org/x/text/unicode/norm: go.mod file not found in current directory or 
any parent directory; see 'go help modules'
make[1]: *** [debian/rules:130: bin/rchive] Error 1
[...]

This failure is also reproducible in Ubuntu, where I first noticed it:

  
https://launchpad.net/ubuntu/+source/ncbi-entrez-direct/14.6.20210224+dfsg-4/+build/21767337

This failure prevents the newer version of the package from being included
in the upcoming Ubuntu release.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#994567: closed by Debian FTP Masters (reply to Antonio Terceiro ) (Bug#994567: fixed in black 21.4b2-2)

[Paul Gevers]

Control: clone -1 -2
Control: retitle -2 black: autopkgtest; please don't exit 0 on unsupported archs
Control: reopen -2
Control: severity -2 important

Hi,

On 28-09-2021 23:24, Debian Bug Tracking System wrote:
>  black (21.4b2-2) unstable; urgency=medium
>  .
>* Team upload.
>* debian/tests/control: drop needs-root restriction
>* debian/tests/control: add new test dependencies (Closes: #994567)

This upload failed to address the following comment in the original
report:

> On top of fixing amd64, can you please stop "PASSING" on the other 
> architectures? If you can't test there, please use the (relatively 
> new) Architecture [0] field in the autopkgtest control file to skip 
> testing on those architectures, or add the skippable restriction and 
> exit with code 77.

Paul





OpenPGP_signature
Description: OpenPGP digital signature

Processed: Re: Bug#994567 closed by Debian FTP Masters (reply to Antonio Terceiro ) (Bug#994567: fixed in black 21.4b2-2)

[Debian Bug Tracking System]

Processing control commands:

> clone -1 -2
Bug #994567 {Done: Antonio Terceiro } [src:black] black: 
autopkgtest regression: ModuleNotFoundError: No module named 'aiohttp_cors'
Bug 994567 cloned as bug 995344
> retitle -2 black: autopkgtest; please don't exit 0 on unsupported archs
Bug #995344 {Done: Antonio Terceiro } [src:black] black: 
autopkgtest regression: ModuleNotFoundError: No module named 'aiohttp_cors'
Changed Bug title to 'black: autopkgtest; please don't exit 0 on unsupported 
archs' from 'black: autopkgtest regression: ModuleNotFoundError: No module 
named 'aiohttp_cors''.
> reopen -2
Bug #995344 {Done: Antonio Terceiro } [src:black] black: 
autopkgtest; please don't exit 0 on unsupported archs
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions black/21.4b2-2.
> severity -2 important
Bug #995344 [src:black] black: autopkgtest; please don't exit 0 on unsupported 
archs
Severity set to 'important' from 'serious'

-- 
994567: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994567
995344: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995344
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995328: eccodes: FTBFS with CMake 3.21.x (Flow control statements are not properly nested)

[Sebastiaan Couwenberg]

Control: tags -1 patch

The attached patch fixes the issue by updating disable-download-tests.patch.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru eccodes-2.23.0/debian/changelog eccodes-2.23.0/debian/changelog
--- eccodes-2.23.0/debian/changelog 2021-08-28 10:51:07.0 +0200
+++ eccodes-2.23.0/debian/changelog 2021-09-30 08:09:23.0 +0200
@@ -1,3 +1,11 @@
+eccodes (2.23.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix 'Flow control statements are not properly nested' error.
+(closes: #995328)
+
+ -- Bas Couwenberg   Thu, 30 Sep 2021 08:09:23 +0200
+
 eccodes (2.23.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru eccodes-2.23.0/debian/patches/disable-download-tests.patch 
eccodes-2.23.0/debian/patches/disable-download-tests.patch
--- eccodes-2.23.0/debian/patches/disable-download-tests.patch  2021-08-28 
10:51:07.0 +0200
+++ eccodes-2.23.0/debian/patches/disable-download-tests.patch  2021-09-30 
08:09:15.0 +0200
@@ -3,10 +3,8 @@
 Last-Updated: 2019-07-15
 Forwarded: not-needed
 
-Index: eccodes-2.21.0/cmake/ecbuild_get_test_data.cmake
-===
 eccodes-2.21.0.orig/cmake/ecbuild_get_test_data.cmake
-+++ eccodes-2.21.0/cmake/ecbuild_get_test_data.cmake
+--- a/cmake/ecbuild_get_test_data.cmake
 b/cmake/ecbuild_get_test_data.cmake
 @@ -10,7 +10,7 @@
  
  # function for downloading test data
@@ -25,7 +23,7 @@
  
  # perform the checksum if requested
  
-@@ -289,12 +289,12 @@ function( ecbuild_get_test_data )
+@@ -289,13 +289,13 @@ function( ecbuild_get_test_data )
  
  endif()
  
@@ -36,10 +34,12 @@
 -  ecbuild_debug("ecbuild_get_test_data: extracting 
${_p_DIRLOCAL}/${_p_NAME} (post-build for target ${_p_TARGET}")
 -  add_custom_command( TARGET ${_p_TARGET} POST_BUILD
 -  COMMAND ${CMAKE_COMMAND} -E chdir ${_p_DIRLOCAL} 
tar xvf ${_p_NAME} )
+-endif()
 +#if( _p_EXTRACT )
 +#  ecbuild_debug("ecbuild_get_test_data: extracting 
${_p_DIRLOCAL}/${_p_NAME} (post-build for target ${_p_TARGET}")
 +#  add_custom_command( TARGET ${_p_TARGET} POST_BUILD
 +# COMMAND ${CMAKE_COMMAND} -E chdir ${_p_DIRLOCAL} 
tar xvf ${_p_NAME} )
- endif()
++#endif()
  
  endfunction(ecbuild_get_test_data)
+ 

Processed: Re: eccodes: FTBFS with CMake 3.21.x (Flow control statements are not properly nested)

[Debian Bug Tracking System]

Processing control commands:

> tags -1 patch
Bug #995328 [src:eccodes] eccodes: FTBFS with CMake 3.21.x (Flow control 
statements are not properly nested)
Added tag(s) patch.

-- 
995328: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995328
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#994285: libseccomp: FTBFS on arm64, armhf, mips64el and mipsel

[Johannes Schauer Marin Rodrigues]

Hi Felix,

On Fri, 17 Sep 2021 07:15:16 +0200 Johannes Schauer Marin Rodrigues 
 wrote:
> you set the upstream bug to https://github.com/seccomp/libseccomp/issues/336
> but I don't think that is correct. The failures is not the same for the
> different architectures. mipsel fails different than arm64. I bisected
> upstream git on both architectures and found out that the arm64 failure was
> introduced in aa0f858 and the mipsel failure comes from e976080.
> 
> I contacted upstream about that here:
> https://github.com/seccomp/libseccomp/issues/338

the problem has no been present in unstable for three weeks. This is blocking
my work. Could we revert the offending commits or at least set a deadline up to
how long we want to wait for upstream to fix this issue?

I'm willing to put work into an NMU in case you don't have the time right now.

Thanks!

cheers, josch

signature.asc
Description: signature