Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[tony mancill]

On Mon, Sep 21, 2020 at 09:24:36PM +0100, Julian Gilbey wrote:
> On Mon, Sep 21, 2020 at 07:03:08AM -0700, tony mancill wrote:
> > On Mon, Sep 21, 2020 at 10:01:35AM +0100, Julian Gilbey wrote:
> > > On Sun, Sep 20, 2020 at 09:59:22PM -0700, tony mancill wrote:
> > > > Hi Tiago, hi Julian,
> > > > [...]
> > > > Julian, I applied the patch and built the package successfully, but
> > > > jlink still fails with the "expected hash" error.  It's (perhaps)
> > > > interesting that the expected hash does differ between the patched build
> > > > and the unpatched build.
> > > 
> > > That's really bizarre.  I checked running strip-nondeterminism on the
> > > resulting jmods and it seemed to be OK.  But if so, then I've clearly
> > > overlooked something.
> > 
> > I'm wondering if we just need more of it sprinkled about earlier in the
> > build.  I didn't believe it at first and so rebuilt (more than once) to
> > be sure.
> 
> Hi Tony,
> 
> Here are a couple more thoughts on exploring this:
> 
> * Search through the build log to check that strip-nondeterminism is
>   actually being called.  If it's not, perhaps the patch has
>   accidentally not been applied.

The patch is definitely being applied and run during the build.  I see
output like this for each of the jmods:

Executing: [strip-nondeterminism 
/<>/build/support/images/jmods/java.xml.jmod && /bin/mv 
/<>/build/support/images/jmods/java.xml.jmod 
/<>/build/images/jmods/java.xml.jmod]

> * Run the sha256sum command (protected with a '-' in case it fails!)
>   at several points in the build-arch and install targets to see when
>   the hashes change, if at all.

Good idea.  I am doing that now, and also building without parallelism,
since I'd like to see the build logs for a single jmod being built
without those being interspersed with others.  Specifically, I'd like to
see the order in which the jmods are built and the hashes recorded.
Somewhere along the line, we must be invoking jmod hash / --hash-modules
on a jmod before strip-nondeterminism was invoked. 

>From the jmod manpage:

> With the --hash-modules option or the jmod hash command, you can, in each 
> module's descriptor, record hashes
> of the content of the modules that are allowed to depend upon it, thus 
> "tying" together these modules.   This
> enables a package to be exported to one or more specifically-named modules 
> and to no others through qualified
> exports.  The runtime verifies if the recorded hash of a module matches the 
> one resolved at run time; if not,
> the runtime returns an error.

One other thing I wanted to mention is what I'm using for a test case:

  jlink --add-modules java.desktop --output test

This fails, complaining about the hash of java.xml recorded in
java.base.  But other invocations of jlink are successful with the
patched build.  For example, the following is fine:

  jlink --add-modules java.base --output test

As does java.compiler and 32 others.  So 34 are okay and 38 of them are
failing.  The "good" vs. "fail" modules are attached in case it sparks
inspiration for someone.  I will take a look at the output of the
non-parallelized build in the (GMT-7) morning.

So there are approximately 50/50 odds that your test case is working
(hence the confusion), because the strip-determinism patch is only be
causing problems for a subset of modules.

Thank you for the ideas.  I will keep working on it.

Cheers,
tony
java.base
java.compiler
java.desktop
java.management.rmi
java.naming
java.prefs
java.se
java.security.jgss
java.sql
java.sql.rowset
java.xml.crypto
jdk.accessibility
jdk.aot
jdk.crypto.cryptoki
jdk.editpad
jdk.hotspot.agent
jdk.incubator.jpackage
jdk.internal.vm.compiler
jdk.internal.vm.compiler.management
jdk.javadoc
jdk.jconsole
jdk.jdeps
jdk.jshell
jdk.jstatd
jdk.management
jdk.management.agent
jdk.naming.dns
jdk.naming.rmi
jdk.rmic
jdk.scripting.nashorn.shell
jdk.security.auth
jdk.security.jgss
jdk.unsupported.desktop
jdk.xml.dom
java.datatransfer
java.instrument
java.logging
java.management
java.net.http
java.rmi
java.scripting
java.security.sasl
java.smartcardio
java.transaction.xa
java.xml
jdk.attach
jdk.charsets
jdk.compiler
jdk.crypto.ec
jdk.dynalink
jdk.httpserver
jdk.incubator.foreign
jdk.internal.ed
jdk.internal.jvmstat
jdk.internal.le
jdk.internal.opt
jdk.internal.vm.ci
jdk.jartool
jdk.jcmd
jdk.jdi
jdk.jdwp.agent
jdk.jfr
jdk.jlink
jdk.jsobject
jdk.localedata
jdk.management.jfr
jdk.net
jdk.nio.mapmode
jdk.scripting.nashorn
jdk.sctp
jdk.unsupported
jdk.zipfs

Bug#970604: Missing golang.org/x files

[Shengjing Zhu]

Control: tags -1 + fixed-upstream

On Mon, Sep 21, 2020 at 5:53 PM Shengjing Zhu  wrote:
>
> On Mon, Sep 21, 2020 at 5:28 PM Matthias Klose  wrote:
> >
> > Control: severity -1 wishlist
> >
> > On 9/19/20 7:29 PM, Shengjing Zhu wrote:
> > > Source: gcc-10
> > > Severity: important
> > >
> > > These files are missing in libgo-10-dev package:
> > > https://github.com/golang/gofrontend/tree/master/libgo/go/golang.org/x
> > >
> > > This causes containerd FTBFS on ppc64,
> > > https://buildd.debian.org/status/fetch.php?pkg=containerd=ppc64=1.4.1%7Eds1-1=1600269780=0
> > >
> > > go build golang.org/x/net/http2/hpack: no Go files in 
> > > /usr/src/golang.org/x/net/http2/hpack
> > > go build golang.org/x/net/http/httpguts: no Go files in 
> > > /usr/src/golang.org/x/net/http/httpguts
> > > go build golang.org/x/net/idna: no Go files in /usr/src/golang.org/x/net
> > >
> > > These files are in upstream libgo repo, and
> > > https://github.com/golang/gofrontend/blob/master/libgo/libgo-packages.txt
> >
> > GCC 10 is based on go 1.14.x. 1.15 (and likely 1.16) will be part of GCC 11.
>
> This is not about go1.14 or go1.15. It's actually an upstream bug
> which I have forwarded later.
>  https://github.com/golang/go/issues/41499
> Let's see if upstream can fix this and then backport to gcc10.

Upstream is really fast to fix this and has backported it to gcc10.
So the next update of gcc10 can close this bug.

https://github.com/gcc-mirror/gcc/commit/b59b9cb483462624b9301e52272760b506458a17

-- 
Shengjing Zhu

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[Shengjing Zhu]

On Tue, Sep 22, 2020 at 10:30 AM El boulangero  wrote:
>
> Then the issue must lie in this commit: 
> https://salsa.debian.org/docker-team/docker/-/commit/ad52cffa31359262a8e9d44daddf896c3e063dd2
>
> The docker.io package didn't build anymore, due to runc `1.0.0~rc92` which 
> landed in debian unstable. Shengjing Zhu came up with the patch to fix that, 
> but it was not a straightforward patch. The issue could be in this patch. Or 
> maybe there's more work required to make docker.io 19.03.x work with latest 
> runc (ie. more patching is needed, not less, sorry :/).
>
> Let me say it another way: when you install docker-ce from Docker's repo, you 
> also get the containerd.io package, that ships the runc binary. All of these 
> components are basically provided altogether by docker, and they are at 
> versions that were tested together. While in Debian, these separate 
> components (containerd, runc) are packaged independently, and these are not 
> the same versions as the ones shipped by Docker. So sometimes we hit this 
> kind of issues with the Debian package.
>
> And to be more correct: in Debian we actually bundle containerd within the 
> docker.io package, because nobody has the bandwidth to try to make docker 
> 19.03.x build-against / work-with containerd 1.4.x. So we build the version 
> of containerd that is vendored in the docker source tree, and ship it in the 
> docker.io package. But runc is NOT bundled in, it is provided independently 
> by the runc package, ie. version `1.0.0~rc92`.
>
> I hope that this clarifies a bit what is the issue here.
>

This is indeed caused by runc 1.0.0~rc92, the following patch can fix
the problem.
https://github.com/moby/moby/pull/41288
This patch is missed in 19.03.13, probably will be in 19.03.14
https://github.com/moby/moby/pull/41293

-- 
Shengjing Zhu

Bug#970619: libnet-telnet-perl: Connections occasionally time out and cause errors

[Asher Gordon]

Asher Gordon  writes:

> I sent this report upstream, but I'm not confident it will be
> applied because upstream doesn't seem t' have been active fer a
> while.

I just got a reply from upstream, and the author says he doesn't think
it's a bug. So maybe wait on applying the patch until we've figured out
whether it's a bug or not. The issue on the request tracker is here:
https://rt.cpan.org/Public/Bug/Display.html?id=133371 You can reply to
it by sending email to  with the string
"[rt.cpan.org #133371]" in the Subject header.

-- 
The marvels of today's modern technology include the development of a
soda can, when discarded will last forever ... and a $7,000 car which
when properly cared for will rust out in two or three years.
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#970703: proxytunnel FTCBFS: forces the build architecture compiler

[Helmut Grohne]

Source: proxytunnel
Version: 1.10.20200907-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

proxytunnel fails to cross build from source, because debian/rules
forces the build architecture compiler. It even has a comment explaining
that exporting CC makes changing the compiler simple. Unfortunately,
that choice overrides the default choice of dh_auto_build and makes
things fail. Please leave CC unset by default and only set it, when you
know it needs being set. I'm attaching a patch that makes proxytunnel
cross buildable for your convenience.

Helmut
diff --minimal -Nru proxytunnel-1.10.20200907/debian/changelog 
proxytunnel-1.10.20200907/debian/changelog
--- proxytunnel-1.10.20200907/debian/changelog  2020-09-19 20:39:44.0 
+0200
+++ proxytunnel-1.10.20200907/debian/changelog  2020-09-22 06:33:08.0 
+0200
@@ -1,3 +1,10 @@
+proxytunnel (1.10.20200907-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Stop forcing the build architecture compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 22 Sep 2020 06:33:08 +0200
+
 proxytunnel (1.10.20200907-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru proxytunnel-1.10.20200907/debian/rules 
proxytunnel-1.10.20200907/debian/rules
--- proxytunnel-1.10.20200907/debian/rules  2020-09-19 20:39:44.0 
+0200
+++ proxytunnel-1.10.20200907/debian/rules  2020-09-22 06:33:05.0 
+0200
@@ -3,11 +3,6 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-# This serves to change compilers easily
-#  It should be set to 'cc' by default. Alternatives can be 'gcc-9', 'gcc-10'
-#  or others, depending on the build environment in use.
-export CC=cc
-
 # Make sure the code is compiled for use with OpenSSL 1.1.0 and above
 export OPTFLAGS=-DOPENSSL11
 

Bug#970678: Network preseeding using http is broken

[Ben Hutchings]

On Mon, 2020-09-21 at 20:42 +0100, Ben Hutchings wrote:
> On Mon, 2020-09-21 at 17:43 +0200, Martin Samuelsson wrote:
> > Philip Hands @ 2020-09-21 (Monday), 15:30 (+0200)
> > > Martin Samuelsson  writes:
> > > 
> > > Just to be clear on this point, are you saying [...]
> > 
> > I'm saying there is no /dev/fd/ at all on current daily debian-installer 
> > images and hasn't been since at least 20200818 (which was the oldest one I 
> > could try with current kernel modules).
> [...]
> 
> Then we should investigate and fix that instead of removing code that
> uses it.

It's a udev regression, bug #967546.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.



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

Bug#967546: udev: missing /dev/stdin etc.

[Ben Hutchings]

Control: reopen 967546
Control: block 970678 with 967546

This udev change also affected the installer, which has neither systemd
nor sysvinit; see bug #970678.  It might also affect some other
initramfs environments (but initramfs-tools itself doesn't use these
symlinks, and dracut creates them).

systemd still includes the dev_setup() function which creates these
symlinks, so I don't see why it can't be called by udevd.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.



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

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[El boulangero]

Then the issue must lie in this commit:
https://salsa.debian.org/docker-team/docker/-/commit/ad52cffa31359262a8e9d44daddf896c3e063dd2

The docker.io package didn't build anymore, due to runc `1.0.0~rc92` which
landed in debian unstable. Shengjing Zhu came up with the patch to fix
that, but it was not a straightforward patch. The issue could be in this
patch. Or maybe there's more work required to make docker.io 19.03.x work
with latest runc (ie. more patching is needed, not less, sorry :/).

Let me say it another way: when you install docker-ce from Docker's repo,
you also get the containerd.io package, that ships the runc binary. All of
these components are basically provided altogether by docker, and they are
at versions that were tested together. While in Debian, these separate
components (containerd, runc) are packaged independently, and these are not
the same versions as the ones shipped by Docker. So sometimes we hit this
kind of issues with the Debian package.

And to be more correct: in Debian we actually bundle containerd within the
docker.io package, because nobody has the bandwidth to try to make docker
19.03.x build-against / work-with containerd 1.4.x. So we build the version
of containerd that is vendored in the docker source tree, and ship it in
the docker.io package. But runc is NOT bundled in, it is provided
independently by the runc package, ie. version `1.0.0~rc92`.

I hope that this clarifies a bit what is the issue here.

I CC Shengjing in case he knows more about this issue. I will also try to
have a look on my side as well.

In the meantime I guess you can downgrade to docker.io version
19.03.12+dfsg1-3 and maybe use `apt-mark hold` to prevent any further
upgrade.

Cheers,

  Arnaud


On Tue, Sep 22, 2020 at 6:35 AM Tianon Gravi  wrote:

> On Mon, 21 Sep 2020 at 13:48,  wrote:
> > On Sun, Sep 20, 2020 at 09:58:45AM +0700, El boulangero wrote:
> > > Do you know what's special with the `tianon/true` image? On what
> OS/release
> > > is it based?
> >
> > It's an image that contains only a single binary that returns 0. That
> > binary uses no libraries, not even libc.
> >
> > It's intended as an extremely light-weight image for purposes that don't
> > need a whole OS. See, for example,
> >
> https://stackoverflow.com/questions/37120260/configure-docker-compose-override-to-ignore-hide-some-containers
> >
> > It seems that something changed between 19.03.12+dfsg1-3 and
> > 19.03.12+dfsg1-4 that is somehow or other assuming the container
> > contains more infrastructure. If you determine that the bug is upstream,
> > feel free to forward it to them (and, ideally, revert whatever patch was
> > added to 19.03.12+dfsg1-4 that caused the problem in the mean time to
> > avoid breaking other software on the system).
>
> I don't think this is an upstream bug -- I'm using their "docker-ce"
> package (version "5:19.03.12~3-0~debian-buster") on a host I've got,
> and here's the result of some tests there:
>
> $ docker run --rm tianon/true && echo ok
> ok
>
> $ docker run --rm --user 0:0 tianon/true && echo ok
> ok
>
> $ docker run --rm --user 1000:1000 tianon/true && echo ok
> ok
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
>

Bug#970702: bpython: "help" display doesnt clear existing terminal data

[Calum McConnell]

Package: bpython
Version: 0.19-1
Severity: normal
X-Debbugs-Cc: calumlikesapple...@gmail.com

I ran some commands in my shell (bash, piped through a plain tty).
I then called bpython, and hit F1, hoping for a help display.  It
just printed over the existing shell output, rather than paging it 
up or deleting it.  Instead, it printed the characters over top of
the existing output: lines would start with the 'help' data, then
switch to the output of 'ls'.  If I wasnt using a colorized
terminal, it would have been impossible to spot: as it was, it
still was completly unreadable

Given this is the help menu, I think this is a significant
issue.

Thanks!
-Calum

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bpython depends on:
ii  less   551-2
ii  python33.8.2-3
ii  python3-curtsies   0.3.4-1
ii  python3-greenlet   0.4.15-4.2
ii  python3-pkg-resources  46.1.3-1
ii  python3-pygments   2.3.1+dfsg-4
ii  python3-requests   2.23.0+dfsg-2
ii  python3-six1.15.0-1

Versions of packages bpython recommends:
ii  python3-watchdog  0.9.0-3

Versions of packages bpython suggests:
ii  python3-jedi  0.17.0-1

-- no debconf information

Bug#957439: libforms: ftbfs with GCC-10

[Paul Wise]

On Tue, 2020-08-25 at 17:30 -0400, Peter S Galbraith wrote:

> I am on vacation so *should* have time to look into this soonish.

Did you get a chance to look at the libforms FTBFS with GCC-10?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#970701: RFS: pekka-kana-2/1.2.7-1 -- 2D Oldschool platform game where you control a rooster

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pekka-kana-2":

 * Package name: pekka-kana-2
   Version : 1.2.7-1
   Upstream Author : Janne Kivilahti (Piste Gamez) 
 * URL : https://pistegamez.net/game_pk2.html
 * License : BSD-2-Clause
 * Vcs : https://salsa.debian.org/games-team/pekka-kana-2
   Section : games

It builds those binary packages:

  pekka-kana-2-data - 2D Oldschool platform game where you control a rooster 
(data file)
  pekka-kana-2 - 2D Oldschool platform game where you control a rooster

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

  https://mentors.debian.net/package/pekka-kana-2/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pekka-kana-2/pekka-kana-2_1.2.7-1.dsc

Changes since the last upload:

 pekka-kana-2 (1.2.7-1) unstable; urgency=medium
 .
   * New upstream release. FTCBFS bug fix. (Closes: #933080)
 + Integrated support fixed for pkg-config.
   * debian/control:
 + Bump debhelper compat to version 13.
   * Added debian/docs.

Regards,
--
  Carlos Donizete Froes [a.k.a coringao]

Bug#969048: smartmontools: Update systemd unit file (StandardOutput=syslog)

[Dmitry Smirnov]

On Tuesday, 22 September 2020 1:40:05 AM AEST Christian Franke wrote:
> Fixed upstream in r5077: https://www.smartmontools.org/changeset/5077
> 
> BTW: https://www.smartmontools.org/changeset/5078

Thank you.

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

---

In questions of science, the authority of a thousand is not worth the
humble reasoning of a single individual.
-- Galileo Galilei


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

Bug#970508: dialog: --aspect and --tab-len options don't work

[Thomas Dickey]

On Thu, Sep 17, 2020 at 03:44:38PM +0100, Rainer Weikusat wrote:
> Package: dialog
> Version: 1.3-20190211-ca-003-1
> Severity: normal
> Tags: patch upstream
> 
> The --aspect and --tab-len options are processed in the 
> process_common_options 
> subroutine called from main. The code changes the corresponding members of 
> the 
> dialog_state structure. After this has happened, the code in main calls then
> init_dialog routine which unconditionally sets both the aspect ratio and the
> tab len to its default value, thereby overwriting any changes which happened
> as part of options processing.
> 
> The patch fixes this by changing the init_dialog code such that it only sets
> these members to their default values if they don't have a value already (ie,
> if their value is 0). It also removes a redundant "set aspect ratio to default
> if still 0" statement from process_common_options.

hmm - the change to util.c seems okay, but removing the check in
dialog.c can change things unexpectedly (since process_common_options
can be called after init_dialog).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#970637: /var/lib/dpkg/info/nvme-cli.postinst: 11: uuidgen: not found

[Steven Shiau]

I am having the exactly same issue when I debootstrap a Sid environment:

Setting up nvme-cli (1.12-4) ...
/var/lib/dpkg/info/nvme-cli.postinst: 11: uuidgen: not found
dpkg: error processing package nvme-cli (--configure):
 installed nvme-cli package post-installation script subprocess returned
error exit status 127

Steven

-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[Tianon Gravi]

On Mon, 21 Sep 2020 at 13:48,  wrote:
> On Sun, Sep 20, 2020 at 09:58:45AM +0700, El boulangero wrote:
> > Do you know what's special with the `tianon/true` image? On what OS/release
> > is it based?
>
> It's an image that contains only a single binary that returns 0. That
> binary uses no libraries, not even libc.
>
> It's intended as an extremely light-weight image for purposes that don't
> need a whole OS. See, for example,
> https://stackoverflow.com/questions/37120260/configure-docker-compose-override-to-ignore-hide-some-containers
>
> It seems that something changed between 19.03.12+dfsg1-3 and
> 19.03.12+dfsg1-4 that is somehow or other assuming the container
> contains more infrastructure. If you determine that the bug is upstream,
> feel free to forward it to them (and, ideally, revert whatever patch was
> added to 19.03.12+dfsg1-4 that caused the problem in the mean time to
> avoid breaking other software on the system).

I don't think this is an upstream bug -- I'm using their "docker-ce"
package (version "5:19.03.12~3-0~debian-buster") on a host I've got,
and here's the result of some tests there:

$ docker run --rm tianon/true && echo ok
ok

$ docker run --rm --user 0:0 tianon/true && echo ok
ok

$ docker run --rm --user 1000:1000 tianon/true && echo ok
ok

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#964621: fakeroot: statx function not wrapped, causing FTBFS

[Clint Adams]

On Mon, Sep 21, 2020 at 12:48:25PM +0200, jhcha54008 wrote:
> should this bug be merged with #940056 and #968868 ?

If statx is the only reason for the failures.

Bug#876398: mysqltest can't read config proberly

[Otto Kekäläinen]

This is most likely a duplicate of #879099 and will be fixed with the
upload of MariaDB 10.5 into Debian.

Bug#963119: petitboot: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: petitboot
> Version: 13.05.29.14.00-g4dc604b-1
> Tags: patch

There hasn't seem to be any update on this bug in 94 days, in which
time the Reproducible Builds effort has come on a long way.

Would you consider applying this patch and uploading?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#963533: python-stem: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: python-stem
> Version: 1.2.2-1.1
> Tags: patch

There hasn't seem to be any update on this bug in 90 days, in which
time the Reproducible Builds effort has come on a long way.

Would you consider applying this patch and uploading?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#931301: mtd-utils: ubiformat command does not work for NANDs with bigger size that 2GB

[Bastian Germann]

On Mon, 1 Jul 2019 07:29:42 +
=?iso-8859-1?Q?Jose_Ignacio_Tornos_Mart=EDnez?=  wrote:
> After stretch migration from jessie (mips architecture), ubiformat command is 
> not working
> any more.
> 
> ubiformat command output error:
> #ubiformat /dev/mtd10
> ubiformat: mtd10 (mlc-nand), size 4294967296 bytes (4.0 GiB), 2048
> eraseblocks of 2097152 bytes (2.0 MiB), min. I/O size 8192 bytes
> libscan: scanning eraseblock 1024 -- 50 % complete  libmtd: error!:
> cannot seek mtd10 to offset 8612548850948015640
> error 22 (Invalid argument)
>   ubiformat: error!: failed to scan mtd10 (/dev/mtd10)
> 
> The problem is that lseek function in mtd library (used by ubiformat
> command) uses 32 bits signed offset except if the flag
> '_FILE_OFFSET_BITS=64' is used. 
> As flag is not included, this is the reason why bigger memories
> than 2GB are not working.
> 
> For mtd-utils 1.5.1 (jessie) commented flag was added in defuald Makefile
> structure (common.mk).
> So, new mtd.utils needs to do the same or be generated like this example:
> ./configure --host=mips-linux-gnu- CC=/usr/bin/mips-linux-gnu-gcc
> --prefix=`pwd`/__install CFLAGS='-D_FILE_OFFSET_BITS=64'

Is this still true for buster, bullseye, and sid versions?

Bug#970700: O: bygfoot -- football (a.k.a soccer) management game

[Elías Alejandro]

Package: wnpp
Severity: normal

I intend to orphan the bygfoot package.

The package description is:
 Bygfoot allows you to manage a team by training the players, buying and
 selling them, contracting loans, maintaining the stadium, etc. You can be
 promoted or relegated, even become a champion if you're a skillful manager.
 You can customise Bygfoot by writing your own country definition files or
 by creating your own team definition files.
 
There aren't upstream releases since 2008.

Best regards,
Elías Alejandro

Bug#970386: dovecot-imapd: assertion failure in message_part_finish when searching large folder

[Noah Meyerhans]

Control: tags -1 + confirmed

On Mon, Sep 21, 2020 at 03:43:31PM +0200, Dimitry Andric wrote:
> I managed to track down at least three mails that seem to cause this
> panic, which appears to be caused by bad MIME headers. (Spammers are
> rather fond of these. :)
> 
> Note, I cannot attach these mails to this message, as otherwise the
> Debian bug system refuses them, since they appear to contain malware,
> which was probably the spammer's intent. So I uploaded them here:
> 
> https://www.andric.com/debian/bug970386-1.eml.xz
> https://www.andric.com/debian/bug970386-2.eml.xz
> https://www.andric.com/debian/bug970386-3.eml.xz

Thanks for these.  I have used them to successfully reproduce a crash
when performing a server-side search using 1:2.2.27-3+deb9u6

noah

Bug#970699: linux: Enable amd_energy driver

[David Schiller]

Source: linux
Severity: wishlist
X-Debbugs-Cc: david.schil...@gmx.at

Hi!

Could you please enable CONFIG_SENSORS_AMD_ENERGY as a module. This
provides RAPL energy monitoring on AMD Zen processors and has been
available since kernel 5.8.

Thanks in advance!

Dave


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

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

Bug#920365: [debian-mysql] Bug#920365: Bug#920365: mariadb_config: improve cross compilation support

[Otto Kekäläinen]

Hello Helmut!

Would you be kind and check out mariadb-10.5 currently in Debian
experimental, and report what the status is and what changes would
still be needed?

Thanks!

Bug#861553: [debian-mysql] Bug#861553: Bug#861553: Please enable numa support

[Otto Kekäläinen]

Hello!

libnuma has been included since
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2039c2755d0c642718dcc8be852174205577542b

Please check if mariadb-10.5 in Debian experimental has now usable
numa stuff and report back here so get on top of what the status
currently is.

Thanks!

Bug#970698: Please remove amd64 from NO_PMIX_ARCH

[Mario Lang]

Package: openmpi
Version: 4.0.5-4
Severity: important

Right now, debian/rules has

NO_PMIX_ARCH:= armel mipsel amd64

This looks like an oversight.  I get an error about undefined
symbol when launching an MPI job via SLURM.  Removing amd64 from
NO_PMIX_ARCH fixes this.

-- 
AR Mario Lang   Phone: +43 316 873 6897
Graz University of Technology  Mobile: +43 664 60 873 6897
IT-Services for research and teaching   Email: ml...@tugraz.at
Steyrergasse 30/1, 8010 Graz, Austria   Please https://useplaintext.email/

Bug#968222: [debian-mysql] Bug#968222: Bug#968222: mariadb-server-core-10.3: daemon won't restart after update to latest unstable

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello Russel!

Can you reproduce this in a clean installation? Can you provide exact
steps how to reproduce this?

What does `find /etc/mysql -ls` yield?
What it the contents of debian-sys-maint ? Is it for example empty?

What does `mysql -e "SELECT Host,User,plugin,authentication_string
FROM user;" mysql` yield?

I suspect that since debian-sys-maint is broken (and it should not
even be needed, since root has unix_socket auth access anyway) the
mysqladmin command fails to run and thus restarting server fails as
mysqladmin did not gracefully shutdown existing mysqld processes.

Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"

[Otto Kekäläinen]

Hello!

Have you tested if this still happens on recent MariaDB versions?

Bug#964436: automake: install-info: warning: no info dir entry in `/usr/share/info/automake-history.info.gz'

[Thorsten Glaser]

Package: automake
Version: 1:1.16.2-4
Followup-For: Bug #964436
X-Debbugs-Cc: t...@mirbsd.de

This bug is still pertinent.

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages automake depends on:
ii  autoconf   2.69-11.1
ii  autotools-dev  20180224.1

automake recommends no packages.

Versions of packages automake suggests:
pn  autoconf-doc   
pn  gnu-standards  

-- no debconf information

Bug#970678: Network preseeding using http is broken

[Martin Samuelsson]

Philip Hands @ 2020-09-21 (Monday), 22:38 (+0200)


BTW The example I pasted was just busybox running on my laptop running
full Debian, so was not supposed to be demonstrating it working under
d-i.


I could likely have been more precise from the beginning about the exact 
cause. Sorry for making you required to ask for clarification.



This mixes the stdout of wget with the %OK% %EOF% stuff, and then puts
it all into the sed, which seems flawed.


And that is why you're a Debian developer and I'm merely a user. I agree.


I'd have thought something like this would do the trick (not tested yet):

local RETVAL=$(
{
  {
wget "$@" 2>&1 >/dev/null && echo 0 >&3
  } | {
grep -q "$file_not_found_pattern" && echo 4 >&3
  } || echo 1 >&3
} 3>&1 | head -1
)


Looks good to me. As in, this code I can actually follow and understand.  
Which was a bit of a stretch for me to claim about for the sed construct.


I don't really understand why the tail would be needed, but am not objecting 
to it.


Replacing the RETVAL assignment expression as above works for me. Both from 
debian-installer and when running this simple test script in a shell:


 #!/bin/sh
 fetch-url http://pxeserver./preseed/base.txt base.txt >/dev/null
 [ $? = 0 ] || exit
 echo "Existing file downloaded"

 fetch-url http://pxeserver./non-existant.txt non-existant.txt >/dev/null
 [ $? = 4 ] || exit
 echo "Non-existing file returned 404"

 fetch-url http://invalid-host./whatever.txt invalid-host.txt >/dev/null
 [ $? = 1 ] || exit
 echo "Unresolvable host return general error"


One could of course use stderr for that (>&2 ... 2>&1) for getting the
echo-ed return codes out, rather than fd #3, but I think this is clearer
(since one really isn't trying to produce stderr output) and AFAIK it
should work fine even if /dev/fd/ is missing.


I agree. Nicely done!


I suspect there may be a way of getting this to work without the need
for a local variable and the echoing for the result codes, so I will
ponder on that...


Maybe it is, and if so it might include early return statements and thus 
save spawning grep on successful fetches. I reckon you could be happy and 
proud with the code you've posted already though.



BTW I just saw Ben's comment that we should just fix the missing /dev/fd
which strikes me as entirely sensible.


It's entirely sensible to also attempt fixing the root cause, but my opinion 
is that it wouldn't hurt to treat missing fd-nodes and an overcomplex 
wget404() as two separate issues. Please feel free to fork the bug report.


One could also envision adding a test case for detecting missing fd:s within 
some test suite for d-i. Are there any tests run on nightly builds, which 
could help catching regressions like these?

--
/Martin

Bug#970692: dovecot-core: fts_solr plugin failure

[Raphaël Walther]

Package: dovecot-core
Version: 2.3.4.1-5+deb10u4
Severity: important
Tags: upstream

Dear Maintainer,


The search via the solr_plugin fails frequently on rather big accounts with 
that error:
Error: fts_solr: received invalid uid '0'

The search via imap timeout after 10 seconds.

"Based on the XML response above, I investigated this problem thoroughly 
and determined that this is a pretty severe bug in the Solr XML response 
parsing code. This occurs only when the response is rather large and the 
boundary between two read chunks falls in the middle of a numeric value 
(that happens to end in '0')."
https://dovecot.org/pipermail/dovecot/2019-October/117290.html

This is fixed in 2.3.11.3+dfsg1-2

There is this patch that was released in 2.3.10.

https://github.com/dovecot/core/commit/74c98d2a18cc9ec0edae7f887605a0959d05c8c5#diff-05c64532f105f533f1b96575f101cb81


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

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

Versions of packages dovecot-core depends on:
ii  adduser  3.118
ii  libapparmor1 2.13.2-10
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libexttextcat-2.0-0  3.4.5-1
ii  libicu63 63.1-6+deb10u1
ii  liblua5.3-0  5.3.3-1.1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libpam-runtime   1.3.1-5
ii  libpam0g 1.3.1-5
ii  libsodium23  1.0.17-1
ii  libssl1.11.1.1d-0+deb10u3
ii  libstemmer0d 0+svn585-1+b2
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400
ii  openssl  1.1.1d-0+deb10u3
ii  ssl-cert 1.0.39
ii  ucf  3.0038+nmu1
ii  zlib1g   1:1.2.11.dfsg-1

Bug#970697: tootle FTCBFS: does not pass a crossfile to meson

[Helmut Grohne]

Source: tootle
Version: 1.0-alpha1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

tootle fails to cross build from source, because it does not pass a
crossfile to meson. The easiest way of doing so - using
dh_auto_configure - makes tootle cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru tootle-1.0-alpha1/debian/changelog 
tootle-1.0-alpha1/debian/changelog
--- tootle-1.0-alpha1/debian/changelog  2020-09-20 17:18:05.0 +0200
+++ tootle-1.0-alpha1/debian/changelog  2020-09-21 23:05:54.0 +0200
@@ -1,3 +1,10 @@
+tootle (1.0-alpha1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass a crossfile to meson. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 21 Sep 2020 23:05:54 +0200
+
 tootle (1.0-alpha1-1) unstable; urgency=low
 
   * New upstream release
diff --minimal -Nru tootle-1.0-alpha1/debian/rules 
tootle-1.0-alpha1/debian/rules
--- tootle-1.0-alpha1/debian/rules  2020-09-20 17:18:05.0 +0200
+++ tootle-1.0-alpha1/debian/rules  2020-09-21 23:05:53.0 +0200
@@ -11,8 +11,7 @@
rm -rf debian/build
 
 override_dh_auto_configure:
-   mkdir -p debian/build
-   cd debian/build && meson --prefix=/usr ../..
+   dh_auto_configure --builddirectory=debian/build
 
 override_dh_auto_build:
cd debian/build && ninja -v

Bug#970690: There appear video glitches/artifacts in opera and chrome browsers

[tonywyattparker]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1

The problem is that there appear (graphic/video) glitches/artifacts in opera 
and chrome browsers like never before.

I guess that is due to the old nvidia video adapter and the driver nouveau.

The system (2006 year - amd athlon, ddr2 4GB) is with built-in Nvidia nForce 
430 / GeForce 6150SE (chipset/video adapter) and debian buster (10) latest 
updates with lxqt/sddm/openbox (LXQt 0.14.1-1, sddm 0.18.0-1, openbox 3.6.1-8 
and Qt 5.11.3) on kernel 4.19.0-10-amd64 (4.19.132-1).

Bug#970471: [pkg-crosswire-devel] Processed: reopen

[Roberto C . Sánchez]

On Mon, Sep 21, 2020 at 08:55:50AM -0400, Roberto C. Sánchez wrote:
> On Mon, Sep 21, 2020 at 02:54:17PM +0200, Bastian Germann wrote:
> > Am 21.09.20 um 14:37 schrieb Roberto C. Sánchez:
> > > On Mon, Sep 21, 2020 at 08:39:05AM +, Debian Bug Tracking System 
> > > wrote:
> > >> Processing commands for cont...@bugs.debian.org:
> > >>
> > >>> reopen 970471 =
> > >> Bug #970471 {Done: Bastian Germann } 
> > >> [bibletime] bibletime: FTBFS on mips64el
> > >> 'reopen' may be inappropriate when a bug has been closed with a version;
> > >> all fixed versions will be cleared, and you may need to re-add them.
> > >> Bug reopened
> > >> No longer marked as fixed in versions bibletime/3.0-2.
> > >>>
> > > 
> > > Bastian,
> > > 
> > > This bug may require further investigation on a porterbox to ensure that
> > > the root cause has been determined and then fixed.  Do you have access
> > > to a mips64el porterbox or perhaps a non-Debian system of that
> > > architecture?  If not, I can make some time later this week to try to
> > > diagnose the issue.
> > > 
> > > Regards,
> > > 
> > > -Roberto
> > > 
> > 
> > No, I do not have access to a mips64el machine. I built the package in
> > qemu. Without the patches it failed and with them applied it built
> > successfully.
> > 
> That is helpful to know.  I will try to rebuild 3.0-2 on a mips64el
> machine this week to see if it fails in that case.  Once I am able to do
> that I will follow-up with the results.
> 
I spent some time on this today and thanks to a suggestion from someone
in IRC, I was able to determine that removing link-time optimization
fixed the mips64el build.  Specifically, these lines had to be removed:

-SET_TARGET_PROPERTIES("${target}" PROPERTIES
-INTERPROCEDURAL_OPTIMIZATION TRUE)

It is likely that since bibletime is a GUI application that it will not
benefit very much from link-time optimization.  Is it possible to drop
that property altogether?  If not, perhaps then conditionally only
setting it on known good architectures would be possible.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[anomie]

On Sun, Sep 20, 2020 at 09:58:45AM +0700, El boulangero wrote:
> Do you know what's special with the `tianon/true` image? On what OS/release
> is it based?

It's an image that contains only a single binary that returns 0. That
binary uses no libraries, not even libc.

It's intended as an extremely light-weight image for purposes that don't
need a whole OS. See, for example,
https://stackoverflow.com/questions/37120260/configure-docker-compose-override-to-ignore-hide-some-containers

It seems that something changed between 19.03.12+dfsg1-3 and
19.03.12+dfsg1-4 that is somehow or other assuming the container
contains more infrastructure. If you determine that the bug is upstream,
feel free to forward it to them (and, ideally, revert whatever patch was
added to 19.03.12+dfsg1-4 that caused the problem in the mean time to
avoid breaking other software on the system).

Bug#970678: Network preseeding using http is broken

[Philip Hands]

Martin Samuelsson  writes:

> I'm saying there is no /dev/fd/ at all

Oh, fair enough.  That's odd.

BTW The example I pasted was just busybox running on my laptop running
full Debian, so was not supposed to be demonstrating it working under
d-i.

...
> --- http.orig 2020-09-21 17:21:24.159480072 +0200
> +++ http.simplified   2020-09-21 17:21:03.951356698 +0200
> @@ -14,10 +14,10 @@
>  
>   local RETVAL=$( {
>   echo 1
> - wget "$@" 2>&1 >&3 && echo %OK%
> + wget "$@" 2>&1 && echo %OK%
>   echo %EOF%
> - } | ( sed -ne 
> '1{h;d};/'"$file_not_found_pattern"'/{p;s/.*/4/;h;d};/^%OK%$/{s/.*/0/;h;d};$!p;$x;$w
>  /dev/fd/4' >&2 ) 4>&1
> - ) 3>&1
> + } | ( sed -ne 
> '1{h;d};/'"$file_not_found_pattern"'/{p;s/.*/4/;h;d};/^%OK%$/{s/.*/0/;h;d};$!p;$x;$p
>  '>&2 )
> + ) 
>   return $RETVAL
>   }

This mixes the stdout of wget with the %OK% %EOF% stuff, and then puts
it all into the sed, which seems flawed.

One could replace the >&3 with >/dev/null, and keep the sed, but if one
isn't trying to preserve the wget output I don't see the point of
keeping the sed at all.

I'd have thought something like this would do the trick (not tested yet):

local RETVAL=$(
 {
   {
 wget "$@" 2>&1 >/dev/null && echo 0 >&3
   } | {
 grep -q "$file_not_found_pattern" && echo 4 >&3
   } || echo 1 >&3
 } 3>&1 | head -1
)

(the patterns will need to be tweaked to take account of sed vs. grep)

One could of course use stderr for that (>&2 ... 2>&1) for getting the
echo-ed return codes out, rather than fd #3, but I think this is clearer
(since one really isn't trying to produce stderr output) and AFAIK it
should work fine even if /dev/fd/ is missing.

I suspect there may be a way of getting this to work without the need
for a local variable and the echoing for the result codes, so I will
ponder on that...

BTW I just saw Ben's comment that we should just fix the missing /dev/fd
which strikes me as entirely sensible. Even if nothing uses /dev/fd/ in
d-i (other than here) it seems wrong to simply ignore the fact that it's
missing, since people might well try to use it in preseed scripts etc.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#879728: closed by Otto Kekäläinen (Re: [debian-mysql] Bug#879728: mysqld fails to start not finding messagefile when started by systemd)

[Thomas DEBESSE]

Note: the faulty package was not MariaDB but was likely to be
another Debian package because this server did not use
third-party software or software from non-Debian repositories.
I have seen the issue on more servers at the time, all of them
running Debian without third-party stuff. The other affected Debian
servers did not run MariaDB so this was less blocking.


Le lun. 21 sept. 2020 à 22:25, Thomas DEBESSE  a
écrit :

> The failure of MariaDB came from a permission set by another process
> on a shared parent dir of that file.
> Then, this was the side effect of another software from another
> package I did not figure.
> Basically another software from another package removed some read
> permission to “other” (or something like that) to some directory that
> sits between / root directory and this file, maybe /usr/share or
> something like that.
> This permission change did not only affect MariaDB but also other
> softwares, some simple “sudo ” would have been able
> to reproduce the bug.
>
> The root cause, the package modifying some permission of some shared
> parent dir to make it less permissive than Debian default, was not
> found.
> As a workaround I've set a cron task restoring the default Debian
> folder permission every time.
> I don't work anymore for the ones running the affected server so I
> lost access to the faulty environment and cannot track down the faulty
> package anymore.
>
>
> Le lun. 21 sept. 2020 à 21:57, Debian Bug Tracking System
>  a écrit :
> >
> > This is an automatic notification regarding your Bug report
> > which was filed against the mariadb-server-10.1 package:
> >
> > #879728: mysqld fails to start not finding messagefile when started by
> systemd
> >
> > It has been closed by Otto Kekäläinen .
> >
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Otto Kekäläinen <
> o...@debian.org> by
> > replying to this email.
> >
> >
> > --
> > 879728: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879728
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> >
> >
> >
> > -- Forwarded message --
> > From: "Otto Kekäläinen" 
> > To: 879728-d...@bugs.debian.org
> > Cc:
> > Bcc:
> > Date: Mon, 21 Sep 2020 22:49:19 +0300
> > Subject: Re: [debian-mysql] Bug#879728: mysqld fails to start not
> finding messagefile when started by systemd
> > Control: tags -1 wontfix
> >
> > There was no further information provides, so closing this as 'wontfix'.
> >
> >
> > -- Forwarded message --
> > From: Thomas DEBESSE 
> > To: sub...@bugs.debian.org
> > Cc:
> > Bcc:
> > Date: Wed, 25 Oct 2017 08:33:48 +0200
> > Subject: mysqld fails to start not finding messagefile when started by
> systemd
> > Package: mariadb-server-10.1
> > Version: 10.1.26-0+deb9u1
> > Severity: grave
> >
> > Hi, I just upgraded my server from jessie to stretch and I face a bug
> > I already reported 13 month ago as bug #837166 but unfortunately this
> > bug was closed when the related package (mysql-server-5.6) was removed
> > from archive. But the bug is still present in mariadb-server-10.1
> > shiped within stretch repository (no backport).
> >
> > What is expected: “systemctl start mariadb” starts mariadb server.
> >
> > What is happening: mariadb server shutdowns at startup printing
> > “[ERROR] Can't find messagefile '/usr/share/mysql/errmsg.sys'” error
> > message.
> >
> > Another interesting fact: starting “/usr/sbin/mysqld” from command
> > line in an interactive shell leads to a working mysql server, but the
> > exact same command started by systemd leads to a instantaneous
> > shutdown with error reporting as stated.
> >
> > Output of “systemctl status mariadb.service” command:
> >
> > oct. 25 06:49:35 machine mysqld[4868]: 2017-10-25  4:49:35
> > 140131405656640 [Note] /usr/sbin/mysqld (mysqld
> > 10.1.26-MariaDB-0+deb9u1) starting as process 4868 ...
> > oct. 25 06:49:35 machine mysqld[4868]: 2017-10-25  4:49:35
> > 140131405656640 [ERROR] Can't find messagefile
> > '/usr/share/mysql/errmsg.sys'
> >
> > For rerefence, the initial bug report (now closed and archived) with
> > some detailed explanations:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837166
> >
> > I set the severity of this bug to “grave” since this bug makes
> > the package unusable.
> >
> > The package mariadb-server-10.1=10.1.26-0+deb9u1 is unusable since the
> > service is not startable.
> >
> > The mysql-server-5.5=5.5.58-0+deb8u1 package from jessie is known to
> > not be affected by the bug.
> >
> > A prior occurrence to this bug was reported on
> > mysql-server-5.6=5.6.30-1~bpo8+1 at the date of 2016-09-09.
> >
> > The mariadb-server-10.1=10.1.26-0+deb9u1 package is known to still be
> > affected by the bug at the date of 2017-10-25.
> >
> > Previous bug report #837166 says the bug was fixed in version
> > 5.6.35-1+rm, but it's 

Bug#925385: [debian-mysql] Bug#925385: /usr/bin/mysql: Poor MariaDB performance

[Otto Kekäläinen]

Control: tags -1 moreinfo

Does this still apply for latest MariaDB version?

Bug#929520: [debian-mysql] Bug#929520: Problem starting mariadb

[Otto Kekäläinen]

Control: tags -1 moreinfo

Is this still an issue?

This is difficult to reproduce and thus debug.

Bug#879728: closed by Otto Kekäläinen (Re: [debian-mysql] Bug#879728: mysqld fails to start not finding messagefile when started by systemd)

[Thomas DEBESSE]

The failure of MariaDB came from a permission set by another process
on a shared parent dir of that file.
Then, this was the side effect of another software from another
package I did not figure.
Basically another software from another package removed some read
permission to “other” (or something like that) to some directory that
sits between / root directory and this file, maybe /usr/share or
something like that.
This permission change did not only affect MariaDB but also other
softwares, some simple “sudo ” would have been able
to reproduce the bug.

The root cause, the package modifying some permission of some shared
parent dir to make it less permissive than Debian default, was not
found.
As a workaround I've set a cron task restoring the default Debian
folder permission every time.
I don't work anymore for the ones running the affected server so I
lost access to the faulty environment and cannot track down the faulty
package anymore.


Le lun. 21 sept. 2020 à 21:57, Debian Bug Tracking System
 a écrit :
>
> This is an automatic notification regarding your Bug report
> which was filed against the mariadb-server-10.1 package:
>
> #879728: mysqld fails to start not finding messagefile when started by systemd
>
> It has been closed by Otto Kekäläinen .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Otto Kekäläinen 
>  by
> replying to this email.
>
>
> --
> 879728: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879728
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Otto Kekäläinen" 
> To: 879728-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 21 Sep 2020 22:49:19 +0300
> Subject: Re: [debian-mysql] Bug#879728: mysqld fails to start not finding 
> messagefile when started by systemd
> Control: tags -1 wontfix
>
> There was no further information provides, so closing this as 'wontfix'.
>
>
> -- Forwarded message --
> From: Thomas DEBESSE 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 25 Oct 2017 08:33:48 +0200
> Subject: mysqld fails to start not finding messagefile when started by systemd
> Package: mariadb-server-10.1
> Version: 10.1.26-0+deb9u1
> Severity: grave
>
> Hi, I just upgraded my server from jessie to stretch and I face a bug
> I already reported 13 month ago as bug #837166 but unfortunately this
> bug was closed when the related package (mysql-server-5.6) was removed
> from archive. But the bug is still present in mariadb-server-10.1
> shiped within stretch repository (no backport).
>
> What is expected: “systemctl start mariadb” starts mariadb server.
>
> What is happening: mariadb server shutdowns at startup printing
> “[ERROR] Can't find messagefile '/usr/share/mysql/errmsg.sys'” error
> message.
>
> Another interesting fact: starting “/usr/sbin/mysqld” from command
> line in an interactive shell leads to a working mysql server, but the
> exact same command started by systemd leads to a instantaneous
> shutdown with error reporting as stated.
>
> Output of “systemctl status mariadb.service” command:
>
> oct. 25 06:49:35 machine mysqld[4868]: 2017-10-25  4:49:35
> 140131405656640 [Note] /usr/sbin/mysqld (mysqld
> 10.1.26-MariaDB-0+deb9u1) starting as process 4868 ...
> oct. 25 06:49:35 machine mysqld[4868]: 2017-10-25  4:49:35
> 140131405656640 [ERROR] Can't find messagefile
> '/usr/share/mysql/errmsg.sys'
>
> For rerefence, the initial bug report (now closed and archived) with
> some detailed explanations:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837166
>
> I set the severity of this bug to “grave” since this bug makes
> the package unusable.
>
> The package mariadb-server-10.1=10.1.26-0+deb9u1 is unusable since the
> service is not startable.
>
> The mysql-server-5.5=5.5.58-0+deb8u1 package from jessie is known to
> not be affected by the bug.
>
> A prior occurrence to this bug was reported on
> mysql-server-5.6=5.6.30-1~bpo8+1 at the date of 2016-09-09.
>
> The mariadb-server-10.1=10.1.26-0+deb9u1 package is known to still be
> affected by the bug at the date of 2017-10-25.
>
> Previous bug report #837166 says the bug was fixed in version
> 5.6.35-1+rm, but it's now verified the bug is still there in lately
> versions.
>
> --
> Thomas Debesse



-- 
Thomas DEBESSE

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[Julian Gilbey]

On Mon, Sep 21, 2020 at 07:03:08AM -0700, tony mancill wrote:
> On Mon, Sep 21, 2020 at 10:01:35AM +0100, Julian Gilbey wrote:
> > On Sun, Sep 20, 2020 at 09:59:22PM -0700, tony mancill wrote:
> > > Hi Tiago, hi Julian,
> > > [...]
> > > Julian, I applied the patch and built the package successfully, but
> > > jlink still fails with the "expected hash" error.  It's (perhaps)
> > > interesting that the expected hash does differ between the patched build
> > > and the unpatched build.
> > 
> > That's really bizarre.  I checked running strip-nondeterminism on the
> > resulting jmods and it seemed to be OK.  But if so, then I've clearly
> > overlooked something.
> 
> I'm wondering if we just need more of it sprinkled about earlier in the
> build.  I didn't believe it at first and so rebuilt (more than once) to
> be sure.

Hi Tony,

Here are a couple more thoughts on exploring this:

* Search through the build log to check that strip-nondeterminism is
  actually being called.  If it's not, perhaps the patch has
  accidentally not been applied.

* Run the sha256sum command (protected with a '-' in case it fails!)
  at several points in the build-arch and install targets to see when
  the hashes change, if at all.

HTH,

   Julian

Bug#968097: transmission-daemon consumes all memory

[Moritz Mühlenhoff]

On Sun, Sep 20, 2020 at 08:52:32PM +0200, ilf wrote:
> Thank you, Moritz!
> 
> I installed your packages on September 15. Since then, transmission behaves
> fine again. See munin-graph attached.
> 
> If this sample - five days on one machine from one user - is big enough to
> be significant, i don't know.

Ack, thanks. The window for getting updates into Buster 10.6 is closed, but
I'll submit the revised package next week.

Cheers,
Moritz

Bug#914215: [debian-mysql] Bug#914215: mariadb-server-10.1: does not start when /var/lib or /var/log is a symbolic link to another filesystem

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello!

Can you please check with the latest MariaDB version if this bug still applies?

Thanks!

Bug#872891: gcc-multilib conflicts with GCC cross toolchains

[Niels Möller]

Hi, 

in 2017, Matthias Klose marked this bug as wontfix, and explained the
problem like this:

> because the cross toolchain has /usr/include on it's include path,
> which has incompatible header files: /usr/include/asm.

Is that still the case, a few years later? I have an x86_64 machine with
debian buster + gcc-10 and cross compilers from "bullseye" (testing),
and no /usr/include/asm at all. I have the following gcc packages
installed:

ii  gcc   4:10.1.0-1 amd64GNU C 
compiler
ii  gcc-1010.2.0-7   amd64GNU C 
compiler
ii  gcc-10-arm-linux-gnueabihf10.2.0-3cross2 amd64GNU C 
compiler (cross compiler for armhf architecture)
ii  gcc-10-arm-linux-gnueabihf-base:amd64 10.2.0-3cross2 amd64GCC, the 
GNU Compiler Collection (base package)
ii  gcc-10-base:amd64 10.2.0-7   amd64GCC, the 
GNU Compiler Collection (base package)
ii  gcc-10-base:armhf 10.2.0-7   armhfGCC, the 
GNU Compiler Collection (base package)
ii  gcc-10-cross-base 10.2.0-3cross2 all  GCC, the 
GNU Compiler Collection (library base package)
ii  gcc-10-i686-linux-gnu 10.2.0-3cross2 amd64GNU C 
compiler (cross compiler for i386 architecture)
ii  gcc-10-i686-linux-gnu-base:amd64  10.2.0-3cross2 amd64GCC, the 
GNU Compiler Collection (base package)
ii  gcc-10-multilib   10.2.0-7   amd64GNU C 
compiler (multilib support)
ii  gcc-10-multilib-i686-linux-gnu10.2.0-3cross2 amd64GNU C 
compiler (multilib support) (cross compiler for i386 architecture)
ii  gcc-8 8.4.0-4amd64GNU C 
compiler
ii  gcc-8-base:amd64  8.4.0-4amd64GCC, the 
GNU Compiler Collection (base package)
ii  gcc-9-base:amd64  9.3.0-18   amd64GCC, the 
GNU Compiler Collection (base package)
ii  gcc-arm-linux-gnueabihf   4:10.1.0-1 amd64GNU C 
compiler for the armhf architecture
ii  gcc-i686-linux-gnu4:10.1.0-1 amd64GNU C 
compiler for the i386 architecture
ii  gcc-mingw-w64 10.1.0-3+23all  GNU C 
compiler for MinGW-w64
ii  gcc-mingw-w64-base10.1.0-3+23amd64GNU 
Compiler Collection for MinGW-w64 (base package)
ii  gcc-mingw-w64-i68610.1.0-3+23all  GNU C 
compiler for MinGW-w64 targeting Win32
ii  gcc-mingw-w64-i686-posix  10.1.0-3+23amd64GNU C 
compiler for MinGW-w64, Win32/POSIX
ii  gcc-mingw-w64-i686-posix-runtime  10.1.0-3+23amd64GNU 
Compiler Collection for MinGW-w64, i686/posix
ii  gcc-mingw-w64-i686-win32  10.1.0-3+23amd64GNU C 
compiler for MinGW-w64, Win32/Win32
ii  gcc-mingw-w64-i686-win32-runtime  10.1.0-3+23amd64GNU 
Compiler Collection for MinGW-w64, i686/win32
ii  gcc-mingw-w64-x86-64  10.1.0-3+23all  GNU C 
compiler for MinGW-w64 targeting Win64
ii  gcc-mingw-w64-x86-64-posix10.1.0-3+23amd64GNU C 
compiler for MinGW-w64, Win64/POSIX
ii  gcc-mingw-w64-x86-64-posix-runtime10.1.0-3+23amd64GNU 
Compiler Collection for MinGW-w64, x86-64/posix
ii  gcc-mingw-w64-x86-64-win3210.1.0-3+23amd64GNU C 
compiler for MinGW-w64, Win64/Win32
ii  gcc-mingw-w64-x86-64-win32-runtime10.1.0-3+23amd64GNU 
Compiler Collection for MinGW-w64, x86-64/win32
ii  gcc-multilib-i686-linux-gnu   4:10.1.0-1 amd64GNU C 
compiler for the i386 architecture
ii  lib32gcc-10-dev   10.2.0-7   amd64GCC 
support library (32 bit development files)
ii  lib32gcc-s1   10.2.0-7   amd64GCC 
support library (32 bit Version)
ii  lib64gcc-10-dev-i386-cross10.2.0-3cross2 all  GCC 
support library (64bit development files)
ii  lib64gcc-s1-i386-cross10.2.0-3cross2 all  GCC 
support library (i386) (64bit)
ii  libgcc-10-dev:amd64   10.2.0-7   amd64GCC 
support library (development files)
ii  libgcc-10-dev-armhf-cross 10.2.0-3cross2 all  GCC 
support library (development files)
ii  libgcc-10-dev-i386-cross  10.2.0-3cross2 all  GCC 
support library (development files)
ii  libgcc-8-dev:amd648.4.0-4amd64GCC 
support library (development files)
ii  libgcc-s1:amd64   10.2.0-7   amd64GCC 
support library
ii  libgcc-s1:armhf   10.2.0-7   armhfGCC 
support library
ii  libgcc-s1-armhf-cross 10.2.0-3cross2 all  GCC 
support library (armhf)
ii  libgcc-s1-i386-cross  

Bug#846950: Fixes for bugs #846950, #849942, #849608

[Felix Lechner]

Hi Joachim.

On Mon, Sep 21, 2020 at 11:18 AM Joachim Falk  wrote:
>
> Could you all test 1:1.3.4-5~RC5?

Thanks so much for picking up these old and unnecessary bugs.

I run stable everywhere and may not have an easy easy to way to test
your fixes, but I applied the patches from my comments manually to
every update for the past four years (probably six or seven times, per
machine). I am confident they do the right thing. They are well
tested!

Kind regards
Felix Lechner

Bug#932290: insserv: Script has overlapping Default-Start and Default-Stop runlevels

[Timo van Roermund]

Same issue here. I get the following output when upgrading initscripts:

Preparing to unpack .../07-initscripts_2.96-5_all.deb ...
Unpacking initscripts (2.96-5) over (2.96-4) ...
(...)
Setting up initscripts (2.96-5) ...
Installing new version of config file /etc/init.d/mountdevsubfs.sh ...
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.


(the last line is repeated another 27 times)

Any idea why this is happening? Anything I should check on my PC?

Bug#970696: RFS: mtd-utils/1:2.1.2-1 [ITS] -- Memory Technology Device Utilities

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mtd-utils":

 * Package name: mtd-utils
   Version : 1:2.1.2-1
   Upstream Author : David Oberhollenzer
 * URL : http://www.linux-mtd.infradead.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/mtd-utils
   Section : utils

It builds those binary packages:

  libubi-dev - UBIFS Development Libraries
  libmtd-dev - Memory Technology Device Development Libraries
  mtd-utils - Memory Technology Device Utilities

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

  https://mentors.debian.net/package/mtd-utils/

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

  dget -x
https://mentors.debian.net/debian/pool/main/m/mtd-utils/mtd-utils_2.1.2-1.dsc

Changes since the last upload:

 mtd-utils (1:2.1.2-1) unstable; urgency=medium
 .
   * d/gbp.conf: Set debian-branch and pristine-tar
   * lintian: rules-requires-root-missing
   * Mention included tools in description (Closes: #905689)
   * d/rules: Build with all hardening features
   * Set myself as maintainer (Closes: #970640)

Regards,
Bastian

Bug#930035: libmariadbclient18: DBD::mysql::db do failed: Malformed packet

[Otto Kekäläinen]

Control: merge -1 930036

Bug#970678: Network preseeding using http is broken

[Ben Hutchings]

On Mon, 2020-09-21 at 17:43 +0200, Martin Samuelsson wrote:
> Philip Hands @ 2020-09-21 (Monday), 15:30 (+0200)
> > Martin Samuelsson  writes:
> > 
> > Just to be clear on this point, are you saying [...]
> 
> I'm saying there is no /dev/fd/ at all on current daily debian-installer 
> images and hasn't been since at least 20200818 (which was the oldest one I 
> could try with current kernel modules).
[...]

Then we should investigate and fix that instead of removing code that
uses it.

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.




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

Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.

[Florian Bruhin]

Hey again,

On Mon, Sep 21, 2020 at 12:17:57PM -0300, felipe wrote:
> Hey,
> 
> > For 1), do you see those QtWebEngineProcess crashes when you run
> > "coredumpctl list"? If so, can you please show "coredumpctl info PID"
> > with the PID from the list? If not, can you check whether you can
> > reproduce them (making the entire browser crash) when you run with
> > "--qt-flag single-process"?
> 
> I have attached  coredumpctl info when it crashes using --temp-basedir.
> 
> Running with:
>   $ qutebrowser --qt-flag single-process
>   [1]5850 illegal hardware instruction (core dumped)  qutebrowser 
> --qt-flag single-process
> The browser starts with a blank page and when I try to open any webpage, it 
> crashes.
> 
> I have also attached coredumpctl of this crash.
> 
> 
> > For 2), it looks like there's no libqt5webengine5-dbg{,sym} package in
> > the debian archives. Could you check if you find them if you run e.g.
> > find-dbgsym-packages on /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.14.2
> > https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
> 
> After adding deb 'http://deb.debian.org/debian-debug/ unstable-debug
> main' to my '/etc/apt/sources.list' and installing
> 'libfile-slurper-perl' and 'libfile-which-perl', I find some debug
> symbols available:
> 
>   $ find-dbgsym-packages 
> /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.14.2
> 
> I have attached the file 'find-dbgsym-packages.txt'

You will need at lesat libqt5webengine5-dbgsym and perhaps
libqt5webenginecore5-dbgsym as well.

From what I see in the attached coredumpctl outputs, those happened
before you installed the symbols, right? Can you try again, so that
you'd hopefully get a stacktrace which says more than just "n/a" for the
entries? :)

> > If getting more info via coredumpctl didn't work, but you can reproduce
> > with --qt-flag single-process, can you please do something like:
> > 
> >gdb -ex r --args /usr/bin/python3 -m qutebrowser --temp-basedir 
> > --qt-flag single-process
> 
>   $ sudo gdb -ex r --args /usr/bin/python3 -m qutebrowser --temp-basedir 
> --qt-flag single-process

Please don't run with 'sudo'. This can cause various other issues (since
Chromium's sandboxing doesn't work properly as root) and running a
browser as root is a bad idea in general ;)

> [...]
> 
> 
> Thread 40 "Chrome_InProcRe" received signal SIGILL, Illegal instruction.
> [Switching to Thread 0x7fff58a89700 (LWP 12375)]
> 0x7fffea1b128f in 
> blink::CompositedLayerMapping::ComputeBoundsOfOwningLayer(blink::PaintLayer 
> const*,
> blink::IntRect&, blink::IntRect&, blink::PhysicalOffset&, blink::IntPoint&) 
> () from
> /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
> 
> (gdb) bt
> #0  0x7fffea1b128f in 
> blink::CompositedLayerMapping::ComputeBoundsOfOwningLayer(blink::PaintLayer 
> const*,
> blink::IntRect&, blink::IntRect&, blink::PhysicalOffset&, blink::IntPoint&) 
> () at
> /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
> #1  0x7fffea1bc054 in 
> blink::CompositedLayerMapping::UpdateGraphicsLayerGeometry(blink::PaintLayer 
> const*,
> blink::PaintLayep

Looks like your output/mail was cut off here, so it's difficult to say
what's happening exactly - but from what I can tell so far, this most
like is indeed an issue in QtWebEngine and not qutebrowser.

Can you check if you get the same crashes with another QtWebEngine-based
browser such as falkon?

If so, this report should probably be moved to libqt5webengine5, though
having the full stack traces would still be useful for the maintainers
of that package :)

Thanks,
Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature

Bug#970694: numba: FTBFS: unsat-dependency: python3-llvmlite:amd64 (< 0.34)

[Sebastian Ramacher]

Source: numba
Version: 0.50.1-2
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

numba has unsatisfiable build dependencies:
| report:
|  -
|   package: sbuild-build-depends-main-dummy
|   version: 0.invalid.0
|   architecture: amd64
|   status: broken
|   reasons:
|-
| missing:
|  pkg:
|   package: sbuild-build-depends-main-dummy
|   version: 0.invalid.0
|   architecture: amd64
|   unsat-dependency: python3-llvmlite:amd64 (< 0.34)

python3-llvmlite is now at version 0.34.0-1.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#926338: tomcat9: tomcat user's home folder is '/'

[David Magda]

On Sun, 2 Jun 2019 23:29:51 +0200, Emmanuel Bourg wrote:


I admit using / as home directory isn't perfect, but I fail to see how
this can be considered insecure.

What about setting the -Duser.home JVM parameter when Tomcat is started
instead of changing the system user home?


Tomcat is operating at two levels: the operating system and the application.

Using "-Duser.home" is useful for telling the application itself where 
to look for things, but less so for doing some operations at the OS layer.


One example is for CI/CD infrastructure: if someone wants to use (say) 
Jenkins to deploy WAR files as they update code, and want to use SSH 
keys for getting into front-end Tomcat systems, where would they put the 
authorized_keys(5) file?


SSHd looks for it in "${HOME}/.ssh/" by default, which would mean "/.ssh/".

So where would one put it? Should the passwd(5) file simply be edited 
manually after installation?

Bug#970693: sweed FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: sweed
Version: 3.2.1+dfsg-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

sweed fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
sweed cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru sweed-3.2.1+dfsg/debian/changelog 
sweed-3.2.1+dfsg/debian/changelog
--- sweed-3.2.1+dfsg/debian/changelog   2020-08-27 17:27:35.0 +0200
+++ sweed-3.2.1+dfsg/debian/changelog   2020-09-21 20:27:28.0 +0200
@@ -1,3 +1,10 @@
+sweed (3.2.1+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 21 Sep 2020 20:27:28 +0200
+
 sweed (3.2.1+dfsg-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru sweed-3.2.1+dfsg/debian/rules sweed-3.2.1+dfsg/debian/rules
--- sweed-3.2.1+dfsg/debian/rules   2020-08-27 17:23:33.0 +0200
+++ sweed-3.2.1+dfsg/debian/rules   2020-09-21 20:27:20.0 +0200
@@ -14,7 +14,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) -f Makefile.gcc $*
+   dh_auto_build --buildsystem=makefile -- -f Makefile.gcc $*
 
 
 override_dh_auto_clean:

Bug#969621: propellor: Propellor fails to find location of built propellor binary

[Diane Trout]

Version: 5.12-1

Version 5.12-1 compiled correctly on my testing system just now.

Diane

On Sun, 2020-09-13 at 20:47 -0700, Sean Whitton wrote:
> Hello,
> 
> On Sat 05 Sep 2020 at 09:22PM -07, Diane Trout wrote:
> 
> > I tried to just build 5.11, but export CABAL=./Setup breaks the
> > build, the
> > makefile assumes ./Setup sdist -o - will output a compressed
> > stream, but the
> > Setup file built in an unstable schroot doesn't support that
> > feature.
> 
> Just uploaded a version which should be fixed to sid; would be
> grateful
> if you could test.
> 


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

Bug#970534: systemd: `busctl introspect org.freedesktop.login1 /org/freedesktop/login1` fails

[Michael Biebl]

Am 20.09.20 um 09:24 schrieb Ansgar:
> Michael Biebl writes:
>> Am 18.09.20 um 09:07 schrieb Ansgar:
>>> The following command fails (as a regular user):
>>>
>>> +---
>>> | $ busctl introspect org.freedesktop.login1 /org/freedesktop/login1
>>> | Failed to get all properties on interface org.freedesktop.login1.Manager: 
>>> Input/output error
>>> +---
>>
>> Hm, interesting. The exact same command works for me.
>> Has this system been rebooted after the 246.5 update? We don't restart
>> logind as part of the upgrade process.
> 
> Yes, it also happened after a restart.
> 
> I assumed it was a permission problem (and `busctl` should show the
> remaining information), but now looked into systemd-logind's journal and
> see the following message whenever I try:
> 
> +---
> | systemd-logind[1850]: Failed to probe partition scheme of "/dev/block/9:1": 
> Input/output error
> +---
> 
> /dev/block/9:1 is /dev/md1 which directly contains the /boot filesystem
> and no partitions (I was also too lazy to properly set it up, so it is a
> failed raid1 with only 1 device...).  `lsblk` shows:
> 
> +---
> | ├─sde1   8:65   0   121M  0 part  /boot/efi
> | ├─sde2   8:66   0   390M  0 part
> | │ └─md1  9:10 389.7M  0 raid1 /boot
> +---
> 
> So the `BootLoaderEntries` property which was the problem causes logind
> to scan disks and give an error when it is unhappy with one of them.
> That might be an additional bug, but `busctl` shouldn't give up and show
> nothing either way.

Nod.
Could you file this upstream please.
It's likely that upstream will want you to run further diagnostics or
test a prospective patch.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature

Bug#969572: ITP: python-duniterpy - Duniter Python API

[Jonas Smedegaard]

Quoting m...@moul.re (2020-09-21 19:28:53)
> How are you doing with the packaging?
> What steps have been done? What's left on your list?
> 
> I released a v0.58.0 which would be the last one with Python 3.5 
> support.

> I am planning a v0.60.0 which drops Python 3.5 and uses Scrypt from 
> v3.6 standard library.

For Debian there is no need to support Python 3.5 - oldest release 
officially supported by Debian is currently stable (a.k.a. buster) which 
has Python 3.7: https://tracker.debian.org/pkg/python3-defaults


> Regarding DuniterPy v0.60.0, is there any requirement or wish from 
> your side for the packaging, for us to include it into this release?

DuniterPy is still waiting for Debian ftpmaster approval in the 
so-called "NEW queue": 
https://ftp-master.debian.org/new/python-duniterpy_0.57.0-1.html

While the package is in NEW queue I do not get automatically notified 
about new releases, and it is helpful if you drop me an email when new 
releases are issued.


> One thing that we need to clarify on our side is about the copyright 
> and license statements usage in the headers of every files.
> In our discussion for Silkaj packaging for Debian Buster, you told me 
> that this how the GPL licensing should be used.
> For our understanding, is it a requirement from Debian packaging or 
> from the GPL licensing guidelines? One answer can be that Debian 
> packaging requires to follow the licenses guidelines.

It is not _required_ to state licensing in every file.

It is only _recommended_ to do so.


> The runtime source code should have them of course. Does the tests and 
> the examples should also have those statements?

Ideally, every file that is protected by copyright contains both 
copyright and license statement.

Legally there is *no* need to write anything at all.  Copyright is 
implicitly assigned!  The sentence "All right reserved" is archaic.

The purpose of those statements is to _help_ your users to a) know what 
they are allowed to do without needing to ask the copyright holders, and 
b) know who are the copyright holders in case they want to ask for 
additional permissions.

If you don't see it as a good thing to help your users know their 
rights, then maybe you should ask yourself why you are licensing your 
code as Free software at all!

If in doubt, I recommend to add copyright and license statements: It is 
not harmful, and it is potentially helpful.


> Does the tests and the examples will be distributed in the package?

Debian distributes both source and binary code.

Tests are typically distributed only as part of the source package.

Examples are typically distributed with both source and binary packages.



Kind regards,

 - 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#846950: Fixes for bugs #846950, #849942, #849608

[Joachim Falk]

Hi all,

I hopefully fixed these bugs in my Debian bullseye package. Could you
all test 1:1.3.4-5~RC5. This can be found for AMD64 under

deb http://www.jfalk.de homebrew-bullseye patched recompiled selfmade

If you use another architecture, you have to compile from source.
The source for the fixes can be found in the following git repository:

git clone https://salsa.debian.org:jfalk-guest/nfs-utils.git -b jfalk

Hopefully, we can convince the Debian kernel team to merge these changes
into the nfs-utils Debian package in time for the Debian bullseye release.

nfs-utils (1:1.3.4-5~RC5) UNRELEASED; urgency=medium

  [ Joachim Falk ]
  * debian/nfs-utils_env.sh: Correctly propagate RPCGSSDOPTS from
/etc/default/nfs-common to rpc-gssd.service. Even though RPCGSSDOPTS
was not documented or explicitly exposed in /etc/default/nfs-common,
it’s used by the init script and there are people that have been
relying on this for a while. (Closes: #846950)
  * Replace hardcoded keytab check in rpc-gssd.service with NEED_GSSD and
auto detection of kerberized NFS mounts in /etc/fstab. Auto detection
logic is in the nfs-utils_need_gssd_check.sh script. (Closes: #849608)
  * Fix kerberized NFS service inside Linux containers when the container
host loads the auth_rpcgss kernel module to enable kerberized NFS
service for its containers.
  * Replace hardcoded keytab check in rpc-svcgssd.service with NEED_SVCGSSD
and auto detection of kerberized NFS exports in /etc/exports. Auto
detection logic is in the nfs-utils_need_svcgssd_check.sh script.
(Closes: #849942)
  * Replace hardcoded keytab check in auth-rpcgss-module.service with
NEED_GSSD and auto detection of kerberized NFS mounts in /etc/fstab as
well as NEED_SVCGSSD and auto detection of kerberized NFS exports in
/etc/exports. Auto detection logic is in the scripts
nfs-utils_need_gssd_check.sh and nfs-utils_need_svcgssd_check.sh.
(Closes: #849942, #849608)
  * Only start the rpc-svcgssd.service when the nfs-kernel-server.service is
requested. The rpc.svcgssd daemon is not needed for an NFS client, even
when using Kerberos security. Moreover, starting this daemon with its
default configuration will fail when no nfs/@REALM principal is in
the krb5.keytab. Furthermore, the nfs/@REALM principal is unneeded
for an NFS client configuration. Thus, resulting in a degraded system
state for NFS client configurations without nfs/@REALM principal in
the krb5.keytab.

 -- Joachim Falk   Fri, 04 Sep 2020 10:28:49 +0200

Best,

Joachim



signature.asc
Description: OpenPGP digital signature

Bug#875457: [debian-mysql] Bug#875457: Bug#875457: mariadb-server-10.1: Only supports certificates signed with SHA1 which is insecure

[Otto Kekäläinen]

control: Forwarded https://jira.mariadb.org/browse/MDEV-12190
control: Tags wontfix

Bug#964132: qgis: Please switch from sip4 to sip5

[Dmitry Shachnev]

On Mon, Sep 21, 2020 at 06:47:18PM +0200, Sebastiaan Couwenberg wrote:
> > We've already tested that it builds as proven by the package in
> > experimental.
> >
> > I don't use QGIS much, so there is not much runtime testing I can do.
>
> A quick test in an unstable VMs doesn't turn up any issues, adding an
> OSM standard layer and a BAG woonplaats WMS layer worked successfully.

Thanks a lot for confirmation!

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#850644: ITP: guix -- A functional package manager based on Scheme

[Vagrant Cascadian]

On 2020-09-21, Lucas Nussbaum wrote:
> On 17/04/20 at 17:25 -0700, Vagrant Cascadian wrote:
>> All the build-depends are packaged and may as well call this an ITP now.
>> Would still very much welcome help maintaining this, though!
>> 
>> Packaging branch updated to 1.1.0:
>> 
>>   https://salsa.debian.org/vagrant/guix
>
> Any progress on this? We are considering deploying GUIX at $DAY_JOB and
> I was wondering if this package could serve as a basis.

Been struggling with the test suites, which make some guix specific
assumptions and various other failures. Last I tried the packaging
branch above it did actually work (with the test suite results ignored),
but that was a while ago.

I'd like to transition to guile-3.0, but a blocker for that is
guile-gnutls test suite issues with recent versions of guile 3.x.

The upcoming release of guix (whenever that might be) will actually
include proper authentication of updates, which I think would be needed
for uploading to anything other than experimental.

I've been tempted to upload to experimental to try and get the NEW queue
processing going while those issues get sorted out, but haven't had a
lot of time or other excuse to work on it.

Would love to see progress on it, though, if anyone could lend a hand!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#970692: dovecot-core: fts_solr plugin failure

[Noah Meyerhans]

On Mon, Sep 21, 2020 at 07:26:59PM +0200, Raphaël Walther wrote:
> The search via the solr_plugin fails frequently on rather big accounts with 
> that error:
> Error: fts_solr: received invalid uid '0'
> 
> The search via imap timeout after 10 seconds.
> 
> "Based on the XML response above, I investigated this problem thoroughly 
> and determined that this is a pretty severe bug in the Solr XML response 
> parsing code. This occurs only when the response is rather large and the 
> boundary between two read chunks falls in the middle of a numeric value 
> (that happens to end in '0')."
> https://dovecot.org/pipermail/dovecot/2019-October/117290.html
> 
> This is fixed in 2.3.11.3+dfsg1-2

Thanks for this report.  If we're able to provide builds with this patch
backported, will you be able to validate that the issue is resolved?  If
so, we should be able to get this fixed in an upcoming buster point
release.

noah

Bug#969572: ITP: python-duniterpy - Duniter Python API

[moul]

Hi Jonas,

How are you doing with the packaging?
What steps have been done? What's left on your list?

I released a v0.58.0 which would be the last one with Python 3.5 
support.
I am planning a v0.60.0 which drops Python 3.5 and uses Scrypt from 
v3.6 standard library.


Silkaj v0.8.0 distribution to PyPI will stay on DuniterPy v0.58.x to 
keep Python 3.5 support.
Silkaj v0.8.0 package on Debian Bullseye will use DuniterPy v0.60.0 
since Python 3.8 is used from Debian.


Regarding DuniterPy v0.60.0, is there any requirement or wish from your 
side for the packaging, for

us to include it into this release?

One thing that we need to clarify on our side is about the copyright 
and license

statements usage in the headers of every files.
In our discussion for Silkaj packaging for Debian Buster, you told me 
that this how the GPL licensing

should be used.
For our understanding, is it a requirement from Debian packaging or 
from the GPL licensing
guidelines? One answer can be that Debian packaging requires to follow 
the licenses guidelines.

Can you confirm that these statements have to be prepend to every file?
The runtime source code should have them of course. Does the tests and 
the examples should also have those

statements?
Does the tests and the examples will be distributed in the package?
The related ticket: 



DuniterPy v0.60.0 is the release which should be packaged in Debian 
Bullseye. Of course, we can make

v0.60.x releases if necessary.

Best regards,
Maël

Bug#875457: [debian-mysql] Bug#875457: mariadb-server-10.1: Only supports certificates signed with SHA1 which is insecure

[Otto Kekäläinen]

Forwarded: https://jira.mariadb.org/browse/MDEV-12190
Tags: wontfix

This is due to use of YaSSL (nowadays called WolfSSL).
This will not be fixed for MariaDB 10.1 or older.

A summary about various TLS issues for WolfSSL/MariaDB in Debian is
listed at https://jira.mariadb.org/browse/MDEV-23772

Contributions are welcome to at least get the TLS testing automated so
all regressions would be quick to spot.

Bug#970444: Can't connect to httpd stream on MPD

[kaliko]

Hi James

Le 21/09/2020 à 17:29, James Klaas a écrit :
> On Mon, 21 Sep 2020 16:04:31 +0200 kaliko  wrote:
> This doesn't count?
> ---
> audio_output {
>   type"httpd"
>   name"My HTTP Stream"
>   encoder "vorbis"# optional, vorbis or lame
>   port"8000"
>   bind_to_address "0.0.0.0"   # optional, IPv4 or IPv6
> # quality "5.0"   # do not define if bitrate is 
> defined
>   bitrate "128"   # do not define if quality is 
> defined
>   format  "44100:16:1"
>   enabled "yes"
> # max_clients "0" # optional 0=no limit
> }
> ---
Right, mea culpa, that was eaten by my mail client I guess!

> Anyway, thank you very much for your help. This is solved for me now.

Alrigh, can you close the report then?
Just send a mail to 970444-d...@bugs.debian.org (maybe add a comment in the 
body saying
there is no actual bug regarding http stream).

Cheers & happy listening
k.

Bug#970691: please include initramfs fixes from upstream

[dann frazier]

Package: clevis-initramfs
Version: 13-2
Severity: normal
Tags: patch

I've prepared a branch that backports several fixes to the initramfs support:

  https://salsa.debian.org/dannf/clevis/-/commits/v13-initramfs-fixes

Here's a summary extracted from the changelog:

  * initramfs: Fix parsing of interface names when bringing the network
back down in local-bottom, which also avoids a mess of "ip: can't find
device '/sys/class/net/$iface'" errors on the console. LP: #1896294.
  * initramfs: Warn users with multiple interfaces that they should consider
specifying an 'ip=' parameter for reliable operation. LP: #1896289.
As a side-effect, also fix interface parsing while bringing links
up. LP: #1873593.
  * initramfs: Wait for interface to appear before attempting configuration.
LP: #1873914.

The first change is already in v14 upstream, the others aren't yet in
an upstream release. Please consider merging :)

Bug#969804: Bug#969804: bart: autopkgtest should be marked superficial

[Uecker, Martin]

Am Montag, den 21.09.2020, 17:57 +0200 schrieb Andreas Tille:
> On Mon, Sep 21, 2020 at 05:30:20PM +0200, Andreas Tille wrote:
> > 
> > May be I misunderstood you - but if you do not run the test at all
> > (as done in some architectures) how will you know whether the test
> > might fail?  May be I miss your point here and thus I implemented
> > my suggestion and we'll see what happends on the buildd logs soon.

Thank you! No, I meant running the tests but ignoring the results,
so exactly what you implemented!

> For instance
> 
>    
> https://buildd.debian.org/status/fetch.php?pkg=bart=i386=0.6.00-3=1600702554
> =0
> 
> has
> 
> ...
> ./test_linop_matrix 
>  ./test_linop_matrix:  4/ 4 passed.
> ./test_linop 
>  [31mERROR: ./test_linop:  2/ 3 passed.
>  [0mmake[3]: *** [Makefile:685: utests-all] Error 1
> make[3]: Leaving directory '/<>'
> make[2]: *** [Makefile:273: utest] Error 2
> 
> 
> --> I guess access to i386 should be simple.  You can either use
> qemu or may be the issue can be even reproduced in an i386
> pbuilder chroot

Yes, I think this is a problem I looked at before. Essentially
the floating point computation has a bigger error for some
reason. But I did not have to time to get on the bottom of it.

What would be really useful is to get bug reports for
failing tests which are not critical.

> 
> The s390x build
> 
> 
> https://buildd.debian.org/status/fetch.php?pkg=bart=s390x=0.6.00-3=1600702311
> aw=0
> 
> has the know issue.
> 
> So at least the logs do not hide the issues that might be worth
> investigating or not.

Yes, this is useful. I will try to change the tests so that a
failing test outputs more information.

Best,
Martin

Bug#970688: rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/i386-linux-gnu/libncurses.so.6)

[Sven Joachim]

On 2020-09-21 18:39 +0200, Rene Engelhard wrote:

> Hi,
>
> Am 21.09.20 um 18:34 schrieb Sven Joachim:
>> Control: reassign -1 cowdancer
>> Control: forcemerge 970555 -1
>>
>> On 2020-09-21 17:53 +0200, Rene Engelhard wrote:
>>
>>> Package: libtinfo6
>>> Version: 6.2+20200918-1
>>> Severity: serious
>>>
>>> Hi,
>>>
>>> in a (dist-|cowbuilder ) upgrade  of my i386 chroot:
>>>
>>> Preparing to unpack .../libncursesw6_6.2+20200918-1_i386.deb ...
>>> Unpacking libncursesw6:i386 (6.2+20200918-1) over (6.2-1) ...
>>> Preparing to unpack .../libncurses6_6.2+20200918-1_i386.deb ...
>>> Unpacking libncurses6:i386 (6.2+20200918-1) over (6.2-1) ...
>>> rm: /lib/i386-linux-gnu/libtinfo.so.6: version
>>> `NCURSES6_TINFO_6.2.current' not found (required by
>>> /lib/i386-linux-gnu/libncurses.so.6)
>>> dpkg: error while cleaning up:
>>>  rm command for cleanup subprocess returned error exit status 1
>>> dpkg-split: /lib/i386-linux-gnu/libtinfo.so.6: version
>>> `NCURSES6_TINFO_6.2.current' not found (required by
>>> /lib/i386-linux-gnu/libncurses.so.6)
>>> rm: /lib/i386-linux-gnu/libtinfo.so.6: version
>>> `NCURSES6_TINFO_6.2.current' not found (required by
>>> /lib/i386-linux-gnu/libncurses.so.6)
>>> dpkg: error processing archive 
>>> /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb (--unpack):
>>>  rm command for cleanup subprocess returned error exit status 1
>>> Errors were encountered while processing:
>>>  /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb
>>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>>> I: Copying back the cached apt archive contents
>>> I: unmounting /home filesystem
>>> I: unmounting dev/ptmx filesystem
>>> I: unmounting dev/pts filesystem
>>> I: unmounting dev/shm filesystem
>>> I: unmounting proc filesystem
>>> I: unmounting sys filesystem
>>> E: pbuilder update failed
>>> E: could not update with cowdancer, try --no-cowdancer-update option
>> Please follow that advice, see #970555 for details.
>
> I've seen that bug in the meanwhile.
>
>
> But interestingly it also failed with;
>
> $ cowbuilder login --basepath  etc.
> [...]
> # apt update
> # apt dist-upgrade
>
> [1] (which I often do) which wouldn't mean not doing a cowdancer update
> would have worked around it? Or do I miss something?

I don't use cowbuilder myself, but the problem is that cowdancer brings
libncurses.so.6 into every started program via its LD_PRELOAD
(--no-cowdancer-update avoids that, AIUI).

This affects programs run internally by dpkg ('rm' in this case), that
is why you are seeing this problem, although libncurses6 and libtinfo6
are unpacked in the same dpkg run and neither of them have maintainer
scripts.

Cheers,
   Sven

Bug#970688: rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/i386-linux-gnu/libncurses.so.6)

[Rene Engelhard]

Hi,

Am 21.09.20 um 18:34 schrieb Sven Joachim:
> Control: reassign -1 cowdancer
> Control: forcemerge 970555 -1
>
> On 2020-09-21 17:53 +0200, Rene Engelhard wrote:
>
>> Package: libtinfo6
>> Version: 6.2+20200918-1
>> Severity: serious
>>
>> Hi,
>>
>> in a (dist-|cowbuilder ) upgrade  of my i386 chroot:
>>
>> Preparing to unpack .../libncursesw6_6.2+20200918-1_i386.deb ...
>> Unpacking libncursesw6:i386 (6.2+20200918-1) over (6.2-1) ...
>> Preparing to unpack .../libncurses6_6.2+20200918-1_i386.deb ...
>> Unpacking libncurses6:i386 (6.2+20200918-1) over (6.2-1) ...
>> rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
>> not found (required by /lib/i386-linux-gnu/libncurses.so.6)
>> dpkg: error while cleaning up:
>>  rm command for cleanup subprocess returned error exit status 1
>> dpkg-split: /lib/i386-linux-gnu/libtinfo.so.6: version 
>> `NCURSES6_TINFO_6.2.current' not found (required by 
>> /lib/i386-linux-gnu/libncurses.so.6)
>> rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
>> not found (required by /lib/i386-linux-gnu/libncurses.so.6)
>> dpkg: error processing archive 
>> /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb (--unpack):
>>  rm command for cleanup subprocess returned error exit status 1
>> Errors were encountered while processing:
>>  /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> I: Copying back the cached apt archive contents
>> I: unmounting /home filesystem
>> I: unmounting dev/ptmx filesystem
>> I: unmounting dev/pts filesystem
>> I: unmounting dev/shm filesystem
>> I: unmounting proc filesystem
>> I: unmounting sys filesystem
>> E: pbuilder update failed
>> E: could not update with cowdancer, try --no-cowdancer-update option
> Please follow that advice, see #970555 for details.

I've seen that bug in the meanwhile.


But interestingly it also failed with;

$ cowbuilder login --basepath  etc.
[...]
# apt update
# apt dist-upgrade

[1] (which I often do) which wouldn't mean not doing a cowdancer update
would have worked around it? Or do I miss something?


Regards,


Rene


[1] yes, that doesn't retain the upgrade but this was a one-shot build
for an upstream anyway.

Bug#964132: qgis: Please switch from sip4 to sip5

[Sebastiaan Couwenberg]

On 9/21/20 5:16 PM, Sebastiaan Couwenberg wrote:
> On 9/21/20 5:10 PM, Dmitry Shachnev wrote:
>> On Mon, Sep 21, 2020 at 04:44:06PM +0200, Sebastiaan Couwenberg wrote:
 But SIP 6 won't be released before Qt 6, which is expected in the beginning
 of 2021.
>>>
>>> Are there any packagers for Qt 6 yet? If not, we'll have qt5 in Debian
>>> for quite awhile still.
>>
>> SIP doesn't depend on Qt, just the upstream SIP/PyQt6 developer wants
>> to coordinate his release schedule with Qt.
>>
>>> Your patches to the upstream buildsystem have been been added to the
>>> master branch on salsa as well. They will be included in the next upload
>>> which likely won't happen before 3.10.10+dfsg-1 migrates to testing, at
>>> the latest when 3.10.11 is released next month.
>>>
>>> Once PyQt5 is moved to unstable, the changes for (build) dependencies
>>> will be adopted on the master branch as well.
>>
>> Can I ask you to test the current QGIS package from unstable with PyQt5
>> 5.15.1 from experimental?
>>
>> I could do it myself, but you know this package more so can probably perform
>> more extensive testing.
> 
> We've already tested that it builds as proven by the package in
> experimental.
> 
> I don't use QGIS much, so there is not much runtime testing I can do.

A quick test in an unstable VMs doesn't turn up any issues, adding an
OSM standard layer and a BAG woonplaats WMS layer worked successfully.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#970688: rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/i386-linux-gnu/libncurses.so.6)

[Sven Joachim]

Control: reassign -1 cowdancer
Control: forcemerge 970555 -1

On 2020-09-21 17:53 +0200, Rene Engelhard wrote:

> Package: libtinfo6
> Version: 6.2+20200918-1
> Severity: serious
>
> Hi,
>
> in a (dist-|cowbuilder ) upgrade  of my i386 chroot:
>
> Preparing to unpack .../libncursesw6_6.2+20200918-1_i386.deb ...
> Unpacking libncursesw6:i386 (6.2+20200918-1) over (6.2-1) ...
> Preparing to unpack .../libncurses6_6.2+20200918-1_i386.deb ...
> Unpacking libncurses6:i386 (6.2+20200918-1) over (6.2-1) ...
> rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
> not found (required by /lib/i386-linux-gnu/libncurses.so.6)
> dpkg: error while cleaning up:
>  rm command for cleanup subprocess returned error exit status 1
> dpkg-split: /lib/i386-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/i386-linux-gnu/libncurses.so.6)
> rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
> not found (required by /lib/i386-linux-gnu/libncurses.so.6)
> dpkg: error processing archive 
> /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb (--unpack):
>  rm command for cleanup subprocess returned error exit status 1
> Errors were encountered while processing:
>  /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> I: Copying back the cached apt archive contents
> I: unmounting /home filesystem
> I: unmounting dev/ptmx filesystem
> I: unmounting dev/pts filesystem
> I: unmounting dev/shm filesystem
> I: unmounting proc filesystem
> I: unmounting sys filesystem
> E: pbuilder update failed
> E: could not update with cowdancer, try --no-cowdancer-update option

Please follow that advice, see #970555 for details.

Cheers,
   Sven

Bug#970689: live-build: fails when lilo can't be installed, even if unused

[Witold Baryluk]

Package: live-build
Version: 1:20191221
Severity: important
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

I am using lb this way:L

sudo 
--preserve-env=DEBIAN_FRONTEND,APT_LISTCHANGES,NEEDRESTART_MODE,NEEDRESTART_SUSPEND,DEBIAN_FRONT
 \
  lb config \
  --apt-recommends true \
  --archive-areas "main non-free contrib" \
  --binary-images iso-hybrid \
  --backports false \
  --bootloaders syslinux \
  --debconf-priority critical \
  --debian-installer live \
  --debian-installer-gui true \
  --distribution bullseye \
  --security false \
  --zsync false \
  --bootappend-live "intel_iommu=on iommu=pt radeon.si_support=0 
amdgpu.si_support=1 amdgpu.ppfeaturemask=0x boot=live components 
locales=en_US.UTF-8"




Yet, `lb build` fails because it tries to install package lilo, which is
at the moment not available in Debian testing (removed due to ftbfs with
gcc-10). I don't need lilo in this build, so lb build shouldn't even
attempt to install it.

I am building iso image image, so I need to use syslinux (which is a
default for iso-hybrid anyway). I don't think grub-efi would work on iso?

I don't know why lb build is trying to install (and then remove) lilo.


-- Package-specific info:

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages live-build depends on:
ii  debootstrap  1.0.123

Versions of packages live-build recommends:
ii  apt-utils   2.1.7
ii  bzip2   1.0.8-3
ii  cpio2.13+dfsg-2
ii  file1:5.38-5
ii  live-boot-doc   1:20190614
ii  live-config-doc 11.0.1
ii  live-manual-html [live-manual]  2:20151217.1
ii  wget1.20.3-1+b3
ii  xz-utils5.2.4-1+b1

Versions of packages live-build suggests:
ii  e2fsprogs  1.45.6-1
ii  mtd-utils  1:2.1.1-1.1
ii  parted 3.3-4

-- no debconf information

Bug#962597: [debian-mysql] Bug#962597: Bug#962597: libmariadb3: Install caching_sha2_password.so

[Otto Kekäläinen]

Current mariadb-10.5 soon in to be uploaded to Debian unstable:

cat debian/libmariadb3.install
# sha256_password not supported by GnuTLS due to missing OAEP padding
usr/lib/*/libmariadb.so.*
usr/lib/*/libmariadb3/plugin/caching_sha2_password.so
usr/lib/*/libmariadb3/plugin/client_ed25519.so
usr/lib/*/libmariadb3/plugin/dialog.so
usr/lib/*/libmariadb3/plugin/mysql_clear_password.so

Bug#970688: rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/i386-linux-gnu/libncurses.so.6)

[Rene Engelhard]

Package: libtinfo6
Version: 6.2+20200918-1
Severity: serious

Hi,

in a (dist-|cowbuilder ) upgrade  of my i386 chroot:

$ sudo cowbuilder --update --basepath /var/cache/pbuilder/base.cow.i386/ 
--bindmounts /home
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.26407
I: forking: cp -al /var/cache/pbuilder/base.cow.i386 
/var/cache/pbuilder/build/cow.26407
I: unlink for ilistfile /var/cache/pbuilder/build/cow.26407/.ilist failed, it 
didn't exist?
I: Invoking pbuilder
I: forking: pbuilder update --bindmounts /home --buildplace 
/var/cache/pbuilder/build/cow.26407 --mirror http://deb.debian.org/debian/ 
--distribution sid --no-targz --internal-chrootexec 'chroot 
/var/cache/pbuilder/build/cow.26407 cow-shell'
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: Current time: Mon Sep 21 17:48:08 CEST 2020
I: pbuilder-time-stamp: 1600703288
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage for 
details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: Mounting /home
I: policy-rc.d already exists
I: Refreshing the base.tgz
I: upgrading packages
Get:1 http://deb.debian.org/debian sid InRelease [146 kB]
Get:2 http://deb.debian.org/debian sid/main i386 Packages.diff/Index [27.9 kB]
Ign:2 http://deb.debian.org/debian sid/main i386 Packages.diff/Index
Get:3 http://deb.debian.org/debian sid/main i386 Packages [8322 kB]
Fetched 8496 kB in 4s (1935 kB/s)
Reading package lists...
I: Obtaining the cached apt archive contents
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  apt aptitude aptitude-common bash binutils binutils-common 
binutils-i686-linux-gnu bsdutils cpp cpp-10 debianutils g++ g++-10 gcc gcc-10 
gcc-10-base gcc-9-base
  libapt-pkg6.0 libasan6 libatomic1 libbinutils libblkid1 libc-bin libc-dev-bin 
libc6 libc6-dev libcc1-0 libcrypt-dev libcrypt1 libctf-nobfd0 libctf0 
libdebconfclient0
  libgcc-10-dev libgcc-s1 libgdbm-compat4 libgdbm6 libgnutls30 libgomp1 libitm1 
libmount1 libmpc3 libncurses6 libncursesw6 libp11-kit0 libquadmath0 libseccomp2
  libsmartcols1 libsqlite3-0 libstdc++-10-dev libstdc++6 libsystemd0 libtinfo6 
libubsan1 libudev1 libuuid1 libxapian30 libzstd1 linux-libc-dev mount 
ncurses-base
  ncurses-bin sysvinit-utils util-linux
63 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/69.4 MB of archives.
After this operation, 584 kB of additional disk space will be used.
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 12421 files and directories currently installed.)
Preparing to unpack .../debianutils_4.11.1_i386.deb ...
Unpacking debianutils (4.11.1) over (4.11) ...
Setting up debianutils (4.11.1) ...
(Reading database ... 12421 files and directories currently installed.)
Preparing to unpack .../archives/bash_5.0-7_i386.deb ...
Unpacking bash (5.0-7) over (5.0-6) ...
Setting up bash (5.0-7) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide 
/usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
(Reading database ... 12421 files and directories currently installed.)
Preparing to unpack .../bsdutils_1%3a2.36-3_i386.deb ...
Unpacking bsdutils (1:2.36-3) over (1:2.35.2-9) ...
Setting up bsdutils (1:2.36-3) ...
(Reading database ... 12421 files and directories currently installed.)
Preparing to unpack .../libcrypt-dev_1%3a4.4.17-1_i386.deb ...
Unpacking libcrypt-dev:i386 (1:4.4.17-1) over (1:4.4.16-1) ...
Preparing to unpack .../libc6-dev_2.31-3_i386.deb ...
Unpacking libc6-dev:i386 (2.31-3) over (2.31-2) ...
Preparing to unpack .../libc-dev-bin_2.31-3_i386.deb ...
Unpacking libc-dev-bin (2.31-3) over (2.31-2) ...
Preparing to unpack .../libcrypt1_1%3a4.4.17-1_i386.deb ...
Unpacking libcrypt1:i386 (1:4.4.17-1) over (1:4.4.16-1) ...
Setting up libcrypt1:i386 (1:4.4.17-1) ...
(Reading database ... 12424 files and directories currently installed.)
Preparing to unpack .../0-linux-libc-dev_5.8.10-1_i386.deb ...
Unpacking linux-libc-dev:i386 (5.8.10-1) over (5.7.6-1) ...
Preparing to unpack .../1-libcc1-0_10.2.0-9_i386.deb ...
Unpacking libcc1-0:i386 (10.2.0-9) over (10.1.0-6+b1) ...
Preparing to unpack .../2-libctf0_2.35-3_i386.deb ...
Unpacking libctf0:i386 (2.35-3) over (2.34.90.20200706-1) ...
Preparing to unpack .../3-libctf-nobfd0_2.35-3_i386.deb ...
Unpacking libctf-nobfd0:i386 (2.35-3) over (2.34.90.20200706-1) ...
Preparing to unpack .../4-binutils-i686-linux-gnu_2.35-3_i386.deb ...
Unpacking binutils-i686-linux-gnu (2.35-3) over (2.34.90.20200706-1) ...
Preparing to unpack .../5-libbinutils_2.35-3_i386.deb ...
Unpacking libbinutils:i386 (2.35-3) over (2.34.90.20200706-1) ...
Preparing to unpack .../6-binutils-common_2.35-3_i386.deb ...
Unpacking binutils-common:i386 (2.35-3) over 

Bug#970672: nftables dnat port range

[Igor M]

Done:

+++-==-===--==
ii  nftables   0.9.6-1~bpo10+1 amd64Program to control packet
filtering rules by Netfilter project

But problem still exist

пн, 21 вер. 2020 о 13:20 Arturo Borrero Gonzalez  пише:

>
>
> On 2020-09-21 11:12, Igor M wrote:
> > apt search -t testing nftables
> > ...
> > nftables/testing,unstable 0.9.6-1 amd64 [upgradable from: 0.9.0-2]
> >
> > did you mean this version?
> >
>
> Yes, or even better:
>
>  buster-backports: 0.9.6-1~bpo10+1
>

Bug#970678: Network preseeding using http is broken

[Martin Samuelsson]

Geert Stappers @ 2020-09-21 (Monday), 17:18 (+0200)


Under which circumstance does the bug shows itself?


As far as I understand /dev/fd seems to be completely missing. Haven't dug 
into it. For what its worth, it seems /proc/self/fd is still available. I 
did experiment with redirecting sed there instead before realizing it wasn't 
really necessary to retain wget's output.

--
/Martin

Bug#969804: Bug#969804: bart: autopkgtest should be marked superficial

[Andreas Tille]

On Mon, Sep 21, 2020 at 05:30:20PM +0200, Andreas Tille wrote:
> 
> May be I misunderstood you - but if you do not run the test at all
> (as done in some architectures) how will you know whether the test
> might fail?  May be I miss your point here and thus I implemented
> my suggestion and we'll see what happends on the buildd logs soon.

For instance

   
https://buildd.debian.org/status/fetch.php?pkg=bart=i386=0.6.00-3=1600702554=0

has

...
./test_linop_matrix 
 ./test_linop_matrix:  4/ 4 passed.
./test_linop 
 [31mERROR: ./test_linop:  2/ 3 passed.
 [0mmake[3]: *** [Makefile:685: utests-all] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:273: utest] Error 2


--> I guess access to i386 should be simple.  You can either use
qemu or may be the issue can be even reproduced in an i386
pbuilder chroot


The s390x build


https://buildd.debian.org/status/fetch.php?pkg=bart=s390x=0.6.00-3=1600702311=0

has the know issue.

So at least the logs do not hide the issues that might be worth
investigating or not.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#970606: [Openjdk] Bug#970606: src:openjdk-*: autopkgtest times out on Debian/Ubuntu infrastructure

[Paul Gevers]

Hi Matthias,

On 21-09-2020 11:43, Matthias Klose wrote:
> I don't think that referring to the Ubuntu autopkg testers is helping here.  I
> couldn't find any documentation on the timeout settings for the Debian
> infrastructure, for both amd64 and arm64.

$(man autopkgtest) has a section about timeouts. The defaults apply to
the Debian infrastructure and I think to the Ubuntu infrastructure as well:
"""
There are five timeouts affected by five values of which: short:
supposedly short operations like setting up the testbed's  apt  and
checking  the  state  (default: 100s);  install:  installation  of
packages  including  dependencies (default: 3,000s); test: test runs
(default: 10,000s); copy: copy files/directories between host and
testbed  (default:  300s);  and  build:  builds  (default: 100,000s).
"""

> I think it would help to document
> these constraints (and yes, Ubuntu doesn't document those either).

Where are you missing the info? I'll happily file bugs to request
inclusion of the information.

> Apparently
> the very same tests don't time out on the buildds.

I don't know what timeouts apply to buildds, but indeed I think they are
much higher to cope with *building* some extremely big packages.

> Unsure if you want to track that under the release.d.o meta issue.

Don't think there is anything to do there, unless you consider that a
place where documentation is missing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#969048: smartmontools: Update systemd unit file (StandardOutput=syslog)

[Christian Franke]

Fixed upstream in r5077: https://www.smartmontools.org/changeset/5077

BTW: https://www.smartmontools.org/changeset/5078

Bug#970678: Network preseeding using http is broken

[Martin Samuelsson]

Philip Hands @ 2020-09-21 (Monday), 15:30 (+0200)

Martin Samuelsson  writes:

Just to be clear on this point, are you saying [...]


I'm saying there is no /dev/fd/ at all on current daily debian-installer 
images and hasn't been since at least 20200818 (which was the oldest one I 
could try with current kernel modules).


Missing fd:s is the root cause, and a different issue which I hope someone 
else is addressing in case it is a bug. (Nothing else in d-i failed for me 
due to it.)



To illustrate this, here's some output from busybox shell, running on my
laptop:


Yet those examples are not from the context of a recent debian-installer 
nightly image, right? 


If you noticed that it's not there when e.g. simply listing the contents
of /dev/fd then that's normal AFAIK.


The issue I reported is that wget404() is unnecessarily complex and fragile, 
for no reasonable reason. (You've stated so yourself in the README.wget404)


A suggested fix for /usr/lib/fetch-url/http looks as below:

--- http.orig   2020-09-21 17:21:24.159480072 +0200
+++ http.simplified 2020-09-21 17:21:03.951356698 +0200
@@ -14,10 +14,10 @@

local RETVAL=$( {
echo 1
-   wget "$@" 2>&1 >&3 && echo %OK%
+   wget "$@" 2>&1 && echo %OK%
echo %EOF%
-   } | ( sed -ne 
'1{h;d};/'"$file_not_found_pattern"'/{p;s/.*/4/;h;d};/^%OK%$/{s/.*/0/;h;d};$!p;$x;$w 
/dev/fd/4' >&2 ) 4>&1
-   ) 3>&1
+   } | ( sed -ne 
'1{h;d};/'"$file_not_found_pattern"'/{p;s/.*/4/;h;d};/^%OK%$/{s/.*/0/;h;d};$!p;$x;$p 
'>&2 )
+		) 
		return $RETVAL

}

I just tried patching as above at the first of the interactive debug prompts 
when setting the DEBUG bootflag high. Installation succeeded, and fetch-url 
still returns 0 on success, 1 on general failure and 4 on http not found.  
The only difference is that any output from wget is discarded already inside 
wget404() rather than by the call to wget404().


It seems me mentioning the issue on irc made you fix typos in the README.  
The preservation of wget's stdout and stderr looks fenomenal, but it fills 
no practical purpose. Please consider killing your darling. Simple code is 
beautiful and robust code.

--
/Martin

Bug#966922: libnitrokey: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

[Jan Luca Naumann]

Hey Scott,

since nitrokey-app has been kickout of testing today, I want to ask
about the update? Do you need some help I could offer?

Best,
Jan

Am 21.08.20 um 00:01 schrieb Scott Kitterman:
> I will take care of it.  The removal isn't scheduled for almost a month, so 
> there is plenty of time.
> 
> Scott K
> 
> On Thursday, August 20, 2020 12:28:17 PM EDT Jan Luca Naumann wrote:
>> Hey Scott,
>>
>> could you update the package? Since this is marked as RC bug,
>> libnitrokey and all depending packages are kicked out of testing.
>>
>> Best,
>> Jan
>>
>> On Mon, 03 Aug 2020 13:54:57 + Scott Kitterman
>>
>>  wrote:
>>> This is probably a result of a new GCC version.  C++ symbols can be
>>> painful to manage.  This will be trivial to update the next time I update
>>> the package.
>>>
>>> Scott K
>>>
>>> On August 3, 2020 9:15:16 AM UTC, Szczepan Zalega | Nitrokey 
>  wrote:
 On 8/3/20 10:41 AM, Lucas Nussbaum wrote:
> (optional=templinst|arch=!amd64 !arm64 !x32)
> (optional=templinst)

 Hi!

 As far as I see the problem comes from the listing format difference,
 not the actual symbol change.

 E.g.:
 ```
 - (optional=templinst|arch=!amd64 !arm64
 !x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14Dev
 iceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx1
 1Ei@Base 3.5
 +
 (optional=templinst)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandID
 E65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translat
 e_commandB5cxx11Ei@Base 3.5
 ```
> 

Bug#970620: Subject: RFS: libwcat1/1.1-3 [ITA] -- Process monitoring library

[Tobias Frost]

Hi Georgy,

(I'll delete the sections which has been handled, to keep the mail
uncluttered)

On Sun, Sep 20, 2020 at 05:35:47PM +0300, Georgy Komarov wrote:
Control: tags -1 moreinfo
# taking care of this sponsorship until uploaded.
Control: owner -1 !

> 
> Hello Tobias,
> 
> > - d/copyright: 
(with Cyrils OK ✔)

> > - The package needs to be adapted for multiarch: It needs to install the
> > shared libaries to /usr/lib/${DEB_HOST_MULTIARCH}/

you should could /usr/lib/${DEB_HOST_MULTIARCH}/ instead
of /usr/lib/*/ in d/install…. This is possible since compat 13)

Ok. Lintian is a bit sad:

I: libwcat1: hardening-no-bindnow usr/lib/x86_64-linux-gnu/libwcat.so.1.1.1
(It seems that LDFLAGS is not passed to the linker)

I: libwcat1: hardening-no-fortify-functions 
usr/lib/x86_64-linux-gnu/libwcat.so.1.1.1
(possibly a false positive)
 
I: libwcat1: package-contains-empty-directory usr/include/
(reason: listed in d/libwcat1.install)

I: libwcat1 source: patch-not-forwarded-upstream 
debian/patches/0001-Makefile-do-not-strip.patch
I: libwcat1 source: patch-not-forwarded-upstream 
debian/patches/0002-Makefile-add-libdir.patch
(add a Forwarded header, possibly with not-needed or Debian-specific)

I: libwcat1: symbols-file-missing-build-depends-package-field
(see tag description, not evaluted further)

X: libwcat1 source: debian-watch-does-not-check-gpg-signature
(irrelevant, just ignore it)

P: libwcat1 source: insecure-copyright-format-uri 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
(easy to fix.)

P: libwcat1 source: silent-on-rules-requiring-root
(see policy §5.6.31)

So not much left before uploading … Ping me when ready!
> 
> > (not a requirement for upload of this package:
> > The library package has also a companion tool package: watchcatd [1].
> > It is also orphaned. Would you mind adopting this too?)
> 
> Interesting. I'll take this package after I finish working on this one.

Nice! Thanks for that!


-- 
Cheers,
tobi 


signature.asc
Description: PGP signature

Bug#970444: Can't connect to httpd stream on MPD

[James Klaas]

On Mon, 21 Sep 2020 16:04:31 +0200 kaliko  wrote:
> Hi James
>
> Le 17/09/2020 à 16:52, James Klaas a écrit :
> >> Also, you need to start playing something for MPD to listen on the HTTPD 
> >> port
> >
> > but I can't even get there. Unless something has changed the way I
> > start things up is to run
> >
> > mpc add http://192.168.47.122:8000
> > mpc play
>
> I'm confused here, I suppose 192.168.47.122 is your MPD server.
> Then you cannot ask it to play itself.

This would be from the remote host. I might have tried it on the main
server, but probably not. To test from the main server I'd use curl.

> Try something like that:
>
>     # Add some tracks
>     mpc listall | head | mpc add
>     # start playing
>     mpc play

OK, this worked. I don't remember having had to do that before, but it
could be that it's been so long since I've had to do that, that I just
don't remember.

> Now if the http output is configured and enabled, mpd should stream some 
> audio on
> http://192.168.47.122:8000

Yes, it does now. Thank you. I knew it was something I was doing wrong
that was stupidly simple.

>
> You can use your browser to listen to the stream:
>
>     xdg-open http://192.168.47.122:8000
>
> > Here's my mpd.conf file:
> >
> > # An example configuration file for MPD.
> > # Read the user manual for documentation: http://www.musicpd.org/doc/user/
> > # or /usr/share/doc/mpd/user-manual.html
> > […]
>
> There is no audio_output defined in the conf you pasted!

This doesn't count?
---
audio_output {
type"httpd"
name"My HTTP Stream"
encoder "vorbis"# optional, vorbis or lame
port"8000"
bind_to_address "0.0.0.0"   # optional, IPv4 or IPv6
#   quality "5.0"   # do not define if bitrate is 
defined
bitrate "128"   # do not define if quality is 
defined
format  "44100:16:1"
enabled "yes"
#   max_clients "0" # optional 0=no limit
}
---
>
> k.
>

Anyway, thank you very much for your help. This is solved for me now.

J

Bug#969804: Bug#969804: bart: autopkgtest should be marked superficial

[Andreas Tille]

Hi Martin,

On Mon, Sep 21, 2020 at 09:26:41AM +, Uecker, Martin wrote:
> > To the best of my knowledge the fact that a test runs on amd64 but fails
> > on some other architecture is not only caused by issues in the tool
> > chain.  For instance recently I learned that for instance if char is
> > used as "very short int" it matters whether it is declared as char,
> > signed char or unsigned char.  
> 
> I know, this is also why I originally thought it would be
> a good idea.
> 
> > To spot this kind of issues it makes
> > perfectly sense to run the test suite on all architectures - except
> > for those where we expicitly know that a broken tool chain is breaking
> > the build.
> 
> If there were an easy way to log into a s390x machine
> and debug the problem, the outcome would likely be a useful
> bug report against GCC which would be useful to the community
> and the s390x port.  But as things are, it only causes
> unnecessary work for us to not get the package removed while
> we learned nothing about the underlying issue.

I *really* appreciate your attempt to get access to one of the porter
boxes and its a real shame that this procedure has turned out to be so
complicated that we gave up.

However, the solution I've just uploaded will IMHO reach approach what
you want (letting the package build) and at the same time print possible
issues inside the build logs.  I activated this for other architectures
I consider at least "interesting" (but not for all since I don't know
about potential performance issues).
 
> > Thus my suggestion to exclude only the affected s390x from the test.
> > If my suggestion is not worded clearly enough feel free to ping me and
> > I implement my suggestion in d/rules to show what I mean.
> 
> Well, the idea would be to do exactly this but pro-actively
> for all architectures except amd64. We would still get
> the information when tests fail (which is useful) but
> avoid wasting effort on fixing it each time.

May be I misunderstood you - but if you do not run the test at all
(as done in some architectures) how will you know whether the test
might fail?  May be I miss your point here and thus I implemented
my suggestion and we'll see what happends on the buildd logs soon.
 
Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#921559: MTP broken for number of phones with "LIBMTP PANIC: Unable to initialize device"

[Dominique Dumont]

Hi

I had a similar issue.

Turns out that Gnome's gvfs was locking the mtp device.

Since I run KDE, I've removed gvfs-backends package and rebooted.

I now can run mtp-detect without issue.

HTH

Bug#809997: emscripten: not installable in sid

[Jonas Smedegaard]

Quoting Sylvestre Ledru (2020-09-21 16:52:18)
> 
> Le 21/09/2020 à 16:48, Jonas Smedegaard a écrit :
> > Hi Sylvestre and others,
> >
> > I have a strong interest in getting emscripten into shape.
> >
> > I am not ready to get involved in the LLVM Packaging Team, nor do I 
> > find the current state of the package useful to work from, but I 
> > would be willing to take over maintenance if that is ok with the 
> > current maintainers.
> >
> > @Sylvestre, it seems you did all previous releases, so I guess you 
> > are qualified to decide: Would you be ok with me taking over as 
> > maintainer?
> 
> With pleasure :)
> 
> And happy to work with you on this. I will be more than happy to make 
> changes to LLVM to make your life easier if needed!

Excellent.

I'll let you know if I need anything :-)


 - 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#954794: New packages must not declare themselves Essential

[Javier Serrano Polo]

On Mon, 23 Mar 2020 08:00:04 -0700 Josh Triplett  wrote:
> This change does not propose eliminating the concept of Essential,

What is the point of Essential? To omit declaring dependencies on the
false assumption that some packages are always required by all systems;
the concept is essentially ill. Thus, if you are not pursuing the
elimination of Essential, your effort is virtually useless. Do you want
to remove Essential?

smime.p7s
Description: S/MIME cryptographic signature

Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.

[felipe]

Hey,

> For 1), do you see those QtWebEngineProcess crashes when you run
> "coredumpctl list"? If so, can you please show "coredumpctl info PID"
> with the PID from the list? If not, can you check whether you can
> reproduce them (making the entire browser crash) when you run with
> "--qt-flag single-process"?

I have attached  coredumpctl info when it crashes using --temp-basedir.

Running with:
$ qutebrowser --qt-flag single-process
[1]5850 illegal hardware instruction (core dumped)  qutebrowser 
--qt-flag single-process
The browser starts with a blank page and when I try to open any webpage, it 
crashes.

I have also attached coredumpctl of this crash.


> For 2), it looks like there's no libqt5webengine5-dbg{,sym} package in
> the debian archives. Could you check if you find them if you run e.g.
> find-dbgsym-packages on /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.14.2
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

After adding deb 'http://deb.debian.org/debian-debug/ unstable-debug main' to 
my '/etc/apt/sources.list' and installing
'libfile-slurper-perl' and 'libfile-which-perl', I find some debug symbols 
available:

$ find-dbgsym-packages 
/usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.14.2

I have attached the file 'find-dbgsym-packages.txt'


> (If there are no debug symbols available at all, I wonder if a bug should
> be opened against libqt5webengine5a - Axel/Fritz, if you have an opinion
> on that, I'd like to hear more)
> 
> If getting more info via coredumpctl didn't work, but you can reproduce
> with --qt-flag single-process, can you please do something like:
> 
>gdb -ex r --args /usr/bin/python3 -m qutebrowser --temp-basedir --qt-flag 
> single-process

$ sudo gdb -ex r --args /usr/bin/python3 -m qutebrowser --temp-basedir 
--qt-flag single-process
(No debugging symbols found in /usr/bin/python3)
Starting program: /usr/bin/python3 -m qutebrowser --temp-basedir --qt-flag 
single-process
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 12318]
[New Thread 0x7fffdd4e2700 (LWP 12329)]
12:12:36 WARNING: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
'/tmp/runtime-root'
[New Thread 0x7fffd075c700 (LWP 12332)]
[New Thread 0x7fffcff5b700 (LWP 12333)]
[New Thread 0x7fffcf75a700 (LWP 12334)]
[New Thread 0x7fffcef59700 (LWP 12335)]
[New Thread 0x7fffce758700 (LWP 12336)]
[New Thread 0x7fffcdf57700 (LWP 12337)]
[New Thread 0x7fffcd756700 (LWP 12338)]
[New Thread 0x7fffccf55700 (LWP 12339)]
[New Thread 0x7fffa700 (LWP 12340)]
[New Thread 0x7fffaf7fe700 (LWP 12341)]
[New Thread 0x7fffaeffd700 (LWP 12342)]
[New Thread 0x7fffae7fc700 (LWP 12343)]
[New Thread 0x7fffadffb700 (LWP 12344)]
[New Thread 0x7fffad7fa700 (LWP 12345)]
[New Thread 0x7fffacff9700 (LWP 12346)]
[New Thread 0x7fff8bfff700 (LWP 12347)]
[Detaching after fork from child process 12348]
[New Thread 0x7fff8b7fe700 (LWP 12349)]
[Thread 0x7fff8b7fe700 (LWP 12349) exited]
[New Thread 0x7fff8b7fe700 (LWP 12350)]
[New Thread 0x7fff8a470700 (LWP 12351)]
[New Thread 0x7fff89c6f700 (LWP 12352)]
[New Thread 0x7fff8946e700 (LWP 12353)]
[New Thread 0x7fff88c6d700 (LWP 12354)]
[New Thread 0x7fff73fff700 (LWP 12355)]
[New Thread 0x7fff737fe700 (LWP 12356)]
[New Thread 0x7fff72ffd700 (LWP 12357)]
[New Thread 0x7fff717e6700 (LWP 12358)]
[New Thread 0x7fff70fe5700 (LWP 12359)]
[New Thread 0x7fff5bfff700 (LWP 12360)]
[New Thread 0x7fff5b7fe700 (LWP 12361)]
[New Thread 0x7fff5affd700 (LWP 12362)]
[Thread 0x7fff5affd700 (LWP 12362) exited]
[New Thread 0x7fff5affd700 (LWP 12363)]
[Thread 0x7fff5affd700 (LWP 12363) exited]
[New Thread 0x7fff5affd700 (LWP 12364)]
[New Thread 0x7fff5a7fc700 (LWP 12365)]
[New Thread 0x7fff59ffb700 (LWP 12366)]
[New Thread 0x7fff597fa700 (LWP 12367)]
[Detaching after fork from child process 12368]
[New Thread 0x7fff727fc700 (LWP 12373)]
[New Thread 0x7fff71ffb700 (LWP 12374)]
[New Thread 0x7fff58a89700 (LWP 12375)]
[New Thread 0x7fff27fff700 (LWP 12376)]
[New Thread 0x7fff277fe700 (LWP 12377)]
[New Thread 0x7fff26ffd700 (LWP 12378)]
[New Thread 0x7fff267fc700 (LWP 12379)]
[New Thread 0x7fff25ffb700 (LWP 12380)]
[New Thread 0x7fff257fa700 (LWP 12381)]
[New Thread 0x7fff24ff9700 (LWP 12382)]
[New Thread 0x7fff07fff700 (LWP 12383)]
[New Thread 0x7ffef700 (LWP 12384)]
[New Thread 0x7fff077fe700 (LWP 12385)]
[New Thread 0x7fff06ffd700 (LWP 12386)]
[New Thread 0x7fff063fc700 (LWP 12387)]
--Type  for more, q to quit, c to continue without paging--


Thread 40 "Chrome_InProcRe" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fff58a89700 (LWP 12375)]
0x7fffea1b128f in 
blink::CompositedLayerMapping::ComputeBoundsOfOwningLayer(blink::PaintLayer 
const*,
blink::IntRect&, blink::IntRect&, blink::PhysicalOffset&, blink::IntPoint&) () 
from
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5

(gdb) bt
#0  

Bug#969260: closed by Debian FTP Masters (reply to Stephen Kitt ) (Bug#969260: fixed in openjfx 11.0.7+0-5~exp1)

[Stephen Kitt]

Hi Tony,

Le 21/09/2020 15:53, tony mancill a écrit :
On Mon, Sep 21, 2020 at 08:39:07AM +, Debian Bug Tracking System 
wrote:

This is an automatic notification regarding your Bug report
which was filed against the src:openjfx package:

#969260: openfjx: FTBFS (gstreamer)

It has been closed by Debian FTP Masters 
 (reply to Stephen Kitt 
).


Thank you for resolving the build issue with openjfx.

I didn't notice that GSTREAMER_LITE was defined for the autobuilders 
but

not being defined when I built the package locally (which never failed,
which made this more difficult to diagnose).

Do you know why the defines would be different in two different clean
sid chroots?  Maybe something with how gstreamer (transitive) 
dependencies are

provided?  I'd like local sbuild chroots to be as representative of the
autobuilder environments as possible.


It’s something to do with arch-specific builds; I reproduced the issue 
with


pdebuild -- --binary-arch

I didn’t spend much time trying to figure out what the difference was...


P.S.  I pushed another commit to undo the change I made to
NUM_COMPILE_THREADS in -4.  This was one of the few differences I could
see between my build environment and the autobuilders, but was a
red-herring.


I wondered about that, I didn’t try reverting it.

Regards,

Stephen

Bug#970678: Network preseeding using http is broken

[Geert Stappers]

On Mon, Sep 21, 2020 at 03:30:27PM +0200, Philip Hands wrote:
> Martin Samuelsson  writes:
> 
> > Booting the installer with DEBCONF_DEBUG=5 and debuging /bin/preseed_fetch, 
> > /bin/fetch-url and /usr/lib/fetch_url/http shows that wget404() in the 
> > latter is what's failing. It seems the pipeline fails since /dev/fd/4 does 
> > not exist.
> 
> Just to be clear on this point, are you saying that /dev/fd/4 does not
> exist when you look for it in a shell, or rather specifically when doing
> so in a context where it is in use?
> 
> If you noticed that it's not there when e.g. simply listing the contents
> of /dev/fd then that's normal AFAIK.
> 
> To illustrate this, here's some output from busybox shell, running on my
> laptop:
> 
> =-=-=-=-
> ~ $ echo /dev/fd/*
> /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/2 /dev/fd/3
> ~ $ ( echo /dev/fd/* ) 4>&1
> /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/2 /dev/fd/3 /dev/fd/4
> ~ $ ( echo /dev/fd/* ) 4>&1 5>&1
> /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/2 /dev/fd/3 /dev/fd/4 /dev/fd/5
> ~ $  ( echo /dev/fd/* ) 6>&1
> /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/2 /dev/fd/3 /dev/fd/6
> ~ $
> =-=-=-=-
> 


On Mon, Sep 21, 2020 at 02:58:36PM +0200, Philip Hands wrote:
 ...
> 
> The fact that /dev/fd/4 is missing does seem to be a separate bug, but a
> quick grep -lr suggests that this is the only place it's used in d-i, so
> perhaps a bug we need not worry about too much.
> 


Under which circumstance does the bug shows itself?



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.

[felipe]

Attachments were missings last time.
libaom0-dbgsym libasound2-dbgsym libavcodec58-dbgsym libavformat58-dbgsym 
libavutil56-dbgsym libblkid1-dbgsym libbluray2-dbgsym libbrotli1-dbgsym 
libbsd0-dbgsym libbz2-1.0-dbgsym libc6-dbg libcairo-gobject2-dbgsym 
libcairo2-dbgsym libchromaprint1-dbgsym libcodec2-0.9-dbgsym libcom-err2-dbgsym 
libdatrie1-dbgsym libdav1d4-dbgsym libdbus-1-3-dbgsym 
libdouble-conversion3-dbgsym libdrm2-dbgsym libevent-2.1-7-dbgsym 
libexpat1-dbgsym libffi7-dbgsym libfontconfig1-dbgsym libfreetype6-dbgsym 
libfribidi0-dbgsym libgcc-s1-dbgsym libgcrypt20-dbgsym 
libgdk-pixbuf2.0-0-dbgsym libgl1-dbgsym libglib2.0-0-dbgsym libglvnd0-dbgsym 
libglx0-dbgsym libgme0-dbgsym libgmp10-dbgsym libgnutls30-dbgsym 
libgomp1-dbgsym libgpg-error0-dbgsym libgraphite2-3-dbgsym libgsm1-dbgsym 
libharfbuzz0b-dbgsym libhogweed6-dbgsym libicu67-dbgsym libidn2-0-dbgsym 
libjpeg62-turbo-dbgsym libkeyutils1-dbgsym libkrb5-dbg liblcms2-2-dbgsym 
liblz4-1-dbgsym liblzma5-dbgsym libmd4c0-dbgsym libmfx1-dbgsym 
libminizip1-dbgsym libmount1-dbgsym libmp3lame0-dbgsym libmpg123-0-dbgsym 
libnettle8-dbgsym libnorm1-dbgsym libnspr4-dbgsym libnss3-dbgsym 
libnuma1-dbgsym libogg-dbg libopenjp2-7-dbgsym libopenmpt0-dbgsym libopus-dbg 
libp11-kit0-dbgsym libpango-1.0-0-dbgsym libpangocairo-1.0-0-dbgsym 
libpangoft2-1.0-0-dbgsym libpcre2-16-0-dbgsym libpcre2-8-0-dbgsym libpcre3-dbg 
libpgm-5.2-0-dbgsym libpixman-1-0-dbgsym libpng16-16-dbgsym libqt5core5a-dbgsym 
libqt5gui5-dbgsym libqt5network5-dbgsym libqt5positioning5-dbgsym 
libqt5qml5-dbgsym libqt5qmlmodels5-dbgsym libqt5quick5-dbgsym 
libqt5test5-dbgsym libqt5webchannel5-dbgsym libqt5webengine5-dbgsym 
libqt5webenginecore5-dbgsym librabbitmq4-dbgsym libre2-8-dbgsym 
librsvg2-2-dbgsym libselinux1-dbgsym libshine3-dbgsym libsnappy1v5-dbgsym 
libsodium23-dbgsym libsoxr0-dbgsym libspeex-dbg libsrt1-gnutls-dbgsym 
libssh-gcrypt-4-dbgsym libssl1.1-dbgsym libstdc++6-dbgsym libswresample3-dbgsym 
libsystemd0-dbgsym libtasn1-6-dbgsym libthai0-dbgsym libtheora0-dbgsym 
libtwolame0-dbgsym libunistring2-dbgsym libuuid1-dbgsym libva-drm2-dbgsym 
libva-x11-2-dbgsym libva2-dbgsym libvdpau1-dbgsym libvorbis0a-dbgsym 
libvorbisenc2-dbgsym libvorbisfile3-dbgsym libvpx6-dbgsym libwavpack1-dbgsym 
libwebp6-dbgsym libwebpdemux2-dbgsym libwebpmux3-dbgsym libx11-6-dbgsym 
libx264-160-dbgsym libx265-192-dbgsym libxau6-dbg libxcb-render0-dbgsym 
libxcb-shm0-dbgsym libxcb1-dbgsym libxcomposite1-dbgsym libxdamage1-dbgsym 
libxdmcp6-dbg libxext6-dbg libxfixes3-dbgsym libxml2-dbgsym libxrender1-dbgsym 
libxslt1.1-dbgsym libxss1-dbgsym libxvidcore4-dbgsym libzmq5-dbgsym 
libzstd1-dbgsym libzvbi0-dbgsym ocl-icd-libopencl1-dbgsym zlib1g-dbgsym
   PID: 5850 (qutebrowser)
   UID: 1000 (felipe)
   GID: 1000 (felipe)
Signal: 4 (ILL)
 Timestamp: Mon 2020-09-21 11:41:40 -03 (39s ago)
  Command Line: /usr/bin/python3 /usr/bin/qutebrowser --qt-flag single-process
Executable: /usr/bin/python3.8
 Control Group: /user.slice/user-1000.slice/session-1.scope
  Unit: session-1.scope
 Slice: user-1000.slice
   Session: 1
 Owner UID: 1000 (felipe)
   Boot ID: 8a493cc1f411446a9c0bc0e0d42580f6
Machine ID: 70dd67e312f741bc93a178be9523797f
  Hostname: fx8350
   Storage: 
/var/lib/systemd/coredump/core.qutebrowser.1000.8a493cc1f411446a9c0bc0e0d42580f6.5850.16006993.zst
   Message: Process 5850 (qutebrowser) of user 1000 dumped core.

Stack trace of thread 5894:
#0  0x7f4c837b3fe1 raise (libpthread.so.0 + 0x13fe1)
#1  0x7f4c837b4140 __restore_rt (libpthread.so.0 + 0x14140)
#2  0x7f4c757c928f n/a (libQt5WebEngineCore.so.5 + 
0x462928f)
#3  0x7f4c757d4054 n/a (libQt5WebEngineCore.so.5 + 
0x4634054)
#4  0x7f4c757d6561 n/a (libQt5WebEngineCore.so.5 + 
0x4636561)
#5  0x7f4c757d64ca n/a (libQt5WebEngineCore.so.5 + 
0x46364ca)
#6  0x7f4c757d64ca n/a (libQt5WebEngineCore.so.5 + 
0x46364ca)
#7  0x7f4c757d64ca n/a (libQt5WebEngineCore.so.5 + 
0x46364ca)
#8  0x7f4c757d64ca n/a (libQt5WebEngineCore.so.5 + 
0x46364ca)
#9  0x7f4c757d66bd n/a (libQt5WebEngineCore.so.5 + 
0x46366bd)
#10 0x7f4c757d6b3d n/a (libQt5WebEngineCore.so.5 + 
0x4636b3d)
#11 0x7f4c757d80d0 n/a (libQt5WebEngineCore.so.5 + 
0x46380d0)
#12 0x7f4c757d8409 n/a (libQt5WebEngineCore.so.5 + 
0x4638409)
#13 0x7f4c751d9377 n/a (libQt5WebEngineCore.so.5 + 
0x4039377)
#14 0x7f4c751e39d9 n/a (libQt5WebEngineCore.so.5 + 
0x40439d9)
#15 0x7f4c751e3e14 n/a (libQt5WebEngineCore.so.5 + 
0x4043e14)
#16 0x7f4c75771564 n/a (libQt5WebEngineCore.so.5 + 
0x45d1564)
#17 0x7f4c7512f16c n/a (libQt5WebEngineCore.so.5 

Bug#964132: qgis: Please switch from sip4 to sip5

[Sebastiaan Couwenberg]

On 9/21/20 5:10 PM, Dmitry Shachnev wrote:
> On Mon, Sep 21, 2020 at 04:44:06PM +0200, Sebastiaan Couwenberg wrote:
>>> But SIP 6 won't be released before Qt 6, which is expected in the beginning
>>> of 2021.
>>
>> Are there any packagers for Qt 6 yet? If not, we'll have qt5 in Debian
>> for quite awhile still.
> 
> SIP doesn't depend on Qt, just the upstream SIP/PyQt6 developer wants
> to coordinate his release schedule with Qt.
> 
>> Your patches to the upstream buildsystem have been been added to the
>> master branch on salsa as well. They will be included in the next upload
>> which likely won't happen before 3.10.10+dfsg-1 migrates to testing, at
>> the latest when 3.10.11 is released next month.
>>
>> Once PyQt5 is moved to unstable, the changes for (build) dependencies
>> will be adopted on the master branch as well.
> 
> Can I ask you to test the current QGIS package from unstable with PyQt5
> 5.15.1 from experimental?
> 
> I could do it myself, but you know this package more so can probably perform
> more extensive testing.

We've already tested that it builds as proven by the package in
experimental.

I don't use QGIS much, so there is not much runtime testing I can do.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#964745: lxc-start fails when specifying a custom lxc.net.0.hwaddr (on armv7l)

[Santiago R.R.]

Salut Pierre,

El 05/09/20 a las 00:23, Pierre-Elliott Bécue escribió:
> Control: tags -1 +moreinfo
> 
> Hey Santiago,
> 
> Thanks for the bugreport!
> 
> Le jeudi 09 juillet 2020 à 22:28:06+0200, Santiago R.R. a écrit :
> > Package: lxc
> > Version: 1:3.1.0+really3.0.3-8
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > After creating an lxc container, I've manually set a MAC address for it.
> > The container fails to start, giving this output in the logs:
> > 

…

> > To make the container work, I had to remove the lxc.net.0.hwaddr entry,
> > start the container and only then copy the autogenerated MAC address in
> > the config.
> > 
> > This happens on armv7l running buster. I haven't test a similar case on
> > other architecture nor testing/sid.
> 
> Could you give me your container config?

I'll do once I regain access to that machine. It has some issues after a
blackout … :-s

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#964132: qgis: Please switch from sip4 to sip5

[Dmitry Shachnev]

On Mon, Sep 21, 2020 at 04:44:06PM +0200, Sebastiaan Couwenberg wrote:
> > But SIP 6 won't be released before Qt 6, which is expected in the beginning
> > of 2021.
>
> Are there any packagers for Qt 6 yet? If not, we'll have qt5 in Debian
> for quite awhile still.

SIP doesn't depend on Qt, just the upstream SIP/PyQt6 developer wants
to coordinate his release schedule with Qt.

> Your patches to the upstream buildsystem have been been added to the
> master branch on salsa as well. They will be included in the next upload
> which likely won't happen before 3.10.10+dfsg-1 migrates to testing, at
> the latest when 3.10.11 is released next month.
>
> Once PyQt5 is moved to unstable, the changes for (build) dependencies
> will be adopted on the master branch as well.

Can I ask you to test the current QGIS package from unstable with PyQt5
5.15.1 from experimental?

I could do it myself, but you know this package more so can probably perform
more extensive testing.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#941745: Tomb 2.6 provides an important fix

[Dominik Schmidt-Philipp]

reached here with the same intention as Joerg Bornemann.

apparently it is against Debian philosophy to include a version that is
compatible with Debian 10 cryptsetup version. What document do I need to
read to understand the reasoning behind that?

I use stable because I expect the chance to things working with default
settings to be highest there. tomb in Debian 10 is not usable without
reading discussions about bugreports. The workaround is both difficult to
remember, and hard to find. Easiest workaround for me was just installing
from source, not using APT. ok for me, but not possible to recommend to
those I usually help out.

thank you for inclusion in backports though. Hadn't thought of that, since
usually I have no need to use newest version of system-tools.

kind regards,
Dom

Bug#970452: RFS: argh

[Andreas Tille]

Hi,

On Mon, Sep 21, 2020 at 04:43:05PM +0200, Steffen Möller wrote:
> Hello Shayan,
> 
> On 21.09.20 14:33, Shayan Doust wrote:
> > Hello Steffen,
> >
> >> looks good to me, but the binary name should be libargh-dev, right?
> > It's just a singular header file, so I am following the same naming 
> > convention
> > as some of the other header-only library packages[1].
> >
> > Kind regards,
> > Shayan Doust
> >
> > [1]: https://salsa.debian.org/med-team/tao-json/-/blob/master/debian/control
> 
> Typically all the C/C++ libraries have "lib" as a prefix and the
> arch-independent header files get "-dev" as a suffix. If for header-only
> libraries there is an exception to this then I have made a few unnoticed
> mistakes with all these recent parallel computing libraries.

I admit I took over cimg-dev which is also an header only library and I
never felt a strong reason to change this but I never liked it.  The
rationale for the user is that it finally does not matter whether a
library is header only or not - its simply a library and the package
name should reflect this.

We even have libdevel packages that are not header only - the famous
zlib1g-dev is a bad example for this.

In short:  I agree with Steffen about the name libargh-dev - except
Shayan can point to some policy statement we both might have missed.
 
> |tao-json-examples is fine, but |||tao-json-dev under my hands indeed
> would have been named |libtao-json-dev.|||
> 
> |||-> Andreas :)|||

ARGH! ;-)
 
Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#891858: DESKTOP-Linux org.gnome.Shell.desktop[729]: libinput error: client bug: timer event8 debounce short: offset negative

[Roman Shentsev]

Hello,
 
Hello! When I try to upload sketch to ESP-WROOM-32 development board through 
Arduino IDE, I would receive serial.serialutil.SerialException: device reports 
readiness to read but returned no data (device disconnected or multiple access 
on port?).
Log from /var/log/message:
Sep 21 10:51:21 DESKTOP-Linux arduino-arduinoide.desktop[729]: Sketch uses 
635782 bytes (48%) of program storage space. Maximum is 1310720 bytes.
Sep 21 10:51:21 DESKTOP-Linux arduino-arduinoide.desktop[729]: Global variables 
use 38760 bytes (11%) of dynamic memory, leaving 288920 bytes for local 
variables. Maximum is 327680 bytes.
Sep 21 10:51:21 DESKTOP-Linux arduino-arduinoide.desktop[729]: esptool.py v2.6
Sep 21 10:51:21 DESKTOP-Linux arduino-arduinoide.desktop[729]: Serial port 
/dev/ttyUSB0
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: 
Connecting_
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: Traceback (most 
recent call last):
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
2959, in 
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: An error 
occurred while uploading the sketch
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: _main()
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
2952, in _main
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: main()
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
2653, in main
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: 
esp.connect(args.before)
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
460, in connect
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: last_error = 
self._connect_attempt(mode=mode, esp32r0_delay=False)
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
440, in _connect_attempt
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: self.sync()
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
381, in sync
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: 
self.command()
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
332, in command
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: p = 
self.read()
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
277, in read
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: return 
next(self._slip_reader)
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.arduino15/packages/esp32/tools/esptool_py/2.6.1/esptool.py", line 
1873, in slip_reader
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: read_bytes = 
port.read(1 if waiting == 0 else waiting)
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]:   File 
"/home/roman/.local/lib/python2.7/site-packages/serial/serialposix.py", line 
501, in read
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: 'device 
reports readiness to read but returned no data '
Sep 21 10:51:42 DESKTOP-Linux arduino-arduinoide.desktop[729]: 
serial.serialutil.SerialException: device reports readiness to read but 
returned no data (device disconnected or multiple access on port?)
Sep 21 10:52:17 DESKTOP-Linux org.gnome.Shell.desktop[729]: libinput error: 
client bug: timer event8 debounce short: offset negative (-1ms)
Sep 21 10:55:22 DESKTOP-Linux org.gnome.Shell.desktop[729]: libinput error: 
client bug: timer event8 debounce short: offset negative (-0ms)
I have the next packages linked with libinput:
 
consolation/stable 0.0.6-2 amd64
  linux console pointer support for copy-paste
libelput1/stable 1.21.1-5 amd64
  EFL abstraction for libinput
libinput-bin/stable,now 1.12.6-2+deb10u1 amd64 [installed,automatic]
  input device management and event handling library - udev quirks
libinput-dev/stable 1.12.6-2+deb10u1 amd64
  input device management and event handling library - development files
libinput-pad-dev/stable 1.0.3-3 amd64
  On-screen Input Pad to Send Characters with Mouse - dev
libinput-pad-xtest/stable 1.0.3-3 amd64
  On-screen Input Pad to Send Characters with Mouse - xtest
libinput-pad1/stable 1.0.3-3 amd64
  On-screen Input Pad to Send Characters with Mouse - libs
libinput-tools/stable 1.12.6-2+deb10u1 amd64

Bug#809997: emscripten: not installable in sid

[Sylvestre Ledru]

Le 21/09/2020 à 16:48, Jonas Smedegaard a écrit :

Hi Sylvestre and others,

I have a strong interest in getting emscripten into shape.

I am not ready to get involved in the LLVM Packaging Team, nor do I find
the current state of the package useful to work from, but I would be
willing to take over maintenance if that is ok with the current
maintainers.

@Sylvestre, it seems you did all previous releases, so I guess you are
qualified to decide: Would you be ok with me taking over as maintainer?


With pleasure :)

And happy to work with you on this. I will be more than happy to make 
changes to LLVM

to make your life easier if needed!

Cheers

S

Bug#956401: [debian-mysql] Bug#956401: mariadb-server: --ssl-verify-server-cert fails

[Faustin Lammler]

Control: forward -1 https://jira.mariadb.org/browse/MDEV-12190

Hi Otto!
So shouldn't we tag wontfix?


signature.asc
Description: PGP signature

Bug#958910: debci: 'debci setup -a armhf' fails to set up an lxc container on an amd64 host

[Antonio Terceiro]

Control: tag -1 + moreinfo

On Sun, Sep 20, 2020 at 08:32:50PM +0200, Sven Geuer wrote:
> Dear Maintainer,
> 
> I am missing someone has taken a look into this issue. I'd appreciate
> to get some feedback.
> 
> Please let me know what further input from my side may be helpful.

I just tried it here, and it just worked for me. Are you able to start
regular lxc containers?


signature.asc
Description: PGP signature

Bug#963684: libjs-mathjax: please package mathjax3

[Andreas Tille]

Hi,

On Mon, Sep 21, 2020 at 04:56:04PM +0300, Dmitry Shachnev wrote:
> 
> Because mathjax 3.x is not compatible with 2.x [1], and given the number
> of packages that currently depend on libjs-mathjax, I think 3.x should be
> a separate package.
> 
> So maybe retitle this bug to ITP?
> 
> I will continue maintaining mathjax 2.x but I would prefer if 3.x is taken
> by someone who is more familiar with nodejs and typescript ecosystem (my
> knowledge of both is around zero).

If this is the fastest way to get mathjax3 into Debian I'm all for it.
 
Thanks a lot for you two for caring

   Andreas.

-- 
http://fam-tille.de