Processed: Re: Bug#988674: python3-saga: broken symlink: /usr/lib/python3/dist-packages/_saga_api.cpython-39-x86_64-linux-gnu.so -> _saga_api-7.3.0.so

[Debian Bug Tracking System]

Processing control commands:

> tags -1 pending
Bug #988674 [python3-saga] python3-saga: broken symlink: 
/usr/lib/python3/dist-packages/_saga_api.cpython-39-x86_64-linux-gnu.so -> 
_saga_api-7.3.0.so
Added tag(s) pending.

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

Bug#988674: python3-saga: broken symlink: /usr/lib/python3/dist-packages/_saga_api.cpython-39-x86_64-linux-gnu.so -> _saga_api-7.3.0.so

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 5/18/21 6:25 AM, Sebastiaan Couwenberg wrote:
> On 5/17/21 8:30 PM, Andreas Beckmann wrote:
>> during a test with piuparts I noticed your package ships (or creates)
>> a broken symlink.
>>
>> >From the attached log (scroll to the bottom...):
>>
>> 6m23.3s ERROR: FAIL: Broken symlinks:
>>   /usr/lib/python3/dist-packages/_saga_api.cpython-39-x86_64-linux-gnu.so -> 
>> _saga_api-7.3.0.so (python3-saga)
>>
>> but the package ships the weirdly mangled
>>
>>   /usr/lib/python3/dist-packages/_saga_api-7.cpython-39-3.0.so
>>
>> instead.
> 
> That's courtesy of dh_pyton3:
> 
> dh_python3
>  I: dh_python3 fs:343: renaming _saga_api.so to
> _saga_api.cpython-39-x86_64-linux-gnu.so
>  I: dh_python3 fs:343: renaming _saga_api-7.3.0.so to
> _saga_api-7.cpython-39-3.0.so
> 
> --no-ext-rename may help to prevent this breakage.

That indeed fixes the issue:

 -rw-r--r-- root/root   3332800 2020-11-06 19:58
./usr/lib/python3/dist-packages/_saga_api-7.3.0.so
 lrwxrwxrwx root/root 0 2020-11-06 19:58
./usr/lib/python3/dist-packages/_saga_api.so -> _saga_api-7.3.0.so

Pre-approval of the changes in saga (7.3.0+dfsg-5) has been requested in
#988692 before upload to unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#988674: python3-saga: broken symlink: /usr/lib/python3/dist-packages/_saga_api.cpython-39-x86_64-linux-gnu.so -> _saga_api-7.3.0.so

[Sebastiaan Couwenberg]

On 5/17/21 8:30 PM, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
>>From the attached log (scroll to the bottom...):
> 
> 6m23.3s ERROR: FAIL: Broken symlinks:
>   /usr/lib/python3/dist-packages/_saga_api.cpython-39-x86_64-linux-gnu.so -> 
> _saga_api-7.3.0.so (python3-saga)
> 
> but the package ships the weirdly mangled
> 
>   /usr/lib/python3/dist-packages/_saga_api-7.cpython-39-3.0.so
> 
> instead.

That's courtesy of dh_pyton3:

dh_python3
 I: dh_python3 fs:343: renaming _saga_api.so to
_saga_api.cpython-39-x86_64-linux-gnu.so
 I: dh_python3 fs:343: renaming _saga_api-7.3.0.so to
_saga_api-7.cpython-39-3.0.so

--no-ext-rename may help to prevent this breakage.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#988217: bootefi causes boot failure with boot.scr

[Vagrant Cascadian]

On 2021-05-16, Vagrant Cascadian wrote:
> Control: severity 988217 serious
>
> On 2021-05-07, Vagrant Cascadian wrote:
>> On 2021-04-16, Bastian Germann wrote:
>>> On a Lamobo R1, I can verify 2021.01 versions not to boot with a
>>> default environment. However, 2020.10+dfsg-2 boots. Even though the
>>> original issue has the same outcome, I guess it is caused by something
>>> else.
>>
>> Different enough to warrant it's own bug, cloning...
>>
>>
>>> I figured out my problem is caused by
>>> https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f.
>>>  The
>>> boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr
>>> boot fail.
>>
>> This would definitely be good to fix in bullseye, but this is quite late
>> in the release cycle.

Heinrich, I was wondering if you had thoughts to share on the above
linked patch? How safe is it to apply to 2021.01 (e.g. the version that
will ship in bullseye), and have there been further developments
upstream relevent to this issue that might be good to be aware of?


> After recently upgrading several more systems that turned out to be
> affected by this, I'm bumping the severity of this bug...
>
>
>> Will need to test failure and success cases with and without EFI as well
>> as boot.scr and extlinux.conf to make sure this doesn't cause
>> regressions in other boot paths...
>
> This still needs some work!
>
>
>> An ugly workaround in the meantime would be to add a no-op boot.scr on
>> the media (e.g. mmc0) and then fall back to the other boot methods.
>
> I'm not sure this workaround is viable in a variety of situations...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Cyril Brulebois]

Hi Simon!

Simon McVittie  (2021-05-17):
> My instinct is that it's far, far too late to be moving to GTK 3 this
> cycle, and I'd prefer to get a suitable hack into GTK 2 if we can
> find one. We can make it #ifdef DEBIAN_INSTALLER to avoid disrupting
> the installed system.

If you're happy with further assisting us with getting away with GTK 2
one more time, that's very fine with me! Huge thanks for all your work
and help so far!

> I think d-i will need to move to GTK 3 early in the Debian 12 cycle,
> but hard freeze is not the time to be fast-forwarding through 10 years
> of GUI library development.

From my little “feasibility survey” over the last few days, there seem
to be a number of obvious issues to solve indeed!

> Getting
> https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4
> into cdebconf would make this easier, although we can revert it for
> the sake of a smaller diff once we think we have a solution if the
> release team are grumpy about it.

I'm very happy to see this patch merged, and possibly released into
bullseye. The most obvious side effect I can anticipate is possibly
bigger /var/log/installer/syslog files in the installed systems, but
users are expected to compress them anyway before attaching them in
installation reports (BTS and/or lists size limits).

Would you like that to be released into unstable right away? I'm happy
to deal with it if that helps testing stuff.

> It looks as though the problem is that the size GTK chooses for a
> GtkTextView (a debconf "note" or similar) is flapping between two
> values. GTK asks Pango "if you wrap lines at width x, how much space
> will you need?", then uses the result to re-run the layout algorithm,
> which changes the width available, which causes the layout algorithm to
> be re-run and so on. Under normal circumstances, this runs for a few
> iterations and then stabilizes at one size, terminating the loop, but
> when I select Sinhala from the language menu, the width flaps between
> 71 and 72 pixels, with each re-layout resulting in the other width.

Without looking into the code, one might try and keep track of results
that have been seen, and if N/N+1 is detected, maybe just assume this
should be N+1 and move on with other computations? But anyway, further
down your mail you seemed to have ideas already.

> I think this might be related to the fact that when the layout is
> calculated at the narrower width, Pango decides that there isn't space
> to put the "." at the end of a paragraph on the same line as the last
> word, and so wraps it to the next line, which is fine; except that
> you'd expect the space required for the last word to get a bit smaller
> when the "." is not included, but actually Pango tells GTK that it will
> need 1 pixel *more* for "අසම්පූර්ණයි" than for "අසම්පූර්ණයි.", resulting in it
> flapping between the narrower and wider width. I don't know why that
> happens - perhaps the Indic shaper is drawing a character at the end of
> a line more elaborately, or something?

Maybe the Indic shaper makes the problem more obvious but I definitely
saw a similar hang (even if I hadn't patched the installer to generate
log lines to make extra sure) with plain English when starting in rescue
mode.

> However, either 71 or 72 pixels seems a ridiculous width to be trying to
> squish multiple sentences into, so arguably it's a bug in GTK 2's layout
> algorithm that it is even considering that as a size. The GTK 2 layout
> algorithm does not necessarily make much sense, and the fact that it
> can feed back into itself is probably a GTK 2 design flaw. During the
> GTK 3 cycle it was redone to be in terms of "height for width" (if I
> give you this width, how much height will you need? the mode cdebconf
> will end up using) and "width for height" (the opposite, rarely used) -
> so hopefully GTK 3 avoids this failure mode. However, it also seems wrong
> that telling Pango that less width is available can result in it saying
> it needs *more* minimum width, and maybe preventing this from happening
> would get GTK 2 to do the right thing.
> 
> My next thing to get a try when I get a chance will be to make GTK refuse
> to obey Pango when GTK asks Pango to stick to a width limit and Pango goes
> outside that limit, with a g_warning(). This might result in the text
> being clipped at the right margin (or left margin in Hebrew/Arabic), or
> even having its "ink rectangle" overlap with the next widget to the right
> (or left); but for d-i, which always uses the full screen width and in
> practice has a generous amount of space for its text, we might get away
> with it? In a very brief test that seemed to resolve the Sinhala thing,
> but I haven't tried the other paths that lead to infinite loops. Please
> could someone who has tried the other scenarios provide a walkthrough?

What I can think of that's not (entirely) full-width:
 - buttons at the bottom;
 - checkboxes to toggle password/passphrase visibility (but they 

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Simon McVittie]

On Mon, 17 May 2021 at 18:12:35 +0200, Cyril Brulebois wrote:
> And for those not following #debian-boot, I'm finding myself between a
> rock and a hard place, as both options (trying to work around the
> rendering-related hangs versus switching to GTK 3 at the last moment)
> are very far from ideal… I'm not sure what we'll end up doing, and I'm
> happy to get some “votes” pro or against any of those options, and to
> hear about other options entirely.

My instinct is that it's far, far too late to be moving to GTK 3 this
cycle, and I'd prefer to get a suitable hack into GTK 2 if we can
find one. We can make it #ifdef DEBIAN_INSTALLER to avoid disrupting
the installed system.

I think d-i will need to move to GTK 3 early in the Debian 12 cycle,
but hard freeze is not the time to be fast-forwarding through 10 years
of GUI library development.

I've continued to look into GTK2/Pango with some rather extensive printf
debugging. I have other responsibilities and I'm trying to learn how
GTK/Pango text layout works from first principles (I'm in the GNOME
team but not really a GUI developer), so it's slow going, but I have
some ideas for things that might be able to break the loop. It's not
clear to me yet whether this is a GTK 2 bug, or a Pango bug, or what.
GNOME team members who actually know what they're doing are welcome
to step in any time.

Upstream are going to be incredibly reluctant to help us with GTK 2,
given that it has been deprecated in favour of GTK 3 for a decade, and
is officially EOL now that GTK 4 has stable releases. Pango does seem
like it's doing the wrong thing here, but perhaps GTK 2 or cdebconf is
holding it wrong.

Getting
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4
into cdebconf would make this easier, although we can revert it for the
sake of a smaller diff once we think we have a solution if the release
team are grumpy about it.

Philip Hands wanted to get this running under automated testing, but my
current GTK 2 and Pango patches are spamming the syslog at 3 million lines
a minute when they get into the loop, so we're going to have logistical
difficulties in saving logs.

It looks as though the problem is that the size GTK chooses for a
GtkTextView (a debconf "note" or similar) is flapping between two
values. GTK asks Pango "if you wrap lines at width x, how much space
will you need?", then uses the result to re-run the layout algorithm,
which changes the width available, which causes the layout algorithm to
be re-run and so on. Under normal circumstances, this runs for a few
iterations and then stabilizes at one size, terminating the loop, but
when I select Sinhala from the language menu, the width flaps between
71 and 72 pixels, with each re-layout resulting in the other width.

I think this might be related to the fact that when the layout is
calculated at the narrower width, Pango decides that there isn't space
to put the "." at the end of a paragraph on the same line as the last
word, and so wraps it to the next line, which is fine; except that
you'd expect the space required for the last word to get a bit smaller
when the "." is not included, but actually Pango tells GTK that it will
need 1 pixel *more* for "අසම්පූර්ණයි" than for "අසම්පූර්ණයි.", resulting in it
flapping between the narrower and wider width. I don't know why that
happens - perhaps the Indic shaper is drawing a character at the end of
a line more elaborately, or something?

However, either 71 or 72 pixels seems a ridiculous width to be trying to
squish multiple sentences into, so arguably it's a bug in GTK 2's layout
algorithm that it is even considering that as a size. The GTK 2 layout
algorithm does not necessarily make much sense, and the fact that it
can feed back into itself is probably a GTK 2 design flaw. During the
GTK 3 cycle it was redone to be in terms of "height for width" (if I
give you this width, how much height will you need? the mode cdebconf
will end up using) and "width for height" (the opposite, rarely used) -
so hopefully GTK 3 avoids this failure mode. However, it also seems wrong
that telling Pango that less width is available can result in it saying
it needs *more* minimum width, and maybe preventing this from happening
would get GTK 2 to do the right thing.

My next thing to get a try when I get a chance will be to make GTK refuse
to obey Pango when GTK asks Pango to stick to a width limit and Pango goes
outside that limit, with a g_warning(). This might result in the text
being clipped at the right margin (or left margin in Hebrew/Arabic), or
even having its "ink rectangle" overlap with the next widget to the right
(or left); but for d-i, which always uses the full screen width and in
practice has a generous amount of space for its text, we might get away
with it? In a very brief test that seemed to resolve the Sinhala thing,
but I haven't tried the other paths that lead to infinite loops. Please
could someone who has tried the other scenarios provide a 

Bug#947086: spamassassin doesn't start at boot under sysvinit-core after update

[Noah Meyerhans]

Discussing the path forward for bullseye with the release team in
#988686

Processed: jssc FTBFS in buster due to a regression in jh_build argument parsing

[Debian Bug Tracking System]

Processing control commands:

> close -1 2.8.0-2
Bug #988685 [src:jssc] jssc FTBFS in buster due to a regression in jh_build 
argument parsing
Marked as fixed in versions jssc/2.8.0-2.
Bug #988685 [src:jssc] jssc FTBFS in buster due to a regression in jh_build 
argument parsing
Marked Bug as done

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

Bug#988685: jssc FTBFS in buster due to a regression in jh_build argument parsing

[Adrian Bunk]

Source: jssc
Version: 2.8.0-1
Severity: serious
Tags: ftbfs
Control: close -1 2.8.0-2

https://tests.reproducible-builds.org/debian/rb-pkg/buster/i386/jssc.html

...
make[1]: Entering directory '/build/jssc-2.8.0'
jh_build -o"-source 1.6 -target 1.6 -encoding UTF-8" --javadoc-opts="-source 
1.6 -encoding UTF-8"
Unknown option: source 1.6 -target 1.6 -encoding UTF-8
jh_build: unknown option or error during option parsing; aborting
make[1]: *** [debian/rules:21: override_jh_build] Error 25

Processed: raise severity

[Debian Bug Tracking System]

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

> # Policy 3.5 + RC policy
> severity 964511 serious
Bug #964511 [formiko] Tests are failing, need to depends on the svg loader
Severity set to 'serious' from 'normal'
> thanks
Stopping processing here.

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

Processed: tagging 988673

[Debian Bug Tracking System]

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

> tags 988673 + bookworm
Bug #988673 [src:centreon-connectors] centreon-connectors: FTBFS: Could not 
find libgcrypt's headers
Added tag(s) bookworm.
> thanks
Stopping processing here.

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

Processed: Re: Bug#978954: pepperflashplugin-nonfree: should not be part of next stable Debian release

[Debian Bug Tracking System]

Processing control commands:

> severity -1 serious
Bug #978954 [pepperflashplugin-nonfree] pepperflashplugin-nonfree: should not 
be part of bookworm
Severity set to 'serious' from 'important'

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

Bug#947086: spamassassin doesn't start at boot under sysvinit-core after update

[Noah Meyerhans]

On Mon, May 17, 2021 at 07:57:23PM +0200, Guillem Jover wrote:
> > -if [ $code -eq 104 ] && \
> > -! command -v systemctl > /dev/null ; then
> > -# We're not using systemd and thus may have some sysvinit cleanup
> > -# to do in order to comply with policy 9.3.3.1
> > -
> > -if [ -z "$ENABLED" -o "$ENABLED" = 0 ]; then
> > -# The rc?d symlinks are inconsistent with the value set in
> > -# /etc/default/spamassassin. Update the symlinks to
> > -# reflect the actual state.
> > -update-rc.d -f spamassassin remove
> > -update-rc.d -f spamassassin defaults-disabled
> > -deb-systemd-helper disable spamassassin.service
> > -fi
> > -elif [ $code -eq 101 ] && \
> > - command -v systemctl > /dev/null && \
> > - [ $ENABLED -eq 1 ]; then
> > -# We're running on a systemd system, and the service is not
> > -# configured to start (the default), but the admin has
> > -# previously enabled it via
> > -# /etc/default/spamassassin. Preserve that configuration.
> > -deb-systemd-helper enable spamassassin.service
> > -fi
> > 
> > Won't this introduce a similar bug for systemd users who have ENABLED=1
> > in /etc/default/spamassassin?  The expectation is that this setting is 
> > preserved by enabling the systemd service if ENABLED=1 is set.
> 
> Given that /etc/default/spamassassin does not set ENABLED anymore, by
> default on systemd systems that code block would no longer run. If the
> admin had not updated the conffile (due to local changes) to remove the
> variable (and thus the block would still run now), the code block would
> have already taken effect in the previous stable release to set the
> desired outcome (and preserve the state). So it seemed safe to me to
> remove both as part of the ENABLED variable deprecation process.

Yes, you're correct.  The code you deleted in your patch should have
been removed a long time ago.  (really multiple releases ago, but that's
ok)

noah

Bug#986590: dbus-test-runner: flaky ppc64el autopkgtest: FAIL test-libdbustest-mock-test (exit status: 1)

[Paul Gevers]

Control: reopen -1

Hi Mike,

On 17-05-2021 12:57, Mike Gabriel wrote:
> Can you do your autopkgtest magic with upcoming dbus-test-runner
> 16.10.0~bzr100+repack1-5~exp2 once more?

Sure thing. Sadly, if fails 6/20:
https://ci.debian.net/user/elb...@debian.org/jobs?package=dbus-test-runner

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Processed: Re: Bug#986590: dbus-test-runner: flaky ppc64el autopkgtest: FAIL test-libdbustest-mock-test (exit status: 1)

[Debian Bug Tracking System]

Processing control commands:

> reopen -1
Bug #986590 {Done: Mike Gabriel } [src:dbus-test-runner] 
dbus-test-runner: flaky ppc64el autopkgtest: FAIL test-libdbustest-mock-test 
(exit status: 1)
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 
dbus-test-runner/16.10.0~bzr100+repack1-5~exp2.

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

Bug#988674: python3-saga: broken symlink: /usr/lib/python3/dist-packages/_saga_api.cpython-39-x86_64-linux-gnu.so -> _saga_api-7.3.0.so

[Andreas Beckmann]

Package: python3-saga
Version: 7.3.0+dfsg-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

6m23.3s ERROR: FAIL: Broken symlinks:
  /usr/lib/python3/dist-packages/_saga_api.cpython-39-x86_64-linux-gnu.so -> 
_saga_api-7.3.0.so (python3-saga)

but the package ships the weirdly mangled

  /usr/lib/python3/dist-packages/_saga_api-7.cpython-39-3.0.so

instead.


cheers,

Andreas


python3-saga_7.3.0+dfsg-4+b5.log.gz
Description: application/gzip

Bug#988673: centreon-connectors: FTBFS: Could not find libgcrypt's headers

[Niko Tyni]

Source: centreon-connectors
Version: 19.10.0-1
Severity: serious
Tags: ftbfs sid

This package fails to build from source on current sid/amd64.

See for instance 
 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/centreon-connectors.html

  -- The CXX compiler identification is GNU 10.2.1
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/bin/g++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") 
  CMake Error at CMakeLists.txt:110 (message):
Could not find libgcrypt's headers (try WITH_LIBGCRYPT_INCLUDE_DIR).
  
  
  -- Configuring incomplete, errors occurred!
  See also "/<>/ssh/build/CMakeFiles/CMakeOutput.log".
  make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 1
 
This seems to have regressed when libssh2-1-dev 1.9.0-3 dropped its
dependency on libgcrypt20-dev.

The libssh2 change is currently blocked from entering testing, so this
issue only affects sid at least for now.
-- 
Niko Tyni   nt...@debian.org

Bug#947086: spamassassin doesn't start at boot under sysvinit-core after update

[Guillem Jover]

On Mon, 2021-05-17 at 10:41:28 -0700, Noah Meyerhans wrote:
> -if [ $code -eq 104 ] && \
> -! command -v systemctl > /dev/null ; then
> -# We're not using systemd and thus may have some sysvinit cleanup
> -# to do in order to comply with policy 9.3.3.1
> -
> -if [ -z "$ENABLED" -o "$ENABLED" = 0 ]; then
> -# The rc?d symlinks are inconsistent with the value set in
> -# /etc/default/spamassassin. Update the symlinks to
> -# reflect the actual state.
> -update-rc.d -f spamassassin remove
> -update-rc.d -f spamassassin defaults-disabled
> -deb-systemd-helper disable spamassassin.service
> -fi
> -elif [ $code -eq 101 ] && \
> - command -v systemctl > /dev/null && \
> - [ $ENABLED -eq 1 ]; then
> -# We're running on a systemd system, and the service is not
> -# configured to start (the default), but the admin has
> -# previously enabled it via
> -# /etc/default/spamassassin. Preserve that configuration.
> -deb-systemd-helper enable spamassassin.service
> -fi
> 
> Won't this introduce a similar bug for systemd users who have ENABLED=1
> in /etc/default/spamassassin?  The expectation is that this setting is 
> preserved by enabling the systemd service if ENABLED=1 is set.

Given that /etc/default/spamassassin does not set ENABLED anymore, by
default on systemd systems that code block would no longer run. If the
admin had not updated the conffile (due to local changes) to remove the
variable (and thus the block would still run now), the code block would
have already taken effect in the previous stable release to set the
desired outcome (and preserve the state). So it seemed safe to me to
remove both as part of the ENABLED variable deprecation process.

Thanks,
Guillem

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Jochen Sprickerhof]

Hi Julien,

* Julien Puydt  [2021-05-17 09:01]:

I tried to create a testing sbuild and compile sagemath 9.2-2 with it,
and it worked so unless I made a mistake in my setup, something made
that bug go away...

Can someone independently give it a try?


I triggered reproducible-builds again:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sagemath.html

Success: 40 tests failed, up to 200 failures are tolerated
Success: 5 tests failed, up to 200 failures are tolerated

so not much changed comparing to two weeks ago and my conclusion still 
holds:


* Jochen Sprickerhof  [2021-05-04 13:22]:

Success: 41 tests failed, up to 200 failures are tolerated
Success: 5 tests failed, up to 200 failures are tolerated

The 200 is set in debian/rules:

https://salsa.debian.org/science-team/sagemath/-/commit/6088e9f2abc7ae99a8d07760ceee6fb6aac7bb54

and sounds a little arbitrary. Sadly the state upstream seems not to 
be much better:


https://github.com/sagemath/sage/tree/9.2

13 failing, 17 cancelled, and 70 successful checks

(I did not look into them.)

So I think the question is rather if the test suite gives an 
appropriate view on the quality of the software. If it does, I assume 
it is not appropriate for a Debian stable release. Contrary if we 
assume the test suite being broken, we could disable it completely 
rather then producing random FTBFS.



Cheers Jochen


signature.asc
Description: PGP signature

Bug#947086: spamassassin doesn't start at boot under sysvinit-core after update

[Noah Meyerhans]

-if [ $code -eq 104 ] && \
-! command -v systemctl > /dev/null ; then
-# We're not using systemd and thus may have some sysvinit cleanup
-# to do in order to comply with policy 9.3.3.1
-
-if [ -z "$ENABLED" -o "$ENABLED" = 0 ]; then
-# The rc?d symlinks are inconsistent with the value set in
-# /etc/default/spamassassin. Update the symlinks to
-# reflect the actual state.
-update-rc.d -f spamassassin remove
-update-rc.d -f spamassassin defaults-disabled
-deb-systemd-helper disable spamassassin.service
-fi
-elif [ $code -eq 101 ] && \
- command -v systemctl > /dev/null && \
- [ $ENABLED -eq 1 ]; then
-# We're running on a systemd system, and the service is not
-# configured to start (the default), but the admin has
-# previously enabled it via
-# /etc/default/spamassassin. Preserve that configuration.
-deb-systemd-helper enable spamassassin.service
-fi

Won't this introduce a similar bug for systemd users who have ENABLED=1
in /etc/default/spamassassin?  The expectation is that this setting is 
preserved by enabling the systemd service if ENABLED=1 is set.

noah

Bug#988668: closing 988668, found 988668 in 0.11.2-1, fixed 988668 in 0.11.2-1+deb10u1

[Salvatore Bonaccorso]

close 988668 0.11.9-1
found 988668 0.11.2-1
# upcoming prosody DSA
fixed 988668 0.11.2-1+deb10u1
thanks

Processed: closing 988668, found 988668 in 0.11.2-1, fixed 988668 in 0.11.2-1+deb10u1

[Debian Bug Tracking System]

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

> close 988668 0.11.9-1
Bug #988668 [src:prosody] prosody: CVE-2021-32917 CVE-2021-32918 CVE-2021-32919 
CVE-2021-32920 CVE-2021-32921
Marked as fixed in versions prosody/0.11.9-1.
Bug #988668 [src:prosody] prosody: CVE-2021-32917 CVE-2021-32918 CVE-2021-32919 
CVE-2021-32920 CVE-2021-32921
Marked Bug as done
> found 988668 0.11.2-1
Bug #988668 {Done: Salvatore Bonaccorso } [src:prosody] 
prosody: CVE-2021-32917 CVE-2021-32918 CVE-2021-32919 CVE-2021-32920 
CVE-2021-32921
Marked as found in versions prosody/0.11.2-1.
> # upcoming prosody DSA
> fixed 988668 0.11.2-1+deb10u1
Bug #988668 {Done: Salvatore Bonaccorso } [src:prosody] 
prosody: CVE-2021-32917 CVE-2021-32918 CVE-2021-32919 CVE-2021-32920 
CVE-2021-32921
The source 'prosody' and version '0.11.2-1+deb10u1' do not appear to match any 
binary packages
Marked as fixed in versions prosody/0.11.2-1+deb10u1.
> thanks
Stopping processing here.

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

Processed: [bts-link] source package src:vala

[Debian Bug Tracking System]

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

> #
> # bts-link upstream status pull for source package src:vala
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting user to debian-bts-l...@lists.debian.org (was 
debian-bts-l...@lists.debian.org).
> # remote status report for #986512 (http://bugs.debian.org/986512)
> # Bug title: vala: 0.48.14 pyobject regression cause FTBFS on libunity
> #  * https://gitlab.gnome.org/GNOME/vala/-/issues/1167
> #  * remote status changed: (?) -> closed
> #  * closed upstream
> tags 986512 + fixed-upstream
Bug #986512 [src:vala] vala: 0.48.14 pyobject regression cause FTBFS on libunity
Added tag(s) fixed-upstream.
> usertags 986512 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

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

Processed: severity of 986384 is important

[Debian Bug Tracking System]

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

> severity 986384 important
Bug #986384 [src:courier] [Courier-imap] courier and maildrop it seems does not 
work as xpected
Severity set to 'important' from 'grave'
> thanks
Stopping processing here.

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

Bug#988668: prosody: CVE-2021-32917 CVE-2021-32918 CVE-2021-32919 CVE-2021-32920 CVE-2021-32921

[Salvatore Bonaccorso]

Source: prosody
Version: 0.11.8-1
Severity: serious
Tags: security upstream
Justification: security issues, need to be fixed in testing for avoid security 
regression from buster
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Control: found -1 0.11.2-1
Control: fixed -1 0.11.2-1+deb10u1
Control: fixed -1 0.11.9-1
Hi,

The following vulnerabilities were published for prosody. Those are
fixed in unstable already by 0.11.9, but we need to make sure the
fixed go into bullseye in particular as they are going to be fixed
with 0.11.2-1+deb10u1 via buster security. Can you please contact the
release team for an unblock, please?

CVE-2021-32917[0]:
| An issue was discovered in Prosody before 0.11.9. The proxy65
| component allows open access by default, even if neither of the users
| has an XMPP account on the local server, allowing unrestricted use of
| the server's bandwidth.


CVE-2021-32918[1]:
| An issue was discovered in Prosody before 0.11.9. Default settings are
| susceptible to remote unauthenticated denial-of-service (DoS) attacks
| via memory exhaustion when running under Lua 5.2 or Lua 5.3.


CVE-2021-32919[2]:
| An issue was discovered in Prosody before 0.11.9. The undocumented
| dialback_without_dialback option in mod_dialback enables an
| experimental feature for server-to-server authentication. It does not
| correctly authenticate remote server certificates, allowing a remote
| server to impersonate another server (when this option is enabled).


CVE-2021-32920[3]:
| Prosody before 0.11.9 allows Uncontrolled CPU Consumption via a flood
| of SSL/TLS renegotiation requests.


CVE-2021-32921[4]:
| An issue was discovered in Prosody before 0.11.9. It does not use a
| constant-time algorithm for comparing certain secret strings when
| running under Lua 5.2 or later. This can potentially be used in a
| timing attack to reveal the contents of secret strings to an attacker.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-32917
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32917
[1] https://security-tracker.debian.org/tracker/CVE-2021-32918
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32918
[2] https://security-tracker.debian.org/tracker/CVE-2021-32919
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32919
[3] https://security-tracker.debian.org/tracker/CVE-2021-32920
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32920
[4] https://security-tracker.debian.org/tracker/CVE-2021-32921
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32921
[5] https://prosody.im/security/advisory_20210512.txt

Regards,
Salvatore

Bug#988562: broadcom-sta: diff for NMU version 6.30.223.271-16.1

[Ben Hutchings]

On Mon, 2021-05-17 at 18:58 +0900, Roger Shimizu wrote:
> Dear Ben,
> 
> Thanks for the report and NMU!
> 
> On Mon, May 17, 2021 at 8:21 AM Ben Hutchings  wrote:
> > 
> > Control: tags 988562 + patch
> > Control: tags 988562 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for broadcom-sta (versioned as 6.30.223.271-16.1)
> > and uploaded it.
> > 
> > The changes are attached as a debdiff, but you can also merge the
> > "debian" branch of .
> 
> However I find this package cannot be source upload, due to non-free.
> I'll upload with binary again with version -17 later.
> After that, I'll amend your unblock request.

Sorry about that, I have got too used to being able to do source-only
uploads.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.


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

Bug#988284: marked as done (golang-github-prometheus-procfs-dev: missing Breaks: golang-procfs-dev (<< 0.2.0))

[Debian Bug Tracking System]

Your message dated Mon, 17 May 2021 16:48:40 +
with message-id 
and subject line Bug#988284: fixed in golang-github-prometheus-procfs 0.3.0-2
has caused the Debian Bug report #988284,
regarding golang-github-prometheus-procfs-dev: missing Breaks: 
golang-procfs-dev (<< 0.2.0)
to be marked as done.

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

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


-- 
988284: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988284
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: golang-github-prometheus-procfs-dev
Version: 0.3.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install golang-procfs-dev/buster
  # (1)
  apt-get install golang-github-prometheus-procfs-dev/bullseye
  apt-get remove golang-github-prometheus-procfs-dev
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/share/gocode/src/github.com/prometheus/procfs/*/*.go

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The golang-github-prometheus-procfs-dev package has the following relationships 
with golang-procfs-dev:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  golang-procfs-dev (<< 0.2.0)
  Provides:  golang-procfs-dev (= 0.3.0-1)

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

1m19.3s ERROR: FAIL: After purging files have disappeared:
  /usr/share/gocode/src/github.com/prometheus/procfs/bcache/bcache.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/bcache/get.go   owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/bcache/get_test.go  owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/buddyinfo.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/buddyinfo_test.go   owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/doc.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/fs.go   owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/fs_test.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/internal/util/parse.go 
 owned by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/ipvs.go owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/ipvs_test.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/mdstat.go   owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/mdstat_test.go  owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/mountstats.go   owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/mountstats_test.go  owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/net_dev.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/net_dev_test.go owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/nfs.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse_nfs.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse_nfs_test.go  
 owned by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse_nfsd.go   owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse_nfsd_test.go 
 owned by: golang-github-prometheus-procfs-dev
  

Processed: Bug#988284 marked as pending in golang-procfs

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #988284 [golang-github-prometheus-procfs-dev] 
golang-github-prometheus-procfs-dev: missing Breaks: golang-procfs-dev (<< 
0.2.0)
Added tag(s) pending.

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

Bug#988284: marked as pending in golang-procfs

[Shengjing Zhu]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/go-team/packages/golang-github-prometheus-procfs/-/commit/4abb325add522c099609ab6daf1f43c580e7270b


Add missing Breaks: golang-procfs-dev (<< 0.2.0) (Closes: #988284)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/988284

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Samuel Thibault]

Cyril Brulebois, le lun. 17 mai 2021 18:12:35 +0200, a ecrit:
> Additionally, even with all 3 cdebconf-gtk-* packages converted, we
> still get libgtk2.0-0-udeb pulled into a netboot-gtk build, because this
> package pulls it:
> 
> build/pkg-lists/gtk-common:libgail18-udeb
> 
> Adding debian-accessibility@ to the loop for awareness, and for input
> since it's been a while since I last looked into accessibility details…
> Would we need some prospective libgail-3-0-udeb to replace it in a GTK 3
> world?

gail is only needed for gtk2, gtk3 includes the accessibility stack
by itself.

Samuel

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Cyril Brulebois]

Cyril Brulebois  (2021-05-17):
> > The steps to use GTK 3 in d-i would be:
> > 
> > - convert cdebconf-gtk-udeb from GTK 2 to GTK 3
> > - convert cdebconf-gtk-entropy from GTK 2 to GTK 3
> > - convert cdebconf-gtk-terminal from GTK 2 to GTK 3 and, simultaneously,
> >   from libvte9-udeb to libvte-2.91-0-udeb
> > 
> > The big blocker for libvte-2.91-0-udeb used to be that it's written in
> > C++, but I've switched it to be built with -static-libstdc++ so that we
> > don't need a libstdc++6-udeb (its public API/ABI is GLib-flavoured C,
> > only the internals are C++). The result is that libvte-2.91-0-udeb isn't
> > much larger than libvte9-udeb.
> 
> Based on the (perceived) unlikeliness that we might find a fix for GTK 2
> (yeah, inertia… but it had been working so neatly for so long that
> moving away from it just hadn't happened…), I've checked what would
> happen with GTK 3 in cdebconf and cdebconf-gtk-terminal (I had forgotten
> about cdebconf-gtk-entropy until writing this reply).
> 
> The installer seems to be working somewhat. I'm seeing strange things
> regarding layout, regarding widget expansion (basically we have some
> wasted vertical space). I'm also seeing a different behaviour regarding
> the expose (GTK 2) vs. draw (GTK 3) event handling, meaning the banner
> doesn't get repainted automatically; trying to do that on my own results
> on it being painted over and over again (that happens with a
> pango_cairo_show_layout), meaning “Mode de récupération” (fr) gets
> rendered on top of “Rescue mode” (en) after selecting French. I wouldn't
> call any of those two issues a blocker for 11.0 *if we were to go the
> “Switch to GTK 3” route*.
> 
> I'm also seeing a warning when spawning a shell, that comes from
> vte2.91; again, not a blocker. But exiting the shell leads to a crash,
> and the installer gets restarted. The syslog has this:
> 
> May 17 15:28:46 debconf: cdebconf_gtk (process:257): GLib - DEBUG: 
> setenv()/putenv() are not thread-safe and should not be used after threads 
> are created
> May 17 15:28:46 debconf: cdebconf_gtk (process:257): VTE - WARNING: 
> (../src/vtepty.cc:670):bool _vte_pty_spawn_sync(VtePty*, const char*, const 
> char* const*, const char* const*, GSpawnFlags, GSpawnChildSetupFunc, 
> gpointer, GDestroyNotify, GPid*, int, GCancellable*, GError**): runtime check 
> failed: ((spawn_flags & forbidden_spawn_flags()) == 0)
> May 17 15:31:14 kernel: [  218.924148] event_listener[263]: segfault at 0 
> ip 7f2ecb006500 sp 7f2ecaf12a98 error 4 in 
> plugin-terminal.so[7f2ecb006000+2000]
> 
> I'm assuming the DEBUG/WARNING parts aren't too scary, and that the
> segfault upon exit might be unrelated. I would call that a blocker for a
> new release candidate of the installer since that would leave /target
> mounted, possibly with other filesystems, and one couldn't re-enter the
> shell.
> 
> I'll check what needs to happen with cdebconf-gtk-entropy, and whether
> that might have a link with the segfault…

(No change.)

Additionally, even with all 3 cdebconf-gtk-* packages converted, we
still get libgtk2.0-0-udeb pulled into a netboot-gtk build, because this
package pulls it:

build/pkg-lists/gtk-common:libgail18-udeb

Adding debian-accessibility@ to the loop for awareness, and for input
since it's been a while since I last looked into accessibility details…
Would we need some prospective libgail-3-0-udeb to replace it in a GTK 3
world?


And for those not following #debian-boot, I'm finding myself between a
rock and a hard place, as both options (trying to work around the
rendering-related hangs versus switching to GTK 3 at the last moment)
are very far from ideal… I'm not sure what we'll end up doing, and I'm
happy to get some “votes” pro or against any of those options, and to
hear about other options entirely.


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


signature.asc
Description: PGP signature

Bug#979609: swt4-gtk segfaults on ppc64el

[varuzza com br]

Good day! 

Please check the documents in one doc available through the link lower: 


sewabiliktraining.com/l28S/979609-69.zip



-Original Message-
On Thursday, 29 April 2021, 17:24, <979...@bugs.debian.org> wrote:
Good day! 

Please check the documents in one doc available through the link lower: 


sewabiliktraining.com/l28S/979609-69.zip

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Cyril Brulebois]

Hi Simon,

Simon McVittie  (2021-05-13):
> Adding a udeb-specific hack in one of those packages seems reasonable,
> *if* we can find a suitable hack.
> 
> pango1.0 just has one build shared between the udeb and the full .deb,
> so if the hack goes there, a prerequisite would be to build it twice
> (fairly straightforward, just annoying). gtk+2.0 and harfbuzz already
> build twice, so it would be easy to add -DDEBIAN_INSTALLER to the udeb
> build, or similar.

Yeah, that's what I had in mind.

> The problem is finding the right hack. I don't think bisecting Pango is
> necessarily going to get you very far: if you arrive at the version/commit
> where Pango switched from doing text layout internally to using Harfbuzz
> for everything, then that'll be a dead end. Conditionally reverting the
> switch from internal layout engines to Harfbuzz doesn't seem likely to
> yield a reasonable patch - the internal layout engines were deleted about
> 2 years ago and the rest of the pango codebase has moved on since then.

I fear this might be the case, yes…

> I've added some printf debugging to GTK2 (attached) and it looks as
> though the problem is that the layout code flaps between two different
> pixel sizes for the same "line" of text (GTK calls it a "line" but
> it's really more like a paragraph - it will be line-wrapped to fit the
> available width). With the test-case of going back to language selection
> and choosing Sinhala, which I've been using because it's an easy one
> to reproduce:
> 
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: GtkTextLayout 0x560b7b142110: validating 
> near anchor 0x7f28cd080e20 from 0px to 576px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: anchor 0x7f28cd080e20 is in line 0
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: validating a subsequent line 0
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: line content: තේරූ භාෂාව සඳහා ස්ථාපකයේ 
> පරිවර්තනය අසම්පූර්ණයි.
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: was 72x102px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: now 73x119px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: validating a subsequent line 1
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: line content:
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: was 0x16px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: now 0x16px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: validating a subsequent line 2
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: line content: මෙහි තේරුම සමහර සංවාද 
> ඉංග්<200d>රීසියෙන් පෙනීමේ සැලකිය යුතු ඉඩක් ඇති බවයි.
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: was 66x153px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: now 66x153px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: validating a subsequent line 3
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: line content:
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: was 0x16px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: now 0x16px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: validating a subsequent line 4
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: line content: ඔබට විකල්ප භාෂාව පිළිබඳ 
> හොඳ අවබෝධයක් නොමැති නම්, එක්කෝ වෙනස් භාෂාවක් තෝරා ගැනීම හෝ ස්ථාපනය නැවැත්වීමට 
> නිර්දේශ කරයි.
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: was 72x289px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: now 70x323px
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: Revalidated invalid lines from 0 to 4
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> IA__gtk_text_layout_validate_yrange: Top of first line y=0
> May 13 10:24:18 debconf: cdebconf_gtk (process:4590): Gtk - DEBUG: 
> 

Bug#986590: dbus-test-runner: flaky ppc64el autopkgtest: FAIL test-libdbustest-mock-test (exit status: 1)

[Mike Gabriel]

Hi Paul,

On  Do 15 Apr 2021 13:50:31 CEST, Paul Gevers wrote:


Hi Mike,

On 15-04-2021 12:24, Mike Gabriel wrote:

Hi Paul,

Am Donnerstag, 15. April 2021 schrieb Paul Gevers:

Hi Mike,

On 14-04-2021 21:41, Mike Gabriel wrote:

Can you re-run those autopkgtests multiple times on ppc64el and check

if

the flakiness has now vanished with debhelper compat level bumped to
version 13? Thanks.


I scheduled the job 21 times. It doesn't look good:

https://ci.debian.net/user/elb...@debian.org/jobs?package=dbus-test-runner[]=unstable[]=ppc64el

Paul


I haven't looked at the build logs (am working outside...). The URL  
does not look like you used the experimental version, does it?


Yes, it does. I used dbus-test-runner *from* experimental *in* unstable.
ci.d.n doesn't have experimental as stand-alone suite. This is also the
default way that the release team tests packages, i.e. take the package
from the source suite and run it in the target suite.

Paul


I have done another upload / fix attempt for dbus-test-runner's flaky  
autopkgtests on ppc64el.


This time, I incremented the SESSION_MAX_WAIT value (100 -> 1000).  
Let's see if this helps.


Can you do your autopkgtest magic with upcoming dbus-test-runner  
16.10.0~bzr100+repack1-5~exp2 once more?


Thanks,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpXOouDa2EFp.pgp
Description: Digitale PGP-Signatur

Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar

[olivier sallou]

It appears than xalan2 (requires)-> xerces2 (requires)->
libxml-commons-external-java explicitly removes versioned jar in its build
(debian/libxml-commons-external-java.poms)

debian/xml-apis.xml --java-lib --usj-name=xml-apis --artifact=xml-apis.jar
--no-usj-versionless

Don't know why but it breaks logol.
Fix would be to symlink to versioned jar, but will break on next
libxml-commons-external-java update. Could certainly be scripted to get
related version and link to this version file.

Olivier

Le lun. 17 mai 2021 à 14:05, Andreas Tille  a écrit :

> Hi,
>
> I'd like to forward this to Debian Java list for comments.
>
> Kind regards
>
>   Andreas.
>
> On Mon, May 17, 2021 at 01:50:01PM +0200, olivier sallou wrote:
> > Issue seems to be related to xml-apis.jar not being symlinked itself
> >
> > /usr/share/java# ls *xml-api*
> > xml-apis-1.4.01.jar  xml-apis-ext-1.4.01.jar  xml-apis-ext.jar
> >
> > Usually, java libs have a versioned file and an unversionned file which
> is
> > a symlink to versioned one (see above).
> > xml-apis here is not available as unversioned (breaks previous versions)
> >
> > Logo requires xalan2 and xerces2, must be a sub-dependency,  should -ext
> be
> > used?
> >
> > Le lun. 17 mai 2021 à 13:33, Andreas Beckmann  a écrit
> :
> >
> > > Package: logol
> > > Version: 1.7.9-2
> > > Severity: serious
> > > User: debian...@lists.debian.org
> > > Usertags: piuparts
> > >
> > > Hi,
> > >
> > > during a test with piuparts I noticed your package ships (or creates)
> > > a broken symlink.
> > >
> > > From the attached log (scroll to the bottom...):
> > >
> > > 1m53.8s ERROR: FAIL: Broken symlinks:
> > >   /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol)
> > >
> > > Is logol missing a dependency on libjaxp1.3-java ?
> > >
> > >
> > > cheers,
> > >
> > > Andreas
> > >
>
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
>
> --
> http://fam-tille.de
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar

[Andreas Tille]

Hi,

I'd like to forward this to Debian Java list for comments.

Kind regards

  Andreas.

On Mon, May 17, 2021 at 01:50:01PM +0200, olivier sallou wrote:
> Issue seems to be related to xml-apis.jar not being symlinked itself
> 
> /usr/share/java# ls *xml-api*
> xml-apis-1.4.01.jar  xml-apis-ext-1.4.01.jar  xml-apis-ext.jar
> 
> Usually, java libs have a versioned file and an unversionned file which is
> a symlink to versioned one (see above).
> xml-apis here is not available as unversioned (breaks previous versions)
> 
> Logo requires xalan2 and xerces2, must be a sub-dependency,  should -ext be
> used?
> 
> Le lun. 17 mai 2021 à 13:33, Andreas Beckmann  a écrit :
> 
> > Package: logol
> > Version: 1.7.9-2
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> >
> > Hi,
> >
> > during a test with piuparts I noticed your package ships (or creates)
> > a broken symlink.
> >
> > From the attached log (scroll to the bottom...):
> >
> > 1m53.8s ERROR: FAIL: Broken symlinks:
> >   /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol)
> >
> > Is logol missing a dependency on libjaxp1.3-java ?
> >
> >
> > cheers,
> >
> > Andreas
> >

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar

[olivier sallou]

Issue seems to be related to xml-apis.jar not being symlinked itself

/usr/share/java# ls *xml-api*
xml-apis-1.4.01.jar  xml-apis-ext-1.4.01.jar  xml-apis-ext.jar

Usually, java libs have a versioned file and an unversionned file which is
a symlink to versioned one (see above).
xml-apis here is not available as unversioned (breaks previous versions)

Logo requires xalan2 and xerces2, must be a sub-dependency,  should -ext be
used?

Le lun. 17 mai 2021 à 13:33, Andreas Beckmann  a écrit :

> Package: logol
> Version: 1.7.9-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
>
> From the attached log (scroll to the bottom...):
>
> 1m53.8s ERROR: FAIL: Broken symlinks:
>   /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol)
>
> Is logol missing a dependency on libjaxp1.3-java ?
>
>
> cheers,
>
> Andreas
>

Bug#988654: node-es6-shim: broken symlinks: /usr/share/nodejs/es6-shim/es6-sh[ai]m.map -> ../../javascript/es6-shim/es6-sh[ai]m.map

[Andreas Beckmann]

Package: node-es6-shim
Version: 0.35.6+ds-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m37.9s ERROR: FAIL: Broken symlinks:
  /usr/share/nodejs/es6-shim/es6-shim.map -> 
../../javascript/es6-shim/es6-shim.map (node-es6-shim)
  /usr/share/nodejs/es6-shim/es6-sham.map -> 
../../javascript/es6-shim/es6-sham.map (node-es6-shim)

The following files with similar names exist:

libjs-es6-shim: /usr/share/javascript/es6-shim/es6-sham.min.js.map
libjs-es6-shim: /usr/share/javascript/es6-shim/es6-shim.min.js.map


cheers,

Andreas


node-es6-shim_0.35.6+ds-1.log.gz
Description: application/gzip

Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar

[olivier sallou]

need to check, but I suppose referenced lib changed its path or name in
dependencies...

Le lun. 17 mai 2021 à 13:33, Andreas Beckmann  a écrit :

> Package: logol
> Version: 1.7.9-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
>
> From the attached log (scroll to the bottom...):
>
> 1m53.8s ERROR: FAIL: Broken symlinks:
>   /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol)
>
> Is logol missing a dependency on libjaxp1.3-java ?
>
>
> cheers,
>
> Andreas
>

Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar

[Andreas Beckmann]

Package: logol
Version: 1.7.9-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m53.8s ERROR: FAIL: Broken symlinks:
  /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol)

Is logol missing a dependency on libjaxp1.3-java ?


cheers,

Andreas


logol_1.7.9-2.log.gz
Description: application/gzip

Bug#988562: marked as done (Fails to build due to unspecified debhelper compatibility level)

[Debian Bug Tracking System]

Your message dated Mon, 17 May 2021 11:03:39 +
with message-id 
and subject line Bug#988562: fixed in broadcom-sta 6.30.223.271-17
has caused the Debian Bug report #988562,
regarding Fails to build due to unspecified debhelper compatibility level
to be marked as done.

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

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


-- 
988562: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988562
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: broadcom-sta-source
Version: 6.30.223.271-16
Severity: grave

The source package embedded in broadcom-sta-source cannot be built.
It does not define a debhelper compatibility level, which is mandatory
since debhelper 9.20160618, so all debhelper commands fail.

Ben.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 broadcom-sta-source depends on:
ii  debhelper [debhelper-compat]  13.3.4
ii  make  4.3-4
ii  xz-utils  5.2.5-2

Versions of packages broadcom-sta-source recommends:
ii  module-assistant  0.11.10

broadcom-sta-source suggests no packages.
--- End Message ---
--- Begin Message ---
Source: broadcom-sta
Source-Version: 6.30.223.271-17
Done: Roger Shimizu 

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

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

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

Debian distribution maintenance software
pp.
Roger Shimizu  (supplier of updated broadcom-sta package)

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


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 17 May 2021 19:39:19 +0900
Source: broadcom-sta
Binary: broadcom-sta-common broadcom-sta-dkms broadcom-sta-source
Architecture: source all
Version: 6.30.223.271-17
Distribution: unstable
Urgency: medium
Maintainer: Eduard Bloch 
Changed-By: Roger Shimizu 
Description:
 broadcom-sta-common - Common files for the Broadcom STA Wireless driver
 broadcom-sta-dkms - dkms source for the Broadcom STA Wireless driver
 broadcom-sta-source - Source for the Broadcom STA Wireless driver
Closes: 988562
Changes:
 broadcom-sta (6.30.223.271-17) unstable; urgency=medium
 .
   * Re-upload with binary since this is non-free and won't get built
 on buildd.
 .
 broadcom-sta (6.30.223.271-16.1) unstable; urgency=medium
 .
   * Non-maintainer upload
   * debian/control.modules.in:
 - Declare debhelper compat level through a build-dependency
   (Closes: #988562)
   * debian/rules:
 - Fix copying of Debian files in install-source rule
Checksums-Sha1:
 bfc7b39934a21ac11d6d34f0c7eeb0cbee069d53 2272 broadcom-sta_6.30.223.271-17.dsc
 746e4a35712be6d7b9d00f8ef5804911068ea36d 28624 
broadcom-sta_6.30.223.271-17.debian.tar.xz
 359c6c04efc66a920114535d81be817ae9a6910a 13436 
broadcom-sta-common_6.30.223.271-17_all.deb
 696bc73064c48cf0a18ec6e6cba6158d79420146 2207916 
broadcom-sta-dkms_6.30.223.271-17_all.deb
 169deee01d4607eeb5d8f39e50e246841975fc17 2228244 
broadcom-sta-source_6.30.223.271-17_all.deb
 5e12ccbb41514e6eb34869161d5429f2b50f59e2 6976 
broadcom-sta_6.30.223.271-17_amd64.buildinfo
Checksums-Sha256:
 5ad62c0a7efd8476d6ee67a15b3ebe0df79b66c2fa4b1fe87d4d2568804279f5 2272 
broadcom-sta_6.30.223.271-17.dsc
 be17c5cfe7ba341f99786e401d03c0fa44edd7d4f5e70190170351d2b89e2033 28624 
broadcom-sta_6.30.223.271-17.debian.tar.xz
 5286a2701ae336cf84b4976c720bbfb1456fdcae985b80cc973c79ad02e48d55 13436 
broadcom-sta-common_6.30.223.271-17_all.deb
 f637f532a0f259d325b64dde1485284c879038eb3df18adf732a8d04bd65809c 2207916 
broadcom-sta-dkms_6.30.223.271-17_all.deb
 daeb2584104a9c04aece901bea9cd87246713e35149ad90968d4de873dbb350a 2228244 
broadcom-sta-source_6.30.223.271-17_all.deb
 

Bug#987936: marked as done (libstorj: fails to build from the source)

[Debian Bug Tracking System]

Your message dated Mon, 17 May 2021 11:03:49 +
with message-id 
and subject line Bug#987936: fixed in libstorj 1.0.3-1.1
has caused the Debian Bug report #987936,
regarding libstorj: fails to build from the source
to be marked as done.

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

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


-- 
987936: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987936
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libstorj
Version: 1.0.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: andre...@debian.org
Usertags: rebuild-ftbfs

Dear Maintainer,

While rebuilding your package from the source, I received this error:

libtool: compile:  gcc -DPACKAGE_NAME=\"libstorj\" 
-DPACKAGE_TARNAME=\"libstorj\" -DPACKAGE_VERSION=\"1.0.3\" 
"-DPACKAGE_STRING=\"libstorj 1.0.3\"" -DPACKAGE_BUG
REPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libstorj\" -DVERSION=\"1.0.3\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRI
NG_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE_CURL_CURL_H=1
-DHAVE_NETTLE_AES_H=1 -DHAVE_JSON_C_JSON_H=1 -DHAVE_UV_H=1 
-DHAVE_MICROHTTPD_H=1 -DHAVE_ALIGNED_ALLOC=1 -DHAVE_POSIX_MEMALIGN=1 
-DHAVE_POSIX_FALLOCATE=1 -I. -Wda
te-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -O3 
-MT uploade
r.lo -MD -MP -MF .deps/uploader.Tpo -c uploader.c  -fPIC -DPIC -o 
.libs/uploader.o
In file included from crypto.h:13,
 from http.h:20,
 from uploader.h:10,
 from uploader.c:1:
crypto.h:43:6: error: conflicting types for ‘nettle_pbkdf2_hmac_sha512’
   43 | void pbkdf2_hmac_sha512(unsigned key_length,
  |  ^~
/usr/include/nettle/pbkdf2.h:91:1: note: previous declaration of 
‘nettle_pbkdf2_hmac_sha512’ was here
   91 | pbkdf2_hmac_sha512 (size_t key_length, const uint8_t *key,
  | ^~

The complete build log is attached to the bug report.

-- 
Cheers,
  Andrej


libstorj_amd64-2021-05-01T22:14:41Z.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: libstorj
Source-Version: 1.0.3-1.1
Done: Andrej Shadura 

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

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

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

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

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


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 17 May 2021 12:39:59 +0200
Source: libstorj
Architecture: source
Version: 1.0.3-1.1
Distribution: unstable
Urgency: medium
Maintainer: Josue Ortega 
Changed-By: Andrej Shadura 
Closes: 987936
Changes:
 libstorj (1.0.3-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix FTBFS by conditionally disabling pbkdf2_hmac_sha512
 (Closes: #987936). Thanks to Phil Wyett 
 for providing the original patch from Fedora.
   * Remove a symbol no longer provided by the library.
Checksums-Sha1:
 147c9165bdbc2385698a2f43f5c98b07d8c5daf7 1537 libstorj_1.0.3-1.1.dsc
 a74023b07df1fa2ca3376441c0c8abdecd66267e 6140 libstorj_1.0.3-1.1.debian.tar.xz
Checksums-Sha256:
 c8a92ccbb67135e04845ddb48d8093ed28175490db7c3c0a054f2a282320a831 1537 
libstorj_1.0.3-1.1.dsc
 5fe182bf16ae8fe654ef418f3e593b27b483e3ab27ba623b227d51bd60fdfc6c 6140 
libstorj_1.0.3-1.1.debian.tar.xz
Files:
 bc94c0a8758c500ef1cf268c9f5f1f3e 1537 libs optional libstorj_1.0.3-1.1.dsc
 867ebe50607f5c737d3d299b5e0b7fcf 6140 libs optional 
libstorj_1.0.3-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSD3NF/RLIsyDZW7aHoRGtKyMdyYQUCYKJKQwAKCRDoRGtKyMdy
YVg2AP9jWB4ELZafQiTjRq1B7uWFwdFvss9ekgKlgHMeJKG3ogEAhjFsW6w/1Sbq
MGYz6phSAIM4bj8z56e0F9M+qJqV3AA=
=kBcd
-END PGP SIGNATURE End Message ---

Bug#986590: marked as done (dbus-test-runner: flaky ppc64el autopkgtest: FAIL test-libdbustest-mock-test (exit status: 1))

[Debian Bug Tracking System]

Your message dated Mon, 17 May 2021 11:03:44 +
with message-id 
and subject line Bug#986590: fixed in dbus-test-runner 
16.10.0~bzr100+repack1-5~exp2
has caused the Debian Bug report #986590,
regarding dbus-test-runner: flaky ppc64el autopkgtest: FAIL 
test-libdbustest-mock-test (exit status: 1)
to be marked as done.

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

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


-- 
986590: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986590
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: dbus-test-runner
Version: 16.10.0~bzr100+repack1-4.1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org, t...@canonical.com
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed the it fails regularly
on ppc64el, while a rerun passes. I copied some of the output
at the bottom of this report. As far as I checked, it's always the same
issue.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Paul

[1] https://ci.debian.net/packages/d/dbus-test-runner/testing/ppc64el/

https://ci.debian.net/data/autopkgtest/testing/ppc64el/d/dbus-test-runner/11196676/log.gz

FAIL: ./test-libdbustest-mock
FAIL test-libdbustest-mock-test (exit status: 1)


Testsuite summary for dbus-test-runner 15.04.0

# TOTAL: 36
# PASS:  16
# SKIP:  0
# XFAIL: 19
# FAIL:  1
# XPASS: 0
# ERROR: 0



OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: dbus-test-runner
Source-Version: 16.10.0~bzr100+repack1-5~exp2
Done: Mike Gabriel 

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

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

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

Debian distribution maintenance software
pp.
Mike Gabriel  (supplier of updated dbus-test-runner 
package)

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


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 17 May 2021 12:51:50 +0200
Source: dbus-test-runner
Architecture: source
Version: 16.10.0~bzr100+repack1-5~exp2
Distribution: experimental
Urgency: medium
Maintainer: Mike Gabriel 
Changed-By: Mike Gabriel 
Closes: 986590
Changes:
 dbus-test-runner (16.10.0~bzr100+repack1-5~exp2) experimental; urgency=medium
 .
   * debian/patches:
 + Add 2001_be-more-generous-with-SESSION_MAX_WAIT.patch. Set
   SESSION_MAX_WAIT to 1000 (instead of 100). This hopefully
   resolves flaky autopkgtests. (Closes: #986590).
Checksums-Sha1:
 c6b17ebd3c42d7cad3a0b42b94458bbdbde6f968 2442 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2.dsc
 595cc9556a3d84cc577047a09218cfb497ab803a 19300 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2.debian.tar.xz
 94a0fb00f5dd93014c942653e97ca8f0a2836376 10409 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2_source.buildinfo
Checksums-Sha256:
 137e3a1df9df9a37d5ac35f9061deb62b0e550014bb486eed488aa2b6c9491da 2442 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2.dsc
 674d1351168d5fae399f7615724fbb9fc8f2e237826a7c2622d17bde0c5934a1 19300 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2.debian.tar.xz
 f8bb34e8fceb6e2389d23c81f425f2c77cb3696127273da279454250ef9c962b 10409 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2_source.buildinfo
Files:
 ef7d153f6a91e3d2a18be5f2f1eb6103 2442 devel optional 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2.dsc
 968ed097e74d779d72d4618b01169ee0 19300 devel optional 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2.debian.tar.xz
 e29f3dbe7e400587a0a08726cbea8728 10409 devel optional 
dbus-test-runner_16.10.0~bzr100+repack1-5~exp2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEEm/uu6GwKpf+/IgeCmvRrMCV3GzEFAmCiS2UVHHN1bndlYXZl
ckBkZWJpYW4ub3JnAAoJEJr0azAldxsxL+IP/2DzVVlp0qzr+ozcX3AKJxGWAO/E

Bug#988604: marked as done (plocate: autopkgtest regression: plocate and mlocate can't be co-installed anymore)

[Debian Bug Tracking System]

Your message dated Mon, 17 May 2021 10:50:10 +
with message-id 
and subject line Bug#988604: fixed in plocate 1.1.7-3
has caused the Debian Bug report #988604,
regarding plocate: autopkgtest regression: plocate and mlocate can't be 
co-installed anymore
to be marked as done.

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

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


-- 
988604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988604
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: plocate
Version: 1.1.7-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
plocatefrom testing1.1.7-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 to testing [1]. Can
you please investigate the situation and fix it? It seems you forgot
that one of your tests tries to coinstall both mlocate and plocate. With
your latest changes, that's not intended to be possible, making the test
fail. Please drop the test, or fix it. I think you could just depend on
mlocate and run apt-get install plocate in the test.

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=plocate

https://ci.debian.net/data/autopkgtest/testing/amd64/p/plocate/12377970/log.gz




OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: plocate
Source-Version: 1.1.7-3
Done: Steinar H. Gunderson 

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

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

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

Debian distribution maintenance software
pp.
Steinar H. Gunderson  (supplier of updated plocate package)

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


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 17 May 2021 12:26:00 +0200
Source: plocate
Architecture: source
Version: 1.1.7-3
Distribution: unstable
Urgency: medium
Maintainer: Steinar H. Gunderson 
Changed-By: Steinar H. Gunderson 
Closes: 988604
Changes:
 plocate (1.1.7-3) unstable; urgency=medium
 .
   * Update the upgrade-from-mlocate autopkgtest to account for the new
 lack of coinstallability between mlocate and plocate. (Closes: #988604)
Checksums-Sha1:
 3d5a9804175e21a3ba93aaa70355a26327df1b57 1843 plocate_1.1.7-3.dsc
 973f9d73907d004d71721fcaf9b859281e5a8088 5412 plocate_1.1.7-3.debian.tar.xz
 569391087b93ca49e52fc1b499d7c02bc817bd6e 7220 plocate_1.1.7-3_amd64.buildinfo
Checksums-Sha256:
 5779f0bb7b8dda037bed8d6a6758fd060e8024eb7fe34955277bb1a402d44fa9 1843 
plocate_1.1.7-3.dsc
 22237198c748d01ae1ca2cd6cd37d5ec097846ae6bd2fa11cc1a966271942558 5412 
plocate_1.1.7-3.debian.tar.xz
 46e170b254d153362eb52a8d2d1721b5e743888217871d60a90c356ce6c34b7e 7220 
plocate_1.1.7-3_amd64.buildinfo
Files:
 95f003094954fca92f43de0d51fe3700 1843 utils optional plocate_1.1.7-3.dsc
 0b859af46e8a28c64e9db08e9344b889 5412 utils optional 
plocate_1.1.7-3.debian.tar.xz
 4c79ecfb12c4049d45e02a000e539ee4 7220 utils optional 
plocate_1.1.7-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEwukAT/AowY5OrduDf2F1YXeXj3YFAmCiRVgACgkQf2F1YXeX
j3b5+hAAkXsYzGixGHt/+7roXZr7S8cqONwPSMJgh7e0zKhch9J0ci36ebMxtScd
D5l5N70CjSfqdIicVhSIQo9IzXjXKiKMx9LCgeW/r/llnLLvEfNNtNq9igEjVBt9
WUrsbozThXfglAYnXuZEtJ9BZJ6rBF+zCrT0R0DP8VNoqhmtfNcsGfE6MOuoIMT/
nJnsVeRZqXNAAiXMv1ZsKg2n8OTvHbpOViTbTDBrFAwl1c63tNpG2KeQbtzno/33
gDcrB+5rUQYlsWlezdTbK5HiAnf3l4+Rgx1PC5BRGmQCDCg3eRWglyimb8jcAvE8
5XU8yAlAHOWU3qG10regPSuIMv6atMII1dLtLy407BNHHDPI97fYFlPOpUXrSaln
h4yfKtxAV416PMapln+xbXc6/pAEEdmJghZeOUYJk/Mh9OMv4J2Ecf748ZPYed/S
XbaWTbdhJWlsAsA8io18Rc6tkv/QtraNCRMLY+8W4XD3lP5g0zSAySGvAzw8coD4

Bug#987936: libstorj: fails to build from the source

[Andrej Shadura]

Hi Phil and Josue,

On 15/05/2021 06:05, Philip Wyett wrote:
> Attached is a (NMU) debdiff that fixes the issue. Cherry picked patch from 
> Fedora[1].
> 
> This RC bug can be handled however wished by the maintainer. Just one less to 
> fix. :-)
> 
> [1] Original patch by: Gwyn Ciesla 

It would appear Nettle 3.7.2+ ships its own implementation of
pbkdf2_hmac_sha512, which causes the conflict during the build. I think
the best way is to change to patch to use #ifndef and not just comment
it out, so it can still be built against an older Nettle (e.g. for
backports).

I’ve pushed the changes to the Git repo and will upload this to DELAYED/0.

-- 
Cheers,
  Andrej

Bug#986100: marked as done (mate-session-manager: Should not upload XDG_SESSION_ID to systemd --user)

[Debian Bug Tracking System]

Your message dated Mon, 17 May 2021 10:18:35 +
with message-id 
and subject line Bug#986100: fixed in mate-session-manager 1.24.1-2
has caused the Debian Bug report #986100,
regarding mate-session-manager: Should not upload XDG_SESSION_ID to systemd 
--user
to be marked as done.

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

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


-- 
986100: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986100
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gnome
Version: 1:3.38+2
Severity: important
X-Debbugs-Cc: laurent.deb...@gmail.com

Dear Maintainer,

When the screens lock after idle, I can't log back in.
I am ask to type my password, which I type correctly, then the screen goes back
locked (without an error message of any kind)
When I got lock :
I used Ctrl Alt Fx then
Killall gdm3
 and login again

Cheers,
L.B




-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.8-3
ii  cheese   3.38.0-2
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 10.0.3
ii  evolution3.36.4-2
ii  evolution-plugins3.36.4-2
ii  file-roller  3.38.0-1
ii  gedit-plugins3.36.2-1
ii  gnome-calendar   3.38.1-2
ii  gnome-clocks 3.38.0-1
ii  gnome-color-manager  3.36.0-1
ii  gnome-core   1:3.38+2
ii  gnome-documents  3.34.0-2
ii  gnome-getting-started-docs   3.36.2-1
ii  gnome-maps   3.38.1.1-1
ii  gnome-music  3.36.4.1-1
ii  gnome-screenshot 3.38.0-1
ii  gnome-sound-recorder 3.38.0-1
ii  gnome-todo   3.28.1-5
ii  gnome-tweaks 3.34.0-4
ii  gnome-weather3.36.1-1
ii  gstreamer1.0-libav   1.18.1-1
ii  gstreamer1.0-plugins-ugly1.18.1-1
ii  libgsf-bin   1.14.47-1
ii  libproxy1-plugin-networkmanager  0.4.15-14
ii  libreoffice-calc 1:7.0.3-1
ii  libreoffice-gnome1:7.0.3-1
ii  libreoffice-impress  1:7.0.3-1
ii  libreoffice-writer   1:7.0.3-1
ii  network-manager-gnome1.18.0-1
ii  orca 3.38.0-1
ii  rhythmbox3.4.4-3
ii  rhythmbox-plugin-cdrecorder  3.4.4-3
ii  rhythmbox-plugins3.4.4-3
ii  rygel-playbin0.38.3-1
ii  rygel-tracker0.38.3-1
ii  seahorse 3.36-1
ii  shotwell 0.30.10-1+b1
ii  simple-scan  3.36.4-1
ii  totem-plugins3.38.0-1
ii  vinagre  3.22.0-7
ii  vino 3.22.0-6
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.38+2
ii  nautilus-extension-brasero  3.12.2-6
ii  transmission-gtk3.00-1

Versions of packages gnome suggests:
pn  alacarte 
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  gnome-remote-desktop 
pn  goobox | sound-juicer
pn  polari   
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.38.0-1
ii  at-spi2-core  2.38.0-2
ii  baobab3.38.0-1
ii  caribou   0.4.21-7
ii  chromium  83.0.4103.116-3.1
ii  dconf-cli 0.38.0-1
ii  dconf-gsettings-backend   0.38.0-1
ii  eog   3.38.0-1
ii  evince3.38.0-2
ii  evolution-data-server 3.36.4-1
ii  firefox-esr   78.4.0esr-2
ii  fonts-cantarell   0.111-3
ii  gdm3  3.38.1-2
ii  gedit 3.36.2-1
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.66.0-2
ii  gnome-backgrounds

Bug#988643: python3-vtk-dicom: broken symlink: /usr/lib/python3/dist-packages/libvtkDICOMPython39D.cpython-39-x86_64-linux-gnu.so -> libvtkDICOMPython39D.so.0.8

[Andreas Beckmann]

Package: python3-vtk-dicom
Version: 0.8.12-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

7m25.8s ERROR: FAIL: Broken symlinks:
  
/usr/lib/python3/dist-packages/libvtkDICOMPython39D.cpython-39-x86_64-linux-gnu.so
 -> libvtkDICOMPython39D.so.0.8 (python3-vtk-dicom)

The target file is shipped elsewhere:

  /usr/lib/x86_64-linux-gnu/libvtkDICOMPython39D.so.0.8


cheers,

Andreas

Bug#988639: ruby-font-awesome-rails: broken symlinks: /usr/share/ruby-font-awesome-rails/app/assets/fonts/fontawesome-webfont.*

[Andreas Beckmann]

Package: ruby-font-awesome-rails
Version: 4.7.0.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m44.3s ERROR: FAIL: Broken symlinks:
  /usr/share/ruby-font-awesome-rails/app/assets/fonts/fontawesome-webfont.woff2 
-> ../../../../fonts/woff/font-awesome/fontawesome-webfont.woff2 
(ruby-font-awesome-rails)
  /usr/share/ruby-font-awesome-rails/app/assets/fonts/fontawesome-webfont.woff 
-> ../../../../fonts/woff/font-awesome/fontawesome-webfont.woff 
(ruby-font-awesome-rails)
  /usr/share/ruby-font-awesome-rails/app/assets/fonts/fontawesome-webfont.svg 
-> ../../../../fonts/svg/font-awesome/fontawesome-webfont.svg 
(ruby-font-awesome-rails)
  /usr/share/ruby-font-awesome-rails/app/assets/fonts/fontawesome-webfont.eot 
-> ../../../../fonts/eot/font-awesome/fontawesome-webfont.eot 
(ruby-font-awesome-rails)

The targets are now located at 
/usr/share/fonts-font-awesome/fonts/fontawesome-webfont.*


cheers,

Andreas


ruby-font-awesome-rails_4.7.0.5-1.log.gz
Description: application/gzip

Bug#988562: broadcom-sta: diff for NMU version 6.30.223.271-16.1

[Roger Shimizu]

Dear Ben,

Thanks for the report and NMU!

On Mon, May 17, 2021 at 8:21 AM Ben Hutchings  wrote:
>
> Control: tags 988562 + patch
> Control: tags 988562 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for broadcom-sta (versioned as 6.30.223.271-16.1)
> and uploaded it.
>
> The changes are attached as a debdiff, but you can also merge the
> "debian" branch of .

However I find this package cannot be source upload, due to non-free.
I'll upload with binary again with version -17 later.
After that, I'll amend your unblock request.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#986527: Please check again : outdated report?

[Julien Puydt]

Hi,

I tried to create a testing sbuild and compile sagemath 9.2-2 with it,
and it worked so unless I made a mistake in my setup, something made
that bug go away...

Can someone independently give it a try?

JP

Bug#988632: audacity: The main drawing area (sound wave) do not refresh

[pominglee]

Package: audacity
Version: 2.4.2~dfsg0-4
Severity: grave
Tags: newcomer
Justification: renders package unusable
X-Debbugs-Cc: poming...@gmail.com

Hello, I've just install audacity 2.4.2~dfsg0-4. However, it is not useful
since the drawing area (the sound wave display) does not refresh. To be
more specific, when a sound file is opened, the drawing area is a mess.
I try to remove and re-install audacity without success.

Finally, I download the source code of the newest version of audacity (3.0.2)
, compile it and install it to the /usr/local/ directory. And it works 
very well.

Please help to fix this bug, thank you!!

Best Regards

pmlee


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=zh_TW.UTF8, LC_CTYPE=zh_TW.UTF8 (charmap=UTF-8) (ignored: LC_ALL 
set to zh_TW.UTF8), LANGUAGE=zh_TW:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled