date:20211026

Hi Nilesh,

Nilesh Patra, on 2021-10-27:
> On 27 October 2021 2:54:02 am IST, "Étienne Mollier"  
> wrote:
> >Maarten, I'm sorry that the round trip to NEW I contributed to
> >trigger stalled your package to not make it in the end.
> >On the good news side, now that the package cleared NEW
> ^
> 
> Uhh, sorry but I don't see how this "cleared" NEW? 1.0.1-4 has been rejected 
> from new, nor do I see any updates a tracker.d.o?
> 
> Do I miss something?

Sorry for the misunderstanding, I meant "cleared" as in "not in
NEW anymore", independently of whether it has been accepted or
rejected.

> And wouldn't new version of libcifpp undergo a proper library transition? -- 
> so is it not mandated for 1.0.1-4 to be accepted first?

At the time of writing, it seemed reasonable to me to transition
from 1.0.1-3, which is still in sid and testing, to 2.0.N-M.
But I might want to double check this at a more reasonable hour.
In any case, the transition would involve another round trip to
NEW, due to introduction of the new binary package libcifpp2
with the SONAME bump.

Thanks for your thoughs,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.

signature.asc
Description: PGP signature

Bug#992673: libgpuarray gemv, ger test fails

2021-10-26 Thread Rebecca N. Palmer


Control: tags -1 pending

(fixed in Salsa, as far as I consider it my bug)

It looks like both of these originate further down the stack, not in 
libgpuarray:


The *ger error code is an OpenCL compile failure from inside clblast, so 
likely either pocl or clblast.


The *gemv problem appears to be that the definition of gemv is 
y=alpha*A.dot(x)+beta*y, the spec allows and possibly requires the 
second term to be skipped entirely if beta is 0, clblas does this but 
clblast doesn't, and libgpuarray pygpu has a short form for beta=0 that 
uses an uninitialized (i.e. potentially NaN) y.  As a workaround I am 
changing this to a zero y, but it maybe should be fixed in clblast.

Bug#984093: [Debian-med-packaging] libcifpp_1.0.1-4_amd64.changes REJECTED

2021-10-26 Thread Nilesh Patra

Hi,

On 27 October 2021 2:54:02 am IST, "Étienne Mollier"  
wrote:
>Maarten, I'm sorry that the round trip to NEW I contributed to
>trigger stalled your package to not make it in the end.
>On the good news side, now that the package cleared NEW
^

Uhh, sorry but I don't see how this "cleared" NEW? 1.0.1-4 has been rejected 
from new, nor do I see any updates a tracker.d.o?

Do I miss something?

And wouldn't new version of libcifpp undergo a proper library transition? -- so 
is it not mandated for 1.0.1-4 to be accepted first?

Nilesh

Bug#997899: src:slurm-wlm: fails to migrate to testing for too long: piuparts regression and unresolved RC bug

2021-10-26 Thread Andreas Beckmann


The piuparts regression is

https://piuparts.debian.org/sid/source/s/slurm-wlm.html

0m23.7s DEBUG: Starting command: ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp5ugph549', '/usr/sbin/logrotate', 
'/etc/logrotate.d/slurmctld']
0m23.7s DUMP:
  /etc/logrotate.d/slurmctld:12 keyword 'size' not properly separated, found 
0x3d
0m23.7s DEBUG: Command ok: ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp5ugph549', '/usr/sbin/logrotate', 
'/etc/logrotate.d/slurmctld']
0m23.7s ERROR: FAIL: Logrotate file /etc/logrotate.d/slurmctld exits with error 
or has output with package removed

i.e. logrotate does not like the conffile.
I'd expect that to happen with the package installed, too.


Andreas

Bug#997914: python3-memcache: Return value of delete() is wrong

2021-10-26 Thread Return value of delete() is wrong

Package: python3-memcache
Version: 1.59-5
Severity: normal

Example:

import memcache
m = memcache.Client(["127.0.0.1:11211"])
m.set("foo", "bar")
print(m.delete("foo"))
print(m.delete("foo"))

Output:
1
1

delete() returns 1 even though the key no longer exists.
On the protocol level it looks different:

telnet localhost 11211
set foo 0 0 3 data
bar
STORED
delete foo
DELETED
delete foo
NOT_FOUND

Memcached returns NOT_FOUND, so I expect delete() to return 0, False or None, 
but not 1.

Bug#734408: add sdcv to stardict-xmlittre's Recommends

2021-10-26 Thread 肖盛文


Hi,

    For bug #734408[1], add sdcv to stardict-xmlittre's Recommends list 
is OK.


The GUI stardict-gtk can match stardict-xmlittre package perfectly.

I'm a new maintainer of the stardict package.

The new version stardict package is Reintroducing. [2]

Welcome to test it.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734408

[2] 
https://ftp-master.debian.org/new/stardict_3.0.7+git20210701.96b96d8+dfsg-1.html 



--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#997908: pocl: Assertion `td->printf_buffer != NULL' failed on armel/armhf

2021-10-26 Thread Rebecca N. Palmer


Source: pocl
Version: 1.8-1

(Filing this as something to refer to when I disable those tests; it may 
or may not actually be worth fixing.)


Since some time in August, all the packages that use pocl for their 
autopkgtests have been failing on armel/armhf (but not arm64) with either

Assertion `td->printf_buffer != NULL' (libgpuarray, theano, examl)
or
Fatal Python error: Aborted (pyopencl, gpyfft).

However, build-time tests using it (pocl itself, pyopencl) pass.

Bug#984093: libcifpp_1.0.1-4_amd64.changes REJECTED

Hi Thorsten, Hi Maarten,

Thorsten Alteholz, on 2021-10-26:
> please update the links in the PDB license block in your debian/copyright. 
> They don't seem to be valid anymore.
> 
> This is one of the reasons why all license information should be added to the 
> package.

Thanks Thorsten for your review!  Indeed the links are broken.
If I trust the Usage & Privacy page of RCSB Protein Data
Bank [1] (may this URL last a few years):
>> The wwPDB policy states that data files contained in the PDB
>> archive are available under the CC0 1.0 Universal (CC0 1.0)
>> Public Domain Dedication.
So this won't be a blocker in upcoming uploads with updated
copyright files hopefully.

[1]: https://www.rcsb.org/pages/policies

Maarten, I'm sorry that the round trip to NEW I contributed to
trigger stalled your package to not make it in the end.  On the
good news side, now that the package cleared NEW, you should
have free hands to move further on libcifpp 2 at your
convenience.

I cc'ed #984093 to postpone autoremoval of libcifpp and reduce
the time pressure.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#996006: ghemical: Segmentation fault when starting

2021-10-26 Thread Daniel Leidert

Am Mittwoch, dem 27.10.2021 um 03:18 +0200 schrieb Daniel Leidert:
> Am Dienstag, dem 26.10.2021 um 22:24 +0200 schrieb Bernhard Übelacker:
> > Dear Maintainer,
> > I could reproduce this inside a minimal qemu VM.
> 
> Thanks.
> 
> The program doesn't crash in Sid though.
> 
> Is it possible that we hit https://bugs.debian.org/958017 ?

Sorry, this is fixed in Bullseye already. I was reading the versions too
quickly. My fault. Still, the problem is not present in Sid.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#996006: ghemical: Segmentation fault when starting

2021-10-26 Thread Daniel Leidert

Am Dienstag, dem 26.10.2021 um 22:24 +0200 schrieb Bernhard Übelacker:
> Dear Maintainer,
> I could reproduce this inside a minimal qemu VM.

Thanks.

The program doesn't crash in Sid though.

Is it possible that we hit https://bugs.debian.org/958017 ?


Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#996693: google-http-client-java: please upgrade to version 1.40.1

2021-10-26 Thread Olek Wojnar

Markus,

Sorry for the slow reply, it has been an extraordinarily crazy time over
here recently. I'm barely keeping up on emails but I'm hoping that things
quiet down a little in the coming weeks and allow me to catch up. This is
near the top of my list!

-Olek

On Fri, Oct 22, 2021 at 6:41 AM Markus Koschany  wrote:

> Hi,
>
> could you both comment on Debian bugs #996693 and #996696 please?
>
> Regards,
>
> Markus
>

Bug#995996: dump: segfaults on long paths

2021-10-26 Thread Bernhard Übelacker


Dear Maintainer,
I guess this crash might be a stack exhaustion.

Given the function treescan in dirs.c would allocate
for locname 4096 bytes, and this function is called recursively,
we would fill up a stack of 8MB, which 'ulimit -s' shows at
my system as default.

Therefore another workaround might be to try to increase the
stack size e.g. by "ulimit -s 16384". (Have not tested it.)

And a possible software change could be to allocate the memory for
locname from heap by e.g. malloc instead of stack.
(If such deep hierarchies are being tried to support ...)

Kind regards,
Bernhard


https://sources.debian.org/src/dump/0.4b47-2/restore/dirs.c/#L292

Bug#997884: libgclib breaks cdbfasta autopkgtest: ABI breakage

Control: tags -1 confirmed

So, there is indeed an ABI breakage in libgclib.  I pushed some
changes on Salsa to bump the SONAME to version 3 [1].  Since
this would require a round trip through NEW, I also made some
welcome updates to the copyright file.  I haven't uploaded yet,
in case someone wishes to have a second look to make sure
nothing is missing, notably in the copyright file, and I will
try to recall to dput this tomorrow evening (UTC+2) if alright
and not sponsored already.

[1]: https://salsa.debian.org/med-team/libgclib/

In hope this helps,
Cheers,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#994165: pipewire: add pipewire-alsa/pipewire-jack packages

2021-10-26 Thread Paul Wise

On Tue, 2021-10-26 at 15:12 +0100, Simon McVittie wrote:

> libjack0-pipewire (Multi-Arch: same):
> libasound2-pipewire (Multi-Arch: same):

Please use pipewire-jack/pipewire-alsa for consistency and ease of use.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#997913: OVMF-ia32 does not provide file usable by -bios

2021-10-26 Thread Glenn Washburn

Package: ovmf-ia32
Version: 2020.11-4

Hello Maintainers,

I'd like ovmf-ia32 to install a file useable by QEMU's -bios option.
Currently the package only installs OVMF32_CODE_4M.secboot.fd and
OVMF32_VARS_4M.fd, but I believe I need a file that combines both code
and vars. According to the wiki[1], I believe I can use the existing
files using "-drive if=pflash,..." options, but that is not a great
option for me.

I've been using the file RELEASEIA32_OVMF.fd file from an edk2-nightly
build repo[2] successfully, so I know this is possible. And it looks
like its just building using the upstream build system. Let me know if
I can help with testing.

Thanks,
Glenn

[1] https://wiki.debian.org/SecureBoot/VirtualMachine
[2] https://github.com/retrage/edk2-nightly

Bug#996006: ghemical: Segmentation fault when starting

2021-10-26 Thread Bernhard Übelacker


Dear Maintainer,
I could reproduce this inside a minimal qemu VM.
Below [1] is a backtrace one instruction before the crash.
It looks like this "font" object has the create_hb_font
function pointer never initialized.
It also crashes with LANG=C set.

Unfortunately to me it is not certain if this is
an issue with pango or the application.
Additionally it looks like there were some changes in
pango (e.g. [2]) between the versions of bullseye and buster.
In the latter no such crash is observable.

Kind regards,
Bernhard


[1]
(rr) reverse-stepi
0x7fb5b32b8c33 in pango_font_get_hb_font 
(font=font@entry=0x558dd5dcdb30) at ../pango/fonts.c:1928
1928  priv->hb_font = PANGO_FONT_GET_CLASS (font)->create_hb_font 
(font);
1: x/i $pc
=> 0x7fb5b32b8c33 :  call   *0xc0(%r12)
(rr) bt
#0  0x7fb5b32b8c33 in pango_font_get_hb_font 
(font=font@entry=0x558dd5dcdb30) at ../pango/fonts.c:1928
#1  0x7fb5b32d4e13 in pango_font_get_hb_font_for_context 
(context=0x7ffc5f4f04c0, font=0x558dd5dcdb30) at ../pango/pangofc-shape.c:277
#2  pango_hb_shape (font=0x558dd5dcdb30, item_text=item_text@entry=0x7fb5b32dff4e  
"Zwölf Boxkämpfer jagen Viktor quer über den großen Sylter Deich.", item_length=item_length@entry=68, 
analysis=analysis@entry=0x7ffc5f4f0850, glyphs=glyphs@entry=0x558dd5acc6c0, 
paragraph_text=paragraph_text@entry=0x7fb5b32dff4e  "Zwölf Boxkämpfer jagen Viktor 
quer über den großen Sylter Deich.", paragraph_length=68) at ../pango/pangofc-shape.c:345
#3  0x7fb5b32d466f in pango_shape_with_flags (item_text=0x7fb5b32dff4e  
"Zwölf Boxkämpfer jagen Viktor quer über den großen Sylter Deich.", item_length=, paragraph_text=, paragraph_length=68, analysis=0x7ffc5f4f0850, 
glyphs=0x558dd5acc6c0, flags=PANGO_SHAPE_NONE) at ../pango/shape.c:205
#4  0x7fb5b32d4adb in pango_shape_full (item_text=, 
item_length=, paragraph_text=, paragraph_length=, analysis=analysis@entry=0x7ffc5f4f0850, glyphs=glyphs@entry=0x558dd5acc6c0) at 
../pango/shape.c:96
#5  0x7fb5b32d4af0 in pango_shape (text=, length=, analysis=analysis@entry=0x7ffc5f4f0850, glyphs=glyphs@entry=0x558dd5acc6c0) at 
../pango/shape.c:63
#6  0x7fb5b264b273 in itemize_string_foreach (font=font@entry=0x558dd5dcdb30, 
language=language@entry=0x0, str=, func=func@entry=0x7fb5b264b010 
, data=data@entry=0x7ffc5f4f08f0) at pangox.c:777
#7  0x7fb5b264b9b4 in get_font_metrics_from_string 
(metrics=0xd60e1730, str=, language=0x0, 
font=0x558dd5dcdb30) at pangox.c:922
#8  pango_x_font_get_metrics (font=0x558dd5dcdb30, language=0x0) at 
pangox.c:984
#9  0x558dd55f4556 in pangofont_wcl::ogl_InitPangoFont(char const*) 
(this=0x558dd5c19bc0, fs=0x558dd5623360 "courier 12") at pangofont_wcl.cpp:79
#10 0x558dd55f492a in oglview_wcl::InitGL() (this=0x558dd5c19bc0) at 
oglview_wcl.cpp:929
#11 0x7fb5b2c3eebe in base_wcl::LinkWnd(base_wnd*) 
(this=0x558dd5c19bc0, w=0x558dd5c18fa0) at base_wcl.cpp:111
#12 0x558dd55eb93d in project::AddGraphicsClient(custom_camera*, bool) 
(this=this@entry=0x558dd5a83df0, cam=0x558dd5c8fae0, cam@entry=0x0, 
detached=detached@entry=false) at project.cpp:622
#13 0x558dd561dc12 in gtk_project::DoSafeStart() (this=0x558dd5a83df0) 
at gtk_project.cpp:80
#14 0x558dd561aed3 in gtk_app::gtk_app() (this=0x558dd59fde70) at 
gtk_app.cpp:450
#15 0x558dd561b165 in gtk_app::GetAppX() () at gtk_app.cpp:465
#16 0x558dd55d49d4 in main(int, char**) (argc=, 
argv=) at gtk_main.cpp:116
(rr) x/1xg $r12+0xc0
0x558dd60e1e70: 0x


[2]

https://gitlab.gnome.org/GNOME/pango/-/commit/b5634799586ed8e3496ffc237b8d08e6d4e64d67

Bug#997912: libc6: tinydns stops replying to queries after libc6 upgrade from 2.31 to 2.32

2021-10-26 Thread Emil

Package: libc6
Version: 2.32-4
Severity: important

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (700, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=ro_RO (charmap=ISO-8859-2), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6 depends on:
ii  libgcc-s1  11.2.0-2

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.2-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.77
pn  glibc-doc  
ii  libc-l10n  2.32-4
ii  libnss-nis 3.1-4
ii  libnss-nisplus 1.3-4
ii  locales2.32-4

-- debconf information excluded

After upgrading libc6 from 2.31 to 2.32 tinydns stops replying to
queries after a while.

None of the tinydns files have been changed when this bug started
manifesting (nor the ELF or its data files).

Any version of libc6 2.32-1/2/3/4 will cause tinydns to ignore queries
after a while. dnscache runing on the same machine is not affected.

tinydns doesn't crash and there is nothing unusual in its logfiles.
If I kill the tinydns daemon then supervise will spawn another version
and it starts working again for a while, then stops replying to queries.

Rolling back libc6 to version 2.31-17 makes tinydns work normal again.

Bug#997873: gwenview: thumbnails not updated; sometimes thumbnails point at deleted image

2021-10-26 Thread Norbert Preining

forwarded 997873 https://bugs.kde.org/show_bug.cgi?id=61
thanks

I have forwarded it to the KDE bug tracker.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#997911: lintian: bash-term-in-posix-shell false positive for '<<<' in quoted strings

2021-10-26 Thread Andreas Beckmann

Package: lintian
Version: 2.110.0
Severity: important

Hi,

src:nvidia-graphics-driver has this in its bug script:

echo "<< $file >>"

which triggers a new lintian warning:

I: libcuda1: bash-term-in-posix-shell [usr/share/bug/libcuda1/script:126] '<<<'
I: libcuda1: bash-term-in-posix-shell [usr/share/bug/libcuda1/script:134] '<<<'


Andreas

Bug#997873: gwenview: thumbnails not updated; sometimes thumbnails point at deleted image

2021-10-26 Thread Norbert Preining

Hi Edward,

On Tue, 26 Oct 2021, Edward C. Jones wrote:
> If I replace an image with another image with the same name, the thumnail is
> not updated.  This is a well-known problem.  A work-around is to empty the KDE
> thumbnail directory.
> 
> If I replace an image with another image with the same name, when I click on a
> thumbnail, Gwenview displays the deleted image. It seems that Gwenview is
> maintaining
> a pointer to a deleted file.

I cannot reproduce *any* of the two behaviours when terminating gwenview
inbetween:

cd $(mktemp -d)
cp ~/photo1.jpg test.jpg
gwenview .
# shows the thumbnail of photo1.jpg, and opens test.jpg with the
# content of photo1.jpg
# quit gwenview
cp ~/photo2.jpg test.jpg
gwenview .
# shows the thumbnail of photo2.jpg, and opens test.jpg with the
# content of photo2.jpg

OTOH, when I keep gwenview running I see a different bevhaviour:
- thumbnail is properly updated
- actual photo is not update (still shows photo1.jpg!)

So it seems the thumbnail issue is fixed, but the display of the actual
photo not.

Thanks

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#55364: , I think you will be interested to learn more

2021-10-26 Thread Willy Flynn


  

  
  
I think you will be interested, 

Want to learn EVERYTHING about Essential Oils?Over the next days allow me to 
become your Essential Oils guide, as I take you on a journey to better 
understand how to incorporate these powerful potions into your everyday life.

Do you want to make
more while helping others too?

I’d love to chat a bit more about what we do and who we serve at Click here - 
"Essential Wealth & Wellness" [https://willyflynn.synduit.com/WEOL0001] as I 
take you
on a journey to better understand how to incorporate these powerful natural
plant potions.You already have the skills to do just that, but if you’re 
reading this, you’re likely feeling you can achieve more in life and are 
underutilized. Isn’t it time to make a change?

Let me know if you’d
like to chat sometime this week about how we as a community:


 Create Wealth & Wellness
 Free Training & coaching
 member sites!


Looking forward to
hearing from you!

Willy Flynn

wi...@willyflynn.com [mailto:wi...@willyflynn.com]

Cell: +27 (0) 82 652
1500

Whatsapp: +27 (0)
82 652 1500

Telegram: https://t.me/willyflynn [https://t.me/willyflynn]



  
  Prefer to stop these emails? Remove yourself here. 
[https://willyflynn.org/u/139ls12qj910vpuyydbo/n3r18yps9k1dxum0vhbd/?jqr7c0n1abi5xgf09qdcbcmemwfi13xrzk41e9w1cj]

Bug#997909: xapian-bindings: FTBFS with ruby3.0: diff: debian/tmp/usr/lib/ruby/vendor_ruby/3.0.0/xapian.rb: No such file or directory

2021-10-26 Thread Olly Betts

On Tue, Oct 26, 2021 at 06:34:06PM -0300, Antonio Terceiro wrote:
> > rb=debian/tmp`/usr/bin/ruby3.0 -rrbconfig -e 'puts 
> > RbConfig::CONFIG["vendorlibdir"]'`/xapian.rb; \
> > for v in 2.7; do \
> > if [ "$v" != "3.0" ] ; then \
> > set -e; \
> > rb_old=debian/tmp`/usr/bin/ruby$v -rrbconfig -e 'puts 
> > RbConfig::CONFIG["vendorlibdir"]'`/xapian.rb; \
> > diff "$rb_old" "$rb"; \
> > rm -rf "$rb_old" debian/tmp/usr/share/doc/xapian-bindings-ruby$v; \
> > fi; \
> > done; \
> > mv "$rb" debian/tmp/usr/lib/ruby/vendor_ruby
> > diff: debian/tmp/usr/lib/ruby/vendor_ruby/3.0.0/xapian.rb: No such file or 
> > directory
> > make[1]: *** [debian/rules:359: override_dh_auto_install] Error 2

I strongly suspect (but haven't yet tested) that the problem is simply
this hard-coded reference to the Ruby version starting `2.` in
debian/rules:

RUBY_VERSIONS := $(shell ruby -rruby_debian_dev -e 'print 
RubyDebianDev::RUBY_CONFIG_VERSION.values.grep(/^2\.[1-9]/).join(" ")')

I'll test the obvious fix there when I get a chance, but I know the
upstream code builds and works with Ruby 3.0, so please don't let
xapian-bindings hold up starting the transition.

Cheers,
Olly

Bug#997884: libgclib breaks cdbfasta autopkgtest: ABI breakage?

Control: affects -1 src:gffread 0.12.1-4

Hi Paul,

On Tue, 26 Oct 2021 16:58:28 +0200 Paul Gevers  wrote:
> [1] https://qa.debian.org/excuses.php?package=libgclib
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/cdbfasta/16212088/log.gz
> 
> + cdbfasta ebola.fasta
> cdbfasta: symbol lookup error: cdbfasta: undefined symbol: _Z8GReallocPPvm
> autopkgtest [22:12:39]: test run-unit-tests

Thank you for the heads up!  This looks to also affect gffread
0.12.1-4 [2].  Looking that up…

[2]: 
https://ci.debian.net/data/autopkgtest/testing/amd64/g/gffread/16212089/log.gz

Have a good evening,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/6, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#997910: RFP: pydyf -- A low-level PDF generator library (python)

2021-10-26 Thread Daniel Kahn Gillmor

Package: wnpp
Severity: wishlist

* Package name: pydyf
  Version : 0.1.1
  Upstream Author : CourtBouillon 
* URL : https://www.courtbouillon.org/pydyf
* License : BSD 3-clause
  Programming Lang: Python
  Description : A low-level PDF generator library (python)

pydyf is a low-level PDF generator written in Python and based on PDF
specification 1.7.

This is useful to have in debian because the latest revision of
weasyprint (53) depends on pydyf instead of cairo.

Bug#997897: Please replace links to alioth by salsa

2021-10-26 Thread Holger Wansing

Package: libccid
Severity: minor



Am 26. Oktober 2021 18:06:04 MESZ schrieb Corrado Campisano 
:
>hello,
>I was trying to make libccid work and noticed that in the package page:
>https://packages.debian.org/bullseye/libccid
>
>there is a link to the alioth server:
>http://pcsclite.alioth.debian.org/section.html
>
>which has been dismissed and replaced by salsa:
>https://wiki.debian.org/Alioth
>
>so, the new link should be like this:
>https://salsa.debian.org/rousseau/CCID/
>
>
>I'm quite sure this is not the only package with such an error, but can't
>tell which ones.

This has to be fixed in the package description
of the relevant package.

So turning this into a bugreport against libccid.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#997902: llvm-toolchain-13: autopkgtest regression on amd64|arm64: debian/qualify-clang.sh: llvm manpage are missing (using llc as an example)

2021-10-26 Thread Simon McVittie

On Tue, 26 Oct 2021 at 21:54:51 +0200, Sylvestre Ledru wrote:
> Le 26/10/2021 à 20:57, Simon McVittie a écrit :
> > The check that is failing is
> >
> >> if test /usr/share/man/man1/llc-$VERSION.1.gz; then
> > but I assume this should have been something more like:
> > if ! test -f "/usr/share/man/man1/llc-$VERSION.1.gz"; then
> 
> hmm, bizarre, I fixed it before. I guess it has been removed during a
> merge?!

Looks like the version of "Bring back the llvm manpages (Closes: #995684)"
on the 12 branch is correct, but the version of that commit on the 13
branch is different and has this bug.

smcv

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

2021-10-26 Thread Zameer Manji

Hello Vincent,

I see and understand the rationale of upstream to deprecate this
functionality.
>From the commit you linked I see another commit [0] which says:

> Loading an initrd passed via the kernel command line is deprecated: it
> is limited to files that reside in the same volume as the one the kernel
> itself was loaded from, and we have more flexible ways to achieve the
> same. So make it configurable so new architectures can decide not to
> enable it.

I assume the 'more flexible ways' to do the same is referencing this
feature [1]
which is indeed more flexible. The problem is that the firmware/bootloader
must
support this new functionality, by populating the right EFI file with the
right GUID.

As far as I can see on arm64 there are three EFI bootloaders:
* GRUB2
* systemd-boot
* refind

Both systemd-boot and refind do not yet support this new mechanism,
although I see
that systemd has some unreleased code [2] to support the new way. I have
not been
able to test GRUB2 but my understanding is that this new method is still
under active
development [3].

The problem is that upstream has deprecated this functionality by assuming
the only
active use was x86, but was completely possible to use it on arm64 (it
works fine for me
on bullseye). Since EFI bootloaders have not yet implemented the new way,
and still
rely on this deprecated method on all architectures, it results in
unbootable systems
on arm64.

I would 100% think this should remain disabled on arm64 if most EFI
bootloaders
supported the new way, but unfortunately they do not.

I hope you would consider enabling this kernel configuration for arm64
until EFI
bootloaders catch up to the recommended way.

[0]
https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5
[1]
https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c
[2]
https://github.com/systemd/systemd/commit/a6089431d52adda93eec251a3df0dffa1fe0661a#diff-76eb4030e88f340c9133388f17c65774b0f17a0a8105500978f6ce18ca1deb5a
[3] https://www.mail-archive.com/grub-devel@gnu.org/msg32272.html

On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut  wrote:

> Control: reassign -1 src:linux
>
> Hi,
>
> Le 2021-10-26 20:44, Zameer Manji a écrit :
> > Package: linux-image-arm64
> > Version: 5.14.9-2
> > Severity: important
> >
> > Dear Maintainer,
> >
> > In bullseye, version 5.10.70-1 has the
> CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> > kernel configuration set to 'y'. In bookworm it is unset which disable
> this feature.
> >
> > This kernel configuration parameter allows for the EFI stub of the
> kernel to
> > parse and use a 'initrd=' parameter to set up an initrd when booting
> from EFI.
> > Boot loaders like 'systemd-boot' or 'refind' set this parameter if
> configured
> > to pass an initrd. If the kernel configuration parameter is unset, the
> > `initrd=` paramater is ignored, and can result in an unbootable system
> because
> > the initrd has not setup the root filesystem.
> >
> > Without the kernel configuaration set, it is not possible to use
> 'systemd-boot'
> > or 'refind' on arm64 as both of these bootloaders assume the kernel will
> > handle the 'initrd=' flag and setup the initrd.
> >
> > Please consider enabling CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> > arm64 so using 'systemd-boot' or 'refind' can continue to work. Until
> these
> > bootloaders have been updated to use an alternative method of passing the
> > initrd to the EFI stub, it is not possible to have a booting system.
>
> Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer enabled
> by
> default. Please see [1] for some details.
>
> Cheers,
> Vincent
>
> [1]
> https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
>

-- 
Zameer Manji

Bug#997909: xapian-bindings: FTBFS with ruby3.0: diff: debian/tmp/usr/lib/ruby/vendor_ruby/3.0.0/xapian.rb: No such file or directory

2021-10-26 Thread Antonio Terceiro

Source: xapian-bindings
Version: 1.4.18-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, xapian-bindings was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[7]: Entering directory '/<>/debian/build/ruby2.7/ruby'
> rm -f 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.7.0/_xapian.la
> make[7]: Leaving directory '/<>/debian/build/ruby2.7/ruby'
> make[6]: Leaving directory '/<>/debian/build/ruby2.7/ruby'
> make[5]: Leaving directory '/<>/debian/build/ruby2.7/ruby'
> make[4]: Leaving directory '/<>/debian/build/ruby2.7/ruby'
> make[3]: Leaving directory '/<>/debian/build/ruby2.7'
> make[2]: Leaving directory '/<>/debian/build/ruby2.7'
> # `created.rid` contains a timestamp making the build non-reproducible.
> # It doesn't seem to be useful to install, so just delete it.
> rm -f debian/tmp/usr/share/doc/xapian-bindings-ruby*/ruby/rdocs/created.rid
> # We only need one xapian.rb for ruby-xapian, and it should be the same
> # for all versions, so if present, check that the older versions are
> # the same as the latest, then throw them away.  Also, delete the older
> # versions of the docs - the latest docs are installed by
> # ruby-xapian.install.
> rb=debian/tmp`/usr/bin/ruby3.0 -rrbconfig -e 'puts 
> RbConfig::CONFIG["vendorlibdir"]'`/xapian.rb; \
> for v in 2.7; do \
> if [ "$v" != "3.0" ] ; then \
>   set -e; \
>   rb_old=debian/tmp`/usr/bin/ruby$v -rrbconfig -e 'puts 
> RbConfig::CONFIG["vendorlibdir"]'`/xapian.rb; \
>   diff "$rb_old" "$rb"; \
>   rm -rf "$rb_old" debian/tmp/usr/share/doc/xapian-bindings-ruby$v; \
> fi; \
> done; \
> mv "$rb" debian/tmp/usr/lib/ruby/vendor_ruby
> diff: debian/tmp/usr/lib/ruby/vendor_ruby/3.0.0/xapian.rb: No such file or 
> directory
> make[1]: *** [debian/rules:359: override_dh_auto_install] Error 2


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/4/xapian-bindings/xapian-bindings_1.4.18-1+rebuild1635263761_amd64.build.txt


signature.asc
Description: PGP signature

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

2021-10-26 Thread Vincent Blut

Control: reassign -1 src:linux

Hi,

Le 2021-10-26 20:44, Zameer Manji a écrit :
> Package: linux-image-arm64
> Version: 5.14.9-2
> Severity: important
> 
> Dear Maintainer,
> 
> In bullseye, version 5.10.70-1 has the 
> CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> kernel configuration set to 'y'. In bookworm it is unset which disable this 
> feature.
> 
> This kernel configuration parameter allows for the EFI stub of the kernel to
> parse and use a 'initrd=' parameter to set up an initrd when booting from EFI.
> Boot loaders like 'systemd-boot' or 'refind' set this parameter if configured
> to pass an initrd. If the kernel configuration parameter is unset, the
> `initrd=` paramater is ignored, and can result in an unbootable system because
> the initrd has not setup the root filesystem.
> 
> Without the kernel configuaration set, it is not possible to use 
> 'systemd-boot'
> or 'refind' on arm64 as both of these bootloaders assume the kernel will
> handle the 'initrd=' flag and setup the initrd.
> 
> Please consider enabling CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> arm64 so using 'systemd-boot' or 'refind' can continue to work. Until these
> bootloaders have been updated to use an alternative method of passing the
> initrd to the EFI stub, it is not possible to have a booting system.
 
Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer enabled by
default. Please see [1] for some details. 

Cheers,
Vincent

[1] 
https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
 


signature.asc
Description: PGP signature

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

2021-10-26 Thread Zameer Manji

Package: linux-image-arm64
Version: 5.14.9-2
Severity: important

Dear Maintainer,

In bullseye, version 5.10.70-1 has the 
CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
kernel configuration set to 'y'. In bookworm it is unset which disable this 
feature.

This kernel configuration parameter allows for the EFI stub of the kernel to
parse and use a 'initrd=' parameter to set up an initrd when booting from EFI.
Boot loaders like 'systemd-boot' or 'refind' set this parameter if configured
to pass an initrd. If the kernel configuration parameter is unset, the
`initrd=` paramater is ignored, and can result in an unbootable system because
the initrd has not setup the root filesystem.

Without the kernel configuaration set, it is not possible to use 'systemd-boot'
or 'refind' on arm64 as both of these bootloaders assume the kernel will
handle the 'initrd=' flag and setup the initrd.

Please consider enabling CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
arm64 so using 'systemd-boot' or 'refind' can continue to work. Until these
bootloaders have been updated to use an alternative method of passing the
initrd to the EFI stub, it is not possible to have a booting system.

Bug#997806: aom: possible ABI breakage; causes ffmpeg autopkgtests failures

2021-10-26 Thread Boyuan Yang

Hi,

On Sun, 24 Oct 2021 23:28:33 +0200 Sebastian Ramacher 
wrote:
> Source: aom
> Version: 1.0.0-errata1.avif-1
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> From ffmpeg's autopkgtest:
> | [libaom-av1 @ 0x55ab8a773940] Failed to initialize encoder: ABI version
mismatch

Given that libaom 3.2.0 just passed the NEW queue, there's really no benefit
on keeping version 1.0.0.errata1.avif and handling related ABI breaks. In
Debian Sid, I will revert to the old libaom version (the same as in Debian
Testing) and initiate a formal transition from libaom 1.x to libaom 3.x.

Thanks for the report and let me know if there are any further issues (e.g.,
issues related to transition).

Regards,
Boyuan Yang

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

Bug#996803: marked as pending in pytest-helpers-namespace

2021-10-26 Thread Sean Whitton

On Tue 26 Oct 2021 at 03:38PM GMT, Benjamin Drung wrote:

> Control: tag -1 pending
>
> Hello,
>
> Bug #996803 in pytest-helpers-namespace 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:

Thanks!


-- 
Sean Whitton

Bug#996401: gnome-shell-extension-prefs: Gnome extensions app fails to open in Wayland but opens in X11

2021-10-26 Thread Justin Searle

Please go ahead and close this bug.  It appears to be a Wayland issue as I
have discovered 2 other programs which are experiencing the same issue.  I
have yet to find the root cause, but have tried a fresh install and can
confirm the extensions app is working fine on my machine with Wayland.

I apologize for the false alarm.

Bug#994275: Reverting breaking changes in debianutils

2021-10-26 Thread Clint Adams

On Tue, Oct 26, 2021 at 09:53:55PM +0200, Thorsten Glaser wrote:
> “It only exists if it’s in Debian.”
> 
> SCNR. But this is relevant, here.
> 
> [ overly harsh words deleted ]

That's right, so we print a deprecation warning at the beginning
of the development cycle to raise awareness of the situation and
this leads to the interested parties packaging the whiches they
want to see in Debian over the subsequent ~2-year period.

This didn't work for tempfile because everyone still using tempfile
seems to redirect stderr to /dev/null and never saw the warning.

Ironically, it seems it hasn't yet worked for the original catalyst,
but it has worked for GNU which, modulo the problem of the NEW
queue.  As a side effect, it seems to have shined a spotlight on
some broken build systems.

Bug#997677: v4l-utils: FTBFS on riscv64 due to missing build-depends on clang:native

2021-10-26 Thread Gregor Jasny


Hello,

Thanks for noticing me about the missing riscv64 architecture. I was 
hoping that GCC catches up with eBPF compilation and I could omit clang 
altogether. But I guess I'll have to wait a little bit longer.


On 24.10.21 10:47, Aurelien Jarno wrote:

The missing file reported by dh_install is lacking as the "BPF IR
Decoders" are not enabled, because clang is not available in the
build-depends on riscv64, contrary to many other architectures.
Therefore the fix is as simple as adding riscv64 to the clang:native
build-depends:

--- v4l-utils-1.22.1/debian/control
+++ v4l-utils-1.22.1/debian/control
@@ -4,7 +4,7 @@
  Maintainer: Gregor Jasny 
  Uploaders: Loic Minier 
  Build-Depends: debhelper-compat (= 13),
-   clang:native [amd64 arm64 armel armhf i386 mips mips64el mipsel 
ppc64el s390x powerpc powerpcspe ppc64 sparc64 x32],
+   clang:native [amd64 arm64 armel armhf i386 mips mips64el mipsel 
ppc64el s390x powerpc powerpcspe riscv64 ppc64 sparc64 x32],
 doxygen,
 gettext,
 graphviz,

Could you please consider applying this patch for the future uploads?


I added the patch to the salsa git repo. It will be included with the 
next upload.



As a long-time member of Debian maybe you could give me an advise how to 
conditionally install the (conditionally created) systemd file. Creatin 
depends on the presence of clang and if systemd enabled bpf socket 
filtering (Debian does, Ubuntu does not). The decision is within the 
autoconf and based on it the systemd unit is created or omitted.


My approach
https://salsa.debian.org/debian/libv4l/-/commit/fe63c0af29bab9471daa6e0aba8d39e955777692

Seems to fail in the test-build-all

https://salsa.debian.org/debian/libv4l/-/jobs/2118024

Do you have an idea how to solve the problem more elegant?

Thanks,
Gregor

Bug#940528: installation-reports: b43 firmware not found or installed (Debian 11 bullseye installer from image with firmware non-free)

2021-10-26 Thread Cyril Brulebois

Hi Holger,

Holger Wansing  (2021-10-26):
> The bullseye amd64 netinst iso does not include this particular package.
> (Don't know why. I did not manage to understand the logic behind the
> selection, which packages get included in the firmware-containing isos.)
> So, installing it 'offline' from the netinst iso is not possible.

This reply went to the list only instead of being cc'd to the bug
report, submitter, etc.:
  https://lists.debian.org/debian-boot/2021/10/msg00095.html

b43 is indeed quite specific…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#997835: you could add powerdns init script

2021-10-26 Thread James Cloos

the pdns init script from the-last-stable-which-had-one (either squeeze or 
buster)
works fine on sid.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#997902: llvm-toolchain-13: autopkgtest regression on amd64|arm64: debian/qualify-clang.sh: llvm manpage are missing (using llc as an example)

2021-10-26 Thread Sylvestre Ledru



Le 26/10/2021 à 20:57, Simon McVittie a écrit :
> Source: llvm-toolchain-13
> Version: 1:13.0.0-6
> Severity: serious
> Justification: Release Team policy
> Tags: patch
>
> The autopkgtest that uses debian/qualify-clang.sh seems to be failing.
> I think this is a bug in debian/qualify-clang.sh rather than a bug in
> the actual packages: /usr/share/man/man1/llc-13.1.gz does exist in
> llvm-13_*.deb.
>
> The check that is failing is
>
>> # Test #995684
>> if test /usr/share/man/man1/llc-$VERSION.1.gz; then
>> echo "llvm manpage are missing (using llc as an example)"
>> exit 1
>> fi
> but I assume this should have been something more like:
>
> 8<
> # Test #995684
> if ! test -f "/usr/share/man/man1/llc-$VERSION.1.gz"; then
> echo "llvm man pages are missing (using llc as an example)"
> exit 1
> fi
> 8<
>
> I would suggest running the autopkgtests and making sure they pass locally
> on at least one architecture before uploading a new version to unstable.
> If llvm-toolchain-13 is too big to build locally, porterboxes and
> experimental are also useful routes to get things tested.

hmm, bizarre, I fixed it before. I guess it has been removed during a
merge?!


S

Bug#995827: llvm-toolchain-13: FTBFS on armel, mipsel, mips64el: undefined references to __atomic_foo symbols

2021-10-26 Thread Sylvestre Ledru



Le 26/10/2021 à 19:31, Nicholas D Steeves a écrit :
> Sylvestre Ledru  writes:
>
>> Hello,
>>
>> Le 12/10/2021 à 03:51, Nicholas D Steeves a écrit :
> [snip]
 Le 06/10/2021 à 17:05, Simon McVittie a écrit :
>> /usr/bin/ld: 
>> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o:
>>  in function `scudo::atomic_u64::Type 
>> scudo::atomic_load(scudo::atomic_u64 const volatile*, 
>> scudo::memory_order)':
>> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
>> undefined reference to `__atomic_load_8'
>> /usr/bin/ld: 
>> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
>> undefined reference to `__atomic_load_8'
 Yeah, I saw, it guess it is a -latomic missing again :)

>>> I've subscribed to this bug, since I just noticed llvm-toolchain-13 was
>>> available, and irony-mode users always want to use the latest Clang.
>>> Most irony-mode users are on amd64, so I'm thinking about switching now
>>> (for the greatest good), but I'm wondering this: Given that you know
>>> what the cause is, do you think this bug will soon be resolved?
>>>
>>
>> I think i fixed that one but not sure yet if there is other pending issue
>> See:
>> https://buildd.debian.org/status/package.php?p=llvm-toolchain-13
>> (it looks good for now)
>>
> Thank you Sylvestre!  Much appreciated :-)  I think the following two RC
> bugs may be new since our last correspondence: #996632 and #996448
Yeah, I saw. I will probably just disable these tests for these archs.
>
> By the way, am I correct in understand that the focus for bookwork will
> be on llvm-toolchain-13 (or possibly 14)?

I guess you mean Bookworm. if this is the case, no, it will probably
much more than that.

Debian releases every 2 years, LLVM/Clang every 6 months. So, probably
16 or 17.

Cheers
Sylvestre

Bug#994275: Reverting breaking changes in debianutils

2021-10-26 Thread Thorsten Glaser

On Tue, 26 Oct 2021, Clint Adams wrote:

> effort maintaining a utility which is superfluous given the
> existence of alternatives which are preferred by people who care

“It only exists if it’s in Debian.”

SCNR. But this is relevant, here.

[ overly harsh words deleted ]

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#997906: cardpeek: libcacard0 missing in dependencies

2021-10-26 Thread bartek 'basz' szurgot


Subject: cardpeek: libcacard0 missing in dependencies
Package: cardpeek
X-Debbugs-Cc: deb...@baszerr.eu
Version: 0.8.4-1.1
Severity: important
Tags: patch

Dear Maintainer,

package is missing dependency to libcacard0. because of this it is not 
possible to read cards at least with "Alcor Micro Corp. AU9540" 
smartcard reader (USB id: 058f:9540).


manually installing above dependency solves the issue.


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cardpeek depends on:
pn  cardpeek-data    
ii  libc6    2.31-13+deb11u2
ii  libcairo2    1.16.0-5
ii  libcurl4 7.74.0-1.3+b1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  liblua5.2-0  5.2.4-1.1+b3
ii  libpango-1.0-0   1.46.2-3
ii  libpcsclite1 1.9.1-1
ii  libreadline8 8.1-1
ii  libssl1.1    1.1.1k-1+deb11u1

cardpeek recommends no packages.

Versions of packages cardpeek suggests:
ii  pcscd  1.9.1-1

--
pozdrawiam serdecznie / best regards,
bartek 'basz' szurgot
/* https://baszerr.eu */
/* https://baszerr.eu/misc/pgp.txt */



OpenPGP_signature
Description: OpenPGP digital signature

Bug#940528: installation-reports: b43 firmware not found or installed (Debian 11 bullseye installer from image with firmware non-free)

2021-10-26 Thread Holger Wansing

Hi Laura,

Laura Arjona Reina  wrote (Tue, 26 Oct 2021 10:09:17 +0200):
> Hello
> 
> I recently installed Debian 11 bullseye on a laptop with BCM4312 with a 
> non-free
> firmware image, and could reproduce this issue.
> 
> Below you can find my installation report.
> 
> TL;DR: The installer reported: failed to load B43/ucode15.fw for my wireless 
> card.
> I continued the installation with the Ethernet adapter.
> After finishing installing Debian and rebooting I had wired network but no
> wireless network. Manually installing firmware-b43-installer package solved 
> the
> problem.
> I'm not sure if debian-installer is able to automatically install
> firmware-b43-installer or the mechanics is designed for simpler firmware
> packages (the ones that include the firmware in the proper package, not
> downloading it on the fly as firmware-b43-installer does).

The bullseye amd64 netinst iso does not include this particular package.
(Don't know why. I did not manage to understand the logic behind the
selection, which packages get included in the firmware-containing isos.)
So, installing it 'offline' from the netinst iso is not possible.

However, the new mechanism for firmware installation basically should have 
detected the need for that firmware, and install it via your wired connection.
If you sent us the installation logs (compressed), we can try to find out, why 
that did not work.




Another way for you to deal with this situation: if you have the required
ucode15.fw firmware file handy at installation time (for example from another 
system), you can copy it to a removable storage (like a USB stick), and 
plug it in, when asked for firmware. (I assume, you got a dialog saying that
such firmware file is missing, and if you have it available on a storage, 
right? That's right at the beginning of the installation process.)

Of course, this is not the perfect solution for all users, but I have  
prepared a stick here, where I have firmware for my wireless-LAN module
stored onto. For installation tests or the like...



Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#997469: dh-python doesn't allow local connections via urllib

2021-10-26 Thread Stefano Rivera

Hi Ole (2021.10.26_11:38:38_-0700)
> All of that said, there's an easy option for you. If you know your
> package needs network access and you're confident that it's not going to
> try to access the internet, you can just 'export http_proxy=' in
> debian/rules, and that will suppress pybuild exporting http_proxy.

FWIW, applied a patch to document this.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#997905: src:iwyu: fails to migrate to testing for too long: depends on llvm-toolchain-12

Source: iwyu
Version: 8.15-2
Severity: serious
Control: close -1 8.16-1
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:iwyu has been trying to migrate for 73
days [2]. Hence, I am filing this bug.

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

@Sylvestre: we discussed llvm-toolchain-* the other day [3], can't you
build iwyu with llvm-toolchain-11 until -12 or -13 is ready?

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=iwyu
[3] https://lists.debian.org/debian-release/2021/10/msg00466.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#997904: chroma build makes strange file access attempts

2021-10-26 Thread Ian Jackson

Package: chroma
Version: 1.9-1

Seen in the build log:

   cd resources && ./make-graphics.sh

   ** (process:30598): WARNING **: 19:06:42.251: Unable to create profile 
directory (Permission denied) (13)
   Unable to init server: Could not connect: Connection refused
   Unknown option -e
   16 arrow_shadow_left
   convert-im6.q16: unable to open image `/tmp/chroma-pieces-30597.png': No 
such file or directory @ error/blob.c/OpenBlob/2924.
   convert-im6.q16: no images defined 
`../graphics/chroma-marble//16_arrow_shadow_left.png' @ 
error/convert.c/ConvertImageCommand/3229.
   16 arrow_shadow_up
   convert-im6.q16: unable to open image `/tmp/chroma-pieces-30597.png': No 
such file or directory @ error/blob.c/OpenBlob/2924.
   convert-im6.q16: no images defined 
`../graphics/chroma-marble//16_arrow_shadow_up.png' @ 
error/convert.c/ConvertImageCommand/3229.
   16 arrow_shadow_right

The build shouldn't try to write to places it can't.  That suggests it
might break something if the filesystem or permissions were different

Nor should it ignore the error.

The build should not try to read fixed filenames in /tmp.  That might
make the build vulnerable on a shared system.

I don't know what "init server" is referred to.  Do we know that it
wouldn't connect to some actual server of some kind (perhaps an
unrelated daemon) ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#997871: Re : Bug#997871: debian-history: A few paragraphs are not translated

2021-10-26 Thread nicolas . patrois

Le 26/10/2021 20:17:29, Bdale Garbee a écrit :

> My French language skills are insufficient to work on this myself. 
> I'll be happy to merge credible patches if/when they appear from others.

OK, I’ll read again the history and propose fixes.
In which format do you want them? diff/patch on HTML? Or just my translations?

Yours,
nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#994275: Reverting breaking changes in debianutils

2021-10-26 Thread Clint Adams

On Tue, Oct 26, 2021 at 12:46:43PM +0200, tito wrote:
> It is possible to create a single command package if somebody
> will maintain it ( e.g busybox-which) like it was done for busybox-syslogd.
> tempfile is missing tough.

If someone wants to do that, I suppose they can.

On Tue, Oct 26, 2021 at 01:53:29PM +0100, Wookey wrote:
> I didn't understand why you wanted to make this change in the first

I think I tried to explain this to you on another mailing list.
There are people who are dissatisfied with the status quo with
respect to which(1).  I, as a user, don't care at all about
which(1).  I, as debianutils upstream, do not want to spend any
effort maintaining a utility which is superfluous given the
existence of alternatives which are preferred by people who care
about this stuff.

Now, as a debianutils maintainer in Debian, I could choose between
various different approaches, taking into account different objectives
to accommodate different stakeholder groups.  It is important to
acknowledge that it is impossible to please all groups here.

One approach is to embrace the status quo.  which(1) is perfectly
fine as it is, and anyone who wants `which -s` or
`which --read-functions` is a fool, an idiot, or worse.  Those
people don't matter and they should shut up.  I believe that this
is roughly equivalent to the original demand at the start of this
bug report.  I'll call this the ultraconservative approach.  It is
predicated on bad values and produces a bad outcome.

Another is to cautiously embrace change at a glacial pace.  This
signals to people who want something else that they are largely
unimportant, but as a gesture of good will, they can be accommodated
eventually, maybe in 2 years, maybe in 10.  It might seem reasonable
in a subculture which is stratified and resistant to change, with
stability (even the stability of _unstable_) paramount.  I'll call
this the conservative approach.  It is predicated on bad values and
produces a bad outcome.

Another is to build a runway for people to get what they want and
remove myself from the equation.  This is what I have attempted to
do.  Now, provided anyone elects to maintain them and the FTP team
allows them in, users will be able to install and use GNU which,
*BSD which, busybox which, rewrite-it-in-rust which, or whatever
should float someone's boat.  I can think all of this is pointless,
and it doesn't matter, because I am not impeding anyone else in
their pursuit of which(1) apotheosis.

> place, and I don't understand why you didn't just revert the message
> when it became clear that it was a problem, and I don't understand why
> you are still trying to justify your somewhat bloody-minded approach
> to this (should-have-been) minor issue, even after the tech comittee
> have agreed that it was not a good approach.

You seem angry that I haven't expended effort to work around a bug
in some other software.  You also seem angry that I am not following
a process that I am explicitly calling a bad process.  Other people
have said that "this is the way Debian does things," but I have been
doing this for 25 years and I recall Debian doing things many different
ways.

I'll save my commentary on the quality of the TC's decision until after
they have made it.

> Please, just remove the deprecation message, until GNU which is in
> unstable (like you should have done a couple of months ago, when first
> asked), then work out how the transition should go such that no-one
> using which will actually notice or care. Then you can throw away the
> hated binary :-) and we can all be happy.

When will GNU which be in unstable?

Bug#997903: ITP: mcxtrace -- An X-ray ray-trace simulation package

2021-10-26 Thread Roland Mas

Package: wnpp
Severity: wishlist
Owner: Roland Mas 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mcxtrace
  Version : 1.6
  Upstream Author : DTU Physics, Kgs. Lyngby, Denmark / Institut Laue Langevin, 
Grenoble, France
* URL : http://www.mcxtrace.org/
* License : GPL-2
  Programming Lang: C
  Description : An X-ray ray-trace simulation package

McXtrace is a general Monte Carlo ray-tracing software for simulation
X-ray beamlines and experiments.

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

2021-10-26 Thread Niko Tyni

On Wed, Oct 20, 2021 at 12:30:54PM -0700, Sean Whitton wrote:
 
> === Resolution A ===
> 
> The Technical Committee resolves:
> 
> 1. The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect which(1) to be in either an
>Essential package or a transitively Essential package (that is, a
>package that is depended on by an Essential package).
> 
> 2. The which(1) program must not print any deprecation warnings.
> 
> 3. We decline to overrule the maintainer of debianutils regarding the
>use of alternatives.  If another package takes over responsibility
>for which(1), then the debianutils maintainers and the other
>package's maintainers should coordinate to choose a suitable
>mechanism, which might be either versioned Depends/Breaks/Replaces,
>dpkg-divert, alternatives or something else.
> 
> 4. The debianutils package must continue to provide the tempfile(1)
>program until a compatible utility is available in a package that is
>at least transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect tempfile(1) to be in either an
>Essential package or a transitively Essential package.
> 
> 5. Programs in debianutils must not be moved to /usr until we have a
>project-wide consensus on going ahead with such a move, and any
>programs that have already been moved must be moved back.  In
>particular, this means debianutils must contain /bin/run-parts and
>/sbin/installkernel for the time being.
> 
> === Resolution B ===
> 
> As Resolution A, except strike point (2) and renumber succeeding items.
> 
> === End Resolutions ===
> 
> A: Issue Resolution A
> B: Issue Resolution B
> F: Further Discussion

I vote: A > B > F

-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature

Bug#997902: llvm-toolchain-13: autopkgtest regression on amd64|arm64: debian/qualify-clang.sh: llvm manpage are missing (using llc as an example)

2021-10-26 Thread Simon McVittie

Source: llvm-toolchain-13
Version: 1:13.0.0-6
Severity: serious
Justification: Release Team policy
Tags: patch

The autopkgtest that uses debian/qualify-clang.sh seems to be failing.
I think this is a bug in debian/qualify-clang.sh rather than a bug in
the actual packages: /usr/share/man/man1/llc-13.1.gz does exist in
llvm-13_*.deb.

The check that is failing is

> # Test #995684
> if test /usr/share/man/man1/llc-$VERSION.1.gz; then
> echo "llvm manpage are missing (using llc as an example)"
> exit 1
> fi

but I assume this should have been something more like:

8<
# Test #995684
if ! test -f "/usr/share/man/man1/llc-$VERSION.1.gz"; then
echo "llvm man pages are missing (using llc as an example)"
exit 1
fi
8<

I would suggest running the autopkgtests and making sure they pass locally
on at least one architecture before uploading a new version to unstable.
If llvm-toolchain-13 is too big to build locally, porterboxes and
experimental are also useful routes to get things tested.

smcv

Bug#997901: ITP: mcstas -- A neutron ray-trace simulation package

2021-10-26 Thread Roland Mas

Package: wnpp
Severity: wishlist
Owner: Roland Mas 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mcstas
  Version : 3.0
  Upstream Author : McStas developers 
* URL : http://www.mcstas.org/
* License : GPL-2
  Programming Lang: C
  Description : A neutron ray-trace simulation package

McStas is a general tool for simulating neutron scattering instruments
and experiments.

Bug#997900: src:golang-github-go-xorm-builder: fails to migrate to testing for too long: uploader built arch:all binaries

Source: golang-github-go-xorm-builder
Version: 0.3.3-2
Severity: serious
Control: close -1 0.3.3-3
X-Debbugs-CC: jel...@debian.org
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:golang-github-go-xorm-builder has been
trying to migrate for 73 days [2]. Hence, I am filing this bug.

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

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

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

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=golang-github-go-xorm-builder




OpenPGP_signature
Description: OpenPGP digital signature

Bug#997899: src:slurm-wlm: fails to migrate to testing for too long: piuparts regression and unresolved RC bug

Source: slurm-wlm
Version: 20.11.7+really20.11.4-2
Severity: serious
Control: close -1 20.11.8-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 997267

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:slurm-wlm has been trying to migrate for
63 days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#997898: src:etbemon: fails to migrate to testing for too long: FTBFS everywhere

Source: etbemon
Version: 1.3.5-6
Severity: serious
Control: close -1 1.3.5-7
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 992896

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:etbemon has been trying to migrate for 63
days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#988333: [Pkg-xen-devel] linux-image-5.10.0-6-amd64: VGA Intel IGD Passthrough to Debian Xen HVM DomUs not working, but Windows Xen HVMs do work

2021-10-26 Thread Chuck Zmudzinski

On 10/26/2021 10:06 AM, Chuck Zmudzinski wrote:

On 10/25/2021 4:45 PM, Chuck Zmudzinski wrote:

On 10/23/2021 11:11 AM, Hans van Kranenburg wrote:

Hi!

On 5/10/2021 1:33 PM, Chuck Zmudzinski wrote:
[...] with buster and bullseye running as the Dom0, I can only get
the VGA/Passthrough feature to work with Windows Xen HVMs. I would
expect both Windows and Linux HVMs to work comparably well.

A possible time-saver that I can recommend is to send a post to the
upstream xen-users list [0] about this already. Like "Hi all, I'm
starting a HVM Linux domU with Linux 5.10.70 on a Xen 4.14.3 system
with

also 5.10.70 dom0 kernel, with this and this domU config file. It fails
to start, this is the xl -vvv create output, and this error (the irq
stuff) appears in the dom0 kernel log.". Try to keep it simple and not
too long initially, without the surrounding stories, to increase chance
of it being fully read.

I can do this soon - I have some more interesting tests to share
here and with the Xen developers upstream.

I will need to think a little about how to present this bug to
the Xen upstream developers in a short and simple enough way
for them to be likely to read it initially. For now, I will report here
some results from the journal log entries of both Bullseye dom0
and Bullseye domU for two different configurations. These logs
are not generated with the -vvv option, but they do provide
quite a bit of interesting information and are already
somewhat overwhelming, even without the -vvv option. So
I will hold off for now before making the logs even more verbose
with -vvv.

The intention of this message is to provide detailed logs for a
detailed analysis of the problem, not to describe the problem
in simple terms.

A few days ago I ran two tests, and I have four different log
files attached from those tests. In both tests, the Bullseye
HVM was configured for PCI/IGD passthrough using the
domain config file and preparation for passthrough in dom0
described in the earlier message #31:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988333#31

The two tests were:

1. Bullseye dom0, Debian 11.1 / Bullseye HVM domU, Debian 11.1

This first test essentially confirmed that the updated versions
of the packages for both Bullseye dom0 and Bullseye domU
since the original report five months ago do not fix the
problem. In this test case, I am using all the official packages
of Debian 11.1 (Bullseye).

It is important to note that the version of the device
model used in this test is the official upstream version
of qemu for Bullseye. On Debian, Xen uses by default the
qemu-system-i386 binary from the qemu-system-x86
package, and Bullseye currently uses qemu version
5.2+dfsg-11+deb11u1 as the default device model.

I attached two log files from this test:
qemu-upstream-hvm.txt and qemu-upstream-dom0.txt.
They are the logged journal entries for the Bullseye HVM
and Bullseye dom0 domains, respectively. They are fairly
complete logs, showing the kernel version running in both
the dom0 and the HVM, the kernel command line for both
the dom0 and the domU, the command that was used to
create the HVM domain, etc.

One might recall that in the original report I said it was
difficult to capture logs from the domU, but this time I was able
to capture the log by waiting a few minutes before shutting
it down. I also discovered, in contrast to what I said in the
earlier report, that it is possible to gracefully shut down the
domU using xl shutdown by waiting long enough
before trying to shut it down, and also it takes a few minutes
instead of the normal few seconds to shut it down because
of the problems caused by this configuration. By waiting
for the graceful shutdown instead of using xl destroy ,
I was able to view the log of the attempted boot in the domU
on a subsequent normal boot (without PCI passthrough) using
journalctl, and capture some useful Call Traces.

For this first test, although there is a successful shut down,
the domain is never built to the point where one can login,
neither at the terminal nor remotely via ssh. But the boot
messages were displayed on the passed through video
device, but only very slowly, it took almost two minutes
before the boot messages started to appear and it also
took a couple of minutes after issuing the xl shutdown
command in dom0 before it indicated on the passed
through video device that the HVM domain shut down
and powered off.

The second test:

2. Same as first test, except use the qemu traditional device
model instead of the qemu upstream model which on Debian
comes from the qemu-system-x86 package.

I also attached two log files from this test:
qemu-traditional-hvm.txt and qemu-traditional-dom0.txt,
and these also are fairly complete logs showing the kernel
version in use, etc.

Since Debian does not provide the traditional device model,
I had to build it from xenbits.xen.org:

https://xenbits.xen.org/gitweb/?p=qemu-xen-traditional.git;a=shortlog;h=refs/heads/stable-4.14

Bug#996859: kded5: crash during init

2021-10-26 Thread Achim Schaefer


Hi,

worked, I upgraded to unstable and now I'm able to log in again.

Thanks



On 25.10.21 14:47, Patrick Franz wrote:

Hi,


Which version of libkdecorations2-5v5 do you have installed? 5.21.5 or
5.23.0 ?

If it's 5.21.5, a possible workaround is decsribed at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996726

Sorry, I meant to say that if you are running libkdecorations2-5v5 in
version 5.23.0, an option is to downgrade to 5.21.5 as described in the
other bug report.

Bug#997469: dh-python doesn't allow local connections via urllib

2021-10-26 Thread Stefano Rivera

Control: notfound -1 dh-python/5.20211022.1

Not starting a reassign war, but also, this shouldn't block testing
migration of an unrelated version.

This is the expected behaviour of dh-python. It exports http_proxy,
https_proxy, and no_proxy environment variables.
https://salsa.debian.org/python-team/tools/dh-python/-/blob/ba1110c8700d8ce9b6027117d0f12df7cfb95471/pybuild#L53-67

These variables are hardly standardized, see for example:
https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/

But maybe we could improve them, possibly adding 127.0.0.1 to the
no_proxy list? But I could easily imagine that causing other packages to
fail, getting confused by the comma in no_proxy.

All of that said, there's an easy option for you. If you know your
package needs network access and you're confident that it's not going to
try to access the internet, you can just 'export http_proxy=' in
debian/rules, and that will suppress pybuild exporting http_proxy.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#997871: debian-history: A few paragraphs are not translated

2021-10-26 Thread Bdale Garbee

Nicolas Patrois  writes:

> Package: debian-history
> Version: 2.26
> Severity: normal
> Tags: l10n
>
> Dear Maintainer,
>
> A few paragraphs in the French pages are not translated.
> These pages are mostly in French excepted one or two paragraphs.
>
> Maybe it’s the same in other languages.

My French language skills are insufficient to work on this myself.  I'll
be happy to merge credible patches if/when they appear from others.

Bdale

signature.asc
Description: PGP signature

Bug#996734: src:nim: fails to migrate to testing for too long: ftbfs on armhf

2021-10-26 Thread Nilesh Patra


On 10/26/21 7:40 PM, Paul Gevers wrote:

Hi Nilesh,

On 26-10-2021 15:59, Nilesh Patra wrote:

Since this bug is already fixed in unstable, it is causing a huge number
of autoremovals,
so I'm decreasing the severity for time being, to avoid temporary and
un-necessary testing removal noise. -- Hope that's OK


As long as you'll be watching then. Pinging the bug already resets the
autoremoval timer, and now *if* something pops up, the autoremoval
doesn't happen. No doubt I see where you're coming from.


Agreed, it does reset the timer, but it still pretty much propagates the noise,
which I wanted to reduce for a bit, I hope you understand me there.
 

I will ping you once nim migrates, and either ask you to close this bug
or take the liberaty to do so myself.


The bug is already closed.


ACK, please excuse me being sloppy here.


It was closed when I submitted it. It's the
other RC bug you need to worry about.


This one right?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993042

Federico closed it a few hours earlier, and I re-opened and closed it again now 
with the right version.


You'll need to teach the BTS which
version fixed the bug (mere closure isn't enough), otherwise the BTS
will believe the bug affects unstable but not testing and migration will
not happen.


Ofcourse, hopefully that's done already. Thanks a lot for quick response! :)
I will re-open this, if I see something which could be problematic.

Have a good day,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996734: src:nim: fails to migrate to testing for too long: ftbfs on armhf

2021-10-26 Thread Nilesh Patra


control: severity -1 important

Hi Paul,

Thanks for reporting

On Sun, 17 Oct 2021 21:52:24 +0200 Paul Gevers  wrote:

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.


The new version of nim (1.6.0) was uploaded some hours back by Federico, and it 
passes on armhf.
Hopefully, this version will migrate in a few days.

Since this bug is already fixed in unstable, it is causing a huge number of 
autoremovals,
so I'm decreasing the severity for time being, to avoid temporary and 
un-necessary testing removal noise. -- Hope that's OK

I will ping you once nim migrates, and either ask you to close this bug or take 
the liberaty to do so myself.

https://buildd.debian.org/status/fetch.php?pkg=nim=armhf=1.6.0-1=1635249411=0

Thanks for your work,
Nilesh

Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)

2021-10-26 Thread Brian Potkin

On Tue 26 Oct 2021 at 10:49:59 -0400, Brendon Higgins wrote:

> Hi Brian,
> 
> On Tuesday, October 26, 2021 8:13:01 A.M. EDT Brian Potkin wrote:
> > On Mon 25 Oct 2021 at 16:07:36 -0400, Brendon Higgins wrote:
> > > Hi Brian,
> > > 
> > > Perhaps I was unclear in my description. You responded:
> > > > You want to replace hp-plugin
> > > 
> > > On the contrary, I would think the proposed hplip-plugin-installer package
> > > would pre-depend on hplip and essentially just run hp-plugin in its
> > > postinst. It's complementary, not a replacement.
> > > 
> > > > with something Debian-specific that Debian has to maintain for ever.
> > > 
> > > Debian-specific, perhaps, though hardly beyond ordinary packaging
> > > practices. Could be useful for derivatives, too. I would think
> > > maintenance for such a simple thing would be minimal (barring major
> > > upstream changes - which users would have to figure out for themselves,
> > > otherwise).
> > > 
> > > And as I mentioned, there's plenty of precedent for this approach, and the
> > > arguments against those are the same.
> > 
> > It strikes me that an hplip-plugin-installer package would not provide
> > anything over and above what hp-plugin provides. This checksum issue
> > reported in Launchpad #1948555 is not uncommon and such a package
> > would not alleviate it. The usual way to tackle it is download the
> > plugin and install with 'sh '.
> 
> Download the plugin from where? I traced its source to the location given in 
> that Launchpad bug, and it's obviously a broken upload at the server - this 
> is 
> a "true negative" checksum failure. (Please try it - it still hasn't been 
> fixed 
> as of writing.) I haven't been able to uncover an alternative download 
> location, so if you know of one I would love to hear it (really!).

The official archive site is

  https://developers.hp.com/hp-linux-imaging-and-printing/plugins

OpenPrinting provides a mirror as a service to users. A problem with it
is a problem for OpenPrinting. 'sh ' is upstream's advice
when hp-plugin doesn't behave.
 
> This negative experience is what inspired me to suggest hp-plugin-installer - 
> because it does provide key usability benefits due to this property: it would 
> run at the same time that the hplip packages are updated. The benefits that 
> come from this are:

You are are not the first (nor will you be the last) to have a problem
installing a plugin. This is upstream's responsibility.

> 1. Automatic updating of the plugin to the corresponding version - which, 
> assuming an environment that uses one of the affected devices, is implicitly 
> required by the hplip package for it to be at all useful.

This is one of my sticking points. Automatic? A user has a device that
requires a non-free plugin for scanning. The user never scans, but is
still obliged to download and install it.

> 2. Any failure to download/install the updated plugin can be found and 
> addressed by the system administrator immediately. This is in contrast to the 
> current situation where the system is left in an incomplete, unusable state, 
> for an indefinite period of time, until the user might try to use their 
> device, 
> encounter a problem, and the user (rather than system administrator) is 
> expected to fix that.
> 
> In my case, the plugin file being broken upstream was my critical failure 
> point. I only encountered this weeks after the hplip packages updated - it 
> seems to me that the plugin file might have been okay back then. (I've since 
> had to downgrade back to stable's version.) But I can imagine other 
> situations 
> which would be helped by hp-plugin-installer, too - perhaps the system is 
> portable and not always connected to the internet, so downloading the plugin 
> at any given time (even if it is good upstream) is not feasible, but 
> downloading it when packages are also downloaded and installed makes much 
> more 
> sense. Or perhaps the user has been granted printing permissions but not root 
> permissions by the system administrator - the sysadmin would absolutely want 
> some kind of automation to install this plugin in such a situation...
> 
> > There is also the matter of what runs the proposed package. It cannot
> > be from any of the HPLIP packages because, as the Debian Policy Manual
> > says:
> > 
> >   In addition, the packages in main must not require or recommend
> >   a package outside of main for compilation or execution...
> 
> hplip could suggest it, though. At any rate, I imagine the sysadmin would 
> install hp-plugin-installer (from contrib) themselves. They would only need 
> to 
> do that once, and only if they actually had a device that needs the plugin to 
> be installed. hp-plugin-installer would be versioned alongside hplip and 
> update at the same time, and thereby run hp-plugin to grab and install the 
> necessary plugin version at the time (or immediately after) the hplip update 
> is installed.

Any issues with hp-scan would be relected in

Bug#997894:

reopen 997894
severity 997894 important
affects 997894 calibre
thanks

I'm downgrading severity to important as a humble courtesy, but if my
hypothesis is correct then it really is RC.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#995827: llvm-toolchain-13: FTBFS on armel, mipsel, mips64el: undefined references to __atomic_foo symbols

Sylvestre Ledru  writes:

> Hello,
>
> Le 12/10/2021 à 03:51, Nicholas D Steeves a écrit :
[snip]
>>> Le 06/10/2021 à 17:05, Simon McVittie a écrit :
> /usr/bin/ld: 
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o:
>  in function `scudo::atomic_u64::Type 
> scudo::atomic_load(scudo::atomic_u64 const volatile*, 
> scudo::memory_order)':
> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> undefined reference to `__atomic_load_8'
> /usr/bin/ld: 
> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> undefined reference to `__atomic_load_8'
>>> Yeah, I saw, it guess it is a -latomic missing again :)
>>>
>> 
>> I've subscribed to this bug, since I just noticed llvm-toolchain-13 was
>> available, and irony-mode users always want to use the latest Clang.
>> Most irony-mode users are on amd64, so I'm thinking about switching now
>> (for the greatest good), but I'm wondering this: Given that you know
>> what the cause is, do you think this bug will soon be resolved?
>> 
>
>
> I think i fixed that one but not sure yet if there is other pending issue
> See:
> https://buildd.debian.org/status/package.php?p=llvm-toolchain-13
> (it looks good for now)
>

Thank you Sylvestre!  Much appreciated :-)  I think the following two RC
bugs may be new since our last correspondence: #996632 and #996448

By the way, am I correct in understand that the focus for bookwork will
be on llvm-toolchain-13 (or possibly 14)?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#984066: Processed: block 984066 with 987379

Control: unblock -1 by 987379

> Processing commands for cont...@bugs.debian.org:
>
>> block 984066 with 987379
> Bug #984066 {Done: Adrian Bunk } [src:irony-mode] 
> irony-mode: ftbfs with GCC-11
> 984066 was not blocked by any bugs.
> 984066 was not blocking any bugs.
> Added blocking bug(s) of 984066: 987379
>> thanks

This block is incorrect, please see the following:

irony-mode (1.5.0-1) unstable; urgency=medium

  * New upstream release.
  * Update my email address.
  * Switch to llvm-toolchain-12, and build with libclang-12-dev, clang-12,
and llvm-12-dev.
  * Switch to watch file v4 (no further changes required).

 -- Nicholas D Steeves   Wed, 15 Sep 2021 16:56:37 -0400

Additionally, I think it may be a better use of time to focus on
stabilising llvm-toolchain-13 rather than 11 and 12.  Of course, that's
not my call, but I'd like to do what I can to support the effort to ship
fewer llvm-toolchain-versions in bookwork.  Consequently I will be
moving this package to version 13 at some point in the near future.

Also, on the upstream bug tracker, users have expressed the desire to
have a Debian irony-mode package that uses the newest Clang available on
Debian systems, so there is a concrete "for our users" reason to do this.

I hope that this position is acceptable to everyone! :-)

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#997655: diodon: FTBFS: autoreconf: error: configure.in: AC_INIT not found; not an autoconf script?

2021-10-26 Thread Oliver Sauder

Lucas,
Thanks for reporting. This issue has actually been resolved upstream but
it seems that I uploaded an invalid orig tarball for version 1.11.1 for
the Debian package. Instead of the new upstream tarball 1.11.1, 1.11.0
was still used (when opening the tarball from [0] the folder name is
still 1.11.0). Not so sure how this happened. Upstream tarball [1] is
correct though.

Do you know a way to fix the invalid orig tarball without a new release
upstream?

Oliver

[0]
http://deb.debian.org/debian/pool/main/d/diodon/diodon_1.11.1.orig.tar.xz
[1] https://launchpad.net/diodon/trunk/1.11.1/+download/diodon-1.11.1.tar.xz

Bug#997895: libsnmp-dev net-snmp-create-v2-user no longer sets ${datarootdir}

2021-10-26 Thread Stefan Rubner

Package: libsnmp-dev
Version: 5.9+dfsg-3+b1

When running `net-snmp-create-v3-user` I get an error message:

# net-snmp-create-v3-user -A  -a SHA -x  -X AES snmp_v3_user
adding the following line to /var/lib/snmp/snmpd.conf:
   createUser snmp_v3_user SHA "" AES ""
adding the following line to /snmp/snmpd.conf:
   rwuser snmp_v3_user
touch: cannot touch '/snmp/snmpd.conf': No such file or directory
/usr/bin/net-snmp-create-v3-user: 144: cannot create /snmp/snmpd.conf: 
Directory nonexistent

Note the last two lines. The reason is that in line 137 the variable òutfile`is 
set like this:

outfile="${datarootdir}/snmp/snmpd.conf“

but since `datarootdir` isn’t defined anywhere the tool goes right for 
`/snmp/snmpd.conf`.
Looking at an older version it seems that the whole section to set the 
variables is missing, e.g.
this part:

prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${prefix}/lib/x86_64-linux-gnu
datarootdir=${prefix}/share

This could probably get condensed into

datarootdir=/usr/share

or the path could be hardcoded into `net-snmp-create-v3-user`



signature.asc
Description: Message signed with OpenPGP

Bug#997896: darkslide: new upstream version 6.0.0 is available

2021-10-26 Thread Daniel Kahn Gillmor

Package: src:python-darkslide
Version: 5.1.0-1

darkslide upstream released 6.0.0 last year.  It would be great to have
it updated in Debian.

Thanks for maintaining darkslide in debian!

   --dkg


signature.asc
Description: PGP signature

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

2021-10-26 Thread Margarita Manterola

> === Resolution A ===
> 
> The Technical Committee resolves:
> 
> 1. The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect which(1) to be in either an
>Essential package or a transitively Essential package (that is, a
>package that is depended on by an Essential package).
> 
> 2. The which(1) program must not print any deprecation warnings.
> 
> 3. We decline to overrule the maintainer of debianutils regarding the
>use of alternatives.  If another package takes over responsibility
>for which(1), then the debianutils maintainers and the other
>package's maintainers should coordinate to choose a suitable
>mechanism, which might be either versioned Depends/Breaks/Replaces,
>dpkg-divert, alternatives or something else.
> 
> 4. The debianutils package must continue to provide the tempfile(1)
>program until a compatible utility is available in a package that is
>at least transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect tempfile(1) to be in either an
>Essential package or a transitively Essential package.
> 
> 5. Programs in debianutils must not be moved to /usr until we have a
>project-wide consensus on going ahead with such a move, and any
>programs that have already been moved must be moved back.  In
>particular, this means debianutils must contain /bin/run-parts and
>/sbin/installkernel for the time being.
> 
> === Resolution B ===
> 
> As Resolution A, except strike point (2) and renumber succeeding items.
> 
> === End Resolutions ===
> 
> A: Issue Resolution A
> B: Issue Resolution B
> F: Further Discussion

I vote:
A > B > F

Thanks,
Marga


signature.asc
Description: PGP signature

Bug#997893: RM: ruby-wirble -- ROM; No longer compatible with current versions of Ruby (incorporated)

2021-10-26 Thread Gunnar Wolf

Package: ftp.debian.org
Severity: normal

Last upstream version for Wirble is from 2009¹, and the last upload of
ruby-wirble to Deblan is from 2015. It was removed from Bullseye on
February 2021. The important parts of its functionality (coloring the
interactive Ruby console, irb) has been adopted in irb itself.

¹ https://rubygems.org/gems/wirble

We were originally two maintainers, Ryan Niebur and myself. Ryan is no
longer active in Debian (#856380), and clearly, I'm not active
maintaining this package, so I request its removal.

Thank you very much,

Bug#996887: tldr also affected

2021-10-26 Thread Diederik de Haas

Control: affects -1 + tldr

Got the same error msg when running tldr. Downgrading to the testing version 
fixed it (aptitude install libcmark0.30.1=0.30.1-2).

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

Bug#989938: MuPDF SIGHUP

2021-10-26 Thread Bastian Germann


Control: tags -1 wontfix

Please send SIGHUP to the mupdf process and not the script.

Bug#997892: ITP: vsomeip -- Scalable service-Oriented MiddlewarE over IP (SOME/IP)

2021-10-26 Thread Al Nikolov

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 
X-Debbugs-Cc: debian-de...@lists.debian.org, alexey.niko...@basemark.com

* Package name: vsomeip
  Version : 3.1.20
  Upstream Author : Bayerische Motoren Werke Aktiengesellschaft (BMW AG)
* URL : https://github.com/GENIVI/vsomeip
* License : MPL-2.0
  Programming Lang: C++
  Description : Scalable service-Oriented MiddlewarE over IP (SOME/IP)

vsomeip stack implements the http://some-ip.com/
(Scalable service-Oriented MiddlewarE over IP (SOME/IP)) protocol.
The stack consists out of:
* a shared library for SOME/IP (libvsomeip3.so)
* a second shared library for SOME/IP's service discovery (libvsomeip3-sd.so)
which is loaded during runtime if the service discovery is enabled.

SOME/IP is an automotive middleware solution that can be used for control
messages. It was designed from beginning on to fit devices of different sizes
and different operating systems perfectly. This includes small devices like
cameras, AUTOSAR devices, and up to head units or telematics devices. It was
also made sure that SOME/IP supports features of the Infotainment domain as
well as that of other domains in the vehicle, allowing SOME/IP to be used for
MOST replacement scenarios as well as more traditional CAN scenarios.

AFAIK, there's no alternative implementations in Debian.

I intend to maintain it as part of my job contract.
No sponsorship would be required.

Bug#997865: autopkgtest: dependency satisfied from testing instead of unstable

2021-10-26 Thread Simon McVittie

On Tue, 26 Oct 2021 at 17:47:17 +0200, Mathias Behrle wrote:
> I have no say where this could be coded, but taking packages with lower
> versions from testing instead using the last available versions in unstable 
> for
> an autopgktest running in unstable seems definitely not logical to me.

This isn't an autopkgtest running in unstable, though: it's an autopkgtest
running in testing, with only selected packages from unstable (hence /testing/
in the URL).

The reason it's taking certain packages from unstable is because the
testing migration scripts (britney) are trying to answer the question:
if I let various tryton modules (specifically the ones listed in
--pin-packages=unstable) migrate from unstable to testing, would
anything stop working? And the answer here seems to be: yes it would. So
ci.debian.net and autopkgtest are doing their job: they're alerting you
to a problem.

> Tryton 6.0 packages (in unstable) will generally break Tryton 5.0 (in 
> testing).
> But all Tryton packages in unstable are 6.0 at the moment and depend on >= 
> 6.0.

If Tryton 5 versions of tryton-modules-* are incompatible with Tryton 6,
that isn't currently reflected by their dependencies, so the testing
migration scripts have no way to know that the migration they're trying
to do here is considered wrong.

For example, tryton-modules-account (= 5.0.18-1) has:
Depends: tryton-server (>= 5.0)

apt (and therefore testing migration and autopkgtest) will consider
tryton-server 6.0.9-1 to be a valid solution to that dependency. If you
consider that to be *not* a valid solution, please set dependencies that
would forbid it.

There are three main strategies you could use to prevent a broken
partial upgrade:

1. versioned Depends, versioned Breaks:
tryton-modules-account (6.x) Depends: tryton-server (>= 6)
tryton-server (6.x) Breaks: tryton-modules-account (<< 6), etc.

2. Depends with a 2-ended range:
tryton-modules-account (6.x) Depends: tryton-server (>= 6),
  tryton-server (<< 7)

3. Virtual package representing the overall API/ABI:
tryton-server (6.x) Provides: tryton-server-6
tryton-modules-account (6.x) Depends: tryton-server-6

Strategy 2 or 3 would probably be best in the long term, but you will
probably need some versioned Breaks (like strategy 1) during the
transition from the current situation to whichever strategy you choose.

Strategy 1 is appropriate if everything is "usually" compatible, with
infrequent incompatible changes that are hard to predict and need
an ad-hoc solution. For example, we use Depends/Breaks when a change
to gsettings-desktop-schemas requires closely-related packages like
gnome-control-center to be updated, which happens once every few years.

Strategies 2 and 3 are appropriate if the compatible/incompatible version
is easy to predict in advance. For example, we use Depends with a range
for GNOME Shell extensions like gnome-shell-extension-caffeine (each
GNOME Shell extension is only compatible with a limited range of GNOME
Shell versions), and we use a virtual package representing the overall
API for Apache modules.

smcv

Bug#997660: pyqt5-sip: appears to declare the wrong API version

clone 997660 -1
reassign -1 pyqt5-sip 12.9.0-1
retitle -1 pyqt5-sip: appears to declare the wrong API version (should be 12.9)
thanks

Alex Relis  writes:

> I'm on version 5.30.0+dfsg-1 and I am still experiencing this bug. It hasn't 
> been fixed quite yet. Here's the error I seem to be getting:
>
> alex@alex-pc:~$ calibre
> Traceback (most recent call last):
>   File "/usr/bin/calibre", line 21, in 
> sys.exit(calibre())
>   File "/usr/lib/calibre/calibre/gui_launch.py", line 64, in calibre
> main(args)
>   File "/usr/lib/calibre/calibre/gui2/main.py", line 533, in main
> app, opts, args = init_qt(args)
>   File "/usr/lib/calibre/calibre/gui2/main.py", line 124, in init_qt
> app = Application(args, override_program_name=override, 
> windows_app_uid=MAIN_APP_UID)
>   File "/usr/lib/calibre/calibre/gui2/__init__.py", line 894, in __init__
> from calibre_extensions import progress_indicator
> RuntimeError: the sip module implements API v12.0 to v12.8 but the 
> progress_indicator module requires API v12.9
>
[snip]
> ii  python3-pyqt5.sip12.9.0-3

Hm, that is strange.  This string comes from pyqt5-sip/12.9.0-3:

siplib.c
1716:"the sip module implements API v%d.0 to v%d.%d but the 
%s module requires API v%d.%d",
1721:"the sip module implements API v%d.0 but the %s module 
requires API v%d.%d",

Thus, it seems like python3-pyqt5.sip may be misidentifying its
version.  The next step was to search for 12.8 strings:

sip.h
1656:PyObject *(*api_is_py_method_12_8)(sip_gilstate_t *gil, char *pymc,

siplib.c
319:static PyObject *sip_api_is_py_method_12_8(sip_gilstate_t *gil, char 
*pymc,
620:sip_api_is_py_method_12_8,
6030:meth = sip_api_is_py_method_12_8(, , , NULL,
8378: * sip_api_is_python_method_12_8() instead.
8383:return sip_api_is_py_method_12_8(gil, pymc, , cname, 
mname);
8391:static PyObject *sip_api_is_py_method_12_8(sip_gilstate_t *gil, char 
*pymc,

Dmitri, would you please take a look at this?  Apologies if I
naively misinterpreted this bug, feel free to bounce it back if
necessary.

Regards,
Nicholas

signature.asc
Description: PGP signature

Bug#997802: ddnet: autopkgtest regression on armhf: output to stderr

2021-10-26 Thread Graham Inggs

On Sun, 24 Oct 2021 at 22:30, Paul Gevers  wrote:
> I copied some of the output at the bottom of this report. It seems that
> the actual test passes, but there's output on stderr and the default
> behavior of autopkgtest is to fail on output to stderr. If in general
> output to stderr is harmless to your test, consider adding the
> allow-stderr restriction. Otherwise, please fix your test.

The autopkgtest on ppc64el [1] also fails due to output on stderr.


[1] https://ci.debian.net/packages/d/ddnet/testing/ppc64el/


/tmp/autopkgtest-lxc.e6vtmdil/downtmp/build.Hvt/src/src/game/collision.cpp:
In member function ‘void CCollision::Init(CLayers*)’:
/tmp/autopkgtest-lxc.e6vtmdil/downtmp/build.Hvt/src/src/game/collision.cpp:66:10:
note: the layout of aggregates containing vectors with 8-byte
alignment has changed in GCC 5
   66 |  m_Width = m_pLayers->GameLayer()->m_Width;
  |  ^
[ 59%] Building CXX object CMakeFiles/game-shared.dir/src/game/extrainfo.cpp.o
[ 59%] Building CXX object CMakeFiles/game-shared.dir/src/game/gamecore.cpp.o
/tmp/autopkgtest-lxc.e6vtmdil/downtmp/build.Hvt/src/src/game/gamecore.cpp:
In member function ‘void CCharacterCore::Reset()’:
/tmp/autopkgtest-lxc.e6vtmdil/downtmp/build.Hvt/src/src/game/gamecore.cpp:70:6:
note: the layout of aggregates containing vectors with 2-byte
alignment has changed in GCC 5
   70 | void CCharacterCore::Reset()
  |  ^~
[ 62%] Building CXX object CMakeFiles/game-shared.dir/src/game/layers.cpp.o
[ 62%] Building CXX object
CMakeFiles/game-shared.dir/src/game/localization.cpp.o
/tmp/autopkgtest-lxc.e6vtmdil/downtmp/build.Hvt/src/src/game/localization.cpp:
In member function ‘void CLocalizationDatabase::AddString(const char*,
const char*, const char*)’:
/tmp/autopkgtest-lxc.e6vtmdil/downtmp/build.Hvt/src/src/game/localization.cpp:39:6:
note: the layout of aggregates containing vectors with 8-byte
alignment has changed in GCC 5
   39 | void CLocalizationDatabase::AddString(const char *pOrgStr,
const char *pNewStr, const char *pContext)
  |  ^

Bug#997865: autopkgtest: dependency satisfied from testing instead of unstable

2021-10-26 Thread Mathias Behrle

* Paul Gevers: " Re: Bug#997865: autopkgtest: dependency satisfied from testing
  instead of unstable" (Tue, 26 Oct 2021 14:01:24 +0200):

Hi Paul,

big thanks for your quick reaction.

> On 26-10-2021 11:25, Mathias Behrle wrote:
> > I am setting the severity to important because this behavior blocks
> > the migration of the Tryton suite to testing. Testing has Tryton 5.0,
> > Unstable has Tryton 6.0.
> > 
> > The problem can be seen at
> > https://ci.debian.net/data/autopkgtest/testing/amd64/t/tryton-modules-account-payment/16194968/log.gz
> > 
> > Setting up tryton-modules-currency (6.0.1-1) ...
> > Setting up tryton-modules-country (6.0.1-1) ...
> > Setting up tryton-modules-party (6.0.2-1) ...
> > Setting up tryton-modules-company (6.0.5-1) ...
> > Setting up tryton-modules-account (6.0.3-1) ...
> > Setting up tryton-modules-product (5.0.5-1) ...
> > Setting up tryton-modules-account-product (5.0.5-1) ...
> > Setting up tryton-modules-account-invoice (5.0.14-1) ...
> > Setting up tryton-modules-account-payment (6.0.1-1) ...
> > Setting up autopkgtest-satdep (0) ...
> > 
> > The versioned depends of tryton-modules-account-payment are pulled in
> > correctly, while the depends of the tests/control is (partly!) satisfied
> > from testing instead of unstable. The relevant control file is [1].  
> 
> And why do you think that is wrong? britney (the migration software run
> the Release Team (of which I am a member)) tries to test with as much as
> possible from testing as allowed by version constraints. So, if there's
> nothing *forcing* the versions from unstable, than we try to use the
> versions from testing. The log you pointed at has this:
> --pin-packages=unstable=src:tryton-modules-account-payment,src:tryton-modules-account,src:tryton-modules-company,src:tryton-modules-country,src:tryton-modules-currency,src:tryton-modules-party,src:tryton-proteus,src:tryton-server

It is very interesting that tryton-proteus is part of this pinning despite it
doesn't appear at all in debian/control, but only in debian/tests/control.

S.
https://salsa.debian.org/tryton-team/tryton-modules-account-payment/-/blob/debian/debian/tests/control

> That means that britney considered all those packages to be needed from
> unstable, but nothing more and autopktest will request apt to install
> only that set from unstable. As we see no "fallback" apparently that's
> possible with current version constraints.
> 
> > tryton-proteus is correctly pulled in as
> > Setting up tryton-proteus (6.0.3-1)  
> 
> Because of the versioned Depends:
> https://packages.debian.org/unstable/tryton-modules-account-payment

tryton-proteus is *not* part of the versioned depends in debian/control.
S.
https://salsa.debian.org/tryton-team/tryton-modules-account-payment/-/blob/debian/debian/control
 
> > while tryton-modules-account-invoice is falsely taken from testing
> > Setting up tryton-modules-account-invoice (5.0.14-1) ...  
> 
> But where is it coded that that version is wrong?

I have no say where this could be coded, but taking packages with lower
versions from testing instead using the last available versions in unstable for
an autopgktest running in unstable seems definitely not logical to me.

Besides the fact that the choice seems to happen randomly, see above.
 
> > The test run was on 25 Oct 2021, tryton-modules-account-invoice 6.0.3-1 was
> > accepted into unstable at 19 Oct 2021.
> > 
> > Please advise, if this is not the correct package or if something else
> > is missing.  
> 
> If at all, the issue lies with britney, but as far as I see it, the
> tryton stack is probably missing a versioned (test) dependency or
> versioned Breaks somewhere. As I have no clue about the tryton stack, I
> can only advice in general terms. Please consider if one of the packages
> in unstable now breaks a package in testing that is allowed to be
> combined by the current versions.

Tryton 6.0 packages (in unstable) will generally break Tryton 5.0 (in testing).
But all Tryton packages in unstable are 6.0 at the moment and depend on >= 6.0.

> If *only* the test is broken,

For me only tests are broken. BTW piuparts shows no problems with the Tryton
packages.

> you can either 1) add the Breaks nevertheless (not all people are fan of
> this), 

That means I would have to add Breaks against all *test* dependencies < 6.0?
Sounds quite odd.

> 2) add a *versioned* *test* Dependency in the "broken" package or

Of course I would favor that solution, *if* it would be injectable like 
dh_gencontrol -- -Vversion:major="$(MAJOR)"
but that's unfortunately not the case. I would have to go with hard coded
versions in tests/control which is from maintainer point of view a PITA.

> 3) ask the Release Team (me) to manually trigger the combination. Note
> that the first two give you control, while the latter means work for me.

Of course the latter should and will be the last ressort.

> You'd need to explain why it's only the test that's broken and I prefer
> you

Bug#997891: elfutils: [INTL:de] initial German debconf translation

2021-10-26 Thread Helge Kreutzmann

Package: elfutils
Version: 0.185-2
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for elfutils
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the elfutils package.
# Helge Kreutzmann , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: elfutils 0.185-2\n"
"Report-Msgid-Bugs-To: elfut...@packages.debian.org\n"
"POT-Creation-Date: 2021-03-06 18:23-0500\n"
"PO-Revision-Date: 2021-09-26 11:11+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../libdebuginfod-common.templates:1001
msgid "Connect to Debian's debuginfod server to download debug symbols?"
msgstr ""
"Mit Debians debuginfod-Sever zum Herunterladen von Debug-Symbolen verbinden?"

#. Type: boolean
#. Description
#: ../libdebuginfod-common.templates:1001
msgid ""
"While debugging programs (with GDB, for example) or using debuginfo-consumer "
"applications, it is possible to connect to Debian's debuginfod server and "
"download the necessary debug information for the program you are debugging "
"on-the-fly, without the need to configure the debian-debug apt repository "
"nor installing any dbgsym packages.  This service is maintained by Debian, "
"and the only information you will have to send to it is the Build-ID hash of "
"the program(s)/library(ies) being debugged."
msgstr ""
"Bei der Fehlersuche in Programmen (mit beispielsweise GDB) oder dem Einsatz "
"von debuginfo-consumer-Anwendungen ist es möglich, sich mit Debians "
"debuginfod-Server zu verbinden und die notwendigen Fehlersuchinformationen "
"für das Programm, dass sie untersuchen, direkt herunterzuladen, ohne das Apt-"
"Depot debian-debug konfigurieren oder irgend ein dbgsym-Paket "
"herunterzuladen zu müssen. Dieser Dienst wird von Debian bereitgestellt und "
"die einzige Information, die sie dem Dienst senden müssen, ist der Hash der "
"Build-ID der Programme/Bibliotheken, für die die Fehlersuche erfolgt."

Bug#995116: 0.3.39-1 No soundcard anymore

2021-10-26 Thread Thomas Renard






On 26.10.21 14:38, Dylan Aïssi wrote:

Le lun. 25 oct. 2021 à 13:15, Thomas Renard  a écrit :




Do you have pipewire-pulse 0.3.39 installed, but not wireplumber?



I checked my setup with

pipewire-pulse 0.3.39
wireplumber 0.4.4-1

and it works and shows up all interfaces. In my setup I now have an 
additional alsa-output.pci-_00_03.0.hdmi-stereo I had not before ;-)


So now there is the question where to put the dependency (or a 
dependency anyways) to wireplumber?


Thomas

Bug#947771: unbound: cannot restart daemon under sysvinit-core when apparmor is enforced

2021-10-26 Thread Simon Deziel


I took the patch from Gedalya and proposed it:

https://salsa.debian.org/dns-team/unbound/-/merge_requests/17

Bug#997890: ITP: node-whatwg-fetch -- window.fetch JavaScript polyfill

2021-10-26 Thread Nicolas Mora


Package: wnpp
Severity: wishlist
Owner: Nicolas Mora 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-whatwg-fetch
  Version : 3.6.2
  Upstream Author : GitHub, Inc.
* URL : https://github.com/github/fetch#readme
* License : Expat
  Programming Lang: JavaScript
  Description : window.fetch JavaScript polyfill

 The fetch() function is a Promise-based mechanism for programmatically 
making

 web requests in the browser. This project is a polyfill that implements a
 subset of the standard Fetch specification, enough to make fetch a viable
 replacement for most uses of XMLHttpRequest in traditional web 
applications.

 .
 Node.js is an event-based server-side JavaScript engine.

This is a dependency to package node-cross-fetch

Bug#886958: Duplicate of #532015?

2021-10-26 Thread era

Should this be marked as a duplicate of #532015?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#997889: bison: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bison)

2021-10-26 Thread agrigomi

Package: bison
Version: 2:3.8.2+dfsg-1
Severity: important
X-Debbugs-Cc: megrigo...@gmail.com

Dear Maintainer,

In testing (bookworm) with glibc version 2.30-8
bison package requires glibc version 2.23


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 bison depends on:
ii  libc6  2.30-4
ii  m4 1.4.18-5

bison recommends no packages.

Versions of packages bison suggests:
pn  bison-doc  

-- no debconf information

Bug#997888: RM: pgaudit -- ROM; superseded by pgaudit-1.6

2021-10-26 Thread Christoph Berg

Package: ftp.debian.org
Severity: normal

Hi,

please remove pgaudit from unstable. That package supports PostgreSQL
13 only; the new source package pgaudit-1.6 supports PostgreSQL 14
which we are moving to.

Christoph

Bug#997813: ITP: python-python-docx -- library for creating and updating Microsoft Word files

2021-10-26 Thread Sandro Tosi

On Mon, 25 Oct 2021 09:49:52 +0300 Andrius Merkys  wrote:
> Package: wnpp
> Owner: Andrius Merkys 
> Severity: wishlist
>
> * Package name: python-python-docx

what's the reason for the double 'python' in the source name? given
there's no `src:python-docx` this should be fixed right away same goes
for the binary name, given the module is docx, it should be
python3-docx, as the python policy mandates

thanks

>   Version : 0.8.11
>   Upstream Author : Steve Canny
> * URL : https://github.com/python-openxml/python-docx
> * License : Expat
>   Programming Lang: Python
>   Description : library for creating and updating Microsoft Word
> files (Python 3)
>
> python-docx is a Python library for creating and updating Microsoft Word
> (.docx) files.
>
> python-docx is a dependency of FinalCif which would be nice to have in
> Debian.
>
> Remark: This package is to be maintained with Debian Python Team
>
>

Bug#997660: calibre: Ah yes, I seem to be having this issue as well!

2021-10-26 Thread Alex Relis

Package: calibre
Version: 5.30.0+dfsg-1
Followup-For: Bug #997660

Dear Maintainer,

I'm on version 5.30.0+dfsg-1 and I am still experiencing this bug. It hasn't 
been fixed quite yet. Here's the error I seem to be getting:

alex@alex-pc:~$ calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 21, in 
sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 64, in calibre
main(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 533, in main
app, opts, args = init_qt(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 124, in init_qt
app = Application(args, override_program_name=override, 
windows_app_uid=MAIN_APP_UID)
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 894, in __init__
from calibre_extensions import progress_indicator
RuntimeError: the sip module implements API v12.0 to v12.8 but the 
progress_indicator module requires API v12.9

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

Kernel: Linux 5.14.0-trunk-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 calibre depends on:
ii  calibre-bin  5.30.0+dfsg-1
ii  dpkg 1.20.9
ii  fonts-liberation22.1.5-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  libjpeg-turbo-progs  1:2.0.6-4
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-2
ii  poppler-utils20.09.0-3.1
ii  python3  3.9.2-3
ii  python3-apsw 3.36.0-r1-2
ii  python3-bs4  4.10.0-2
ii  python3-chardet  4.0.0-1
ii  python3-chm  0.8.6-3
ii  python3-css-parser   1.0.6-1
ii  python3-cssselect1.1.0+ds-2
ii  python3-cssutils 1.0.2-3
ii  python3-dateutil 2.8.1-6
ii  python3-feedparser   5.2.1-3
ii  python3-html2text2020.1.16-1
ii  python3-html5-parser 0.4.10-1
ii  python3-html5lib 1.1-3
ii  python3-jeepney  0.6.0-1
ii  python3-lxml 4.6.3+dfsg-1
ii  python3-markdown 3.3.4-1
ii  python3-mechanize1:0.4.5-2
ii  python3-msgpack  1.0.2-2
ii  python3-netifaces0.11.0-1
ii  python3-pil  8.3.2-1
ii  python3-pkg-resources58.2.0-1
ii  python3-py7zr0.11.3+dfsg-1
ii  python3-pygments 2.7.1+dfsg-2.1
ii  python3-pyparsing2.4.7-1
ii  python3-pyqt55.15.5+dfsg-1
ii  python3-pyqt5.qtsvg  5.15.5+dfsg-1
ii  python3-pyqt5.qtwebengine5.15.5-1
ii  python3-pyqt5.sip12.9.0-3
ii  python3-regex0.1.20211008-1
ii  python3-routes   2.5.1-1
ii  python3-speechd  0.10.2-3
ii  python3-zeroconf 0.36.9-1
ii  python3.93.9.7-4
ii  xdg-utils1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.0.0-1
ii  python3-ipython7.22.0-1
ii  udisks22.9.4-1

Versions of packages calibre suggests:
ii  python3-openssl   21.0.0-1
pn  python3-unrardll  

-- no debconf information

Bug#997887: r-cran-effectsize: autopkgtest regression on ppc64el: machine precision issue?

Source: r-cran-effectsize
Version: 0.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 r-cran-effectsize the autopkgtest of
r-cran-effectsize fails in testing on ppc64el when that autopkgtest is
run with the binary packages of r-cran-effectsize from unstable. It
passes when run with only packages from testing. In tabular form:

   passfail
r-cran-effectsize  from testing0.5-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=r-cran-effectsize

https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/r-cran-effectsize/16211124/log.gz

BEGIN TEST spelling.R

R version 4.1.1 (2021-08-10) -- "Kick Things"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: powerpc64le-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> if (requireNamespace("spelling", quietly = TRUE)) {
+   spelling::spell_check_test(
+ vignettes = TRUE, error = FALSE,
+ skip_on_cran = TRUE
+   )
+ }
> 
BEGIN TEST testthat.R

R version 4.1.1 (2021-08-10) -- "Kick Things"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: powerpc64le-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(testthat)
> library(effectsize)
> 
> test_check("effectsize")
Starting 2 test processes
══ Skipped tests
═══
• On CRAN (17)
• rstanarm cannot be loaded (1)

══ Failed tests

── Failure (test-eta_squared.R:89:5): aov
──
et1$CI_low (`actual`) not equal to et2$CI_low (`expected`).

  `actual`: 0.20996729 0.
`expected`: 0.20996728 0.

[ FAIL 1 | WARN 1 | SKIP 18 | PASS 467 ]
Error: Test failures
Execution halted
autopkgtest [22:31:26]: test run-unit-test




OpenPGP_signature
Description: OpenPGP digital signature

Bug#997886: prottest: autopkgtest regression: Stats file does not exist

Source: prottest
Version: 3.4.2+dfsg-6
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
prottest   from testing3.4.2+dfsg-6
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=prottest

https://ci.debian.net/data/autopkgtest/testing/amd64/p/prottest/16225046/log.gz

-
Basic usage:  - Sequential version: java -jar prottest-3.4.2.jar
-i align_file [OPTIONS]
./prottest3 -i align_file [OPTIONS]
 - Parallel version: mpjrun.sh -wdir $PWD/ -np [NUM_PROCS] -jar
prottest-3.4.2.jar -i align_file [OPTIONS]
OPTIONS:
 -i alignment_filename
Alignment input file (required)
 -t tree_filename
Tree file   (optional) [default: NJ tree]
 -o output_filename
Output file (optional) [default: standard output]
 -log enabled/disabled
Enables / Disables PhyML logging into log directory (see
prottest.properties)
 -[matrix]
Include matrix (Amino-acid) = JTT LG DCMut MtREV MtMam MtArt
Dayhoff WAG   RtREV CpREV Blosum62 VT
HIVb HIVw FLU If you don't specify any matrix, all
matrices displayed above will
be included.
 -I
Include models with a proportion of invariable sites
 -G
Include models with rate variation among sites and number of
categories
 -IG
include models with both +I and +G properties
 -all-distributions
Include models with rate variation among sites, number of
categories and both
 -ncat number_of_categories
Define number of categories for +G and +I+G models [default: 4]
 -F
Include models with empirical frequency estimation  -AIC
Display models sorted by Akaike Information Criterion (AIC)
 -BIC
Display models sorted by Bayesian Information Criterion (BIC)
 -AICC
Display models sorted by Corrected Akaike Information
Criterion (AICc)
 -DT
Display models sorted by Decision Theory Criterion
 -all
Displays a 7-framework comparison table
 -S optimization_strategy
Optimization strategy mode: [default: 0]
0: Fixed BIONJ JTT
1: BIONJ Tree
2: Maximum Likelihood tree
3: User defined topology
 -s moves
Tree search operation for ML search: NNI
(fastest), SPR (slowest), BEST (best of NNI and SPR) [default: NNI]
 -t1
Display best-model's newick tree [default: false]
 -t2
Display best-model's ASCII tree  [default: false]
 -tc consensus_threshold Display consensus tree with the
specified threshold, between 0.5 and 1.0
[0.5 = majority rule consensus ; 1.0 = strict consensus]
 -threads number_or_threads 
Number of threads requested to compute (only if MPJ is not
used) [default: 1]
 -verbose
Verbose mode [default: false]
-
Example: - Sequential version:
java -jar prottest-3.4.2.jar -i align_file -t tree_file -S 0
-all-distributions -F -AIC -BIC -tc 0.5 > output
- Parallel version:
mpjrun.sh -wdir $PWD/ -np 2 -jar prottest-3.4.2.jar -i align_file -t
tree_file -S 0 -all-distributions -F -AIC -BIC -tc 0.5
PHYLIP format detected.MSA read in PHYLIP format (Taxa = 28, Length =
149).MSA successfully converted to PHYLIP format!

No such file or directory

--
ProtTest 3.4.2  Fast selection of the best-fit
models of protein evolution
(c) 2009-2016   Diego Darriba (1,2), Guillermo Taboada (2), Ramón Doallo
(2), David Posada (1)
(1)   Facultad de Biologia, Universidad de
Vigo, 36200 Vigo, Spain
(2)Facultade de Informática, Universidade da Coruña,
15071 A Coruña, Spain
--
Manual:

Bug#997885: python-moreorless: autopkgtest regression: No module named 'parameterized'

Source: python-moreorless
Version: 0.4.0-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-moreorless the autopkgtest of
python-moreorless fails in testing when that autopkgtest is run with the
binary packages of python-moreorless from unstable. It passes when run
with only packages from testing. In tabular form:

   passfail
python-moreorless  from testing0.4.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looks like
you're missing a (test) dependency.

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-moreorless

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

=== testing with python3.9 ===
Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
  File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
  File
"/tmp/autopkgtest-lxc.tkseerp6/downtmp/autopkgtest_tmp/python-moreorless/tests/__main__.py",
line 4, in 
from .general import ParityTest  # noqa: F401
  File
"/tmp/autopkgtest-lxc.tkseerp6/downtmp/autopkgtest_tmp/python-moreorless/tests/general.py",
line 6, in 
from parameterized import parameterized
ModuleNotFoundError: No module named 'parameterized'
autopkgtest [19:14:08]: test unittests




OpenPGP_signature
Description: OpenPGP digital signature

Bug#997884: libgclib breaks cdbfasta autopkgtest: ABI breakage?

Source: libgclib
Control: found -1 libgclib/0.12.7+ds-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks
Control: affects -1 src:cdbfasta

Dear maintainer(s),

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

   passfail
libgclib   from testing0.12.7+ds-2
cdbfasta   from testing1.00+git20181005.014498c+dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
message and the changelog, it seems that symbols were changed, but this
one was apparently used by cdbfasta. I think this points at an ABI
breakage and the SONAME of libgclib must be bumped and a transition must
be followed through. (I could be wrong).

Currently this regression is blocking the migration of libgclib to
testing [1]. Can you please investigate the situation?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cdbfasta/16212088/log.gz

+ cdbfasta ebola.fasta
cdbfasta: symbol lookup error: cdbfasta: undefined symbol: _Z8GReallocPPvm
autopkgtest [22:12:39]: test run-unit-tests




OpenPGP_signature
Description: OpenPGP digital signature

Bug#997883: rails: autopkgtest needs update for new version of puma: Could not find gem 'puma (~> 4.1)'

Source: rails
Version: 2:6.0.3.7+dfsg-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, p...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:puma

Dear maintainer(s),

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

   passfail
puma   from testing5.3.2-3
rails  from testing2:6.0.3.7+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 puma to testing
[1]. Of course, puma shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in puma 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 puma 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=puma

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rails/16207757/log.gz

 run  bundle install --local
Could not find gem 'puma (~> 4.1)' in cached gems from rubygems repository
https://rubygems.org/ or installed locally.
The source contains the following versions of 'puma': 5.3.2
 run  bundle binstubs bundler
Could not find gem 'puma (~> 4.1)' in locally installed gems.
The source contains the following versions of 'puma': 5.3.2
 run  bundle exec spring binstub --all
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:278:in
`block in verify_gemfile_dependencies_are_found!': Could not find gem
'puma (~> 4.1)' in locally installed gems. (Bundler::GemNotFound)
The source contains the following versions of 'puma': 5.3.2
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:253:in
`each'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:253:in
`verify_gemfile_dependencies_are_found!'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:50:in
`start'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:23:in
`resolve'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/definition.rb:262:in
`resolve'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/definition.rb:483:in
`materialize'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/definition.rb:234:in
`specs_for'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/runtime.rb:18:in
`setup'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler.rb:149:in
`setup'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/setup.rb:20:in
`block in '
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/ui/shell.rb:136:in
`with_level'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/ui/shell.rb:88:in
`silence'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/setup.rb:20:in
`'
from
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in
`require'
from
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in
`require'
+ cd foo
+ rails runner puts "Empty Rails %s app booted correctly" % Rails.version
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:278:in
`block in verify_gemfile_dependencies_are_found!': Could not find gem
'puma (~> 4.1)' in locally installed gems. (Bundler::GemNotFound)
The source contains the following versions of 'puma': 5.3.2
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:253:in
`each'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:253:in
`verify_gemfile_dependencies_are_found!'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:50:in
`start'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/resolver.rb:23:in
`resolve'
from
/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/definition.rb:262:in
`resolve'
from

Bug#997882: licensecheck: autopkgtest regression: lots of failures

Source: licensecheck
Version: 3.2.13-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 licensecheck the autopkgtest of licensecheck
fails in testing when that autopkgtest is run with the binary packages
of licensecheck from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
licensecheck   from testing3.2.13-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=licensecheck

https://ci.debian.net/data/autopkgtest/testing/amd64/l/licensecheck/16222812/log.gz

t/OSI.t .. # Seeded srand with seed '20211026' from
local date.
1..26
ok 1 - Corpus file t/OSI/MPL-1.0
ok 2 - Corpus file t/OSI/EPL-1.0
ok 3 - Corpus file t/OSI/RPSL-1.0
ok 4 - Corpus file t/OSI/Artistic-2.0
ok 5 - Corpus file t/OSI/Python-2.0
ok 6 - Corpus file t/OSI/Zlib
ok 7 - Corpus file t/OSI/AFL-3.0
ok 8 - Corpus file t/OSI/GPL-2.0
ok 9 - Corpus file t/OSI/BSL-1.0
ok 10 - Corpus file t/OSI/LGPL-2.0
ok 11 - Corpus file t/OSI/MPL-1.1
ok 12 - Corpus file t/OSI/CECILL-2.1
ok 13 - Corpus file t/OSI/Apache-2.0
ok 14 - Corpus file t/OSI/AGPL-3.0
ok 15 - Corpus file t/OSI/NTP
ok 16 - Corpus file t/OSI/Artistic-1.0-Perl
ok 17 - Corpus file t/OSI/PostgreSQL
ok 18 - Corpus file t/OSI/MPL-2.0
ok 19 - Corpus file t/OSI/OFL-1.1
ok 20 - Corpus file t/OSI/CDDL-1.0
ok 21 - Corpus file t/OSI/BSD-3-Clause
ok 22 - Corpus file t/OSI/MIT
ok 23 - Corpus file t/OSI/BSD-2-Clause-Views
ok 24 - Corpus file t/OSI/QPL-1.0
ok 25 - Corpus file t/OSI/LGPL-2.1
ok 26 - Corpus file t/OSI/ISC
ok
t/SPDX.t . # Seeded srand with seed '20211026' from
local date.
1..88
ok 1 - Corpus file t/SPDX/CC-BY-2.5.txt
ok 2 - Corpus file t/SPDX/CC-BY-SA-4.0.txt
ok 3 - Corpus file t/SPDX/CC-BY-NC-ND-4.0.txt
ok 4 - Corpus file t/SPDX/CC-BY-NC-SA-3.0.txt
ok 5 - Corpus file t/SPDX/BSD-3-Clause.txt
ok 6 - Corpus file t/SPDX/CC-BY-SA-2.0.txt
ok 7 - Corpus file t/SPDX/AFL-2.0.txt
ok 8 - Corpus file t/SPDX/LGPL-2.0.txt
ok 9 - Corpus file t/SPDX/zlib-acknowledgement.txt
ok 10 - Corpus file t/SPDX/MS-RL.txt
ok 11 - Corpus file t/SPDX/Apache-2.0.txt
ok 12 - Corpus file t/SPDX/OFL-1.0.txt
ok 13 - Corpus file t/SPDX/Zlib.txt
ok 14 - Corpus file t/SPDX/Eurosym.txt
ok 15 - Corpus file t/SPDX/ISC.txt
ok 16 - Corpus file t/SPDX/MIT-feh.txt
ok 17 - Corpus file t/SPDX/CC-BY-SA-3.0.txt
ok 18 - Corpus file t/SPDX/MIT-CMU.txt
ok 19 - Corpus file t/SPDX/Artistic-1.0.txt
ok 20 - Corpus file t/SPDX/WTFPL.txt
ok 21 - Corpus file t/SPDX/EPL-1.0.txt
ok 22 - Corpus file t/SPDX/CC-BY-NC-2.5.txt
ok 23 - Corpus file t/SPDX/CDDL-1.0.txt
ok 24 - Corpus file t/SPDX/CC0-1.0.txt
ok 25 - Corpus file t/SPDX/MIT.txt
ok 26 - Corpus file t/SPDX/CC-BY-1.0.txt
ok 27 - Corpus file t/SPDX/AGPL-1.0.txt
ok 28 - Corpus file t/SPDX/AFL-3.0.txt
ok 29 - Corpus file t/SPDX/CC-BY-SA-2.5.txt
ok 30 - Corpus file t/SPDX/ICU.txt
ok 31 - Corpus file t/SPDX/AFL-2.1.txt
ok 32 - Corpus file t/SPDX/CC-BY-NC-3.0.txt
ok 33 - Corpus file t/SPDX/SGI-B-1.1.txt
ok 34 - Corpus file t/SPDX/CC-BY-ND-3.0.txt
ok 35 - Corpus file t/SPDX/Python-2.0.txt
ok 36 - Corpus file t/SPDX/CC-BY-NC-SA-1.0.txt
ok 37 - Corpus file t/SPDX/CC-BY-NC-4.0.txt
ok 38 - Corpus file t/SPDX/CECILL-1.0.txt
ok 39 - Corpus file t/SPDX/MS-PL.txt
ok 40 - Corpus file t/SPDX/MPL-1.0.txt
ok 41 - Corpus file t/SPDX/CC-BY-NC-SA-2.5.txt
ok 42 - Corpus file t/SPDX/MPL-2.0.txt
ok 43 - Corpus file t/SPDX/Libpng.txt
ok 44 - Corpus file t/SPDX/OFL-1.1.txt
ok 45 - Corpus file t/SPDX/Cube.txt
ok 46 - Corpus file t/SPDX/CC-BY-3.0.txt
ok 47 - Corpus file t/SPDX/CC-BY-ND-1.0.txt
ok 48 - Corpus file t/SPDX/CC-BY-NC-ND-1.0.txt
ok 49 - Corpus file t/SPDX/CC-BY-SA-1.0.txt
ok 50 - Corpus file t/SPDX/CC-BY-2.0.txt
ok 51 - Corpus file t/SPDX/CC-BY-NC-1.0.txt
ok 52 - Corpus file t/SPDX/AFL-1.1.txt
ok 53 - Corpus file t/SPDX/CC-BY-ND-2.5.txt
ok 54 - Corpus file t/SPDX/MIT-enna.txt
ok 55 - Corpus file t/SPDX/Apache-1.1.txt
ok 56 - Corpus file t/SPDX/RPSL-1.0.txt
ok 57 - Corpus file t/SPDX/CC-BY-4.0.txt
ok 58 - Corpus file t/SPDX/MIT-advertising.txt
ok 59 - Corpus file t/SPDX/BSD-4-Clause.txt
ok 60 - Corpus file t/SPDX/SGI-B-1.0.txt
ok 61 - Corpus file t/SPDX/Artistic-2.0.txt
ok 62 - Corpus file t/SPDX/LGPL-2.1.txt
ok 63 - Corpus file t/SPDX/CC-BY-NC-ND-2.0.txt
ok 64 - Corpus file t/SPDX/Aladdin.txt
ok 65 - Corpus file t/SPDX/CECILL-B.txt
ok 66 - Corpus file t/SPDX/AFL-1.2.txt
ok 67 - Corpus file t/SPDX/MPL-1.1.txt
ok 68 - Corpus file t/SPDX/curl.txt
ok 69 - Corpus file t/SPDX/QPL-1.0.txt
ok 70 - Corpus file t/SPDX/FTL.txt

Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)

2021-10-26 Thread Brendon Higgins

Hi Brian,

On Tuesday, October 26, 2021 8:13:01 A.M. EDT Brian Potkin wrote:
> On Mon 25 Oct 2021 at 16:07:36 -0400, Brendon Higgins wrote:
> > Hi Brian,
> > 
> > Perhaps I was unclear in my description. You responded:
> > > You want to replace hp-plugin
> > 
> > On the contrary, I would think the proposed hplip-plugin-installer package
> > would pre-depend on hplip and essentially just run hp-plugin in its
> > postinst. It's complementary, not a replacement.
> > 
> > > with something Debian-specific that Debian has to maintain for ever.
> > 
> > Debian-specific, perhaps, though hardly beyond ordinary packaging
> > practices. Could be useful for derivatives, too. I would think
> > maintenance for such a simple thing would be minimal (barring major
> > upstream changes - which users would have to figure out for themselves,
> > otherwise).
> > 
> > And as I mentioned, there's plenty of precedent for this approach, and the
> > arguments against those are the same.
> 
> It strikes me that an hplip-plugin-installer package would not provide
> anything over and above what hp-plugin provides. This checksum issue
> reported in Launchpad #1948555 is not uncommon and such a package
> would not alleviate it. The usual way to tackle it is download the
> plugin and install with 'sh '.

Download the plugin from where? I traced its source to the location given in 
that Launchpad bug, and it's obviously a broken upload at the server - this is 
a "true negative" checksum failure. (Please try it - it still hasn't been fixed 
as of writing.) I haven't been able to uncover an alternative download 
location, so if you know of one I would love to hear it (really!).

This negative experience is what inspired me to suggest hp-plugin-installer - 
because it does provide key usability benefits due to this property: it would 
run at the same time that the hplip packages are updated. The benefits that 
come from this are:
1. Automatic updating of the plugin to the corresponding version - which, 
assuming an environment that uses one of the affected devices, is implicitly 
required by the hplip package for it to be at all useful.
2. Any failure to download/install the updated plugin can be found and 
addressed by the system administrator immediately. This is in contrast to the 
current situation where the system is left in an incomplete, unusable state, 
for an indefinite period of time, until the user might try to use their device, 
encounter a problem, and the user (rather than system administrator) is 
expected to fix that.

In my case, the plugin file being broken upstream was my critical failure 
point. I only encountered this weeks after the hplip packages updated - it 
seems to me that the plugin file might have been okay back then. (I've since 
had to downgrade back to stable's version.) But I can imagine other situations 
which would be helped by hp-plugin-installer, too - perhaps the system is 
portable and not always connected to the internet, so downloading the plugin 
at any given time (even if it is good upstream) is not feasible, but 
downloading it when packages are also downloaded and installed makes much more 
sense. Or perhaps the user has been granted printing permissions but not root 
permissions by the system administrator - the sysadmin would absolutely want 
some kind of automation to install this plugin in such a situation...

> There is also the matter of what runs the proposed package. It cannot
> be from any of the HPLIP packages because, as the Debian Policy Manual
> says:
> 
>   In addition, the packages in main must not require or recommend
>   a package outside of main for compilation or execution...

hplip could suggest it, though. At any rate, I imagine the sysadmin would 
install hp-plugin-installer (from contrib) themselves. They would only need to 
do that once, and only if they actually had a device that needs the plugin to 
be installed. hp-plugin-installer would be versioned alongside hplip and 
update at the same time, and thereby run hp-plugin to grab and install the 
necessary plugin version at the time (or immediately after) the hplip update 
is installed.

When I get some time I'll try to get a basic patch working.

> Ultimately, it is the user's responsibility to download a non-free plugin.

Well, to be precise, it's the sysadmin's responsibility to install said 
plugin, rather than the user's (unless they happen to be the sysadmin, but 
then it's a question of which hat they're wearing at any point in time).

Peace,
Brendon

Bug#997881: keepalived: track_script in vrrp_instance gets removed and logged as "not used"

2021-10-26 Thread Sebastian Philipp


Package: keepalived
Version: 1:2.1.5-0.2
Severity: important
Tags: upstream
X-Debbugs-Cc: sebastian.phil...@adfinis.com

Dear Maintainer,

upstream keepalived 2.1 contains a bug which causes unweighted
track_scripts assigned directly to a vrrp_instance to be removed and
unintuitively logged as "script is not used".

The bug is tracked upstream as
https://github.com/acassen/keepalived/issues/1813 and
is fixed in the 2.2 release line.  A patch is available, it is linked
in the upstream issue ticket.  According to an upstream maintainer, this
patch should apply cleanly to 2.1.5.

## Example keepalived configuration

```
global_defs {
router_id ha01
enable_script_security
}

vrrp_script check_haproxy {
script "/usr/bin/killall -0 haproxy"
interval 1
weight 0
user root
}

vrrp_instance vi_haproxy {
interface enp1s0
state MASTER
priority 255
advert_int 1
virtual_router_id 42

virtual_ipaddress {
fe80::42/64
2001:db8::42/64
}

track_script {
check_haproxy
}

}
```

(Yes, I'm aware of vrrp_track_process; this is just an example for
reproducing the issue.)

The example in the upstream bug report uses a configuration with
multiple instances grouped together in a vrrp_sync_group, but the issue
appears with a single vrrp_instance as well.

## Expected behavior

The check script should be applied, regularly executed and vi_haproxy
set to MASTER or FAULT depending on the script outcome.

## Actual behavior

keepalived mistakenly emties out the track_script list; the vi_haproxy
instance then does not have any health checks assigned and will always
be in MASTER state.

On startup, keepalived logs that the script is not used:

Oct 26 16:23:04 ha01 Keepalived_vrrp[132483]: Opening file 
'/etc/keepalived/keepalived.conf'.
Oct 26 16:23:04 ha01 Keepalived_vrrp[132483]: Warning - script 
check_haproxy is not used
Oct 26 16:23:04 ha01 Keepalived_vrrp[132483]: Registering gratuitous 
NDISC shared channel
Oct 26 16:23:04 ha01 Keepalived_vrrp[132483]: (vi_haproxy) Entering 
MASTER STATE
Oct 26 16:23:04 ha01 Keepalived_vrrp[132483]: (vi_haproxy) using locally 
configured advertisement interval (1000 milli-sec)


## Workaround

The upstream maintainer proposes a workaround:  Apply the track_script
to a vrrp_sync_group instead of the vrrp_instance.  In the config
example in the upstream bug report, this is easily done, as sync groups
are already used, however in this simple case this introduces quite some
overhead, as keepalived doesn't allow sync groups with only one member,
so a second dummy instance is required to use the workaround.

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages keepalived depends on:
ii  init-system-helpers  1.60
ii  iproute2 5.10.0-4
ii  libc62.31-13+deb11u2
ii  libglib2.0-0 2.66.8-1
ii  libmnl0  1.0.4-3
ii  libnftnl11   1.1.9-1
ii  libnl-3-200  3.4.0-1+b1
ii  libnl-genl-3-200 3.4.0-1+b1
ii  libpcre2-8-0 10.36-2
ii  libsnmp405.9+dfsg-3+b1
ii  libssl1.11.1.1k-1+deb11u1

Versions of packages keepalived recommends:
ii  ipvsadm  1:1.31-1+b1

keepalived suggests no packages.

-- no debconf information

Bug#996734: src:nim: fails to migrate to testing for too long: ftbfs on armhf