Bug#949466: node-request: depends on transitional package node-node-uuid

[Jaap-Jan van der Veen]

Package: node-request
Version: 2.88.1-2
Severity: normal

This package depends on the transitional package node-node-uuid, instead of 
node-uuid, which replaces it.


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages node-request depends on:
ii  node-aws-sign20.7.1-1
ii  node-aws4 1.8.0-1
ii  node-caseless 0.12.0-1
ii  node-combined-stream  1.0.7-1
ii  node-extend   3.0.2-1
ii  node-forever-agent0.6.1-1
ii  node-form-data2.3.2-2
ii  node-har-validator5.1.0-1
ii  node-http-signature   1.2.0-1
ii  node-is-typedarray1.0.0-2
ii  node-isstream 0.1.2+dfsg-1
ii  node-json-stringify-safe  5.0.1-1
ii  node-mime-types   2.1.21-1
ii  node-node-uuid3.3.2-2
ii  node-oauth-sign   0.9.0-1
ii  node-performance-now  2.1.0+debian-1
ii  node-qs   6.5.2-1
ii  node-safe-buffer  5.1.2-1
ii  node-tough-cookie 2.3.4+dfsg-1
ii  node-tunnel-agent 0.6.1-1
ii  nodejs10.15.2~dfsg-2

node-request recommends no packages.

node-request suggests no packages.

-- no debconf information

Bug#949334: marked as done (src:plasma-desktop: missing multiple Breaks+Replaces)

[Aurélien COUDERC]

Hi Pino,

quick feedback to confirm the fix.
I did an upgrade before the fix on one machine which failed, and a second 
upgrade after the fix on another machine that went fine.

And thanks for all the Plasma 5.17.5 packaging. :-)


Happy hacking !
--
Aurélien

Bug#949457: mmdebstrap default variant is not "required" as documented

[Johannes Schauer]

Hi,

Quoting Josh Triplett (2020-01-21 03:08:26)
> mmdebstrap's documentation and --help document the default variant as
> "required". However, when I tried mmdebstrap, it defaulted to installing
> various packages with priority "important". Passing --variant=required
> produced a much smaller installation.
> 
> Please consider changing the default to "required" to match the
> documentation.

whoops, thanks for making me aware of this!

Unfortunately, this is a bug in the documentation. The default variant should
be "debootstrap" or "-" because mmdebstrap is supposed to be a drop-in
replacement for debootstrap.

So instead of changing the default to match the documentation, I'm afraid I
will have to change the documentation to match the (correct) behaviour.

If you want a smaller rootfs, you will have to pass --variant=minbase as you
would with debootstrap.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#949163: Please provide a repo for packages not intent for users

[Paul Wise]

On Mon, 2020-01-20 at 22:51 +0800, Shengjing Zhu wrote:
> On Mon, Jan 20, 2020 at 10:37 PM Ximin Luo wrote:
> > This doesn't work for Rust unfortunately, due to features. Based on
> > which feature-set is activated, when you depend on a source-package 
> > you would want to pull in different sets of transitive
> > dependencies.
> > 
> > However, a combination of:
> > 
> > 1. implicitly being able to install source packages into /usr/src
> > 2. metadata-only binary Packages that can depend on these implicit
> > source packages
> 
> This applies to Go too. Currently a source-package's build-depends
> usually include those for testing purposes, which are not needed when
> building the rdepends. Or we don't test it, or we have a separate
> control-filed in source-package..

IIRC the proposals about build-depending on source packages included
being able to build-depend on their build-depends. If you could also
filter those build-depends by build profiles then that might work.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#948734: The package should be in contrib section

[Paul Wise]

On Mon, 2020-01-20 at 12:33 -0500, Olek Wojnar wrote:

> Hmm, I always interpreted that as meaning a dependency on another .deb
> package because of the "package" wording vs a word such as "component."

I always interpreted it in the general sense rather than in the sense
of a dependency on Debian packages, mainly because of this sentence:

   None of the packages in the main archive area require software
   outside of that area to function.

> Furthermore, in Policy 2.2.1 it lists examples as "Pre-Depends, Depends,
> Recommends" etc. which further implies the authors were thinking about
> .deb packages. I also always saw the causality being along the lines of:
> licensing prohibits inclusion in Debian (main) therefore a package must
> be in non-free and .deb packages that depend on it must be in contrib
> and potentially do install-time downloads of certain components (e.g.
> Flash). I didn't see Policy applying to components outside of the Debian
> distribution channels or the causality working the other way (i.e.
> install-time download requiring contrib).

Your package does install-time downloads of certain components and
isn't in any way useful without those downloads, so the only difference
between your case and that of Flash is the licensing of the download.

> Do you have any additional insights as to the intent behind those words?

Debian has always required downloader packages go to contrib, but
I don't see anything in the ftp-master reject FAQ about this:

https://ftp-master.debian.org/REJECT-FAQ.html

> With that being said, and having thought about it some more, I agree
> that the *intent* of Policy is possibly what you stated above. My
> rationale being that install-time downloads have not been verified by a
> DM/DD and could include software with problematic licensing that has
> changed and not been appropriately reviewed. It that a valid concern? In
> the interests of understanding Policy better, are there any other
> aspects here that I'm missing?

As far as I know Debian main was always meant to be self-contained and
downloader packages violate that constraint. The possibility of
problematic licensing is just one aspect of a non-self-contained
archive, you could also have source code disappear or malware added,
but if you have a mirror of Debian main that you do not change, then
these things generally cannot happen.

> I appreciate your time in this conversation! However it turns out, I
> think that I may recommend an update to 2.2.1 to include things such as
> Snap and Flatpak which were not prevalent when that section was first
> written. Since those (and similar systems) are more and more common, we
> should probably explicitly address the issue in Policy.

I don't think it would be a good idea to list specific technologies in
Policy since there is always the possibility of other technologies
existing and the ones you list becoming less popular. I agree that the
wording could use a slight clarification to state that Debian main must
be entirely self-contained and that any dependencies on content of any
kind outside of Debian main are not allowed.

Please ask the Debian ftp-masters to mention this in the REJECT-FAQ.

> Well there's certainly no need for that since the Snap mechanism makes
> it easy to transition existing users until such time as the packages get
> more stable. But removal from Debian proper (main) may be necessary in
> light of the above conversation.

As I have said above, I think the Snap package is a violation of Debian
policy due to requiring things outside of main. You could of course
move the Snap-depending package to contrib as a workaround until you
can return a proper Debian package back to main.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#949281: r-bioc-tximport: autopkgtest regression

[Andreas Tille]

On Sun, Jan 19, 2020 at 11:39:01AM +0200, Graham Inggs wrote:
> Error in library(tximportData) :
>   there is no package called ‘tximportData’

While I've fixed prepare_missing_cran_package in Git to enable fetching
tximportData and I'm a big fan of packaging also test-depends its just
0.5GB compressed data and from my point of view a bit much.  If you
(Steffen since you are Uploader or Dylan since you did the last update)
agree please simply exclude the tests that are requiring these additional
data (or throw ENOTIME error to let me do this).

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#949465: ITP: r-cran-tinytest -- Lightweight and Feature Complete Unit Testing Framework

[Dylan Aïssi]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-tinytest -- Lightweight and Feature Complete Unit Testing 
Framework
Package: wnpp
Owner: Dylan Aïssi 
Severity: wishlist

* Package name: r-cran-tinytest
  Version : 1.1.0
  Upstream Author : Mark van der Loo
* URL : https://cran.r-project.org/package=tinytest
* License : GPL-3
  Programming Lang: GNU R
  Description : Lightweight and Feature Complete Unit Testing Framework
 Provides a lightweight (zero-dependency) and easy to use
 unit testing framework. Main features: install tests with
 the package. Test results are treated as data that can be stored and
 manipulated. Test files are R scripts interspersed with test commands, that
 can be programmed over. Fully automated build-install-test sequence for
 packages. Skip tests when not run locally (e.g. on CRAN). Flexible and
 configurable output printing. Compare computed output with output stored
 with the package. Run tests in parallel. Extensible by other packages.
 Report side effects.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-tinytest

Bug#949464: the gwcs build accesses the network during the build

[Matthias Klose]

Package: src:gwcs
Version: 0.12.0-3
Severity: serious
Tags: sid bullseye

the gwcs build accesses the network during the build, according to the build 
log:

[...]
Running Sphinx v1.8.5
making output directory...
loading intersphinx inventory from https://docs.python.org/3/objects.inv...
loading intersphinx inventory from
/usr/lib/python3/dist-packages/sphinx_astropy/local/python3_local_links.inv...
loading intersphinx inventory from 
https://docs.scipy.org/doc/numpy/objects.inv...
loading intersphinx inventory from
https://docs.scipy.org/doc/scipy/reference/objects.inv...
loading intersphinx inventory from https://matplotlib.org/objects.inv...
loading intersphinx inventory from 
http://docs.astropy.org/en/stable/objects.inv...
loading intersphinx inventory from http://docs.h5py.org/en/stable/objects.inv...
[autosummary] generating autosummary for: gwcs/ifu.rst,
gwcs/imaging_with_distortion.rst, gwcs/points_to_wcs.rst, gwcs/pure_asdf.rst,
gwcs/schemas/index.rst, gwcs/using_wcs.rst, gwcs/wcs_ape.rst,
gwcs/wcs_validation.rst, gwcs/wcstools.rst, index.rst
[automodsumm] index.rst: found 20 automodsumm entries to generate
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 10 source files that are out of date
updating environment: 30 added, 0 changed, 0 removed

Bug#949450: thunderbird: apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg" name="/dev/shm/org.chromium.*"

[Carsten Schoenert]

Hi Vincas,

do we need to adjust the TB profile once again? Do you have any advice?

Am 21.01.20 um 00:49 schrieb Dmitry Smirnov:
> Package: thunderbird
> Version: 1:68.4.1-1~deb10u1
> Severity: minor
> 
> While Thunderbird is being used, kernel repeatedly logs the following:
> 
> ```
> audit: type=1400 audit(1579563490.921:660): apparmor="DENIED" 
> operation="file_inherit" profile="thunderbird//gpg" name="/dev/shm/
> org.chromium.9d3eJz" pid=23349 comm="gpg" requested_mask="r" denied_mask="r" 
> fsuid=1001 ouid=1001
> ```
> 
> Please advise.
> 

-- 
Regards
Carsten Schoenert

Bug#949463: ITP: fonts-pc -- TrueType conversions of PC ROM fonts

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: fonts-pc
  Upstream Author : VileR
* URL : https://int10h.org/oldschool-pc-fonts/
* License : CC-BY-SA 4.0
  Description : TrueType conversions of PC ROM fonts

These fonts came from versions of IBM PC and its clones in the DOS era
(1981-1994), embedded in ROM, and used in text modes.  They are provided
in a form usable by modern display libraries.  Character coverage comes
from taking together many language versions sold regionally, with additional
characters that are expected today drawn in a given font's style.


I plan to make two binary packages: fonts-pc for the best known machines,
and fonts-pc-extra for the rest.

This package's immediate use is for cool-retro-term, but they're also
useful on their own.

The original machines came from either the US, UK, or Japan.  US doesn't
recognize copyright on bitmap fonts, so doesn't Japan.  In UK, copyright
on fonts is limited to 25 years, counting from the end of the calendar
year of first publishing.

Bug#875041: [meshlab] Future Qt4 removal from Buster

[Gürkan Myczko]

Hi Moritz,

I'm trying hard to get later versions of meshlab built and working, 
please

don't remove the package.
Later versions support qt5 already, so no more porting needed.


I failed to get built the latest versions, however according to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946685
Ryan can do! We failed to meet on irc, and I failed to build his 
packages.


There's also a lot of installations of it, and at my work place we 
have some

users of it as well:
https://qa.debian.org/popcon.php?package=meshlab


What's the status?


I'm waiting for Ryan to speak up on irc and/or just get his package
fixed and sponsored.

Qt4 has now been droppped from testing, qt4 will be removed from 
unstable by

end of February (along with the remaining rdeps (currently 15)).


Great, plenty of time left.


Cheers,
Moritz


Best,

Bug#949462: python-pygraphviz: please reduce build dependencies

[Helmut Grohne]

Source: python-pygraphviz
Version: 1.5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

python-pygraphviz cannot be cross built, because it has a fair number of
dependency issues. Involved packages include graphviz, python3-sphinx
and python*-mock. Without tackling the cross compilation part, we can
improve the dependency situation a lot:

 * graphviz, *-nose and *-mock are only used for running tests. They can
   be annotated with .
 * Documentation resides in an arch:all package. As such, we can move
   the sphinx dependency and the sequencer to Build-Depends-Indep
   leveraging a debhelper 12.5 feature of using delcarative sequencers.

Thanks to reproducible builds, we can verify that all these changes do
not affect the produced binary packages in any way. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru python-pygraphviz-1.5/debian/changelog 
python-pygraphviz-1.5/debian/changelog
--- python-pygraphviz-1.5/debian/changelog  2018-11-23 18:42:16.0 
+0100
+++ python-pygraphviz-1.5/debian/changelog  2020-01-21 06:35:07.0 
+0100
@@ -1,3 +1,13 @@
+python-pygraphviz (1.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce build dependencies:
++ Annotate graphviz, *-nose and *-mock with .
++ Use sphinxdoc dh sequencer via Build-Depends-Indep.
++ Only build documentation during indep build.
+
+ -- Helmut Grohne   Tue, 21 Jan 2020 06:35:07 +0100
+
 python-pygraphviz (1.5-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --minimal -Nru python-pygraphviz-1.5/debian/control 
python-pygraphviz-1.5/debian/control
--- python-pygraphviz-1.5/debian/control2018-11-23 18:42:16.0 
+0100
+++ python-pygraphviz-1.5/debian/control2020-01-21 06:35:07.0 
+0100
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Sandro Tosi 
 Uploaders: Debian Python Modules Team 

-Build-Depends: debhelper (>= 10), dh-python, python-all-dev (>= 2.3.5-11), 
python-all-dbg, python3-all-dev, python3-all-dbg, libgraphviz-dev, 
python-setuptools, python3-setuptools, pkg-config, graphviz, python-nose, 
python3-nose, python3-sphinx, python-mock (>= 1.3), python3-mock (>= 1.3)
+Build-Depends: debhelper (>= 12.5), dh-python, python-all-dev (>= 2.3.5-11), 
python-all-dbg, python3-all-dev, python3-all-dbg, libgraphviz-dev, 
python-setuptools, python3-setuptools, pkg-config, graphviz , 
python-nose , python3-nose , python-mock (>= 1.3) 
, python3-mock (>= 1.3) 
+Build-Depends-Indep: dh-sequence-sphinxdoc, python3-sphinx
 Standards-Version: 4.2.1
 Homepage: https://pygraphviz.github.io/
 Vcs-Git: https://salsa.debian.org/python-team/modules/python-pygraphviz.git
diff --minimal -Nru python-pygraphviz-1.5/debian/rules 
python-pygraphviz-1.5/debian/rules
--- python-pygraphviz-1.5/debian/rules  2018-11-23 18:42:16.0 +0100
+++ python-pygraphviz-1.5/debian/rules  2020-01-21 06:35:07.0 +0100
@@ -2,9 +2,10 @@
 
 PYTHON2=$(shell pyversions -r)
 PYTHON3=$(shell py3versions -r)
+DO_PACKAGES=$(shell dh_listpackages)
 
 %:
-   dh  $@ --with python2,python3,sphinxdoc
+   dh  $@ --with python2,python3
 
 override_dh_install:
set -e; \
@@ -23,7 +24,9 @@
$$python setup.py build; \
$$python-dbg setup.py build; \
done
+ifneq (,$(filter python-pygraphviz-doc,$(DO_PACKAGES)))
PYTHONPATH=$(CURDIR)/`python3 -c "from distutils.command.build import 
build ; from distutils.core import Distribution ; b = build(Distribution()) ; 
b.finalize_options() ; print (b.build_platlib)"` $(MAKE) -C doc html
+endif
 
 override_dh_strip:
 ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))

Bug#948359: Re: Bug#948359: multipath issue on Debian 9.11

[Kumar Ranjan]

Please close this bug.

Got resolved with buster packages :
# ls -l
total 936
-rw-r--r-- 1 hgst hgst 330728 Jan 16 04:41 libsystemd0_241-7_deb10u2_amd64.deb
-rw-r--r-- 1 hgst hgst 325328 Jan 16 04:41 
libtinfo6_6.1+20181013-2+deb10u2_amd64.deb
-rw-r--r-- 1 hgst hgst 295836 Jan 16 04:41 multipath-tools_0.7.9-3_amd64.deb



Regards,
Ranjan

Bug#949326: [Pkg-kde-extras] Bug#949326: transition: libgwenhywfar

[Pino Toscano]

In data lunedì 20 gennaio 2020 22:10:38 CET, Micha Lenk ha scritto:
> Control: tags -1 moreinfo
> 
> On 20.01.20 09:52, Pino Toscano wrote:
> > Since you are already updating Gwenhywfar, can you please update it to
> > the newly released 5.1.2?
> 
> Just uploaded to experimental.

Thanks!

> > The newly released version of KMyMoney (5.0.8) requires:
> > - Gwenhywfar >= 5.1.2
> > - AqBanking >= 6.0.1
> 
> I looked into that and just realized this version of AqBanking did a 
> SONAME bump as well. This means its uploads will go through NEW. :(

Ouch... OTOH, the AqBanking transition is basically a subset of the
Gwenhywfar transition, so packing these two transitions together should
simplify things a bit.

Considering the requirements of KMyMoney 5.0.8, I will upload this new
version once the Gwenhywfar/AqBanking transition starts -- let me know
when that happens.

Thanks,
-- 
Pino Toscano

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

Bug#948349: Re: Bug#948349: multipath issue on Debian 9.11

[Kumar Ranjan]

Hi Ritesh,
Thank you for providing the suggestion.

I installed the packages from buster, and see the multipath working. However, 
the host crashes when I perform any failover, looks to be issue with nvme-rdma 
package.
Will report another bug to chase that.

Below are the files that I installed :
# ls -l
total 936
-rw-r--r-- 1 hgst hgst 330728 Jan 16 04:41 libsystemd0_241-7_deb10u2_amd64.deb
-rw-r--r-- 1 hgst hgst 325328 Jan 16 04:41 
libtinfo6_6.1+20181013-2+deb10u2_amd64.deb
-rw-r--r-- 1 hgst hgst 295836 Jan 16 04:41 multipath-tools_0.7.9-3_amd64.deb

Is there a way that I can install multipath-tools with dependencies sorted out 
? local yum ?


Regards,
Ranjan

Bug#949461: repo is an empty package in unstable/testing, failing it's autopkg tests

[Matthias Klose]

Package: repo
Version: 1.13.7-1
Severity: serious
Tags: sid bullseye

https://packages.debian.org/sid/all/repo/filelist

/usr/bin/repo
/usr/share/bash-completion/completions/repo
/usr/share/doc/repo/README.Debian
/usr/share/doc/repo/changelog.Debian.gz
/usr/share/doc/repo/copyright
/usr/share/doc/repo/manifest-format.md.gz
/usr/share/doc/repo/repo-hooks.md.gz
/usr/share/man/man1/repo.1.gz

autopkgtest [16:16:37]: test command1: (! repo help) && repo init --quiet
--depth=1 -u https://android.googlesource.com/platform/manifest -b 
android-2.3.7_r1
autopkgtest [16:16:37]: test command1: [---
usage: repo COMMAND [ARGS]

repo is not yet installed.  Use "repo init" to install it here.

The most commonly used repo commands are:

  init  Install repo in the current working directory
  help  Display detailed help on a command

For access to the full online help, install repo ("repo init").

autopkgtest [16:16:38]: test command1: ---]

Bug#949426: postgis: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://trac.osgeo.org/postgis/ticket/4626

Forwarded upstream.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#949412: mapnik: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/mapnik/mapnik/issues/4109

Forwarded upstream.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#939989: transition: gdal

[Sebastiaan Couwenberg]

On 1/20/20 5:38 AM, Sebastiaan Couwenberg wrote:
> Looks like britney needs some help to migrate everything to testing. The
> update_output.txt shows most rdeps, I can't make sense of why it's not
> migrating them.

DDPO shows 3.0.3+dfsg-1 in testing-proposed-updates, is that intended?

Kind Regards,

Bas

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

Bug#949387: Merge request for upgrading to 1.19.17

[Sebastiaan Couwenberg]

On Mon, 20 Jan 2020 16:25:25 +0100 Adam Cecile wrote:
> PR available here: 
> https://salsa.debian.org/nagios-team/pkg-nagvis/merge_requests/2

That misses the changes for the upstream & pristine-tar branches.

I've added you to the team so you can push to the repo.

Please add yourself to Uploaders if you intend to keep maintaining the
package.

I'm available to sponsor uploads, ping me on the team mailinglist.

Kind Regards,

Bas

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

Bug#949460: openjdk-14 FTCBFS: missing build-depends and wrong tools

[Helmut Grohne]

On Tue, Jan 21, 2020 at 05:40:24AM +0100, Helmut Grohne wrote:
> Please consider applying the attached patch.

Uhm. Seems like I forgot something.

Helmut
diff --minimal -Nru openjdk-14-14~32/debian/changelog 
openjdk-14-14~32/debian/changelog
--- openjdk-14-14~32/debian/changelog   2020-01-16 23:31:42.0 +0100
+++ openjdk-14-14~32/debian/changelog   2020-01-20 20:10:45.0 +0100
@@ -1,3 +1,12 @@
+openjdk-14 (14~32-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Missing Build-Depends: zlib1g-dev:native.
++ Use triplet-prefixed objcopy and strip.
+
+ -- Helmut Grohne   Mon, 20 Jan 2020 20:10:45 +0100
+
 openjdk-14 (14~32-1) unstable; urgency=medium
 
   * OpenJDK 14 snapshot, build 32.
diff --minimal -Nru openjdk-14-14~32/debian/control 
openjdk-14-14~32/debian/control
--- openjdk-14-14~32/debian/control 2019-10-18 15:55:10.0 +0200
+++ openjdk-14-14~32/debian/control 2020-01-20 20:09:15.0 +0100
@@ -12,7 +12,7 @@
   openjdk-13-jdk-headless:native | openjdk-14-jdk-headless:native,
   libxtst-dev, libxi-dev, libxt-dev, libxaw7-dev, libxrender-dev, 
libcups2-dev, libasound2-dev, liblcms2-dev, libfreetype6-dev (>= 2.2.1), 
libxinerama-dev, libkrb5-dev, xsltproc, libpcsclite-dev, libxrandr-dev, 
libelf-dev, libfontconfig1-dev, libgtk2.0-0 | libgtk-3-0,
   libffi-dev,
-  zlib1g-dev, libattr1-dev, libpng-dev, libjpeg-dev, libgif-dev, 
+  zlib1g-dev, zlib1g-dev:native, libattr1-dev, libpng-dev, libjpeg-dev, 
libgif-dev,
   libnss3-dev (>= 2:3.17.1),
   openjdk-14-jdk-headless ,
 Build-Depends-Indep: graphviz, pandoc,
diff --minimal -Nru openjdk-14-14~32/debian/rules openjdk-14-14~32/debian/rules
--- openjdk-14-14~32/debian/rules   2020-01-16 22:46:33.0 +0100
+++ openjdk-14-14~32/debian/rules   2020-01-20 20:10:43.0 +0100
@@ -28,6 +28,9 @@
 DEB_HOST_ARCH_CPU  ?= $(call vafilt,$(DPKG_VARS),DEB_HOST_ARCH_CPU)
 DEB_HOST_MULTIARCH ?= $(call vafilt,$(DPKG_VARS),DEB_HOST_MULTIARCH)
 
+OBJCOPY := $(DEB_HOST_GNU_TYPE)-objcopy
+STRIP := $(DEB_HOST_GNU_TYPE)-strip
+
 PATH := $(CURDIR)/bin:$(PATH)
 export PATH
 
@@ -1774,18 +1777,18 @@
id=$$(echo $$i | sed -r 's,debian/[^/]+,$(d_dbg)/usr/lib/debug,'); \
echo strip $$i; \
mkdir -p $$(dirname $$id); \
-   objcopy --only-keep-debug $$i $$id; \
+   $(OBJCOPY) --only-keep-debug $$i $$id; \
chmod 644 $$id; \
-   strip --remove-section=.comment --remove-section=.note \
+   $(STRIP) --remove-section=.comment --remove-section=.note \
  --strip-debug $$i; \
-   objcopy --add-gnu-debuglink $$id $$i; \
+   $(OBJCOPY) --add-gnu-debuglink $$id $$i; \
  else \
d=usr/lib/debug/.build-id/$${b_id:0:2}; \
f=$${b_id:2}.debug; \
mkdir -p $(d_dbg)/$$d; \
-   objcopy --only-keep-debug --compress-debug-sections $$i 
$(d_dbg)/$$d/$$f; \
+   $(OBJCOPY) --only-keep-debug --compress-debug-sections $$i 
$(d_dbg)/$$d/$$f; \
chmod 644 $(d_dbg)/$$d/$$f; \
-   strip --remove-section=.comment --remove-section=.note $$i; \
+   $(STRIP) --remove-section=.comment --remove-section=.note $$i; \
  fi; \
done
 endif

Bug#949460: openjdk-14 FTCBFS: missing build-depends and wrong tools

[Helmut Grohne]

Source: openjdk-14
Version: 14~32-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

openjdk-14 fails to cross build from source. The immediate failure is
when linking -lz using the build architecture compiler, because there is
not dependency on zlib1g-dev:native. In this case, it seems that the
build rules are already fully correct and openjdk really needs a build
tool that links -lz. As such it should have a relevant dependency on
zlib1g-dev:native. Once adding it, the build proceeds much further until
it finally fails when debian/rules invokes the build architecture
objcopy and strip. Using triplet-prefixed tools is necessary here. After
doing so, openjdk-14 cross builds successfully. Please consider applying
the attached patch.

At least the dependency issue appears to also affect openjdk-11 and
openjdk-13. Do you prefer fixing it yourself there or should I send
separate patchs?

Helmut

Bug#949459: sms4you: homepage link does not exist

[Paul Wise]

Source: sms4you
Severity: normal

I noticed that the Homepage for this package redirects to the salsa
login page and when you login it says 404 Page Not Found.

https://salsa.debian.org/debacle/sms4you

Please either publish the git repository or correct the Homepage.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#949458: liggghts: git repo does not contain correct source and is not buildable

[Stuart Prescott]

Source: liggghts
Version: 3.8.0+repack1-1
Severity: important

Dear Maintainer,

The current git master branch is not descended from the upstream branch and,
worse, has lots of merge conflicts committed to the tree.

The solution appears to be to do a synthetic merge of the upstream branch
into the current master and ensure that everything outside of the debian
directory comes only from the upstream branch. The git history will not
match the archive reality, but at least git will be buildable and the next
upstream update has a chance of being applied.

I'll attempt to do this later.

Stuart

Fix up incorrect merge of previous upstream release

 src/atom_vec_ellipsoid.cpp  |   6 -
 src/atom_vec_sphere.cpp |   3 -
 src/comm.cpp|  15 --
 src/comm.h  |   3 -
 src/comm_I.h|  16 --
 src/compute_erotate_sphere.cpp  |   3 -
 src/container_base.cpp  |  18 --
 src/container_base.h|   8 -
 src/domain.cpp  |   4 -
 src/domain.h|  25 --
 src/fix_ave_spatial.cpp |  73 --
 src/fix_cfd_coupling_force_implicit.cpp |  35 ---
 src/fix_massflow_mesh.cpp   |  16 --
 src/fix_mesh_surface_stress_servo.cpp   | 878 

 src/fix_neighlist_mesh.cpp  |   5 -
 src/fix_property_atom_tracer.cpp|   5 -
 src/general_container.h |   5 -
 src/general_container_I.h   |  67 --
 src/lammps.cpp  |   6 -
 src/modify_liggghts.cpp |  17 --
 src/multi_vector_container.h|   9 -
 src/neighbor.cpp|   8 -
 src/pair_gran_hooke.cpp | 267 -
 src/pair_gran_hooke_history.cpp | 826 

 src/pair_hybrid.cpp |  20 --
 src/pair_sph.cpp|  16 --
 src/read_data.cpp   |  36 ---
 src/scalar_container.h  |  15 --
 src/set.h   |   4 -
 29 files changed, 2409 deletions(-)



-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'proposed-updates'), (550, 
'stable'), (500, 'stable-debug'), (500, 'stable'), (60, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#936944: liggghts: Python2 removal in sid/bullseye

[Stuart Prescott]

The build-dependency on libpython-dev appears to be unused in the package; it 
builds just fine without libpython-dev installed and the package contents 
appear to be the same. Shall we just drop the build-dep in that case?


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#949457: mmdebstrap default variant is not "required" as documented

[Josh Triplett]

Package: mmdebstrap
Version: 0.6.0-2
Severity: normal

mmdebstrap's documentation and --help document the default variant as
"required". However, when I tried mmdebstrap, it defaulted to installing
various packages with priority "important". Passing --variant=required
produced a much smaller installation.

Please consider changing the default to "required" to match the
documentation.

Thanks,
Josh Triplett

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

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mmdebstrap depends on:
ii  apt   1.8.4
ii  perl  5.30.0-9

Versions of packages mmdebstrap recommends:
pn  arch-test   
pn  fakechroot  
ii  fakeroot1.24-1
ii  gpg 2.2.19-1
ii  mount   2.34-0.1
pn  uidmap  

Versions of packages mmdebstrap suggests:
ii  binfmt-support2.2.0-2
ii  dpkg-dev  1.19.7
pn  perl-doc  
pn  proot 
pn  qemu-user 
pn  qemu-user-static  

-- no debconf information

Bug#949456: vmdb2: grub failure with mklabel gpt

[Matt Taggart]

Package: vmdb2
Version: 0.13.2+git20191220-1

When I use the example yaml config at

https://vmdb2-manual.liw.fi/#getting-started

I get the following error:

Exec: ['chroot', '/tmp/tmpyacmp7io', 'grub-install', '--target=i386-pc', 
'--no-nvram', '--force-extra-removable', '--no-floppy', 
'--modules=part_msdos part_gpt', 
'--grub-mkdevicemap=/boot/grub/device.map', '/dev/loop0']
ERROR: Command failed: chroot /tmp/tmpyacmp7io grub-install 
--target=i386-pc --no-nvram --force-extra-removable --no-floppy 
--modules=part_msdos part_gpt --grub-mkdevicemap=/boot/grub/device.map 
/dev/loop0

b''
b"Installing for i386-pc platform.\ngrub-install: warning: this GPT 
partition label contains no BIOS Boot Partition; embedding won't be 
possible.\ngrub-install: warning: Embedding is not possible.  GRUB can 
only be installed in this setup by using blocklists.  However, 
blocklists are UNRELIABLE and their use is discouraged..\ngrub-install: 
error: will not proceed with blocklists.\n"

Something went wrong, cleaning up!


If I change the mklabel step to use msdos instead of gpt then it works.

From IRC:

 ...It is, of course, missing a magic number in the device... 
But, yes, it makes sense that the generated image is not listed in 
/boot/grub/device.map


Thanks,

--
Matt Taggart
tagg...@debian.org

Bug#947759: Configuration optimizations for the cloud variant

[Noah Meyerhans]

On Mon, Jan 20, 2020 at 04:38:55PM -0800, Josh Triplett wrote:
> Following up on this, here's a simplified list of optimizations for the
> cloud variant in one place, taking into account the previous reply.
> Would it help to get this in the form of a patch or MR on
> https://salsa.debian.org/kernel-team/linux/ ?

Hi Josh.  I started some work on integrating and testing your proposed
changes in a private branch at
https://salsa.debian.org/noahm/linux/tree/cloud-optimizations-bug947759,
but haven't gotten to the point of creating an MR yet.  I can likely
pick this up again this week, but if you create one first, that's fine
too.  One thing to note is that MR !193 changes the layout of the cloud
configs as it introduces an arm64 cloud flavour.  It hasn't been fully
reviewed yet, but there will be some merging to do if you work on your
MR independently of that.
https://salsa.debian.org/kernel-team/linux/merge_requests/193

Thank you for opening this bug!

noah

Bug#949455: vmdb2: new copy-file step

[Matt Taggart]

Package: vmdb2
Version: 0.13.2+git20191220-1
Severity: wishlist

I would like to be able to use the new copy-file step listed at

https://vmdb2-manual.liw.fi/#step-copy-file

It looks like it was added here

http://git.liw.fi/vmdb2/commit/?id=eabf1e8fc87fa581db997f2506a9ad708f1420e3

but that it didn't make it in the current version in unstable. So when 
it makes sense, please consider a new version in unstable (and maybe a 
buster backport when it goes into testing).


Thanks,

--
Matt Taggart
tagg...@debian.org

Bug#579790:

[Al Wifaq Finance]

*Sehr geehrte Damen und Herren, beantragen Sie ein schnelles und bequemes
Darlehen zur Begleichung von Rechnungen. Benötigen Sie Mittel, um ein
Unternehmen zu gründen, um sich jetzt zu bewerben und mit einem Zinssatz
von 2% genehmigt zu werden? Wir bieten alle Arten von Darlehen,
Investitionen, Projektfinanzierung und geben auch finanzielle Unterstützung
für Einzelpersonen, Körperschaften und Unternehmen weltweit. Für weitere
Informationen zu unserem Angebot kontaktieren Sie uns bitte per E-Mail:
i...@mail-customercaremarketing.com *
*Freundliche Grüße*

Bug#880407: still occurs in xterm 352-1

[Thomas Dickey]

On Mon, Jan 20, 2020 at 11:18:16PM +0100, Vincent Lefevre wrote:
> Control: reopen -1
> Control: found -1 352-1
> 
> On 2020-01-20 18:07:01 +, Sven Joachim wrote:
> > Changes:
> >  xterm (352-1) unstable; urgency=medium
> >  .
> >* New upstream release.
> >  - Adjust fontsize data to handle a minor inconsistency from recent Xft
> >versions (Closes: #880407, adapted from patch by Vincent Lefevre).
> 
> The bug still occurs with 352-1. Note that my patch was still
> working with 351-1.

The change that I used gave me the same result for the font which you
mentioned in the bug report.  You may be using some different font.

Keep in mind that you're rating a 1 or 2 pixel change in the size
as "important".  Without a screen-magnifier (or printing the data
in a log file), others won't notice this problem.

However, in reviewing the suggested change, I found that more than 90%
of the fonts on my system would be 1 pixel in error.  Less than 10%
adjusted the height consistently with ascent/descent.

Doing that test takes about a half hour on my machine, and makes it
unusable during the test.  Script is attached, feel free to run it
a few times.

The part where you're modifying the inputs to the calculation didn't
change the result for the font you specified.  Just as well (since
modifying the inputs will make the results less predictable), but if
you can identify the problem which it was intended to fix, you might
come up with a workable solution.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
#!/usr/bin/env perl
# $Id: all-xft,v 1.4 2020/01/15 01:39:37 tom Exp $
# -
# Copyright 2020 by Thomas E. Dickey
#
# All Rights Reserved
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the
# "Software"), to deal in the Software without restriction, including
# without limitation the rights to use, copy, modify, merge, publish,
# distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so, subject to
# the following conditions:
#
# The above copyright notice and this permission notice shall be included
# in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
# IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT HOLDER(S) BE LIABLE FOR ANY
# CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
# TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#
# Except as contained in this notice, the name(s) of the above copyright
# holders shall not be used in advertising or otherwise to promote the
# sale, use or other dealings in this Software without prior written
# authorization.
# -
# Use fc-list to obtain a list of TrueType font families, and execute an
# xterm-style command for each of those.

use strict;
use warnings;

use Getopt::Std;

$| = 1;

our ( $opt_d, $opt_e, $opt_s, $opt_t, $opt_x );

our @families;

sub fc_list() {
my @data;
my %result;
if ( open my $fh, "fc-list : family |" ) {
@data = sort <$fh>;
chomp @data;
close $fh;
for my $n ( 0 .. $#data ) {
my @items = split /,/, $data[$n];
for my $q ( 0 .. $#items ) {
$result{ $items[$q] } = $n;
}
}
}
return sort keys %result;
}

sub quoted($) {
my $text = shift;
$text =~ s/\\//g;
$text =~ s/"/\\"/g;
return '"' . $text . '"';
}

sub doit($) {
my $family = shift;
printf "** %s\n", $family;
my $cmd = sprintf( "%s -fa %s", $opt_x, ($family) );
$cmd .= sprintf( " -fs %s",   $opt_s )  if ($opt_s);
$cmd .= sprintf( " -xrm \"Xft.dpi: %s\"", $opt_d )  if ($opt_d);
$cmd .= sprintf( " -e %s",($opt_e) ) if ($opt_e);
$cmd = "time -p " . $cmd if ($opt_t);
system($cmd);
}

sub main::HELP_MESSAGE() {
printf STDERR <= 0 ) {
$opt_e = join( ' ', @ARGV ) unless $opt_e;
}

@families = _list;
for my $n ( 0 .. $#families ) {
( $families[$n] );
}

1;


signature.asc
Description: PGP signature

Bug#948372: Please push your changes to nibabel

[Yaroslav Halchenko]

On Mon, 20 Jan 2020, Andreas Tille wrote:

> On Mon, Jan 20, 2020 at 01:01:00PM -0500, Yaroslav Halchenko wrote:

> > > I'm fine with re-doing what I changed if you consider it really of
> > > practical relevance.  If you ask me we two would spent time we could
> > > use more productively but its OK if you want to do it.

> > You just rename and I will do the rest (push your pristine-tar, align
> > branches properly).  then debcheckout should work for old people (if
> > gitlab redirects correctly as github does in such cases), and you could
> > proceed with your work ;)

> Just ping me if you are done.  Next time I should try to move first. :-)

I guess we got some communication disconnect... anyways -- since I have
needed super-powers in debian-med I did the move myself:

- changed name and adjusted path for yours to become

https://salsa.debian.org/med-team/nibabel-andreas

- went to https://salsa.debian.org/neurodebian-team/nibabel
 and in Settings -> General -> Advanced -> Transfer

 to Debian Med to get

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

- verified -- debcheckout nibabel does the right thing, all the way from
  original elderly
  https://salsa.debian.org/neurodebian-team/pynifti.git
  redirecting to
  https://salsa.debian.org/med-team/nibabel 

- did following dance (extracting from bash history):

git remote add --fetch andreas https://salsa.debian.org/med-team/nibabel-andreas
git co --track andreas/pristine-tar
git push salsa -u pristine-tar
git co upstream
git push salsa -u upstream
git co master
git reset --hard andreas/master
git push salsa -u master


I think that should do it.  Please let me know if nothing is forgotten, and
then we could remove nibabel-andreas, and I would remove andreas remote
;)

after above I did

debcheckout nibabel  to see that it checks out old  dist/debian/proper which is
unavoidable since it  is what was in Vcs fields.  But I guess whenever you
upload new version with new Vcs -- all should work standard ways

PS note that nibabel is the core library for many python neuroimaging toolkits.
Typically before uploading it I was running our
https://github.com/neurodebian/neurodebian/blob/master/tools/nd_build_testrdepends
to see what next nibabel possibly breaks for other toolkits. I see that I
haven't done that for 3.0.0 yet, which IIRC did break API, so I expect
surprises to come with 3.0.0 upload

Cheers and thanks!
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#949454: libctf-nobfd0: missing Breaks+Replaces against libbinutils versions with the same files

[Jonathan Nieder]

Package: libctf-nobfd0
Version: 2.33.50.20200115-2
Severity: serious
Rationale: breaks upgrades

libctf-nobfd0 takes over the file libctf-nobfd.so.0.0.0 from libbinutils
but is missing a Breaks + Replaces declaring so:

 Unpacking libctf-nobfd0:amd64 (2.33.50.20200115-2) ...
 dpkg: error processing archive 
/tmp/apt-dpkg-install-YXR1z2/3-libctf-nobfd0_2.33.50.20200115-2_amd64.deb 
(--unpack):
  trying to overwrite '/usr/lib/x86_64-linux-gnu/libctf-nobfd.so.0.0.0', which 
is also in package libbinutils:amd64 2.33.50.20191121-2

Could it have

 Breaks: libbinutils (<< 2.33.50.20191128-1~)
 Replaces: libbinutils (<< 2.33.50.20191128-1~)

to address that?

Thanks,
Jonathan

Bug#949453: ITP: r-cran-gwidgetsrgtk2 -- Toolkit Implementation of gWidgets for RGtk2

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gwidgetsrgtk2 -- Toolkit Implementation of gWidgets for 
RGtk2
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-gwidgetsrgtk2
  Version : 0.0
  Upstream Author : Michael Lawrence
* URL : https://cran.r-project.org/package=gWidgetsRGtk2
* License : GPL-2+
  Programming Lang: GNU R
  Description : Toolkit Implementation of gWidgets for RGtk2
 Port of the gWidgets API to the RGtk2 toolkit.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gwidgetsrgtk2

Bug#949388: zlib: build lib64z for x32 and mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el

[YunQiang Su]

John Paul Adrian Glaubitz  于2020年1月20日周一
下午11:50写道：
>
> Hi!
>
> On 1/20/20 4:27 PM, YunQiang Su wrote:
> > @powerpc: does powerpc need it?
>
> Do you have an example package that fails to build because of memory 
> exhaustion
> of the linker? Then we could check the build logs on powerpc to see if any of
> the packages are affected.

see this thread:
https://lists.debian.org/debian-arm/2019/08/msg9.html

This is some problem we met on mips/mipsel:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879636
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849657



>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#947759: Configuration optimizations for the cloud variant

[Josh Triplett]

Following up on this, here's a simplified list of optimizations for the
cloud variant in one place, taking into account the previous reply.
Would it help to get this in the form of a patch or MR on
https://salsa.debian.org/kernel-team/linux/ ?

- Please compile in the NVME driver and the EXT4 filesystem; this will
  allow many cloud systems to avoid using an initramfs at all, which
  substantially improves boot time.

- Please consider changing the default kernel compression to LZ4, which
  decompresses much faster and thus boots faster. (Benchmarks to support
  this: https://smackerelofopinion.blogspot.com/2019/09/ ) Please
  consider doing this on the non-cloud configuration as well.

- Please disable CONFIG_ACPI_BGRT; a cloud kernel doesn't need to spend
  time or code space looking for a boot logo that won't exist.

- Please disable the CONFIG_CPU_SUP_* options for CPUs that no cloud
  provider uses (concretely, please disable everything except
  CONFIG_CPU_SUP_AMD and CONFIG_CPU_SUP_INTEL).

- Please disable CONFIG_GNSS_*, which won't be hooked up to a cloud
  server.

- Please disable CONFIG_GTP for the same reason.

- Please configure CONFIG_INPUT_MOUSEDEV as a module, not built-in, as
  most cloud servers won't have a mouse and probing for one takes time.

- Please change CONFIG_NET_MPLS_GSO from y to m. While nothing will
  automatically load it, it's sufficiently rare that loading it manually
  seems reasonable, and this would reduce attack surface and boot time.

- Please disable CONFIG_NUMA_EMU, only used to create fake-NUMA systems
  for debugging.

- Please disable CONFIG_PCIPCWATCHDOG and CONFIG_RMI4_*, which won't
  appear on a cloud server.

- Please enable CONFIG_SCHED_MC_PRIO (on both cloud and non-cloud
  kernels).

- Please disable CONFIG_VFIO_PCI_VGA and CONFIG_VGA_SWITCHEROO, which
  won't appear on cloud.

Thank you,
Josh Triplett

Bug#949452: ITP: r-cran-rsgcc -- Gini methodology-based correlation and clustering analysis of

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rsgcc -- Gini methodology-based correlation and clustering 
analysis of
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-rsgcc
  Version : 1.0.6
  Upstream Author : Copyright: (FIXME: year)-2013 Chuang Ma, Xiangfeng Wang
* URL : https://cran.r-project.org/package=rsgcc
* License : GPL-2+
  Programming Lang: GNU R
  Description : Gini methodology-based correlation and clustering analysis 
of
   microarray and RNA-Seq gene expression data
 This package provides functions for calculating
 associations between two genes with five correlation
 methods(e.g., the Gini correlation coefficient [GCC], the
 Pearson's product moment correlation coefficient [PCC], the
 Kendall tau rank correlation coefficient [KCC], the Spearman's
 rank correlation coefficient [SCC] and the Tukey's biweight
 correlation coefficient [BiWt], and three non-correlation
 methods (e.g., mutual information [MI] and the maximal
 information-based nonparametric exploration [MINE], and the
 euclidean distance [ED]). It can also been implemented to
 perform the correlation and clustering analysis of
 transcriptomic data profiled by microarray and RNA-Seq
 technologies. Additionally, this package can be further applied
 to construct gene co-expression networks (GCNs).

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-rsgcc

Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2

[Russ Allbery]

Marco d'Itri  writes:
> On Jan 20, Russ Allbery  wrote:

>> This also implies that there is arguably an SONAME issue with this library
>> given that two versions of the library with the same SONAME don't provide
>> the same symbols, but I suspect there were really, really good reasons to
>> not change the SONAME.

> The upstream maintainers choose to provide backward compatibility to old 
> binaries but not forward compatibility from old libraries.

Oh, yes, that makes sense and is entirey normal.  I was thinking about it
the wrong way around.  So the root problem is that the dependency was
satisfied for the binary but there was a stray copy of the old library
with the same SONAME in an earlier directory on the search path, which
shadowed the correct library.

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

Bug#949451: ITP: r-bioc-ctc -- Cluster and Tree Conversion

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-ctc -- Cluster and Tree Conversion
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-ctc
  Version : 1.60.0
  Upstream Author : Antoine Lucas , Laurent Gautier 

* URL : https://bioconductor.org/packages/ctc/
* License : GPL-2
  Programming Lang: GNU R
  Description : Cluster and Tree Conversion
 Tools for export and import classification trees and clusters to other
 programs.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-ctc

Bug#949449: ITP: r-cran-amap -- Another Multidimensional Analysis Package

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-amap -- Another Multidimensional Analysis Package
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-amap
  Version : 0.8
  Upstream Author : Antoine Lucas
* URL : https://cran.r-project.org/package=amap
* License : GPL-2
  Programming Lang: GNU R
  Description : Another Multidimensional Analysis Package
 Tools for Clustering and Principal Component Analysis
 (With robust methods, and parallelized functions).

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-amap

Bug#949450: thunderbird: apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg" name="/dev/shm/org.chromium.*"

[Dmitry Smirnov]

Package: thunderbird
Version: 1:68.4.1-1~deb10u1
Severity: minor

While Thunderbird is being used, kernel repeatedly logs the following:

```
audit: type=1400 audit(1579563490.921:660): apparmor="DENIED" 
operation="file_inherit" profile="thunderbird//gpg" name="/dev/shm/
org.chromium.9d3eJz" pid=23349 comm="gpg" requested_mask="r" denied_mask="r" 
fsuid=1001 ouid=1001
```

Please advise.

-- 
Best wishes,
 Dmitry Smirnov

---

Belief is the death of intelligence.
-- Robert Anton Wilson


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

Bug#949448: linux-image-5.4.0-2-amd64: PCEngines APU LEDs not working after 5.4 update

[cheetah]

Package: src:linux
Version: 5.4.8-1
Severity: normal

Between 5.3.x and 5.4.x, the APU LED driver support was changed, and now
requires an additional kconfig option to be enabled to support the LEDs on
the APU2/APU3 hardware, namely:

CONFIG_PCENGINES_APU2=m

Historical reference: 
https://salsa.debian.org/kernel-team/linux/merge_requests/101

-- Package-specific info:
** Version:
Linux version 5.4.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20200104 (Debian 9.2.1-22)) #1 SMP Debian 5.4.8-1 (2020-01-05)

** Command line:
BOOT_IMAGE=/vmlinuz-5.4.0-2-amd64 root=/dev/mapper/caracal--vg-root ro 
console=ttyS0,115200n8 quiet

** Not tainted

** Kernel log:
[35506.788578] leds_apu: No PC Engines APUv1 board detected. For APUv2,3 
support, enable CONFIG_PCENGINES_APU2

** Model information
sys_vendor: PC Engines
product_name: APU2
product_version: 1.0
chassis_vendor: PC Engines
chassis_version: 
bios_vendor: coreboot
bios_version: 4.0.7
board_vendor: PC Engines
board_name: APU2
board_version: 1.0


-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-5.4.0-2-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-5.4.0-2-amd64 recommends:
pn  apparmor 
ii  firmware-linux-free  3.4

Versions of packages linux-image-5.4.0-2-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02+dfsg1-20
pn  linux-doc-5.4   

Versions of packages linux-image-5.4.0-2-amd64 is related to:
ii  firmware-amd-graphics 20190114-2
ii  firmware-atheros  20190114-2
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20190114-2
ii  firmware-misc-nonfree 20190114-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#933065: htop: Old process name bleeds through when “Update progress names” is checked

[14mrh4x0r]

On Tue, 21 Jan 2020 00:32:18 +0100 Willem Mulder <14mrh4...@gmail.com>
wrote:
> [...]
> I took the liberty of adding the patch and creating a debdiff of it
> (which you'll find below my signature).

Of course my mail client would mess up the formatting. Here's the patch
as an attachment.

Willem
diff -Nru htop-2.2.0/debian/patches/812-fix-process-name-updates-for-shorter-strings.patch htop-2.2.0/debian/patches/812-fix-process-name-updates-for-shorter-strings.patch
--- htop-2.2.0/debian/patches/812-fix-process-name-updates-for-shorter-strings.patch	1970-01-01 01:00:00.0 +0100
+++ htop-2.2.0/debian/patches/812-fix-process-name-updates-for-shorter-strings.patch	2020-01-07 00:41:53.0 +0100
@@ -0,0 +1,24 @@
+From b9c0d6d87c5b0bf7baf81370de02c5f9b62ffb7a Mon Sep 17 00:00:00 2001
+From: Score_Under 
+Date: Tue, 10 Jul 2018 21:17:49 +0100
+Subject: [PATCH] Fix process name updates for shorter strings
+
+When a process name changes from a long string to a short string,
+truncate instead of just overwriting the beginning.
+---
+ linux/LinuxProcessList.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/linux/LinuxProcessList.c b/linux/LinuxProcessList.c
+index 2edd0425..27ead28a 100644
+--- a/linux/LinuxProcessList.c
 b/linux/LinuxProcessList.c
+@@ -709,7 +709,7 @@ static bool LinuxProcessList_readCmdlineFile(Process* process, const char* dirna
+}
+command[lastChar + 1] = '\0';
+process->basenameOffset = tokenEnd;
+-   setCommand(process, command, lastChar);
++   setCommand(process, command, lastChar + 1);
+ 
+return true;
+ }
diff -Nru htop-2.2.0/debian/patches/series htop-2.2.0/debian/patches/series
--- htop-2.2.0/debian/patches/series	2018-04-26 20:59:57.0 +0200
+++ htop-2.2.0/debian/patches/series	2020-01-07 00:38:51.0 +0100
@@ -1,2 +1,3 @@
 780-fix-option-string.patch
 fix-linux-process.patch
+812-fix-process-name-updates-for-shorter-strings.patch

Bug#933065: htop: Old process name bleeds through when “Update progress names” is checked

[Willem Mulder]

It's been a while since I reported this bug, and it doesn't look like
upstream is going to release a new version anytime soon—the last commit
was 11 months ago. However, this is quite annoying when checking the
status of e.g. Postgres processes (which include their status in their
process name), so I took the liberty of adding the patch and creating a
debdiff of it (which you'll find below my signature).

Kind regards,

Willem Mulder

diff -Nru
htop-2.2.0/debian/patches/812-fix-process-name-updates-for-shorter-strings.patch
htop-2.2.0/debian/patches/812-fix-process-name-updates-for-shorter-strings.patch
---
htop-2.2.0/debian/patches/812-fix-process-name-updates-for-shorter-strings.patch
  
 1970-01-01 01:00:00.0 +0100
+++
htop-2.2.0/debian/patches/812-fix-process-name-updates-for-shorter-strings.patch
  
 2020-01-07 00:41:53.0 +0100
@@ -0,0 +1,24 @@
+From b9c0d6d87c5b0bf7baf81370de02c5f9b62ffb7a Mon Sep 17 00:00:00 2001
+From: Score_Under 
+Date: Tue, 10 Jul 2018 21:17:49 +0100
+Subject: [PATCH] Fix process name updates for shorter strings
+
+When a process name changes from a long string to a short string,
+truncate instead of just overwriting the beginning.
+---
+ linux/LinuxProcessList.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/linux/LinuxProcessList.c b/linux/LinuxProcessList.c
+index 2edd0425..27ead28a 100644
+--- a/linux/LinuxProcessList.c
 b/linux/LinuxProcessList.c
+@@ -709,7 +709,7 @@ static bool
LinuxProcessList_readCmdlineFile(Process* process, const char* dirna
+    }
+    command[lastChar + 1] = '\0';
+    process->basenameOffset = tokenEnd;
+-   setCommand(process, command, lastChar);
++   setCommand(process, command, lastChar + 1);
+
+    return true;
+ }
diff -Nru htop-2.2.0/debian/patches/series htop-2.2.0/debian/patches/series
--- htop-2.2.0/debian/patches/series    2018-04-26 20:59:57.0 +0200
+++ htop-2.2.0/debian/patches/series    2020-01-07 00:38:51.0 +0100
@@ -1,2 +1,3 @@
 780-fix-option-string.patch
 fix-linux-process.patch
+812-fix-process-name-updates-for-shorter-strings.patch

Bug#949447: ITP: r-cran-gwidgetstcltk -- Toolkit implementation of gWidgets for tcltk package

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gwidgetstcltk -- Toolkit implementation of gWidgets for 
tcltk package
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-gwidgetstcltk
  Version : 0.0
  Upstream Author : John Verzani
* URL : https://cran.r-project.org/package=gWidgetstcltk
* License : GPL-2+
  Programming Lang: GNU R
  Description : Toolkit implementation of gWidgets for tcltk package
 Port of the gWidgets API to the tcltk package. Requires Tk 8.5 or greater.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gwidgetstcltk

Bug#948904: spf-engine 2.9.2-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948904 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: spf-engine
Version: 2.9.2-0+deb10u1

Explanation: fix privilege managment at startup so Unix sockets work; update 
documentation for TestOnly

Bug#949430: webkit2gtk: FTBFS: fatal error: X11/Xlib-xcb.h: No such file or directory

[Alberto Garcia]

Control: tags -1 pending

On Mon, Jan 20, 2020 at 08:44:30PM +0100, Mattia Rizzolo wrote:
> In file included from 
> ../Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:64:
> /usr/include/gstreamer-1.0/gst/gl/x11/gstgldisplay_x11.h:26:10: fatal error: 
> X11/Xlib-xcb.h: No such file or directory
>26 | #include 
>   |  ^~~~

Thanks, I was aware of the problem and it will be fixed in the next
upload.

See also #948143.

Thanks,

Berto

Bug#949446: python3-ipython: Prevents sage fro starting, fails to import _baseclass_reprs

[Amaury Pouly]

Package: python3-ipython
Version: 7.11.1-1
Severity: important

Dear Maintainer,

Sagemath is not usable on my system because of an import error. I am not sure 
if the issue
lies with sage or with ipython. Here is the backtrace:

Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/sage/repl/ipython_kernel/__main__.py", 
line 3, in 
IPKernelApp.launch_instance(kernel_class=SageKernel)
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 
663, in launch_instance
app.initialize(argv)
  File "", line 2, in initialize
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 
87, in catch_config_error
return method(app, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 542, in 
initialize
self.init_kernel()
  File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 447, in 
init_kernel
user_ns=self.user_ns,
  File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line 
412, in instance
inst = cls(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/sage/repl/ipython_kernel/kernel.py", 
line 51, in __init__
super(SageKernel, self).__init__(**kwds)
  File "/usr/lib/python3/dist-packages/ipykernel/ipkernel.py", line 68, in 
__init__
kernel  = self,
  File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line 
412, in instance
inst = cls(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line 
683, in __init__
self.init_display_formatter()
  File "/usr/lib/python3/dist-packages/sage/repl/interpreter.py", line 231, in 
init_display_formatter
backend.get_display_manager().switch_backend(backend, shell=self)
  File 
"/usr/lib/python3/dist-packages/sage/repl/rich_output/display_manager.py", line 
322, in switch_backend
self._backend.install(**kwds)
  File 
"/usr/lib/python3/dist-packages/sage/repl/rich_output/backend_ipython.py", line 
59, in install
from sage.repl.display.formatter import SageDisplayFormatter
  File "/usr/lib/python3/dist-packages/sage/repl/display/formatter.py", line 
66, in 
from sage.repl.display.pretty_print import SagePrettyPrinter
  File "/usr/lib/python3/dist-packages/sage/repl/display/pretty_print.py", line 
29, in 
from sage.repl.display.fancy_repr import *
  File "/usr/lib/python3/dist-packages/sage/repl/display/fancy_repr.py", line 
17, in 
from IPython.lib.pretty import (
ImportError: cannot import name '_baseclass_reprs' from 'IPython.lib.pretty' 
(/usr/lib/python3/dist-packages/IPython/lib/pretty.py)

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

Kernel: Linux 5.4.2-amdmp2 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-ipython depends on:
ii  python3 3.7.5-3
ii  python3-backcall0.1.0-2
ii  python3-decorator   4.3.0-1.1
ii  python3-jedi0.15.2-1
ii  python3-pexpect 4.6.0-1
ii  python3-pickleshare 0.7.5-1
ii  python3-pkg-resources   44.0.0-1
ii  python3-prompt-toolkit  2.0.10-2
ii  python3-pygments2.3.1+dfsg-1
ii  python3-traitlets   4.3.3-2

python3-ipython recommends no packages.

python3-ipython suggests no packages.

-- no debconf information

Bug#947832: cups 2.2.10-6+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 947832 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cups
Version: 2.2.10-6+deb10u2

Explanation: fix memory leak in ppdOpen; fix validation of default language in 
ippSetValuetag [CVE-2019-2228]

Bug#948979: dkimpy-milter 1.0.3-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948979 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: dkimpy-milter
Version: 1.0.3-1

Explanation: fix privilege managment at startup so Unix sockets work

Bug#947834: cups 2.2.1-8+deb9u5 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 947834 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: cups
Version: 2.2.1-8+deb9u5

Explanation: fix validation of default language in ippSetValuetag 
[CVE-2019-2228]

Bug#948988: postfix 3.4.8-0+10debu1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948988 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: postfix
Version: 3.4.8-0+10debu1

Explanation: new upstream stable release

Bug#948826: brightd 0.4.1-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948826 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: brightd
Version: 0.4.1-2+deb10u1

Explanation: actually compare the value read out of 
/sys/class/power_supply/AC/online with '0'

Bug#949445: RFS: vnstat/2.6-1 -- console-based network traffic monitor

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "vnstat"

 * Package name: vnstat
   Version : 2.6-1
   Upstream Author : Teemu Toivola 
 * URL : https://humdi.net/vnstat/
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/vnstat
   Section : net

It builds those binary packages:

  vnstat - console-based network traffic monitor
  vnstati - image output support for vnStat

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.6-1.dsc

Changes since the last upload:

   * New upstream version 2.6
 .
   * d/control:
 - move vcs to shared salsa/debian repository
 - add Rob Savoury to maintainer team
 - use dephelper-compat dependency instead of d/compat
 - bump to std version 4.5.0 (no further changes)
   * d/salsa-ci.yml: add standard salsa-ci configuration
   * d/copyright: fix artifact, use https and bump to 2020
   * d/postrm: ignore userdel failure
   * d/patches:
 - rebase to v2.6 and drop upstream applied ones
 - handle all occurrences of /var/run in pidfile patch
 - add patch to fix salsa-ci reprotest

Regards,

--
  Christian Göttsche

Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2

[Marco d'Itri]

On Jan 20, Russ Allbery  wrote:

> This also implies that there is arguably an SONAME issue with this library
> given that two versions of the library with the same SONAME don't provide
> the same symbols, but I suspect there were really, really good reasons to
> not change the SONAME.
The upstream maintainers choose to provide backward compatibility to old 
binaries but not forward compatibility from old libraries.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#948257: "depmod: ERROR: ..." still occurs

[Vincent Lefevre]

Control: notfound -1 0.136
Control: fixed -1 0.136

On 2020-01-20 18:36:24 +, Ben Hutchings wrote:
> On Mon, 2020-01-20 at 10:30 +0100, Vincent Lefevre wrote:
> > Control: reopen -1
> > Control: found -1 0.136
> > 
> > After the Linux kernel upgrade (initramfs-tools was upgrade to 0.136
> > earlier), I still get many errors
> > 
> > depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not 
> > open builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'
> 
> But that has nothing to do with initramfs-tools.  You should reopen
> #948350.

Indeed, this does not occur during update-initramfs. I've opened
a new bug (this is different from #948350):

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

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

Bug#948650: stretch-pu: package nginx/1.10.3-1+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-01-11 at 12:19 +0200, Christos Trochalakis wrote:
> I'd like to upload nginx 1.10.3-1+deb9u4, addressing the non-critical
> CVE-2019-20372.
> 

Please go ahead, thanks.

Regards,

Adam

Bug#949367: stretch-pu: package wpa/2:2.4-1+deb9u5

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Mon, 2020-01-20 at 10:02 +0100, Andrej Shadura wrote:
>  wpa (2:2.4-1+deb9u5) stretch; urgency=medium
>  .
>* SECURITY UPDATE:
>  - AP mode PMF disconnection protection bypass.
>More details:
> + https://w1.fi/security/2019-7/
>Closes: #940080 (CVE-2019-16275)
> 

As wpa builds a udeb, this will need a d-i ack. Tagging and CCing to
that end.

Regards,

Adam

Bug#948652: buster-pu: package nginx/1.14.2-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-01-11 at 12:24 +0200, Christos Trochalakis wrote:
> I'd like to upload nginx 1.14.2-2+deb10u2, addressing the non-
> critical
> CVE-2019-20372.
> 

Please go ahead.

Regards,

Adam

Bug#949444: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/[...]/modules.builtin.bin'

[Vincent Lefevre]

Package: kmod
Version: 26+20191223-1
Severity: important

When installing a *new* Linux kernel 5.4.0-3-amd64, I got 3567 errors

depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'

after

Setting up linux-image-5.4.0-3-amd64 (5.4.13-1) ...

I've attached the log with most error messages removed.

Note: This appears to be different from bug 948350 as the path is not
the same (starting with "/lib/modules" here instead of "/var/tmp/"),
and this occurs after "Setting up linux-image-5.4.0-3-amd64" and not
during update-initramfs.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kmod depends on:
ii  libc6  2.29-9
ii  libkmod2   26+20191223-1
ii  liblzma5   5.2.4-1+b1
ii  libssl1.1  1.1.1d-2
ii  lsb-base   11.1.0

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Preparing to unpack .../0-linux-compiler-gcc-9-x86_5.4.13-1_amd64.deb ...
Unpacking linux-compiler-gcc-9-x86 (5.4.13-1) over (5.4.8-1) ...
Preparing to unpack .../1-linux-doc_5.4.13-1_all.deb ...
Unpacking linux-doc (5.4.13-1) over (5.4.8-1) ...
Preparing to unpack .../2-linux-doc-5.4_5.4.13-1_all.deb ...
Unpacking linux-doc-5.4 (5.4.13-1) over (5.4.8-1) ...
Selecting previously unselected package linux-headers-5.4.0-3-common.
Preparing to unpack .../3-linux-headers-5.4.0-3-common_5.4.13-1_all.deb ...
Unpacking linux-headers-5.4.0-3-common (5.4.13-1) ...
Preparing to unpack .../4-linux-kbuild-5.4_5.4.13-1_amd64.deb ...
Unpacking linux-kbuild-5.4 (5.4.13-1) over (5.4.8-1) ...
Selecting previously unselected package linux-headers-5.4.0-3-amd64.
Preparing to unpack .../5-linux-headers-5.4.0-3-amd64_5.4.13-1_amd64.deb ...
Unpacking linux-headers-5.4.0-3-amd64 (5.4.13-1) ...
Preparing to unpack .../6-linux-headers-amd64_5.4.13-1_amd64.deb ...
Unpacking linux-headers-amd64 (5.4.13-1) over (5.4.8-1) ...
Selecting previously unselected package linux-image-5.4.0-3-amd64.
Preparing to unpack .../7-linux-image-5.4.0-3-amd64_5.4.13-1_amd64.deb ...
Unpacking linux-image-5.4.0-3-amd64 (5.4.13-1) ...
Preparing to unpack .../8-linux-image-amd64_5.4.13-1_amd64.deb ...
Unpacking linux-image-amd64 (5.4.13-1) over (5.4.8-1) ...
Preparing to unpack .../9-linux-libc-dev_5.4.13-1_amd64.deb ...
Unpacking linux-libc-dev:amd64 (5.4.13-1) over (5.4.8-1) ...
Setting up linux-image-5.4.0-3-amd64 (5.4.13-1) ...
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'
[...]
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.4.0-2-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.4.0-2-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.4.0-3-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.4.0-3-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.4.0-3-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: .background_cache.png
Found linux image: /boot/vmlinuz-5.4.0-3-amd64
Found initrd image: /boot/initrd.img-5.4.0-3-amd64
Found linux image: /boot/vmlinuz-5.4.0-2-amd64
Found initrd image: /boot/initrd.img-5.4.0-2-amd64
Found linux image: /boot/vmlinuz-5.4.0-1-amd64
Found initrd image: /boot/initrd.img-5.4.0-1-amd64
Found linux image: /boot/vmlinuz-4.19.0-6-amd64
Found initrd image: /boot/initrd.img-4.19.0-6-amd64
done
Setting up linux-libc-dev:amd64 (5.4.13-1) ...
Setting up linux-image-amd64 (5.4.13-1) ...
Setting up linux-compiler-gcc-9-x86 (5.4.13-1) ...
Setting up linux-kbuild-5.4 (5.4.13-1) ...
Setting up linux-headers-5.4.0-3-common (5.4.13-1) ...
Setting up linux-doc-5.4 (5.4.13-1) ...
Setting up linux-doc (5.4.13-1) ...
Setting up linux-headers-5.4.0-3-amd64 (5.4.13-1) ...
Setting up linux-headers-amd64 (5.4.13-1) ...

Bug#949443: ITP: r-cran-gwidgets -- gWidgets API for Toolkit-Independent, Interactive GUIs

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gwidgets -- gWidgets API for Toolkit-Independent, 
Interactive GUIs
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-gwidgets
  Version : 0.0
  Upstream Author : John Verzani
* URL : https://cran.r-project.org/package=gWidgets
* License : GPL-2+
  Programming Lang: GNU R
  Description : gWidgets API for Toolkit-Independent, Interactive GUIs
 Provides a toolkit-independent API for building interactive GUIs. At
 least one of the 'gWidgetsXXX packages', such as gWidgetstcltk, needs to
 be installed. Some icons are on loan from the scigraphica project
 .

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gwidgets

Bug#949441: RFS: disk-filltest/0.8.1-1 [ITP] -- Simple Tool to Detect Bad Disks by Filling with Random Data

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "disk-filltest"

 * Package name: disk-filltest
   Version : 0.8.1-1
   Upstream Author : Timo Bingmann 
 * URL : https://panthema.net/2013/disk-filltest/
 * License : GPL-3.0+
 * Vcs : https://github.com/sudipm-mukherjee/disk-filltest
   Section : utils

It builds those binary packages:

  disk-filltest - Simple Tool to Detect Bad Disks by Filling with Random Data

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

  https://mentors.debian.net/package/disk-filltest

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/disk-filltest/disk-filltest_0.8.1-1.dsc

Changes since the last upload:

   * Initial release (Closes: #949307)


-- 
Regards
Sudip

Bug#880407: still occurs in xterm 352-1

[Vincent Lefevre]

Control: reopen -1
Control: found -1 352-1

On 2020-01-20 18:07:01 +, Sven Joachim wrote:
> Changes:
>  xterm (352-1) unstable; urgency=medium
>  .
>* New upstream release.
>  - Adjust fontsize data to handle a minor inconsistency from recent Xft
>versions (Closes: #880407, adapted from patch by Vincent Lefevre).

The bug still occurs with 352-1. Note that my patch was still
working with 351-1.

What has been done in fontutils.c is:

@@ -2912,6 +2921,17 @@
ascent = font->ascent;
descent = font->descent;
if (height < ascent + descent) {
+   if ((ascent + descent) > (height + 1)) {
+   /* this happens less than 10% of the time */
+   --ascent;
+   --descent;
+   } else if (ascent > descent) {
+   /* this is the usual case */
+   --ascent;
+   } else {
+   /* this could happen, though rare... */
+   --descent;
+   }
TRACE(("...increase height from %d to %d\n", height, ascent + 
descent));
height = ascent + descent;
}

I don't know why, but I needed to modify font->ascent, font->descent
and font->height too... well, at least the first two, i.e. using

ascent = --font->ascent;

and

descent = --font->descent;

solves the problem. Alternatively, add "font->" everywhere, and set

ascent = font->ascent;
descent = font->descent;
height = ascent + descent;

only at the end.

Note: for easier readablility, I also suggest to change the test

if (height < ascent + descent) {

to

if ((ascent + descent) > height) {

in order to be similar to the test on the next line.

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

Bug#949442: ITP: r-cran-parmigene -- Parallel Mutual Information to establish Gene Networks

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-parmigene -- Parallel Mutual Information to establish Gene 
Networks
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-parmigene
  Version : 1.0.2
  Upstream Author : Gabriele Sales 
* URL : https://cran.r-project.org/package=parmigene
* License : AGPL-3
  Programming Lang: GNU R
  Description : Parallel Mutual Information to establish Gene Networks
 The package provides a parallel estimation of the mutual
 information based on entropy estimates from k-nearest neighbors
 distances and algorithms for the reconstruction of gene
 regulatory networks.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-parmigene

Bug#947941: alpine: 2.22 released

[Amit Gurdasani]

Package: alpine
Version: 2.21+dfsg1-1.1
Followup-For: Bug #947941

Dear Maintainer,

Alpine 2.22 appears to have been released. Please consider packaging the new 
release as it seems to include important enhancements (such as XOAUTH2 support 
and TLS 1.3 support, as well as the ability to be built against LibreSSL).

http://alpine.x10host.com/alpine/release/
https://repo.or.cz/alpine.git

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

Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages alpine depends on:
ii  libc6 2.29-9
ii  libgssapi-krb5-2  1.17-6
ii  libkrb5-3 1.17-6
ii  libldap-2.4-2 2.4.48+dfsg-1+b2
ii  libpam0g  1.3.1-5
ii  libssl1.1 1.1.1d-2
ii  libtinfo6 6.1+20191019-1
ii  mlock 8:2007f~dfsg-7+b1

Versions of packages alpine recommends:
ii  alpine-doc  2.21+dfsg1-1.1

Versions of packages alpine suggests:
ii  aspell0.60.8-1
ii  ssmtp [mail-transport-agent]  2.64-8.1+b1

-- no debconf information

Bug#949440: chromium: Blank window when used over ssh tunnel

[Paul Szabo]

Package: chromium
Version: 79.0.3945.130-1~deb10u1
Severity: normal

Up until version 78, chromium (and google-chrome) worked just fine.
Since the update to version 79, chromium (and google-chrome) does not
work over an ssh tunnel, but only shows a blank (grey?) window.

To reproduce: connect to some remote (or very same) machine with
"ssh -X user@machine" and run chromium there.

For google-chrome, I found a workaround: using the option
  --use-gl=swiftshader
allows it to work (even over ssh), but the same option does not help
for chromium. See also:
  https://support.google.com/chrome/thread/23330705

Thanks, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia


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

Kernel: Linux 4.19.67-pk10.17-amd64 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  chromium-common  79.0.3945.130-1~deb10u1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.3.0-6
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.4-1~deb10u1
ii  libavformat587:4.1.4-1~deb10u1
ii  libavutil56  7:4.1.4-1~deb10u1
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.2.10-6+deb10u1
ii  libdbus-1-3  1.12.16-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-2+deb10u1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1+deb10u2
ii  libopenjp2-7 2.3.0-2
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4+deb10u1
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.3.0-6
ii  libvpx5  1.7.0-3+deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  79.0.3945.130-1~deb10u1

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n79.0.3945.130-1~deb10u1
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox   79.0.3945.130-1~deb10u1
ii  dunst [notification-daemon]1.3.2-1
ii  fonts-liberation   1:1.07.4-9
ii  gnome-flashback [notification-daemon]  3.30.0-3
ii  gnome-shell [notification-daemon]  3.30.2-11~deb10u1
ii  libgl1-mesa-dri18.3.6-2
ii  libu2f-udev1.1.9-1
ii  notification-daemon3.20.0-4
ii  upower 0.99.10-1
ii  xfce4-notifyd [notification-daemon]0.4.3-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  8.3.0-6
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

-- no debconf information

Bug#949439: evolution: Please switch from enchant(1) to enchant-2

[Boyuan Yang]

Source: evolution
Version: 3.34.1-2
Severity: normal
X-Debbugs-CC: jbi...@debian.org la...@debian.org bi...@debian.org
Tags: sid bullseye
Control: blocks 947979 by -1

Dear evolution maintainers,

Package enchant-2 is now in Debian unstable and testing, please switch from
enchant to enchant-2 (libenchant-dev -> libenchant-2-dev).

The original libenchant 1.x is old and no longer maintained upstream. The
detail about the transition can be found at 
https://release.debian.org/transitions/html/enchant-2.html .

The evolution upstream is already supporting enchant 2.x. Please make the
switch and test accordingly. According to 
https://sources.debian.org/src/evolution/3.34.1-2/CMakeLists.txt/#L282 , it
should be better if the dependency is switched together with other related
packages, like gspell and webkitgtk+.

-- 
Regards,
Boyuan Yang


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

Bug#949438: lincredits: diff for NMU version 0.8+nmu1

[Boyuan Yang]

Control: tags 949438 + patch
Control: tags 949438 + pending

Dear maintainer,

I've prepared an NMU for lincredits (versioned as 0.8+nmu1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru lincredits-0.8/debian/changelog lincredits-0.8+nmu1/debian/changelog
--- lincredits-0.8/debian/changelog 2019-11-16 20:33:57.0 -0500
+++ lincredits-0.8+nmu1/debian/changelog2020-01-20 16:48:43.0
-0500
@@ -1,3 +1,11 @@
+lincredits (0.8+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * No-change source-only upload to allow testing migration.
+(Closes: #949438)
+
+ -- Boyuan Yang   Mon, 20 Jan 2020 16:48:43 -0500
+
 lincredits (0.8) unstable; urgency=medium
 
   * Update to Python 3. (Closes: #936949)


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

Bug#948697: apt-listbugs: Listbugs-spawned QueryBTS can't find Firefox

[Calum McConnell]

Below is the email I accidentally sent directly to the maintainer,
instead of pressing reply-all

> > Sorry about taking so long to get back to you: I have been really
> > busy
> > recently.
> 
> No problem, I got ill immediately afterwards!  :-/

That sucks, hope you're doing better!

> But now, I finally found some time to spend on investigating this
> bug.
> I have mixed news for you.
> 
> [...]
> > > First of all: it seems to me that you have firefox-esr unpacked,
> > > but
> > > not configured. In other words, firefox-esr does not seem to be
> > > properly installed on your system:
> > > 
> > > [from System Information in your bug report...]
> > > > iu  firefox-esr [www-browser]  68.4.1esr-1
> > > [...]
> > > 
> > > This could be responsible for a number of errors you encounter,
> > > when
> > > trying to start firefox...
> > 
> > Okay.  I did test a bit, and firefox is definatly working: so if
> > its
> > not unpacked, then somthing weird is going on...
> 
> Did you fix the installation status of firefox-esr?
> What's the output of the command
> 
>   $ dpkg -l | grep firefox
> 
> on your system, now?

I put it below: I did some re-wrapping of lines, because I couldnt
quickly figure out how to make evolution stop wrapping the selection.

$ dpkg -l | grep firefox
ii  firefox-esr   
68.4.1esr-1  amd64
Mozilla Firefox web browser - Extended Support Release (ESR)

> As explained below, this is not the cause of your errors, but
> something
> to be fixed anyway...
> 
> > > I guess xdg-open (internally used by querybts to find a browser)
> > > eventually selected a text browser, such as lynx or w3m:
> > 
> > It did.  I think the errors made that more clear: I'm setting up a
> > controlled test to capture a few.
> [...]
> 
> Now I managed to reproduce the issue, at least with a bunch of
> similar
> errors from firefox (including dialog windows to click into).
> The key point is that you are using "sudo" to become root, while I
> use
> "su -", thus missing one subtle difference.
> 
> Your controlled test was useful in clarifying what you experienced.
> Thanks for taking the time to transcript it (and comment it!).
No problem

> So, without further ado, what happened?
> 
>  • regular user calls sudo to run apt as root
>  • apt calls apt-listbugs
>  • apt-listbugs invokes s6-setuidgid to drop root privileges and run
>querybts as the original regular user
>  • querybts wants to invoke a browser and calls xdg-open on the URL
> 
> [...]
> 
> OK, I think I shared enough of my headache!   ;-)

Thanks for the explaination: it's all making sence now.

> [...]
> 
> Of course, I could completely drop these features, so that apt-
> listbugs
> will no longer be able to invoke querybts or to launch a browser.
> After all, there are other, more comfortable, ways to read bug logs.
> Usually, if you are already in a graphical session, you can start
> your
> favorite browser and copy and paste the bug numbers there. This can
> perhaps be possible even when switching between text consoles...
> 
> But I think there are situations where these strategies are not
> available. Maybe you are stuck in a single text console, and no other
> means to access the web...
> As a consequence, I would like to keep these features, although I
> should probably document that they should be regarded as "last
> resort" approaches...

There is also the fact that it is somtimes handy to be able to get a
full view of the bug quicky: so while copy-paste replicates the
functionality, it also drops the convinience of being able to get more
info about bugs with minimal effort.

> I could drop the s6-setuidgid trick (which will be replaced by
> setpriv in the next version of apt-listbugs, which is however
> equivalent). But running querybts or a browser as root is not a good
> idea, security-wise, and should hence be avoided, wherever possible.
> So, no, I would like to keep the root privilege dropping mechanism,
> to the maximum possible extent.
> 
> Maybe apt-listbugs could drop the DISPLAY enviroment variable before
> invoking querybts or any browser.
> The equivalent of 
> 
>   $ sudo env -u DISPLAY -u XAUTHORITY s6-setuidgid MYREGULARUSER xdg-
> open http://bugs.debian.org/948697
> 
> which directly chooses a text browser, which many less needs than
> firefox!
> I acknowledge that this is not a perfect workaround, but, at least,
> it
> seems to reduce to the more minimalist situations, where the features
> are really needed...
> 
> Let me think about it some more (and feel free to express your
> thoughts!).

That definatly would work for me.  The importance of apt-listbugs, to
me, is being able to take a look at what might break, weigh its
importance, and making a decision on whether or not I should upgrade. 
I can't really think of a reason why reading the bug info in a text
browser would fail to accomplish that goal just as well as a full-
fledged web browser: and if there is some 

Bug#949438: lincredits: Please rebuild package to allow testing migration

[Boyuan Yang]

Package: lincredits
Severity: important
Version: 0.8

Dear lincredits maintainer,

The latest upload of your package (lincredits) was not a source-only upload.
As a result, it will not migrate to Debian Testing.

Since July 2019, all uploads have to be source-only upload to be able to
migrate to Testing. For details about source-only upload, please see 
https://wiki.debian.org/SourceOnlyUpload .

Please make another source-only upload to allow the new version to migrate to
Testing. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#949326: [Pkg-kde-extras] Bug#949326: transition: libgwenhywfar

[Micha Lenk]

Control: tags -1 moreinfo

On 20.01.20 09:52, Pino Toscano wrote:

Since you are already updating Gwenhywfar, can you please update it to
the newly released 5.1.2?


Just uploaded to experimental.


The newly released version of KMyMoney (5.0.8) requires:
- Gwenhywfar >= 5.1.2
- AqBanking >= 6.0.1


I looked into that and just realized this version of AqBanking did a 
SONAME bump as well. This means its uploads will go through NEW. :(



* https://tracker.debian.org/kmymoney will need a binNMU to pick up the new
   SONAME from libgwenhywfar.


Did you rebuild KMyMoney with the new Gwenhywfar? Does it build fine?


I will, once libaqbanking/6.0.1 cleared the NEW queue. I will update 
this bug with more information as soon as I have them.


Pino, thank you for making me realize that this transition isn't ready 
yet. This saved us some frustration later on.


Regards,
Micha

Bug#943398: linux-perf-5.2: perf report segmentation fault

[Bernhard Übelacker]

Hello Salvatore,

> Can you report the issue directly upstream?
Will do, but I am not sure exactly to where.

I found the MAINTAINERS file and I guess if there
is no "B:" line it has to be reported to the "L:" list ?

Kind regards,
Bernhard

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n12936

Bug#949437: postorius: FTBFS and autopkgtest failure (needs update for new version of mailmanclient

[Paul Gevers]

Source: postorius
Version: 1.2.4-1
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:mailmanclient

[X-Debbugs-CC: debian...@lists.debian.org,
mailmancli...@packages.debian.org]

Dear maintainers,

With a recent upload of mailmanclient the autopkgtest of postorius fails
in testing when that autopkgtest is run with the binary packages of
mailmanclient from unstable. If fails during the build, on
reproducible-builds infra you can see if failing on armhf. It passes
when run with only packages from testing. In tabular form:
   passfail
mailmanclient  from testing3.3.0-1
postorius  from testing1.2.4-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of mailmanclient to
testing [1]. Of course, mailmanclient shouldn't just break your
autopkgtest (or even worse, your package), but somehow I guess that the
change in mailmanclient was intended and your package needs to update to
the new situation. If not, feel free to reassign to mailmanclient.

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/p/postorius/4038349/log.gz

==
ERROR: test_list_options_shows_all_addresses
(postorius.tests.mailman_api_tests.test_user.MailmanUserTest)
--
Traceback (most recent call last):
  File "example_project/postorius/tests/mailman_api_tests/test_user.py",
line 167, in test_list_options_shows_all_addresses
address.verify()
  File
"/usr/lib/python3/dist-packages/mailmanclient/restobjects/address.py",
line 75, in verify
self._connection.call(
  File
"/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py",
line 91, in call
response = request(
  File "/usr/lib/python3/dist-packages/requests/api.py", line 60, in request
return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 533,
in request
resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 646,
in send
r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439,
in send
resp = conn.urlopen(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line
665, in urlopen
httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line
412, in _make_request
httplib_response = conn.getresponse(buffering=True)
  File "/usr/lib/python3/dist-packages/vcr/stubs/__init__.py", line 231,
in getresponse
raise CannotOverwriteExistingCassetteException(
vcr.errors.CannotOverwriteExistingCassetteException: Can't overwrite
existing cassette
('/tmp/autopkgtest-lxc.jqexguc2/downtmp/build.aFf/src/example_project/postorius/tests/fixtures/vcr_cassettes/MailmanUserTest.test_list_options_shows_all_addresses.yaml')
in your current record mode ('once').
No match for the request (http://localhost:9001/3.0/addresses/anotheremail%40example.com/verify>)
was found.
Found 8 similar requests with 1 different matcher(s) :

1 - (http://localhost:9001/3.0/domains>).
Matchers succeeded : ['method', 'scheme', 'host', 'port', 'query']
Matchers failed :
path - assertion failure :
/3.0/addresses/anotheremail%40example.com/verify != /3.0/domains

2 - (http://localhost:9001/3.0/lists>).
Matchers succeeded : ['method', 'scheme', 'host', 'port', 'query']
Matchers failed :
path - assertion failure :
/3.0/addresses/anotheremail%40example.com/verify != /3.0/lists

3 - (http://localhost:9001/3.1/users>).
Matchers succeeded : ['method', 'scheme', 'host', 'port', 'query']
Matchers failed :
path - assertion failure :
/3.0/addresses/anotheremail%40example.com/verify != /3.1/users

4 - (http://localhost:9001/3.0/members>).
Matchers succeeded : ['method', 'scheme', 'host', 'port', 'query']
Matchers failed :
path - assertion failure :
/3.0/addresses/anotheremail%40example.com/verify != /3.0/members

5 - (http://localhost:9001/3.0/users/996/addresses>).
Matchers succeeded : ['method', 'scheme', 'host', 'port', 'query']
Matchers failed :
path - assertion failure :
/3.0/addresses/anotheremail%40example.com/verify 

Bug#949264: nageru: FTBFS on arm/i386/mipsel architectures

[Steinar H. Gunderson]

On Mon, Jan 20, 2020 at 04:32:14PM -0500, Boyuan Yang wrote:
> In this case a rebuild might be worthwhile anyway. Rebuilding package is
> almost always harmless.

Well, rebuilding movit would fix it, but it would also break any reverse
dependency, so they would also need to be rebuilt. And if my theory is right,
this might affect other libraries (although taking in this specific type and
using C++ might not be that common).

> Are you going to trigger the rebuild recently? If not, I can help to trigger
> it through NMU.

I don't intend to do a Movit upload anytime soon, no, and I if I did one,
it would be unlikely to contain a soname bump.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#949435: apt-ftparchive: package filenames are not canonicalized

[Robin Gustafsson]

Package: apt-utils
Version: 1.8.2
Severity: minor

Dear Maintainer,

Packages files created by apt-ftparchive will sometimes contain non-
canonicalized filenames, e.g. "./pool/dummy_1.0_all.deb". This conflicts with
the field's format specification, according to the wiki
(https://wiki.debian.org/DebianRepository/Format#Filename).

The problem occurs whenever the "path" parameter contains "." or ".." in any
combination. Presumably, the path is just used as-is without any attempt at
canonicalization.

Steps to reproduce (one example):

  equivs-build /dev/null
  apt-ftparchive packages .

The resulting output will contain a Filename field with a non-canonical path:

  Filename: ./equivs-dummy_1.0_all.deb


Regards,
Robin


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores)
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=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-utils depends on:
ii  apt 1.8.2
ii  libapt-inst2.0  1.8.2
ii  libapt-pkg5.0   1.8.2
ii  libc6   2.28-10
ii  libdb5.35.3.28+dfsg1-0.5
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

apt-utils recommends no packages.

apt-utils suggests no packages.

-- no debconf information

Bug#949436: firmware-iwlwifi: Got an HT rate (flags:0x88/mcs:15) for a non data frame

[Patrice Duroux]

Package: firmware-iwlwifi
Version: 20190717-2
Severity: normal

Dear Maintainer,

I am reporting this «exception» here without being sure this is the right
package or if it has been already reported (not easy to check).

Thanks,
Patrice


[   48.335755] [ cut here ]
[   48.335766] Got an HT rate (flags:0x88/mcs:15) for a non data frame
[   48.335839] WARNING: CPU: 7 PID: 543 at
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:333
iwl_mvm_get_tx_rate.isra.0+0xc0/0xd0 [iwlmvm]
[   48.335842] Modules linked in: fuse ctr ccm rfcomm bnep bbswitch(OE) uinput
binfmt_misc intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi nls_ascii
nls_cp437 x86_pkg_temp_thermal intel_powerclamp vfat coretemp fat iwlmvm btusb
btrtl btbcm btintel mei_wdt ppdev bluetooth mac80211 libarc4 kvm
snd_hda_codec_realtek snd_hda_codec_generic efi_pstore irqbypass ledtrig_audio
iwlwifi uvcvideo intel_cstate snd_hda_intel intel_uncore snd_intel_nhlt
videobuf2_vmalloc snd_hda_codec videobuf2_memops videobuf2_v4l2 drbg
intel_rapl_perf cfg80211 joydev hp_wmi snd_hda_core videobuf2_common
sparse_keymap pcspkr efivars ansi_cprng wmi_bmof serio_raw snd_hwdep videodev
snd_pcm snd_timer rtsx_pci_ms ecdh_generic iTCO_wdt ecc mei_me snd
iTCO_vendor_support tpm_infineon sg rfkill parport_pc memstick mei mc soundcore
watchdog ie31200_edac parport tpm_tis tpm_tis_core tpm hp_accel hp_wireless
lis3lv02d input_polldev evdev rng_core ac efivarfs ip_tables x_tables autofs4
ext4 crc16 mbcache jbd2 raid10 raid456
[   48.335946]  async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod dm_mirror
dm_region_hash dm_log dm_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel
i915 ghash_clmulni_intel rtsx_pci_sdmmc mmc_core ahci libahci xhci_pci
i2c_algo_bit mxm_wmi xhci_hcd aesni_intel drm_kms_helper libata crypto_simd
ehci_pci ehci_hcd drm scsi_mod rtsx_pci psmouse e1000e usbcore cryptd
glue_helper i2c_i801 lpc_ich mfd_core ptp pps_core usb_common battery video wmi
button
[   48.336015] CPU: 7 PID: 543 Comm: irq/37-iwlwifi Tainted: G   OE
5.4.0-3-amd64 #1 Debian 5.4.13-1
[   48.336018] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, BIOS M70
Ver. 01.25 08/29/2019
[   48.336039] RIP: 0010:iwl_mvm_get_tx_rate.isra.0+0xc0/0xd0 [iwlmvm]
[   48.336045] Code: 41 5d 09 d0 c3 0f 0b 31 db eb d4 80 3d d5 d7 02 00 00 75
81 0f b7 f1 48 c7 c7 00 22 54 c1 c6 05 c2 d7 02 00 01 e8 be e2 35 c8 <0f> 0b 0f
be 55 08 89 d3 e9 5e ff ff ff 0f 1f 00 0f 1f 44 00 00 40
[   48.336048] RSP: 0018:b7f74056b110 EFLAGS: 00010282
[   48.336053] RAX:  RBX: 000f RCX:
0006
[   48.336055] RDX: 0007 RSI: 0096 RDI:
9f89279d7680
[   48.336058] RBP: b7f74056b278 R08: 0457 R09:
0004
[   48.336061] R10:  R11: 0001 R12:
9f891f7448a0
[   48.336065] R13: 9f8924562bd0 R14: b7f74056b278 R15:
4188
[   48.336069] FS:  () GS:9f89279c()
knlGS:
[   48.336073] CS:  0010 DS:  ES:  CR0: 80050033
[   48.336076] CR2: 55a04a253c58 CR3: 00029fdd8002 CR4:
001606e0
[   48.336079] Call Trace:
[   48.336105]  iwl_mvm_set_tx_cmd_rate+0x66/0xc0 [iwlmvm]
[   48.336125]  iwl_mvm_set_tx_params+0x337/0x4f0 [iwlmvm]
[   48.336134]  ? kmem_cache_alloc+0x159/0x210
[   48.336151]  iwl_mvm_tx_mpdu+0x94/0x510 [iwlmvm]
[   48.336159]  ? recalibrate_cpu_khz+0x10/0x10
[   48.336200]  ? ieee80211_tx_dequeue+0x429/0xb50 [mac80211]
[   48.336213]  iwl_mvm_tx_skb+0x197/0x460 [iwlmvm]
[   48.336231]  iwl_mvm_mac_itxq_xmit+0x7b/0xb0 [iwlmvm]
[   48.336275]  ieee80211_queue_skb+0x2b2/0x440 [mac80211]
[   48.336308]  __ieee80211_subif_start_xmit+0xb18/0xca0 [mac80211]
[   48.336335]  ? __ieee80211_subif_start_xmit+0xb18/0xca0 [mac80211]
[   48.336368]  ieee80211_subif_start_xmit+0x45/0x2d0 [mac80211]
[   48.336376]  dev_hard_start_xmit+0x8d/0x1e0
[   48.336390]  __dev_queue_xmit+0x736/0x9d0
[   48.336398]  ? dev_hard_start_xmit+0x8d/0x1e0
[   48.336407]  ip6_finish_output2+0x250/0x5b0
[   48.336415]  ip6_output+0x6c/0x120
[   48.336422]  ? __ip6_finish_output+0x110/0x110
[   48.336428]  ip6_xmit+0x2b5/0x5d0
[   48.336436]  ? ip6_xmit+0x2b5/0x5d0
[   48.336444]  ? __sk_dst_check+0x34/0x70
[   48.336451]  ? inet6_csk_route_socket+0x13b/0x1f0
[   48.336458]  inet6_csk_xmit+0xa7/0xf0
[   48.336466]  __tcp_transmit_skb+0x51c/0xac0
[   48.336477]  tcp_rcv_established+0x55e/0x630
[   48.336483]  tcp_v6_do_rcv+0xc6/0x3b0
[   48.336489]  tcp_v6_rcv+0xb38/0xbe0
[   48.336495]  ? tcp_v6_do_rcv+0xc6/0x3b0
[   48.336501]  ip6_protocol_deliver_rcu+0xcd/0x4b0
[   48.336507]  ip6_input_finish+0x11/0x20
[   48.336512]  ip6_input+0xa2/0xb0
[   48.336517]  ? tcp_v6_early_demux+0xff/0x170
[   48.336524]  ? ip6_rcv_finish_core.isra.0+0x72/0xd0
[   48.336530]  ipv6_rcv+0xc0/0xd0
[   48.336538]  ? tcp_gro_receive+0x1c9/0x2c0
[   

Bug#949264: nageru: FTBFS on arm/i386/mipsel architectures

[Boyuan Yang]

Hi,

在 2020-01-19日的 10:38 +0100，Steinar H. Gunderson写道：
> On Sun, Jan 19, 2020 at 12:50:43AM -0500, Boyuan Yang wrote:
> > Recent source-only rebuild for nageru has mulitple FTBFS architectures on
> > buildd: https://buildd.debian.org/status/package.php?p=nageru
> > 
> > The tail log all reads like this:
> 
> It looks like the definition of GLsizeiptr is different between the movit
> and
> nageru builds:
> 
> > ./obj-mipsel-linux-gnu/../nageru/timecode_renderer.cpp:51: undefined
> > reference
> > to `movit::generate_vbo(int, unsigned int, long, void const*)'
> > /usr/bin/ld: ./obj-mipsel-linux-gnu/../nageru/timecode_renderer.cpp:51:
> > undefined reference to `movit::generate_vbo(int, unsigned int, long, void
> > const*)'
> 
> klump:~/dev/movit> nm --dynamic --demangle /usr/lib/i386-linux-
> gnu/libmovit.so.8 | grep vbo
> 0001b9a0 T movit::generate_vbo(int, unsigned int, int, void const*)   
> 
> Is this an ABI break caused by some recent Mesa change, perhaps? I guess one
> could always rebuild Movit...
> 
> Seemingly it changed upstream from ptrdiff_t to khronos_ssize_t in Nov 2018,
> but I don't know if that was the actual break. krhonos_ssize_t is defined
> as:
> 
>   typedef signed   long  int khronos_ssize_t;

In this case a rebuild might be worthwhile anyway. Rebuilding package is
almost always harmless.

Are you going to trigger the rebuild recently? If not, I can help to trigger
it through NMU.

-- 
Thanks,
Boyuan Yang

Bug#949434: licensecheck: autopkgtest failure: Can't locate App/Licensecheck.pm in @INC

[Paul Gevers]

Source: licensecheck
Version: 3.0.39-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of licensecheck you added an autopkgtest, awesome.
However, it fails. I copied some of the output at the bottom of this report.

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

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

Paul

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

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

autopkgtest [04:40:01]: test autodep8-perl-build-deps:
/usr/share/pkg-perl-autopkgtest/runner build-deps
autopkgtest [04:40:01]: test autodep8-perl-build-deps:
[---
t/OSI.t ...
Can't locate App/Licensecheck.pm in @INC (you may need to install the
App::Licensecheck module) (@INC contains:
/tmp/autopkgtest-lxc.3dq2oqhz/downtmp/autopkgtest_tmp/smokeVoK0OO/blib/lib
/tmp/autopkgtest-lxc.3dq2oqhz/downtmp/autopkgtest_tmp/smokeVoK0OO/blib/arch
/tmp/autopkgtest-lxc.3dq2oqhz/downtmp/autopkgtest_tmp/smokeVoK0OO
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
/usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30
/usr/share/perl/5.30 /usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base) at t/OSI.t line 4.
BEGIN failed--compilation aborted at t/OSI.t line 4.
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/SPDX.t ..
Can't locate App/Licensecheck.pm in @INC (you may need to install the
App::Licensecheck module) (@INC contains:
/tmp/autopkgtest-lxc.3dq2oqhz/downtmp/autopkgtest_tmp/smokeVoK0OO/blib/lib
/tmp/autopkgtest-lxc.3dq2oqhz/downtmp/autopkgtest_tmp/smokeVoK0OO/blib/arch
/tmp/autopkgtest-lxc.3dq2oqhz/downtmp/autopkgtest_tmp/smokeVoK0OO
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
/usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30
/usr/share/perl/5.30 /usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base) at t/SPDX.t line 4.
BEGIN failed--compilation aborted at t/SPDX.t line 4.
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/Software-License.t ..
1..29
not ok 1 - Script bin/licensecheck runs

# Failed test 'Script bin/licensecheck runs'
# at t/Software-License.t line 65.
# 2 - Can't open perl script "bin/licensecheck": No such file or directory
# Looks like you planned 29 tests but ran 1.
# Looks like you failed 1 test of 1 run.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 29/29 subtests
t/devscripts.t 
1..14
# Subtest: copyright declared on 2 lines; t/devscripts/bsd-regents.c
not ok 1 - bin/licensecheck -m --copyright t/devscripts/bsd-regents.c

# Failed test 'bin/licensecheck -m --copyright
t/devscripts/bsd-regents.c'
# at t/devscripts.t line 15.
# 2 - Can't open perl script "bin/licensecheck": No such file or
directory
not ok 2 - stdout matches

# Failed test 'stdout matches'
# at t/devscripts.t line 16.
# The output
# does not match
#   t/devscripts/bsd-regents.c  (?^:BSD (?:3-clause "New" or
"Revised" License|\(3 clause\)) 1987, 1993.*1994 The Regents of the
University of California.)
not ok 3 - stderr matches

# Failed test 'stderr matches'
# at t/devscripts.t line 19.
# The output
#   Can't open perl script "bin/licensecheck": No such file or directory
# does not match
1..3
# Looks like you failed 3 tests of 3.
not ok 1 - copyright declared on 2 lines; t/devscripts/bsd-regents.c

#   Failed test 'copyright declared on 2 lines; t/devscripts/bsd-regents.c'
#   at t/devscripts.t line 22.
# Subtest: copyright declared on 3 lines; t/devscripts/texinfo.tex
not ok 1 - bin/licensecheck -m --copyright t/devscripts/texinfo.tex

# Failed test 'bin/licensecheck -m --copyright t/devscripts/texinfo.tex'
# at t/devscripts.t line 15.
# 2 - Can't open perl script "bin/licensecheck": No such file or
directory
not ok 2 - stdout matches

# Failed test 'stdout matches'
# at t/devscripts.t line 16.
# The output
# does not match
#   t/devscripts/texinfo.tex(?^:GPL \(v3 or later\) 1985.*2012 Free
Software Foundation, Inc.)
not ok 3 - stderr matches

# Failed test 'stderr matches'
# at t/devscripts.t line 19.
# The output
#   Can't open perl script "bin/licensecheck": No such file or directory
# does not match
1..3
# Looks like you failed 3 tests of 3.
not ok 2 - copyright declared on 3 lines; t/devscripts/texinfo.tex

#   Failed test 'copyright declared on 3 lines; t/devscripts/texinfo.tex'
#   at t/devscripts.t line 22.
# Subtest: multi-line multi-statements; t/devscripts/multi-line-copyright.c
not ok 

Bug#925720: isc-dhcp: ftbfs with GCC-9

[Paul Gevers]

Hi all,

On Fri, 4 Oct 2019 15:08:39 +0200 Reiner Herrmann 
wrote:
> Dear maintainer,
> 
> the attached patch fixes the FTBFS with GCC 9.
> I moved the linked library irs-export from LDFLAGS to LIBS, so that
> it will appear in the correct place on the command line.
> 
> Kind regards,
>   Reiner

Any progress on this? bind9 started a transition and binNMU's failed as
reported.

Reiner, do you maybe want to NMU your fix?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#949428: postgresql-12: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Christoph Berg]

Control: tags -1 wontfix

Re: Mattia Rizzolo 2020-01-20 <20200120194247.ga3704...@mapreri.org>
> your package is using `xml2-config` to detect and use libxml2.  I'm
> removing that script

Hi,

please don't do that unless you get libxml2 upstream to properly
announce the deprecation first.

Christoph

Bug#949278: libreoffice hangs at startup if ~/.libreoffice folder does not exist

[Rene Engelhard]

On Mon, Jan 20, 2020 at 10:05:00PM +0100, Rene Engelhard wrote:
> For a migration which happened almost two decades ago.

Sorry, obviously too tired. One decade. But still.

Regards,

Rene

Bug#949336: Mapped integrity devices of size ≥2TiB are unusable on 32-bits platforms

[Guilhem Moulin]

Control: tag -1 + moreinfo

On Mon, 20 Jan 2020 at 21:25:56 +0100, Milan Broz wrote:
> but I definitely need a clear reproducer (with the latest stable - 2.2.2 or 
> 2.3.0-rc0) - ideally with attached debug and system log.
> (Debug log will provide all versions I need - kernel and dm targets versions 
> are important here)
> 
> It could be also kernel problem, so if you can attach .config for the kernel, 
> it helps.

Ack, tagging this ‘moreinfo’ in the meantime.  n.b.f., assuming you're using
the stock kernel you'll find the .config under /boot/config-$VERSION-$ARCH.
As of 2:2.2.2-2 we don't have custom Debian patches against the libcryptsetup
and cryptsetup binary we're shipping.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#949278: libreoffice hangs at startup if ~/.libreoffice folder does not exist

[Rene Engelhard]

retitle 949278 endless loop if ~/.config/libreoffice is a symlink
severity 949278 minor
thanks

Hi,

On Mon, Jan 20, 2020 at 09:22:55PM +0100, Pierre Bernhardt wrote:
> Am 20.01.20 um 11:14 schrieb Rene Engelhard:
> > You mean keep the .config/libreoffice and remove the old .libreoffice.
> 
> No, really mean remove the link .config/libreoffice which points to 
> .libreoffice,
> remove .libreoffice

Exactly my point.

Remove the bogus link and let the "correct" one be generated.

> and then next start .config/libreoffice will be recreated by starting 
> libreoffice.

Indeed.

> However the loop itself is a bug and a symlink is not an error.

But you are not supposed to play tricks in stuff the applications
do not expect either. User config is tricky in this regard and this is
not a "save space" thing either. In fact, .config/libreoffice ->
.libreoffice was always wrongdoing to begin with.

As shown in the commits there is upstream migration code for this and
there was no need for any symlink here.
And the migration code LO 3 -> LO 4+ (or .libreoffice ->
.config/libreoffice) needs to know what it can expect.

> It is a regular tool to point to another place whenever it is wanted. Each 
> software should deal
> with them and if it is not allowed/supported, it should show a message e.g.
> displayed by an exception handling. But supporting a symlink is not really
> hard to support.

This case would then need a "way out" of a migration.

For a migration which happened almost two decades ago.

I don't believe upstream will invest time in this - they have more
important stuff on the plate...

> PS: Don't know how long the .libreoffice folder exists. It could be very long
> in the past maybe before libreoffice has to been forked from openoffice. Maybe
> I renamed/copied it from .openoffice to .libreoffice or whatever. But let us

LO 3.x (first LO was 3.3) did .libreoffice initially (as it was forked from 
OpenOffice.org)
until it was renamed to .config/libreoffice in 2011 (see my referenced
commit)

Anyway, will try myself in a VM...

Regards,

Rene

Bug#949360: w cuts IPv6 addres

[Craig Small]

The idea of having a -w option is something I'll look into.  I'm not sure
if you noticed, but there is the PROCPS_FROMLEN environment variable you
can set to make that column wider too.

 - Craig


On Mon, 20 Jan 2020 at 17:51, Marc Haber 
wrote:

> Package: procps
> Version: 2:3.3.15-2+b1
> Severity: normal
> File: /usr/bin/w
> Tags: ipv6
>
> Hi,
>
> [1/1520]mh@roll:~ $ w
>  07:48:37 up 12:09,  1 user,  load average: 0,00, 0,01, 0,01
> USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
> mh   pts/22a01:238:4071:32 07:484.00s  0.05s  0.00s w
> [2/1521]mh@roll:~ $ dpkg --list procps
>
> The IP address cut off at the interesting point makes the information
> useless. The formatting looks like w invokes last, which has an option
> -w to give the full address. Maybe it is a good idea to give that option
> here as well.
>
> Greetings
> Marc
>

Bug#875184: Help needed for medical imaging framework sofa (Was: Bug#875184: [sofa-framework] Future Qt4 removal from Buster)

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El lun., 20 ene. 2020 16:38, Moritz Mühlenhoff  escribió:

> On Sat, Sep 21, 2019 at 08:42:14AM +0200, Andreas Tille wrote:
> > Hi,
> >
> > On Fri, Sep 20, 2019 at 11:55:03PM +0200, Moritz Mühlenhoff wrote:
> > > On Fri, Sep 20, 2019 at 06:41:05PM -0300, Lisandro Damián Nicanor
> Pérez Meyer wrote:
> > > > I've created a WIP merge request at
> > > >
> > > >   https://salsa.debian.org/med-team/sofa-framework/merge_requests/1
> > > >
> > > > I could solve TinyXML (at least in the aspect of finding it, I might
> need to
> > > > adjust something else later on) but came across libgtest-dev... It
> ships static
> > > > libraries!
> >
> > @Lisandro: Thanks a lot, merged.
> >
> > > > I would have to check how to use them within CMake, but I do wonder
> if it's not
> > > > better to just keep the embedded version. After all it's only used
> for testing
> > > > C++ classes, so build time...
> > >
> > > Agreed, that seems preferable here.
> >
> > I've created a new tarball +dfsg3 which includes gtest.
> >
> > Lisandro, I'm really happy that you are pushing sofa-framework forward.
>
> Any further progress?


No, I'm afraid I'm quite busy with family stuff and I barely get to do
Debian stuff :-(

Bug#949336: Mapped integrity devices of size ≥2TiB are unusable on 32-bits platforms

[Milan Broz]

On 20/01/2020 14:11, Guilhem Moulin wrote:
> Milan, should I forward that upstream (verbatim)?

Sure, put it to the upstream, issue tracker , but I definitely need a clear 
reproducer (with the latest stable - 2.2.2 or 2.3.0-rc0) - ideally with 
attached debug and system log.
(Debug log will provide all versions I need - kernel and dm targets versions 
are important here)

It could be also kernel problem, so if you can attach .config for the kernel, 
it helps.

Milan

Bug#949387: nagivs: New upstream release 1.19.17

[andreimpopescu]

Control: reassign -1 nagvis 1:1.9.11-1

On Lu, 20 ian 20, 16:08:50, Adam Cecile wrote:
> Package: nagivs
> Version: 1:1.9.11-1
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainer,
> 
> Several upstream versions have been released and the latest one is 1.9.17.
> 
> Between current Debian's version and latest upstream there are several changes
> but the following are important to me:
>  * Performance improvments
>  * Ability to pass a custom Openstreetmap WMS server
> 
> I'll provided a PR on Salsa in a few minutes.
> 
> Best regards, Adam.
> 
> 
> 
> -- System Information:
> Debian Release: 10.2
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#949432: chromium: Version 79.0.3945.130-1~deb10u1; infinite loop when used with X over a network

[Karl O. Pinc]

Package: chromium
Version: 79.0.3945.130-1~deb10u1
Severity: important

Hello,

After installing chromimum version 79.0.3945.130-1~deb10u1 from the
security repos chromium goes into an infinite loop when used on
a X client/server setup that passes X traffic over the network.

This makes chromium unusable with X thin clients, etc.

Prior to installing the security update chromium worked fine.

Given the output below there might be a race condition between
processes or threads.

I do not believe I am using any extensions.

In the commands given below the arguments to chromium can be left
off (except for --debug) and the results are similar.

I believe I have always received the libGL errors, which I have always
ignored because the old chromium worked.  I'm also pretty confidient
that I also previously got the FontService errors and they did not
cause a problem.

---

The following command results in a "window" rendered in white.  This
window has nothing but a frame that allows it to be resized.  Pressing
Ctrl-C does nothing.  Chromium must be killed (I used 'killall
chromium') from a separate window.

$ chromium --user-data-dir=$(mktemp -d) --incognito 
libGL error: failed to authenticate magic 1
libGL error: failed to load driver: radeonsi
[15041:15041:0120/134456.934149:ERROR:sandbox_linux.cc(372)] 
InitializeSandbox() called with multiple threads in process gpu-process.
[15106:27:0120/134457.153701:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[15106:27:0120/134457.154600:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.

-
Running the following strace results in what seems to be an infinite
loop producing the following output:

$ strace chromium --user-data-dir=$(mktemp -d) --incognito

poll([{fd=178, events=POLLIN}, {fd=179, events=POLLIN}, {fd=198, 
events=POLLIN}, {fd=202, events=POLLIN}, {fd=228, events=POLLIN}], 5, 0) = 0 
(Timeout)
recvmsg(202, {msg_namelen=0}, 0)= -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(202, {msg_namelen=0}, 0)= -1 EAGAIN (Resource temporarily 
unavailable)
write(197, "\0", 1) = 1
recvmsg(198, {msg_namelen=0}, 0)= -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(198, {msg_namelen=0}, 0)= -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(202, {msg_namelen=0}, 0)= -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(202, {msg_namelen=0}, 0)= -1 EAGAIN (Resource temporarily 
unavailable)

The file descriptors 178, 179, and 198 seem to be reproducable.



Running chromium in debug mode seems to work, although the running window
displays the message (all on one line):

You are using an unsupported command-line flag: --single-process.
Stability and security will suffer.


$ chromium --debug
# Env:
# LD_LIBRARY_PATH=
#PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --load-extension=
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.279a41
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...(no debugging symbols 
found)...done.
(gdb) run
Starting program: /usr/lib/chromium/chromium --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --load-extension= --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffea9e1700 (LWP 16053)]
[Detaching after fork from child process 16054]
[New Thread 0x7fffea1e0700 (LWP 16058)]
[New Thread 0x7fffe3fff700 (LWP 16059)]
[New Thread 0x7fffe37fe700 (LWP 16060)]
[New Thread 0x7fffe2ffd700 (LWP 16061)]
[New Thread 0x7fffe27fc700 (LWP 16062)]
[New Thread 0x7fffe1ffb700 (LWP 16063)]
[New Thread 0x7fffe17fa700 (LWP 16064)]
[New Thread 0x7fffe0ff9700 (LWP 16065)]
[New Thread 0x7fffc700 (LWP 16066)]
[New Thread 0x7fffe847b700 (LWP 16067)]
[New 

Bug#949278: libreoffice hangs at startup if ~/.libreoffice folder does not exist

[Pierre Bernhardt]

Am 20.01.20 um 11:14 schrieb Rene Engelhard:
> You mean keep the .config/libreoffice and remove the old .libreoffice.

No, really mean remove the link .config/libreoffice which points to 
.libreoffice,
remove .libreoffice and then next start .config/libreoffice will be recreated
by starting libreoffice.

However the loop itself is a bug and a symlink is not an error. It is a regular
tool to point to another place whenever it is wanted. Each software should deal
with them and if it is not allowed/supported, it should show a message e.g.
displayed by an exception handling. But supporting a symlink is not really
hard to support.

PS: Don't know how long the .libreoffice folder exists. It could be very long
in the past maybe before libreoffice has to been forked from openoffice. Maybe
I renamed/copied it from .openoffice to .libreoffice or whatever. But let us
stop this kind of discussion, when and how it has been created. It has been
worked for many years and only after removing my config the problem occurs
by the endless loop.

Cheers,
Pierre

Bug#949433: No documentation included for the assembler/linker

[Pedro Gimeno]

Package: sdcc-doc
Version: 3.8.0+dfsg-3

This problem was previously reported as bug 198376 "sdcc includes no aslink 
documentation"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198376
but I was advised to submit it as a new bug rather than reopening the old one.

When using 'man sdasz80' (or any other sdas), the man page says:

   For complete and current  documentation,  refer  to  the  AS  Cross
   Assembler Documentation, available in /usr/share/doc/sdcc-doc/aslink.

But when installing package sdcc-doc, that file or directory does not exist.

As a workaround, the file with the documentation can be obtained with:

cd /tmp
apt-get source sdcc
cp sdcc-*/sdas/doc/asmlnk.txt 

Bug#946528: liblwip0: Bad TCP_MSS value

[Joan Lledó]

Hi,

El 14/1/20 a les 8:50, Ondřej Tůma ha escrit:
> V Sun, 22 Dec 2019 09:45:05 +0100 (CET)
> Joan Lledó  napsáno:
> 
>> Hi,
>>
>> El 10/12/19 a les 16:29, Ondřej Tůma ha escrit:
>>> Creating TCP server with existing value in library crashed by bad
>>> memory using. Valgrind found the problem in low_level_input
>>> function, which uses pbuf_alloc, that allocate too less memory.
>>> This "original" value will work. 
>>
>> low_level_info is usually implemented by the driver. Which driver are
>> you using? Are you using IPv6?
> 
> Hi,
> 
> I'm using tap, you can see here:
> 
> https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/tests/integration/main.c
> 
> lwsapi is LUA WSAPI or Python WSGI like implementation somewhere code,
> which is linked to this directory after git clone.
> 
> And as you can see, I'm not using IPv6 at this moment.
> 

I'm reluctant to change the TCP tuning values without a good reason,
because any value will always fit for some cases and be inappropriate
for others. Besides, I don't see how it's the MSS value related to this
bug. And anyway, memory bugs in C are always tricky, the problem can be
produced in any other place than the place where they manifest.

Reading your code I assume you're using the tapif driver that is
distributed with lwip, could the problem be the harcoded size of the
input buffer? [1]


[1]
http://git.savannah.nongnu.org/cgit/lwip.git/tree/contrib/ports/unix/port/netif/tapif.c#n267

Bug#940871: openconnect: diff for NMU version 8.02-1.1

[Salvatore Bonaccorso]

Hi Mike,

On Mon, Jan 20, 2020 at 12:00:18PM -0800, Mike Miller wrote:
> On Sat, Jan 18, 2020 at 23:54:53 +0100, Salvatore Bonaccorso wrote:
> > I've prepared an NMU for openconnect (versioned as 8.02-1.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I
> > should delay it longer.
> 
> Seems fine to me, thank you!

Thanks, for confirming. The NMU should enter the archive tonight. I
have as well prepared respective updates for buster- and
stretch-security which I was planning to release soon.

Could you import those then as well in the packaging repository?

Regards,
Salvatore

Bug#940871: openconnect: diff for NMU version 8.02-1.1

[Mike Miller]

On Sat, Jan 18, 2020 at 23:54:53 +0100, Salvatore Bonaccorso wrote:
> I've prepared an NMU for openconnect (versioned as 8.02-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Seems fine to me, thank you!

-- 
mike


signature.asc
Description: PGP signature

Bug#548825: texlive-latex-base: \pdfinfo with hyperref should not have undefined behavior

[Hilmar Preuße]

Control: tags -1 - fixed-upstream

Am 29.09.2009 um 01:37 teilte Vincent Lefevre mit:

Hi,

the issue has been forwarded upstream and the issue been closed w/ the
following comment:

I think I'll close here, interaction with direct use of the primitives
is largely undefined and this whole area is likely to get looked at
again with the expl3 backend code.

Therefore the tag fixed-upstream is not correct, I remove it.

Hilmar

> When using the \pdfinfo pdftex command with hyperref, one gets a PDF
> file with multiply-defined fields (Title, Subject, Keywords, Author);
> see attached files as an example. According to
> 
>   
> http://groups.google.fr/group/comp.text.tex/browse_thread/thread/f8f2d1733b0f22f0/
> 
> this is undefined behavior (for instance, pdfinfo from xpdf-utils and
> pdfinfo from poppler-utils behave differently), and the fact that the
> user must not use \pdfinfo with hyperref is not documented (there are
> even various documents on the web that provide examples using \pdfinfo
> with hyperref). The hyperref package should do everything to avoid the
> multiply-defined entries (an error would probably be best).
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#949431: RFP: retry -- Retry a command until the command succeeds.

[Graham Leggett]

Package: wnpp
Severity: wishlist

* Package name: retry
  Version : 1.0.2
  Upstream Author : Graham Leggett 
* URL : https://github.com/minfrin/retry
* License : Apache 2.0
  Programming Lang: C
  Description : Retry a command until the command succeeds.

Retry captures stdin into memory as the data is passed to the repeated
command, and this captured stdin is then replayed should the command be
repeated. This makes it possible to embed the retry tool into shell pipelines.

Retry captures stdout into memory, and if the command was successful stdout
is passed on to stdout as normal, while if the command was repeated stdout
is passed to stderr instead. This ensures that output is passed to stdout
once and once only.

Bug#548825: texlive-latex-base: \pdfinfo with hyperref should not have undefined behavior

[Hilmar Preuße]

Control: -1 tags - fixed-upstream

Am 29.09.2009 um 01:37 teilte Vincent Lefevre mit:

Hi,

the issue has been forwarded upstream and the issue been closed w/ the
following comment:

I think I'll close here, interaction with direct use of the primitives
is largely undefined and this whole area is likely to get looked at
again with the expl3 backend code.

Therefore the tags fixed-upstream is not correct, I remove it.

Hilmar

> When using the \pdfinfo pdftex command with hyperref, one gets a PDF
> file with multiply-defined fields (Title, Subject, Keywords, Author);
> see attached files as an example. According to
> 
>   
> http://groups.google.fr/group/comp.text.tex/browse_thread/thread/f8f2d1733b0f22f0/
> 
> this is undefined behavior (for instance, pdfinfo from xpdf-utils and
> pdfinfo from poppler-utils behave differently), and the fact that the
> user must not use \pdfinfo with hyperref is not documented (there are
> even various documents on the web that provide examples using \pdfinfo
> with hyperref). The hyperref package should do everything to avoid the
> multiply-defined entries (an error would probably be best).
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#948372: Please push your changes to nibabel

[Andreas Tille]

On Mon, Jan 20, 2020 at 01:01:00PM -0500, Yaroslav Halchenko wrote:
> 
> > I'm fine with re-doing what I changed if you consider it really of
> > practical relevance.  If you ask me we two would spent time we could
> > use more productively but its OK if you want to do it.
> 
> You just rename and I will do the rest (push your pristine-tar, align
> branches properly).  then debcheckout should work for old people (if
> gitlab redirects correctly as github does in such cases), and you could
> proceed with your work ;)

Just ping me if you are done.  Next time I should try to move first. :-)

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#949426: postgis: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Mattia Rizzolo]

Source: postgis
Version: 3.0.0+dfsg-6
Severity: important
Tags: ftbfs
User: libx...@packages.debian.org
Usertags: ftbfs-2.9.10 xml2-config


Dear maintainer,

your package is using `xml2-config` to detect and use libxml2.  I'm
removing that script, so please update your build system to use
pkg-config instead.

The libxml2 package in experimental already doesn't ship the xml2-config
script.

Attached is the full build log, hopefully relevant excerpt follows:


checking for xml2-config... no
configure: error: could not find xml2-config from libxml2 within the current 
path. You may need to try re-running configure with a --with-xml2config 
parameter.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
I: Using pkgname logfile
I: Current time: Mon Jan 20 16:46:44 UTC 2020
I: pbuilder-time-stamp: 1579538804
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [pkgs/postgis_3.0.0+dfsg-6.dsc]
I: copying [pkgs/postgis_3.0.0+dfsg.orig.tar.xz]
I: copying [pkgs/postgis_3.0.0+dfsg-6.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/mattia/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Fri Dec 13 09:30:02 2019 UTC
gpgv:using RSA key 8182DE417056408D614650D16750F10AE88D4AF1
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./postgis_3.0.0+dfsg-6.dsc
dpkg-source: info: extracting postgis in postgis-3.0.0+dfsg
dpkg-source: info: unpacking postgis_3.0.0+dfsg.orig.tar.xz
dpkg-source: info: unpacking postgis_3.0.0+dfsg-6.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying relax-test-timing-constraints.patch
dpkg-source: info: applying chaikin
I: using fakeroot in build.
I: Installing the build-deps
I: -> Attempting to satisfy build-dependencies
Note, using file '/build/postgis_3.0.0+dfsg-6.dsc' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  adwaita-icon-theme autoconf autoconf2.13 automake autopoint autotools-dev
  binfmt-support bison bsdmainutils clang-9 dblatex dctrl-tools debhelper
  default-libmysqlclient-dev dh-autoreconf dh-strip-nondeterminism dirmngr
  distro-info-data docbook docbook-xml docbook-xsl dwz file flex fontconfig
  fontconfig-config fonts-dejavu-core fonts-gfs-baskerville fonts-gfs-porson
  fonts-lmodern gcc-8-base gdal-data gettext gettext-base gir1.2-atk-1.0
  gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0 gir1.2-gtk-2.0
  gir1.2-harfbuzz-0.0 gir1.2-pango-1.0 gnupg gnupg-l10n gnupg-utils gpg
  gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm groff-base
  gtk-update-icon-cache hdf5-helpers hicolor-icon-theme imagemagick
  imagemagick-6-common imagemagick-6.q16 intltool-debian lib32gcc1
  lib32stdc++6 libaec-dev libaec0 libapt-inst2.0 libarchive-zip-perl
  libarmadillo-dev libarmadillo9 libarpack2 libarpack2-dev libassuan0
  libatk1.0-0 libatk1.0-data libatk1.0-dev libavahi-client3
  libavahi-common-data libavahi-common3 libblas-dev libblas3 libblkid-dev
  libboost-atomic1.67-dev libboost-atomic1.67.0 libboost-chrono1.67-dev
  libboost-chrono1.67.0 libboost-date-time1.67-dev libboost-date-time1.67.0
  libboost-dev libboost-program-options-dev libboost-program-options1.67-dev
  libboost-program-options1.67.0 libboost-serialization1.67-dev
  libboost-serialization1.67.0 libboost-system-dev libboost-system1.67-dev
  libboost-system1.67.0 libboost-thread-dev libboost-thread1.67-dev
  libboost-thread1.67.0 libboost1.67-dev libbrotli1 libbsd0 libc-l10n
  libc6-i386 libcairo-gobject2 libcairo-script-interpreter2 libcairo2
  libcairo2-dev libcfitsio-dev libcfitsio8 libcgal-dev libcharls-dev
  libcharls2 libclang-common-9-dev libclang-cpp9 libcroco3 libcunit1
  libcunit1-dev libcups2 libcurl3-gnutls libcurl4-gnutls-dev libdap-dev
  libdap25 libdapclient6v5 libdapserver7v5 libdatrie1 libdbus-1-3 libde265-0
  libdebhelper-perl libecpg-compat3 libecpg-dev libecpg6 libedit2 libelf1
  libepsilon-dev libepsilon1 libevent-2.1-7 libexpat1-dev libffi-dev
  libfftw3-double3 libfile-stripnondeterminism-perl libfontconfig1
  libfontconfig1-dev libfreetype-dev libfreetype6 libfreetype6-dev
  libfreexl-dev libfreexl1 libfribidi-dev libfribidi0 libfyba-dev libfyba0
  libgc1c2 libgcc-8-dev libgdal-dev libgdal26 libgdk-pixbuf2.0-0
  libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libgdk-pixbuf2.0-dev
  libgeos-3.8.0 libgeos-c1v5 libgeos-dev libgeotiff-dev libgeotiff5
  libgfortran5 libgif-dev libgif7 

Bug#949424: pgadmin3: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Mattia Rizzolo]

Source: pgadmin3
Version: 1.22.2-6
Severity: important
Tags: ftbfs
User: libx...@packages.debian.org
Usertags: ftbfs-2.9.10 xml2-config


Dear maintainer,

your package is using `xml2-config` to detect and use libxml2.  I'm
removing that script, so please update your build system to use
pkg-config instead.

The libxml2 package in experimental already doesn't ship the xml2-config
script.

Attached is the full build log, hopefully relevant excerpt follows:


checking for xml2-config... no
configure: error: Could not find your libxml2 installation. You might need to 
use the --with-libxml2=DIR configure option


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
I: Using pkgname logfile
I: Current time: Mon Jan 20 15:29:10 UTC 2020
I: pbuilder-time-stamp: 1579534150
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [pkgs/pgadmin3_1.22.2-6.dsc]
I: copying [pkgs/pgadmin3_1.22.2.orig.tar.gz]
I: copying [pkgs/pgadmin3_1.22.2-6.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/mattia/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Tue Jan  7 12:51:23 2020 UTC
gpgv:using RSA key 5C48FE6157F49179597087C64C5A6BAB12D2A7AE
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./pgadmin3_1.22.2-6.dsc
dpkg-source: info: extracting pgadmin3 in pgadmin3-1.22.2
dpkg-source: info: unpacking pgadmin3_1.22.2.orig.tar.gz
dpkg-source: info: unpacking pgadmin3_1.22.2-6.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying x-terminal-emulator
dpkg-source: info: applying no-wx-webview
dpkg-source: info: applying 843344
dpkg-source: info: applying pgversion
dpkg-source: info: applying pg10
I: using fakeroot in build.
I: Installing the build-deps
I: -> Attempting to satisfy build-dependencies
Note, using file '/build/pgadmin3_1.22.2-6.dsc' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  adwaita-icon-theme autoconf automake autopoint autotools-dev binfmt-support
  bsdmainutils ca-certificates chrpath clang-9 dbus dbus-user-session
  dconf-gsettings-backend dconf-service debhelper dh-autoreconf
  dh-strip-nondeterminism dmsetup docutils-common dwz file fontconfig
  fontconfig-config fonts-dejavu-core gcc-8-base gettext gettext-base
  glib-networking glib-networking-common glib-networking-services groff-base
  gsettings-desktop-schemas gtk-update-icon-cache hicolor-icon-theme
  intltool-debian lib32gcc1 lib32stdc++6 libapparmor1 libarchive-zip-perl
  libargon2-1 libatk-bridge2.0-0 libatk1.0-0 libatk1.0-data libatspi2.0-0
  libavahi-client3 libavahi-common-data libavahi-common3 libbrotli1 libbsd0
  libc6-i386 libcairo-gobject2 libcairo2 libcap2 libclang-common-9-dev
  libclang-cpp9 libcolord2 libcroco3 libcryptsetup12 libcups2 libdatrie1
  libdbus-1-3 libdconf1 libdebhelper-perl libdevmapper1.02.1 libdrm-amdgpu1
  libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2
  libelf1 libepoxy0 libffi-dev libfile-stripnondeterminism-perl libfontconfig1
  libfreetype6 libfribidi0 libgc1c2 libgcc-8-dev libgcrypt20-dev
  libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libgl-dev libgl1 libgl1-mesa-dev
  libgl1-mesa-dri libglapi-mesa libglib2.0-0 libglu1-mesa libglu1-mesa-dev
  libglvnd0 libglx-dev libglx-mesa0 libglx0 libgpg-error-dev libgraphite2-3
  libgssapi-krb5-2 libgtk-3-0 libgtk-3-common libharfbuzz0b libice6 libip4tc2
  libjbig0 libjpeg62-turbo libjs-jquery libjs-sphinxdoc libjs-underscore
  libjson-c4 libjson-glib-1.0-0 libjson-glib-1.0-common libk5crypto3
  libkeyutils1 libkmod2 libkrb5-3 libkrb5support0 liblcms2-2 libldap-2.4-2
  libldap-common libllvm9 libmagic-mgc libmagic1 libmpx2 libncurses-dev
  libncurses6 libnotify4 libobjc-8-dev libobjc4 libpam-systemd libpango-1.0-0
  libpangocairo-1.0-0 libpangoft2-1.0-0 libpciaccess0 libpfm4 libpipeline1
  libpixman-1-0 libpng16-16 libpq-dev libpq5 libprocps7 libproxy1v5 libpsl5
  libpthread-stubs0-dev librest-0.7-0 librsvg2-2 librsvg2-common libsasl2-2
  libsasl2-modules-db libsensors-config libsensors5 libsigsegv2 libsm6
  libsoup-gnome2.4-1 libsoup2.4-1 libssl-dev libstdc++-8-dev
  libsub-override-perl libthai-data libthai0 libtiff5 libtinfo-dev libtool
  libuchardet0 libwayland-client0 libwayland-cursor0 libwayland-egl1 libwebp6
  libwxbase3.0-0v5 libwxbase3.0-dev libwxgtk3.0-gtk3-0v5 libwxgtk3.0-gtk3-dev
  libx11-6 libx11-data libx11-dev libx11-xcb1 libxau-dev libxau6 

Bug#875243: [yagf] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Thu, Sep 05, 2019 at 01:32:39PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Hi Boris!
> 
> On Thu, 5 Sep 2019 at 13:17, Boris Pek  wrote:
> >
> > Hi,
> >
> > > similar ping as for qpxtool, last upstream commits are from 2015. Are you
> > > planning to port it yourself or should it be removed?
> >
> > Patch for yagf port to Qt5 already exists at least in Mageia GNU/Linux 
> > distro.
> >
> > I may backport this patch to yagf 0.9.3.2 or update yagf package to latest
> > release 0.9.5 and prepare patches with fixes for some regressions in this
> > version of program. (I have not decided yet.)
> >
> > Do you have any time schedule for Qt4 removal? At least preliminary.
> 
> As soon as possible. There is already an RC bug in qt4-x11 to avoid
> shipping it in bullseye and, at the the current bug fixing rate, it is
> going to be dropped from testing soon, and it will not return there.
> Once that happens we will be asking for removals even more
> aggressively.
> 
> You can also push yagf with the Qt 5 patch to experimental, in that
> way the qt4-based version can be removed from unstable and you will
> not have to pass trough NEW once you consider it ready for unstable.

Status update: Qt4 has now been droppped from testing, qt4 will be removed
from unstable by end of February (along with the remaining rdeps (currently 
15)).

Cheers,
Moritz