Bug#954852: cmake depends on libarchive13 3.3.3, but only 3.2.2 is available

[Junya Hayashi]

I'm also getting trouble with this issue. Are there any updates?

Junya Hayashi

Bug#975591: insserv/update-rc.d coordination missing (was Re: Canonical method to locally disable an init script?)

[Lorenzo]

On Sun, 13 Dec 2020 07:17:15 +0100 (CET)
Thorsten Glaser  wrote:

 
> > root@angst:/etc# apt-get install --reinstall bind9
> […]
> > It warned that they were different from the LSB headers in the init
> > script.  Because they were different.  And that could be any of the
> > possible differences.  But it did not reset them.
> > 
> > root@angst:/etc# find /etc/rc?.d -name '*bind9'
> > /etc/rc0.d/K04bind9
> > /etc/rc1.d/K04bind9
> > /etc/rc2.d/K04bind9
> > /etc/rc3.d/K04bind9
> > /etc/rc4.d/K04bind9

> > root@angst:/etc# find /etc/rc?.d -name '*bind9'
> > /etc/rc0.d/K04bind9
> > /etc/rc1.d/K04bind9
> > /etc/rc2.d/S03bind9
> > /etc/rc3.d/S03bind9
> > /etc/rc4.d/S03bind9
> > /etc/rc5.d/S03bind9
> > /etc/rc6.d/K04bind9
> 
> Yes, and that MUST NOT happen.

That is an expected behavior 

> 
> > Removing the S* links instead of disabling them with a K* link.  But
> > leaving the K* links so it is an installed configuration.  Then
> 
> If the local administrator actively disables an init script, e.g. by
> update-rc.d remove, it MUST NOT be re-added later. (This MIGHT require
> insserv and update-rc.d to coordinate on “manually removed” state, but
> this state MUST NOT be the presence of ANY symlinks for that script.)
> 

with update-rc.d remove you are not disabling the service, you are
purging it while it's still installed.
The only way supported in update-rc.d to disable a service is
update-rc.d disable

> Rationale:
> 
> Disabling an init script is *not* the same as leaving a K link…
> because a K link will attempt to stop the service if manually started.
> This MUST NOT happen.

This is interesting: could you please write the exact sequence that
cause a manually started service to be stopped when there is a K
link in the current runlevel?
(if you already have please post again so that I'm sure)
You are upgrading the package or you are switching runlevels?

> 
> Considering raising severity on this as disabling with update-rc.d
> remove does not work and disabling with update-rc.d disable wrongly
> leaves any K links around which causes unrelated software, that is, a
> manually started service, to be broken, that is, stopped.
> 
> I just had this happen, so it isn’t an academic mind exercise.
> 
> bye,
> //mirabilos

I suspect what you want is a new feature in update-rc.d, but it depends
on your answer to my question above.

Lorenzo

Bug#977345: libxxhash built without hw-accelerated XXH3, 50% performance loss

[Julian Andres Klode]

Package: src:xxhash
Version: 0.8.0-1
Severity: normal

XXH3 supports various hardware-accelerated variants in
xxh_x86dispatch.{c,h}, which are currently not built into the library.

This means that it only operates at roughly half the speed on my Core
i5-8250U compared to the AVX2-accelerated variant.

The implementation is odd: Client code explcitly has to use the
xxh_x86dispatch.h header instead of the xxhash.h one. It would be more
convenient if any code that includes xxhash.h on x86 automatically
benefits from dispatched optimized code.

At the bare minimum, on x86, export DIGEST=1 when building and install
xxh_x86dispatch.h header. I'd love to see the xxh_x86dispatch.h also
replace the xxhash.h header on x86 (still keeping xxh_x86dispatch.h in
case people look for it) such that clients can directly benefit from it
even if they do not handle looking up that header and using it.

-- System Information:
Debian Release: bullseye/sid
  APT prefers hirsute
  APT policy: (991, 'hirsute'), (500, 'hirsute'), (500, 'groovy-updates'), 
(500, 'groovy-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-32-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#977343: RFS: breseq/0.35.4+ds-1 [ITP] -- Find mutations relative to reference sequences

[Gürkan Myczko]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "breseq":

 * Package name: breseq
   Version : 0.35.4+ds-1
   Upstream Author : Jeffrey Barrick 
 * URL : https://barricklab.org/breseq
 * License : GPL-3+, MIT, BSD-2-clause
 * Vcs : https://salsa.debian.org/myczko-guest/breseq
   Section : science

It builds those binary packages:

  breseq - Find mutations relative to reference sequences

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/breseq/

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/b/breseq/breseq_0.35.4+ds-1.dsc

Changes for the initial release:

 breseq (0.35.4+ds-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #942845)

Regards,
-- 
  Gürkan Myczko

Bug#977344: ITP: orchis-gtk-theme -- a Material Design theme for GNOME/GTK based desktop environments

[Mo Zhou]

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

* Package name: orchis-gtk-theme
  Version : git master
  Upstream Author : https://github.com/vinceliuice/
* URL : https://github.com/vinceliuice/Orchis-theme
* License : GPL-3.0
  Programming Lang: CSS
  Description : a Material Design theme for GNOME/GTK based desktop 
environments


Generally I don't tweak my desktop environment given a decent default,
but this GTK theme is so beautiful that it temporarily changed my mind.
It looks pretty under Gnome3, while it's a pity that it does not work
under MATE.

This package will be maintained under a salsa team where gtk themes are
relevant.

Bug#977338: konsole: unable to select intensive color using ANSI \e[1m sequence

[Norbert Preining]

Hi Antonio,

BIG BIG THANKS! I was puzzled about what has happened with my colors and
was reading through the wiki article you mentioned and tried to make
sense of it.

Thanks for reporting and fixing it. I pushed this change to the repo and
will upload it soon.

Best

Norbert

On Sun, 13 Dec 2020, Antonio Russo wrote:
> Konsole 20.12.0 contains a regression which breaks the ability to select an
> "intensive" color in the standard way, which I've reported upstream [1].
> The commit in question is 82806a2.

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

Bug#977341: adequate reports broken symlink for node-core-js

[shirish शिरीष]

Package: node-core-js
Version: 3.8.1-1
Severity: normal

User : debian...@lists.debian.org
Usertags : broken-symlink adequate

Dear Maintainer,
While upgrading I was hit by a broken symlink of node-core-js. On
further investigation got the following, please fix it -

$ adequate node-core-js
node-core-js: broken-symlink /usr/share/nodejs/core-js-pure/scripts ->
../core-js/scripts

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages node-core-js depends on:
ii  node-browserslist  4.14.7+~cs9.12.69-1
ii  node-semver7.3.4-1
ii  nodejs 12.19.0~dfsg-1

node-core-js recommends no packages.

node-core-js suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#977340: spip: Not compatible with php8.0

[David Prévot]

Package: spip
Version: 3.2.8-1
Severity: important
Tags: upstream
Control: block 976811 by -1

SPIP 3.3 is expected to be released “soon” (it has already been delayed
for months), but is only expected to be compatible with PHP 7.4, so not
sure we’ll be able to make it work on PHP 8.0 before the freeze (or even
the release) of Bullseye.


signature.asc
Description: PGP signature

Bug#977339: pandoc: `data-dir` or `XDG_DATA_HOME` don't appear to work for --defaults

[Kapil Paranjape]

Package: pandoc
Version: 2.9.2.1-1+b1
Severity: normal

Dear Maintainer,

The --defaults option does not appear to look in $HOME/.local/share/pandoc/
it also does not appear to look into $XDG_DATA_HOME/pandoc/ to look
for the file mentioned in this option.

$ export XDG_DATA_HOME=$HOME/.local/share
$ pandoc -d options report.md
pandoc: options.yaml: openBinaryFile: does not exist (No such file or
directory)

(This is in spite of the fact that $HOME/.local/share/pandoc/options.yaml
exists.)

The man page mentions these two locations.

Regards,

Kapil.
--

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

Kernel: Linux 4.14.199-16598-gb08cd9ce6991 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_IN.utf8, LC_CTYPE=en_IN.utf8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages pandoc depends on:
ii  libc6 2.31-5
ii  libcmark-gfm-extensions0  0.29.0.gfm.0-6
ii  libcmark-gfm0 0.29.0.gfm.0-6
ii  libffi7   3.3-5
ii  libgmp10  2:6.2.1+dfsg-1
ii  libpcre3  2:8.39-13
ii  pandoc-data   2.9.2.1-1
ii  zlib1g1:1.2.11.dfsg-2

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  citation-style-language-styles  
pn  context 
pn  ghc 
ii  groff   1.22.4-5
pn  libjs-mathjax   
pn  librsvg2-bin
pn  node-katex  
pn  nodejs  
ii  pandoc-citeproc 0.17.0.1-1+b1
ii  perl5.32.0-5
pn  php 
pn  python  
pn  r-base-core 
ii  ruby1:2.7+2
ii  texlive-latex-extra 2020.20201129-1
ii  texlive-latex-recommended   2020.20200925-1
ii  texlive-luatex  2020.20200925-1
pn  texlive-xetex   
pn  wkhtmltopdf 

-- no debconf information

Bug#971713: sysstat: init or systemd file has overlapping runlevels

[Lorenzo]

On Sun, 13 Dec 2020 19:44:01 +0100
Trek  wrote:

> 
> on new installations, simply adding the correct levels (0 1 6) to the
> script should fix the bug, but to fix on upgrades you should remove
> those links before running insserv, that is adding something like that
> to postinst inside the configure step:
> 
>   # new Default-Stop (see #971713)
>   if dpkg --compare-versions "$2" le '12.4.0-2'; then
>  update-rc.d -f sysstat remove
>   fi
> 
> this will also remove any tweaking done by user, that should be
> annotated inside the NEWS.Debian file
> 
> I would like to provide you a patch, but I can't find where the init.d
> file is enabled inside the sysstat postinst, that should be:
> 
>   update-rc.d sysstat defaults
> 
> ciao!
> 

Hi,

if you are searching in the source under /debian directory, the code
that you are looking for will be written by dh-installinit in place of
the #DEBHEPLER# placeholder, during the build of the package.
To find out what the postinst will look like just compare the one in the
source with the one in the deb package in the archive.

Lorenzo

Bug#977337: icingaweb2: Not compatible with php8.0

[Bas Couwenberg]

Source: icingaweb2
Version: 2.8.2-1
Severity: important
Tags: upstream
Control: forwarded -1 https://github.com/Icinga/icingaweb2/issues/4287
Control: block 976811 by -1

Dear Maintainer,

As reported upstream, icingaweb2 is not compatible with php8.0:

 https://github.com/Icinga/icingaweb2/issues/4287

The issue is included in the 2.9.0 but this is unlikely to be released
before the freeze.

Bug#977293: Read .xlsx from stdin, write .csv to stdout

[Sébastien Hinderer]

Dear Andrius,

Many thanks for your prompt and helpful response!

Andrius Merkys (2020/12/14 08:16 +0200):
> Hello,
> 
> On 2020-12-13 19:00, Sebastien Hinderer wrote:
> > Dear upstream authors,
> 
> Debian is not the upstream of this package. Bug reports filed in Debian
> BTS are not automatically forwarded to upstream either. To contact the
> upstream, I suggest opening an issue on their GitHub issue tracker
> [1].

My bad, sorry. Iwanted to write "dear maintainers" but while doing so I
was thinking that it was an upstream bug. My reason for submitting it as
a Debian bug was that I wanted to have a feedback not only in terms of
whether the feature can be included or not but also in terms of in which
version of the Debian package a fix would be included.

> > Would it please be possible to extend is so that "-" ban be specified
> > both as the name of the input file (meaning to read the .xlsx file
> > from standard input) and as the name of the output file, meaning that
> > the CSV file is written to stdout?
> > 
> > That way the program could be used in a pipe, which would be very
> > convenient. Of course that requires to make sure that all the
> > other messages the program could possibly produce are written to stderr.
> 
> Have you tried using /dev/stdin and /dev/stdout on the command line?
> This usually does the trick for commands not accepting '-'.

No I didn't because, after almost 20 years of use of Unix, I was simply
not aware of the existence of these files! So, many thanks for making me
realise their existence!

Best wishes and thanks again, feel free to close the bug. If I submit an
issue I can always write back to link it with the present bug report.

Sébastien.

Bug#977336: ITP: transfuse -- Runs formatted documents through transformations/translation

[Kartik Mistry]

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

 Package name: transfuse
 Version : 0.5.6
 Upstream Author : Tino Didriksen 
 URL : https://github.com/TinoDidriksen/transfuse
 License : GPL-3+
 Programming Lang: C++
 Description : Runs formatted documents through transformations/translation

Extract formatted text from documents, transform it, then put back in place.

 Q. why is this package useful/relevant? is it a dependency for another
package?

 A. Dependency and used by new Apertium packages.

 Q. how do you plan to maintain it?

 A. Debian-Science team at Salsa.



signature.asc
Description: PGP signature

Bug#977335: irssi: stops processing input after NUL character

[Kacper Gutowski]

Package: irssi
Version: 1.2.2-1+b2
Severity: normal
Tags: patch upstream

Dear Maintainer,
After receiving a NUL character from the terminal (which can happen 
for variety of reasons most likely of which is accidentally pressing 
Ctrl+Space or Ctrl+2), irssi stops accepting any further input.

This was already reported upstream as #1180 and fixed, but no new 
release was done. The upstream provides a patch for 1.2.2 at 
https://github.com/irssi/irssi/releases/download/1.2.2/glib-2-63.patch

Please consider applying the patch.
Thanks.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages irssi depends on:
ii  libc6   2.31-5
ii  libglib2.0-02.66.3-2
ii  libperl5.32 5.32.0-5
ii  libssl1.1   1.1.1i-1
ii  libtinfo6   6.2+20201114-1
ii  perl5.32.0-5
ii  perl-base [perlapi-5.32.0]  5.32.0-5

irssi recommends no packages.

Versions of packages irssi suggests:
ii  irssi-scripts  20201016

-- no debconf information

Bug#977293: Read .xlsx from stdin, write .csv to stdout

[Andrius Merkys]

Hello,

On 2020-12-13 19:00, Sebastien Hinderer wrote:
> Dear upstream authors,

Debian is not the upstream of this package. Bug reports filed in Debian
BTS are not automatically forwarded to upstream either. To contact the
upstream, I suggest opening an issue on their GitHub issue tracker [1].

> Would it please be possible to extend is so that "-" ban be specified
> both as the name of the input file (meaning to read the .xlsx file
> from standard input) and as the name of the output file, meaning that
> the CSV file is written to stdout?
> 
> That way the program could be used in a pipe, which would be very
> convenient. Of course that requires to make sure that all the
> other messages the program could possibly produce are written to stderr.

Have you tried using /dev/stdin and /dev/stdout on the command line?
This usually does the trick for commands not accepting '-'.

[1] https://github.com/dilshod/xlsx2csv/issues

Best,
Andrius

Bug#976235: enlightenment: e switches off screen|monitor

[Ross Vandegrift]

On Mon, Dec 07, 2020 at 11:34:46PM +0100, enno wrote:
> > "Ross" == Ross Vandegrift  writes:
> >> So all three cases use LVDS and know the precise measurements
> >> of my display, just e seems to need something additional which
> >> alas is not in the dependency list i suppose.
> >
> > Well, not quite - this output shows that X knows the
> > measurements of your LVDS display, ie, your laptop's built-in
> > panel.  The external screen are not detected - that confirms
> > this is not a problem in E.
> 
> Uh, Ross, I had hoped to have made that clear, all this is just about my--as 
> you call it--built-in panel.  I don't have any external screen.  I'm sorry I 
> haven't been able to make that clear straight away.

Oh sorry, I misunderstood your first message - apologies!  Is there any chance
that you only see this behavior after a suspend/resume cycle?

If I suspend by closing my lid on bullseye, I get a cycle of suspend &
unsuspend that takes ~20-30 seconds each time.  I haven't really tried to track
down a cause since I normally suspend using the menu anyhow.  That's the only
remote similar issue I've ever seen.

Ross

Bug#977269: [Pkg-javascript-devel] Bug#977269: Bug#977269: node-rollup-plugin-terser seems incompatible with current node-terser

[Xavier]

Control: fixed -1 7.0.2-3
Control: tags -1 + confirmed

Le 13/12/2020 à 22:52, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-13 22:00:53)
>> Le 13/12/2020 à 20:53, Jonas Smedegaard a écrit :
>>> Control: severity 977269 important
>>> Control: tags 977269 +moreinfo +unreproducible
>>>
>>> Quoting Jonas Smedegaard (2020-12-13 20:29:46)
 Quoting Jonas Smedegaard (2020-12-13 17:22:05)
> Quoting Xavier Guimard (2020-12-13 13:19:47)
>> Package: node-rollup-plugin-terser
>> Version: 7.0.2-2
>> Severity: grave
>> Justification: renders package unusable
>>
>> When trying current rollup-plugin-terser (7.0.2)  with current
>> node-terser (4.1.2), package is unuseable:
>>
>> $ rollup -c
>>
>> index.js → dist/pako.js, dist/pako.min.js...
>> [!] (plugin terser) Error: Cannot find module 
>> '/home/xavier/dev/debian/src/pkg-js/packages/node-pako/node_modules/terser/dist/bundle.min.js'.
>>  Please verify that the package.json has a valid "main" entry
> 
>> index.js → dist/pako.js, dist/pako.min.js...
>> minify(...).then is not a function
> 
> "Cannot find module" and "minify(...).then is not a function" are 
> clearly differen issues.  But ok, if the latter is the issue being 
> tracked with this report then I am confident it is solved with the 
> package in incoming.
> 
> Please do close this bugreport when you confirm that is the case.
> 
>  - Jonas
> 

Bug#977334: RFS: python-opentype-sanitizer/8.1.0-1 [ITP] -- Python wheels for the OpenType Sanitizer

[Romain Porte]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "python-opentype-sanitizer":

 * Package name: python-opentype-sanitizer
   Version : 8.1.0-1
   Upstream Author : Khaled Hosny 
 * URL : https://github.com/googlefonts/ots-python
 * License : BSD-3-Clause
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-opentype-sanitizer
   Section : python

It builds those binary packages:

  python3-opentype-sanitizer - Python wheels for the OpenType Sanitizer

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/python-opentype-sanitizer/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-opentype-sanitizer/python-opentype-sanitizer_8.1.0-1.dsc

Changes for the initial release:

 python-opentype-sanitizer (8.1.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #976453)

Regards,
--
  Romain Porte

Bug#977333: klayout: Vcs-* headers inac

[Vagrant Cascadian]

Package: klayout
Severity: minor

The Vcs headers in debian/control do not point to a publicly accessible
git repository:

  Vcs-Browser: https://salsa.debian.org/electronics-team/klayout
  Vcs-Git: https://salsa.debian.org/electronics-team/klayout.git

Please update the Vcs repository or update the Vcs headers in
debian/control to point to the current respository and/or branch.

Thanks for maintaining klayout!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#977332: Confusing debhelper tags (or perhaps duplicates)

[Felix Lechner]

Package: lintian
Severity: normal

Hi,

During an experimental run (in which debhelper levels may not have
been available) the test suite produced the following output:

# --- 
debian/test-out/eval/checks/debhelper/debhelper-no-depends/tags.specified.calibrated
# +++ 
debian/test-out/eval/checks/debhelper/debhelper-no-depends/tags.actual.parsed
# -debhelper-no-depends (source):
package-needs-versioned-debhelper-build-depends 9
# +debhelper-no-depends (source):
package-lacks-versioned-build-depends-on-debhelper 9
#
# Unexpected tags:
#   package-lacks-versioned-build-depends-on-debhelper
#
# Missing tags:
#   package-needs-versioned-debhelper-build-depends

Those two tags sound very much alike (but carry different visibility
levels). Upon inspection, the code that triggers them also looks
similar. For details, please see below.

Please explain and differentiate the meanings of these tags in their
descriptions, or possibly combine them. Thanks!

Kind regards
Felix Lechner

* * *

$dh_bd_version = $level if not defined($dh_bd_version);
unless ($bdepends->implies("debhelper (>= ${dh_bd_version}~)")
or $bdepends->implies("debhelper-compat (= ${dh_bd_version})")){
my $tagname = 'package-needs-versioned-debhelper-build-depends';
my @extra = ($level);
$tagname = 'package-lacks-versioned-build-depends-on-debhelper'
  if ($dh_bd_version <= $compat_level->value('pedantic'));
$self->hint($tagname, @extra);
}

$dh_bd_version = $level if not defined($dh_bd_version);
unless ($bdepends->implies("debhelper (>= ${dh_bd_version}~)")
or $bdepends->implies("debhelper-compat (= ${dh_bd_version})")){
my $tagname = 'package-needs-versioned-debhelper-build-depends';
my @extra = ($level);
$tagname = 'package-lacks-versioned-build-depends-on-debhelper'
  if ($dh_bd_version <= $compat_level->value('pedantic'));
$self->hint($tagname, @extra);
}

Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/

[Reinhard Tartler]

Control: forwarded -1 https://github.com/shirou/gopsutil/issues/881

I'm having a hard time seeing bugs like this as RC-critical. Looking at
the testsuite more specifically, I strongly believe this is upstream bug
https://github.com/shirou/gopsutil/issues/881

Lucas, can you please post /proc/cpuinfo from the amd64 machine you
tested on so that we confirm that it doesn't report a modelname?

I'd concur with Andreas to disable running tests on !amd64, maybe with
something like this patch:

modified   debian/rules
@@ -10,3 +10,9 @@ export CIRCLECI := true
 
 %:
dh $@ --buildsystem=golang --with=golang
+
+
+override_dh_auto_test:
+ifneq (,$(filter $(DEB_HOST_ARCH), amd64))
+   dh_auto_test --buildsystem=golang
+endif



Alternativly, we could also disable the "problematic part" of the test until 
the upstream bug is fixed properly:

diff --git a/cpu/cpu_test.go b/cpu/cpu_test.go
index e8e0e8d..dbcaaae 100644
--- a/cpu/cpu_test.go
+++ b/cpu/cpu_test.go
@@ -85,11 +85,6 @@ func TestCpuInfo(t *testing.T) {
if len(v) == 0 {
t.Errorf("could not get CPU Info")
}
-   for _, vv := range v {
-   if vv.ModelName == "" {
-   t.Errorf("could not get CPU Info: %v", vv)
-   }
-   }
 }


In any case, I'm unconvinced that this bug is severe enough to claim it
as 'release critical' would warrant removing the package from unstable.

Bug#976915: (no subject)

[Logan Rosen]

Control: tags -1 patch

Subject: Re: service-wrapper-java: FTBFS on ppc64el:  [exec] 
wrapper.c:(.text+0x3598): undefined reference to `pow'
Followup-For: Bug #976915
Package: service-wrapper-java
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Version: 3.5.30-1

Dear Maintainer,

In Ubuntu, the attached patch (from Dimitri John Ledkov ) was 
applied to achieve the following:

  * Fix as-needed linking in ppc64el and s390x per-arch Makefiles too.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: bullseye/sid
  APT prefers groovy-updates
  APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 
'groovy'), (100, 'groovy-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.128-microsoft-standard (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru service-wrapper-java-3.5.30/debian/patches/fix-as-needed-ppc.patch 
service-wrapper-java-3.5.30/debian/patches/fix-as-needed-ppc.patch
--- service-wrapper-java-3.5.30/debian/patches/fix-as-needed-ppc.patch  
2016-12-19 07:17:55.0 -0500
+++ service-wrapper-java-3.5.30/debian/patches/fix-as-needed-ppc.patch  
2017-06-20 06:22:53.0 -0400
@@ -3,10 +3,9 @@
 Author: Andreas Moog 
 Bug: https://sourceforge.net/p/wrapper/bugs/285/
 
-diff -pruN -x '*~' wrapper_3.5.25_src.orig/src/c/Makefile-linux-ppc-32.make 
wrapper_3.5.25_src/src/c/Makefile-linux-ppc-32.make
 wrapper_3.5.25_src.orig/src/c/Makefile-linux-ppc-32.make   2015-01-04 
01:21:32.915068936 +0100
-+++ wrapper_3.5.25_src/src/c/Makefile-linux-ppc-32.make2015-01-04 
01:23:18.271591362 +0100
-@@ -33,7 +33,7 @@ init:
+--- a/src/c/Makefile-linux-ppc-32.make
 b/src/c/Makefile-linux-ppc-32.make
+@@ -33,7 +33,7 @@
if test ! -d .deps; then mkdir .deps; fi
  
  wrapper: $(wrapper_SOURCE)
@@ -15,10 +14,9 @@
  
  libwrapper.so: $(libwrapper_so_OBJECTS)
${COMPILE} -shared $(LDFLAGS) $(libwrapper_so_OBJECTS) -o 
$(LIB)/libwrapper.so
-diff -pruN -x '*~' wrapper_3.5.25_src.orig/src/c/Makefile-linux-ppc-64.make 
wrapper_3.5.25_src/src/c/Makefile-linux-ppc-64.make
 wrapper_3.5.25_src.orig/src/c/Makefile-linux-ppc-64.make   2015-01-04 
01:21:32.915068936 +0100
-+++ wrapper_3.5.25_src/src/c/Makefile-linux-ppc-64.make2015-01-04 
01:23:02.287512123 +0100
-@@ -33,7 +33,7 @@ init:
+--- a/src/c/Makefile-linux-ppc-64.make
 b/src/c/Makefile-linux-ppc-64.make
+@@ -33,7 +33,7 @@
if test ! -d .deps; then mkdir .deps; fi
  
  wrapper: $(wrapper_SOURCE)
@@ -27,3 +25,25 @@
  
  libwrapper.so: $(libwrapper_so_OBJECTS)
${COMPILE} -shared $(LDFLAGS) $(libwrapper_so_OBJECTS) -o 
$(LIB)/libwrapper.so
+--- a/src/c/Makefile-linux-ppcle-64.make
 b/src/c/Makefile-linux-ppcle-64.make
+@@ -33,7 +33,7 @@
+   if test ! -d .deps; then mkdir .deps; fi
+ 
+ wrapper: $(wrapper_SOURCE)
+-  $(COMPILE) -lm -pthread $(wrapper_SOURCE) -o $(BIN)/wrapper
++  $(COMPILE) -pthread $(wrapper_SOURCE) -lm -o $(BIN)/wrapper
+ 
+ libwrapper.so: $(libwrapper_so_OBJECTS)
+   ${COMPILE} -shared $(libwrapper_so_OBJECTS) -o $(LIB)/libwrapper.so
+--- a/src/c/Makefile-linux-s390x-64.make
 b/src/c/Makefile-linux-s390x-64.make
+@@ -34,7 +34,7 @@
+   if test ! -d .deps; then mkdir .deps; fi
+ 
+ wrapper: $(wrapper_SOURCE)
+-  $(COMPILE) -lm -pthread $(wrapper_SOURCE) $(LDFLAGS) -o $(BIN)/wrapper
++  $(COMPILE) -pthread $(wrapper_SOURCE) $(LDFLAGS) -lm -o $(BIN)/wrapper
+ 
+ libwrapper.so: $(libwrapper_so_OBJECTS)
+   ${COMPILE} -shared $(libwrapper_so_OBJECTS) $(LDFLAGS) -o 
$(LIB)/libwrapper.so

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ryutaroh Matsumoto]

Hi Ben,

> But linux-image-rpi does not have the virtio driver, this option cannot
> be used (at least for now).
> 
> Can you try adding it?  You should be able to cross-build the kernel
> package quite easily if you use the profiles "cross,pkg.linux.notools".
> There are generic instructions at
> .

Thanks. I will. But please give me some time as I am in my working hour... 
I didn't have experience with u-boot'ing a Debian kernel, so maybe I need some
time to correctly build a qemu bootable image by u-boot-rpi:armel package...
Ryutaroh

Bug#973670: vim-athena: Vim Athena - E236: Font Unifont is not fixed width

[James McCoy]

On Mon, Nov 02, 2020 at 09:55:45PM -0300, DieSpinne wrote:
> If I try to set GNU Unifont as my Gvim's font I get errors. Attempt:
> 
> :set gfn=-*-unifont-*-*-*-*-*-*-*-*-c-*-*-*
> 
> Errors raised:
> 
> E236: Font "-*-unifont-*-*-*-*-*-*-*-*-c-*-*-*" is not fixed-width
> E596: Invalid font(s): gfn=-*-unifont-*-*-*-*-*-*-*-*-c-*-*-*
> 
> Note that GNU Unifont is a fixed width font, as indicated by the "c" in the 
> spacing element.
> There is no error with "-*-terminus-*-*-*-*-*-*-*-*-c-*-*-*", on the other 
> hand.

This error comes directly from comparing the XFontStruct's
min_bounds.width and max_bounds.width values.  If they differ, then the
error is emitted.

[XFontStruct]: 
https://manpages.debian.org/buster/libx11-doc/XFontStruct.3.en.html

This implies there is a but in the font, such that it isn't truly the
same width for all characters.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#977107: [Gente-ctu] Bug#977107: proftpd-basic: Cannot login after upgrade from jessie to stretch then to buster

[Hostmaster FCEIA-UNR]

Hello. Sorry for the delay. I was on a trip this weekend.

I´m not using  "AuthUsingAlias", just "AuthAliasOnly".
I have a near default proftpd.conf and then ( in a file included from 
conf.d with) 400 users defined by the snippet I already sent (without 
AuthUsingAlias, as told before).


Well, removing all AuthAliasOnly from the configuration, started to work 
as expected.


What I still don´t understand is if it is a bug or a configuration error.

Do you still need my proftpd.conf ?

Thanks a lot.

Javier


El 12/12/2020 a las 13:00, Francesco P. Lovergine escribió:

tags 977107 = confirmed upstream
severity 977107 normal

thanks

Ok, I managed to replicate the issue by using the default configuration
and your snippet on buster. It works only by removing the 
AuthAliasOnly/AuthUsingAlias directives.


Also, I did a fast trial with the latest jessie version (several 
security patch had been applied during its support time) with the same 
results.


Same results with testing and moving AuthAliasOnly in global, too.


  AnonRequirePassword on
  RequireValidShell   off

   AuthAliasOnly   on   <- here the problem
   AuthUsingAlias  on   <- here the problem, 
even by using x for UserPassword


   User    www-data
  UserAlias   x www-data
  Group   www-data
  Umask   003
  GroupOwner  www-data
  MaxClients  2
  AccessGrantMsg  "Acceso Permitido a %u - Toda su 
actividad esta siendo monitoreada."

  HideNoAccess    on
  UserPassword    www-data w4/CBsf6D7jf2

Bug#968626: gitlab: Error 500 during CI artifacts upload from gitlab-runner

[devel]

Hello,


On Tue, 18 Aug 2020 20:37:09 +0200 Maximilian Stein  wrote:
> Since the upgrade to above mentioned version, artifact uploads from
> gitlab runners fail with an error 500.

the same error (with the same stacktrace) also occurs on my gitlab instance
after the upgrade of the Debian package (from 11.8 to 13.4).

With increased log_level (see /etc/gitlab/environments/production.rb) I saw the
following (slightly more verbose) log output in /var/log/gitlab/production.log:


Started POST 
"/api/v4/jobs/6118/artifacts?artifact_format=zip_type=archive_in=2d"
 for x.x.x.x at 2020-12-14 02:35:51 +0100
  Ci::Build Load (1.5ms)  SELECT "ci_builds".* FROM "ci_builds" WHERE 
"ci_builds"."type" = $1 AND "ci_builds"."id" = $2 LIMIT $3  [["type", 
"Ci::Build"], ["id", 6118], ["LIMIT", 1]]
  Project Load (1.2ms)  SELECT "projects".* FROM "projects" WHERE 
"projects"."id" = $1 LIMIT $2  [["id", 4], ["LIMIT", 1]]
  Ci::Runner Load (0.9ms)  SELECT "ci_runners".* FROM "ci_runners" WHERE 
"ci_runners"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]
  Namespace Load (1.1ms)  SELECT "namespaces".* FROM "namespaces" WHERE 
"namespaces"."id" = $1 LIMIT $2  [["id", 4], ["LIMIT", 1]]
  Plan Load (1.1ms)  SELECT "plans".* FROM "plans" WHERE "plans"."name" = $1 
LIMIT $2  [["name", "default"], ["LIMIT", 1]]
  PlanLimits Load (1.4ms)  SELECT "plan_limits".* FROM "plan_limits" WHERE 
"plan_limits"."plan_id" = $1 LIMIT $2  [["plan_id", 1], ["LIMIT", 1]]
  Group Load (3.1ms)  SELECT "namespaces".* FROM "namespaces" WHERE 
"namespaces"."type" = $1 AND "namespaces"."id" = $2  [["type", "Group"], ["id", 
4]]
  Ci::JobArtifact Load (1.1ms)  SELECT "ci_job_artifacts".* FROM 
"ci_job_artifacts" WHERE "ci_job_artifacts"."job_id" = $1 AND 
"ci_job_artifacts"."file_type" = $2 LIMIT $3  [["job_id", 6118], ["file_type", 
1], ["LIMIT", 1]]
  User Load (1.4ms)  SELECT "users".* FROM "users" WHERE "users"."id" = $1 
LIMIT $2  [["id", 1], ["LIMIT", 1]]
  Route Load (1.0ms)  SELECT "routes".* FROM "routes" WHERE 
"routes"."source_id" = $1 AND "routes"."source_type" = $2 LIMIT $3  
[["source_id", 4], ["source_type", "Project"], ["LIMIT", 1]]
undefined method `empty?' for 201:Integer excluded from capture: DSN not set
  
NoMethodError (undefined method `empty?' for 201:Integer):
  
lib/gitlab/middleware/read_only/controller.rb:51:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/same_site_cookies.rb:27:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'
lib/gitlab/middleware/request_context.rb:23:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'



For now I sadly could not find a way to work around this issue or gather more
debugging information.

I would appreciate any hints!

Cheers,
Lars

Bug#977331: O: autoconf -- automatic configure script builder

[Ben Pfaff]

Package: wnpp
Severity: normal

This package is going to require some work from someone who is already
familiar with Autoconf.  A major new release (2.70) has come out
following more than 8 years of upstream development without one.
Whoever adopts it will have to figure out whether it makes sense to
package 2.70 under the name "autoconf" (and create a compatibility
package for 2.69, as was done previously with autoconf2.13), to instead
package 2.70 as "autoconf2.70", or to do something else.  I do not have
the motivation and the time to commit to this myself.  I hope that
someone out there does!

This package is pretty important to developers: popularity-contest
(https://qa.debian.org/popcon.php?package=autoconf) shows it installed
on over 55,000 machines.

This package has several bugs.  I expect that the 2.70 release fixes a
number of them (and introduces more).

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ben Hutchings]

On Mon, 2020-12-14 at 10:24 +0900, Ryutaroh Matsumoto wrote:
Hi Ben, thanks again for your response.

> We used to provide a 'versatile' flavour on armel, for the ARM
> > Versatile boards that QEMU has supported for a long time.  I removed
> > this flavour back in 2016 after finding that it had been broken for a
> > while and no-one had reported it.  Adding that back might be an option,
> > if the Raspberry Pi device emulation in QEMU is slow.  What do you
> think?

If nobody uses linux-image-versatile now, I don't want to request the
kernel team to revive it. It may/might increase the maintainance
effort...

It will, though probably not very much.

The minimum requirements by autopkgtest-virt-qemu are
* VM has at least two serial ports,
* the Linux kernel has a driver for them, and
* the Linux kernel has a driver for a storage attached to the VM.

On the other hand, RPi series has only one serial port by PL011.
So we need to attach another serial port to the VM. For armhf, arm64,
and ppc64el, I was advised to use virtconsole by Simon McVittie,
and it has worked fine as far as I see.

But linux-image-rpi does not have the virtio driver, this option cannot
be used (at least for now).

Can you try adding it?  You should be able to cross-build the kernel
package quite easily if you use the profiles "cross,pkg.linux.notools".
There are generic instructions at
.

[...]
> The usual practice is to use u-boot or some other board-specific boot
> loader, which can be configured by the flash-kernel package.  I don't
> think that works in QEMU.

I have not intensively investigated if we can boot linux-image-marvell
by qemu-system-arm and some u-boot Debian package...
I will see it within several days and report it back here.
First I will see u-boot-qemu Debian package and the qemu "virt" machine
can boot linux-image-marvell as suggested at
https://github.com/ARM-software/u-boot/blob/master/doc/README.qemu-arm

It won't - it has very different hardware.  Even the CPU will be
incompatible (ARMv7 whereas marvell is built for v5).

Ben.

linux-image-marvell seems capable of handling PCI serial ports.
Storage options for QEMU VM seems only "ich9-ahci" and "sdhci-pci"...

Best regards, Ryutaroh

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#972437: debian-reference: mentions no longer existing packages

[肖盛文]

In most situation, if one package in oldstable but not in stable,this
package can usually been installed in stable.

Drop such packages from listing is also fix this bug report.

Is debian-reference need to support list such oldstable packages? I'm
not sure.


在 2020/12/14 上午6:25, Osamu Aoki 写道:
> Doesn't this give impression that these packages are supported well?
> I usually drop such packages from listing
>
> On Fri, 2020-11-13 at 16:44 +0800, xiao sheng wen (肖盛文) wrote:
>> tags -1 + fixed pending
>>
>>
>> I'd committed the patch in git repo use the attachment patch.
>>
>> This patch add the package info come from oldstable and stable.
>>
>> Debian-reference will get the package info from oldstable, stable,
>> sid now.
>>
>> 在 2020/10/21 下午5:36, Holger Wansing 写道:
>>> We talk about experienced users here, but if such users are unable
>>> to find old versions of the debian-reference in the archive, they 
>>> should
>>> better not mix up stable and oldstable (and therefore risk to break
>>> the next dist-upgrade and similar), since they are *not*
>>> experienced users, 
>>> but - ok, I will stop that here.
>>>
>>> Holger 
>>>
-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat)：atzlinux
《铜豌豆 Linux》 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977330: uhd: reproducible builds: Embeds timestamp in build log

[Vagrant Cascadian]

Source: uhd
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

A build log file included with the shipped documentation files embeds
the build time:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/uhd.html
  /usr/share/doc/uhd-host/doxygen/latex/refman.log.gz

  1 
This·is·pdfTeX,·Version·3.14159265-2.6-1.40.21·(TeX·Live·2020/Debian)·(preloaded·format=pdflatex·2020.12.11)··11·DEC·2020·17:05
  1 
This·is·pdfTeX,·Version·3.14159265-2.6-1.40.21·(TeX·Live·2020/Debian)·(preloaded·format=pdflatex·2022.1.15)··15·JAN·2022·01:51


The attached patch fixes this by removing the documentation sources from
the documentation directory in debian/rules.

If the sources for the documentation are intentionally included, please
consider adjusting the patch to just remove the refman.log file.

With this issue fixed, uhd should become reproducible once it reaches
bullseye, although unstable and experimental also vary build path,
causing other reproducibility issues with uhd.


Thanks for maintaining uhd!


live well,
  vagrant
From 1bb35256f8c1a2ca429975179d09f43aced85c6e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 14 Dec 2020 00:49:59 +
Subject: [PATCH] debian/rules: Remove source files from documentation
 directory.

The installed package need not ship the source code to generate the
html documentation.

Some files such as refman.log include timestamp and other
non-deterministic information about the build, resulting in
reproducibility issues.
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 467ad4f..c83ee32 100755
--- a/debian/rules
+++ b/debian/rules
@@ -43,6 +43,8 @@ override_dh_auto_install:
 	dh_auto_install
 	chmod -x debian/tmp/usr/lib/uhd/tests/devtest/*.py
 	- rm debian/libuhd-dev/usr/lib/cmake/uhd/
+	# Remove source files used to generate documentation
+	rm -rf debian/tmp/usr/share/doc/uhd/doxygen/latex
 
 get-orig-source:
 	echo $(VER) $(GITREV)
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ryutaroh Matsumoto]

Hi Ben, thanks again for your response.

> We used to provide a 'versatile' flavour on armel, for the ARM
> Versatile boards that QEMU has supported for a long time.  I removed
> this flavour back in 2016 after finding that it had been broken for a
> while and no-one had reported it.  Adding that back might be an option,
> if the Raspberry Pi device emulation in QEMU is slow.  What do you
> think?

If nobody uses linux-image-versatile now, I don't want to request the
kernel team to revive it. It may/might increase the maintainance effort...

The minimum requirements by autopkgtest-virt-qemu are
* VM has at least two serial ports,
* the Linux kernel has a driver for them, and
* the Linux kernel has a driver for a storage attached to the VM.

On the other hand, RPi series has only one serial port by PL011.
So we need to attach another serial port to the VM. For armhf, arm64,
and ppc64el, I was advised to use virtconsole by Simon McVittie,
and it has worked fine as far as I see.

But linux-image-rpi does not have the virtio driver, this option cannot
be used (at least for now). Another option is to attach "pci-serial-2x"
to the qemu VM, but linux-image-rpi does not seem to have a PCI driver...
Yet another option is to attach "qemu-xhci" and "usb-serial" to the VM,
but "usb-serial" behaves much differently from isa/pci-serial and virtconsole
and it cannot be used by the current autopkgtest-virt-qemu as reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038#40

> The usual practice is to use u-boot or some other board-specific boot
> loader, which can be configured by the flash-kernel package.  I don't
> think that works in QEMU.

I have not intensively investigated if we can boot linux-image-marvell
by qemu-system-arm and some u-boot Debian package...
I will see it within several days and report it back here.
First I will see u-boot-qemu Debian package and the qemu "virt" machine
can boot linux-image-marvell as suggested at
https://github.com/ARM-software/u-boot/blob/master/doc/README.qemu-arm

linux-image-marvell seems capable of handling PCI serial ports.
Storage options for QEMU VM seems only "ich9-ahci" and "sdhci-pci"...

Best regards, Ryutaroh

Bug#974087: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

[Guillem Jover]

Hi!

On Mon, 2020-11-16 at 02:33:53 +0100, Guillem Jover wrote:
> On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote:
> > > Adding more hurdles does not help. 
> > > I think this is a hurdle we do not need.
> > 
> > To me, a one-line change in packaging seems like a quite small hurdle in
> > the short-term, but clearly you do not agree.
> 
> This being just a default change that can be overridden with a one
> line modification, seems to me also to be quite unobtrusive. More so
> when we have things like hardening that people are overriding all over
> the place w/o much of an issue.
> 
> > So it really comes down to applying opt-in patches for hundreds (maybe
> > thousands) of packages, or an opt-out change for somewhere in the
> > ballpark of tens or hundreds of packages.
> 
> Yes, that's my view too. I had the patch queued in dpkg for my next
> push, but I've pulled it out for now given the raised concern, but
> I'm not seeing a very strong case here to not include it again TBH.

Ok, I'm doing this now and will reinstate the patch into the queue to
be part of my next push.

Thanks,
Guillem

Bug#976249: dpkg: /usr/share/perl5/Dpkg/Source/Package.pm call syserror() instead of syserr()

[Guillem Jover]

Control: tags -1 pending

Hi!

On Wed, 2020-12-02 at 07:29:26 +0100, Uwe Steinmann wrote:
> Package: dpkg
> Version: 1.20.5
> Severity: normal

> In line 547 of /usr/share/perl5/Dpkg/Source/Package.pm syserror()
> instead of syserr() is called.
> 
>   cp($src, $dst)
>   or syserr(g_('cannot copy %s to %s'), $src, 
> $dst);

Thanks for the report. This had been reported as part of #849752 and
fixed in git, will be included in the next release:

  


Thanks,
Guillem

Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1

[proctor]

Package: krita
Version: 1:4.4.1+dfsg-1+b1
Severity: important
X-Debbugs-Cc: damonswir...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


krita will not open. when i try i get this in dmesg and syslog

[327378.536890] krita[1273329]: segfault at 0 ip 7efdeea7c190 sp 
7fff99cbf6f8 error 4 in libQt5Gui.so.5.15.1[7efdee9fe000+4c3000]
[327378.536895] Code: e0 10 48 09 f0 48 c1 e0 10 4c 09 e8 49 89 40 04 31 c0 66 
41 89 40 0c 48 83 c4 18 4c 89 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 <48> 8b 06 
8b 56 08 48 89 07 89 57 08 f0 83 00 01 c3 90 66 66 2e 0f

krita does work on a similar system but with AMD video card (this machine
has nvidia card) so maybe this is a video driver problem instead? is so let
me know and i will try to file this bug there instead!

cheers!


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages krita depends on:
ii  krita-data1:4.4.1+dfsg-1
ii  libc6 2.31-5
ii  libexiv2-27   0.27.3-3
ii  libfftw3-double3  3.3.8-2
ii  libgcc-s1 10.2.0-19
ii  libgif7   5.1.9-1
ii  libgsl25  2.6+dfsg-2
ii  libheif1  1.9.1-1
ii  libilmbase25  2.5.3-2
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libkf5completion5 5.74.0-2
ii  libkf5configcore5 5.74.0-2
ii  libkf5configgui5  5.74.0-2
ii  libkf5coreaddons5 5.74.0-2
ii  libkf5crash5  5.74.0-2
ii  libkf5guiaddons5  5.74.0-3
ii  libkf5i18n5   5.74.0-3
ii  libkf5itemviews5  5.74.0-2
ii  libkf5widgetsaddons5  5.74.0-3
ii  libkf5windowsystem5   5.74.0-2
ii  liblcms2-22.9-4+b1
ii  libopencolorio1v5 1.1.1~dfsg0-6+b3
ii  libopenexr25  2.5.3-2
ii  libopenjp2-7  2.3.1-1
ii  libpng16-16   1.6.37-3
ii  libpoppler-qt5-1  20.09.0-3
ii  libpython3.9  3.9.1-1
ii  libqt5concurrent5 5.15.1+dfsg-4
ii  libqt5core5a  5.15.1+dfsg-4
ii  libqt5dbus5   5.15.1+dfsg-4
ii  libqt5gui55.15.1+dfsg-4
ii  libqt5multimedia5 5.15.1-2
ii  libqt5network55.15.1+dfsg-4
ii  libqt5printsupport5   5.15.1+dfsg-4
ii  libqt5qml55.15.1+dfsg-3
ii  libqt5quick5  5.15.1+dfsg-3
ii  libqt5quickwidgets5   5.15.1+dfsg-3
ii  libqt5svg55.15.1-2
ii  libqt5widgets55.15.1+dfsg-4
ii  libqt5x11extras5  5.15.1-2
ii  libqt5xml55.15.1+dfsg-4
ii  libquazip5-1  0.9.1-1
ii  libraw20  0.20.2-1
ii  libstdc++610.2.0-19
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.12-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages krita recommends:
ii  krita-gmic   2.4.5-1.1+b1
ii  python3-pyqt55.15.2+dfsg-1
ii  python3-sip  4.19.24+dfsg-1+b2
ii  qml-module-qtmultimedia  5.15.1-2

Versions of packages krita suggests:
ii  colord  1.4.4-2
ii  ffmpeg  7:4.3.1-5
pn  krita-l10n  

-- no debconf information

Bug#977240: dpkg-query --showformat='${db-fsys:Files}' incompatible with buster

[Guillem Jover]

Control: tags -1 moreinfo unreproducible

Hi!

On Sun, 2020-12-13 at 00:27:39 +0100, Bill Allombert wrote:
> Package: dpkg
> Version: 1.20.5
> Severity: important

> The command
> dpkg-query --show --showformat='${db-fsys:Files}
> displays an extra spurious first line:
> 
> (Reading database ... 134656 files and directories currently installed.)
> 
> which breaks compatibiity with buster (which doe not)

I cannot reproduce this on either my main sid systems nor on a clean
sid chroot. Can you reproduce this elsewhere?

Thanks,
Guillem

Bug#977247: FTBFS against opencv 4.5.0

[José Luis Blanco-Claraco]

Dear Mo:

Thanks for reporting.
Fixed upstream:
https://github.com/MRPT/mrpt/commit/671d8f0d85d68b800a3d07e7e2371509683df5a0

I'll release a new version very soon.

Best,
JL

On Sun, Dec 13, 2020 at 7:21 AM Mo Zhou  wrote:
>
> Source: mrpt
> Version: 2.1.5-1
> Severity: important
> Tags: ftbfs
>
> Dear maintainer,
>
> package mrpt FTBFS against opencv 4.5.0-1 (experimental).



-- 

/**
 * Jose Luis Blanco-Claraco
 * Universidad de Almería - Departamento de Ingeniería
 * [Homepage]( https://w3.ual.es/~jlblanco/ )
 * [GH profile]( https://github.com/jlblancoc )
 */

Bug#976247: speech-dispatcher: conffiles not removed: /etc/speech-dispatcher/modules/ kali.conf ibmtts.conf baratinoo.conf

[Guillem Jover]

On Tue, 2020-12-08 at 01:25:30 +0100, Samuel Thibault wrote:
> I moved a configuration file kali.conf from the speech-dispatcher
> package to the speech-dispatcher-kali package (as well as others, but
> let's keep that example only).
> 
> The thing is: speech-dispatcher does not depend on
> speech-dispatcher-kali (and cannot: the former is in main, the latter is
> in contrib). It means that we either have
> 
> - a system with speech-dispatcher only, we want kali.conf to go away.
> 
> - a system with speech-dispatcher and speech-dispatcher-kali, we want to
>   keep kali.conf and reassign it to speech-dispatcher-kali.

> Do you have any other idea?

I'd probably try adding a Breaks to speech-dispatcher against the
older speech-dispatcher-kali versions not owning the file, to force
the upgrade, and add a Replaces to speech-dispatcher-kali against
speech-dispatcher, but I assume you already have these. Then just
drop the file from speech-dispatcher and let dpkg handle the conffile
takeover, and then conditionally run rm_conffile in speech-dispatcher
iff speech-dispatcher-kali is not present?

Thanks,
Guillem

Bug#977292: New upstream version 1.2.5

[Dmitry Smirnov]

On Monday, 14 December 2020 3:57:56 AM AEDT Shengjing Zhu wrote:
> Would you mind that I add myself to uploaders and upload 1.2.5?

Please go ahead and thanks for your help.


> I still use it exclusively in my container images and want to keep it up to
> date.

Awesome. I'm glad to read that it is useful to you.

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

COVID-19: Majority testing positive have no symptoms.
-- 
https://thecritic.co.uk/issues/july-august-2020/ignoring-the-covid-evidence/


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

Bug#977328: false positive when passing variables to functions by address

[Russ Allbery]

Package: cppcheck
Version: 2.3-1
Severity: normal

Thank you for packaging cppcheck 2.3!  I'm pleased to confirm that the
bugs that I reported in #943463 were indeed fixed in that release.

Unfortunately, it appears to have introduced a few more false positives
in this general area.  Here is a minimized test case:

#include 
#include 

int
test_a(void)
{
uint32_t pag;
struct some_struct foo;

pag = (uint32_t) -1;
/* The bug disappears if  is not cast to void *. */
foo.pag = (void *) 
foo.pag_size = sizeof(pag);
result = some_call();
if (result == 0)
return pag != (uint32_t) -1;
}

int
test_b(void)
{
char **string = NULL;

/* The bug disappears if retval is not included in the check. */
retval = some_other_call();
if (retval && string && string[0])
return 0;
return -1;
}

void
test_c(void)
{
some_type *foo = NULL;
other_type blah;

retval = call_a();
if (retval != 0)
goto done;
blah.flag = foo->flag;
call_b();

done:
if (foo != NULL)
free_foo(foo);
}

And here is the output from cppcheck:

% cppcheck --enable=warning,style foo.c
Checking foo.c ...
foo.c:16:20: style: Condition 'pag!=(uint32_t)-1' is always false 
[knownConditionTrueFalse]
return pag != (uint32_t) -1;
   ^
foo.c:10:11: note: Assignment 'pag=(uint32_t)-1', assigned value is 4294967295
pag = (uint32_t) -1;
  ^
foo.c:16:20: note: Condition 'pag!=(uint32_t)-1' is always false
return pag != (uint32_t) -1;
   ^
foo.c:22:12: warning: Either the condition 'retval&' is redundant or 
there is possible null pointer dereference: string. [nullPointerRedundantCheck]
char **string = NULL;
   ^
foo.c:26:16: note: Assuming that condition 'retval&' is not redundant
if (retval && string && string[0])
   ^
foo.c:22:12: note: Null pointer dereference
char **string = NULL;
   ^
foo.c:40:17: warning: Either the condition 'foo!=NULL' is redundant or there is 
possible null pointer dereference: foo. [nullPointerRedundantCheck]
blah.flag = foo->flag;
^
foo.c:44:13: note: Assuming that condition 'foo!=NULL' is not redundant
if (foo != NULL)
^
foo.c:40:17: note: Null pointer dereference
blah.flag = foo->flag;
^

The common theme in all three cases is that a variable is passed by
address to another function (via adding its address to a struct or
just directly), and cppcheck loses track of the fact that function may
have changed its value.

In the first case, I think the (void *) cast is the key.  If it's
removed, cppcheck understands the code correctly.  (But this is sometimes
required by badly-designed APIs.)

In the second case, something about adding retval to the test messes up
its understanding of the data flow.

The third case seems similar to the previous set of bugs, although note
that it only happens with assignment.  If that line is instead replaced
with something like call_c(foo->flag), there is no error.

(Apologies, I haven't reported these upstream since they want bug
reporters to catch them on IRC to get a Trac account created.)

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 cppcheck depends on:
ii  libc6 2.31-5
ii  libgcc-s1 10.2.1-1
ii  libpcre3  2:8.39-13
ii  libstdc++610.2.1-1
ii  libtinyxml2-8 8.0.0+dfsg-2
ii  libz3-4   4.8.9-1
ii  python3   3.9.0-4
ii  python3-pygments  2.7.1+dfsg-1

cppcheck recommends no packages.

Versions of packages cppcheck suggests:
ii  clang 1:11.0-51
pn  clang-tidy
pn  cppcheck-gui  

-- no debconf information

Bug#977327: Please package Ansible v2.10.x

[John Zaitseff]

Package: ansible
Severity: wishlist

Thank you for packaging Ansible for Debian!  Is it possible for you
to package v2.10.x?  Version 2.10.0 was released on 14th August; the
current version is 2.10.3 (3rd November) and v2.10.4 is current RC1.

Yours truly,

John Zaitseff

-- 
John Zaitseff  ╭───╮   Email: j.zaits...@zap.org.au
The ZAP Group  │ Z │   GnuPG: 0x0D254111C4EE569B
Sydney, Australia  ╰───╯   https://www.zap.org.au/~john/

Bug#977326: fuse-emulator-gtk: No display if window is tall. GTK warnings: drawing failure for widget 'GtkDrawingArea': invalid value for stride

[James Youngman]

Package: fuse-emulator-gtk
Version: 1.5.7+dfsg1-2~deb10u1
Severity: important

When I run "fuse" or "fuse-gtk" the fuse main window appears, but
there is no display of the Spectrum screen within it.  However, things
are working, even if not visible.  If I record the screen as a movie
(using fuse's menus) and replay the movie, things are recorded
OK. They're just not visible at the time.

The fust-gtk binary spews many Gtk warnings which may or may not be
relevant:

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.064: drawing failure for widget 
'GtkWindow': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.081: drawing failure for widget 
'GtkDrawingArea': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.081: drawing failure for widget 
'GtkBox': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.081: drawing failure for widget 
'GtkWindow': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.099: drawing failure for widget 
'GtkDrawingArea': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.099: drawing failure for widget 
'GtkBox': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.099: drawing failure for widget 
'GtkWindow': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.115: drawing failure for widget 
'GtkDrawingArea': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.115: drawing failure for widget 
'GtkBox': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.115: drawing failure for widget 
'GtkWindow': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.131: drawing failure for widget 
'GtkDrawingArea': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.132: drawing failure for widget 
'GtkBox': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.132: drawing failure for widget 
'GtkWindow': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.148: drawing failure for widget 
'GtkDrawingArea': invalid value for stride

(fuse-gtk:20377): Gtk-WARNING **: 23:28:57.148: drawing failure for widget 
'GtkBox': invalid value for stride


This version of fuse-gtk running on this machine worked OK earlier
today.  I do not know what changed.  I didn't change any settings
AFAIK.  The behaviour seems unaffected by any choice of command-line
options.

Also fuse-sdl works OK (but its window is tiny).

I'm using a tiling window manager (i3) on a 3840x1600 display.   If I
enlarge the neighbouring window to increase the size of the (only)
other window by about 50%, the "fuse" window gets smaller (of course)
but then the usual display of the Spectrum's sceen appears!

Changing the width of the window seems to have no effect either way,
but the largest height it seems to work at is about 1134 pixels; if I
enlarge it above that the Spectrum display goes away again.

So it seems to me as if the the problem is that it doesn't like a tall
window (or perhaps it interacts adversely with the i3 window manager
in a way affected by window height).

-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-12-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fuse-emulator-gtk depends on:
ii  fuse-emulator-common  1.5.7+dfsg1-2~deb10u1
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libpangocairo-1.0-0   1.42.4-8~deb10u1
ii  libpng16-16   1.6.36-6
ii  libsdl1.2debian   1.2.15+dfsg2-4
ii  libspectrum8  1.4.4-1
ii  libx11-6  2:1.6.7-1+deb10u1
ii  libxml2   2.9.4+dfsg1-7+deb10u1
ii  zlib1g1:1.2.11.dfsg-1

fuse-emulator-gtk recommends no packages.

fuse-emulator-gtk suggests no packages.

-- no debconf information

Bug#977021: bus errors on armhf running on a 64bit kernel

[Bernd Rinn]

Dear Pierre,

Thanks for digging into it. Indeed the tests check whether unaligned 
memory access works. Unfortunately, that is used in the 
NativeTaggedArray for 64bit primitive types and even ranks, see e.g. 
line 267 in NativeTaggedArray.


As I cannot reproduce the error myself, not even on a machine with 
aarch64 architecture, can you please tell me if the tests pass when you 
apply the attached patch?


Best regards,
Bernd

On 12/13/20 9:51 PM, Pierre Gruet wrote:

Dear Bernd,

I have looked again at the issue we discussed last Friday; as pointed 
out in the companion bug report


 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929530#5

I see an unaligned address is passed to GetXxxArrayRegion() in the 
native part of the code, when running the tests testXxxToByteToXxx, for 
Xxx in {Char, Short, Ing, Long, Float, Double}: this happens when the 
argument targetOfs of the test is not a multiple of the size of Xxx.


I suggest to remove all pairs (i,j) from getOfs() in NativeDataTests 
where j is not zero. I think the pairs (i,0) could remain even when i is 
not zero, but I would remove them as well because the only place, in the 
main source, where copyXxxToByte or copyByteToXxx are used is in 
NativeTaggedArray, and there it never happens that inStart and outStart 
are not multiples of the size of Xxx.


Do you agree or am I missing something? If you think my suggestions are 
correct, I will upload the package with a patch leaving only the pair 
(0,0) in getOfs() in NativeDataTests.


Warm thanks for your help,
Pierre


On Thu, 10 Dec 2020 18:45:37 +0100 Bernd Rinn  wrote:
 > Dear Pierre,
 >
 > No, I've not yet seen this bus error. I can see two changes to my test
 > setup:
 >
 > - JDK 11 instead of JDK 8
 > - 64bit OS instead of 32 bit OS
 >
 > The 64bit platoform is more likely to be the change that uncovers this
 > bug. Which hardware did you get the error on?
 >
 > All the best,
 > Bernd
 >
 > On 12/10/20 5:45 PM, Pierre Gruet wrote:
 > > Control: forwarded -1 br...@ethz.ch
 > >
 > >
 > > Dear Bernd,
 > >
 > > In Debian we have received a bug report you may find below: there 
seems
 > > to be an unaligned memory access in (seemingly) the JNI part of 
sis-base
 > > version 18.09, leading to a failure on the architecture armhf 
running on

 > > a 64bit kernel.
 > >
 > > Have you already met this issue and do you see how it might be fixed?
 > >
 > > Thanks a lot,
 > > Pierre Gruet
 > >
 > >
 > > On Thu, 10 Dec 2020 07:15:24 +0100 Matthias Klose  
wrote:

 > >  > Package: src:libsis-base-java
 > >  > Version: 18.09~pre1+git20180928.45fbd31+dfsg-2
 > >  > Severity: important
 > >  > Tags: sid bullseye
 > >  >
 > >  > building libsis-base-java (or running the jni) leads to a bus 
error,

 > > usually
 > >  > caused by unaligned memory accesses.
 > >  >
 > >  > [...]
 > >  > LC_ALL=C java -Djava.library.path=source/c/.libs -classpath
 > > sis-base-test.jar
 > >  > ch.systemsx.cisd.base.AllTests
 > >  > Application: base
 > >  > Version: UNKNOWN*
 > >  > Java VM: OpenJDK Server VM (v11.0.9.1+1-Debian-1)
 > >  > CPU Architecture: arm
 > >  > OS: Linux (v4.15.0-126-generic)
 > >  > Test class: NativeDataTests
 > >  >
 > >  > Running testFloatToByteNonNativeByteOrderPartialOutputArray
 > >  > Running testIntToByteToInt
 > >  >  Arguments: [0, 0]
 > >  >  Arguments: [0, 1]
 > >  > #
 > >  > # A fatal error has been detected by the Java Runtime Environment:
 > >  > #
 > >  > #  SIGBUS (0x7) at pc=0xf74b1d1c, pid=10186, tid=10187
diff --git a/source/java/ch/systemsx/cisd/base/convert/NativeData.java b/source/java/ch/systemsx/cisd/base/convert/NativeData.java
index f962af5..ec85500 100644
--- a/source/java/ch/systemsx/cisd/base/convert/NativeData.java
+++ b/source/java/ch/systemsx/cisd/base/convert/NativeData.java
@@ -15,8 +15,6 @@ package ch.systemsx.cisd.base.convert;
 
 import java.nio.ByteBuffer;
 
-import ch.systemsx.cisd.base.utilities.NativeLibraryUtilities;
-
 /**
  * This class encapsulates native methods to deal with arrays of numbers, converting from numbers to
  * bytes and bytes to numbers.
@@ -28,26 +26,10 @@ import ch.systemsx.cisd.base.utilities.NativeLibraryUtilities;
  * primitive numbers (int, short, ...)
  * 
  * Variant interfaces convert only a sub-array.
- * 
- * The class has optimized methods using jni-libraries for some common platforms and a pure-java
- * implementation (called javamode if the jni-libraries are not available). If you want to
- * enforce javamode, you need to pass the property nativedata.javamode=true to
- * the JRE.
  */
 public class NativeData
 {
-private static final boolean useNativeLib;
-
-static
-{
-if (Boolean.getBoolean("nativedata.javamode"))
-{
-useNativeLib = false;
-} else
-{
-useNativeLib = NativeLibraryUtilities.loadNativeLibrary("nativedata");
-}
-}
+private static final boolean useNativeLib = false;
 
 /** Size of a short value in bytes. */
 public 

Bug#973670: E236: Font Unifont is not fixed width

[x11sh]

Actually I could reproduce this in GTK Vim too.

Bug#977322: Following advice of cute-field tag for X-DhRuby-Root breaks build

[Russ Allbery]

Russ Allbery  writes:

> Lintian now emits the following pedantic tag for packages using
> X-DhRuby-Root:

Sorry, forgot to mention: you will be able to see this behavior with the
3.17-1 version of remctl that I'm about to upload, and I'm fairly sure
that you'll see the same with 3.16-4, which is currently in the archive.
(I don't think anything will change between those versions.)

-- 
Russ Allbery (r...@debian.org)  

Bug#977324: doesn't run: 'xml.etree.ElementTree.Element' object has no attribute 'getchildren'

[John Scott]

Package: ocrfeeder
Version: 0.8.3-1
Severity: important

Except that I'm on a KDE Plasma system and might be missing some GNOMEy 
libraries,
I can't think of any particularities of my Bullseye system. I just installed
OCRFeeder and right away it says
Traceback (most recent call last):
  File "/usr/bin/ocrfeeder", line 36, in 
studio = Studio()
  File "/usr/lib/python3/dist-packages/ocrfeeder/studio/studioBuilder.py", line 
76, in __init__
self.ocr_engines_manager.makeEnginesFromFolder(user_engines_folder)
  File "/usr/lib/python3/dist-packages/ocrfeeder/feeder/ocrEngines.py", line 
197, in makeEnginesFromFolder
engine = self.getEngineFromXml(xml_file)
  File "/usr/lib/python3/dist-packages/ocrfeeder/feeder/ocrEngines.py", line 
236, in getEngineFromXml
for child in root_node.getchildren():
AttributeError: 'xml.etree.ElementTree.Element' object has no attribute 
'getchildren'

Maybe this was broken by python3-lxml?

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
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 ocrfeeder depends on:
ii  ghostscript   9.52.1~dfsg-1
ii  gir1.2-goocanvas-2.0  2.0.4-1
ii  gir1.2-gtk-3.03.24.23-3
ii  gir1.2-gtkspell3-3.0  3.0.10-1
ii  iso-codes 4.5.0-1
ii  python3   3.9.0-4
ii  python3-enchant   3.0.1-1
ii  python3-gi3.38.0-1+b2
ii  python3-lxml  4.6.2-1
ii  python3-odf   1.4.1-1
ii  python3-pil   8.0.1-1+b1
ii  python3-reportlab 3.5.56-1
ii  python3-sane  2.8.3-5
ii  tesseract-ocr 4.1.1-2+b1

Versions of packages ocrfeeder recommends:
ii  unpaper  6.1-2+b2
ii  yelp 3.38.2-1

ocrfeeder suggests no packages.

-- no debconf information


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

Bug#977325: Include reportbug presubj to prompt for affected package

[Russ Allbery]

Package: lintian
Version: 2.104.0
Severity: wishlist

Given that you want a reference to a package showing the problem on
all Lintian bug reports, based on recent responses, could you consider
including reportbug configuration in the package to prompt for this?  A
presubj file would probably do it.  It would make it easier to remember to
include this in the bug report.

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 lintian depends on:
ii  binutils2.35.1-4
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.39-3
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b6
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.21-8
ii  lzop1.04-2
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#977323: nouveau: The X session is closed, return to login screen

[jpp]

Package: libdrm-nouveau2
Version: 2.4.103-2
Severity: important
File: nouveau

Hello dear Maintainer,

I experienced many times the same problem : The X session is closed with return
to the login screen.
The Xorg.0.log contains indications about a crash in the "nouveau" libraries.

I enclose the Xorg.0.log file.

Regards

JP P

>From lspci :
01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710]
(rev a1)

My system :
Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
Ram 32Go
Some disks ...






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

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

Versions of packages libdrm-nouveau2:amd64 depends on:
ii  libc62.31-5
ii  libdrm2  2.4.103-2

libdrm-nouveau2:amd64 recommends no packages.

libdrm-nouveau2:amd64 suggests no packages.

-- no debconf information
[  3214.672] 
X.Org X Server 1.20.10
X Protocol Version 11, Revision 0
[  3214.672] Build Operating System: Linux 4.19.0-12-amd64 x86_64 Debian
[  3214.672] Current Operating System: Linux k2000 5.9.0-4-amd64 #1 SMP Debian 
5.9.11-1 (2020-11-27) x86_64
[  3214.672] Kernel command line: BOOT_IMAGE=/vmlinuz-5.9.0-4-amd64 
root=UUID=233786b8-87ae-42eb-8c6f-45fc5f2d752c ro quiet
[  3214.672] Build Date: 02 December 2020  10:41:35AM
[  3214.673] xorg-server 2:1.20.10-1 (https://www.debian.org/support) 
[  3214.673] Current version of pixman: 0.36.0
[  3214.673]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  3214.673] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  3214.673] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 13 13:53:27 
2020
[  3214.673] (==) Using config directory: "/etc/X11/xorg.conf.d"
[  3214.673] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  3214.674] (==) No Layout section.  Using the first Screen section.
[  3214.674] (==) No screen section available. Using defaults.
[  3214.674] (**) |-->Screen "Default Screen Section" (0)
[  3214.674] (**) |   |-->Monitor ""
[  3214.675] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  3214.675] (==) Automatically adding devices
[  3214.675] (==) Automatically enabling devices
[  3214.675] (==) Automatically adding GPU devices
[  3214.675] (==) Max clients allowed: 256, resource mask: 0x1f
[  3214.675] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  3214.675]Entry deleted from font path.
[  3214.675] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  3214.675] (==) ModulePath set to "/usr/lib/xorg/modules"
[  3214.675] (**) Extension "Composite" is disabled
[  3214.675] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  3214.675] (II) Loader magic: 0x56226a0bfe40
[  3214.675] (II) Module ABI versions:
[  3214.675]X.Org ANSI C Emulation: 0.4
[  3214.675]X.Org Video Driver: 24.1
[  3214.675]X.Org XInput driver : 24.1
[  3214.675]X.Org Server Extension : 10.0
[  3214.677] (++) using VT number 7

[  3214.677] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[  3214.678] (II) xfree86: Adding drm device (/dev/dri/card0)
[  3214.686] (--) PCI:*(1@0:0:0) 10de:128b:1043:8572 rev 161, Mem @ 
0xde00/16777216, 0xd000/134217728, 0xd800/33554432, I/O @ 
0xe000/128, BIOS @ 0x/131072
[  3214.686] (II) LoadModule: "glx"
[  3214.686] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  3214.688] (II) Module glx: vendor="X.Org Foundation"
[  3214.688]compiled for 1.20.10, module version = 1.0.0
[  3214.688]ABI class: X.Org Server Extension, version 10.0
[  3214.818] (==) Matched modesetting as autoconfigured driver 0
[  3214.818] (==) Matched fbdev as autoconfigured driver 1
[  3214.818] (==) Matched vesa as autoconfigured driver 2
[  3214.818] (==) Assigned the driver to the xf86ConfigLayout
[  3214.818] (II) LoadModule: "modesetting"
[  3214.818] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[  3214.818] (II) Module modesetting: vendor="X.Org Foundation"
[  3214.818]compiled for 1.20.10, module version = 1.20.10
[  3214.818]Module class: X.Org Video Driver
[  3214.818]ABI class: X.Org 

Bug#977322: Following advice of cute-field tag for X-DhRuby-Root breaks build

[Russ Allbery]

Package: lintian
Version: 2.104.0
Severity: normal

Lintian now emits the following pedantic tag for packages using
X-DhRuby-Root:

P: remctl source: cute-field debian/control@ruby-remctl X-DhRuby-Root vs 
X-Dhruby-Root
N:
P: cute-field
N:
N:   The named field uses a free-style form of capitalization, which is
N:   permitted by policy. The alternative offered is probably a more common
N:   variant in the archive.
N:   
N:   Refer to Debian Policy Manual section 5.1 (Syntax of control files)
N:   for details.
N:   
N:   Severity: pedantic
N:   
N:   Check: fields/style

However, following this advice breaks the Ruby package tooling.  The
build products are not copied into the package correctly and the resulting
package is empty.  Apparently the Ruby package tooling requires that
specific capitalization.

This is with gem2deb 1.4.

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 lintian depends on:
ii  binutils2.35.1-4
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.39-3
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b6
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.21-8
ii  lzop1.04-2
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#977318: corrections to description

[proctor]

i would like to make two corrections to this report:

where i wrote
   * What led up to the situation?
   presumably an apt upgrade

this is incorrect. not a apt upgrade issue, but x hanging and a subsequent
reboot (possibly hard reboot -- can't recall at this moment) let up to it.



where i wrote:
[... and i can switch to a non-x terminal and
observe that the machine is reletively unloaded]

this is incorrect. i CAN switch to a terminal, but the x-hang/stuck screen
does not disappear. i can perform commands in the terminal blindly such as
killall firefox-esr
(which does seem to kill firefox, as the audio then stops) but
the hung x-screen remains until a reboot.

---

when the screen seems hung during the login/sddm problem described i AM
able to work in a non-x terminal however, so that part is correct.

apologies for the confusion. i think the x problem and sddm problem are
unlikely to be related anyway, but i include them here just in case, for
completeness.

-- 
.this message has been rot26 encrypted for security reasons.
gpg 0x385E2954CE572CADE8C091C09479B105A6770473

Bug#977321: O: autoconf2.13 -- automatic configure script builder (obsolete version)

[Ben Pfaff]

Package: wnpp
Severity: normal

This package is really obsolete.  It has several bug reports but the
right thing to do is probably to get any packages that use autoconf2.13
updated to use something else.  (Or removed; they are antiques
themselves.)

This package still has about 1000 installs according to
popularity-contest
(https://qa.debian.org/popcon.php?package=autoconf2.13) but only about
100 of them use it regularly, so a lot of those installs are probably
unnecessary.

Bug#977320: linux-image-4.19.0-9-amd64: Enable CONFIG_BACKLIGHT_PWM

[Pablo Bianucci]

Package: src:linux
Version: 4.19.118-2+deb10u1
Severity: normal

Dear Maintainer,

My ASUS Transformer TA102 needs CONFIG_BACKLIGHT_PWM enabled to be able to turn
down the screen backlight.
Reducing the backlight is critical to extend battery life, so I having the
option enabled in the default Debian kernel would lead to improving the battery
life in this computer (and similar ones, I imagine).
I can compile my own kernel, but it would be much nicer if the option were
enabled by default in the distribution kernel, since it does not seem to impact
anything negatively in terms of stability or performance.



-- Package-specific info:
** Version:
Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/eMMC-Root ro fbcon=rotate:1 
quiet

** Not tainted

** Kernel log:
[   10.532244] ath10k_pci :01:00.0: enabling device ( -> 0002)
[   10.535074] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 
reset_mode 0
[   10.580628] hid-multitouch 0003:0B05:183B.0003: input,hiddev1,hidraw2: USB 
HID v1.11 Mouse [ASUS HID Device ASUS HID Device] on usb-:00:14.0-2/input2
[   10.598428] intel_rapl: Found RAPL domain package
[   10.598433] intel_rapl: Found RAPL domain core
[   10.704116] cht-bsw-rt5645 cht-bsw-rt5645: snd-soc-dummy-dai <-> 
media-cpu-dai mapping ok
[   10.704186] cht-bsw-rt5645 cht-bsw-rt5645: snd-soc-dummy-dai <-> 
deepbuffer-cpu-dai mapping ok
[   10.704516] cht-bsw-rt5645 cht-bsw-rt5645: rt5645-aif1 <-> ssp2-port mapping 
ok
[   10.726155] intel_atomisp2_pm :00:03.0: Refused to change power state, 
currently in D3
[   10.788126] input: chtrt5645 Headset as 
/devices/pci:00/808622A8:00/cht-bsw-rt5645/sound/card0/input30
[   10.808751] pci_bus :01: Allocating resources
[   10.808775] pcieport :00:1c.0: bridge window [io  0x1000-0x0fff] to [bus 
01] add_size 1000
[   10.808782] pcieport :00:1c.0: bridge window [mem 0x0010-0x000f 
64bit pref] to [bus 01] add_size 20 add_align 10
[   10.808817] pcieport :00:1c.0: BAR 15: assigned [mem 
0x9100-0x911f 64bit pref]
[   10.808825] pcieport :00:1c.0: BAR 13: assigned [io  0x1000-0x1fff]
[   10.810199] pci :00:03.0: [8086:22b8] type 00 class 0x048000
[   10.810229] pci :00:03.0: reg 0x10: [mem 0x-0x003f]
[   10.810640] pci :00:03.0: BAR 0: assigned [mem 0x91c0-0x91ff]
[   10.821566] pci_bus :01: Allocating resources
[   10.884827] ath10k_pci :01:00.0: firmware: failed to load 
ath10k/pre-cal-pci-:01:00.0.bin (-2)
[   10.884991] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   10.885179] ath10k_pci :01:00.0: firmware: failed to load 
ath10k/cal-pci-:01:00.0.bin (-2)
[   10.901914] ath10k_pci :01:00.0: firmware: direct-loading firmware 
ath10k/QCA9377/hw1.0/firmware-6.bin
[   10.901933] ath10k_pci :01:00.0: qca9377 hw1.1 target 0x05020001 chip_id 
0x003821ff sub 1a3b:2a51
[   10.901937] ath10k_pci :01:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 
0 testmode 0
[   10.903147] ath10k_pci :01:00.0: firmware ver 
WLAN.TF.2.1-00021-QCARMSWP-1 api 6 features wowlan,ignore-otp crc32 42e41877
[   11.071391] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   11.087072] ath10k_pci :01:00.0: firmware: direct-loading firmware 
ath10k/QCA9377/hw1.0/board-2.bin
[   11.087637] ath10k_pci :01:00.0: board_file api 2 bmi_id N/A crc32 
8aedfa4a
[   11.364547] Bluetooth: Core ver 2.22
[   11.364593] NET: Registered protocol family 31
[   11.364595] Bluetooth: HCI device and connection manager initialized
[   11.364854] Bluetooth: HCI socket layer initialized
[   11.364860] Bluetooth: L2CAP socket layer initialized
[   11.364876] Bluetooth: SCO socket layer initialized
[   11.422382] usbcore: registered new interface driver btusb
[   11.433376] bluetooth hci0: firmware: direct-loading firmware 
qca/rampatch_usb_0302.bin
[   11.433389] Bluetooth: hci0: using rampatch file: 
qca/rampatch_usb_0302.bin
[   11.433393] Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware 
rome 0x302 build 0x111
[   11.511886] bluetooth hci0: firmware: direct-loading firmware 
qca/nvm_usb_0302.bin
[   11.511900] Bluetooth: hci0: using NVM file: qca/nvm_usb_0302.bin
[   12.058694] ath10k_pci :01:00.0: Unknown eventid: 118809
[   12.061615] ath10k_pci :01:00.0: Unknown eventid: 90118
[   12.062818] ath10k_pci :01:00.0: htt-ver 3.56 wmi-op 4 htt-op 3 cal otp 
max-sta 32 raw 0 hwcrypto 1
[   12.069593] ath: EEPROM regdomain: 0x6a
[   12.069601] ath: EEPROM indicates we should expect a direct regpair map
[   12.069611] ath: Country alpha2 being used: 00
[   12.069615] ath: Regpair used: 0x6a
[   12.128438] ath10k_pci :01:00.0 wlp1s0: renamed from wlan0
[   12.323737] Adding 4118524k swap on /dev/mmcblk0p7.  

Bug#977319: slurm-wlm: reproducible builds: Binaries contain embedded paths from usrmerge systems

[Vagrant Cascadian]

Source: slurm-wlm
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Several binaries shipped with slurm-wlm include embedded paths to the
"su" and "sleep" commands:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/slurm-wlm.html

  200 Could·not·locate·command:·/bin/su
  201 Could·not·locate·command:·/usr/bin/su

The attached patch fixes this in debian/rules by passing variables to
the configure script that specify using the locations in /bin, as this
is the most compatible path.


Thanks for maintaining slurm-wlm!


live well,
  vagrant
From 9358f54ddf5c36f9c83a056464a58455191a6686 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 13 Dec 2020 22:15:20 +
Subject: [PATCH] debian/rules: Pass SUCMD and SLEEP_CMD to configure.

The path to "su" and "sleep" are embedded in the binaries, which may
be /bin/CMD or /usr/bin/CMD depending on if the running system is a
usrmerge system or not. Consistently use /bin/CMD as this is the most
compatible path.

https://tests.reproducible-builds.org/debian/issues/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index b84d25ab..90060bf0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -26,8 +26,8 @@ override_dh_auto_clean:
 # hardening-no-fortify-functions
 # Notice that -g in CFLAGS is still provided by dpkg-buildflags
 override_dh_auto_configure:
-	dh_auto_configure -- --sysconfdir=/etc/slurm --with-munge --enable-pam --without-rpath --disable-debug --enable-multiple-slurmd --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 $(ENABLEDEPRECATED)
-	dh_auto_configure --builddirectory build-emulator -- -sysconfdir=/etc/slurm --with-munge --enable-pam --without-rpath --disable-debug --enable-front-end --enable-multiple-slurmd --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 $(ENABLEDEPRECATED)
+	dh_auto_configure -- --sysconfdir=/etc/slurm --with-munge --enable-pam --without-rpath --disable-debug --enable-multiple-slurmd --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 $(ENABLEDEPRECATED) SUCMD=/bin/su SLEEP_CMD=/bin/sleep
+	dh_auto_configure --builddirectory build-emulator -- -sysconfdir=/etc/slurm --with-munge --enable-pam --without-rpath --disable-debug --enable-front-end --enable-multiple-slurmd --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 $(ENABLEDEPRECATED) SUCMD=/bin/su SLEEP_CMD=/bin/sleep
 override_dh_auto_build:
 	dh_auto_build
 	dh_auto_build --builddirectory build-emulator
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#971713: sysstat: init or systemd file has overlapping runlevels

[Trek]

On Sun, 13 Dec 2020 11:03:57 +0100
Robert Luberda  wrote:

> sysstat's init.d has the following lines in /etc/init.d/sysstat
> # Default-Start: 2 3 4 5
> # Default-Stop:
> I'm not sure how empty Default-Stop is interpreted, so I've just tried

it seems to me that on empty Default-Stop the runlevels will be copied
from Default-Start, but this is not an issue, just to better understand


> to change it to:
> # Default-Stop: 0 1 6

this seems correct


> As a result insserv displays two warnings instead of one:

before explaining the error messages, remember that init scripts and
their links are configuration files, like (almost) everything else
under /etc


> insserv: warning: current stop runlevel(s) (empty) of script `sysstat'
> overrides LSB defaults (0 1 6).

it is saying that the current stop runlevels (the /etc/rc*.d/*sysstat
links) are overriding the ones described by the LSB header (inside
the /etc/init.d/sysstat script)


> insserv: Script ssh has overlapping Default-Start and Default-Stop
> runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.

the end result is that the rc*.d links are unchanged and the runlevels
still inconsistent


> As a maintainer of sysstat I have no idea what else I can do to fix
> the warning. It seems to me there is some bug in insserv. As the bug
> affects my package, and  according to the bug report "any package
> that has init.d file", I'm setting severity of this report to grave.

on new installations, simply adding the correct levels (0 1 6) to the
script should fix the bug, but to fix on upgrades you should remove
those links before running insserv, that is adding something like that
to postinst inside the configure step:

  # new Default-Stop (see #971713)
  if dpkg --compare-versions "$2" le '12.4.0-2'; then
 update-rc.d -f sysstat remove
  fi

this will also remove any tweaking done by user, that should be
annotated inside the NEWS.Debian file

I would like to provide you a patch, but I can't find where the init.d
file is enabled inside the sysstat postinst, that should be:

  update-rc.d sysstat defaults

ciao!

Bug#977312: [RFS] ivar 1.3+dfsg-1

[tony mancill]

On Sun, Dec 13, 2020 at 11:25:00PM +0100, Étienne Mollier wrote:
> Control: tag -1 pending
> 
> Greetings,
> 
> Thanks for the notice Paul, it turned out the build time test
> failed at random on amd64 as well as i386 with same symptoms.  I
> suspect several test components were attempting to access the
> same data set, or something of that taste.  When I ran the suite
> using dh_auto_test --no-parallel, I haven't been able to
> reproduce the issue seen on i386 build (nor amd64).
> 
> To Debian Med fellows, routine-update caught ivar 1.3 in the
> process; it is available for review and upload hopefully (and DM
> grant if you think relevant):
> 
>   https://salsa.debian.org/med-team/ivar/

Hi Étienne,

I am able to find your public GPG key, but I don't see it in
debian-keyring for the DM grant.  Please let me know what I'm missing
here.

In the meantime, I have uploaded the package.

Thank you for the update!
tony


signature.asc
Description: PGP signature

Bug#976134: vorta: flaky autopkgtest

[Nicholas D Steeves]

Control: tag -1 confirmed

Hi Graham,

Thank you for this bug report.  Reply follows inline:

On Mon, Nov 30, 2020 at 09:11:29AM +0200, Graham Inggs wrote:
> Source: vorta
> Version: 0.7.1-2
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky
> 
> Hi Maintainer
> 
> The autopkgtests of vorta are failing often.  Two of the failures
> [1][2] seem to be a time out, but there may be other problems as well.
> I've copied what I hope is the relevant part of these logs below.
> 
> Regards
> Graham
> 
> 
> [1] 
> https://ci.debian.net/data/autopkgtest/testing/arm64/v/vorta/8520699/log.gz
> [2] https://ci.debian.net/data/autopkgtest/testing/i386/v/vorta/8521042/log.gz
>
[snip much appreciated bts]

I'm speculating that ppc64el might also be affected due to
https://bugs.debian.org/977114 (mariadb via python-peewee), but I
haven't yet sat down to analyse the problem so at this point that's
just a guess.

Ubuntu has a patch that increases a timeout value (sadly not forwarded
back upstream to us), and it might be necessary to increase other
self-test timeouts--waiting longer is sometimes all it takes for a test
to succeed.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#973848: chromium: Unsupported version, many security bugs unfixed

[David Worsham]

 Hi there,

Thank you for all of the great work on this so far!

I'm interested in helping with this effort, and very familiar with C++ code
and processes in Google code (though not specifically Chromium).  I have
gotten the 83/84 versions in unstable/experimental building locally in a
container as a sanity check.  I also have a fork on salsa to work from
now:  https://salsa.debian.org/arbreng/chromium

However, I am very new to Debian packaging and so not sure what the "ideal"
workspace setup and workflow is for this kind of work.  I just kinda made
things up as I went along yesterday.  If one of ya'll could walk me through
it that would be greatly appreciated - I only know what I learned from
the debian Wiki.  I know how to build and hack on Chromium itself -- it's
just the packaging bits that are still a bit mystifying to me.

Thanks again for all the effort!

On Sat, 12 Dec 2020 19:47:32 +0100 Michel Le Bihan 
wrote:
> Hello,
>
> Thank you for your reply. libvpx got updated in Debian, but I can't use
> it because it's missing a lib. I also had issues with harfbuzz, so I'm
> using bundled versions of those libs as you are. I also used your ozone
> patch because it is match cleaner than mine. With that I was able to
> build Chromium, but with many lint errors and many missing patches.
>
> BTW, have you tried opening a bug upstream or submitting your ozone
> patch upstream?
>
> Michel Le Bihan
>
> On Wed, 9 Dec 2020 04:34:39 + Jeff Blake  wrote:
> > On Tue, 08 Dec 2020 12:33:57 +0100 Michel Le Bihan 
wrote:
> > > Hello,
> > >
> > > I started work on updating the chromium package (you can see my work
> > > here:
> > >
https://salsa.debian.org/mimi8/chromium/-/commit/af70b14701aaf6bdb34e23af01657676e27ba5d4
>

> > ), but got stuck because `libvpx` is too old in Debian testing. It
> > > needs to be updated before I can continue work.
> > >
> > > Michel Le Bihan
> > >
> > >
> > >
> >
> > I've managed to successfully update the ungoogled-chromium debian
package [1], which is based upon
> > the official debian package.
> >
> > Until libvpx is updated (or a new release is made) you could use
Chromium's bundled version of libvpx [2].
> >
> > Feel free to have a look around my repo, as you might well encounter
some of the same problems that
> > I had in getting things to build.
> >
> >
> > Jeff Blake 
> >
> >
> > [1]
https://github.com/berkley4/ungoogled-chromium-debian/commits/87.0.4280.88
>

>
> > [2]
https://github.com/berkley4/ungoogled-chromium-debian/commit/05ffc529e685817aac8a9c5bb419daba17204a66
>

>
> >
> >
>
>
>
>

Bug#977318: xdg-user-dirs: cannot log in if permissions wrong on file .config/user-dirs.dirs

[proctor]

Package: xdg-user-dirs
Version: 0.17-2
Severity: important
X-Debbugs-Cc: damonswir...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   presumably an apt upgrade

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 set permissions on file .config/user-dirs.dirs 0700 and owned by
 myself

   * What was the outcome of this action?
   able to log in again as normal

   * What outcome did you expect instead?
   able to log in without changing automatically set permisisons

*** End of the template - remove these template lines ***

more details:
=
after what seemed like a hung xserver (nouveau) while watching a video a
reboot was performed.
after this reboot was unable to log in as my normal user. however after
some experimentation i found that if i made a new user i was able to log
in as before with this new user (but still not with the old/normal user).
this gave me reason to investigate the user config files
and eventually i narrowed it down to the file .config/user-dirs.dirs --
if it was present in the old/normal account i could not log in. i then 
realized that the
permissions on that file were different (now owned by root) than the 
permissions in the new user
account that i had made (owned by new user). once i changed the permissions in 
the old
account to be owned by that user the problem disappeared and i was able 
to log in properly again.

i am guessing that at some point the program 'xdg-user-dirs-update'
modified the permissions perhaps, because the top of the .config/user-dirs.dirs 
file says:
# This file is written by xdg-user-dirs-update

there was no relevant debugging info that i could find in dmesg, syslog,
or journalctl. only related messages seemed to point to pam closing the
session for no reason.

one last bit of perhaps relevant info: for some time before this issue,
two things have been happening on this machine that are odd and
noteworthy. one is the aforementioned xserver hang. this seems to happen
when watching youtube videos. the computer continues to work, but the
mouse pointer slows down rapidly until it won't move any longer. the audio
continues in the video however, and i can switch to a non-x terminal and
observe that the machine is reletively unloaded.

the second odd piece of info is that also for some time (2 weeks
estimate) when logging in with the regular user or with a newly created
one, if the wrong password is input, sddm and/or lightdm quickly reshows
the login screen. however if the correct password is input the session
hangs for what looks like exactly 2 minutes, before displaying the
desktop session. during this time i am able to switch to a terminal and
use the computer without x.

hope some of this helps!


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xdg-user-dirs depends on:
ii  libc6  2.31-5

xdg-user-dirs recommends no packages.

xdg-user-dirs suggests no packages.

-- no debconf information

Bug#975863: Merge request

[Anton Gladky]

Dear maintainers,

MR is here [1]. Please consider to accept it.

[1] https://salsa.debian.org/puppet-team/leatherman/-/merge_requests/2

Best Regards

Anton

Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker

[Luca Boccassi]

Control: owner -1 Luca Boccassi 

On Mon, 28 Oct 2019 10:17:36 + Luca Boccassi  wrote:
> On Sun, 2019-10-27 at 19:49 -0600, Daniele Nicolodi wrote:
> > On 25/10/2019 14:31, Luca Boccassi wrote:
> > > Any update on dbus-broker? If you are looking for a sponsor, I am
> > > willing to help.
> > 
> > Hello Luca,
> > 
> > my work on dbus-broker stalled a while ago. The package is functional
> > but there was consensus that adding it to the archive required major
> > restructuring of how systemd user instance services are activated,
> > requiring patches for init-system-helpers and debhelper.
> > Unfortunately
> > it took me 4 months to have those patches reviewed. After that I
> > didn't
> > have time to dedicate to this little project.
> > 
> > To bring dbus-broker into the archive it is at least necessary to
> > update
> > the package to the latest upstream release, update the package to
> > make
> > use of the added functionality in debhelper (dh_installsystemduser).
> > That's probably not very difficult to do.
> > 
> > In the long run, it would probably be necessary to coordinate with
> > the
> > dbus maintainers on the best way forward for splitting the dbus
> > package
> > into smaller pieces so that dbus-broker would not have to
> > (transitively)
> > depend on dbus-deamon.
> > 
> > I am still interested in working on this but I don't have much free
> > time
> > at the moment and I prefer to work on more rewarding things. Seeing
> > that
> > there is some interest in seeing dbus-broker in Debian may be enough
> > of
> > an incentive to work again on this, but I cannot promise anything.
> > 
> > The current status of the package is here:
> > 
> > https://salsa.debian.org/dnn-guest/dbus-broker
> > 
> > 
> > Cheers,
> > Dan
> 
> Thank you for your work on this!
> 
> Is it supported to have the system bus handled by -broker and sessions
> buses handled by -daemon? If it is, we could start with what's already
> working, and only upload to ustable (blocking migration to bullseye)
> with system bus support, and dependency on -daemon for the tools. And
> then iterate from there.
> What do you think?

Hi,

I have updated the package and done several changes, and unless there
are objections I intend to upload to experimental/NEW in a couple of
days. I'll start by grabbing the ITP. Repository:

https://salsa.debian.org/bluca/dbus-broker

I've also done some work on src:dbus to split out config and tools,
like it's done in Fedora/RHEL and Yocto. MR on Salsa:

https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8


Thanks for starting the work on this! I'm of course very happy to work
together and be both uploaders if you'd like to work on this as well
going forward. Just let me know and I'll list you and add you to the
shared repository once it's created.

CC'ing Simon for the src:dbus bits.

-- 
Kind regards,
Luca Boccassi


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

Bug#972181: possible-gpl-code-linked-with-openssl tag/test can be retired

[Michael Biebl]

On Tue, 13 Oct 2020 23:08:44 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= 
 wrote:
> On Tue, Oct 13, 2020 at 01:56:40PM -0700, Felix Lechner wrote:
> > Hi Moritz,
> > 
> > On Tue, Oct 13, 2020 at 1:33 PM Moritz Muehlenhoff  wrote:
> > >
> > > FTP masters are now treating OpenSSL as a system library, which makes
> > > it GPL compatible
> > 
> > According to the OpenSSL website, the new license applies from 3.0.0
> > onward [1], but unstable still ships 1.1.1h (with 3.0.0 in
> > experimental). You probably waited five years for this, but is this
> > removal request still a tiny bit premature?
> > 
> > [1] https://www.openssl.org/source/license.html
> 
> The decision by FTP masters is totally independent of the license change
> for OpenSSL 3.0. In fact the same policy has been applied by Red Hat/Fedora 
> basically
> since forever, see 
> http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html

See also https://salsa.debian.org/ftp-team/website/-/merge_requests/6

The ftp-team removed the relevant OpenSSL section from their REJECT
criteria website.

Regards,
Michael


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

Bug#977312: [RFS] ivar 1.3+dfsg-1

[Étienne Mollier]

Control: tag -1 pending

Greetings,

Thanks for the notice Paul, it turned out the build time test
failed at random on amd64 as well as i386 with same symptoms.  I
suspect several test components were attempting to access the
same data set, or something of that taste.  When I ran the suite
using dh_auto_test --no-parallel, I haven't been able to
reproduce the issue seen on i386 build (nor amd64).

To Debian Med fellows, routine-update caught ivar 1.3 in the
process; it is available for review and upload hopefully (and DM
grant if you think relevant):

https://salsa.debian.org/med-team/ivar/

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#972437: debian-reference: mentions no longer existing packages

[Osamu Aoki]

Doesn't this give impression that these packages are supported well?
I usually drop such packages from listing

On Fri, 2020-11-13 at 16:44 +0800, xiao sheng wen (肖盛文) wrote:
> tags -1 + fixed pending
> 
> 
> I'd committed the patch in git repo use the attachment patch.
> 
> This patch add the package info come from oldstable and stable.
> 
> Debian-reference will get the package info from oldstable, stable,
> sid now.
> 
> 在 2020/10/21 下午5:36, Holger Wansing 写道:
> > We talk about experienced users here, but if such users are unable
> > to find old versions of the debian-reference in the archive, they 
> > should
> > better not mix up stable and oldstable (and therefore risk to break
> > the next dist-upgrade and similar), since they are *not*
> > experienced users, 
> > but - ok, I will stop that here.
> > 
> > Holger 
> > 

Bug#968504: RFS: aqemu/0.9.2-3 [NMU] [RC] -- Qt5 front-end for QEMU and KVM

[Alexis Murzeau]

Control: tags -1 -moreinfo

Dear mentors,

Doing a classic RFS mail now if anyone can review this :)

I am looking for a sponsor for a QA upload of "aqemu" to fix this RC bug:
  #957003 - aqemu: ftbfs with GCC-10 [0]

And these additional bugs:
  #966261 - please drop `qemu' from Depends [1]
  #874050 - aqemu depends on meta-package qemu, which pulls in all supported 
emulation architectures [2]


I've checked that it actually runs fine and that I'm able to create a VM and 
run it.

I encountered crashes which I've patches and forwarded all existing and new 
patches to upstream.

About the 3 left Debian bugs, I think these are upstream bugs.
Actually, upstream seems mostly inactive since 2016 with just PR merges earlier 
this year.
At least with what I've done, aqemu should still work fine and be used in 
Bullseye.


 * Package name: aqemu
   Version : 0.9.2-3
   Upstream Author : Andrey Rijov, Tobias Gläßer
 * URL : https://sourceforge.net/projects/aqemu/,
 https://github.com/tobimensch/aqemu
 * License : GPL-2+, BSD-3-clause
   Section : x11

It builds those binary packages:

  aqemu - Qt5 front-end for QEMU and KVM

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/aqemu


Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/a/aqemu/aqemu_0.9.2-3.dsc

Changes since the last upload to unstable:
aqemu (0.9.2-3) unstable; urgency=medium

  * QA upload.
  * debian/patches:
- Fix build with GCC 10 (Closes: #957003).
- Docs: fix groff warning about empty line.
- Fix spelling of some words.
- Merge Debian-specific desktop file into upstream's one and move
  icons to share/icons.
- Forward all patches to upstream.
  * debian/control:
- Replace qemu dummy package dependency to qemu system packages
  (Closes: 966261, 874050).
- Bumped Standards-Version to 4.5.1 and debhelper compat to 13.
- Put package in Debian QA Group now that it is orphaned.
- Remove trailing spaces.
- add Rules-Requires-Root: no as the build doesn't require root.
  * debian/copyright:
- Use secure uri (https) for Format field.
  * debian/changelog:
- Remove trailing whitespaces.
  * debian/rules:
- Add hardening option.
- Remove build dir from aqemu binary.
  * debian/watch:
- Update to version 4.
  * Add upstream/metadata file.

 -- Alexis Murzeau   Sat, 05 Dec 2020 22:45:24 +0100


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957003
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966261
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874050

Regards,

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



signature.asc
Description: OpenPGP digital signature

Bug#974684: Incorrect dependency in python3-lxml

[Christian Kastner]

Hi Andreas,

On 20.11.20 19:27, Andreas Tille wrote:
>> The amd64 binaries uploaded to buster-backports by Andreas Tille (cc'd)
>> seem to have been built in a stretch environment? Other architectures'
>> builds from the buildds seem to be as expected.
> 
> Argh!
>  
>> https://packages.debian.org/buster-backports/python3-lxml says:
>>
>> dep: python3 (<< 3.6) [amd64]
>> dep: python3 (<< 3.8) [not amd64]
>> dep: python3 (>= 3.5~) [amd64]
>> dep: python3 (>= 3.7~) [not amd64]
>>
>> If backports packages can be binNMU'd, please could someone with
>> appropriate access rebuild this? I think the right runes are:
>>
>> nmu python3-lxml_4.6.1-1~bpo10+1 . amd64 . buster-backports . -m 'Rebuild in 
>> buster environment'
>>
>> Or if binNMUs are not possible in buster-backports, someone who uses
>> and can test this backported package could do a source-only upload.
> 
> If it helps I can do a source-only upload for sure.

could you take another look at this?

There was just a DSA for lxml (DSA-4810-1) and for those that have
backports pinned, the above issue blocks the security update to
python3-lxml (because the uninstallable backported version has a greater
version).

There's a new version in testing, 4.6.2, so backporting that one might
even be the simplest fix to the process.

Best,
Christian

Bug#973797: doc-base: package dicomscope-doc is required but not available in testing

[Robert Luberda]

Michael Becker pisze:
> Package: doc-base
> Version: 0.10.9
> Severity: normal
> 
> doc-base can't be installed on testing because it requires file 
> /usr/share/doc-base/dicomscope-doc-dscs from package dicomscope-doc, which is 
> not available on testing
> 

Hi,

It would be helpful if you could be more specific, for example by
including output that you saw on screen. Anyway, I've just managed to
reproduce the bug. I've installed old version of dicomscope-doc (i.e.
3.6.0-20). Now, when trying to upgrade it to the latest version
(3.6.0-22) doc-base fails with:


Setting up doc-base (0.10.9) ...
Processing 2 added doc-base files...
Cannot open file `/usr/share/doc-base/dicomscope-doc-dscs' for reading:
No such file or directory.
dpkg: error processing package doc-base (--configure):
 installed doc-base package post-installation script subprocess returned
error exit status 3
Setting up libsndio6.1:amd64 (1.1.0-3) ...
Processing triggers for libc-bin (2.31-5) ...
Errors were encountered while processing:
 doc-base


I'll fix in next upload. As a work-around, running 'install-docs -I'
command manually helps.

Regards,
robert

Bug#977317: O: fmtools -- FM radio tuner

[Ben Pfaff]

Package: wnpp
Severity: normal

This package has two bugs.  One might be obsolete (it was reported
against an old kernel and might not even be valid) and the other is a
feature request that includes a patch, that might be worth applying.
This package has about 80 users according to popularity-contest
(https://qa.debian.org/popcon.php?package=fmtools).  I'm orphaning it
because I am no longer spending much time on Debian.

Bug#977269: [Pkg-javascript-devel] Bug#977269: Bug#977269: node-rollup-plugin-terser seems incompatible with current node-terser

[Jonas Smedegaard]

Quoting Xavier (2020-12-13 22:00:53)
> Le 13/12/2020 à 20:53, Jonas Smedegaard a écrit :
> > Control: severity 977269 important
> > Control: tags 977269 +moreinfo +unreproducible
> > 
> > Quoting Jonas Smedegaard (2020-12-13 20:29:46)
> >> Quoting Jonas Smedegaard (2020-12-13 17:22:05)
> >>> Quoting Xavier Guimard (2020-12-13 13:19:47)
>  Package: node-rollup-plugin-terser
>  Version: 7.0.2-2
>  Severity: grave
>  Justification: renders package unusable
> 
>  When trying current rollup-plugin-terser (7.0.2)  with current
>  node-terser (4.1.2), package is unuseable:
> 
>  $ rollup -c
> 
>  index.js → dist/pako.js, dist/pako.min.js...
>  [!] (plugin terser) Error: Cannot find module 
>  '/home/xavier/dev/debian/src/pkg-js/packages/node-pako/node_modules/terser/dist/bundle.min.js'.
>   Please verify that the package.json has a valid "main" entry

> index.js → dist/pako.js, dist/pako.min.js...
> minify(...).then is not a function

"Cannot find module" and "minify(...).then is not a function" are 
clearly differen issues.  But ok, if the latter is the issue being 
tracked with this report then I am confident it is solved with the 
package in incoming.

Please do close this bugreport when you confirm that is the case.

 - Jonas

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

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

signature.asc
Description: signature

Bug#977316: selinux-policy-default of Debian 10.7.0 gives 52 denials with minimal install

[Debian bugs <-> IOPEN]

Package: selinux-policy-default
Version: 2:2.20190201-2

Using debian-10.7.0-amd64-netinst.iso we installed minimal + SSH server
+ standard system utilities.

Kernel: 4.19.0-13-amd64

Upon first boot of the installed system we stopped and disabled apparmor.

Then we performed the steps in this :

> https://wiki.debian.org/SELinux/Setup

When the system rebooted following the relabelling we executed
audit2why -al  and found 52 denials.

We expected zero denials. We expect the problem to occur with any such
installation.

The output of "audit2why -al" is attached, because the long lines make
the pasted version very messy.

Regards,
The IOPEN Team


type=AVC msg=audit(1607611437.896:7): avc:  denied  { getattr } for  pid=346 
comm="mkdir" path="/run/console-setup" dev="tmpfs" ino=11449 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611437.896:8): avc:  denied  { create } for  pid=295 
comm="cached_setup_fo" name="font-loaded" 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611437.896:8): avc:  denied  { add_name } for  pid=295 
comm="cached_setup_fo" name="font-loaded" 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611437.896:8): avc:  denied  { write } for  pid=295 
comm="cached_setup_fo" name="console-setup" dev="tmpfs" ino=11449 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611438.920:15): avc:  denied  { read } for  pid=229 
comm="systemd-timesyn" name="dbus" dev="tmpfs" ino=12202 
scontext=system_u:system_r:ntpd_t:s0 
tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611438.920:16): avc:  denied  { read } for  pid=229 
comm="systemd-timesyn" name="system_bus_socket" dev="tmpfs" ino=12205 
scontext=system_u:system_r:ntpd_t:s0 
tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file 
permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:34): avc:  denied  { add_name } for  pid=399 
comm="login" name="motd.dynamic" 
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:34): avc:  denied  { rename } for  pid=399 
comm="login" name="motd.dynamic.new" dev="tmpfs" ino=13733 
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:34): avc:  denied  { remove_name } for  
pid=399 comm="login" name="motd.dynamic.new" dev="tmpfs" ino=13733 
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:34): avc:  denied  { write } for  pid=399 
comm="login" name="/" dev="tmpfs" ino=1128 
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:35): avc:  

Bug#976811: transition: php8.0

[David Prévot]

Hi,

Le Fri, Dec 11, 2020 at 12:38:01PM -0400, David Prévot a écrit :
> Le Tue, Dec 08, 2020 at 09:28:38AM +0100, Ondřej Surý a écrit :
> 
> > I would like to transition the PHP to version 8.0;
> 
> The timing of this request makes me uneasy […]
> 
> > it's not such a huge bump as it was with 5.6 -> 7.0 and
> 
> [ 7.3 -> 7.4 was not a huge bump but took months to deal with ]

A look at https://php.watch/versions/8.0 (just the size of the page,
compared to https://php.watch/versions/7.4) and a few pages linked from
there helps me disagree to your “not such a huge bump”.

> > most of the packages that were compatible with PHP
> > 7.4 are working just fine with PHP 8.0.
> 
> That does not match my experience as a maintainer of about a hundred
> packages relying on PHP. Many upstream are currently releasing updates
> to fix compatibility with PHP 8.0, and many more have not yet done so.
[…]
> uploading [PHPUnit from experimenatal] to unstable would mean
> having to deal with dozens of breakage (in the FTBFS form):
> 
> https://release.debian.org/britney/pseudo-excuses-experimental.html#phpunit

I spent my weekend on this list, uploaded about twenty packages that can
now at least pass their test suite with PHPUnit 8 or 9, under PHP 7 or
8, so the list is about half the size it was two days ago. I managed to
deal with some (easy) PHP 8 issues, but I’m stuck on a dozen of the
remaining packages: I’ve updated their repository, but didn’t upload
them yet (because it only fixes the PHPUnit issues, not the PHP 8 ones).

My point of view after actually working on those issues is that there is
a significant number of packages that are not working just fine with PHP
8.0, and require a fair amount of work before that. Some of them being
security sensitive, so just working around visible issues may not be of
the best interest of anyone…

> That said, it would be nice to have an updated php-default in
> *experimental* to help have a grasp of the possible breakages.

Thank you for your quick upload! As expected, the number of packages
failing on CI is significant (a lot more than the PHPUnit related ones),
and may I stress that it only shows packages that do run autopkgtests,
so we are probably missing a lot (and it may take some time to catch
them).

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults

I hear the argument about PHP release schedule, but this schedule is not
new (there is a lot we could have done to prepare for such a huge bump
if you had shared your plans in advance), and the PHP 7.2 to 7.3 update
before Buster freeze was really nothing compared to this PHP 7.4 to 8.0
update.

Don’t get me wrong, I love how PHP 8.0 is way faster in my environment,
but I’m really concerned about the compatibility of the code running on
it (not only as Debian packages, but also as installed by our users).

Regards

David


signature.asc
Description: PGP signature

Bug#977315: slurm-wlm: Vcs repository out of date

[Vagrant Cascadian]

Package: slurm-wlm
Severity: minor

The Vcs headers in debian/control appear to be out of date:

  Vcs-Browser: https://salsa.debian.org/hpc-team/slurm-wlm
  Vcs-Git: https://salsa.debian.org/hpc-team/slurm-wlm.git

The newest version available in the master branch is 19.05.5-1, while
the archive contains slurm-wlm 20.02.6-2, with changelog entries for
20.02.6-1 and 19.05.5-2.1.

There *are* tags for 20.02.6-1 and 20.02.6-2, but no branch appears to
reference them, which makes it hard to use with tools like debcheckout.

Please update the Vcs repository or update the Vcs headers in
debian/control to point to the current respository and/or branch.

Thanks for maintaining slurm-wlm!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello Simon and others,

On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote:

> If we are unable to use particular system services (in this case NM) with
> a particular non-default init system without putting extra responsibility
> on the maintainers of those system services, then I think that's a
> limitation of that init system that its maintainers could usefully
> address, and addressing that limitation would certainly be within the
> scope of exploring alternatives to systemd.

This is a good way to understand the notion of "exploring alternatives
to" systemd.  Thank you for explaining it.

I have not yet seen an argument which convinced me that asking the NM
maintainer to keep the init script in the package would actually be
putting extra responsibility on that maintainer, and this concerns me.

Participants in the thread who have argued on that side of the
discussion seem to implicitly rely on the idea that a package maintainer
is responsible for applying an equally high level of quality assurance
to every file or feature in their package, as that which they would
apply to its most basic or flagship features.  For example, it's been
suggested that requiring the NM maintainer to keep the file in the
package would mean that the NM maintainer would need to keep a sysvinit
system around to test that the init script still works before they could
upload a new version of NM.  I don't see why there would be any such
need.

Indeed, I don't think this is how we typically think of the
responsibilities of Debian package maintainers.  We want maintainers to
perform testing which is adequate to ensure that the core features of a
package won't regress if they upload a new version, but we do not take
maintainers to be responsible for testing every optional feature and we
accept that such things might be temporarily broken until someone other
than the maintainer can provide a patch.

In this case, I don't see how keeping the init script in the package
creates any expectations on the NM maintainer beyond applying patches to
the init script from those who have the relevant specialised knowledge.
A good analogy would be ports.  We do not expect maintainers to maintain
an environment to test their package on ports architectures before
uploading, but we do expect them to apply patches provided by porters
who discover regressions.  Why would our expectations be any greater in
this case?

Of course, if the script became seriously broken and was getting in the
way of a release or something like that, we would typically see it as
within the maintainer's prerogative to remove it.  Just as we would
accept a maintainer breaking compatibility with a port by reverting a
porter's patch if that was the only feasible way to meet a freeze
deadline, say.  But as has been pointed out, that's not the case we are
dealing with here.

I would like to see arguments that we would be imposing any extra
responsibility on the NM maintainer which do not rely on the idea that a
package maintainer is equally responsible for regressions anywhere in
their package, or, of course, an argument that I'm misunderstanding
what's being implicitly assumed.

The dependency issue is more challenging.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#977269: [Pkg-javascript-devel] Bug#977269: node-rollup-plugin-terser seems incompatible with current node-terser

[Xavier]

Le 13/12/2020 à 20:53, Jonas Smedegaard a écrit :
> Control: severity 977269 important
> Control: tags 977269 +moreinfo +unreproducible
> 
> Quoting Jonas Smedegaard (2020-12-13 20:29:46)
>> Quoting Jonas Smedegaard (2020-12-13 17:22:05)
>>> Quoting Xavier Guimard (2020-12-13 13:19:47)
 Package: node-rollup-plugin-terser
 Version: 7.0.2-2
 Severity: grave
 Justification: renders package unusable

 When trying current rollup-plugin-terser (7.0.2)  with current
 node-terser (4.1.2), package is unuseable:

 $ rollup -c

 index.js → dist/pako.js, dist/pako.min.js...
 [!] (plugin terser) Error: Cannot find module 
 '/home/xavier/dev/debian/src/pkg-js/packages/node-pako/node_modules/terser/dist/bundle.min.js'.
  Please verify that the package.json has a valid "main" entry
>>>
>>> Neither node-rollup-plugin-terser nor node-terser asks for files below 
>>> /home/xavier - please try locate which code did that.
>>
>> Something _is_ broken with node-rollup-plugin-terser - the provided 
>> error message is just not really helpful for me.
>>
>> I might have a fix for the error I located - we'll see if that turns out 
>> to also cure the issue you are experiencing, but for future sake please 
>> try unwrap any node_modules tricks when reporting bugs, as they hide 
>> ability to trace what is going on where (at least for me - I have no 
>> doubt that you are fluent in your tools).
> 
> If problem persist with node-rollup-plugin-terser 7.0.2-3 then please 
> try isolate a test causing the failure without node_modules wrapping.
> 
> Otherwise please close.
> 
>  - Jonas

Sorry, in my different tests, I didn't post the good logs. Here are the
relevant logs:

$ rollup -c

index.js → dist/pako.js, dist/pako.min.js...
minify(...).then is not a function

[!] (plugin terser) TypeError: minify(...).then is not a function
TypeError: minify(...).then is not a function
at Object.transform
(/usr/share/nodejs/rollup-plugin-terser/transform.js:5:32)
at execFunction
(/usr/share/nodejs/jest-worker/build/workers/processChild.js:135:17)
at execHelper
(/usr/share/nodejs/jest-worker/build/workers/processChild.js:117:5)
at execMethod
(/usr/share/nodejs/jest-worker/build/workers/processChild.js:121:5)
at process.messageListener
(/usr/share/nodejs/jest-worker/build/workers/processChild.js:46:7)
at process.emit (events.js:314:20)
at emit (internal/child_process.js:876:12)
at processTicksAndRejections (internal/process/task_queues.js:85:21)

When replacing /usr/share/nodejs/terser by version 5 (as recommended in
rollup-plugin-terser package.json), everything works fine.

The rollup.config.js has nothing special
(https://github.com/nodeca/pako/blob/master/rollup.config.js)

Bug#977269: [Pkg-javascript-devel] Bug#977269: node-rollup-plugin-terser seems incompatible with current node-terser

[Xavier]

Le 13/12/2020 à 22:00, Xavier a écrit :
> Le 13/12/2020 à 20:53, Jonas Smedegaard a écrit :
>> Control: severity 977269 important
>> Control: tags 977269 +moreinfo +unreproducible
>>
>> Quoting Jonas Smedegaard (2020-12-13 20:29:46)
>>> Quoting Jonas Smedegaard (2020-12-13 17:22:05)
 Quoting Xavier Guimard (2020-12-13 13:19:47)
> Package: node-rollup-plugin-terser
> Version: 7.0.2-2
> Severity: grave
> Justification: renders package unusable
>
> When trying current rollup-plugin-terser (7.0.2)  with current
> node-terser (4.1.2), package is unuseable:
>
> $ rollup -c
>
> index.js → dist/pako.js, dist/pako.min.js...
> [!] (plugin terser) Error: Cannot find module 
> '/home/xavier/dev/debian/src/pkg-js/packages/node-pako/node_modules/terser/dist/bundle.min.js'.
>  Please verify that the package.json has a valid "main" entry

 Neither node-rollup-plugin-terser nor node-terser asks for files below 
 /home/xavier - please try locate which code did that.
>>>
>>> Something _is_ broken with node-rollup-plugin-terser - the provided 
>>> error message is just not really helpful for me.
>>>
>>> I might have a fix for the error I located - we'll see if that turns out 
>>> to also cure the issue you are experiencing, but for future sake please 
>>> try unwrap any node_modules tricks when reporting bugs, as they hide 
>>> ability to trace what is going on where (at least for me - I have no 
>>> doubt that you are fluent in your tools).
>>
>> If problem persist with node-rollup-plugin-terser 7.0.2-3 then please 
>> try isolate a test causing the failure without node_modules wrapping.
>>
>> Otherwise please close.
>>
>>  - Jonas
> 
> Sorry, in my different tests, I didn't post the good logs. Here are the
> relevant logs:
> 
> $ rollup -c
> 
> index.js → dist/pako.js, dist/pako.min.js...
> minify(...).then is not a function
> 
> [!] (plugin terser) TypeError: minify(...).then is not a function
> TypeError: minify(...).then is not a function
> at Object.transform
> (/usr/share/nodejs/rollup-plugin-terser/transform.js:5:32)
> at execFunction
> (/usr/share/nodejs/jest-worker/build/workers/processChild.js:135:17)
> at execHelper
> (/usr/share/nodejs/jest-worker/build/workers/processChild.js:117:5)
> at execMethod
> (/usr/share/nodejs/jest-worker/build/workers/processChild.js:121:5)
> at process.messageListener
> (/usr/share/nodejs/jest-worker/build/workers/processChild.js:46:7)
> at process.emit (events.js:314:20)
> at emit (internal/child_process.js:876:12)
> at processTicksAndRejections (internal/process/task_queues.js:85:21)
> 
> When replacing /usr/share/nodejs/terser by version 5 (as recommended in
> rollup-plugin-terser package.json), everything works fine.
> 
> The rollup.config.js has nothing special
> (https://github.com/nodeca/pako/blob/master/rollup.config.js)

I pushed node-pako "as is" to salsa.d.o if you want to take a look. It
seems that node-pako is the first Debian package which will use
rollup-plugin-terser (looking at reverse dependencies).

Bug#892058: Your Debian key is expiring

[Craig Small]

>
> This is a courtesy reminder that your Debian key is expiring on 2021-02-01.
>
For once in many many years, I have not uploaded something after my key has
expired and wondered why it bounced.

Thanks for the note.

 - Craig

Bug#977314: src:rust-bzip2-sys: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: rust-bzip2-sys
Version: 0.1.7-2
Severity: serious
Control: close -1 0.1.9-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 975480

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-bzip2-sys in its current version in unstable has been trying to
migrate for 60 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 bullseye, 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=rust-bzip2-sys




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977313: src:rust-rpassword: fails to migrate to testing for too long: autopgktest regression

[Paul Gevers]

Source: rust-rpassword
Version: 4.0.5-1
Severity: serious
Control: close -1 5.0.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 975479

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-rpassword in its current version in unstable has been trying to
migrate for 60 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 bullseye, 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=rust-rpassword




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977312: src:ivar: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: ivar
Version: 1.2.2+dfsg-3
Severity: serious
Tags: sid bullseye ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:ivar in its
current version in unstable has been trying to migrate for 61 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.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977021: bus errors on armhf running on a 64bit kernel

[Pierre Gruet]

Dear Bernd,

I have looked again at the issue we discussed last Friday; as pointed 
out in the companion bug report


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929530#5

I see an unaligned address is passed to GetXxxArrayRegion() in the 
native part of the code, when running the tests testXxxToByteToXxx, for 
Xxx in {Char, Short, Ing, Long, Float, Double}: this happens when the 
argument targetOfs of the test is not a multiple of the size of Xxx.


I suggest to remove all pairs (i,j) from getOfs() in NativeDataTests 
where j is not zero. I think the pairs (i,0) could remain even when i is 
not zero, but I would remove them as well because the only place, in the 
main source, where copyXxxToByte or copyByteToXxx are used is in 
NativeTaggedArray, and there it never happens that inStart and outStart 
are not multiples of the size of Xxx.


Do you agree or am I missing something? If you think my suggestions are 
correct, I will upload the package with a patch leaving only the pair 
(0,0) in getOfs() in NativeDataTests.


Warm thanks for your help,
Pierre


On Thu, 10 Dec 2020 18:45:37 +0100 Bernd Rinn  wrote:
> Dear Pierre,
>
> No, I've not yet seen this bus error. I can see two changes to my test
> setup:
>
> - JDK 11 instead of JDK 8
> - 64bit OS instead of 32 bit OS
>
> The 64bit platoform is more likely to be the change that uncovers this
> bug. Which hardware did you get the error on?
>
> All the best,
> Bernd
>
> On 12/10/20 5:45 PM, Pierre Gruet wrote:
> > Control: forwarded -1 br...@ethz.ch
> >
> >
> > Dear Bernd,
> >
> > In Debian we have received a bug report you may find below: there 
seems
> > to be an unaligned memory access in (seemingly) the JNI part of 
sis-base
> > version 18.09, leading to a failure on the architecture armhf 
running on

> > a 64bit kernel.
> >
> > Have you already met this issue and do you see how it might be fixed?
> >
> > Thanks a lot,
> > Pierre Gruet
> >
> >
> > On Thu, 10 Dec 2020 07:15:24 +0100 Matthias Klose  
wrote:

> >  > Package: src:libsis-base-java
> >  > Version: 18.09~pre1+git20180928.45fbd31+dfsg-2
> >  > Severity: important
> >  > Tags: sid bullseye
> >  >
> >  > building libsis-base-java (or running the jni) leads to a bus 
error,

> > usually
> >  > caused by unaligned memory accesses.
> >  >
> >  > [...]
> >  > LC_ALL=C java -Djava.library.path=source/c/.libs -classpath
> > sis-base-test.jar
> >  > ch.systemsx.cisd.base.AllTests
> >  > Application: base
> >  > Version: UNKNOWN*
> >  > Java VM: OpenJDK Server VM (v11.0.9.1+1-Debian-1)
> >  > CPU Architecture: arm
> >  > OS: Linux (v4.15.0-126-generic)
> >  > Test class: NativeDataTests
> >  >
> >  > Running testFloatToByteNonNativeByteOrderPartialOutputArray
> >  > Running testIntToByteToInt
> >  >  Arguments: [0, 0]
> >  >  Arguments: [0, 1]
> >  > #
> >  > # A fatal error has been detected by the Java Runtime Environment:
> >  > #
> >  > #  SIGBUS (0x7) at pc=0xf74b1d1c, pid=10186, tid=10187

Bug#977245: openssh-server: Kernel error after big rsync or scp

[Ben Hutchings]

[Reply to all, not just to me]

On Sun, 2020-12-13 at 20:11 +, Gabe Alvarez wrote:
> I am using the on-board ethernet.
> I've checked the files in /var/log, and none of them contain
> anything referencing the oopses that have happened; neither does
> anything in journalctl. Please advise.

You'll need to capture the kernel log using a serial console

or netconsole
.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ben Hutchings]

On Mon, 2020-12-14 at 05:13 +0900, Ryutaroh Matsumoto wrote:
> > The rpi flavour doesn't have those constraints, though.  What would be
> > the benefit of booting it in UEFI mode?
> 
> Thank you for paying your attention!
> I considered extending autopkgtest-virt-qemu to armel (and other archs) 
> testbeds at
> https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100#note_205984
> 
> To boot a qemu disk image by qemu-system-*, a booting firmware seems
> indispensable, as the autopkgtest maintainer does not like giving 
> -kernel=something
> qemu option as
> https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/97#note_205357

OK, this seems like a good reason.

We used to provide a 'versatile' flavour on armel, for the ARM
Versatile boards that QEMU has supported for a long time.  I removed
this flavour back in 2016 after finding that it had been broken for a
while and no-one had reported it.  Adding that back might be an option,
if the Raspberry Pi device emulation in QEMU is slow.  What do you
think?

> A booting firmware for an armel Debian disk image seems only
> the qemu-efi-arm Debian package (is there anything else??).

The usual practice is to use u-boot or some other board-specific boot
loader, which can be configured by the flash-kernel package.  I don't
think that works in QEMU.

Ben.

> So I resorted to the UEFI booting.
> Currently I proposes to use linux-image-armmp-lpae for armel testbed.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ryutaroh Matsumoto]

> The rpi flavour doesn't have those constraints, though.  What would be
> the benefit of booting it in UEFI mode?

Thank you for paying your attention!
I considered extending autopkgtest-virt-qemu to armel (and other archs) 
testbeds at
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100#note_205984

To boot a qemu disk image by qemu-system-*, a booting firmware seems
indispensable, as the autopkgtest maintainer does not like giving 
-kernel=something
qemu option as
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/97#note_205357

A booting firmware for an armel Debian disk image seems only
the qemu-efi-arm Debian package (is there anything else??).
So I resorted to the UEFI booting.
Currently I proposes to use linux-image-armmp-lpae for armel testbed.

Best regards, Ryutaroh

Bug#977311: node-uglifyjs-webpack-plugin: dead upstream since July 2019

[Jonas Smedegaard]

Package: node-uglifyjs-webpack-plugin
Version: 1.3.0-9
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

node-uglifyjs-webpack-plugin is dead since 1.5 years, already carries a
patch to not actually use node-uglifyjs but node-terser, and terser will
soon see a major backwards-incompatible change that will require even
more custom hacks.

It seems this package has only one reverse dependency (webpack) and two
reverse build-dependencies (node-chai and node-webpack).

Seems it is time to replace this package with its successor,
https://github.com/webpack-contrib/terser-webpack-plugin

Setting severity to serious due to the upcoming breaking change to
node-terser.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/Wee8ACgkQLHwxRsGg
ASEm7A/9Ej+JJvvILoUu8D+AwKDF/JYKYo/UDALjSYVODE81lgpQ8QkuQxsIg/yF
MKJHD/ZhPoO+MPSApY93rJ+Gsoh5N2vDtT1F7RfbI7kqq8iT08NF3cPyBirbF8Rg
ewPUP4gnRQd4bSLOesYzv1w57mESrqd+u7Cw1kPZM9c5S8k1JMTvFwTZjBrNoHu3
nMMgFgkxDO3tHOTy8verRvBfWL7UwfrecBUKTM92SswzBz03j7bj98x17Ra8WtyM
0jihm44SE6urFXJSCRc91Pbse1zG9Pi10GKqiqKKJOZl7hsZ9rGEE68e+GLU8k+L
b2cCco0THSb+1HmlI0xJsVuni6PcO+GeijW2UFuQ7Vn80STrLJ4Ots9GEuKRWbNO
meo9Q1QfcyJxhVs+XfxPTbKEJr5aipgCgCAy/M9bmuL2ltDx4vLUIokMC9NK37ZO
67WxdrOb91bbCVHisntjsRlmqf7ltUZEIx6pvyS42GW5bdBPyzoZYtqqnGWkJyDz
z52DT4Q5FROy/iZRTCyTO+vHAOnMoW7jRYQfPsyrpVn51AF+a439u8FVz6LkNAv+
nnEV1RrZ90/hwNMK4abfIN+ljPsr7LoI+sux1FeDLDerBRvAEo2pr3u9DxiPzYKU
Q1AJcIig0X+CrwwMnrpomy34W6WpQ7Qi4aPJdaAPgD5nms4Z6u0=
=9occ
-END PGP SIGNATURE-

Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information and compared this
situation on real hardware armv5tel with an armv7 and
it looks like in keccak_finalize the following instruction
stores different data to memory depending on the arm hardware:

   0x005c4ac0 :f0 20 c4 e1 strdr2, [r4]

In the failing case this is stored:
(gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a
0xbeffef5c: 0x6f0x6e0x200x630x000x000x000x00

And in the good case this:
(gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a
0xbeffef5c: 0x2e0x6f0x6e0x690x6f0x6e0x200x63

While on both the registers r2 and r3 contain:
r2 0x696e6f2e  1768845102
r3 0x63206e6f  1663069807

In the attached files are some more details leading to the above result.

Kind regards,
Bernhard


(gdb) bt
#0  0x7f719ac4 in xorin8 (len=136, src=, dst=) at 
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:21
#1  keccak_finalize (s=0xbeffef5c) at 
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:189
#2  0x7f71a410 in hash (out=0xbefff1a8 "", outlen=32, in=, 
inlen=48, bits=256, delim=6 '\006') at ../src/ext/keccak-tiny/keccak-tiny-unrolled.c:353
#3  0x7f71a640 in sha3_256 (out=out@entry=0xbefff1a8 "", outlen=outlen@entry=32,
in=in@entry=0xbefff15c ".onion 
checksum\243\356\241Jͩ\036U\313\365\026;Z\"\370\357\016\272\030\251nOU\367\006(S6\177-V",
 inlen=inlen@entry=48)
at ../src/ext/keccak-tiny/keccak-tiny-unrolled.c:389
#4  0x7f6fb5e8 in crypto_digest256 (digest=digest@entry=0xbefff1a8 "", m=m@entry=0xbefff15c 
".onion 
checksum\243\356\241Jͩ\036U\313\365\026;Z\"\370\357\016\272\030\251nOU\367\006(S6\177-V",
len=len@entry=48, algorithm=algorithm@entry=DIGEST_SHA3_256) at 
../src/lib/crypt_ops/crypto_digest.c:153
#5  0x7f651948 in build_hs_checksum (key=key@entry=0x7f837df4, version=version@entry=3 
'\003', checksum_out=checksum_out@entry=0xbefff1a8 "") at 
../src/feature/hs/hs_common.c:748
#6  0x7f6530b0 in hs_build_address (key=key@entry=0x7f837df4, version=, 
addr_out=addr_out@entry=0x7f837da0 "") at ../src/feature/hs/hs_common.c:1001
...

# Buster armel chroot 2020-12-13 on another Buster armel

# uname -a
Linux qnap119 4.19.0-12-marvell #1 Debian 4.19.152-1 (2020-10-18) armv5tel 
GNU/Linux

# cat /proc/cpuinfo 
processor   : 0
model name  : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS: 400.00
Features: swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part: 0x131
CPU revision: 1

Hardware: Marvell Kirkwood (Flattened Device Tree)
Revision: 

# chroot/bin/busybox mount -o rbind /dev  chroot/dev
# chroot/bin/busybox mount -o rbind /proc chroot/proc
# chroot/bin/busybox mount -o rbind /sys  chroot/sys

# cd debian-10-buster-armel-chroot
# env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -

# apt install openssl tor
# dpkg -l tor
...
ii  tor0.3.5.12-1   armelanonymizing overlay network for TCP
# exit

# unshare -n /bin/bash
# env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -l benutzer

$ mkdir hs
$ chmod go-rwx -R hs
$ echo 
'PT0gZWQyNTUxOXYxLXNlY3JldDogdHlwZTAgPT0AAACg6zoxlQ2hy7C6fUoTgIa0GLMk/YdVs2ic6jUDCzztZeLWcfqwCQ5/KoPk9v99cuWKO5mNpVrDtbOc27UUyC7e'
 | base64 -d > hs/hs_ed25519_secret_key

$ echo '6bff2f57fcd69049091dcfa42b08fb84919d60dac919cbb16e3df1d960bb7843  
./hs/hs_ed25519_secret_key' | sha256sum -c
./hs/hs_ed25519_secret_key: OK

$ cat < torrc
HiddenServiceDir /home/benutzer/hs
HiddenServicePort 80 127.0.0.1:8080
EOF

$ /usr/sbin/tor -f torrc Log 'info stdout'
...
^C

$ cat hs/hostname 
upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyac43yd.onion




# apt build-dep tor
# apt install gdb tor-dbgsym

mkdir /home/benutzer/source/tor/orig -p
cd/home/benutzer/source/tor/orig
apt source tor
cd


$ rm hs/hostname 
$ gdb -q --args /usr/sbin/tor -f torrc Log 'info stdout'
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/tor/orig/tor-0.3.5.12/src
(gdb) b build_hs_checksum
(gdb) run

(gdb) print sizeof(*key)
$3 = 32
(gdb) x/32xb key
0x6e2de4:   0xa30xee0xa10x4a0xcd0xa90x1e0x55
0x6e2dec:   0xcb0xf50x160x3b0x5a0x220xf80xef
0x6e2df4:   0x0e0xba0x180xa90x6e0x4f0x550xf7
0x6e2dfc:   0x060x280x530x360x7f0x2d0x560x00

(gdb) next
(gdb) next
(gdb) next
748   crypto_digest256((char *) checksum_out, data, sizeof(data),

(gdb) print sizeof(data)
$4 = 48
(gdb) x/48xb data
0xbefff17c: 0x2e0x6f0x6e0x690x6f0x6e0x200x63
0xbefff184: 0x680x650x630x6b0x730x750x6d0xa3
0xbefff18c: 0xee0xa10x4a0xcd0xa90x1e0x550xcb
0xbefff194: 0xf50x160x3b0x5a0x220xf80xef0x0e
0xbefff19c: 0xba0x180xa90x6e

Bug#964090: Please upload backport

[Salvatore Bonaccorso]

Hi,

Cc'in the security-team alias.

On Wed, Oct 07, 2020 at 01:15:23PM -0700, Felix Lechner wrote:
> Control: tags -1 + patch
> 
> Hi,
> 
> > Is this because of a ghostscript vulnerability?
> 
> The PDF policy restriction is also in effect on Debian stable even
> though that release ships with Ghostscript 9.27, which online sources
> suggest is safe. [1]
> 
> Converting images to PDF is a very common functionality. Please
> provide a backport with the attached patch, or similar. Thanks!

It is actually unlikely for the moment that we will revert the
200-disable-ghostscript-formats.patch patch again, which was firstly
included in the 8:6.9.10.23+dfsg-2.1+deb10u1 upload. It does mitigates
in general problems with the ghostscript handled formats, e.g. the
(new) CVE-2020-29599, cf.
https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html
.

We follow here only what other distributions have done earlier, I
believe SuSE has such and as well Ubuntu, from which the mentioned
patch was actually merged in in the last update, TTBOMK.

Regards,
Salvatore

Bug#977309: node-less: needlessly depends on node-terser

[Jonas Smedegaard]

Package: node-less
Version: 4.1.2-7
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

node-less depends on node-terser, which will soon see a major
backwards-incompatible upgrade.

Seem to me nothing in binary package node-less actually calls "terser"
and that the runtime dependency on that Nodejs module can therefore
simply be dropped.

Setting severity to serious, because if the library interface _is_ used
then that will soon break.

(the upcoming major change affects only library interface, not arguments
to the executable uglifyjs.terser).


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/WdoQACgkQLHwxRsGg
ASHR+g//ePCWHgbtuA7Cb8jjumE9YwnfGgdENm5DHwrIBfGfw7rmzxyz863l8Mj5
GHFxK43ORA708D6+imEzHSTjjr6OmOXK6ES44QfkkScZrpImuo1kREBN6F6zhfAo
4Ju3vck9IfpYT2Ou01PQHp9PiieacAEqhia0iuHOVdT6Asuc7lM5Ul96HJwKiy0U
mcdrWTLkONqqihkhzJNlA33HDfsofT/x8Bg2/JPodXmhv47PZPYR6zHyi2f3LdTd
SCZElGhUDHQLCBXx3qdaxwAnBSiSyBUfHRRfiGK6NYw91TH18Fa2S1eK2krKZTbp
Clf5SOovYdRBulzt2cRbPhEvRTcINUMXOBwCfMuZEXwiqjuRNb7vqF4HuDLDfbCH
yapEYOl4ZdDs7paay/hCGNza5YiOLeIZOGl6CqMcagez2uqNib23sXglPFa3AKPF
5wusEwaKnVxH0wGrQ9xCa6ljwGbiVhOeK+POg3eDZlI7p3MKMfe8lPU7faWOV+Ny
G7dzMlSxw1AvCbEd89m1sF5w5T6+gJF72QXwlb0TfjyVPq6ZmV4V+sjToeR3Dld4
n3jEp1IxoLcPjBKVLWLDRVZ2kYjgQ0tvZNrRF98ckEeZh7vXtCKUXevGwAEEgbvm
o/mQ8Frs5jCaolKmorNeEHKfGOZCS6rUrZ0VpfLJPpXxB49+wQo=
=d6Bp
-END PGP SIGNATURE-

Bug#977310: libboost1.74-dev needs Breaks+Replaces: libleatherman-dev (<< 1.12.1+dfsg-1.1~)

[Adrian Bunk]

Package: libboost1.74-dev
Version: 1.74.0-3
Severity: serious

See #975863 for background.

Bug#977308: shasta: hardcoded dependencies on boost 1.71

[Graham Inggs]

Source: shasta
Version: 0.6.0-4
Severity: serious
Tags: ftbfs

Hi Maintainer

Binary package shasta has a hardcoded dependency on
libboost-chrono1.71.0 and binary package python3-shasta has a
hardcoded dependency on libboost-program-options1.71.0.

Boost 1.71 will be removed after the Boost 1.74 transition, which is ongoing.

Regards
Graham

Bug#977307: Please package new upstream version 6.0.5 or newer

[Nicholas D Steeves]

Source: juce
Version: 5.4.7~ds0-2
Severity: normal

Hi,

Thank you for maintaining juce.  Recently someone on
#debian-multimedia needed a recent version for a package and is faced
with having to use its bundled copy, because our copy in the archive
is too old.

Please package new upstream version 6.0.5 or newer so this packager
can do the right thing and use the system-provided copy :-)

Regards,
Nicholas

Bug#977306: plplot FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file

[Adrian Bunk]

Source: plplot
Version: 5.15.0+dfsg-17
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=plplot

...
   dh_makeshlibs -a -a -O-Scmake
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libplplot17/DEBIAN/symbols doesn't match 
completely debian/libplplot17.symbols
--- debian/libplplot17.symbols (libplplot17_5.15.0+dfsg-17_amd64)
+++ dpkg-gensymbolsN0fXmN   2020-12-13 06:56:03.198015538 +
@@ -1,6 +1,6 @@
 libplplot.so.17 libplplot17 #MINVER#
 * Build-Depends-Package: libplplot-dev
- FontLookup@Base 5.15.0+dfsg
+#MISSING: 5.15.0+dfsg-17# FontLookup@Base 5.15.0+dfsg
  c_pl_setcontlabelformat@Base 5.15.0+dfsg
  c_pl_setcontlabelparam@Base 5.15.0+dfsg
  c_pladv@Base 5.15.0+dfsg
@@ -198,9 +198,9 @@
  plAllocDev@Base 5.15.0+dfsg
  plClearOpts@Base 5.15.0+dfsg
  plCloseFile@Base 5.15.0+dfsg
- plD_FreeType_Destroy@Base 5.15.0+dfsg
- plD_FreeType_init@Base 5.15.0+dfsg
- plD_render_freetype_text@Base 5.15.0+dfsg
+#MISSING: 5.15.0+dfsg-17# plD_FreeType_Destroy@Base 5.15.0+dfsg
+#MISSING: 5.15.0+dfsg-17# plD_FreeType_init@Base 5.15.0+dfsg
+#MISSING: 5.15.0+dfsg-17# plD_render_freetype_text@Base 5.15.0+dfsg
  plFamInit@Base 5.15.0+dfsg
  plFindCommand@Base 5.15.0+dfsg
  plFindName@Base 5.15.0+dfsg
@@ -254,7 +254,7 @@
  pl_cpcolor@Base 5.15.0+dfsg
  pl_create_tempfifo@Base 5.15.0+dfsg
  pl_create_tempfile@Base 5.15.0+dfsg
- pl_set_extended_cmap0@Base 5.15.0+dfsg
+#MISSING: 5.15.0+dfsg-17# pl_set_extended_cmap0@Base 5.15.0+dfsg
  plabort@Base 5.15.0+dfsg
  plbuf_restore@Base 5.15.0+dfsg
  plbuf_save@Base 5.15.0+dfsg
dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:41: binary-arch] Error 25

Bug#977305: ros-ros-comm: FTBFS with boost 1.74

[Sebastian Ramacher]

Source: ros-ros-comm
Version: 1.15.9+ds1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

See
https://buildd.debian.org/status/fetch.php?pkg=ros-ros-comm=amd64=1.15.9%2Bds1-3=1607875323=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#977269: [Pkg-javascript-devel] Bug#977269: node-rollup-plugin-terser seems incompatible with current node-terser

[Pirate Praveen]

On Sun, Dec 13, 2020 at 1:19 pm, Xavier Guimard  wrote:

Package: node-rollup-plugin-terser
Version: 7.0.2-2
Severity: grave
Justification: renders package unusable

When trying current rollup-plugin-terser (7.0.2)  with current
node-terser (4.1.2), package is unuseable:

$ rollup -c

index.js → dist/pako.js, dist/pako.min.js...
[!] (plugin terser) Error: Cannot find module 
'/home/xavier/dev/debian/src/pkg-js/packages/node-pako/node_modules/terser/dist/bundle.min.js'. 
Please verify that the package.json has a valid "main" entry
Error: Cannot find module 
'/home/xavier/dev/debian/src/pkg-js/packages/node-pako/node_modules/terser/dist/bundle.min.js'.


There is a possibility that this is caused by symbolic links.

I'm hit by symbolic link issue with yarn so I suspect this could be the 
case here too.


Try adding a custom path to node-resolve plugin instead of adding a 
symbolic link


see this example
https://salsa.debian.org/js-team/node-chart.js/commit/979576e93b7aa17083ae5149e9753a5f6b1a522d

Bug#977269: [Pkg-javascript-devel] Bug#977269: node-rollup-plugin-terser seems incompatible with current node-terser

[Jonas Smedegaard]

Control: severity 977269 important
Control: tags 977269 +moreinfo +unreproducible

Quoting Jonas Smedegaard (2020-12-13 20:29:46)
> Quoting Jonas Smedegaard (2020-12-13 17:22:05)
> > Quoting Xavier Guimard (2020-12-13 13:19:47)
> > > Package: node-rollup-plugin-terser
> > > Version: 7.0.2-2
> > > Severity: grave
> > > Justification: renders package unusable
> > > 
> > > When trying current rollup-plugin-terser (7.0.2)  with current
> > > node-terser (4.1.2), package is unuseable:
> > > 
> > > $ rollup -c
> > > 
> > > index.js → dist/pako.js, dist/pako.min.js...
> > > [!] (plugin terser) Error: Cannot find module 
> > > '/home/xavier/dev/debian/src/pkg-js/packages/node-pako/node_modules/terser/dist/bundle.min.js'.
> > >  Please verify that the package.json has a valid "main" entry
> > 
> > Neither node-rollup-plugin-terser nor node-terser asks for files below 
> > /home/xavier - please try locate which code did that.
> 
> Something _is_ broken with node-rollup-plugin-terser - the provided 
> error message is just not really helpful for me.
> 
> I might have a fix for the error I located - we'll see if that turns out 
> to also cure the issue you are experiencing, but for future sake please 
> try unwrap any node_modules tricks when reporting bugs, as they hide 
> ability to trace what is going on where (at least for me - I have no 
> doubt that you are fluent in your tools).

If problem persist with node-rollup-plugin-terser 7.0.2-3 then please 
try isolate a test causing the failure without node_modules wrapping.

Otherwise please close.

 - Jonas

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

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

signature.asc
Description: signature

Bug#977304: autosize.js: include add-module-exports plugin equivalent in .babelrc

[Pirate Praveen]

Package: autosize.js
Version: 4.0.2~dfsg1-4
Severity: important

I get this error is javascript console when running gitlab,

TypeError: a() is not a function. (In 'a()(this.textarea)', 'a()' is an 
instance of Object)


It seems to be generated by this code,

document.addEventListener("DOMContentLoaded", function() {
   Object(s.a)(function() {
   const t = document.querySelectorAll(".js-autosize");
   a()(t),
   a.a.update(t),
   t.forEach(function(t) {
   return t.classList.add("js-autosize-initialized")
   })
   })
   });

I suspect this is caused by autosize.js build issues

https://salsa.debian.org/js-team/autosize.js/-/blob/master/debian/patches/add-babelrc.patch 
tries to replace some babel 6 modules with babel 7 equivalents.


But is it not include add-module-exports plugin 
https://salsa.debian.org/js-team/autosize.js/-/blob/master/build.js#L51


I think we should add this plugin also to babelrc and add 
node-babel-plugin-add-module-exports as build dependency.

Bug#976547: Bug#976535: Bug#976495: also happens on amd64, should be worked around by 1.8.20-5 but the real fix will come with 1.8.20-6

[Neil Roeth]

Attached is a minimal Docbook SGML file and a script which invokes the
commands required to make a PDF using pdfjadetex.

Thanks for looking into this.


test.sh
Description: application/shellscript


  Some Title Here
  STH
  

  Neil
  Roeth


  2020
  Neil Roeth

  
  
Introduction
This is a test.  This is only a test.  Now, back to our regularly scheduled program.
  

Bug#977269: [Pkg-javascript-devel] Bug#977269: node-rollup-plugin-terser seems incompatible with current node-terser

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-12-13 17:22:05)
> Quoting Xavier Guimard (2020-12-13 13:19:47)
> > Package: node-rollup-plugin-terser
> > Version: 7.0.2-2
> > Severity: grave
> > Justification: renders package unusable
> > 
> > When trying current rollup-plugin-terser (7.0.2)  with current
> > node-terser (4.1.2), package is unuseable:
> > 
> > $ rollup -c
> > 
> > index.js → dist/pako.js, dist/pako.min.js...
> > [!] (plugin terser) Error: Cannot find module 
> > '/home/xavier/dev/debian/src/pkg-js/packages/node-pako/node_modules/terser/dist/bundle.min.js'.
> >  Please verify that the package.json has a valid "main" entry
> 
> Neither node-rollup-plugin-terser nor node-terser asks for files below 
> /home/xavier - please try locate which code did that.

Something _is_ broken with node-rollup-plugin-terser - the provided 
error message is just not really helpful for me.

I might have a fix for the error I located - we'll see if that turns out 
to also cure the issue you are experiencing, but for future sake please 
try unwrap any node_modules tricks when reporting bugs, as they hide 
ability to trace what is going on where (at least for me - I have no 
doubt that you are fluent in your tools).


 - Jonas

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

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

signature.asc
Description: signature

Bug#977223: Info received (Bug#977223: Info received (Bug#977223: Acknowledgement (guile-3.0: FTBFS on hppa - segmentation faults)))

[John David Anglin]

The x=0 value comes from this hunk of code in vm-engine.c:

  /* call-scm<-scm-uimm dst:8 a:8 b:8 IDX:32
   *
   * Call the SCM-returning instrinsic with index IDX, passing the SCM
   * local A and the uint8_t immediate B as arguments.  Place the SCM
   * result in DST.
   */
  VM_DEFINE_OP (53, call_scm_from_scm_uimm, "call-scm<-scm-uimm", DOP2 (X8_S8_S8
_C8, C32))
    {
  uint8_t dst, a, b;
  SCM res;
  scm_t_scm_from_scm_uimm_intrinsic intrinsic;

  UNPACK_8_8_8 (op, dst, a, b);
  intrinsic = intrinsics[ip[1]];

  SYNC_IP ();
  res = intrinsic (SP_REF (a), b);
  CACHE_SP ();
  SP_SET (dst, res);

  NEXT (2);
    }

SP_REF (a) evaluates to 0.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#977303: nss-tlsd: New upstream version 1.1 available

[Petter Reinholdtsen]

Package: nss-tlsd
Version: 0~git20200523-2 
Severity: minor

Dear maintainer,

There is a new tagged release available from upstream for nss-tls.  Any
hope to have the latest version included in Debian before the freeze?

-- 
Happy hacking
Petter Reinholdtsen

Bug#971030: soapysdr, libaudioSupport: libarmmem-${PLATFORM}.so => libarmmem-v7l.so

[Frans van Berckel]

I don't have a Pi myself! A friend of mine, a Radio Amateur Hobbyist,
asked me to help installing his openwebrx dependency.

It's all because of the difficulty of building SoapySDRPlay from
source. A normal user would even not investigate this bug.

That's why I did not dd the img to the SD card. So you may be right
about that, it could be Raspbian indeed!

Thanks for the effort,

-- 
Frans van Berckel
Media Engineer / Linux Master
LinkedIn: https://www.linkedin.com/in/fransvberckel/

On Sun, 2020-12-13 at 18:57 +0100, Andreas Bombe wrote:
> tags 971030 + moreinfo
> thanks
> 
> On Sat, Sep 26, 2020 at 03:35:40PM +0200, Frans van Berckel wrote:
> > Package: soapysdr0.6-module-audio
> > Version: 0~git20160607-3
> > 
> > On a Pi: Found a strange link, with name brackets, when exec ldd.
> > 
> > $ ldd /usr/lib/arm-linux-
> > gnueabihf/SoapySDR/modules0.6/libaudioSupport.so
> > 
> > linux-vdso.so.1 (0xbefe5000)
> > /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so =>
> > /usr/lib/arm-
> > linux-gnueabihf/libarmmem-v7l.so (0xb6f51000)
> > libhamlib.so.2 => /usr/lib/arm-linux-gnueabihf/libhamlib.so.2
> > (0xb6ca4000)
> 
> I've been looking into this and I don't think this is a Debian thing.
> It
> looks like Raspbian which, from what I understand, preloads this
> library by default. At least I don't see a reference to libarmmem in
> the
> Debian binaries.
> 
> Can you please confirm whether this is on Raspbian or not?

Bug#977302: CVE-2019-20093

[Moritz Muehlenhoff]

Source: libpodofo
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2019-20093:
https://sourceforge.net/p/podofo/tickets/75/

Cheers,
Moritz

Bug#977301: segfault in audio_init()

[dann frazier]

Package: qemu-system-x86
Version: 1:5.2+dfsg-2
Severity: normal

One of my libvirt/QEMU guests is now segfaulting on startup:

Thread 1 (Thread 0x7fcd275e5e80 (LWP 829788)):
#0  audio_init (dev=dev@entry=0x0, name=name@entry=0x5590b2b8a27b "hda") at 
../../audio/audio.c:1712
#1  0x5590b2890f7a in AUD_register_card (name=name@entry=0x5590b2b8a27b 
"hda", card=card@entry=0x5590b67676f8) at ../../audio/audio.c:1831
#2  0x5590b28459d5 in hda_audio_init (hda=, 
desc=0x5590b2f39f60 ) at ../../hw/audio/hda-codec.c:691
#3  0x5590b26dd59a in hda_codec_dev_realize (qdev=, 
errp=0x7ffd21d56380) at ../../hw/audio/intel-hda.c:74
#4  0x5590b2ae98b1 in device_set_realized (obj=, 
value=, errp=0x7ffd21d56400) at ../../hw/core/qdev.c:886
#5  0x5590b2ad45c6 in property_set_bool (obj=0x5590b6767660, v=, name=, opaque=0x5590b4e453e0, errp=0x7ffd21d56400) at 
../../qom/object.c:2251
#6  0x5590b2ad7418 in object_property_set (obj=obj@entry=0x5590b6767660, 
name=name@entry=0x5590b2cc2ee9 "realized", v=v@entry=0x5590b676fde0, 
errp=errp@entry=0x5590b308c010 ) at ../../qom/object.c:1398
#7  0x5590b2ad3580 in object_property_set_qobject 
(obj=obj@entry=0x5590b6767660, name=name@entry=0x5590b2cc2ee9 "realized", 
value=value@entry=0x5590b676fd20, errp=errp@entry=0x5590b308c010 ) 
at ../../qom/qom-qobject.c:28
#8  0x5590b2ad79f5 in object_property_set_bool (obj=0x5590b6767660, 
name=name@entry=0x5590b2cc2ee9 "realized", value=value@entry=true, 
errp=errp@entry=0x5590b308c010 ) at ../../qom/object.c:1465
#9  0x5590b2ae9ebe in qdev_realize (dev=, 
bus=bus@entry=0x5590b6722348, errp=errp@entry=0x5590b308c010 ) at 
../../hw/core/qdev.c:399
#10 0x5590b27a3ef7 in qdev_device_add (opts=0x5590b4e43030, 
errp=errp@entry=0x5590b308c010 ) at 
../../softmmu/qdev-monitor.c:676
#11 0x5590b2a05a3f in device_init_func (opaque=, 
opts=, errp=0x5590b308c010 ) at 
../../softmmu/vl.c:2104
#12 0x5590b2b7144a in qemu_opts_foreach (list=, 
func=func@entry=0x5590b2a05a30 , opaque=opaque@entry=0x0, 
errp=0x5590b308c010 ) at ../../util/qemu-option.c:1156
#13 0x5590b2a0c4a4 in qemu_init (argc=, argv=, envp=) at ../../softmmu/vl.c:4400
#14 0x5590b26a3479 in main (argc=, argv=, 
envp=) at ../../softmmu/main.c:49

I'm working around it by removing the sound device from my XML:

--- debian10.xml.crashes2020-12-13 10:49:45.376371832 -0700
+++ debian10.xml2020-12-13 10:49:52.812335134 -0700
@@ -135,9 +135,6 @@
   
   
 
-
-  
-
 
   
   


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5
ii  libaio1   0.3.112-8
ii  libc6 2.31-5
ii  libcapstone4  4.0.2-3
ii  libfdt1   1.6.0-1
ii  libgcc-s1 10.2.1-1
ii  libglib2.0-0  2.66.3-2
ii  libgnutls30   3.7.0-3
ii  libibverbs1   32.0-1+b1
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libnettle83.6-2
ii  libnuma1  2.0.12-1+b1
ii  libpixman-1-0 0.40.0-1
ii  libpmem1  1.10-1
ii  libpng16-16   1.6.37-3
ii  librdmacm132.0-1+b1
ii  libsasl2-22.1.27+dfsg-2
ii  libseccomp2   2.5.0-3+b1
ii  libslirp0 4.3.1-1
ii  libudev1  247.1-4
ii  liburing1 0.7-2
ii  libusb-1.0-0  2:1.0.24-1
ii  libvdeplug2   4.0.1-2
ii  libxendevicemodel14.14.0+80-gd101b417b7-1
ii  libxenevtchn1 4.14.0+80-gd101b417b7-1
ii  libxenforeignmemory1  4.14.0+80-gd101b417b7-1
ii  libxengnttab1 4.14.0+80-gd101b417b7-1
ii  libxenmisc4.144.14.0+80-gd101b417b7-1
ii  libxenstore3.04.14.0+80-gd101b417b7-1
ii  libxentoolcore1   4.14.0+80-gd101b417b7-1
ii  qemu-system-common1:5.2+dfsg-2
ii  qemu-system-data  1:5.2+dfsg-2
ii  seabios   1.14.0-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages qemu-system-x86 recommends:
ii  ovmf 2020.11-1
pn  qemu-system-gui  
ii  qemu-utils   1:5.2+dfsg-2

Versions of packages qemu-system-x86 suggests:
pn  qemu-block-extra
ii  qemu-system-data [sgabios]  1:5.2+dfsg-2
pn  samba   
pn  vde2

-- no debconf information