date:20201128

On Sat, 28 Nov 2020 at 17:04:10 +0100, Michael Biebl wrote:
> Given the nature of the package, I would prefer that it is moved under
> GNOME maintainership (I actually don't know anymore why it is in debian
> and not the gnome-team salsa namespace on salsa).
> That said, you can just as well make a Team-Upload and apply any
> changes you see fit, if you want.

Thanks, done. In addition to fixing this bug, I made some trivial
janitorial changes and added an autopkgtest, but I haven't converted
it to DEP-14 or to the GNOME Team debian/control.in machinery.

I've opened https://salsa.debian.org/salsa/support/-/issues/250 to ask
the salsa sysadmins to move it into the gnome-team namespace.

smcv

Bug#976052: RFP: zola -- Zola is a static site generator (SSG).

2020-11-28 Thread Sebastien CHAVAUX

Package: wnpp
Severity: wishlist

* Package name: zola
  Version : 0.12.2
  Upstream Author : Vincent Prouillet 
* URL : https://github.com/getzola/zola
* License : MIT
  Programming Lang: Rust
  Description : An opinionated static site generator.

Zola is a static site generator (SSG), similar to Hugo, Pelican, and Jekyll. It
is written in Rust and uses the Tera template engine, which is similar to
Jinja2, Django templates, Liquid, and Twig. Content is written in CommonMark, a
strongly defined, highly compatible specification of Markdown

It is a good alternative to Hugo.
I would like to maintain it, currently I'm leaning to pack it, if someone can
give me a hand, I'm not against.

Bug#973741: [Pkg-javascript-devel] Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

2020-11-28 Thread Paolo Greppi

there is a 4th option, see below

Il 28/11/20 20:28, Pirate Praveen ha scritto:

...
So some options I can think,

1. Port yarn 1.x to build with babel 7 (but this has not been successfull)
2. Try to run ES6 code directly somehow, may be with newer nodejs and patches.
I think Paolo tried this option, not sure what happened.
3. Build it using 'deb
https://snapshot.debian.org/archive/debian/20200502T085134Z sid main' (the last
version that builds in sid) and embed the built files in the package (as two
steps, like we bootstrap babel, rollup etc). This will mean, we will have to
move it to contrib. I prefer shipping yarn in contrib to missing it in bullseye.

4. Build yarn 2 (berry)

I have done some preliminary exploration.

First, if I follow the upstream suggested path to install yarn 2 I get this (on
Debian testing with node 14 from experimental):

1. running `npm install yarn` in an empty dir adds node_modules/yarn (about 5
MB), and no other dependencies; running `./node_modules/yarn/bin/yarn -v`
returns 1.22.10

2. if you then run `./node_modules/yarn/bin/yarn set version berry` it drops a
`.yarnrc.yml` file with the content `yarnPath: ".yarn/releases/yarn-berry.cjs"`
and pulls the single file `.yarn/releases/yarn-berry.cjs` (1.8 MB)

3. now running `./node_modules/yarn/bin/yarn -v` or directly
`.yarn/releases/yarn-berry.cjs` returns 2.3.3; I can run this file from
anywhere, referencing its full path

4. for example running `/tmp/yarn/.yarn/releases/yarn-berry.cjs add yarn` in an
empty dir adds .yarn/unplugged/yarn-npm-1.22.10-b1a926d20f (about 5 MB), and
running `.yarn/unplugged/yarn-npm-1.22.10-b1a926d20f/node_modules/yarn/bin/yarn
-v' returns 1.22.10 (back to square one).

What we want is to build the yarn-berry.cjs file from sources. This is what I
have found on that:

1. Cloning the berry repo from github pulls almost 1GB of data (up from about
100 MB for yarn 1)

2. the tarball is 180 MB (up from ~70 MB for yarn 1) and has all dependencies
needed to run yarn (!) including monaco-editor (?) from Microsoft (the code
editor which powers VS Code), react-icons, 6 versions of the typescript tree
(version 3.75, 3.95 and 4.1 and three patched versions) etc.

3. running npm install in the source tree fails ('Unsupported URL Type
"workspace:"')

4. if I delete yarn.lock and remove from package.json the 4 dependencies that
use the workspace url (@yarnpkg/cli, @yarnpkg/core, @yarnpkg/eslint-config and
@yarnpkg/pnpify), npm install runs fine

5. we want to run `yarn build:cli`, which according to
packages/yarnpkg-cli/package.json runs `builder build bundle`; this file gives
some clue as to what is supposed to happen:
https://github.com/yarnpkg/berry/blob/master/packages/yarnpkg-builder/sources/commands/build/bundle.ts#L96

Finally, I have also found: https://yarnpkg.com/advanced/telemetry

Paolo

Bug#976051: ITP: peptidebuilder -- generate atomic oligopeptide 3D structure from sequence

2020-11-28 Thread Steffen Moeller

Package: wnpp
Severity: wishlist

Subject: ITP: peptidebuilder -- generate atomic oligopeptide 3D structure from 
sequence
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: peptidebuilder
  Version : 1.1.0
  Upstream Author : Matthew ZTien
* URL : https://github.com/clauswilke/PeptideBuilder/
* License : MIT
  Programming Lang: Python
  Description : generate atomic oligopeptide 3D structure from sequence
 PeptideBuilder is a simple Python library to generate model peptides.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/peptidebuilder

Bug#976039: mutter: Windows have wrong minimum width

2020-11-28 Thread Michel Le Bihan

Package: mutter
Version: 3.38.1-2
Severity: important
Tags: upstream

Hello,
I noticed that all windows are 26px wider than the requested minimum width.
This is an important issue because it causes windows to not fit in screens that
did fit previously. Debian on mobile is especially affected by this issue
because many apps have the requested min width of 360px that is the width of
the screen of the Librem 5. Those apps get a width of 386px and don't fit on
the screen making them hardly usable.

There is an upstream bug report of this issue that is now fixed:
https://gitlab.gnome.org/GNOME/mutter/-/issues/1542



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

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

Versions of packages mutter depends on:
ii  adwaita-icon-theme3.38.0-1
ii  gnome-settings-daemon-common  3.38.1-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libc6 2.31-4
ii  libgles2  1.3.2-1
ii  libglib2.0-0  2.66.3-1
ii  libmutter-7-0 3.38.1-2
ii  libwayland-client01.18.0-2~exp1.1
ii  libx11-6  2:1.6.12-1
ii  libxcomposite11:0.4.5-1
ii  mutter-common 3.38.1-2
ii  zenity3.32.0-6

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:3.38.1-1
ii  xdg-user-dirs 0.17-2

-- no debconf information

Bug#976019: vips 8.7.4-1+deb10u1 flagged for acceptance

2020-11-28 Thread Adam D Barratt

package release.debian.org
tags 976019 = 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: vips
Version: 8.7.4-1+deb10u1

Explanation: fix use of uninitialised variable [CVE-2020-20739]

Bug#975650: blhc: reports false positives for missing flags

2020-11-28 Thread Eriberto

Thanks Fabian and Simon!

Considering that some false positives can't be fixed in blhc source
code, could I close this bug?

Cheers,

Eriberto

Bug#976043: d/control: moving to libgdk-pixbuf-2.0-dev and what about dh-sequence-gnome

On Sat, 28 Nov 2020 at 20:09:41 +0100, Patrice Duroux wrote:
> I am using cowbuilder + pbuilder to build gtkmm3.0 from source and before
> facing #959602, I got the following:
> 
> $ pdebuild --pbuilder cowbuilder -- --distribution bullseye --basepath
> /var/cache/pbuilder/base-bullseye.cow
> I: using cowbuilder as pbuilder
> dpkg-checkbuilddeps: error: Unmet build dependencies: dh-sequence-gnome 
> doxygen
> libgdk-pixbuf2.0-dev (>= 2.35.5) mm-common (>= 0.9.10) xvfb

Is your base image up to date?

gtkmm3.0 3.24.2-2, which I uploaded today, builds successfully in sbuild
using an unstable chroot.

I don't use cowbuilder myself; if that can't build gtkmm3.0 but sbuild
can, then that suggests that there's a problem with either cowbuilder's
build-dependency resolver or the base image you're using.

Note that packages intended for upload to unstable are meant to be built
in unstable, not testing.

> dh-sequence-gnome is a virtual package supplied by gnome-pkg-tools

That's correct. Build-dependency resolvers should be able to work out
that this means they need to install gnome-pkg-tools (sbuild does that
successfully).

> Finally in d/control, I just removed dh-sequence-gnome.

Please don't. This will break the mechanism that updates debian/control
from debian/control.in, and might break the package's build in other ways.

> But also, main point of this report, I also replaced libgdk-pixbuf2.0-dev by
> libgdk-pixbuf-2.0-dev
>
> The built was ok then.

Installing libgdk-pixbuf2.0-dev as a build-dependency should work fine in
an up-to-date chroot. For example, I tried building tumbler in sbuild. It
correctly installs the transitional libgdk-pixbuf2.0-dev, which pulls in
libgdk-pixbuf-2.0-dev and libgdk-pixbuf-xlib-2.0-dev.

For packages that don't need the deprecated Xlib integration it's better
to switch the build-dependency to libgdk-pixbuf-2.0-dev, as I did in
gtkmm3.0 3.24.2-2 before seeing this bug report, but not doing that
shouldn't break the build.

smcv

Bug#969675: mailutils: please upgrade to guile-3.0 soon, if feasible

2020-11-28 Thread Rob Browning

severity 969675 normal
thanks

Rob Browning  writes:

> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
> like to have the option to drop guile-2.2 from bullseye, so that we
> won't have to maintain two versions throughout that release.

I can't be sure this will work, given the other FTBS, but it might be
a start:

diff --git a/.pc/set_mu_sieve_moddir.patch/configure.ac 
b/.pc/set_mu_sieve_moddir.patch/configure.ac
index fa5baa0..4c7ed7f 100644
--- a/.pc/set_mu_sieve_moddir.patch/configure.ac
+++ b/.pc/set_mu_sieve_moddir.patch/configure.ac
@@ -1162,7 +1162,7 @@ AC_SUBST([GUILE_BINDIR])
 AC_SUBST([LIBMU_SCM])
 AC_SUBST([LIBMU_SCM_DEPS])
 AC_SUBST([MU_GUILE_SIEVE_MOD_DIR])
-GINT_INIT([gint],[2.2.0 with-guile],
+GINT_INIT([gint],[3.0 with-guile],
  [useguile=yes
   AC_DEFINE([WITH_GUILE],1,[Enable Guile support])
GUILE_BINDIR=`guile-config info bindir`
diff --git a/configure.ac b/configure.ac
index 174ee01..74774fe 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1169,7 +1169,7 @@ AC_SUBST([GUILE_BINDIR])
 AC_SUBST([LIBMU_SCM])
 AC_SUBST([LIBMU_SCM_DEPS])
 AC_SUBST([MU_GUILE_SIEVE_MOD_DIR])
-GINT_INIT([gint],[2.2.0 with-guile],
+GINT_INIT([gint],[3.0 with-guile],
  [useguile=yes
   AC_DEFINE([WITH_GUILE],1,[Enable Guile support])
GUILE_BINDIR=`guile-config info bindir`
diff --git a/debian/control b/debian/control
index 7e61ef3..f137928 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Build-Depends: bison,
flex,
gawk,
gettext,
-   guile-2.2-dev,
+   guile-3.0-dev,
help2man,
libfribidi-dev,
libgnutls28-dev,
@@ -220,7 +220,7 @@ Package: mailutils-guile
 Architecture: any
 Depends: mailutils-common (= ${source:Version}),
  libmailutils-dev,
- guile-2.2 | guile,
+ guile-3.0 | guile,
  ${misc:Depends},
  ${shlibs:Depends}
 Description: GNU mailutils Guile interpreter and modules

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#973741: [Pkg-javascript-devel] Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

2020-11-28 Thread Paolo Greppi


See below

Il 28/11/20 20:28, Pirate Praveen ha scritto:

On Thu, 19 Nov 2020 23:50:24 +0530 Pirate Praveen  
wrote:
...
So some options I can think,

1. Port yarn 1.x to build with babel 7 (but this has not been successfull)
2. Try to run ES6 code directly somehow, may be with newer nodejs and patches. 
I think Paolo tried this option, not sure what happened.


I did some tests, but no success.

The plan was to target node 14 (that supports ECMAScript modules) as follows:
- move entire src tree to lib
- strip flow type annotations with @babel/plugin-transform-flow-strip-types
- rename all files from .js to .mjs
- have /usr/bin/yarnpkg just launch node 
/usr/share/nodejs/yarn/lib/cli/index.mjs

I got lost at some point trying to make node find modules here and there, with 
a quote from W. Allen Sleeper's film echoing in my ears:
https://youtu.be/XA_Zrvxjyek#t=1m00s

The resulting binary fails with this error:
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'commander' imported from 
/usr/share/nodejs/yarn/lib/cli/index.mjs

I pushed my failed experiment to this separate repo:
https://salsa.debian.org/paolog/node-yarnpkg/-/tree/wip/paolog/nobabel


3. Build it using 'deb 
https://snapshot.debian.org/archive/debian/20200502T085134Z sid main' (the last 
version that builds in sid) and embed the built files in the package (as two 
steps, like we bootstrap babel, rollup etc). This will mean, we will have to 
move it to contrib. I prefer shipping yarn in contrib to missing it in bullseye.


+1


Also can someone help me with a patch for node-mkdirp 1.0? I tried but could 
not figure it out, I looked at some of the packages ported by yadd, but this 
one is using a different syntax.


Not sure if it's relevant, but did you check this comment ?
https://github.com/yarnpkg/yarn/issues/8417#issuecomment-723519990


We can't build it in current sid, but create a chroot from the above snapshot 
and run dpkg-buildpackage.

sudo debootstrap sid /srv/chroot/debian-sid-20200502T085134Z 
https://snapshot.debian.org/archive/debian/20200502T085134Z/

I manually installed node-mkdirp and reverse dependencies to test the built 
package.

We will have to do a binary included upload (it can't migrate to testing 
because of babel 6 requirement anyway).




Paolo

Bug#976050: mailutils: FTBFS on amd64 with current unstable

2020-11-28 Thread Rob Browning



Package: mailutils
Version: 1:3.10-3
Severity: serious

After an "apt-get source mailutils/sid" with current unstable,
"debian/rules binary" fails here like this:

  Creating popauth.1...
  /home/vagrant/mailutils/mailutils-3.10/debian/tmp/usr/bin/popauth: error 
while loading shared libraries: libmu_dbm.so.7: cannot open shared object file: 
No such file or directory
  help2man: can't get `--help' info from 
/home/vagrant/mailutils/mailutils-3.10/debian/tmp/usr/bin/popauth
  Try `--no-discard-stderr' if option outputs to stderr
  make[1]: *** [debian/rules:52: override_dh_auto_install] Error 127
  make[1]: Leaving directory '/home/vagrant/mailutils/mailutils-3.10'
  make: *** [debian/rules:4: binary] Error 2

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#972679: chrony 4.0 in backports

2020-11-28 Thread Kurt Roeckx

On Sat, Nov 28, 2020 at 07:54:05PM +0100, Vincent Blut wrote:
> Anyone willing to test the attached deb on Buster? FWIW, it seems to behave
> nicely on my VM.

It seems to be working fine for me.

I've enabled NTS on ntp.roeckx.be, both as client and server, and
both seem to be working fine.

It seems to set up NTS as a server, I had to put the key and
certificate in /var/lib/chrony/, it was not happy with files in any
other place. It works without problems as a client.

Kurt

Bug#971815: podman: --init is broken: /usr/libexec/podman/catatonit not found

2020-11-28 Thread Reinhard Tartler

Awesome, thanks!

On Sat, Nov 28, 2020, 15:50 Antonio Terceiro  wrote:

> Hello Reinhard,
>
> On Sat, Nov 28, 2020 at 10:57:52AM -0500, Reinhard Tartler wrote:
> > please go ahead with packaging catatonit. Regarding the symlink, I don't
> > have a strong preference, your patch seems reasonable to me!
>
> I have uploaded it to NEW, including the /usr/libexec/podman/catatonit
> symlink.
>
> After it goes through, it would be just a matter of making it the
> default in the alternative dependency, i.e.
>
> catatonit | tini | dumb-init
>

Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu

2020-11-28 Thread Félix Arreola Rodríguez

Now I think this bug, this could be used as DOS, should we call the
security team to handle this?

-- 
Atte. Félix Arreola
Firmado con GPG 0x1e249ee4


pgpV3xZ_Wj95S.pgp
Description: Firma digital OpenPGP

Bug#971815: podman: --init is broken: /usr/libexec/podman/catatonit not found

2020-11-28 Thread Antonio Terceiro

Hello Reinhard,

On Sat, Nov 28, 2020 at 10:57:52AM -0500, Reinhard Tartler wrote:
> please go ahead with packaging catatonit. Regarding the symlink, I don't
> have a strong preference, your patch seems reasonable to me!

I have uploaded it to NEW, including the /usr/libexec/podman/catatonit
symlink.

After it goes through, it would be just a matter of making it the
default in the alternative dependency, i.e.

catatonit | tini | dumb-init

signature.asc
Description: PGP signature

Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu

2020-11-28 Thread Félix Arreola Rodríguez

On Mon, 16 Dec 2019 02:37:50 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?=
 wrote:
> Dear Maintainer,
> tried to reconstruct the given backtrace with debug symbols
> in a gdb session and came to following, maybe it could be
> of some help.
> (Still a proper backtrace with dbgsym packages
> installed would be better.)
> 
> Kind regards,
> Bernhard
> 
> 

Dear Maintainer:

I came across this bugs too. The problem is a infinite loop between
mod-reqtimeout and mod-gnutls. The mod-gnutls (and underlaying gnutls)
tries to read some bytes when the client hasn't sent any (like an empty
tcp conn) and the mod-reqtimeout returns a timeout, causing mod-gnutls
to loop endless trying to read more. Either mod-reqtimeout is broken,
or either mod-gnutls doesn't handle correctly the timeouts.

After debugging a lot with gdb, I can reconstruct the loop as follow:

The code starts at function gnutls_io_input_read from gnutls_io.c from
mod_gnutls, line 246, the "while(1)" loop.

The code calls gnutls_record_recv, from gnutls, which in turns calls
_gnutls_recv_int. gnutls_recv_int is called with
type=GNUTLS_APPLICATION_DATA asking for 8192 bytes. Next it calls
check_session_status, which checks if there is an EOF, and there is
NO EOF. Also, check_session_status says that the
session->internals.recv_state is RECV_STATE_0, whichs makes
check_session_status return 1.

Next, it calls get_data_from_buffers, which returns 0, which means
there is no data in the buffer to consume. Next, it
calls _gnutls_recv_in_buffers. _gnutls_recv_in_buffers calls
recv_headers, which tries to read the header (which is 5). it calls
_gnutls_io_read_buffered for 5 bytes. _gnutls_io_read_buffered ask for
5 bytes to _gnutls_read, which in turn uses _gnutls_stream_read to
complete the request.

_gnutls_stream_read returns back to mod-gnutls using the "pull_func"
mgs_transport_read. msg_transport_read is located at gnutls_io.c:824
mgs_transport_read tries to use ap_get_brigade to get some bytes from
the underlaying socket.

ap_get_brigade tries to read from the "next" ap_filter_t, which (in my
case) is "reqtimeout". reqtimeout_filter function calls
check_time_left, which returns APR_TIMEUP. When it returns APR_TIMEUP,
it logs "Request %s read timeout". So, back to mgs_transport_read, it
reads APR_TIMEUP from the ap_get_brigade. BUT, it handles wrong this
timeout and converts it to EAGAIN, which makes this whole stack run
back.

This is a big, 'nice' nasty bug, I have to say.

As a workout around, I disabled module reqtimeout. Seems to solve the
cpu usage issue. But, the bug is way more big than 'disabling'
reqtimeout. Because, the problem is between mod-gnutls and
mod-reqtimeout

Steps to reproduce:
Enable apache2 with the modules mod-gnutls, and mod-reqtimeout. Setup a
reqtimeout like: RequestReadTimeout header=20-40,minrate=500 and open
an openssl s_client:

openssl s_client -connect IP:port

Don't send any data over the openssl connect. Just wait for the timeout
to happen. After the timeout, the CPU usage will increase. Also, you
can quit the openssl s_client and the apache process will be stuck in
the endless loop.

-- 
Atte. Félix Arreola
Firmado con GPG 0x1e249ee4

pgpRhuwCqo6hD.pgp
Description: Firma digital OpenPGP

Bug#976038: openstack-pkg-tools: pkgos-make causes FTBFS when used in Dh-Compat 13 (due to dh_systemd_enable)

2020-11-28 Thread Lorenzo Puliti

Package: openstack-pkg-tools
Version: 116
Severity: important
Tags: patch
X-Debbugs-Cc: plore...@disroot.org

Dear Maintainers,

bumping the Dh_compat level to 13 of opentmpfiles causes FTBFS with the 
following

$ dpkg-buildpackage -us -uc
dpkg-buildpackage: info: source package opentmpfiles
dpkg-buildpackage: info: source version 0.2+2019.05.21.git.44a55796ba-3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Lorenzo Puliti 
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
 fakeroot debian/rules clean

pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions 
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
debian/rules:16: warning: overriding recipe for target 'override_dh_installinit'
/usr/share/openstack-pkg-tools/pkgos.make:43: warning: ignoring old recipe for 
target 'override_dh_installinit'
dh clean
dh: warning: The target override_dh_systemd_enable references a now obsolete 
command and will not be run!
dh: error: Aborting due to left over override/hook targets for now removed 
commands.
make: *** [debian/rules:7: clean] Error 255
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2


dh_systemd_enable is discouraged and in dh compat 13 causes an error, this is 
documented in
Debhelper manpage (section describing Compat level 13)
"- The dh command will now error if an override or hook target for
   an obsolete command are present in debian/rules (e.g. 
override_dh_systemd_enable:)."

The attached patch fix the issue for me but be aware that i'm building on a non
standard system, I have a poor knowledge about systemd and its dh tools, and
I have not serched for other occurrencies of dh_systemd_enable in this package, 
so
it could be wise to seek help from the systemd team before applying the patch

Best Regards,
Lorenzo

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages openstack-pkg-tools depends on:
ii  gettext  0.19.8.1-10
ii  jq   1.6-1
ii  po-debconf   1.0.21
ii  python3-pip  20.1.1-2

Versions of packages openstack-pkg-tools recommends:
ii  autopkgtest   5.15
ii  madison-lite  0.26
ii  pristine-tar  1.49

openstack-pkg-tools suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/openstack-pkg-tools/pkgos.make (from 
openstack-pkg-tools package)
--- pkgos.make.now  2020-11-15 22:59:21.0 +0100
+++ pkgos.make.patched  2020-11-28 16:23:29.562425427 +0100
@@ -36,8 +36,8 @@
fi \
done
 
-override_dh_systemd_enable: gen-init-configurations
-   dh_systemd_enable
+override_dh_installsystemd: gen-init-configurations
+   dh_installsystemd
 
 override_dh_installinit: gen-init-configurations
dh_installinit --error-handler=true

Bug#975941: add exception case to package-contains-documentation-outside-usr-share-doc if docs are linked to /usr/share/doc?

2020-11-28 Thread Nicholas D Steeves

Hi Russ,

Russ Allbery  writes:

> Nicholas D Steeves  writes:
>
>> The case is software that provides, for example, html docs, and that
>> opens these docs using the standard F1 (file bar help) interface.  Such
>> docs should of course also be present in /usr/share/doc.  As I see it,
>> the question is whether the files should actually exist in their
>> upstream location--which in Debian translates to /usr/share/foo/bar and
>> have these docs linked to /usr/share/doc, or whether they should be
>> moved to /usr/share/doc and be linked back to where the software expects
>> them.  Option three is maintaining a patch for a Debian-specific
>> location, but I don't think that's the right solution.
>
>> So, should Lintian not warn about
>> package-contains-documentation-outside-usr-share-doc if the package
>> links the assets to /usr/share/doc, or should the Lintian information
>> output recommend the inverse case (moving the docs to /usr/share/doc and
>> linking them back to where the software expects them)?
>
> If the files are used at runtime, Policy requires installing the files
> outside of /usr/share/doc and linking them to /usr/share/doc.  See Policy
> 12.3, second-to-last paragraph.
>

Thank you for definitively NACKing that option.

Given that W: package-contains-documentation-outside-usr-share-doc will
still warn in cases where Policy requires the documentation, which
suggests that lintian wants developers to do something different than
Policy, it seems like there are two or three avenues forward:

1. Demote package-contains-documentation-outside-usr-share-doc to
experimental--still not a great option, because of the tension with
Policy.

2. Check to see if docs have been linked to /usr/share/doc for
discoverability, and if they haven't then warn with something like
packages-doesnt-link-documentation-to-usr-share-doc.  Lintian output is
clean if the docs have been linked.  Alternatively maybe
package-contains-documentation-outside-usr-share-doc explanatory
information could be updated instead of adding
packages-doesnt-link-documentation-to-usr-share-doc?

3. Update explanatory information of
packages-doesnt-link-documentation-to-usr-share-doc to note that it will
find false positives and that lintian overrides should be employed.

In any case, I think Policy §12.3 should be cited in the explanatory
description[s].

Of course, if the expectation is that all software should be patched to
get its runtime documentation from /usr/share/doc, then Policy should be
amended.

Regards,
Nicholas

signature.asc
Description: PGP signature

Bug#976049: ros-ros-comm: autopkgtest regression: No rule to make target '/usr/lib//libpython3.9.so'

Source: ros-ros-comm
Version: 1.15.9+ds1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent change in testing (I believe the support of Python3.9) the
autopkgtest of ros-ros-comm started to fail. I copied some of the output
at the bottom of this report. I'm not into the details of how the python
packaging works, but you seem to be missing a (test) dependency
somewhere. libpython3.9.so is provided by libpython3.9-dev. 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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ros-ros-comm/8397909/log.gz

+ cmake --build build
Scanning dependencies of target main
[ 10%] Building CXX object CMakeFiles/main.dir/main.cc.o
gmake[2]: *** No rule to make target
'/usr/lib/x86_64-linux-gnu/libpython3.9.so', needed by 'main'.  Stop.
gmake[1]: *** [CMakeFiles/Makefile2:117: CMakeFiles/main.dir/all] Error 2
gmake: *** [Makefile:160: all] Error 2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976048: ITP: seatd -- Minimal user, seat and session management daemon

2020-11-28 Thread Mark Hindley

Package: wnpp
Severity: wishlist
Owner: Mark Hindley 

* Package name: seatd
  Version : 0.4.0
  Upstream Author : Kenny Levinsen 
* URL : https://git.sr.ht/~kennylevinsen/seatd
* License : Expat
  Programming Lang: C
  Description : Flexible user, seat and session management daemon

Supports runtime switching between backend implementations. Currently this
includes seatd itself, elogind and systemd-logind.

Bug#976047: shoogle: flaky autopkgtest on ci.debian.net and missing needs-internet restriction

Source: shoogle
Version: 0.1.4-9
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky
Control: affects -1 python3-defaults

Dear maintainer(s),

shoogle has an autopkgtest, great. However, it fails more often than it
passes [1].

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

I copied the output at the bottom of this report. Can you please look
into it and make the test more robust (against network issues). If you
keep the test that requires internet, you should add the needs-internet
restriction too.

Paul

[1] https://ci.debian.net/packages/s/shoogle/testing/amd64/
[2] https://ci.debian.net/packages/s/shoogle/testing/arm64/

https://ci.debian.net/data/autopkgtest/testing/amd64/s/shoogle/8333563/log.gz

==
FAIL: test_main_execute_with_missing_parameter
(tests.test_shoogle.TestShoogle)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.es_gm45h/downtmp/build.BYz/src/tests/test_shoogle.py",
line 158, in test_main_execute_with_missing_parameter
self.assertIn('Missing required parameter "task"', e.err)
AssertionError: 'Missing required parameter "task"' not found in
'/tmp/autopkgtest-lxc.es_gm45h/downtmp/build.BYz/src/shoogle/common.py:34:
ResourceWarning: unclosed \n
apis =
download("https://www.googleapis.com/discovery/v1/apis;)\nResourceWarning:
Enable tracemalloc to get the object allocation
traceback\n/tmp/autopkgtest-lxc.es_gm45h/downtmp/build.BYz/src/shoogle/common.py:64:
ResourceWarning: unclosed \n
service_json = download(service["discoveryRestUrl"])\nResourceWarning:
Enable tracemalloc to get the object allocation traceback\n[ERROR]
googleapiclient.discovery: Missing required parameter "tasklist"\n'

--
Ran 12 tests in 5.137s

FAILED (failures=1)
Test failed: 
error: Test failed: 
autopkgtest [12:10:55]: test test-unittest: ---]

Bug#976046: RM: kore [i386 mips64el mipsel ppc64el s390x] -- ANAIS; maintainer limited architectures to upstream supported ones

Package: ftp.debian.org
X-Debbugs-Cc: fourdoll...@debian.org
Severity: normal
Control: block 975839 by -1

Dear ftp-masters,

The src:kore package stopped building binaries on i386, mips64el,
mipsel, ppc64el and s390x. The package is not migrating because the
maintainer didn't ask for removal of the old binaries, hence I file this
bug now.

Please remove the binaries on unsupported architectures.

Paul

Bug#976045: bind9: flaky autopkgtest on ci.debian.net

Source: bind9
Version: 1:9.11.5.P4+dfsg-5.1+deb10u2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky
Control: found -1 1:9.16.8-1

Dear maintainer(s),

bind9 has an autopkgtest, great. However, your test (correctly) has the
restriction needs-internet, but it doesn't retry the part where it uses
the internet.  On ci.debian.net, we're seeing (e.g. [1]) regular
failures in the internet based test. Can you please make the test more
robust against network issues? E.g. a couple of retries with some time
in between before failing?

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

I copied the output at the bottom of this report.

Please do get in touch if we need to dive into this together.

Paul

[1] https://ci.debian.net/packages/b/bind9/testing/amd64/

https://ci.debian.net/data/autopkgtest/stable/armhf/b/bind9/8471318/log.gz

autopkgtest [21:59:15]: test simpletest: [---

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> -x 127.0.0.1 @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53032
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 20d019dc324ffa05fbfc9b425fc176b5e6f0b962dccc8e3c (good)
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 604800  IN  PTR localhost.

;; AUTHORITY SECTION:
127.in-addr.arpa.   604800  IN  NS  localhost.

;; ADDITIONAL SECTION:
localhost.  604800  IN  A   127.0.0.1
localhost.  604800  IN  ::1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Nov 27 21:59:17 UTC 2020
;; MSG SIZE  rcvd: 160

Checking for DNSSEC validation status of internetsociety.org
autopkgtest [21:59:17]: test simpletest: ---]

Bug#913864: KiCad is not usable, because cvpcb is not working

2020-11-28 Thread Carsten Schoenert


Hi,

Am 28.11.20 um 11:17 schrieb Karsten:


i have made my circuit diagram, but cvpcb is not working.
The window opens, but when you click on a library, the component list is not 
actualized in the window right.

So you can't assign the footprints to the components.
KiCad is unusable, because at this point you can't proceed to layout.


I can't reproduce this behavior. Seems to me you didn't use CvPcb the 
way it is intended.


And btw., your message about your potential problem is completely wrong 
in this report.


--
Regards
Carsten

Bug#973741: [Pkg-javascript-devel] Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

2020-11-28 Thread Xavier




Le 28/11/2020 à 20:28, Pirate Praveen a écrit :
> On Thu, 19 Nov 2020 23:50:24 +0530 Pirate Praveen
>  wrote:
>>
>>
>> On Thu, Nov 19, 2020 at 18:58, Xavier  wrote:
>> > we opened bugs to upstream repo and are waiting for...
>>
>> I don't think upstream will make any significant changes to 1.x branch
>> any more. Someone who want to see yarn in debian bullseye will have to
>> fix it.
> 
> As per https://dev.to/arcanis/introducing-yarn-2-4eh1 yarn 1.x is
> officially in maintenance mode.
> 
> Quoting from above:
> 
> "What will happen to the legacy codebase?
> 
> Yarn 1.22 will be released next week. Once done, the 1.x branch will
> officially enter maintenance mode - meaning that it won't receive
> further releases from me except when absolutely required to patch
> vulnerabilities. New features will be developed exclusively against Yarn
> 2."
> 
> And there is no way to separately install yarn 2, you have to install
> yarn 1.x to get newer versions of yarn.
> 
> Quoting again,
> "The yarn package on npm will not change; we will distribute further
> version using the new yarn set version command."
> 
> So some options I can think,
> 
> 1. Port yarn 1.x to build with babel 7 (but this has not been successfull)
> 2. Try to run ES6 code directly somehow, may be with newer nodejs and
> patches. I think Paolo tried this option, not sure what happened.
> 3. Build it using 'deb
> https://snapshot.debian.org/archive/debian/20200502T085134Z sid main'
> (the last version that builds in sid) and embed the built files in the
> package (as two steps, like we bootstrap babel, rollup etc). This will
> mean, we will have to move it to contrib. I prefer shipping yarn in
> contrib to missing it in bullseye.
> 
> Also can someone help me with a patch for node-mkdirp 1.0? I tried but
> could not figure it out, I looked at some of the packages ported by
> yadd, but this one is using a different syntax.

Hi, just to replace mkdirp by mkdirp-classic in src/util/fs.js

> We can't build it in current sid, but create a chroot from the above
> snapshot and run dpkg-buildpackage.
> 
> sudo debootstrap sid /srv/chroot/debian-sid-20200502T085134Z
> https://snapshot.debian.org/archive/debian/20200502T085134Z/
> 
> I manually installed node-mkdirp and reverse dependencies to test the
> built package.
> 
> We will have to do a binary included upload (it can't migrate to testing
> because of babel 6 requirement anyway).
> 
>

Bug#973741: [Pkg-javascript-devel] Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

2020-11-28 Thread Pirate Praveen

On Thu, 19 Nov 2020 23:50:24 +0530 Pirate Praveen 
 wrote:

>
>
> On Thu, Nov 19, 2020 at 18:58, Xavier  wrote:
> > we opened bugs to upstream repo and are waiting for...
>
> I don't think upstream will make any significant changes to 1.x 
branch
> any more. Someone who want to see yarn in debian bullseye will have 
to

> fix it.

As per https://dev.to/arcanis/introducing-yarn-2-4eh1 yarn 1.x is 
officially in maintenance mode.

Quoting from above:

"What will happen to the legacy codebase?

Yarn 1.22 will be released next week. Once done, the 1.x branch will 
officially enter maintenance mode - meaning that it won't receive 
further releases from me except when absolutely required to patch 
vulnerabilities. New features will be developed exclusively against 
Yarn 2."

And there is no way to separately install yarn 2, you have to install 
yarn 1.x to get newer versions of yarn.

Quoting again,
"The yarn package on npm will not change; we will distribute further 
version using the new yarn set version command."

So some options I can think,

1. Port yarn 1.x to build with babel 7 (but this has not been 
successfull)
2. Try to run ES6 code directly somehow, may be with newer nodejs and 
patches. I think Paolo tried this option, not sure what happened.
3. Build it using 'deb 
https://snapshot.debian.org/archive/debian/20200502T085134Z sid main' 
(the last version that builds in sid) and embed the built files in the 
package (as two steps, like we bootstrap babel, rollup etc). This will 
mean, we will have to move it to contrib. I prefer shipping yarn in 
contrib to missing it in bullseye.

Also can someone help me with a patch for node-mkdirp 1.0? I tried but 
could not figure it out, I looked at some of the packages ported by 
yadd, but this one is using a different syntax.

We can't build it in current sid, but create a chroot from the above 
snapshot and run dpkg-buildpackage.

sudo debootstrap sid /srv/chroot/debian-sid-20200502T085134Z 
https://snapshot.debian.org/archive/debian/20200502T085134Z/

I manually installed node-mkdirp and reverse dependencies to test the 
built package.

We will have to do a binary included upload (it can't migrate to 
testing because of babel 6 requirement anyway).

Bug#976018: cups 2.2.10-6+deb10u4 flagged for acceptance

2020-11-28 Thread Adam D Barratt

package release.debian.org
tags 976018 = 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+deb10u4

Explanation: fix 'printer-alert' invalid free

Bug#966138: Package: connman sysvint script disables DNS lookups when resolvconf package installed

2020-11-28 Thread Pelayo González Muñoz

There is a typo in the init script, a "$" is missing to expand the variable:

if [ "CONNMAN_RUNSTATEDIR_RESOLVCONF" != "no" ] ; then

Should be:

if [ "$CONNMAN_RUNSTATEDIR_RESOLVCONF" != "no" ] ; then

Once fixed, create /etc/default/connman:

echo " CONNMAN_RUNSTATEDIR_RESOLVCONF=no" > /etc/default/connman

Regards
--
Pelayo González

On Thu, 23 Jul 2020 11:39:54 -0400 Vernon Van Steenkist 
wrote:
> Package: connman
> Version: 1.36-2
>
> Beowulf connman 1.36-2 i386 sysvinit script conflicts with resolvconf
1.79 package leaving the system in a state unable to do DNS lookups.
>
> Problem one:
>
> sed -n "22,25p" /etc/init.d/connman
>
> if [ "CONNMAN_RUNSTATEDIR_RESOLVCONF" != "no" ] ; then
>  mkdir -p /run/connman
>  ln -sf /run/connman/resolv.conf /etc/
> fi
>
> Since string CONNMAN_RUNSTATEDIR_RESOLVCONF will never be equal to string
no, the following line will always be executed
> ln -sf /run/connman/resolv.conf /etc/
>
>
> So, I am not what conditional
>
> if [ "CONNMAN_RUNSTATEDIR_RESOLVCONF" != "no" ]
>
> is supposed to accomplish.
>
> Problem Two:
>
> This creates a problem when using the resolvconf package. Package
resolvconf links /etc/resolv.conf to
> /run/resolvconf/resolv.conf However, after re-boot, /etc/init.d/connman
overwrites this link and links
> /etc/resolv.conf to /run/connman/resolv.conf
> once again leaving the system in a state unable to do DNS look-ups.
>
> I have brute forced a fix by commenting out the line
> ln -sf /run/connman/resolv.conf /etc/ in /etc/init.d/connman
>
> sed -n "22,25p" /etc/init.d/connman
>
> if [ "CONNMAN_RUNSTATEDIR_RESOLVCONF" != "no" ] ; then
>  mkdir -p /run/connman
> #ln -sf /run/connman/resolv.conf /etc/
> fi
>
> and re-linking /etc/resolv.conf to /run/resolvconf/resolv.conf
>
> I am not sure what the correct fix should be.
>
> Please don't hesitate to contact me if you have any questions.
>
> Thanks,
> Vernon
>
>
>

Bug#976042: llvm-11: generates WebAssembly incompatible with binaryen 98

2020-11-28 Thread Sylvestre Ledru




Le 28/11/2020 à 19:57, Jonas Smedegaard a écrit :
> Package: llvm-11
> Version: 1:11.0.0-5+b1
> Severity: normal

Seems to me that -  - the least invasive solution is to have
LLVM 11


is your sentence finished ? :)



Assuming my understanding of the above is correct, the least invasive
solution seems to be to have llvm-11 cherry-pick the LLVM patch to
handle this "emscripten EH functions" renaming:
https://github.com/llvm/llvm-project/commit/3bba91f64eef15956f589fa446c265a714cc7893


I am not super excited to take a patch that big, esp for bullseye.

Instead, what about getting upstream to take this patch into 11.0.1 ? 
(which will be ready in time for bullseye).


Thanks

S

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

On Sat, 2020-11-28 at 11:07 -0800, tony mancill wrote:
> On Sat, Nov 28, 2020 at 04:56:28PM +, Adam D. Barratt wrote:
> > On Sat, 2020-11-28 at 08:01 -0800, tony mancill wrote:
> > > On Sat, Nov 28, 2020 at 05:10:39PM +0200, Adrian Bunk wrote:
> > > > On Wed, Nov 25, 2020 at 08:23:45PM -0800, tony mancill wrote:
> > > > > -with_check = disabled for this upload
> > > > > +# with_check = disabled for this upload
> > > > > ...
> > > > 
> > > > FTR, this change increases the build time on zero architectures
> > > > by
> > > > half a week of running tests.
> > > > 
> > > > E.g. on mipsel-osuosl-01 that is currently building mips64el
> > > > this
> > > > adds 3 days 23 hours to the buildtime.[1]
> > > > 
> > > > Which is a bit wasteful since failures are ignored and a 3
> > > > digit
> > > > number of tests fail on all release architectures.
> > [...]
> > > Ugh, that is unfortunate.  The "with_check" change is there to
> > > keep
> > > the package as close to the version in testing/unstable as
> > > feasible.  The only sourceful packaging difference is the build-
> > > dep
> > > on g++-8 instead of g++-10.
> > > 
> > > Adam expressed concerns about the change as well.  Do I need to
> > > prepare another upload?
> > 
> > Given that this weekend is the freeze for the point release, that
> > might
> > be safest, just in case the builds show any issues. It's at least
> > not a
> > regression from the version currently in buster.
> 
> I assumed that I needed to bump the revision instead of overwriting
> deb10u1; debdiff for the deb10u2 source package attached.  

That's correct.

> Let me know if that looks okay and I can proceed with the upload.

As this is the second revision, it doesn't need the:

+  * Rebuild for Buster (Closes: #975728)

but if it makes it easier to get the upload sorted more quickly then I
also don't mind it being included. Please feel free to upload.

Regards,

Adam

Bug#976044: (no subject)

2020-11-28 Thread Mmobilea


Package: debconf

Version: 1.5.74

Severity: low

I'm sending a translation.

# debconf
# Copyright (C) 2000 Free Software Foundation, Inc.
# Polish translation Copyright (C) Marcin Owsiany , 
2000-2002.
#
msgid ""
msgstr ""
"Project-Id-Version: debconf\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-02-28 09:48+\n"
"PO-Revision-Date: 2014-12-04 21:59+0100\n"
"Last-Translator: Marcin Owsiany \n"
"Language-Team: Polish \n"
"Language: pl\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../Debconf/AutoSelect.pm:88
#, perl-format
msgid "falling back to frontend: %s"
msgstr "powrót do nakładki: %s"

#: ../Debconf/AutoSelect.pm:96
#, perl-format
msgid "unable to initialize frontend: %s"
msgstr "nie udało się zainicjalizować nakładki: %s"

#: ../Debconf/AutoSelect.pm:102
#, perl-format
msgid "Unable to start a frontend: %s"
msgstr "Nie udało się uruchomić nakładki: %s"

#: ../Debconf/Config.pm:130
msgid "Config database not specified in config file."
msgstr "Brak bazy danych konfiguracji w pliku konfiguracyjnym."

#: ../Debconf/Config.pm:134
msgid "Template database not specified in config file."
msgstr "Brak bazy danych szablonów w pliku konfiguracyjnym."

#: ../Debconf/Config.pm:139
msgid ""
"The Sigils and Smileys options in the config file are no longer used. Please "
"remove them."
msgstr ""
"Opcje Sigils i Smileys w pliku konfiguracyjnym nie są już wykorzystywane - "
"zaleca się ich usunięcie."

#: ../Debconf/Config.pm:153
#, perl-format
msgid "Problem setting up the database defined by stanza %s of %s."
msgstr ""
"Problem z ustawieniem bazy danych zdefiniowanej przez fragment %s pliku %s."

#: ../Debconf/Config.pm:228
msgid ""
"  -f,  --frontend\t\tSpecify debconf frontend to use.\n"
"  -p,  --priority\t\tSpecify minimum priority question to show.\n"
"   --terse\t\t\tEnable terse mode.\n"
msgstr ""
"  -f,  --frontend\t\tUstawia określoną nakładkę.\n"
"  -p,  --priority\t\tOkreśla minimalny priorytet pytań jakie będą "
"pokazywane.\n"
"   --terse\t\t\tWłącza tryb zwięzły.\n"

#: ../Debconf/Config.pm:308
#, perl-format
msgid "Ignoring invalid priority \"%s\""
msgstr "Ignorowanie niewłaściwego priorytetu \"%s\""

#: ../Debconf/Config.pm:309
#, perl-format
msgid "Valid priorities are: %s"
msgstr "Właściwe priorytety to: %s"

#: ../Debconf/Element/Editor/Boolean.pm:30
#: ../Debconf/Element/Editor/Multiselect.pm:31
#: ../Debconf/Element/Editor/Select.pm:31
msgid "Choices"
msgstr "Pozycje do wyboru"

#: ../Debconf/Element/Editor/Boolean.pm:30
#: ../Debconf/Element/Editor/Boolean.pm:36
#: ../Debconf/Element/Editor/Boolean.pm:59
#: ../Debconf/Element/Teletype/Boolean.pm:28
msgid "yes"
msgstr "tak"

#: ../Debconf/Element/Editor/Boolean.pm:30
#: ../Debconf/Element/Editor/Boolean.pm:39
#: ../Debconf/Element/Editor/Boolean.pm:62
#: ../Debconf/Element/Teletype/Boolean.pm:29
msgid "no"
msgstr "nie"

#: ../Debconf/Element/Editor/Multiselect.pm:32
msgid ""
"(Enter zero or more items separated by a comma followed by a space (', ').)"
msgstr ""
"(Wpisz zero lub więcej pozycji oddzielonych przecinkiem i spacją (', ').)"

#: ../Debconf/Element/Gnome.pm:184
msgid "_Help"
msgstr "_Pomoc"

#: ../Debconf/Element/Gnome.pm:186
msgid "Help"
msgstr "Pomoc"

#: ../Debconf/Element/Noninteractive/Error.pm:40
msgid ""
"Debconf is not confident this error message was displayed, so it mailed it "
"to you."
msgstr ""
"Debconf nie ma pewności czy ten komunikat błędu został wyświetlony, więc "
"został przesłany do Ciebie pocztą elektroniczną."

#: ../Debconf/Element/Noninteractive/Error.pm:67
msgid "Debconf"
msgstr "Debconf"

#: ../Debconf/Element/Noninteractive/Error.pm:90
#, perl-format
msgid "Debconf, running at %s"
msgstr "Debconf, działający na %s"

#: ../Debconf/Element/Select.pm:95 ../Debconf/Element/Select.pm:110
#, perl-format
msgid ""
"Input value, \"%s\" not found in C choices! This should never happen. "
"Perhaps the templates were incorrectly localized."
msgstr ""
"Wartość wejściowa \"%s\" nie została znaleziona w źródłach C! To niepowinno. "
"się nigdy zdarzyć. Być może szablony nie zostały poprawnie przetłumaczone."

#: ../Debconf/Element/Teletype/Multiselect.pm:27
msgid "none of the above"
msgstr "żadna z powyższych"

#: ../Debconf/Element/Teletype/Multiselect.pm:47
#, fuzzy
#| msgid "Enter the items you want to select, separated by spaces."
msgid "Enter the items or ranges you want to select, separated by spaces."
msgstr "Wpisz, oddzielone spacjami, pozycje, które chcesz zaznaczyć."

#: ../Debconf/FrontEnd.pm:140
#, perl-format
msgid "Unable to load Debconf::Element::%s. Failed because: %s"
msgstr "Nie udało się załadować Debconf::Element:: %s. Powodem było: %s"

#: ../Debconf/FrontEnd.pm:333
#, perl-format
msgid "Configuring %s"
msgstr "Konfiguracja pakietu %s"

#: ../Debconf/FrontEnd/Dialog.pm:53
msgid "TERM is not set, so the dialog frontend is not usable."
msgstr ""
"Zmienna TERM nie jest ustawiona, więc nakładka \"dialog\" nie może działać."

Bug#976043: d/control: moving to libgdk-pixbuf-2.0-dev and what about dh-sequence-gnome

2020-11-28 Thread Patrice Duroux

Source: gtkmm3.0
Severity: wishlist

Dear Maintainer,

I am using cowbuilder + pbuilder to build gtkmm3.0 from source and before
facing #959602, I got the following:

$ pdebuild --pbuilder cowbuilder -- --distribution bullseye --basepath
/var/cache/pbuilder/base-bullseye.cow
I: using cowbuilder as pbuilder
dpkg-checkbuilddeps: error: Unmet build dependencies: dh-sequence-gnome doxygen
libgdk-pixbuf2.0-dev (>= 2.35.5) mm-common (>= 0.9.10) xvfb
W: Unmet build-dependency in source
dh clean
dh: error: unable to load addon gnome: Can't locate
Debian/Debhelper/Sequence/gnome.pm in @INC (you may need to install the
Debian::Debhelper::Sequence::gnome module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.32.0 /usr/local/share/perl/5.32.0
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-
gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32
/usr/local/lib/site_perl) at (eval 13) line 1.
BEGIN failed--compilation aborted at (eval 13) line 1.

make: *** [debian/rules:10: clean] Error 25

As this is not notified in #959602 and neither looking at reproducible builds
of Debian:
https://tests.reproducible-builds.org/debian/rb-
pkg/bullseye/amd64/gtkmm3.0.html

Is my system have something wrong?
dh-sequence-gnome is a virtual package supplied by gnome-pkg-tools

Finally in d/control, I just removed dh-sequence-gnome.

But also, main point of this report, I also replaced libgdk-pixbuf2.0-dev by
libgdk-pixbuf-2.0-dev

The built was ok then.

Thanks,
Patrice



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

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

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

2020-11-28 Thread tony mancill

On Sat, Nov 28, 2020 at 04:56:28PM +, Adam D. Barratt wrote:
> On Sat, 2020-11-28 at 08:01 -0800, tony mancill wrote:
> > On Sat, Nov 28, 2020 at 05:10:39PM +0200, Adrian Bunk wrote:
> > > On Wed, Nov 25, 2020 at 08:23:45PM -0800, tony mancill wrote:
> > > > -with_check = disabled for this upload
> > > > +# with_check = disabled for this upload
> > > > ...
> > > 
> > > FTR, this change increases the build time on zero architectures by
> > > half a week of running tests.
> > > 
> > > E.g. on mipsel-osuosl-01 that is currently building mips64el this
> > > adds 3 days 23 hours to the buildtime.[1]
> > > 
> > > Which is a bit wasteful since failures are ignored and a 3 digit
> > > number of tests fail on all release architectures.
> [...]
> > Ugh, that is unfortunate.  The "with_check" change is there to keep
> > the package as close to the version in testing/unstable as
> > feasible.  The only sourceful packaging difference is the build-dep
> > on g++-8 instead of g++-10.
> > 
> > Adam expressed concerns about the change as well.  Do I need to
> > prepare another upload?
> 
> Given that this weekend is the freeze for the point release, that might
> be safest, just in case the builds show any issues. It's at least not a
> regression from the version currently in buster.

I assumed that I needed to bump the revision instead of overwriting
deb10u1; debdiff for the deb10u2 source package attached.  

Let me know if that looks okay and I can proceed with the upload.

Thank you,
tony
diff -Nru openjdk-11-11.0.9.1+1/debian/changelog 
openjdk-11-11.0.9.1+1/debian/changelog
--- openjdk-11-11.0.9.1+1/debian/changelog  2020-11-25 08:55:48.0 
-0800
+++ openjdk-11-11.0.9.1+1/debian/changelog  2020-11-28 09:42:37.0 
-0800
@@ -1,3 +1,10 @@
+openjdk-11 (11.0.9.1+1-1~deb10u2) buster; urgency=medium
+
+  * Rebuild for Buster (Closes: #975728)
+  * Disable tests for this upload.
+
+ -- tony mancill   Sat, 28 Nov 2020 09:42:37 -0800
+
 openjdk-11 (11.0.9.1+1-1~deb10u1) buster; urgency=medium
 
   * Rebuild for Buster (Closes: #975728)
diff -Nru openjdk-11-11.0.9.1+1/debian/rules openjdk-11-11.0.9.1+1/debian/rules
--- openjdk-11-11.0.9.1+1/debian/rules  2020-11-05 05:32:42.0 -0800
+++ openjdk-11-11.0.9.1+1/debian/rules  2020-11-28 09:42:37.0 -0800
@@ -158,7 +158,7 @@
 ifneq (,$(filter $(distrel), precise trusty))
   with_docs =
 endif
-# with_check = disabled for this upload
+with_check = disabled for this upload
 
 with_wqy_zenhai = $(if $(filter $(distrel),lenny),,yes)
 


signature.asc
Description: PGP signature

Bug#976042: llvm-11: generates WebAssembly incompatible with binaryen 98

2020-11-28 Thread Jonas Smedegaard

Package: llvm-11
Version: 1:11.0.0-5+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Seems LLVM and binaryen is out of sync, causing some code compilations
to fail with emscripten: https://bugs.debian.org/975069

Seems that some renaming of "emscripten EH functions" was previously
done by binaryen and more recently in LLVM - binaryen 98 is too new to
do it and LLVM is too old to do it:
https://github.com/llvm/llvm-project/commit/3bba91f64eef15956f589fa446c265a714cc7893

Emscripten upstream generally use bleeding edge unreleased LLVM and
binaryen which is obviously not possible with Debian.  Their suggestion
is to alternatively use the last release of emscripten known to work
with LLVM 11, but I strongly suspect that it requires using older
releases of binayen (and possibly other tools as well) - i.e. again
an approach less suitable for Debian.

Seems to me that -  - the least invasive solution is to have
LLVM 11 

Assuming my understanding of the above is correct, the least invasive
solution seems to be to have llvm-11 cherry-pick the LLVM patch to
handle this "emscripten EH functions" renaming:
https://github.com/llvm/llvm-project/commit/3bba91f64eef15956f589fa446c265a714cc7893

What do you think?  Are you willing to carry such patch?

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/CnYAACgkQLHwxRsGg
ASFngA//WQ/LiSXwxumqdZatSrMa4E//i4qViXDyF2q0wiJ1lZRcQDMPiaG3XlDM
0ymbE3OV0af6aOd4VHocSwpvKLDjr+TRjM9KhuvFUsN/eWiA9g+kw2ubsbxmMyqF
iCnEVTKsYeGv5r/rLDGeyvw5XQKaVmJtjsbKPpLfqzZitpPZDVl4GRPUWKbs+7TC
Kj1UhqXgKMkLH+PhVsuO0ZshHkHRkfwB3D/RvYCFe1XvhCAcGSsYDFzHiIiXe5Us
lgnE2oh5MJE1K43rLoHECwuV34X6gblF+CMgFP/7QrvGn9MyJnQFEfI8hN7QYZuS
yKzwZ0lNzdJg0xgtB+5Y81+lvSLLOWp4dmaq60ObiINnFO08515Xk/mnqcQdiAAM
QU6feiAfajqNOh0xANxyUfDn7aJ+5QdGAlkena4lnZukX2jmKFRyF3evw6D7laYW
v8obDlfl2l727GrT6d6X9EWa3Z7+URc0as0IRfc+hhz+PoNk0JXlwa8eCRvKsXWr
wlHxryfPazh62EuMOJSSQlGy099xH4quraPL2uZmsaTosVajWz3j0u1RO3gJw961
HDjGS3sWsefopXJZ30fyKBWAIFf3QYNMFdBBLe0no9lo9dY6LysgDhyV0TeQFILs
+lxJXAGsOx4rQ7300qp5YWFYhZ4w2d9hUm+j3n71sxcYLzeBpNA=
=Hiv8
-END PGP SIGNATURE-

Bug#975069: [Pkg-javascript-devel] Bug#975069: emscripten: Incompatibilities with LLVM 11

2020-11-28 Thread Jonas Smedegaard

Quoting Sébastien Jodogne (2020-11-18 20:49:27)
> >> When building a large C++ project using the current package, the
> >> WebAssembly linking might fail with error "emscripten:ERROR: emscript:
> >> failure to parse metadata output from wasm-emscripten-finalize".
> > 
> > Which exact options passed to wasm-emscripten-finalize?
> 
> After inspection of "/usr/share/emscripten/emscripten.py", the options are:
> 
> ['--detect-features', '--minimize-wasm-changes', '--dyncalls-i64',
> '--global-base=1024']
> 
> You'll find the error log attached to this mail.
> 
> Note how "wasm-emscripten-finalize" produced an invalid JSON file: It
> contains percents that are not properly escaped. From what I see on a
> working emsdk deployment, no function starting with "__invoke" in the
> "declares" section should be present.

Seems the problem is not which options emscripten passes to llvm, but 
that llvm and binaryen are out of sync: Some renaming of "emscripten EH 
EH functions" was previously done by binaryen and more recently in LLVM 
- binaryen 98 is too new to do it and LLVM is too old to do it: 
https://github.com/llvm/llvm-project/commit/3bba91f64eef15956f589fa446c265a714cc7893

Here is a minimal code to reproduce that (final parts of) that same 
error message (tested in a clean chroot of Debian sid as of today):

  apt install emscripten
  emcc --version
  /usr/share/emscripten/tests/runner.py test_exceptions


 - Jonas

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

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

signature.asc
Description: signature

Bug#976041: ITP: fastddsgen -- IDL source code generator for eProsima FastDDS

2020-11-28 Thread Timo Röhling

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org, t...@gaussglocke.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: fastddsgen
  Version : 1.0.4
  Upstream Author : Proyectos y Sistemas de Mantenimiento SL (eProsima)
* URL : https://github.com/eProsima/Fast-DDS-Gen
* License : Apache-2
  Programming Lang: Java
  Description : IDL source code generator for eProsima FastDDS

eProsima Fast DDS-Gen is a Java application that generates source code
for eProsima Fast DDS using the data types defined in an IDL (Interface
Definition Language) file. This generated source code can be used in any
Fast DDS application in order to define the data type of a topic, which
will later be used to publish or subscribe.

Fast DDS is the default backend for the Robot OS version 2, and this
package is part of the ongoing effort to debianize it.

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAl/CmmkACgkQ+C8H+466
LVkUnwwA5eEE/nfI2rKroBHbRpv/EV9izbp6saXN3ts4zVUYt62RjLRe4jmmT3E9
a/W1f+1fqzwH4jTnjwPKQl8+JZQhvuR4nx6aiRVEy5cmdJpC1p8vAFoPIhyr3r3G
7A4rnJsx9smfiqhVAbD8UyxdpH065Eu3pKUfkAmq8/NLBvz4tZKij0Y/O56/pd6G
rXQzxyYmNbkDd5PIlvnt8ApuVzLljSElDlHr/NAQ6MVRPZeTNZByki2IpzBLDblr
yFkajBY9xg5xhfm+Hs8CO69Ynd1bMvu9M6sw6eUbYDmoiQR8/xo0l4JAnUTiM+Gn
WUS+qJjKfU3huZdJtw5OSoiZlWlvfccv5X+0bIHLLzvQEt3WoOQkHFrVnRMnVFHi
C2nW9SFnco4cdufA/1jVWs2NAXXgTM67ImVcdqNVaXlPMYYiKfgfkRkQYhAgSH8S
xyGCQQt7eK+3OGHqvfKCmwEH1p9Utc0UjQus1yW6nl7s+2oxpT45Qh2TH0oorOdl
+d37EajI
=Eahd
-END PGP SIGNATURE-

Bug#975650: blhc: reports false positives for missing flags

2020-11-28 Thread Fabian Wolff

On 11/28/20 12:28 PM, Simon Ruderich wrote:
> blhc uses a few heuristics to detect lines with (possible)
> compiler commands to prevent false negatives. Lines containing
> `gcc` and similar are flagged. In this case the CC= environment
> variable triggers this. Then blhc looks for the actual build
> command and its flags. Here the quote after -D_FORTIFY_SOURCE=2
> is the problem because blhc requires a space after each flag. I
> know this handling is not perfect but parsing arbitrary shell
> commands is difficult.

I see. Thanks for your explanation! I'm aware of the complexity and
difficulty of parsing arbitrary shell commands, so it's not a problem
at all that some false positives (and negatives) exist. I just found
this particular example confusing because blhc seemed to recognize the
compiler command in the environment variable assignment, but not the
flags on the same line, which seemed weird to me.

Thanks again for having a look at this!
Fabian

Bug#976040: ITP: eprosima-idl-parser -- IDL parser library for eProsima FastDDS

2020-11-28 Thread Timo Röhling

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org, t...@gaussglocke.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: eprosima-idl-parser
  Version : 1.0.4
  Upstream Author : Proyectos y Sistemas de Mantenimiento SL (eProsima)
* URL : https://github.com/eProsima/IDL-Parser
* License : Apache-2
  Programming Lang: Java
  Description : IDL parser library for eProsima FastDDS

The eProsima IDL parser library is provides support for the Interface
Definition Language (IDL), and was written specifically for the
eProsima Fast DDS source code generator. Fast DDS is the default backend
for the Robot OS version 2, and this package is part of the ongoing
effort to debianize it.

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAl/ClwIACgkQ+C8H+466
LVlBKgv/e5snfx4TVLURK4kPFsl8dHYat8/ytGBZaBBqNr/Vomy+jcjd03XmGWAd
jEOQNodd7o8pW5dWuD4Nhws8suMy69KxE5YXkPcVK6JRLpJKeCUk8unPX0qf9Uxp
cUeDRpNMqeoGgFQbeM9FmKzB4lFlebWNII4D04Ij12Z9d3bI2ccL/tgU128sZ5j7
BeUC84uvMO46dVqbjCY6Qzu6WutkTN2UiEuzrZLs5zk8moklRv5tbLCEXCwFb2xp
2I3Nbmdz0lfVxUDQu4fZaNdtBUs8hxovZwt4L0e0njSXL7PyeaufSTppLg+tBTks
JSLF+cZTsJ/PsC4Z9VfHW36zG17284RTPTuDs+SdTI7eU3W6sofNFIRl/unKuTJp
ZzlJkFIhYQFFjnaQkiYmdU88H3fNc4P40CFZNA9eRaVJfyQ0X7T27Mq/hnqoH1KH
qaVx5/vn3C6M9gS6O+D0gGdIXyxImE0Bo6i4DvZOaT5DZrQlivZeSebFhVAt6wMx
dQFaRiT1
=+48i
-END PGP SIGNATURE-

Bug#975998: licensecheck: Fails with a Perl problem

2020-11-28 Thread Niko Tyni

On Fri, Nov 27, 2020 at 11:25:25PM +0100, Uwe Kleine-König wrote:
> Package: licensecheck
> Version: 3.0.47-1
> Severity: normal
 
> this might not be licensecheck's fault but maybe is related to the
> recent perl transition. But given I don't know much about Perl, I'm
> reporting against licensecheck.
> 
> For all invokations of licensecheck I encounter:
> 
>   uwe@taurus:~$ licensecheck
>   Base class package "Pod::Parser" is empty.
>   (Perhaps you need to 'use' the module which defines that package 
> first,
>   or make that module available in @INC (@INC contains: /etc/perl 
> /usr/local/lib/x86_64-linux-gnu/perl/5.32.0 /usr/local/share/perl/5.32.0 
> /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 
> /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 
> /usr/share/perl/5.32 /usr/local/lib/site_perl).
>at /usr/share/perl5/Pod/Constants.pm line 7.
>   BEGIN failed--compilation aborted at /usr/share/perl5/Pod/Constants.pm 
> line 7.
>   Compilation failed in require at /usr/bin/licensecheck line 14.
>   BEGIN failed--compilation aborted at /usr/bin/licensecheck line 14.
> 
> This is on a machine that runs a mix of testing and unstable, but I can
> reproduce this problem on a sid chroot.

Hi, thanks for the report. This doesn't seem to occur for me in a
clean sid chroot. Is yours an older one that has been upgraded? Do you
happen to have an old perl-modules-5.24 package lying around in both?
Is libpod-parser-perl installed?

I'm guessing this might be similar to #972322 and we need to do something
about it on the src:perl side.
-- 
Niko Tyni   nt...@debian.org

Bug#972784: Malformated JSON on tc qdisc

2020-11-28 Thread romeo.ginon

Hello Luca,

 

Looks great with a valid json syntax.

 


tc -j qdisc show dev enp1s0f0


[{"kind":"mqprio","handle":"8001:","root":true,"options":{"tc":2,"map":[0,0,0,1,0,1,0,0,0,0,0,0,0,0,0,0],"queues":[[0,3],[4,7]],"mode":"channel","shaper":"dcb"}},{"kind":"pfifo_fast","handle":"0:","parent":"8001:8","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","parent":"8001:7","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","parent":"8001:6","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","parent":"8001:5","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","parent":"8001:4","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","parent":"8001:3","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","parent":"8001:2","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","parent":"8001:1","options":{"bands":3,"priomap
 ":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}}]


tc -j qdisc


[{"kind":"noqueue","handle":"0:","dev":"lo","root":true,"refcnt":2,"options":{}},{"kind":"mqprio","handle":"8001:","dev":"enp1s0f0","root":true,"options":{"tc":2,"map":[0,0,0,1,0,1,0,0,0,0,0,0,0,0,0,0],"queues":[[0,3],[4,7]],"mode":"channel","shaper":"dcb"}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f0","parent":"8001:8","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f0","parent":"8001:7","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f0","parent":"8001:6","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f0","parent":"8001:5","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f0","parent":"8001:4","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f0","parent":"8001:3","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f0","parent":"8001:2","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f0","parent":"8001:1","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp0s31f6","root":true,"refcnt":2,"options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"mq","handle":"0:","dev":"enp1s0f1","root":true,"options":{}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":10","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":f","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":e","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":d","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":c","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":b","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":a","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":9","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":8","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":7","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":6","options":{"bands":3,"priomap
 
":[1,2,2,2,1,2,0,0,1,1,1,1,1,1,1,1],"multiqueue":false}},{"kind":"pfifo_fast","handle":"0:","dev":"enp1s0f1","parent":":5","options":{"bands":3,"priomap

Bug#921740: Pointless scans of the root filesystem at startup

2020-11-28 Thread Steve McIntyre

On Sat, Nov 28, 2020 at 12:49:21AM +0100, Andreas Ronnquist wrote:
>On Fri, 27 Nov 2020 23:28:25 +
>Steve McIntyre  wrote:
>>tack:~/debian/geeqie$ strace -f -o strace geeqie ~/*jpg
>>
>>(geeqie:6782): Gdk-ERROR **: 23:27:04.560: The program 'geeqie'
>>received an X Window System error. This probably reflects a bug in the
>>program. The error was 'GLXBadContext'.
>>  (Details: serial 183 error_code 158 request_code 152 (GLX)
>> minor_code 6) (Note to programmers: normally, X errors are reported
>> asynchronously; that is, you will receive the error a while after
>> causing it. To debug your program, run it with the GDK_SYNCHRONIZE
>> environment variable to change this behavior. You can then get a
>> meaningful backtrace from your debugger if you break on the
>> gdk_x_error() function.)
>>Trace/breakpoint trap
>>
>>No idea what's up there... :-(
>
>Please try starting geeqie with --disable-clutter
>
>- this should make it possible to start, at least.

Ah, yes - that fixed that issue. Now things start up OK. As far as I
can see (by testing with the network cable unplugged) geeqie no longer
seems to be scanning all the stuff from root - yay!

However, I'm still a little confused as to the behaviour geeqie is
trying to do here - it seems to scan *all* files under a given path,
ignoring any filenames given. That's quite annoying when I'm asking it
to just display a few files. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The whole problem with the world is that fools and fanatics are
 always so certain of themselves, and wiser people so full of doubts."
   -- Bertrand Russell

Bug#976007: adb: Adb completely broken after today's update in android-libboringssl (testing branch)

2020-11-28 Thread jim_p

Package: adb
Version: 1:8.1.0+r23-8
Followup-For: Bug #976007
X-Debbugs-Cc: pitsior...@gmail.com

As expected, downgrading android-libboringssl to its previous version
(8.1.0+r23-3) makes adb usable again, and fdroidcl too.

$ adb devices
List of devices attached
ABCDEF1234567890device

I also noticed that there is a pending update for adb and the like to v10.x in
unstable. Too bad the depending libs were updated before adb itself was. That
caused the breakage.



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

Kernel: Linux 5.9.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages adb depends on:
ii  android-libadb   1:8.1.0+r23-8
ii  android-libbase  1:8.1.0+r23-8
ii  libc62.31-4
ii  libgcc-s110.2.0-16
ii  libstdc++6   10.2.0-16

Versions of packages adb recommends:
ii  android-sdk-platform-tools-common  27.0.0+12

adb suggests no packages.

-- no debconf information

Bug#975086: dav4tbsync 1.23-1~deb10u1 flagged for acceptance

2020-11-28 Thread Adam D Barratt

package release.debian.org
tags 975086 = 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: dav4tbsync
Version: 1.23-1~deb10u1

Explanation: new upstream release, compatible with newer Thunderbird versions

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

On Sat, 2020-11-28 at 08:01 -0800, tony mancill wrote:
> On Sat, Nov 28, 2020 at 05:10:39PM +0200, Adrian Bunk wrote:
> > On Wed, Nov 25, 2020 at 08:23:45PM -0800, tony mancill wrote:
> > > -with_check = disabled for this upload
> > > +# with_check = disabled for this upload
> > > ...
> > 
> > FTR, this change increases the build time on zero architectures by
> > half a week of running tests.
> > 
> > E.g. on mipsel-osuosl-01 that is currently building mips64el this
> > adds 3 days 23 hours to the buildtime.[1]
> > 
> > Which is a bit wasteful since failures are ignored and a 3 digit
> > number of tests fail on all release architectures.
[...]
> Ugh, that is unfortunate.  The "with_check" change is there to keep
> the package as close to the version in testing/unstable as
> feasible.  The only sourceful packaging difference is the build-dep
> on g++-8 instead of g++-10.
> 
> Adam expressed concerns about the change as well.  Do I need to
> prepare another upload?

Given that this weekend is the freeze for the point release, that might
be safest, just in case the builds show any issues. It's at least not a
regression from the version currently in buster.

Regards,

Adam

Bug#975563: golang-k8s-sigs-structured-merge-diff: Please update to upstream version 4.0 or later

2020-11-28 Thread Shengjing Zhu

Hi

On Sun, Nov 29, 2020 at 12:06 AM El boulangero  wrote:
>
> This broke the build for containerd, and also for docker.io which embeds 
> containerd:
>
> https://buildd.debian.org/status/fetch.php?pkg=docker.io=s390x=20.10.0%7Erc1%2Bdfsg1-1=1606547204=0
>
> /<>/.gopath/src/github.com/containerd/containerd/vendor/sigs.k8s.io/structured-merge-diff/v3/value
>  (vendor tree)
> /usr/lib/go-1.15/src/sigs.k8s.io/structured-merge-diff/v3/value (from $GOROOT)
> /<>/.gopath/src/sigs.k8s.io/structured-merge-diff/v3/value (from 
> $GOPATH)
>
> (the latest containerd builds were still against k8s-structured-merge-diff 
> v3, so they succeeded, only this docker.io build was late enough to pick up 
> the v4)
>
> By any chance, do you know if simply patching to use v4 instead of v3 in the 
> import path will work? Or is there another way to handle this?
>

The code in k8s-structured-merge-diff which containerd uses, is same
in v3 and v4. So in containerd, I just relax the version,
https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/debian/patches/0004-relax-structured-merge-diff-version.patch

-- 
Shengjing Zhu

Bug#974166: 5.9.0-1-amd64 (5.9.11-1) has fixed the issue

2020-11-28 Thread Salvatore Bonaccorso

Source: linux
Source-Version: 5.9.11-1

On Sat, Nov 28, 2020 at 05:05:38PM +0100, Alejandro Colomar (man-pages) wrote:
> Hi,
> 
> I'm glad to say that just now I upgraded to the unstable kernel:
> 
> $ sudo apt-get install linux-image-amd64
> 
> and now I can boot normally:
> 
> $ uname -a
> Linux debian 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1 (2020-11-27) x86_64
> GNU/Linux

Thanks for confirming, then we can close the bug with that version.

> I'm curious: I'd like to see the changelog and the code
> to see what fixed the issue.
> Could you point me to it,
> or give me some hint so that I can search for it myself?

You can find the Debian changelog in
/usr/share/doc/linux-image-5.9.0-4-amd64/changelog.gz .

Mostly apart what you will see on Debian changes it will list mostly
(a filtered changelog as well from the repsective upstrema changes
from the stable version imports).

Regards,
Salvatore

Bug#975657: [Pkg-rust-maintainers] Bug#975657: debcargo: Debcargo, cargo, and other Rust packaging tools are NOT in testing

2020-11-28 Thread peter green


On 26/11/2020 13:20, peter green wrote:

On 25/11/2020 08:11, Sylvestre Ledru wrote:


Le 25/11/2020 à 01:55, peter green a écrit :

Unfortunately it seems that there have been API changes in semver-parser that 
actually effect debcargo


Do you need help to fix that?


"help" is probablly an understatement. I have no clue where to start. I think 
the import may be failing because
the crate has been split into multiple modules, but "WildcardVersion" seems to 
have disappeared completely.


I decided to take another look at this, this time digging into the upstream git 
history to see if it revealed any
clues. From the upstream git history it looks like 0.10 is basically a 
rewrite/redesign.

I therefore decided to package rust-semver-parser-0.9 as a seperate source 
package. With this in place I was able
to get an autopkgtest pass on debcargo. I have now uploaded the 0.9 package to 
new, if the ftpmasters accept it
I will follow it up with uploads of rust-vte, rust-core-foundation and 
rust-cargo and a source-only upload of
rust-semver-parser-0.9.

Fingers crossed that will be enough to get debcargo back in testing.

Bug#976037: ms-gsl's autopkg tests are broken by design

2020-11-28 Thread Matthias Klose

Source: src:ms-gsl
Version: 3.1.0-3
Severity: serious

$ cat debian/tests/control
Tests: with-gcc8-std14 with-gcc8-std17
Depends: cmake, g++-8, libgtest-dev, pkg-config
Restrictions: allow-stderr, skip-not-installable

Tests: with-gcc9-std14 with-gcc9-std17
Depends: cmake, g++-9, libgtest-dev, pkg-config
Restrictions: allow-stderr, skip-not-installable

Tests: with-gcc10-std17 with-gcc10-std20
Depends: cmake, g++-10, libgtest-dev, pkg-config
Restrictions: allow-stderr, skip-not-installable

Tests: with-clang8-std14 with-clang8-std17
Depends: cmake, clang-8, libc++-8-dev, libc++abi-8-dev, libgtest-dev, pkg-config
Restrictions: allow-stderr, skip-not-installable

Tests: with-clang9-std14 with-clang9-std17
Depends: cmake, clang-9, libc++-9-dev, libc++abi-9-dev, libgtest-dev, pkg-config
Restrictions: allow-stderr, skip-not-installable

Tests: with-clang10-std14 with-clang10-std17
Depends: cmake, clang-10, libc++-10-dev, libc++abi-10-dev, libgtest-dev, 
pkg-config
Restrictions: allow-stderr, skip-not-installable

Tests: with-clang11-std17 with-clang11-std20
Depends: cmake, clang-11, libc++-11-dev, libc++abi-11-dev, libgtest-dev, 
pkg-config
Restrictions: allow-stderr, skip-not-installable

Tests: with-clang12-std17 with-clang12-std20
Depends: cmake, clang-12, libc++-12-dev, libc++abi-12-dev, libgtest-dev, 
pkg-config
Restrictions: allow-stderr, skip-not-installable

Now, there's at least one test (the clang-12 one), which never will succeed. So
what's the value of these tests when you always have failures due to
non-existing versions?  Please just test for the default gcc and clang.

Bug#975866: apt-listbugs: [INTL:fr] French templates translation

2020-11-28 Thread Francesco Poli

On Sat, 28 Nov 2020 14:45:33 +0100 Jean-Pierre Giraud wrote:

[...]
> I send you a patch with the new translation for these strings (if you
> prefer, I can send the entire file fixed)

Thanks a lot!
I've just incorporated all the fixes, no need to send the entire file
again (actually, it was even better to have the patch, so that it was
clear what changed and where!).

> 
> Sorry for the delay.

It's totally fine, no need to worry about a short delay from yesterday
evening!   ;-)

> 
> Best regards

Have a nice week-end!   :-)

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

pgpNwzZRhKhcq.pgp
Description: PGP signature

Bug#976036: rust-gdk-pixbuf-sys: Please depend and build-depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: rust-gdk-pixbuf-sys
Version: 0.9.0-2
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though mate-desktop only requires the main gdk-pixbuf-2.0
library. Please update the Depends and Build-Depends so that it only
pulls in that part, as in the attached patch.

The form suggested in the attached patch is backwards-compatible with
older Debian releases:

libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev

but if this package is unlikely to be backported, you can simplify that
to just the new package:

libgdk-pixbuf-2.0-dev

Thanks,
smcv
diff --git a/debian/control b/debian/control
index cfc882e..005541b 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Build-Depends: debhelper (>= 11),
  librust-gobject-sys-0.9+default-dev ,
  librust-libc-0.2+default-dev ,
  librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) ,
- libgdk-pixbuf2.0-dev 
+ libgdk-pixbuf-2.0-dev  | libgdk-pixbuf2.0-dev 
 Maintainer: Debian Rust Maintainers 

 Uploaders:
  Wolfgang Silbermayr 
@@ -30,7 +30,7 @@ Depends:
  librust-gobject-sys-0.9+default-dev,
  librust-libc-0.2+default-dev,
  librust-pkg-config-0.3+default-dev (>= 0.3.7-~~),
- libgdk-pixbuf2.0-dev
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev
 Provides:
  librust-gdk-pixbuf-sys+default-dev (= ${binary:Version}),
  librust-gdk-pixbuf-sys+dox-dev (= ${binary:Version}),

Bug#974166: 5.9.0-1-amd64 (5.9.11-1) has fixed the issue

2020-11-28 Thread Alejandro Colomar (man-pages)

Hi,

I'm glad to say that just now I upgraded to the unstable kernel:

$ sudo apt-get install linux-image-amd64

and now I can boot normally:

$ uname -a
Linux debian 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1 (2020-11-27) x86_64
GNU/Linux

I'm curious: I'd like to see the changelog and the code
to see what fixed the issue.
Could you point me to it,
or give me some hint so that I can search for it myself?

Thanks,

Alex

Bug#976032: libmediaart: Please depend and build-depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

2020-11-28 Thread Michael Biebl

Hi Simon

Am Samstag, den 28.11.2020, 15:52 + schrieb Simon McVittie:
> Source: libmediaart
> Version: 1.9.4-2
> Severity: normal
> Tags: patch
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: split-gdk-pixbuf
> 
> In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
> development files for two libraries: gdk-pixbuf-2.0 and the
> deprecated
> gdk-pixbuf-xlib-2.0.
> 
> In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
> and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
> upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
> into a separate source package. libgdk-pixbuf2.0-dev continues to
> exist, but is now a transitional package that pulls in the deprecated
> libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.
> 
> It looks as though libmediaart only requires the main gdk-pixbuf-2.0
> library. Please update the Depends and Build-Depends so that it only
> pulls in that part, as in the attached patch.
> 
> The form suggested in the attached patch is backwards-compatible with
> older Debian releases:
> 
>     libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev
> 
> but if this package is unlikely to be backported, you can simplify
> that
> to just the new package:
> 
>     libgdk-pixbuf-2.0-dev
> 

Given the nature of the package, I would prefer that it is moved under
GNOME maintainership (I actually don't know anymore why it is in debian
and not the gnome-team salsa namespace on salsa).
That said, you can just as well make a Team-Upload and apply any
changes you see fit, if you want.

Regards,
Michael





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

Bug#975563: golang-k8s-sigs-structured-merge-diff: Please update to upstream version 4.0 or later

2020-11-28 Thread El boulangero

This broke the build for containerd, and also for docker.io which embeds
containerd:

https://buildd.debian.org/status/fetch.php?pkg=docker.io=s390x=20.10.0%7Erc1%2Bdfsg1-1=1606547204=0

/<>/.gopath/src/
github.com/containerd/containerd/vendor/sigs.k8s.io/structured-merge-diff/v3/value
(vendor tree)
/usr/lib/go-1.15/src/sigs.k8s.io/structured-merge-diff/v3/value (from
$GOROOT)
/<>/.gopath/src/sigs.k8s.io/structured-merge-diff/v3/value
(from $GOPATH)

(the latest containerd builds were still against k8s-structured-merge-diff
v3, so they succeeded, only this docker.io build was late enough to pick up
the v4)

By any chance, do you know if simply patching to use v4 instead of v3 in
the import path will work? Or is there another way to handle this?

Cheers,

  Arnaud

Bug#976035: Doesn't work with Python 3.9

2020-11-28 Thread Andrey Rahmatullin

Package: mitmproxy
Version: 5.1.1-2
Severity: grave
Tags: upstream fixed-upstream 
Control: forwarded -1 https://github.com/mitmproxy/mitmproxy/issues/4021

[...]
  File "/usr/lib/python3/dist-packages/mitmproxy/utils/typecheck.py", line 73,
in check_option_type
elif not isinstance(value, typeinfo):
  File "/usr/lib/python3.9/typing.py", line 697, in __instancecheck__
return self.__subclasscheck__(type(obj))
  File "/usr/lib/python3.9/typing.py", line 700, in __subclasscheck__
raise TypeError("Subscripted generics cannot be used with"
TypeError: Subscripted generics cannot be used with class and instance checks



This is fixed at https://github.com/mitmproxy/mitmproxy/pull/4179 but there is
no release since it was merged.



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

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

Versions of packages mitmproxy depends on:
ii  dpkg  1.20.5
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-2
ii  python3   3.9.0-3
ii  python3-blinker   1.4+dfsg1-0.3
ii  python3-brotli1.0.9-2+b1
ii  python3-certifi   2020.6.20-1
ii  python3-click 7.1.2-1
ii  python3-cryptography  3.2.1-1
ii  python3-flask 1.1.2-2
ii  python3-h11   0.11.0-1
ii  python3-h23.2.0-2
ii  python3-hyperframe5.2.0-4
ii  python3-kaitaistruct  0.8-3
ii  python3-ldap3 2.7-2
ii  python3-openssl   19.1.0-2
ii  python3-passlib   1.7.2-2
ii  python3-pkg-resources 50.3.0-1
ii  python3-protobuf  3.12.3-2+b1
ii  python3-publicsuffix2 2.20191221-2
ii  python3-pyasn10.4.8-1
ii  python3-pyparsing 2.4.7-1
ii  python3-pyperclip 1.8.0-1
ii  python3-ruamel.yaml   0.16.12-2
ii  python3-sortedcontainers  2.1.0-2
ii  python3-tornado   6.1.0-1
ii  python3-urwid 2.1.1-1+b1
ii  python3-wsproto   0.15.0-3

mitmproxy recommends no packages.

mitmproxy suggests no packages.

-- no debconf information

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

2020-11-28 Thread tony mancill

On Sat, Nov 28, 2020 at 05:10:39PM +0200, Adrian Bunk wrote:
> On Wed, Nov 25, 2020 at 08:23:45PM -0800, tony mancill wrote:
> >...
> > --- openjdk-11-11.0.9+11/debian/changelog   2020-10-22 07:49:15.0 
> > -0700
> > +++ openjdk-11-11.0.9.1+1/debian/changelog  2020-11-25 08:55:48.0 
> > -0800
> > @@ -1,8 +1,16 @@
> > -openjdk-11 (11.0.9+11-1~deb10u1) buster-security; urgency=medium
> > +openjdk-11 (11.0.9.1+1-1~deb10u1) buster; urgency=medium
> >  
> > -  * Rebuild for Buster
> > +  * Rebuild for Buster (Closes: #975728)
> >  
> > - -- Moritz Muehlenhoff   Thu, 22 Oct 2020 14:49:15 +
> > + -- tony mancill   Wed, 25 Nov 2020 08:55:48 -0800
> > +
> > +openjdk-11 (11.0.9.1+1-1) unstable; urgency=medium
> > +
> > +  * OpenJDK 11.0.9.1+1 build (release).
> > +  * Configure --with-jvm-features=shenandoahgc for hotspot builds.
> > +LP: #1902029.
> > +
> > + -- Matthias Klose   Thu, 05 Nov 2020 14:32:42 +0100
> >  
> >  openjdk-11 (11.0.9+11-1) unstable; urgency=medium
> >...
> > --- openjdk-11-11.0.9+11/debian/rules   2020-10-21 10:38:16.0 
> > -0700
> > +++ openjdk-11-11.0.9.1+1/debian/rules  2020-11-05 05:32:42.0 
> > -0800
> > @@ -158,7 +158,7 @@
> >  ifneq (,$(filter $(distrel), precise trusty))
> >with_docs =
> >  endif
> > -with_check = disabled for this upload
> > +# with_check = disabled for this upload
> >...
> 
> FTR, this change increases the build time on zero architectures by half 
> a week of running tests.
> 
> E.g. on mipsel-osuosl-01 that is currently building mips64el this adds
> 3 days 23 hours to the buildtime.[1]
> 
> Which is a bit wasteful since failures are ignored and a 3 digit number 
> of tests fail on all release architectures.
> 
> cu
> Adrian
> 
> [1] https://buildd.debian.org/status/logs.php?pkg=openjdk-11=mips64el

Ugh, that is unfortunate.  The "with_check" change is there to keep the
package as close to the version in testing/unstable as feasible.  The
only sourceful packaging difference is the build-dep on g++-8 instead of
g++-10.

Adam expressed concerns about the change as well.  Do I need to prepare
another upload?

Thank you,
tony

Bug#953668: [Pkg-rust-maintainers] Bug#953668: cargo fails to find default X.509 certificates to validate https on powerpc

2020-11-28 Thread Jan Niehusmann

Hi,

On Thu, Mar 12, 2020 at 11:07:08AM +0100, Fabian Grünbichler wrote:
> I am not sure whether we want to work around it in cargo (by defaulting 
> to that location, for example), but this is related to
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927889
> 
> libgit2 picks up an installed ca-certificates if available in the 
> build-env, but does not build-depend on it. if it was available, it sets 
> the default CA certificate location accordingly (at build time), and 
> cargo works. if it was not available, the certs provided by 
> ca-certificates need to be passed in explicitly by any user of libgit2.

As the bug is fixed in libgit2, and cargo links to the most recent
version of libgit2, I think this ticket can be closed, right?

(I'm hesitating to close it myself as didn't verify it really works as
expected, now.)

Jan

Bug#971815: podman: --init is broken: /usr/libexec/podman/catatonit not found

2020-11-28 Thread Reinhard Tartler

Hi Antonio,

sorry for taking so long to get back to you

On Thu, Nov 5, 2020 at 1:15 PM Antonio Terceiro  wrote:

> On Wed, Oct 07, 2020 at 06:39:43PM -0300, Antonio Terceiro wrote:
> > Package: podman
> > Version: 2.0.6+dfsg1-1
> > Severity: normal
> > Tags: patch
> >
> > I was testing some things that I usually run against docker with podman,
> > and discovered that --init does not work:
> >
> > $ docker run --init debian echo Hello world
> > Hello world
> > $ podman run --init debian echo Hello world
> > Error: container-init binary not found on the host: stat
> /usr/libexec/podman/catatonit: no such file or directory
> >
> > I found https://github.com/containers/podman/issues/4159 upstream
> >
> > I did a quick packaging of catatonit, installed it, and with the
> > attached patch, I can make it work. I have just submitted an ITP for
> > catatonit.
> >
> > $ podman run --init debian echo Hello world
> > Hello world
> >
> > Should I go ahead and upload catatonit? Or would you rather point to a
> > different init by default? It seems we have quite some of them in the
> > archive already (tini, dumb-init, ...)?
>
> Hi, ping. It would be nice to have some feedback on this, so we can make
> --init work out of the box.
>
> Should I upload catatonit?
>
> Should I make it provide /usr/libexec/podman/catatonit, or are you
> willing to apply my patch to src:libpod?
>

please go ahead with packaging catatonit. Regarding the symlink, I don't
have a strong preference, your patch seems reasonable to me!

-rt


-- 
regards,
Reinhard

Bug#976034: ukwm: Please depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: ukwm
Version: 1.2.0-1
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though ukwm only requires the main gdk-pixbuf-2.0
library. Please update the -dev Depends so that it only pulls in that
part, as in the attached patch.

The form suggested in the attached patch is backwards-compatible with
older Debian releases:

libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev

but if this package is unlikely to be backported, you can simplify that
to just the new package:

libgdk-pixbuf-2.0-dev

Thanks,
smcv
diff --git a/debian/control b/debian/control
index ff77b86..14aa2f8 100644
--- a/debian/control
+++ b/debian/control
@@ -143,7 +143,7 @@ Depends: ${misc:Depends},
  libxdamage-dev,
  libxcomposite-dev,
  libxi-dev,
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
  libxfixes-dev,
  libxrandr-dev
 Conflicts: libukwm-0-dev

Bug#975926: enigmail should not be shipped in bullseye

2020-11-28 Thread Adrian Bunk

Control: retitle -1 enigmail should not be shipped in bookworm
Control: tags -1 - bullseye
Control: tags -1 bookworm

On Fri, Nov 27, 2020 at 06:41:03PM +0100, Michael Biebl wrote:
>...
> I don't see the problem with shipping the migration wizard for one stable
> release cycle and dropping it afterwards.

I guess we have to agree to disagree on that,
and it is not really harmful to ship in bullseye.

> Michael

cu
Adrian

BTW: The package description would be clearer with the two sections
 that are describing the pre-migration assistant situation removed.

Bug#976033: plank: Please depend and build-depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: plank
Version: 0.11.89-1
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though plank only requires the main gdk-pixbuf-2.0
library. Please update the Depends and Build-Depends so that it only
pulls in that part, as in the attached patch.

The form suggested in the attached patch is backwards-compatible with
older Debian releases:

libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev

but if this package is unlikely to be backported, you can simplify that
to just the new package:

libgdk-pixbuf-2.0-dev

Thanks,
smcv
diff --git a/debian/control b/debian/control
index 2896575..7e8ef1f 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends: debhelper-compat (=12),
libbamf3-dev (>= 0.4),
libcairo2-dev (>= 1.13.0),
libdbusmenu-gtk3-dev (>= 0.6.2),
-   libgdk-pixbuf2.0-dev (>= 2.26.0),
+   libgdk-pixbuf-2.0-dev (>= 2.26.0) | libgdk-pixbuf2.0-dev (>= 
2.26.0),
libgee-0.8-dev,
libglib2.0-dev (>= 2.40.0),
libgnome-menu-3-dev,
@@ -68,7 +68,7 @@ Section: libdevel
 Depends: libplank1 (= ${binary:Version}),
  libbamf3-dev (>= 0.2.92),
  libcairo2-dev (>= 1.10.0),
- libgdk-pixbuf2.0-dev (>= 2.26.0),
+ libgdk-pixbuf-2.0-dev (>= 2.26.0) | libgdk-pixbuf2.0-dev (>= 2.26.0),
  libgee-0.8-dev,
  libglib2.0-dev (>= 2.40.0),
  libgtk-3-dev (>= 3.10.0),

Bug#976032: libmediaart: Please depend and build-depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: libmediaart
Version: 1.9.4-2
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though libmediaart only requires the main gdk-pixbuf-2.0
library. Please update the Depends and Build-Depends so that it only
pulls in that part, as in the attached patch.

The form suggested in the attached patch is backwards-compatible with
older Debian releases:

libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev

but if this package is unlikely to be backported, you can simplify that
to just the new package:

libgdk-pixbuf-2.0-dev

Thanks,
smcv
diff --git a/debian/control b/debian/control
index a902408..6a64c8f 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: autoconf-archive,
intltool,
iso-codes,
libdconf-dev (>= 0.13.4),
-   libgdk-pixbuf2.0-dev (>= 2.36.5),
+   libgdk-pixbuf-2.0-dev (>= 2.36.5) | libgdk-pixbuf2.0-dev (>= 
2.36.5),
libgirepository1.0-dev,
libglib2.0-dev (>= 2.50.0),
libglib2.0-doc,
@@ -100,7 +100,7 @@ Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends: libdconf-dev,
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
  libgtk-3-dev,
  libmate-desktop-2-17 (= ${binary:Version}),
  libstartup-notification0-dev,

Bug#976031: mate-desktop: Please depend and build-depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: mate-desktop
Version: 1.24.1-1
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though mate-desktop only requires the main gdk-pixbuf-2.0
library. Please update the Depends and Build-Depends so that it only
pulls in that part, as in the attached patch.

The form suggested in the attached patch is backwards-compatible with
older Debian releases:

libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev

but if this package is unlikely to be backported, you can simplify that
to just the new package:

libgdk-pixbuf-2.0-dev

Thanks,
smcv
diff --git a/debian/control b/debian/control
index a902408..6a64c8f 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: autoconf-archive,
intltool,
iso-codes,
libdconf-dev (>= 0.13.4),
-   libgdk-pixbuf2.0-dev (>= 2.36.5),
+   libgdk-pixbuf-2.0-dev (>= 2.36.5) | libgdk-pixbuf2.0-dev (>= 
2.36.5),
libgirepository1.0-dev,
libglib2.0-dev (>= 2.50.0),
libglib2.0-doc,
@@ -100,7 +100,7 @@ Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends: libdconf-dev,
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
  libgtk-3-dev,
  libmate-desktop-2-17 (= ${binary:Version}),
  libstartup-notification0-dev,

Bug#976030: gxr: Please depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: gxr
Version: 0.15.1-2
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though gxr only requires the main gdk-pixbuf-2.0
library. Please update the Depends so that it only pulls in that part,
as in the attached patch.

Thanks,
smcv
diff --git a/debian/control b/debian/control
index a27e336..c179627 100644
--- a/debian/control
+++ b/debian/control
@@ -40,7 +40,7 @@ Depends:
  ${misc:Depends},
  libcogl-dev,
  libcogl-path-dev,
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
  libglib2.0-dev,
  libgraphene-1.0-dev,
  libgtk-3-dev,

Bug#976029: gulkan: Please depend and build-depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: gulkan
Version: 0.15.1-2
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though gulkan only requires the main gdk-pixbuf-2.0
library. Please update the Depends and Build-Depends so that it only
pulls in that part, as in the attached patch.

The form suggested in the attached patch is backwards-compatible with
older Debian releases:

libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev

but if this package is unlikely to be backported, you can simplify that
to just the new package:

libgdk-pixbuf-2.0-dev

Thanks,
smcv
diff --git a/debian/control b/debian/control
index 9360b22..96c1b51 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Build-Depends: debhelper (>= 11),
glslang-tools,
gtk-doc-tools,
libcairo2-dev,
-   libgdk-pixbuf2.0-dev,
+   libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
libglew-dev,
libglfw3-dev,
libglib2.0-dev,
@@ -35,7 +35,7 @@ Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends: libcairo2-dev,
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
  libgraphene-1.0-dev,
  libvulkan-dev,
  libgulkan-0.15-0 (= ${binary:Version}),

Bug#976028: libgtkada: Please depend and build-depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: libgtkada
Version: 19-4
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf
Control: found -1 21.0.0.785f3cf4-1

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though libgtkada only requires the main gdk-pixbuf-2.0
library. Please update the Depends and Build-Depends so that it only
pulls in that part, as in the attached patch.

The form suggested in the attached patch is backwards-compatible with
older Debian releases:

libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev

but if this package is unlikely to be backported, you can simplify that
to just the new package:

libgdk-pixbuf-2.0-dev

Thanks,
smcv
diff --git a/debian/control b/debian/control
index 84743b1..5c57229 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Build-Depends:
 # src/fontconfig.adb
  libfontconfig1-dev | libfontconfig-dev,
 # gtkada sources refer to gtk_* gdk_* cairo_* pango_* g_*
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
  libglib2.0-dev,
  libgtk-3-dev,
  libpango1.0-dev,
@@ -33,7 +33,7 @@ Section: libdevel
 Architecture: any
 Depends: ${ada:Depends}, ${misc:Depends},
  libcairo2-dev | libcairo-dev,
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
  libgtk-3-dev,
  libpango1.0-dev,
 Suggests: libgtkada-bin (=${binary:Version}),

Bug#976027: haskell-gi-gdkpixbuf: Please depend and build-depend on libgdk-pixbuf-2.0-dev instead of libgdk-pixbuf2.0-dev

Source: haskell-gi-gdkpixbuf
Version: 2.0.24-1
Severity: normal
Tags: patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

In Debian 10 and older, the libgdk-pixbuf2.0-dev package contains
development files for two libraries: gdk-pixbuf-2.0 and the deprecated
gdk-pixbuf-xlib-2.0.

In testing/unstable, it has been split into libgdk-pixbuf-2.0-dev
and libgdk-pixbuf-xlib-2.0-dev packages, in preparation for a new
upstream release of gdk-pixbuf-2.0 that moves gdk-pixbuf-xlib-2.0
into a separate source package. libgdk-pixbuf2.0-dev continues to
exist, but is now a transitional package that pulls in the deprecated
libgdk-pixbuf-xlib-2.0-dev in addition to libgdk-pixbuf-2.0-dev.

It looks as though haskell-gi-gdkpixbuf only requires the main
gdk-pixbuf-2.0 library. Please update the Depends and Build-Depends
so that it only pulls in that part, as in the attached patch.

The form suggested in the attached patch is backwards-compatible with
older Debian releases:

libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev

but if this package is unlikely to be backported, you can simplify that
to just the new package:

libgdk-pixbuf-2.0-dev

Thanks,
smcv
diff --git a/debian/control b/debian/control
index 5629cb5..1b53e3b 100644
--- a/debian/control
+++ b/debian/control
@@ -27,7 +27,7 @@ Build-Depends: debhelper (>= 10),
  libghc-haskell-gi-base-dev (<< 0.25),
  libghc-haskell-gi-base-prof,
  pkg-config,
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
 Build-Depends-Indep: ghc-doc,
  libghc-gi-gio-doc,
  libghc-gi-glib-doc,
@@ -44,7 +44,7 @@ Architecture: any
 Depends: ${haskell:Depends},
  ${misc:Depends},
  ${shlibs:Depends},
- libgdk-pixbuf2.0-dev,
+ libgdk-pixbuf-2.0-dev | libgdk-pixbuf2.0-dev,
 Recommends: ${haskell:Recommends},
 Suggests: ${haskell:Suggests},
 Conflicts: ${haskell:Conflicts},

Bug#975875: marked as pending in x11vnc

2020-11-28 Thread Salvatore Bonaccorso

Hi Antoni,

On Fri, Nov 27, 2020 at 02:24:16PM +, Antoni Villalonga wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #975875 in x11vnc reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/debian-remote-team/x11vnc/-/commit/b5ba0d67c4dac88741483b815d2865b3eb20f739
> 
> 
> scan: limit access to shared memory segments to current user (CVE-2020-29074)
> 
> Closes: #975875
> 

Thanks!

FWIW, released DSA 4799-1 for buster-security. Not sure how you would
like the branching names so have not proposed it as well as MR. But
can you import those changes as well?

Regards,
Salvatore

Bug#976018: buster-pu: package cups/2.2.10-6+deb10u4

Control: tags -1 + confirmed

On Sat, 2020-11-28 at 12:15 +0100, Didier 'OdyX' Raboud wrote:
> cups (2.2.10-6+deb10u4) buster; urgency=medium
> 
>   * Backport upstream fix:
> - backend,scheduler/ipp.c: Fix 'printer-alert' invalid free
>   (Closes: #961345)
> 

Please go ahead.

Regards,

Adam

Bug#975411: proposed patch

2020-11-28 Thread Matthias Klose

Control: tags -1 + patch

please find a possible fix attached. However when I enable the patch in
debian/patches/series, I get:

$ dpkg-buildpackage -sd -S -d
dpkg-buildpackage: info: source package meson
dpkg-buildpackage: info: source version 0.56.0-1.1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Matthias Klose 
 dpkg-source --before-build .
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 1-disable-openmpi.patch
dpkg-source: info: applying 2-disable-rootdir-test.patch
dpkg-source: info: applying skip-unimplemented-aarch64-test.diff
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff --git a/test cases/common/122 llvm ir and assembly/meson.build b/test
cases/common/122 llvm ir and assembly/meson.build
|--- a/test cases/common/122 llvm ir and assembly/meson.build
|+++ b/test cases/common/122 llvm ir and assembly/meson.build
--
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'skip-unimplemented-aarch64-test.diff' is correctly
applied by quilt, use 'quilt refresh' to update it
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B
.pc/skip-unimplemented-aarch64-test.diff/ --reject-file=- <
meson-0.56.0/debian/patches/skip-unimplemented-aarch64-test.diff subprocess
returned exit status 1
dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit
status 2


Note that applying the first two patches (already in the package) works fine.
diff -Nru meson-0.56.0/debian/changelog meson-0.56.0/debian/changelog
--- meson-0.56.0/debian/changelog   2020-10-30 09:28:21.0 +0100
+++ meson-0.56.0/debian/changelog   2020-11-28 15:30:07.0 +0100
@@ -1,3 +1,10 @@
+meson (0.56.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Skip unimplmented test on arm64.
+
+ -- Matthias Klose   Sat, 28 Nov 2020 15:30:07 +0100
+
 meson (0.56.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru meson-0.56.0/debian/patches/series meson-0.56.0/debian/patches/series
--- meson-0.56.0/debian/patches/series  2020-10-30 09:28:05.0 +0100
+++ meson-0.56.0/debian/patches/series  2020-11-28 15:30:07.0 +0100
@@ -1,2 +1,3 @@
 1-disable-openmpi.patch
 2-disable-rootdir-test.patch
+#skip-unimplemented-aarch64-test.diff
diff -Nru meson-0.56.0/debian/patches/skip-unimplemented-aarch64-test.diff 
meson-0.56.0/debian/patches/skip-unimplemented-aarch64-test.diff
--- meson-0.56.0/debian/patches/skip-unimplemented-aarch64-test.diff
1970-01-01 01:00:00.0 +0100
+++ meson-0.56.0/debian/patches/skip-unimplemented-aarch64-test.diff
2020-11-28 15:30:07.0 +0100
@@ -0,0 +1,12 @@
+diff --git a/test cases/common/122 llvm ir and assembly/meson.build b/test 
cases/common/122 llvm ir and assembly/meson.build
+--- a/test cases/common/122 llvm ir and assembly/meson.build
 b/test cases/common/122 llvm ir and assembly/meson.build
+@@ -1,7 +1,7 @@
+ project('llvm-ir', 'c', 'cpp')
+ 
+ cpu = host_machine.cpu_family()
+-supported_cpus = ['arm', 'aarch64', 'x86', 'x86_64']
++supported_cpus = ['arm', 'x86', 'x86_64']
+ 
+ foreach lang : ['c', 'cpp']
+   cc = meson.get_compiler(lang)

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

2020-11-28 Thread Adrian Bunk

On Wed, Nov 25, 2020 at 08:23:45PM -0800, tony mancill wrote:
>...
> --- openjdk-11-11.0.9+11/debian/changelog 2020-10-22 07:49:15.0 
> -0700
> +++ openjdk-11-11.0.9.1+1/debian/changelog2020-11-25 08:55:48.0 
> -0800
> @@ -1,8 +1,16 @@
> -openjdk-11 (11.0.9+11-1~deb10u1) buster-security; urgency=medium
> +openjdk-11 (11.0.9.1+1-1~deb10u1) buster; urgency=medium
>  
> -  * Rebuild for Buster
> +  * Rebuild for Buster (Closes: #975728)
>  
> - -- Moritz Muehlenhoff   Thu, 22 Oct 2020 14:49:15 +
> + -- tony mancill   Wed, 25 Nov 2020 08:55:48 -0800
> +
> +openjdk-11 (11.0.9.1+1-1) unstable; urgency=medium
> +
> +  * OpenJDK 11.0.9.1+1 build (release).
> +  * Configure --with-jvm-features=shenandoahgc for hotspot builds.
> +LP: #1902029.
> +
> + -- Matthias Klose   Thu, 05 Nov 2020 14:32:42 +0100
>  
>  openjdk-11 (11.0.9+11-1) unstable; urgency=medium
>...
> --- openjdk-11-11.0.9+11/debian/rules 2020-10-21 10:38:16.0 -0700
> +++ openjdk-11-11.0.9.1+1/debian/rules2020-11-05 05:32:42.0 
> -0800
> @@ -158,7 +158,7 @@
>  ifneq (,$(filter $(distrel), precise trusty))
>with_docs =
>  endif
> -with_check = disabled for this upload
> +# with_check = disabled for this upload
>...

FTR, this change increases the build time on zero architectures by half 
a week of running tests.

E.g. on mipsel-osuosl-01 that is currently building mips64el this adds
3 days 23 hours to the buildtime.[1]

Which is a bit wasteful since failures are ignored and a 3 digit number 
of tests fail on all release architectures.

cu
Adrian

[1] https://buildd.debian.org/status/logs.php?pkg=openjdk-11=mips64el

Bug#976019: buster-pu: package vips/8.7.4-1+deb10u1