Bug#913122: remmina-plugin-rdp: ERRCONNECT_TLS_CONNECT_FAILED with libssl1.1 1.1.1-2

[Matsievskiy S.V.]

Yes, it does work after the update

On 09/11/2018 00:42, Mike Gabriel wrote:

HI,

On  Mi 07 Nov 2018 09:02:11 CET, Matsievskiy S.V. wrote:


Package: remmina-plugin-rdp
Version: 1.2.32+dfsg-2
Severity: important

Dear Maintainer,

remmina-plugin-rdp seems to be affected by issue, described in bug 
#912206 for freerdp2-x11.

Original report:


Package: freerdp2-x11
Version: 2.0.0~git20180411.1.7a7b1802+dfsg1-2+b1
Severity: normal

Dear Maintainer,

After upgrading libssl1.1 from 1.1.0h-4 to 1.1.1-1 xfreerdp is no 
longer
able to connect to a computer running Remote Desktop Services on 
Windows

Server 2008 R2 (with default settings as far as I am aware) using TLS
security.  Connection fails with the following messages:

    [ERROR][com.freerdp.core] - freerdp_set_last_error
ERRCONNECT_TLS_CONNECT_FAILED [0x00020008]
    [ERROR][com.freerdp.core.connection] - Error: protocol security
negotiation or connection failure

Downgrading libssl1.1 to 1.1.0h-4 fixes the issue.  To further diagnose
the cause, I noticed that the server sends TCP RST in response to the
SSL Client Hello message.  After some trial and error, I determined 
that

this occurs whenever rsa_pkcs1_sha1 in not the offered signature
algorithms, which is the case for SECLEVEL=2 which is the default in 
the

libssl1.1 Debian package since version 1.1.1~~pre6-1.  To confirm, this
fails:

    openssl s_client -connect 192.168.0.2:3389

while this works:

    openssl s_client -cipher DEFAULT@SECLEVEL=1 -connect 
192.168.0.2:3389


For further confirmation that rsa_pkcs1_sha1 is responsible, this 
works:


    openssl s_client -cipher DEFAULT@SECLEVEL=1 -sigalgs
rsa_pkcs1_sha1 -connect 192.168.0.2:3389

while this fails:

    openssl s_client -cipher DEFAULT@SECLEVEL=1 -sigalgs
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:DSA+SHA1:ECDSA+SHA1 
-connect

192.168.0.2:3389

Applying this discovery, it is possible to make xfreerdp work using:

    xfreerdp /tls-ciphers:DEFAULT@SECLEVEL=1

However, since most users are unlikely to figure this out on their own,
I'd suggest calling SSL_CTX_set_security_level to set the security 
level

to 1 or improving the error message to suggest this workaround.

Thanks,
Kevin




This issue is probably fixed my today's freerdp2 upload to unstable 
(2.0.0~git20180411.1.7a7b1802+dfsg1-3).


Please check and report back. Thanks!

Mike (co-maintainer+uploader of freerdp2 in Debian)

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277



Ok:

"cat /proc/asound/cards
 0 [PCH]: HDA-Intel - HDA Intel PCH
  HDA Intel PCH at 0xe061 irq 27"

Bug#902533: missing files

[Gürkan Myczko]

Hi James

I figured, the genereated fonts are of really bad quality and dropped 
them.

Feel free to generate them if you are happy with them.

But I will only distribute the original fonts for the future.

Best,

Bug#913189: [Pkg-tcltk-devel] Bug#913189: /usr/bin/tclsh8.6: `file delete' can produce EFAULT

[Sergei Golovan]

Hi Ian,
On Thu, Nov 8, 2018 at 1:03 AM Ian Jackson
 wrote:
>
> To reproduce:
>
> $ rm -rf d
> $ mkdir d
> $ cd d
> $ rm -rf ../d
> $ env - pwd
> pwd: couldn't find directory entry in '..' with matching i-node
> $ tclsh8.6
> % file delete spong
> error deleting "spong": bad address in system call argument
> %

Right, the error message isn't an appropriate one.

>
> strace shows:
>
> getcwd(0x7ffcf224aeb0, 4097)= -1 ENOENT (No such file or 
> directory)
> lstat(NULL, 0x7ffcf224c100) = -1 EFAULT (Bad address)
>
> Not sure why `file delete spong' needs to call cwd at all, but
> certainly it should have a proper error check.

I'll forward the bug upstream shortly. Thank you for the report.

Cheers!
-- 
Sergei Golovan

Bug#912532: stunnel4: "Internal error: double free attempt" with OpenSSL 1.1.1-1 and 1.1.1-2

[Frank Chung]

Dear maintainer,

Here's some additional info I've only noticed today that might be relevant:

My stunnel4 client side has OpenSSL 1.1.1-2. When the stunnel4 server side
has OpenSSL 1.1.1-1 or 1.1.1-2, the two sides negotiate TLS 1.3. This is
when the internal error and subsequent kernel general protection
error occurs. When the stunnel4 server side downgrades to OpenSSL
1.1.1~~pre8-1, the two sides actually negotiate TLS 1.2.

Hope this little detail helps to zero in on the problem.

Regards,
Frank

Bug#913266: [Pkg-rust-maintainers] Bug#913266: rustc fails to build many rust-* packages on arm64: LLVM ERROR: Only small and large code models are allowed on AArch64

[Ximin Luo]

Control: severity -1 important

Hi, please file these upstream.

As far as I can see these builds never worked in the first place, so this issue 
should not affect migration to Debian Testing.

X

Adrian Bunk:
> Package: rustc
> Version: 1.30.0+dfsg1-2
> Severity: serious
> 
> Example:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/rust-bytecount.html
> 
> ...
>dh_auto_test -O--buildsystem=cargo
> error: failed to run `rustc` to learn about target-specific information
> 
> Caused by:
>   process didn't exit successfully: `rustc - --crate-name ___ 
> --print=file-names --crate-type bin --crate-type rlib --crate-type dylib 
> --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit 
> code: 1)
> --- stderr
> LLVM ERROR: Only small and large code models are allowed on AArch64
> 
> dh_auto_test: cargo build --verbose --verbose -j8 --target 
> aarch64-unknown-linux-gnu -Zavoid-dev-deps returned exit code 101
> make: *** [debian/rules:3: build] Error 25
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#913229: release.debian.org: RC status of merged-/usr bugs?

[Niels Thykier]

Simon McVittie:
> Package: release.debian.org
> Severity: normal
> User: m...@linux.it
> Usertags: usrmerge
> 
> debootstrap in >= buster produces merged-/usr chroots for buster and sid
> by default. Some packages are misbuilt in such chroots: the only concrete
> example I have that is currently open is 
> in quilt, in which a package built in a merged-/usr environment will
> work on merged-/usr systems but won't work (at all) on a non-merged-/usr
> system.
> 
> There are almost certainly others; [...]
> 
> If binary packages in the archive don't work on a non-merged-/usr system,
> is that a RC bug in the binary packages? [...]
> 
> smcv
> 

Hi Simon,

Thanks for bringing the issue to our attention.

TL;DR summary:

  Can we effectively/measurably answer "which packages are affected?"
  (or "when do we know that all packages work when built-in in a
   merged-/usr?")?

As I understand it, what this question effectively ends up being is "Do
we commit to supporting merged-/usr in Buster in all source packages
(making such bugs RC) OR do we rollback the default merged-/usr in
debootstrap (making them non-RC)?".

To answer such a question at this point in the release cycle, we need to
understand the number of affected packages to tell whether it is
realistic to complete this by the freeze (regardless of which "part" of
the freeze we choose as deadline for it).

In the absence of a clear way to define "when is everything fixed", I
gut feeling is that we might be opening pandora's box right before a
release.

Thanks,
~Niels

Bug#893439: stretch-pu: package gnucash/1:2.6.15-1+deb9u1

[GCS]

On Sat, Oct 6, 2018 at 7:07 PM Adam D. Barratt  wrote:
>
> László: ping?
>
> On Mon, 2018-04-02 at 15:20 +0200, Julien Cristau wrote:
> > On Mon, Apr  2, 2018 at 14:51:54 +0300, Adrian Bunk wrote:
> > > On Mon, Apr 02, 2018 at 01:05:39PM +0200, Julien Cristau wrote:
> > > > On Sun, Mar 18, 2018 at 22:07:25 +0200, Adrian Bunk wrote:
> [...]
> > > > libdbi 0.9.0-4+deb9u1 broke gnucash tests, runtime issues
> > > > > with this backend were so far not reported but are not
> > > > > unlikely.
> [...]
> > So the other option here would be to revert the libdbi change.  As
> > far as I can tell from #880896 it wasn't prompted by a specific
> > problem, so a revert there might be the safest course of action and
> > sidesteps the gnucash issue.  László, any thoughts?
 Indeed, that change is better reverted. I've proposed a patch on
#884119 [1]. Can I upload it to Stretch or should file a separate PU
proposal?

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/884119#17

Bug#884119: libdbi1: dbi_result_next_row() error handler change breaks existing code

[GCS]

On Mon, Jan 22, 2018 at 11:21 PM gotodimas  wrote:
>
> This bug breakes gammu-smsd. Daemon exit with error:
>
> gammu-smsd[2018]: DBI error -6: -6: An invalid or out-of-range index was 
> passed to libdbi
 This is bad. :(

> Reverting libdbi1 to 0.9.0-4 (not 0.9.0-4+deb9u1) fixes this problem.
 Going to ask for a package update with the attached patch.

Regards,
Laszlo/GCS
diff -Nru libdbi-0.9.0/debian/changelog libdbi-0.9.0/debian/changelog
--- libdbi-0.9.0/debian/changelog	2017-10-29 18:19:04.0 +
+++ libdbi-0.9.0/debian/changelog	2018-11-09 06:12:20.0 +
@@ -1,3 +1,9 @@
+libdbi (0.9.0-4+deb9u2) stretch; urgency=medium
+
+  * Comment out _error_handler() call again.
+
+ -- Laszlo Boszormenyi (GCS)   Fri, 09 Nov 2018 06:12:20 +
+
 libdbi (0.9.0-4+deb9u1) stretch; urgency=medium
 
   * Backport fix to re-enable a call to _error_handler() that was commented
diff -Nru libdbi-0.9.0/debian/patches/series libdbi-0.9.0/debian/patches/series
--- libdbi-0.9.0/debian/patches/series	2017-10-29 18:19:04.0 +
+++ libdbi-0.9.0/debian/patches/series	2018-11-09 06:12:20.0 +
@@ -1,4 +1,4 @@
 fix_memory_leak_if_not_connected.patch
 fix_possible_access_to_unallocated_memory.patch
 fix_double-free_in_dbi_shutdown_r.patch
-re-enable_call_to_error_handler.patch
+#re-enable_call_to_error_handler.patch

Bug#892070: stretch-pu: package obs-build/20160921-1

[Salvatore Bonaccorso]

Hi Hector,

On Tue, Jul 03, 2018 at 08:59:39PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2018-03-04 at 23:23 +0100, Hector Oron wrote:
> [...]
> > 2018-03-04 23:13 GMT+01:00 Héctor Orón Martínez :
> [...]
> > >   I would like to push security fix into stable for `obs-build`.
> > >   The patch fixes CVE-2017-14804 as described in #887306.
> > >  
> 
> Please go ahead; sorry for the delay.

Thats unfortunately to late for 9.6, but given the gonfirmation could
you upload the fixed package so it can make it into 9.7?

Regards,
Salvatore

Bug#892031: stretch-pu: package wayland/1.12.0-1

[Salvatore Bonaccorso]

Hi Héctor,

On Sun, Aug 26, 2018 at 02:43:43PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2018-07-14 08:00, Salvatore Bonaccorso wrote:
> > Control: tags -1 - moreinfo
> > 
> > Hi Adam,
> > 
> > On Tue, Jul 03, 2018 at 08:55:44PM +0100, Adam D. Barratt wrote:
> > > Control: tags -1 + moreinfo
> > > 
> > > On Sun, 2018-03-04 at 12:42 +0100, Héctor Orón Martínez wrote:
> > > >   I would like to apply fix in stable for #889681.
> > > >
> > > 
> > > The metadata for that bug report suggests that it still applies to
> > > unstable, possibly because the current changelog is based on the
> > > experimental uploads and contains no reference to either the 1.14.0-2
> > > upload or #889681. Please confirm that the bug is actually fixed in
> > > unstable and fix up the metadata appropriately.
> > 
> > What I think what happened. The issue really was fixed with the
> > unstable upload as 1.14.0-2
> > https://tracker.debian.org/news/937846/accepted-wayland-1140-2-source-into-unstable/
> > 
> > A later 1.15.0-1 upload did though not merged in the debian/changelog
> > information from 1.14.0-2 and that got lost, which is probably what
> > confused the BTS version tracking then because 1.14.0-2 not anymore
> > known.
> 
> That's the conclusion I came to as well, but I was trying to prod Héctor
> towards fixing it. ;-) I see that you did so, thanks.
> 
> Please feel free to go ahead.

Friendly ping, can you upload the fixed package? Unfortunately this
will not make it for 9.6 but can then for 9.7.

Regards,
Salvatore

Bug#885183: stretch-pu: package ntopng/2.4+dfsg1-3+deb9u1

[Salvatore Bonaccorso]

Hi Ludovico,

On Sat, Feb 10, 2018 at 10:25:47AM +0100, Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> On Mon, Dec 25, 2017 at 21:26:58 +0100, Ludovico Cavedon wrote:
> 
> > I would like to submit to your consideration an update to ntopng in
> > stretch.
> > 
> > The main bug that triggered this upload is #856048, which causes the
> > user management and preferences section of the web interface to
> > be unusuable.
> > 
> > The fix is already in version 2.4+dfsg1-4 in unstable.
> > 
> > There are three additional important issues from 2.4+dfsg1-4 that I
> > think it would make sense to include:
> > - #859653 which causes ntopng to crash if the mysql backend is selected.
> >   This change only affects mysql users. On the other side it is an
> >   obvious usage-after-free and out-of-bound memeory access issues.
> > - #866721 and #866719, which are securirity-related issues. Do you want
> >   me to reach out to the security team about these first? Do we need to
> >   treat the whole update as a security one instead, or split it?
> > 
> Assuming this has been properly tested in a stretch environment, please
> go ahead and upload.

Friendly ping ;-)

Regards,
Salvatore

Bug#885069: stretch-pu: package open-iscsi/2.0.874-3~deb9u1

[Salvatore Bonaccorso]

Hi Christian,

On Sat, Feb 10, 2018 at 10:15:48AM +0100, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Sat, Dec 23, 2017 at 13:40:43 +0100, Christian Seiler wrote:
> 
> > diff -Nru 
> > open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
> >  
> > open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
> > --- 
> > open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
> >   1970-01-01 01:00:00.0 +0100
> > +++ 
> > open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
> >   2017-12-23 13:09:13.0 +0100
> > @@ -0,0 +1,122 @@
> > +From e313bd648a4c8a9526421e270eb597a5de1e0c7f Mon Sep 17 00:00:00 2001
> > +From: Lee Duncan 
> > +Date: Fri, 15 Dec 2017 10:36:11 -0800
> > +Subject: [PATCH 1/8] Check for root peer user for iscsiuio IPC
> > +
> > +This fixes a possible vulnerability where a non-root
> > +process could connect with iscsiuio. Fouund by Qualsys.
> > +---
> > + iscsiuio/src/unix/Makefile.am  |  3 ++-
> > + iscsiuio/src/unix/iscsid_ipc.c | 47 
> > ++
> > + 2 files changed, 49 insertions(+), 1 deletion(-)
> > +
> [...]
> > +@@ -1029,6 +1035,40 @@ static void iscsid_loop_close(void *arg)
> > +   LOG_INFO(PFX "iSCSI daemon socket closed");
> > + }
> > + 
> > ++/*
> > ++ * check that the peer user is privilidged
> > ++ *
> 
> This function doesn't actually do that.
> 
> > ++ * return 1 if peer is ok else 0
> > ++ *
> > ++ * XXX: this function is copied from iscsid_ipc.c and should be
> > ++ * moved into a common library
> > ++ */
> > ++static int
> > ++mgmt_peeruser(int sock, char *user)
> > ++{
> > ++  struct ucred peercred;
> > ++  socklen_t so_len = sizeof(peercred);
> > ++  struct passwd *pass;
> > ++
> > ++  errno = 0;
> > ++  if (getsockopt(sock, SOL_SOCKET, SO_PEERCRED, ,
> > ++  _len) != 0 || so_len != sizeof(peercred)) {
> > ++  /* We didn't get a valid credentials struct. */
> > ++  LOG_ERR(PFX "peeruser_unux: error receiving credentials: %m");
> > ++  return 0;
> > ++  }
> > ++
> > ++  pass = getpwuid(peercred.uid);
> > ++  if (pass == NULL) {
> > ++  LOG_ERR(PFX "peeruser_unix: unknown local user with uid %d",
> > ++  (int) peercred.uid);
> > ++  return 0;
> > ++  }
> > ++
> > ++  strlcpy(user, pass->pw_name, PEERUSER_MAX);
> > ++  return 1;
> > ++}
> > ++
> > + /**
> > +  *  iscsid_loop() - This is the function which will process the broadcast
> > +  *  messages from iscsid
> > +@@ -1038,6 +1078,7 @@ static void *iscsid_loop(void *arg)
> > + {
> > +   int rc;
> > +   sigset_t set;
> > ++  char user[PEERUSER_MAX];
> > + 
> > +   pthread_cleanup_push(iscsid_loop_close, arg);
> > + 
> > +@@ -1077,6 +1118,12 @@ static void *iscsid_loop(void *arg)
> > +   continue;
> > +   }
> > + 
> > ++  if (!mgmt_peeruser(iscsid_opts.fd, user) || strncmp(user, 
> > "root", PEERUSER_MAX)) {
> > ++  close(s2);
> > ++  LOG_ERR(PFX "Access error: non-administrative 
> > connection rejected");
> > ++  break;
> > ++  }
> > ++
> > +   process_iscsid_broadcast(s2);
> > +   close(s2);
> > +   }
> 
> The above makes little sense to me.  We find out the peer uid, then
> instead of just comparing that against 0 we turn it into a struct passwd
> and compare pw_name against "root".  Why?

Did you had any chance to look at Julien's concerns/questions back on
this proposed update for stretch?

Regards,
Salvatore

Bug#913045: [Pkg-alsa-devel] Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Elimar Riesebieter]

* Pedro Silva  [2018-11-08 22:25 +]:

[...]
> 
> This is getting weird.
> 
> Even with the $HOME/.asoundrc file, I've nailed it down to not being
> able to play two sound sources at the same time.

Could you please add:

###
ctl.snd_card {
type hw
card 2
device 2
}
###

to your .asoundrc and try again?

Thanks
Elimar
-- 
  Alles, was viel bedacht wird, wird bedenklich!;-)
 Friedrich Nietzsche


signature.asc
Description: PGP signature

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Elimar Riesebieter]

* Awtul  [2018-11-08 18:31 -0500]:

> Package: moc
> Version: 1:2.6.0~svn-r2984-1
> Severity: important
> 
> Dear Maintainer,
> 
> Until yesterday 'moc' worked just fine. But now when I start it I get:
> 
[...]
> Trying JACK...
> Trying ALSA...
> Trying OSS...
> 
> FATAL_ERROR: No valid sound driver!
> 
> 
> FATAL_ERROR: Server exited!"

Please post the output of

cat /proc/asound/cards

Elimar
-- 
  >what IMHO then?
  IMHO - Inhalation of a Multi-leafed Herbal Opiate ;)
  --posting from alex in debian-user--


signature.asc
Description: PGP signature

Bug#913291: wireless-tools misbuilds: installs to build architecture multiarch directory

[Helmut Grohne]

Source: wireless-tools
Version: 30~pre9-13
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

wireless-tools sucessfully cross builds a broken package. The libraries
are installed into the build architecture multiarch directories rather
than the host architecture ones. The attached patch fixes that. Please
consider applying it.

Helmut
diff --minimal -Nru wireless-tools-30~pre9/debian/changelog 
wireless-tools-30~pre9/debian/changelog
--- wireless-tools-30~pre9/debian/changelog 2018-09-15 16:35:08.0 
+0200
+++ wireless-tools-30~pre9/debian/changelog 2018-11-09 06:16:30.0 
+0100
@@ -1,3 +1,11 @@
+wireless-tools (30~pre9-13.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix misbuild: install to host architecture multiarch directory.
+(Closes: #-1)
+
+ -- Helmut Grohne   Fri, 09 Nov 2018 06:16:30 +0100
+
 wireless-tools (30~pre9-13) unstable; urgency=medium
 
   * Call /sbin/ip instead of ifconfg in if-pre-up script. (Closes: 908886)
diff --minimal -Nru wireless-tools-30~pre9/debian/rules 
wireless-tools-30~pre9/debian/rules
--- wireless-tools-30~pre9/debian/rules 2018-09-15 16:28:38.0 +0200
+++ wireless-tools-30~pre9/debian/rules 2018-11-09 06:16:30.0 +0100
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 %:
dh $@
 
@@ -7,7 +9,7 @@
dh_auto_build -- all libiw.a
 
 override_dh_auto_install:
-   dh_auto_install -- install install-static PREFIX=debian/tmp
+   dh_auto_install -- install install-static PREFIX=debian/tmp 
ARCH=$(DEB_HOST_MULTIARCH)
# Hack to make udeb friendly binaries
$(MAKE) clean
dh_auto_build -- BUILD_NOLIBM=y CFLAGS="-Os -I."

Bug#913290: lintian: Incorrectly reports invalid-template-id-in-symbols-file/syntax-error-in-symbols-file for certain symbols files

[James McCoy]

Package: lintian
Version: 2.5.110
Severity: normal
Tags: patch

14098d4c65159b651d6c324d04cc9a83c26a592e introduced a regression with
these two tags[0][1], as noticed by the libsvn1 package.  This was due
to no longer re-setting[2] meta_info_seen when encountering a new entry
in the symbols file.

[0]: https://lintian.debian.org/tags/invalid-template-id-in-symbols-file.html
[1]: https://lintian.debian.org/tags/syntax-error-in-symbols-file.html
[2]: 
https://salsa.debian.org/lintian/lintian/commit/14098d4c65159b651d6c324d04cc9a83c26a592e#1fa89243df10deea1f8a05360d685b460458e201_500_500

The below patch fixes the issue, although I'm not familiar enough with
the test suite to add a regression test.

diff --git i/checks/shared-libs.pm w/checks/shared-libs.pm
index 61dcd4138..9d520d4f5 100644
--- i/checks/shared-libs.pm
+++ w/checks/shared-libs.pm
@@ -498,6 +498,7 @@ sub run {
 
 $dep_templates = 0;
 $symbol_count = 0;
+undef %meta_info_seen;
 } elsif (m/^\|\s+\S+\s*(?:\(\S+\s+\S+\)|#MINVER#)?/) {
 # alternative dependency template
 

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-7
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-8
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.74+repack-1+b1
ii  man-db 2.8.4-3
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.28.0-3
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.2
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277

There goes 'mocp_server_log' if it can help.
According to dpkg.log, 'alsa-utils', 'libasound2', 'libasound2-data' and 
'libasound2-plugins'
have been upgraded a few days ago.


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

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

Versions of packages moc depends on:
ii  libasound21.1.7-1
ii  libc6 2.27-8
ii  libcurl3-gnutls   7.62.0-1
ii  libdb5.3  5.3.28+dfsg1-0.2
ii  libfaad2  2.8.8-1
ii  libflac8  1.3.2-3
ii  libgcc1   1:8.2.0-9
ii  libid3tag00.15.1b-13
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libltdl7  2.4.6-6
ii  libmad0   0.15.1b-9
ii  libmagic1 1:5.34-2
ii  libmodplug1   1:0.8.9.0-2
ii  libmpcdec62:0.1~r495-1+b2
ii  libncursesw6  6.1+20181013-1
ii  libogg0   1.3.2-1+b1
ii  libopusfile0  0.9+20170913-1
ii  libpopt0  1.16-11
ii  librcc0   0.2.12-0.1
ii  libresid-builder0c2a  2.1.1-15
ii  libsamplerate00.1.9-2
ii  libsidplay2   2.1.1-15
ii  libsidutils0  2.1.1-15
ii  libsndfile1   1.0.28-4
ii  libspeex1 1.2~rc1.2-1+b2
ii  libstdc++68.2.0-9
ii  libtagc0  1.11.1+dfsg.1-0.2+b1
ii  libtinfo6 6.1+20181013-1
ii  libvorbis0a   1.3.6-1
ii  libvorbisfile31.3.6-1
ii  libwavpack1   5.1.0-4
ii  zlib1g1:1.2.11.dfsg-1

moc recommends no packages.

Versions of packages moc suggests:
ii  moc-ffmpeg-plugin  1:2.6.0~svn-r2984-1

-- no debconf information
Nov  8 21:35:09.255844: main.c:1191 main(): This is Music On Console (version 
2.6-alpha3)
Nov  8 21:35:09.255899: main.c:1195 main(): Configured: 
'--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' 
'--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' 
'--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' 
'--libdir=${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' 
'--disable-maintainer-mode' '--disable-dependency-tracking' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/moc-f7enRA/moc-2.6.0~svn-r2984=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic' 
'LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed' 'CPPFLAGS=-Wdate-time 
-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 
-fdebug-prefix-map=/build/moc-f7enRA/moc-2.6.0~svn-r2984=. 
-fstack-protector-strong -Wformat -Werror=format-security'
Nov  8 21:35:09.255911: main.c:1205 main(): Running on: Linux 4.18.0-2-amd64 
x86_64
Nov  8 21:35:09.256050: main.c:1157 log_command_line(): mocp -D 
Nov  8 21:35:09.256081: main.c:1171 log_popt_command_line(): mocp --debug 
Nov  8 21:35:09.316673: decoder.c:700 load_plugins(): Loaded 12 decoders: aac 
ffmpeg flac modplug mp3 musepack opus sidplay2 sndfile speex vorbis wavpack
Nov  8 21:35:09.317679: server.c:360 server_init(): Starting MOC Server
Nov  8 21:35:09.317859: log.c:233 log_init_stream(): Writing log to: 
mocp_server_log
Nov  8 21:35:09.317968: server.c:300 log_process_stack_size(): Process's stack 
size: 8388608
Nov  8 21:35:09.317981: server.c:317 log_pthread_stack_size(): PThread's stack 
size: 8388608
Nov  8 21:35:09.319420: jack.c:121 error_cb(): ERROR: JACK: Cannot connect to 
server socket err = No such file or directory
Nov  8 21:35:09.319446: server.c:672 add_event_all(): No events have been added 
because there are no clients
Nov  8 21:35:09.319462: jack.c:121 error_cb(): ERROR: JACK: Cannot connect to 
server request channel
Nov  8 21:35:09.319468: server.c:672 add_event_all(): No events have been added 
because there are no clients
Nov  8 21:35:09.321634: jack.c:121 error_cb(): ERROR: JACK: jack server is not 
running or cannot be started
Nov  8 21:35:09.321662: server.c:672 add_event_all(): No events have been added 
because there are no clients
Nov  8 21:35:09.321871: jack.c:121 error_cb(): ERROR: JACK: 
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping 
unlock
Nov  8 21:35:09.321885: server.c:672 add_event_all(): No events have been added 
because there are no clients
Nov  8 21:35:09.321895: jack.c:121 

Bug#913288: netcat-openbsd: udptest returns false positives

[Guilhem Moulin]

Hi,

On Thu, 08 Nov 2018 at 19:52:01 -0500, Moshe Piekarski wrote:
> The function udptest() reports a successfull connection even when my
> machine is not connected to anything.
> The same thing happens if the server is configured not to return
> connection refused (try nc -vu google.com 6789)

FWIW nc.traditional does the same:

$ nc.traditional -vu -q0 1.1.1.1 12345 

signature.asc
Description: PGP signature

Bug#913174: globs: GL_shadow and GL_smoke segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
I just tried to reproduce the issue.

This segfault in GL_shadow happens here:

Thread 1 "gl_shadow" received signal SIGSEGV, Segmentation fault.
0x79f6 in LoadTexture (tex_name=0x7fffe120 "tex.png") at 
src/benchmarks/GL_shadow/object.c:196
196 if ((tex_img->format)->Amask)
(gdb) bt
#0  0x55909d0d59f6 in LoadTexture (tex_name=0x7ffd0d909650 "tex.png") 
at src/benchmarks/GL_shadow/object.c:196
#1  0x55909d0d528c in LoadObject (objfile=0x55909d0d8076 "cube.obj") at 
src/benchmarks/GL_shadow/object.c:83
#2  0x55909d0d5ed8 in InitObject (objfile=0x55909d0d8076 "cube.obj") at 
src/benchmarks/GL_shadow/object.c:268
#3  0x55909d0d4a89 in main (argc=4, argv=0x7ffd0d909ad8) at 
src/benchmarks/GL_shadow/main.c:121


This looks like another case of truncated pointer because of
implicit prototypes, which unfortunately on amd64 default
to int (4 bytes) and therefore fail when a pointer (8 bytes) is
returned by a function.

This warning seems to be contained in the build logs:

gcc -o src/benchmarks/GL_shadow/object.o -c -g -D_GNU_SOURCE=1 -D_REENTRANT 
-I/usr/include/SDL src/benchmarks/GL_shadow/object.c
src/benchmarks/GL_shadow/object.c: In function 'LoadTexture':
src/benchmarks/GL_shadow/object.c:192:31: warning: implicit declaration of 
function 'IMG_Load' [-Wimplicit-function-declaration]
  if(tex_img = (SDL_Surface *) IMG_Load(tex_name)) {
   ^~~~
src/benchmarks/GL_shadow/object.c:192:15: warning: cast to pointer from 
integer of different size [-Wint-to-pointer-cast]
  if(tex_img = (SDL_Surface *) IMG_Load(tex_name)) {
   ^


Attached patch adds compiler flags and includes to avoid
implicit prototypes.

Kind regards,
Bernhard


> gdb run is not very helpful due lack of debugging symbols.

PS. @Witold Baryluk:
Also a failing stack can be of some use when the issue
is tried to be reproduced.
And the debug symbols are stored in a different repository.
You find some information at https://wiki.debian.org/HowToGetABacktrace
Description: Force prototypes

---
Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/913174
Forwarded: no
Last-Update: 2018-11-09

--- globs-0.2.0~svn50.orig/src/benchmarks/GLSL_parallax/extra.c
+++ globs-0.2.0~svn50/src/benchmarks/GLSL_parallax/extra.c
@@ -17,6 +17,8 @@
 */
 
 
+#define GL_GLEXT_PROTOTYPES
+
 #include 
 #include 
 #include 
@@ -26,6 +28,7 @@
 #include  
 
 #include "init.h"
+#include "extra.h"
 
 void UpdateLight(struct Light *l)
 {
--- globs-0.2.0~svn50.orig/src/benchmarks/GLSL_parallax/init.c
+++ globs-0.2.0~svn50/src/benchmarks/GLSL_parallax/init.c
@@ -17,15 +17,19 @@
 */
 
 
+#define GL_GLEXT_PROTOTYPES
+
 #include 
 #include 
 
 #include 
+#include 
 #include 
 #include  
 
 #include "init.h"
 #include "textfile.h"
+#include "extra.h"
 
 
 void InitLighting(struct Light *l, struct Material *m)
--- globs-0.2.0~svn50.orig/src/benchmarks/GLSL_parallax/main.c
+++ globs-0.2.0~svn50/src/benchmarks/GLSL_parallax/main.c
@@ -16,6 +16,7 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */
 
+#define GL_GLEXT_PROTOTYPES
 
 #include 
 #include 
--- globs-0.2.0~svn50.orig/src/benchmarks/GLSL_parallax/textfile.c
+++ globs-0.2.0~svn50/src/benchmarks/GLSL_parallax/textfile.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include "textfile.h"
 
 
 char *textFileRead(char *fn) {
--- globs-0.2.0~svn50.orig/src/benchmarks/GL_shadow/object.c
+++ globs-0.2.0~svn50/src/benchmarks/GL_shadow/object.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "object.h"
 
--- globs-0.2.0~svn50.orig/src/benchmarks/GL_smoke/particle.c
+++ globs-0.2.0~svn50/src/benchmarks/GL_smoke/particle.c
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "particle.h"
--- globs-0.2.0~svn50.orig/src/benchmarks/SConstruct
+++ globs-0.2.0~svn50/src/benchmarks/SConstruct
@@ -13,7 +13,7 @@ except SCons.Errors.UserError:
 	install_dir = os.path.join(root, prefix, 'share/globs/benchmarks')
 
 # create build environment
-env = Environment(CCFLAGS = '-g')
+env = Environment(CCFLAGS = '-g -Werror=missing-prototypes -Werror=implicit-function-declaration')
 
 # determine compiler and linker flags for SDL
 env.ParseConfig('sdl-config --cflags')
--- globs-0.2.0~svn50.orig/src/benchmarks/check_time.c
+++ globs-0.2.0~svn50/src/benchmarks/check_time.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include "check_time.h"
 
 long int check_time(int time)
 {
--- globs-0.2.0~svn50.orig/src/benchmarks/get_options.c
+++ globs-0.2.0~svn50/src/benchmarks/get_options.c
@@ -1,3 +1,4 @@
+#include 
 #include 
 #include "get_options.h"
 


apt update
apt install dpkg-dev devscripts xserver-xorg lightdm openbox xterm 
systemd-coredump gdb mc mesa-utils globs globs-dbgsym libsdl-image1.2-dbgsym
apt build-dep globs

systemctl start lightdm



mkdir globs/orig -p
cdglobs/orig
apt 

Bug#913289: netconsole: Fails to install: mount: /sys/kernel/config: mount point does not exist.

[Axel Beckert]

Package: netconsole
Version: 0.1-1
Severity: serious

Hi,

netconsole fails to install for me as follows on amd64 (sysvinit, report
written on this machine) and i386 (PAE, openrc):

Setting up netconsole (0.1-1) ...
netconsole-setup: Kernel config directory /sys/kernel/config not present.
netconsole-setup: configfs probably not mounted; mounting configfs...
mount: /sys/kernel/config: mount point does not exist.
invoke-rc.d: initscript netconsole, action "start" failed.
dpkg: error processing package netconsole (--configure):
 installed netconsole package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 netconsole

On arm64 (systemd, Raspberry Pi 3) it fails, too, as follows:

Setting up netconsole (0.1-1) ...
Job for netconsole.service failed because the control process exited with error 
code.
See "systemctl status netconsole.service" and "journalctl -xe" for details.
invoke-rc.d: initscript netconsole, action "start" failed.
● netconsole.service - Dynamically configure Linux netconsole
   Loaded: loaded (/lib/systemd/system/netconsole.service; disabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2018-11-09 01:25:46 UTC; 43ms 
ago
 Docs: man:netconsole-setup(8)
  Process: 5720 ExecStart=/usr/sbin/netconsole-setup $NETCONSOLE_OPTS 
(code=exited, status=32)
 Main PID: 5720 (code=exited, status=32)

Nov 09 01:25:46 rpi3 systemd[1]: Starting Dynamically configure Linux 
netconsole...
Nov 09 01:25:46 rpi3 netconsole-setup[5720]: netconsole-setup: Kernel config 
directory /sys/kernel/config not present.
Nov 09 01:25:46 rpi3 netconsole-setup[5720]: netconsole-setup: configfs 
probably not mounted; mounting configfs...
Nov 09 01:25:46 rpi3 netconsole-setup[5720]: mount: /sys/kernel/config: mount 
point does not exist.
Nov 09 01:25:46 rpi3 systemd[1]: netconsole.service: Main process exited, 
code=exited, status=32/n/a
Nov 09 01:25:46 rpi3 systemd[1]: netconsole.service: Failed with result 
'exit-code'.
Nov 09 01:25:46 rpi3 systemd[1]: Failed to start Dynamically configure Linux 
netconsole.
dpkg: error processing package netconsole (--configure):
 installed netconsole package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 netconsole

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages netconsole depends on:
ii  iputils-arping  3:20180629-2
ii  lsb-base9.20170808

netconsole recommends no packages.

netconsole suggests no packages.

-- no debconf information

Bug#913288: netcat-openbsd: udptest returns false positives

[Moshe Piekarski]

Package: netcat-openbsd
Version: 1.195-1
Severity: normal

The function udptest() reports a successfull connection even when my machine is 
not connected to anything.
The same thing happens if the server is configured not to return connection 
refused (try nc -vu google.com 6789)

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

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

Versions of packages netcat-openbsd depends on:
ii  libbsd0  0.9.1-1
ii  libc62.27-8

netcat-openbsd recommends no packages.

netcat-openbsd suggests no packages.

-- no debconf information

Bug#850637: dangling symlink: /usr/share/man/man1/rksh.1.gz

[Boyuan Yang]

Control: tag -1 + moreinfo

Hi Michael!

On Sun, 08 Jan 2017 19:02:13 +0100 Michael Stapelberg 
wrote:
> Package: ksh
> Version: 93u+20120801-2
> Severity: normal
> 
> ksh currently ships the following files:
> 
> $ dpkg -c ksh_93u+20120801-2_amd64.deb | grep usr/share/man
> /usr/share/man/fr/man1/shcomp.1.gz
> /usr/share/man/man1/ksh93.1.gz
> /usr/share/man/man1/shcomp.1.gz
> /usr/share/man/man1/rksh93.1.gz -> ksh93.1.gz
> /usr/share/man/man1/rksh.1.gz -> ksh.1.gz
> 
> …but ksh.1.gz does not exist in Debian:
> 
> $ apt-file search /usr/share/man/man1/ksh.1.gz
> $
> 
> Presumably, the link should point to ksh93.1.gz instead.

The symlink will never be dangling as long as ksh has been properly installed.
It was due to ksh.1.gz being provided via update-alternatives mechanism.

Do you still consider it a bug? If you find it acceptable, I assume we should
close this bug report.

--
Regards,
Boyuan Yang


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

Bug#913275: iwd: 4-Way Handshake Failure

[Andreas Henriksson]

Hello Sebastian Reichel,

Thanks for your bug report.

On Fri, Nov 09, 2018 at 12:05:14AM +0100, Sebastian Reichel wrote:
> Package: iwd
> Version: 0.10-1
> Severity: normal
> Tags: upstream
> 
> Hi,
> 
> I gave iwd (0.10-1 from Debian) a try on my notebook - It does not connect to
> the wireless network in my hackerspace:
[...]

Could you please discuss this directly with upstream?

They're available in #iwd on FreeNode or via iwd list at lists.01.org.
They will most likely ask you to gather a trace during the interaction
as a first step. They'll be able to assist with more details about
how to proceed.

Regards,
Andreas Henriksson

Bug#821408: Pam 1.3.0

[Andreas Henriksson]

Control: retitle -1 New upstream release available (1.3.1)

Hi Florian,

On Sun, Feb 05, 2017 at 05:48:23PM +0100, Florian Vessaz wrote:
> Hi,
> 
> I've refreshed the patches against the 1.3.0 release and moved the
> packaging to Git as upstream is also using Git. (This was discussed with
> Steve two weeks ago.)
[...]
>   https://gitlab.gnugen.ch/fvessaz/pkg-pam.git
[...]
> I'm naturally open to constructive criticism. Let me know if there is
> something I can do to help out.

I (unfortunately) just redid all of your work because I didn't
find this bug report because of the non-standard subject. :(

OTOH I did against pam 1.3.1 so slightly newer.
See https://people.debian.org/~ah/pkg-pam/

I'm just at the point where it now builds. No further checks done yet.

I guess we can always compare work to see if we did it the same.

Since a long time has passed, I'd like to ask if you are still
interested in working on pam in Debian?
I think an upload to experimental would be a good start and I'm willing
to sponsor if there's a need. (If we continue from your work then 
incorporating all the NMUs that happened since it was prepared is
also needed.)

Regards,
Andreas Henriksson

Bug#913287: libqt5core5a: loads libGL.so instead of libGL.so.1, causing PyQt5 to crash on systems with NVIDIA libraries installed

[Julian Gilbey]

Package: libqt5core5a
Version: 5.11.2+dfsg-4
Severity: important
Tags: patch upstream

Hello,

A long-standing bug affects the PyQt5 (and previously the PyQt4)
packages, whereby they crash on Debian-based systems which have the
NVIDIA libraries installed.  The following almost minimal code
crashes:

#!/usr/bin/python3

import sys

from PyQt5.QtCore import QUrl
from PyQt5.QtWidgets import QApplication
from PyQt5.QtWebEngineWidgets import QWebEngineView

app = QApplication(sys.argv)
wv = QWebEngineView()

wv.load(QUrl('about:blank'))
wv.show()

app.exec_()


See for example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912925 
https://bugs.launchpad.net/ubuntu/+source/python-qt4/+bug/941826

I have managed to track down the source of the error and reported it
upstream (along with debugging logs and so on) at:
https://bugreports.qt.io/browse/QTBUG-71488

It turns out that the bug lies in the libqt5core5a library, which
tries loading libGL.so before trying libGL.so.1, which is the wrong
order (in particular on Debian-based systems - see the above Debian
bug report for a discussion of why).  I have created and tested the
attached patch for the bug.

It would be great if this patch could be applied to Debian before
buster is frozen; it probably won't make it into the upstream sources
in time for buster (because it would presumably go into the 5.12.x
tree).

Thanks!

   Julian

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

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

Versions of packages libqt5core5a depends on:
ii  libc6  2.27-8
ii  libdouble-conversion1  3.1.0-2
ii  libgcc11:8.2.0-9
ii  libglib2.0-0   2.58.1-2
ii  libicu60   60.2-6
ii  libpcre2-16-0  10.32-3
ii  libstdc++6 8.2.0-9
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages libqt5core5a recommends:
ii  qttranslations5-l10n  5.11.2-2

Versions of packages libqt5core5a suggests:
ii  libthai0  0.1.28-1

-- no debconf information
--- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp
+++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp
@@ -650,9 +650,9 @@
 #if QT_CONFIG(library)
 extern const QString qt_gl_library_name();
 //QLibrary lib(qt_gl_library_name());
-QLibrary lib(QLatin1String("GL"));
+QLibrary lib(QLatin1String("GL"), 1);
 if (!lib.load())
-lib.setFileNameAndVersion(QLatin1String("GL"), 1);
+lib.setFileName(QLatin1String("GL"));
 glXGetProcAddressARB = (qt_glXGetProcAddressARB) 
lib.resolve("glXGetProcAddressARB");
 #endif
 }

Bug#913286: nmu: libre-engine-re2-perl_0.13-2

[gregor herrmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu libre-engine-re2-perl_0.13-2 . i386 arm64 armel mips ppc64el s390x . 
unstable . -m "Rebuild against perl 5.28."

Cf. #913278.
Looks like the package was uploaded during the perl 5.26 → 5.28
transition and hit some updated and some outdated mirrors.

I guess --extra-depends 'perl-base (>= 5.28)' shouldn't be needed
anymore at that point?

Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlvk0QxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYUZxAAghri7s7s88e6VrO4W2YhN86wFPyLx6k0rkZbse5DY64v0TjxuDWTtzLv
Hi8WSKEtprUgwxlbPKOc4IQE1+leoCPydL1Zfr0faTOTw5riR998tAJYhs2oKnS6
j8XLhpcJPAq59tnWa1bVTDGk+G8SihUdOi1xZJNj/mp6WCWMs1ZV8tCT2YDT5vDn
WrqlAEsTsEEsGHnQyvjn7UIlI69oPBaLUvlz/N1ZlLli1+QLo6d9JdHNgR8W1gEh
82sHAJVffoy2YVP4GeeQ7NIq1Lhbk+bjXMQSmrbyZyRx7X4a8CTzHz0tuDYbGmbj
5lc6zmWmcJjIZXaJnno6dR2rW778Ug79/lu+H+Hs36y3GFxlMlMR1W6PI0eshyMC
9s4cIKkrvV6roGlQUccjTOgZWx6L4IFdKbbktySftFyT04MUbJt0/Q0nawgO6Pgb
f+hX0sV6pl+DnOmcZasqvcCVBWl+O9pnvP4PHFDjlBVU1e1KRN3eXyHl5ZFQwvI0
5BFxVSDmZLLASGyS2FRENyyCy38eLUfFGwT81+R35YMYe8Drt6iEd0XkLGJKdNYk
Z2Dl9BIyab+ypq0cYymOn6PKHwnKcKJXTezPh3Ni72RrnNaddSIn95iPSOrhTyFt
PZ0ULpBIwDajRoWNjiBRhcg3ao135HHzCFzKI6PVqpb6HP+tw8w=
=GrAI
-END PGP SIGNATURE-

Bug#913285: RFP: oxipng -- Parallel lossless PNG compression optimizer

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: oxipng
  Version : 2.1.5
  Upstream Author : Joshua Holmer 
* URL : https://github.com/shssoichiro/oxipng
* License : MIT
  Programming Lang: Rust
  Description : Parallel lossless PNG compression optimizer

Oxipng optimizes PNG images to make them use less storage and bandwidth.
In parallel, oxipng evaluates possible PNG encoding parameters, zlib
DEFLATE encoding parameters, and optionally Zopfli-optimized DEFLATE
encoding parameters, writing out the optimized image that uses the least
storage and bandwidth.

Bug#913048: hy 0.15.0 fails to install for Python2

[Jakub Wilk]

* Matthias Klose , 2018-11-06, 12:15:

Version: 0.15.0


There's no such version of hy in Debian.


Version: serious


Ditto.


 File "/home/packages/tmp/p/hy-0.15.0/hy/compiler.py", line 42, in ast_str
   x = mangle(x)
 File "/home/packages/tmp/p/hy-0.15.0/hy/lex/parser.py", line 67, in mangle
   assert isidentifier(s)
AssertionError


This is fallout after the fix for https://bugs.python.org/issue33899 
was backported to 2.7. This backport was deemed too disruptive and was 
eventually reverted upstream.


--
Jakub Wilk

Bug#913284: webext-debianbuttons: icon is hard to see in the default Firefox theme

[Paul Wise]

Package: webext-debianbuttons
Version: 2.2-1
Severity: normal
Usertags: accessibility

The icon is coloured white, which is really hard to see in the default
Firefox ESR theme. Even when the icon is highlighted with mouseover it
is still fairly hard to see.

I'd suggest using the standard Debian logo colours for the icon
instead. I've attached screenshots of the icon to illustrate exactly
how hard to see it is.

https://www.debian.org/logos/
https://wiki.debian.org/DebianLogo

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages webext-debianbuttons depends on:
ii  firefox  63.0.1-1
ii  firefox-esr  60.3.0esr-1

webext-debianbuttons recommends no packages.

webext-debianbuttons suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#913282: libsane-common: delete obsolete /usr/share/hal directory

[Paul Wise]

Package: libsane-common
Version: 1.0.25-4.1
Severity: normal
Usertags: obsolete

Please delete the obsolete /usr/share/hal directory, hal was removed
from Debian and is no longer present in any supported Debian release.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libsane-common depends on:
ii  dpkg  1.19.2

libsane-common recommends no packages.

libsane-common suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#913283: libmtp-common: delete obsolete /usr/share/hal directory

[Paul Wise]

Package: libmtp-common
Version: 1.1.13-1
Severity: normal
Usertags: obsolete

Please delete the obsolete /usr/share/hal directory, hal was removed
from Debian and is no longer present in any supported Debian release.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#913279: libmtp9: does not provide udev rules nor run mtp-probe, move Recommends to libmtp-common

[Paul Wise]

Package: libmtp9
Version: 1.1.13-1
Severity: normal

The libmtp9 package does not provide udev rules nor run mtp-probe
AFAICT, so it should not Recommends: libmtp-runtime, udev.

That should be moved to the libmtp-common package, which provides some
udev rules that run mtp-probe.

I'd argue that libmtp-common should actually depend on libmtp-runtime
or subsume the mtp-probe binary since the binary is tiny compared to
the rest of the libmtp-common package.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libmtp9 depends on:
ii  dpkg   1.19.2
ii  libc6  2.27-8
ii  libgcrypt201.8.4-3
ii  libmtp-common  1.1.13-1
ii  libusb-1.0-0   2:1.0.22-2

Versions of packages libmtp9 recommends:
pn  libmtp-runtime  
ii  udev239-11

libmtp9 suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#913281: ntfs-3g: delete obsolete /usr/share/hal directory

[Paul Wise]

Package: ntfs-3g
Version: 1:2017.3.23-2
Severity: normal
Usertags: obsolete

Please delete the obsolete /usr/share/hal directory, hal was removed
from Debian and is no longer present in any supported Debian release.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ntfs-3g depends on:
ii  fuse   2.9.8-2
ii  libc6  2.27-8
ii  libgcrypt201.8.4-3
ii  libgnutls303.5.19-1+b1
ii  libgpg-error0  1.32-3
ii  libntfs-3g88   1:2017.3.23-2

ntfs-3g recommends no packages.

ntfs-3g suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#913280: lintian: please warn about packages including files in /usr/share/hal/ (used by obsolete hal package)

[Paul Wise]

Package: lintian
Version: 2.5.111
Severity: wishlist
Usertags: obsolete

Three packages install files in /usr/share/hal/ but this directory is
no longer looked at by any package in Debian since hal was removed in
2014 because it was replaced by udev. I will file bugs on the three
affected packages but it would be good for lintian to warn about use of
/usr/share/hal/ so that no new or updated packages add files there.

https://bugs.debian.org/747662

$ apt-file search /usr/share/hal/
libmtp-common: /usr/share/hal/fdi/information/20thirdparty/20-libmtp9.fdi
libsane-common: /usr/share/hal/fdi/preprobe/10osvendor/20-libsane.fdi
ntfs-3g: /usr/share/hal/fdi/policy/10osvendor/25-ntfs-3g-policy.fdi

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-7
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-8
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.74+repack-1+b1
ii  man-db 2.8.4-2+b1
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.28.0-3
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-7
ii  dpkg-dev   1.19.2
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.53-1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#913278: libre-engine-re2-perl: Uninstallable on multiple architectures due to being built against Perl 5.26

[Axel Beckert]

Package: libre-engine-re2-perl
Version: 0.13-2
Severity: serious

Hi,

libre-engine-re2-perl version 0.13-2 is uninstallable on i386 since it
is compiled against Perl 5.26:

→ apt-cache show libre-engine-re2-perl | egrep 'Package:|Version:|Depends'
Package: libre-engine-re2-perl
Version: 0.13-2
Depends: perl (>= 5.26.2-7+b1), perlapi-5.26.2, libc6 (>= 2.4), libgcc1 (>= 
1:3.0), libre2-4 (>= 20160901), libstdc++6 (>= 5.2)

According to https://tracker.debian.org/pkg/libre-engine-re2-perl this
also affects the architectures arm64, armel, mips, ppc64el and s390x.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: i386 (x86)

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277

I do not have '.asoundrc' or any special config file for 'moc' or system sound.

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

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

Versions of packages moc depends on:
ii  libasound21.1.7-1
ii  libc6 2.27-8
ii  libcurl3-gnutls   7.62.0-1
ii  libdb5.3  5.3.28+dfsg1-0.2
ii  libfaad2  2.8.8-1
ii  libflac8  1.3.2-3
ii  libgcc1   1:8.2.0-9
ii  libid3tag00.15.1b-13
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libltdl7  2.4.6-6
ii  libmad0   0.15.1b-9
ii  libmagic1 1:5.34-2
ii  libmodplug1   1:0.8.9.0-2
ii  libmpcdec62:0.1~r495-1+b2
ii  libncursesw6  6.1+20181013-1
ii  libogg0   1.3.2-1+b1
ii  libopusfile0  0.9+20170913-1
ii  libpopt0  1.16-11
ii  librcc0   0.2.12-0.1
ii  libresid-builder0c2a  2.1.1-15
ii  libsamplerate00.1.9-2
ii  libsidplay2   2.1.1-15
ii  libsidutils0  2.1.1-15
ii  libsndfile1   1.0.28-4
ii  libspeex1 1.2~rc1.2-1+b2
ii  libstdc++68.2.0-9
ii  libtagc0  1.11.1+dfsg.1-0.2+b1
ii  libtinfo6 6.1+20181013-1
ii  libvorbis0a   1.3.6-1
ii  libvorbisfile31.3.6-1
ii  libwavpack1   5.1.0-4
ii  zlib1g1:1.2.11.dfsg-1

moc recommends no packages.

Versions of packages moc suggests:
ii  moc-ffmpeg-plugin  1:2.6.0~svn-r2984-1

-- no debconf information

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Severity: important

Dear Maintainer,

Until yesterday 'moc' worked just fine. But now when I start it I get:

"mocp -D
Loading plugins from /usr/lib/x86_64-linux-gnu/moc/decoder_plugins...
Loading plugin libaac_decoder...
OK
Loading plugin libffmpeg_decoder...
OK
Loading plugin libflac_decoder...
OK
Loading plugin libmodplug_decoder...
OK
Loading plugin libmp3_decoder...
OK
Loading plugin libmusepack_decoder...
OK
Loading plugin libopus_decoder...
OK
Loading plugin libsidplay2_decoder...
OK
Loading plugin libsndfile_decoder...
OK
Loading plugin libspeex_decoder...
OK
Loading plugin libvorbis_decoder...
OK
Loading plugin libwavpack_decoder...
OK
Running the server...
Trying JACK...
Trying ALSA...
Trying OSS...

FATAL_ERROR: No valid sound driver!


FATAL_ERROR: Server exited!"

Disabling 'pulseaudio' donot help.

Since a few days, before having the referred issue, I noticed that 'mocp' shows 
"PCM" next to volume percentage in the volume bar;
it doesn't do that previously, it always only showed volume percentage.




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

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

Versions of packages moc depends on:
ii  libasound21.1.7-1
ii  libc6 2.27-8
ii  libcurl3-gnutls   7.62.0-1
ii  libdb5.3  5.3.28+dfsg1-0.2
ii  libfaad2  2.8.8-1
ii  libflac8  1.3.2-3
ii  libgcc1   1:8.2.0-9
ii  libid3tag00.15.1b-13
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libltdl7  2.4.6-6
ii  libmad0   0.15.1b-9
ii  libmagic1 1:5.34-2
ii  libmodplug1   1:0.8.9.0-2
ii  libmpcdec62:0.1~r495-1+b2
ii  libncursesw6  6.1+20181013-1
ii  libogg0   1.3.2-1+b1
ii  libopusfile0  0.9+20170913-1
ii  libpopt0  1.16-11
ii  librcc0   0.2.12-0.1
ii  libresid-builder0c2a  2.1.1-15
ii  libsamplerate00.1.9-2
ii  libsidplay2   2.1.1-15
ii  libsidutils0  2.1.1-15
ii  libsndfile1   1.0.28-4
ii  libspeex1 1.2~rc1.2-1+b2
ii  libstdc++68.2.0-9
ii  libtagc0  1.11.1+dfsg.1-0.2+b1
ii  libtinfo6 6.1+20181013-1
ii  libvorbis0a   1.3.6-1
ii  libvorbisfile31.3.6-1
ii  libwavpack1   5.1.0-4
ii  zlib1g1:1.2.11.dfsg-1

moc recommends no packages.

Versions of packages moc suggests:
ii  moc-ffmpeg-plugin  1:2.6.0~svn-r2984-1

-- no debconf information

Bug#913189: [Pkg-tcltk-devel] Bug#913189: /usr/bin/tclsh8.6: `file delete' can produce EFAULT

[Stefan Sobernig]

Hi!

Just to be clear: The manpage of [file delete] states that

> Trying to delete a non-existent file is not considered an error.

see https://www.tcl.tk/man/tcl8.6/TclCmd/file.htm#M12

or, the Wiki states that

> If pathname is a non-existent file, nothing is done and it is not an
error.

see https://wiki.tcl-lang.org/page/file+delete

... so your expectation is that this behaviour also applies to this
EFAULT instance?

If so (I agree), you might consider opening a ticket at
https://core.tcl.tk/tcl/login?g=/tcl/tktnew

This can also be (re-)produced under macOs, FWIW:

$  rm -rf d
$ mkdir d
$ cd d
$ rm -rf ../d
$ env - pwd
pwd: .: No such file or directory
$ tclsh8.6
% pwd
error getting working directory name: no such file or directory
% file delete spong
error deleting "spong": bad address in system call argument
% exit

Stefan

Bug#904111: clamav-daemon causing deadlocks/blocking I/O

[Adam Lambert]

 I apologize for weighing in late, I saw earlier in the thread that Marc
Dequènes reported reproducing it and assumed that would be sufficient.

No, this is not solved.   I just apt upgrade'd to the latest version
(0.100.2+dfsg-0+deb9u1),
and again, within seconds, the system went down hard.

What do you need me to do to provide debug info on this?

And this is indeed a 'critical' level bug - it renders ClamAV (and the
underlying system) entirely unusable in any of the 0.100.xxx versions I've
tried.

Thanks,

On Thu, Nov 8, 2018 at 2:28 PM Sebastian Andrzej Siewior
 wrote:

> On 2018-11-03 17:11:07 [+], Scott Kitterman wrote:
> > Does anyone still have this problem with 0.100.2?  It's been out awhile
> and this bug has gone quiet.
>
> I would suggest to close it. I never had any luck to reproduce it. It
> may or may not be a problem but without any additional help to get a
> reproducer there is nothing that we can do to either fix it ourself or
> throw at upstream.
> I'm not sure if severity `critical' applies here after all.
>
> > Scott K
>
> Sebastian
>

Bug#913276: pinball: Typo in manual

[Moshe Piekarski]

Package: pinball
Version: 0.3.1-14.1
Severity: minor

Just noting that the man page has "meny" written instead of "menu" twice.

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

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

Versions of packages pinball depends on:
ii  libc6   2.27-8
ii  libgcc1 1:8.2.0-9
ii  libgl1  1.1.0-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libice6 2:1.0.9-2
ii  libltdl72.4.6-6
ii  libsdl-image1.2 1.2.12-9
ii  libsdl-mixer1.2 1.2.12-15
ii  libsdl1.2debian 1.2.15+dfsg2-4
ii  libsm6  2:1.2.2-1+b3
ii  libstdc++6  8.2.0-9
ii  pinball-data0.3.1-14.1

pinball recommends no packages.

pinball suggests no packages.

-- no debconf information

Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs

[Stuart Prescott]

Hi Marcus,

Thanks for this interesting report.

> I have come across a case where whitespace is added in
> Packages{.gz,.bz2} and I am not sure how it should be parsed.
[...]
> Should this whitespace be parsed as a paragraph delimiter?

For a Packages file, each paragraph is defined as a set of DEBIAN/control 
paragraphs; the Description field is not allowed to contain lines that are 
whitespace-only.

https://wiki.debian.org/DebianRepository/Format#A.22Packages.22_Indices

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-description

So the strict answer is yes, it should be a paragraph delimiter but most 
implementations seem to be more forgiving in what they accept.

Note that for debian/control files in source packages, whitespace-only lines 
are treated as paragraph separators so that whitespace errors in an editor 
don't accidentally make packages disappear from the archive.


> Currently, the whitespace is being treated as a paragraph delimiter,
> in python-debian, but not by apt-get, etc.

Could you expand on this with an example, perhaps?

python-debian actually uses python-apt for dealing with Sources and Packages 
files (i.e. the exact same code as apt) and already does treat whitespace-only 
lines as being part of a paragraph rather than breaking them:


$ ipython3 
Python 3.6.7 (default, Oct 21 2018, 08:08:16)  
Type "copyright", "credits" or "license" for more information. 

In [1]: from debian.deb822 import Packages 

In [2]: with open('Packages') as fh: 
  ...: for p in Packages.iter_paragraphs(fh): 
  ...: if p['Version'] == '1.25.0-1529904044': 
  ...: print(p) 
  ...:  
Package: code-insiders 
Priority: optional 
Section: devel 
Installed-Size: 213952 
Maintainer: Microsoft Corporation  
Architecture: amd64 
Version: 1.25.0-1529904044 
Replaces: visual-studio-code-insiders 
Provides: visual-studio-code-insiders 
Depends: libnotify4, libnss3, gnupg, apt, libxkbfile1, libgconf-2-4, 
libsecret-1-0, libgtk-3-0 (>= 3.10.0) 
Conflicts: visual-studio-code-insiders 
Filename: pool/main/c/code-insiders/code-insiders_1.25.0-1529904044_amd64.deb 
Size: 46342528 
MD5sum: 6cd7bbd2eebcae2ebddf95bba4627681 
SHA1: 793a36306fa6f78b7d20b1a8e99458fcdcd5221c 
SHA256: 7c75fece717778bc3fc3f86efc77c4cd7a717f05e23e3f23d86442d3c95365fc 
SHA512: 
19196ecdedd0306dcb1504d51bbb8ece9bcdac224e34623992e0cfda3fa43ed4a0def10a0200ae1b16652ec772e9265d2024f7ba80f
294e1cec57184f9213432 
Description: Code editing. Redefined. 
Visual Studio Code is a new choice of tool that combines the simplicity of a 
code editor with what developers need
for the core edit-build-debug cycle. See https://code.visualstudio.com/docs/
setup/linux for installation instructi
ons and FAQ. 
 
Homepage: https://code.visualstudio.com/ 

Cheers
Stuart


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

Bug#913275: iwd: 4-Way Handshake Failure

[Sebastian Reichel]

Package: iwd
Version: 0.10-1
Severity: normal
Tags: upstream

Hi,

I gave iwd (0.10-1 from Debian) a try on my notebook - It does not connect to
the wireless network in my hackerspace:

---
$ iwctl
[iwd]# station wlp3s0 connect mainframe
Type the network passphrase for mainframe psk.
Passphrase: *
Operation failed
---

Information from journal:

---
Nov 08 23:32:17 earth systemd[1]: Starting Wireless service...
Nov 08 23:32:17 earth iwd[16327]: No Diffie-Hellman support found, WPS will not 
be available
Nov 08 23:32:17 earth iwd[16327]: The following options are missing in the 
kernel:
Nov 08 23:32:17 earth iwd[16327]: CONFIG_KEY_DH_OPERATIONS
Nov 08 23:32:17 earth iwd[16327]: The following optimized implementations might 
be available:
Nov 08 23:32:17 earth iwd[16327]: Wireless daemon version 0.10
Nov 08 23:32:17 earth iwd[16327]: Skipping optional configuration file 
/etc/iwd/main.conf
Nov 08 23:32:17 earth systemd[1]: Started Wireless service.
Nov 08 23:32:17 earth iwd[16327]: Wiphy: 0, Name: phy0
Nov 08 23:32:17 earth iwd[16327]: Bands: 2.4 GHz 5 GHz
Nov 08 23:32:17 earth iwd[16327]: Ciphers: CCMP TKIP BIP
Nov 08 23:32:17 earth iwd[16327]: Supported iftypes: ad-hoc station ap
Nov 08 23:32:17 earth iwd[16327]: No ControlPortOverNL80211 setting, defaulting 
to False
Nov 08 23:33:15 earth iwd[16327]: 4-Way handshake failed for ifindex: 3, 
reason: 1
---

The network is provided by multiple Juniper access points (wla522 & wla532)
controlled by WLC-V MSS 9.1.6.2. wpa_supplicant (Debian 
2:2.7~git20181004+1dd66fc-1)
works as expected with the same network on the same machine:

---
$ wpa_cli -i wlp3s0 status
bssid=dc:38:e1:90:5b:c1
freq=5180
ssid=mainframe
id=18
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
---

My understanding is, that WPA2-PSK with CCMP should be supported by iwd,
so I wonder what went wrong.

-- Sebastian

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

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

Versions of packages iwd depends on:
ii  libc6 2.27-8
ii  libreadline7  7.0-5

iwd recommends no packages.

iwd suggests no packages.

-- no debconf information

Bug#911408: dnsmasq breaks systemd autopkgtest

[Michael Biebl]

Hi

Am 08.11.18 um 22:08 schrieb Simon Kelley:

> To test this, please could you apply
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a220545c4277cba534be5ef4638b5076fc7d2cf4
> 
> to 2.80 and run the test again? If that fixes the problem, I'll gladly
> take to bug back and issue a 2.80-2 with that fix.

I've tried this patch, but the result seems to be basically the same:
root@debian:~# resolvectl query kettle.cantina.company
kettle.cantina.company: resolve call failed: DNSSEC validation failed:
no-signature

root@debian:~# cat /tmp/tmpglvpfi8s/dnsmasq-vpn.log
Nov  8 22:55:47 dnsmasq[11647]: started, version 2.80 cachesize 150
Nov  8 22:55:47 dnsmasq[11647]: compile time options: IPv6 GNU-getopt
DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
loop-detect inotify dumpfile
Nov  8 22:55:47 dnsmasq[11647]: reading /etc/resolv.conf
Nov  8 22:55:47 dnsmasq[11647]: using nameserver 10.0.2.3#53
Nov  8 22:55:47 dnsmasq[11647]: read /etc/hosts - 4 addresses
Nov  8 22:57:21 dnsmasq[11647]: query[A] kettle.cantina.company from
10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: config kettle.cantina.company is 10.241.4.4
Nov  8 22:57:21 dnsmasq[11647]: query[SOA] kettle.cantina.company from
10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: config kettle.cantina.company is NODATA
Nov  8 22:57:21 dnsmasq[11647]: query[DS] kettle.cantina.company from
10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: config kettle.cantina.company is NODATA
Nov  8 22:57:21 dnsmasq[11647]: query[SOA] cantina.company from 10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: config cantina.company is NODATA
Nov  8 22:57:21 dnsmasq[11647]: query[DS] cantina.company from 10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: config cantina.company is NODATA
Nov  8 22:57:21 dnsmasq[11647]: query[SOA] company from 10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: forwarded company to 10.0.2.3
Nov  8 22:57:21 dnsmasq[11647]: query[DNSKEY] company from 10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: forwarded company to 10.0.2.3
Nov  8 22:57:21 dnsmasq[11647]: query[DS] company from 10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: forwarded company to 10.0.2.3
Nov  8 22:57:21 dnsmasq[11647]: query[DNSKEY] . from 10.241.3.1
Nov  8 22:57:21 dnsmasq[11647]: forwarded . to 10.0.2.3


> Sorry for the back-and-forth. I've not worked out how to run the systemd
> test suite and reproduce the problem here.

The easiest way is to use autopkgtest. This will ensure all necessary
dependencies are installed and the test is run in an isolated environment.

It should be possible to run this manually though, in case you are not
familiar with autopkgtest.
For that install the test dependencies:
  systemd,
  libpam-systemd,
  libnss-systemd,
  acl,
  locales,
  evemu-tools,
  python3,
  pkg-config,
  cryptsetup-bin,
  systemd-sysv,
  policykit-1,
  dnsmasq-base

Then get the systemd sources (e.g. via apt-get source systemd) and
execute test/networkd-test.py

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#911835: rss-bridge: autopkgtest needs update for new version of php-defaults

[Johannes Schauer]

Hi Ondřej,

Quoting Ondřej Surý (2018-11-07 04:42:04)
> I uploaded a fixed version, and here are the patches to be consumed by git
> am.
> 
> I unhardcoded the PHP-FPM socket path, so your package can be binNMUed for
> the future transitions.

oh wow, I just saw the new CI results and it's passing!

Amazing! Thanks for your work!! :)

Also thanks for your attached patches but since the packages uses dgit, your
changes will be automatically incorporated the next time I do "dgit clone".

cheers, josch


signature.asc
Description: signature

Bug#913205: python-urllib3: mythtv ttvdb.py fails with latest python-urllib3

[James Bottomley]

On Thu, 2018-11-08 at 23:23 +0100, Daniele Tricoli wrote:
> On 11/8/18 10:26 PM, James Bottomley wrote:
> > The reported bug is a well known API incompatibility going> from
> > urllib3 1.23 to 1.24 and affects more than just mythtv.
> 
> It's not sure that this is a bug either for mythtv, as I said, the
> problem seems to be related to that cache that use pickle.
> Could you try to clean this cache?

Yes, removing the cache directory seems to allow it to work again.

> Consider, that this bug report is the first one after the upload of
> urllib3 1.24 to experimental, then unstable and urllib3 1.24 was also
> backported in 2018-10-29.

It's not the only bug report, though.  The internet has quite a few of
them; that's how I (eventually) figured out that the version change
from 1.22 to 1.24 of urllib3 was the problem.

> > I get that at some point upstreams do daft stuff like this and a
> > distribution has to roll with it but it's only been 23 days since
> > 1.24 was released so I think debian testing could do with a little
> > more caution, at least to give all the dependent projects time to
> > update their code.
> 
> I can understand your feeling but testing is the development state of
> the next stable Debian distribution, so some breakage can happen:
> yes, I hate that too, and I try to minimize it.
> I'm sorry for you but honestly I don't understand your "debian
> testing could do with a little more caution" related to packages that
> are not even in Debian: what do you suggest, practically?

Well, the usual assumption people work under is that upgrading minor
versions doesn't break stuff ... that means you should be able to
upgrade from 1.22 to 1.24 without issue.  That, unfortunately, doesn't
seem to be true for urllib3 as the trace dump show.  I suspect the only
way you're going to find out is by bug reports like this one.  So now
you know and you think you have a cause, is there a way to prevent
other people seeing the same issue?

James


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

Bug#913138: linux: I/O on md RAID 6 hangs completely

[Stanisław]

I suffer the same problem while running RAID1 with kernel 4.18.10-2.   I have 
found a hint in the Debian kernel mailing list, however, I havent tested 
it yet:   ...Someone else suggested this might be related to using 
blk-mq, so  could you try with these parameter:   dm_mod.use_blk_mq=0 
scsi_mod.use_blk_mq=0   Also, do you have laptop-mode-tools installed?   
Ben...   Please, read:  lists.debian.org lists.debian.org  
lists.debian.org lists.debian.org  lists.debian.org lists.debian.org

Bug#904111: clamav-daemon causing deadlocks/blocking I/O

[Sebastian Andrzej Siewior]

On 2018-11-03 17:11:07 [+], Scott Kitterman wrote:
> Does anyone still have this problem with 0.100.2?  It's been out awhile and 
> this bug has gone quiet.

I would suggest to close it. I never had any luck to reproduce it. It
may or may not be a problem but without any additional help to get a
reproducer there is nothing that we can do to either fix it ourself or
throw at upstream.
I'm not sure if severity `critical' applies here after all.

> Scott K

Sebastian

Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Pedro Silva]

On Thu, 8 Nov 2018 22:00:03 + Pedro Silva 
wrote:
> On Thu, 8 Nov 2018 19:59:56 +0100 Elimar Riesebieter 
> wrote:
> > >
> > > With the $HOME/.asoundrc, pointed to card 2, the sound is back and
fully
> > > working, thank you.
> > >
> > > You mean that a minor revision to this package caused it to now
require
> > > a manual configuration file?  Why?
> >
> > Hmm, the priority of the sequence of sond devices is done by the
> > kernel (udev|systemd). If you are interested please run a test as
> > follows:
> >
> > Unplug your usb device and reboot. After reboot plug in your usb
> > device and run 'cat /proc/asound/cards'.
> >
> >
> > Boot with a plugged in usb device and run 'cat /proc/asound/cards'.
> >
> > Is there any difference?
> >
> > Elimar
> > --
> > You cannot propel yourself forward by
> > patting yourself on the back.
>
>
> No difference.
>
> As the original bug reporter, please understand that my knowledge of
> Alsa is also limited.
>
> Unplug, reboot, plug, $ cat /proc/asound/cards >
> libasound2bug_reboot_thenplug.txt.
> Reboot.
>
> $ cat /proc/asound/cards
>  0 [HDMI   ]: HDA-Intel - HDA ATI HDMI
>   HDA ATI HDMI at 0xfe96 irq 67
>  1 [Generic    ]: HDA-Intel - HD-Audio Generic
>   HD-Audio Generic at 0xfe80 irq 69
>  2 [USB    ]: USB-Audio - Razer Kraken USB
>   Razer Razer Kraken USB at usb-:09:00.3-4.3,
> full speed
>
> $ diff /proc/asound/cards libasound2bug_reboot_thenplug.txt
> [no output]
>
> My concern is the "it worked before". Anything else besides Alsa and the
> kernel that could cause this issue?
>
> Best regards,
> Pedro Silva

This is getting weird.

Even with the $HOME/.asoundrc file, I've nailed it down to not being
able to play two sound sources at the same time.

Reboot with USB card plugged, login, run game, sound works. Open browser
(firefox), open youtube, play video, doesn't play, hangs playback until
I close the game.

Close browser and game, start browser and play youtube video, everything
ok. Start game, no error message (as the subject of this bug) but no
sound whatsoever.

Needless to say that none of this happened before the upgrade. I haven't
tried to downgrade libasound2 to previous version, but I can if it helps
troubleshooting.

Best regards,
Pedro Silva

Bug#913205: python-urllib3: mythtv ttvdb.py fails with latest python-urllib3

[Daniele Tricoli]

On 11/8/18 10:26 PM, James Bottomley wrote:
> The reported bug is a well known API incompatibility going> from urllib3 1.23 
> to 1.24 and affects more than just mythtv.

It's not sure that this is a bug either for mythtv, as I said, the
problem seems to be related to that cache that use pickle.
Could you try to clean this cache?

Consider, that this bug report is the first one after the upload of
urllib3 1.24 to experimental, then unstable and urllib3 1.24 was also
backported in 2018-10-29.

> I get that at some point upstreams do daft stuff like this and a
> distribution has to roll with it but it's only been 23 days since 1.24
> was released so I think debian testing could do with a little more
> caution, at least to give all the dependent projects time to update
> their code.

I can understand your feeling but testing is the development state of
the next stable Debian distribution, so some breakage can happen: yes, I
hate that too, and I try to minimize it.
I'm sorry for you but honestly I don't understand your "debian testing
could do with a little more caution" related to packages that are not
even in Debian: what do you suggest, practically? We already have CI for
packages in the distribution, but I don't see any viable way to cover
projects not packaged in Debian.

Anyway could you clean the cache and see if mythtv works again?

Cheers,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org



signature.asc
Description: OpenPGP digital signature

Bug#913020: [Pkg-clamav-devel] Bug#913020: clamd: apparmor denials: cap net_admin, openssl.conf

[Sebastian Andrzej Siewior]

intrigeri, I added you on Cc since you were a help the last time
apparmor came around.

On 2018-11-06 10:45:15 [+0800], Paul Wise wrote:
> Package: clamav-daemon
> Version: 0.100.2+dfsg-1
> Severity: normal
> File: /etc/apparmor.d/usr.sbin.clamd
> Usertags: apparmor
> 
> When I restart clamav-daemon I get two apparmor denials in syslog:
> 
> AVC apparmor="DENIED" operation="capable" profile="/usr/sbin/clamd" pid=13277 
> comm="clamd" capability=12  capname="net_admin"
> AVC apparmor="DENIED" operation="open" profile="/usr/sbin/clamd" 
> name="/etc/ssl/openssl.cnf" pid=13277 comm="clamd" requested_mask="r" 
> denied_mask="r" fsuid=111 ouid=0

I have no idea what the first one is one about. If this is related to
#903834 then I think I know what I have to do.
The second one should be required by every application using libssl. Is
there a general rule where it could be allowed for every application to
just read the openssl.cnf file or is the clamd profile too restrictive
and not allowing it by default?

Sebastian

Bug#912634: [Pkg-clamav-devel] Bug#912634: clamav scanner didn't unpack RAR archives

['Sebastian Andrzej Siewior']

On 2018-11-06 08:41:47 [+0700], Dmitriy wrote:
> 
> Yes. I compiled deb package from source and add to Clamav daemon. After this 
> it works.
> I think in man page for clam antivirus must be menchioned that some non GNU 
> code are absent (like RAR code)
> This is be very heplfull for users to understand which function are present 
> and which are not.

There is a "Suggests" for the library. The package is only split in
Debian due to license issues. There is this "clamav-testfiles" which
contains .rar samples for testing.
Would it have helped if it would be mentioned in README.Debian? And
then I would have to check if it is possible to add a reference there…

Sebastian

Bug#903834: [Pkg-clamav-devel] Bug#903834: clamav-freshclam: AppArmor denies access to /procp//status

[Andrzej Siewior]

On 2018-11-08 19:24:28 [+0200], Vincas Dargis wrote:
> Ping?

ehm. So I assumed that I have taken care of this. But it seems I have
not. Sorry.
I doubt I can make this week and I will be gone next week but I will try
to look at this once I get back.

Should nothing happen within reasonable time feel free to ping again.

Sebastian

Bug#871056: transition: openssl

[Sebastian Andrzej Siewior]

On 2018-02-25 10:59:57 [+0100], Emilio Pozuelo Monfort wrote:
> We're getting close. According to the transition tracker, the remaining rdeps 
> in
> testing are:
…
> kopete - no fix upstream, optional for jingle (call) support in XMPP
…

This is the last one in testing. kopete's #858938 has been closed in
experimental but it never made to unstable.

> Cheers,
> Emilio

Sebastian

Bug#907219: Fwd: [ANN] M2Crypto 0.31.0 ... plenty of bugfixes (and support for OpenSSL 1.1.1)

[Kurt Roeckx]

--- Begin Message ---
Hi, everybody,

there is a new release of M2Crypto, most complete Python bindings
for OpenSSL (from 1.0.1e to 1.1.1), supporting both Python 2 (2.6
and 2.7) and Python 3 (from 3.4 upwards).

This is mostly bugfix release, including:

  - support for OpenSSL 1.1.1
  - Fixes for Windows builds
  - Fixes of installs on AWS Lambda
  - Fixes of Mac OS X related failures
  - Fix Python 2.6 compatibility issues

Support for OpenSSL 1.1.1 is just minimal, to make test suite
pass. The biggest problem is that the latest OpenSSL doesn't
raise exceptions in some situations where the earliest versions
did so. Not sure, what is the proper reaction from M2Crypto size.

Also, reminder, that we have special email list for development
of M2Crypto. Its web page is http://redcrew.org/mailman/listinfo/
m2crypto and it is mailman with the posting address
m2cry...@lists.redcrew.org so all email commands work.

All complaints, support requests, and bug reports are welcome in
the email list or on the issue tracker
https://gitlab.com/m2crypto/m2crypto/issues

Happy security hacking!

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
A man who won't die for something is not fit to live.


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

Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Pedro Silva]

On Thu, 8 Nov 2018 19:59:56 +0100 Elimar Riesebieter 
wrote:
> >
> > With the $HOME/.asoundrc, pointed to card 2, the sound is back and fully
> > working, thank you.
> >
> > You mean that a minor revision to this package caused it to now require
> > a manual configuration file?  Why?
>
> Hmm, the priority of the sequence of sond devices is done by the
> kernel (udev|systemd). If you are interested please run a test as
> follows:
>
> Unplug your usb device and reboot. After reboot plug in your usb
> device and run 'cat /proc/asound/cards'.
>
>
> Boot with a plugged in usb device and run 'cat /proc/asound/cards'.
>
> Is there any difference?
>
> Elimar
> --
> You cannot propel yourself forward by
> patting yourself on the back.


No difference.

As the original bug reporter, please understand that my knowledge of
Alsa is also limited.

Unplug, reboot, plug, $ cat /proc/asound/cards >
libasound2bug_reboot_thenplug.txt.
Reboot.

$ cat /proc/asound/cards
 0 [HDMI   ]: HDA-Intel - HDA ATI HDMI
  HDA ATI HDMI at 0xfe96 irq 67
 1 [Generic    ]: HDA-Intel - HD-Audio Generic
  HD-Audio Generic at 0xfe80 irq 69
 2 [USB    ]: USB-Audio - Razer Kraken USB
  Razer Razer Kraken USB at usb-:09:00.3-4.3,
full speed

$ diff /proc/asound/cards libasound2bug_reboot_thenplug.txt
[no output]

My concern is the "it worked before". Anything else besides Alsa and the
kernel that could cause this issue?

Best regards,
Pedro Silva

Bug#906643: Bug#911832: Bug#906643: transition: php7.3

[Ondřej Surý]

But php-defaults and rss-bridge needs to go together.

I thought that runtime detection of default PHP version in autopkgtest would be 
overkill, so the socket path is hardcoded at the build-time.

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 9 Nov 2018, at 04:47, Ondřej Surý  wrote:
> 
> Hi Paul,
> 
> 
>> On 9 Nov 2018, at 03:35, Paul Gevers  wrote:
>> 
>> You also uploaded (NMU) two revisions of rss-bridge. The last one is
>> stuck in unstable because you broke the autopkgtest. 
> 
> Umm, no?
> 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/r/rss-bridge/1281281/log.gz
> https://ci.debian.net/packages/r/rss-bridge/unstable/amd64/
> 
> I made the package binNMUable…
> 
> Also php-doctrine-data-fixture haven’t been run with php-doctrine-orm >= 
> 2.6.2+dfsg-2 yet in unstable.
> 
> In testing ci, it passes now:
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-data-fixtures/1284518/log.gz
> 
> O.
> --
> Ondřej Surý
> ond...@sury.org

Bug#906643: Bug#911832: Bug#906643: transition: php7.3

[Ondřej Surý]

Hi Paul,


> On 9 Nov 2018, at 03:35, Paul Gevers  wrote:
> 
> You also uploaded (NMU) two revisions of rss-bridge. The last one is
> stuck in unstable because you broke the autopkgtest. 

Umm, no?

https://ci.debian.net/data/autopkgtest/unstable/amd64/r/rss-bridge/1281281/log.gz
https://ci.debian.net/packages/r/rss-bridge/unstable/amd64/

I made the package binNMUable…

Also php-doctrine-data-fixture haven’t been run with php-doctrine-orm >= 
2.6.2+dfsg-2 yet in unstable.

In testing ci, it passes now:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-data-fixtures/1284518/log.gz

O.
--
Ondřej Surý
ond...@sury.org

Bug#913137: virtualbox: VirtualBox E1000 Guest-to-Host Escape

[Evgeny Kapun]

Control: severity -1 critical

Raising severity because this bug can be used by any local user to elevate 
privileges.

Also, before this bug is fixed upstream, it is possible to use this patch as a 
band-aid:

--- a/src/VBox/Devices/Network/DevE1000.cpp
+++ b/src/VBox/Devices/Network/DevE1000.cpp
@@ -4343,6 +4343,7 @@
 {
 /* Calculate how many bytes we have left in this TCP segment */
 uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen;
+if (u16MaxPktLen < pThis->u16TxPktLen) abort();
 if (cb > cbFragment)
 {
 /* This descriptor fits completely into current segment */
@@ -4409,6 +4410,7 @@
 {
 /* Calculate how many bytes we have left in this TCP segment */
 uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen;
+if (u16MaxPktLen < pThis->u16TxPktLen) abort();
 if (cb > pDesc->data.cmd.u20DTALEN)
 {
 /* This descriptor fits completely into current segment */

This will crash the hypervisor if an exploit is attempted, preventing memory 
corruption.

Also, I've attached the report, in case the original link stops working.
## Why
I like VirtualBox and it has nothing to do with why I publish a 0day vulnerability. The reason is my disagreement with contemporary state of infosec, especially of security research and bug bounty:

1) Wait half a year until a vulnerability is patched is considered fine.
2) In the bug bounty field these are considered fine:
1) Wait more than month until a submitted vulnerability is verified and a decision to buy or not to buy is made.
2) Change the decision on the fly. Today you figured out the bug bounty program will buy bugs in a software, week later you come with bugs and exploits and receive "not interested".
3) Have not a precise list of software a bug bounty is interested to buy bugs in. Handy for bug bounties, awkward for researchers.
4) Have not precise lower and upper bounds of vulnerability prices. There are many things influencing a price but researchers need to know what is worth to work on and what is not.
3) Delusion of grandeur and marketing bullshit: naming vulnerabilities and creating websites for them; making a thousand conferences in a year; exaggerating importance of own job as a security researcher; considering yourself "a world saviour". Come down, Your Highness.

I'm exhausted of the first two, therefore my move is full disclosure. Infosec, please move forward.

## General Information
**Vulnerable software:** VirtualBox 5.2.20 and prior versions.

**Host OS:** any, the bug is in a shared code base.

**Guest OS:** any.

**VM configuration:** default (the only requirement is that a network card is Intel PRO/1000 MT Desktop (82540EM) and a mode is NAT).

## How to protect yourself
Until the patched VirtualBox build is out you can change the network card of your virtual machines to PCnet (either of two) or to Paravirtualized Network. If you can't, change the mode from NAT to another one. The former way is more secure.

## Introduction
A default VirtualBox virtual network device is Intel PRO/1000 MT Desktop (82540EM) and the default network mode is NAT. We will refer to it E1000.

The E1000 has a vulnerability allowing an attacker with root/administrator privileges in a guest to escape to a host ring3. Then the attacker can use existing techniques to escalate privileges to ring 0 via /dev/vboxdrv.

## Vulnerability Details

### E1000 101
To send network packets a guest does what a common PC does: it configures a network card and supplies network packets to it. Packets are of data link layer frames and of other, more high level headers. Packets supplied to the adaptor are wrapped in Tx descriptors (Tx means transmit). The Tx descriptor is data structure described in the 82540EM datasheet (317453006EN.PDF, Revision 4.0). It stores such metainformation as packet size, VLAN tag, TCP/IP segmentation enabled flags and so on.

The 82540EM datasheet provides for three Tx descriptor types: legacy, context, data. Legacy is deprecated I believe. The other two are used together. The only thing we care of is that context descriptors set the maximum packet size and switch TCP/IP segmentation, and that data descriptors hold physical addresses of network packets and their sizes. The data descriptor's packet size must be lesser than the context descriptor's maximum packet size. Usually context descriptors are supplied to the network card before data descriptors.

To supply Tx descriptors to the network card a guest writes them to Tx Ring. This is a ring buffer residing in physical memory at a predefined address. When all descriptors are written down to Tx Ring the guest updates E1000 MMIO TDT register (Transmit Descriptor Tail) to tell the host there are new descriptors to handle.

### Input
Consider the following array of Tx descriptors:

```
[context_1, data_2, data_3, context_4, data_5]
```

Let's assign their structure fields as follows (field names are 

Bug#913122: remmina-plugin-rdp: ERRCONNECT_TLS_CONNECT_FAILED with libssl1.1 1.1.1-2

[Mike Gabriel]

HI,

On  Mi 07 Nov 2018 09:02:11 CET, Matsievskiy S.V. wrote:


Package: remmina-plugin-rdp
Version: 1.2.32+dfsg-2
Severity: important

Dear Maintainer,

remmina-plugin-rdp seems to be affected by issue, described in bug  
#912206 for freerdp2-x11.

Original report:


Package: freerdp2-x11
Version: 2.0.0~git20180411.1.7a7b1802+dfsg1-2+b1
Severity: normal

Dear Maintainer,

After upgrading libssl1.1 from 1.1.0h-4 to 1.1.1-1 xfreerdp is no longer
able to connect to a computer running Remote Desktop Services on Windows
Server 2008 R2 (with default settings as far as I am aware) using TLS
security.  Connection fails with the following messages:

[ERROR][com.freerdp.core] - freerdp_set_last_error
ERRCONNECT_TLS_CONNECT_FAILED [0x00020008]
[ERROR][com.freerdp.core.connection] - Error: protocol security
negotiation or connection failure

Downgrading libssl1.1 to 1.1.0h-4 fixes the issue.  To further diagnose
the cause, I noticed that the server sends TCP RST in response to the
SSL Client Hello message.  After some trial and error, I determined that
this occurs whenever rsa_pkcs1_sha1 in not the offered signature
algorithms, which is the case for SECLEVEL=2 which is the default in the
libssl1.1 Debian package since version 1.1.1~~pre6-1.  To confirm, this
fails:

openssl s_client -connect 192.168.0.2:3389

while this works:

openssl s_client -cipher DEFAULT@SECLEVEL=1 -connect 192.168.0.2:3389

For further confirmation that rsa_pkcs1_sha1 is responsible, this works:

openssl s_client -cipher DEFAULT@SECLEVEL=1 -sigalgs
rsa_pkcs1_sha1 -connect 192.168.0.2:3389

while this fails:

openssl s_client -cipher DEFAULT@SECLEVEL=1 -sigalgs
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:DSA+SHA1:ECDSA+SHA1  
-connect

192.168.0.2:3389

Applying this discovery, it is possible to make xfreerdp work using:

xfreerdp /tls-ciphers:DEFAULT@SECLEVEL=1

However, since most users are unlikely to figure this out on their own,
I'd suggest calling SSL_CTX_set_security_level to set the security level
to 1 or improving the error message to suggest this workaround.

Thanks,
Kevin




This issue is probably fixed my today's freerdp2 upload to unstable  
(2.0.0~git20180411.1.7a7b1802+dfsg1-3).


Please check and report back. Thanks!

Mike (co-maintainer+uploader of freerdp2 in Debian)
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

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



pgp6BPWzLixF1.pgp
Description: Digitale PGP-Signatur

Bug#909356: iwd 0.8 not compatible with NM < 1.14

[Ivo De Decker]

Hi Andreas,

On Sat, Sep 22, 2018 at 11:22:07AM +0200, Andreas Henriksson wrote:
> This bug report should be closed once we have network-manager 1.14 in
> testing/buster.

This is now the case. I'm not closing the bug, however, because it's probably
best to add the breaks Adrian suggested, to avoid the installation of the
newer version of iwd with an older version of network-manager that isn't
compatible with it.

Thanks,

Ivo

Bug#913205: python-urllib3: mythtv ttvdb.py fails with latest python-urllib3

[James Bottomley]

On Thu, 2018-11-08 at 22:10 +0100, Daniele Tricoli wrote:
> Thanks for your report!
> Unfortunately package from deb-multimedia.org are not official, so
> you should ask to deb-multimedia.org maintainers as reported in their
> FAQ

I don't think this is necessarily their fault.  The reported bug is a
well known API incompatibility going from urllib3 1.23 to 1.24 and
affects more than just mythtv.

I get that at some point upstreams do daft stuff like this and a
distribution has to roll with it but it's only been 23 days since 1.24
was released so I think debian testing could do with a little more
caution, at least to give all the dependent projects time to update
their code.

James


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

Bug#913099: Thank you

[Felix Lechner]

Hi,

Thank you for sending the patch. We adopted all your changes except
for the architecture restriction on 'files-multiarch-foreign-files'.
(The issue may not be related to #886163.) Instead, the previous
behavior should be restored with this commit:

https://salsa.debian.org/lintian/lintian/commit/1b886506df601e2235a7ba0b9ab80e5ee0e8889d#756caf68255acd27da6501c989bfd38778f890e0_5_5

Thank you!

Kind regards,
Felix Lechner

Bug#913099: lintian: autopkgtests fail on !(amd64)

[Chris Lamb]

tags 913099 + pending
thanks

Merged https://salsa.debian.org/lintian/lintian/merge_requests/71
into Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/4326d7d416d482bbda7ae550097b2e2ac297d416

  debian/changelog  | 2 ++
  t/tests/binaries-missing-lfs/debian/debian/compat | 1 +
  t/tests/binaries-missing-lfs/desc | 4 +++-
  t/tests/binaries-missing-lfs/tags | 1 +
  t/tests/shared-libs-non-pic-i386/debian/debian/compat | 1 +
  t/tests/shared-libs-non-pic-i386/desc | 4 +++-
  t/tests/shared-libs-non-pic-i386/tags | 1 +
  7 files changed, 12 insertions(+), 2 deletions(-)


Regards,

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

Bug#913205: python-urllib3: mythtv ttvdb.py fails with latest python-urllib3

[Daniele Tricoli]

Thanks for your report!
Unfortunately package from deb-multimedia.org are not official, so you
should ask to deb-multimedia.org maintainers as reported in their FAQ

https://www.deb-multimedia.org/faq#q5

On 11/8/18 2:44 AM, James Bottomley wrote:
> Package: python-urllib3
> Version: 1.24-1
> Severity: important
> 
> Mythtv version 29.1+fixes20180821.gite5fc66e822-dmo2 is failing with

> mythtv@vito:~$ /usr/share/mythtv/metadata/Television/ttvdb.py -B Superstore
> Traceback (most recent call last):
>   File "/usr/share/mythtv/metadata/Television/ttvdb.py", line 2578, in 
> 
> sys.exit(main())
>   File "/usr/share/mythtv/metadata/Television/ttvdb.py", line 2278, in main
> userkey=tvdb_account.account_identifier)
>   File "/usr/lib/python2.7/dist-packages/MythTV/ttvdb/tvdb_api.py", line 693, 
> in __init__
> self.session.remove_expired_responses()
>   File "/usr/lib/python2.7/dist-packages/requests_cache/core.py", line 159, 
> in remove_expired_responses
> self.cache.remove_old_entries(datetime.utcnow() - 
> self._cache_expire_after)
>   File "/usr/lib/python2.7/dist-packages/requests_cache/backends/base.py", 
> line 110, in remove_old_entries
> response, created_at = self.responses[key]
>   File 
> "/usr/lib/python2.7/dist-packages/requests_cache/backends/storage/dbdict.py", 
> line 163, in __getitem__
> return pickle.loads(bytes(super(DbPickleDict, self).__getitem__(key)))
> ImportError: No module named ordered_dict
> 
> Meaning that mythtv can no longer pick up programme information from 
> thetvdb.org
> 
> Falling back to version 1.22-1 makes everything work again.

Befor reporting a bug to deb-multimedia maintainers you should try to
clean the cache: the only thing that came in my mind related to
ordered_dict module is that urllib3 dropped Python2.6 support, and
urllib3.packages.ordered_dict module was removed:

https://github.com/urllib3/urllib3/commit/cb2159878f8b47c5b4bc6d159ae2857b85c0a197

but in the traceback there is a pickle.loads() invocation.

Hope this help!

Regards!

P.S. this is not a Debian bug, but I will wait your reply for a few days
before closing it.

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org



signature.asc
Description: OpenPGP digital signature

Bug#901578: opa-basic-tools

[Brian Smith]

> This is not the case with other Linux flavors, such as RHEL. Perhaps there is 
> a
> rules.d file that is missing?

For clarification, this statement was made regarding the
opa-basic-tools package delivered by Intel's IFS distribution for
RHEL.

RHEL's in-box opa-basic-tools exhibits the same behavior described by this bug.

-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#913091: RFS: scdoc/1.5.2-1

[Birger Schacht]

Hi,

On 11/08/2018 12:48 PM, Dmitry Bogatov wrote:
> 
> [2018-11-06 22:03] Birger Schacht 
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "scdoc"
>>
>> * Package name : scdoc
>>   Version  : 1.5.2-1
>>   Upstream Author  : Drew DeVault
>> * Url  : https://git.sr.ht/~sircmpwn/scdoc
>> * Licenses : MIT
>>   Programming Lang : C
>>   Section  : text
>>
>>  scdoc is a tool designed to make the process of writing man pages more
>>  friendly. It reads scdoc syntax from stdin and writes roff to stdout,
>>  suitable for reading with *man*(1).
>>  scdoc is a build dependency for swaywm.
> 
> Here is my review for commit (6b2f11).

Thanks for your feedback! I've adjusted the files accordingly, pushed
dddbe9 to salsa and uploaded a new package to mentors.

cheers,
Birger


> 
> What stops me from uploading
> 
> 
>  * I believe using *such* notation in package description is bad idea;
>it is confusing to those, who are not accustomized to markdown, and
>is not processed specially by tools.
> 
>  * There is unused comment in `debian/watch'
> 
>  * There is commented debian/source/local-options
> 
> Minor suggestions
> -
> 
>  * Consider adding 'Upstream-Author' into `debian/copyright'
> 
>  * You may want add 'Rules-Requires-Root: no' field into `debian/control'
> 
>  * I prefer use of parensis: (Closes: #00)
> 



signature.asc
Description: OpenPGP digital signature

Bug#913274:

[Marcus Furlong]

Example to find the stanzas with extra whitespace:

# curl -s 
http://packages.microsoft.com/repos/vscode/dists/stable/main/binary-amd64/Packages
| grep -n -H "^ $"
(standard input):3485:
(standard input):3780:
(standard input):3802:
(standard input):3824:
(standard input):3846:
(standard input):3868:
(standard input):3890:
(standard input):3912:
(standard input):3934:
(standard input):3956:
(standard input):3978:
(standard input):4000:

-- 
Marcus Furlong

Bug#756117: Resurrecting patch-tracker.d.o

[Petter Reinholdtsen]

What about linking to the patches like packages.qa.debian.org is doing
it, ie via https://sources.debian.org/patches/ ?  See for example
https://packages.qa.debian.org/c/conv-tools.html > for a package
with the patches linked to from the info page.

-- 
Happy hacking
Petter Reinholdtsen

Bug#911408: dnsmasq breaks systemd autopkgtest

[Simon Kelley]

On 07/11/2018 15:17, Michael Biebl wrote:
> Hi Simon,
> 
> I see that you reassigned this back to systemd, but I know too little
> about DNS(SEC) to assess the situation. So your help on this issue would
> be most welcome.
> 
> What I did is, to run the test against v2.79 and v2.80
> 
> This starts a dnsmasq process like this:
> nobody   11531  0.0  0.3  25260  3316 pts/1S+   23:10   0:00 dnsmasq
> --keep-in-foreground --log-queries
> --log-facility=/tmp/tmp3_id7zsx/dnsmasq-vpn.log --conf-file=/dev/null
> --dhcp-leasefile=/dev/null --bind-interfaces --interface=testvpnrouter
> --except-interface=lo --address=/math.lab/10.241.3.3
> --address=/cantina.company/10.241.4.4
> 
> With v2.79 I get the following in the log files:
> 
> # resolvectl query kettle.cantina.company
> kettle.cantina.company: 10.241.4.4
> 
> -- Information acquired via protocol DNS in 3.6ms.
> -- Data is authenticated: no
> 
> # cat /tmp/tmp3_id7zsx/dnsmasq-vpn.log
> Nov  6 23:10:39 dnsmasq[11531]: started, version 2.79 cachesize 150
> Nov  6 23:10:39 dnsmasq[11531]: compile time options: IPv6 GNU-getopt
> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> loop-detect inotify
> Nov  6 23:10:39 dnsmasq[11531]: reading /etc/resolv.conf
> Nov  6 23:10:39 dnsmasq[11531]: using nameserver 10.0.2.3#53
> Nov  6 23:10:39 dnsmasq[11531]: read /etc/hosts - 4 addresses
> Nov  6 23:17:38 dnsmasq[11531]: query[A] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:17:38 dnsmasq[11531]: config kettle.cantina.company is 10.241.4.4
> Nov  6 23:17:38 dnsmasq[11531]: query[A] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:17:38 dnsmasq[11531]: config kettle.cantina.company is 10.241.4.4
> 
> # journalctl -u systemd-resolved
> Nov 06 23:17:38 debian systemd-resolved[11545]: Using degraded feature
> set (UDP) for DNS server 10.241.3.1.
> Nov 06 23:17:38 debian systemd-resolved[11545]: Server 10.241.3.1 does
> not support DNSSEC, downgrading to non-DNSSEC mode.
> 
> 
> With v2.80
> ==
> nobody   1  0.0  0.3  25280  3328 pts/1S+   23:29   0:00 dnsmasq
> --keep-in-foreground --log-queries
> --log-facility=/tmp/tmpf3unvou5/dnsmasq-vpn.log --conf-file=/dev/null
> --dhcp-leasefile=/dev/null --bind-interfaces --interface=testvpnrouter
> --except-interface=lo --address=/math.lab/10.241.3.3
> --address=/cantina.company/10.241.4.4
> 
> # resolvectl query kettle.cantina.company
> kettle.cantina.company: resolve call failed: DNSSEC validation failed:
> no-signature
> 
> # cat /tmp/tmpf3unvou5/dnsmasq-vpn.log
> Nov  6 23:29:09 dnsmasq[1]: started, version 2.80 cachesize 150
> Nov  6 23:29:09 dnsmasq[1]: compile time options: IPv6 GNU-getopt
> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> loop-detect inotify dumpfile
> Nov  6 23:29:09 dnsmasq[1]: reading /etc/resolv.conf
> Nov  6 23:29:09 dnsmasq[1]: using nameserver 10.0.2.3#53
> Nov  6 23:29:09 dnsmasq[1]: read /etc/hosts - 4 addresses
> Nov  6 23:29:56 dnsmasq[1]: query[A] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: config kettle.cantina.company is 10.241.4.4
> Nov  6 23:29:56 dnsmasq[1]: query[SOA] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: config kettle.cantina.company is NODATA
> Nov  6 23:29:56 dnsmasq[1]: query[DS] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: config kettle.cantina.company is NODATA
> Nov  6 23:29:56 dnsmasq[1]: query[SOA] cantina.company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: config cantina.company is NODATA
> Nov  6 23:29:56 dnsmasq[1]: query[DS] cantina.company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: config cantina.company is NODATA
> Nov  6 23:29:56 dnsmasq[1]: query[SOA] company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: forwarded company to 10.0.2.3
> Nov  6 23:29:56 dnsmasq[1]: query[DNSKEY] company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: forwarded company to 10.0.2.3
> Nov  6 23:29:56 dnsmasq[1]: query[DS] company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: forwarded company to 10.0.2.3
> Nov  6 23:29:56 dnsmasq[1]: query[DNSKEY] . from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[1]: forwarded . to 10.0.2.3
> 
> # journalctl -u systemd-resolved
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question cantina.company IN DS: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question cantina.company IN SOA: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question kettle.cantina.company IN DS: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question kettle.cantina.company IN SOA: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question kettle.cantina.company IN A: no-signature
> 
> So 

Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs

[Marcus Furlong]

Package: python-debian
Version: 0.1.33

I have come across a case where whitespace is added in
Packages{.gz,.bz2} and I am not sure how it should be parsed.
Currently, the whitespace is being treated as a paragraph delimiter,
in python-debian, but not by apt-get, etc.

See, for example, line 3780 of

http://packages.microsoft.com/repos/vscode/dists/stable/main/binary-amd64/Packages

Should this whitespace be parsed as a paragraph delimiter?
-- 
Marcus Furlong

Bug#913273: exiv2: CVE-2018-19107

[Salvatore Bonaccorso]

Source: exiv2
Version: 0.25-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/Exiv2/exiv2/issues/427

Hi,

The following vulnerability was published for exiv2, it has actually
the same root cause as CVE-2018-19108 and fixed with same patch, but
given two distinct issue and as well reported in different issues
upstream, filling a different bug in downstream as well.

CVE-2018-19107[0]:
| In Exiv2 0.26, Exiv2::IptcParser::decode in iptc.cpp (called from
| psdimage.cpp in the PSD image reader) may suffer from a denial of
| service (heap-based buffer over-read) caused by an integer overflow via
| a crafted PSD image file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19107
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19107
[1] https://github.com/Exiv2/exiv2/issues/427
[2] https://github.com/Exiv2/exiv2/pull/518

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#913272: exiv2: CVE-2018-19108

[Salvatore Bonaccorso]

Source: exiv2
Version: 0.25-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/Exiv2/exiv2/issues/426

Hi,

The following vulnerability was published for exiv2.

CVE-2018-19108[0]:
| In Exiv2 0.26, Exiv2::PsdImage::readMetadata in psdimage.cpp in the PSD
| image reader may suffer from a denial of service (infinite loop) caused
| by an integer overflow via a crafted PSD image file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19108
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19108
[1] https://github.com/Exiv2/exiv2/issues/426
[2] https://github.com/Exiv2/exiv2/pull/518

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#906643: Bug#911832: Bug#906643: transition: php7.3

[Paul Gevers]

Hi Ondřej,

On 07-11-18 20:48, Ondřej Surý wrote:
> I solved the doctrine bug, but php-symfony-polyfill 1.10.0 turned out to be 
> harder nut to crack:
> 
> For reference:
> 
> 1. I removed references for Normalizer::NONE as they were testing if the code 
> would "assert" (whatever that means in this context)
> 2. There was mismatch between declaration of warning() function in 
> TestListener
> 3. I commented out all IDNA2003 tests as I suspect that something has moved 
> to IDNA2008 and that's causing failure
> 
> And then it started to be beyond my current understanding of the code and the 
> amount of time I would like to spend fixing it.

You also uploaded (NMU) two revisions of rss-bridge. The last one is
stuck in unstable because you broke the autopkgtest. On top of that, the
autopkgtest in testing (your first version) still fails with
php-defaults, but passes otherwise.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

Hi,

On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> We were again biten by this issue for some security-updates (most
> recent one nginx). Do any involved parties know, was there any
> progress in adressing this problem? 

in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
wrote:

   Perhaps the simplest and more correct might be to name it using
   something like source+amd64 as the arch name, which seems like a
   dubious arch, but at least is accurate and might be trivial to
   implement, taking care of not ending up with such fake arch in
   unexpected places…

and I cannot find anything wrong with this simple solution and have
already asked Guillem in August to implement this ;)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#913271: segfault - broken rust compiling

[Sylvestre Ledru]

Le 08/11/2018 à 21:30, jnq...@gmail.com a écrit :
> Package: llvm-7
> Version: 1:7.0.1~+rc2-1
> Severity: grave
>
> I've just updated my Sid install and found that building Rust crates
> with Cargo now fails with a seg fault.
>
> Initially I fired a bug report at cargo to kick things off, but I've
> now discovered that it relates to the llvm-7 update, as switching llvm7
> packages back to testing versions fixes the problem.

Do you have more info than "it segfaults"?

S

Bug#911580: [britney2] missing trigger with breaks relationship

[Niels Thykier]

Paul Gevers:
> Hi Gianfranco,
> 
> On Mon, 22 Oct 2018 09:45:28 +0200 Gianfranco Costamagna
>  wrote:
>> As said, britney fails to add the appropriate trigger for virtualbox
>> when a major release is out, and for this reason the ext-pack fails to
>> install reliably on ci.d.o without additional manual triggers.
>>
>> "virtualbox (>= 5.2.20-dfsg-0~) | virtualbox-5.2,  virtualbox (<< 
>> 5.2.20-dfsg-z) | virtualbox-5.2"
>>
>> should be a valid relationship.
> 
> I am staring at the britney2 code at
> https://salsa.debian.org/release-team/britney2/blob/master/britney2/installability/builder.py#L77
> and it seems there is code available to do this correctly, except it
> only does that for cases where there is no alternative (len(block) ==
> 1). I'll try to generate a test case in the test suite for this.
> 
> [...]
> 
> Paul
> 

Fair warning; I am not sure there *is* a correct solution for
"len(block) > 1" in the general case (and much less an efficient one at
that).  It is likely going to be very difficult and expensive with
almost no return for the effort.

Thanks,
~Niels

Bug#889885: [Pkg-libvirt-maintainers] Bug#889885: reassign to qemu?

[Guido Günther]

Hi,
On Thu, Nov 08, 2018 at 12:22:30PM -0700, dann frazier wrote:
> I think virt-manager maybe too high up the stack for this
> dependency. I mean, it doesn't depend on seabios either - but that
> gets installed through the dependency chain. It also isn't possible
> for an architecture-independent package to depend on the correct EFI
> firmware package for the target architecture (e.g. x86 wants ovmf, but
> arm64 wants qemu-efi-aarch64).
> 
> I propose we reassign this to qemu, and ask that:
>  1) qemu-system-x86 bump the ovmf relationship from suggests to
>recommends. I wonder if the "suggests" decision was made back when
>edk2 was non-free?
>  2) qemu-system-arm replace the "qemu-efi" recommends with both
> "qemu-efi-aarch64, qemu-efi-arm". qemu-efi is now just a dummy
> package that depends on qemu-efi-aarch64.

Makes sense.
 -- Guido

Bug#913271: segfault - broken rust compiling

[jnqnfe]

Package: llvm-7
Version: 1:7.0.1~+rc2-1
Severity: grave

I've just updated my Sid install and found that building Rust crates
with Cargo now fails with a seg fault.

Initially I fired a bug report at cargo to kick things off, but I've
now discovered that it relates to the llvm-7 update, as switching llvm7
packages back to testing versions fixes the problem.

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Salvatore Bonaccorso]

Hi

We were again biten by this issue for some security-updates (most
recent one nginx). Do any involved parties know, was there any
progress in adressing this problem? 

Sorry I know, probably patches and ideas welcome, but I cannot
contribute here, take my question please just from my "users"
point of view.

Regards,
Salvatore

Bug#913270: systemc FTBFS: symbol differences

[Adrian Bunk]

Source: systemc
Version: 2.3.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=systemc=sid
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemc.html

...
   dh_makeshlibs
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libsystemc/DEBIAN/symbols doesn't match 
completely debian/libsystemc.symbols
--- debian/libsystemc.symbols (libsystemc_2.3.2-1_amd64)
+++ dpkg-gensymbolsnAEHIa   2019-12-11 14:32:31.606562882 -1200
@@ -156,6 +156,7 @@
  _ZN5sc_dt11sc_unsigned10concat_setExi@Base 2.3.2
  _ZN5sc_dt11sc_unsigned10concat_setEyi@Base 2.3.2
  _ZN5sc_dt11sc_unsigned14set_packed_repEPj@Base 2.3.2
+ _ZN5sc_dt11sc_unsigned22convert_SM_to_2C_to_SMEv@Base 2.3.2-1
  _ZN5sc_dt11sc_unsigned3setEi@Base 2.3.2
  _ZN5sc_dt11sc_unsigned4scanERSi@Base 2.3.2
  _ZN5sc_dt11sc_unsigned5clearEi@Base 2.3.2
@@ -4279,6 +4280,7 @@
  
_ZNK9tlm_utils41instance_specific_extensions_per_accessor13get_extensionEj@Base 
2.3.2
  _ZNKSt5ctypeIcE8do_widenEc@Base 2.3.2
  
_ZNSt6vectorIN5sc_dt8sc_logicESaIS1_EE17_M_realloc_insertIJRKS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 2.3.2
+ _ZNSt6vectorIN7sc_core15sc_reset_targetESaIS1_EE17_M_default_appendEm@Base 
2.3.2-1
  
_ZNSt6vectorIN7sc_core15sc_reset_targetESaIS1_EE17_M_realloc_insertIJRKS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 2.3.2
  
_ZNSt6vectorIN7sc_core17sc_process_handleESaIS1_EE17_M_realloc_insertIJRKS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 2.3.2
  _ZNSt6vectorIN7sc_core9sc_statusESaIS1_EE12emplace_backIJS1_EEEvDpOT_@Base 
2.3.2
@@ -4295,7 +4297,7 @@
  _ZNSt6vectorIPN7sc_core10sc_bind_efESaIS2_EE12emplace_backIJS2_EEEvDpOT_@Base 
2.3.2
  
(arch=any-i386)_ZNSt6vectorIPN7sc_core10sc_bind_efESaIS2_EE17_M_default_appendEj@Base
 2.3.2
  (arch=alpha any-amd64 
ia64)_ZNSt6vectorIPN7sc_core10sc_bind_efESaIS2_EE17_M_default_appendEm@Base 
2.3.2
- 
_ZNSt6vectorIPN7sc_core10sc_bind_efESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
+#MISSING: 2.3.2-1# 
_ZNSt6vectorIPN7sc_core10sc_bind_efESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
  
_ZNSt6vectorIPN7sc_core12sc_attr_baseESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
  
_ZNSt6vectorIPN7sc_core12sc_bind_elemESaIS2_EE12emplace_backIJS2_EEEvDpOT_@Base 
2.3.2
  
_ZNSt6vectorIPN7sc_core12sc_bind_elemESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
@@ -4317,6 +4319,7 @@
  (arch=alpha any-amd64 
ia64)_ZNSt6vectorIPN7sc_core17sc_thread_processESaIS2_EE17_M_default_appendEm@Base
 2.3.2
  
_ZNSt6vectorIPN7sc_core17sc_thread_processESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
  
_ZNSt6vectorIPN7sc_core17sc_thread_processESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
+ 
_ZNSt6vectorIPN7sc_core18sc_process_monitorESaIS2_EE17_M_default_appendEm@Base 
2.3.2-1
  
_ZNSt6vectorIPN7sc_core18sc_process_monitorESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
  
_ZNSt6vectorIPN7sc_core18sc_signal_inout_ifIN5sc_dt8sc_logicEEESaIS5_EE17_M_realloc_insertIJRKS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 2.3.2
  
_ZNSt6vectorIPN7sc_core18sc_signal_inout_ifIbEESaIS3_EE17_M_realloc_insertIJRKS3_EEEvN9__gnu_cxx17__normal_iteratorIPS3_S5_EEDpOT_@Base
 2.3.2
@@ -4325,6 +4328,7 @@
  
_ZNSt6vectorIPN7sc_core8sc_eventESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
  _ZNSt6vectorIPN7sc_core8sc_eventESaIS2_EED1Ev@Base 2.3.2
  _ZNSt6vectorIPN7sc_core8sc_eventESaIS2_EED2Ev@Base 2.3.2
+ _ZNSt6vectorIPN7sc_core8sc_resetESaIS2_EE17_M_default_appendEm@Base 2.3.2-1
  
_ZNSt6vectorIPN7sc_core8sc_resetESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
  
_ZNSt6vectorIPN7sc_core9sc_moduleESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
  
_ZNSt6vectorIPN7sc_core9sc_objectESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
@@ -4336,6 +4340,7 @@
  
_ZNSt6vectorIPN7sc_core9wif_traceESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.2
  
(arch=any-i386)_ZNSt6vectorIPN9tlm_utils10ispex_baseESaIS2_EE17_M_default_appendEj@Base
 2.3.2
  (arch=alpha any-amd64 
ia64)_ZNSt6vectorIPN9tlm_utils10ispex_baseESaIS2_EE17_M_default_appendEm@Base 
2.3.2
+ 
_ZNSt6vectorIPN9tlm_utils41instance_specific_extensions_per_accessorESaIS2_EE17_M_default_appendEm@Base
 2.3.2-1
  

Bug#913268: pngcrush overwrites a file in the current directory

[Nicolas George]

Package: pngcrush
Version: 1.7.85-1+b2
Severity: normal

Hi.

When using the -ow option to overwrite the source file with the modified
file, pngcrush creates a temporary file named "pngout.png" in the
current working directory. If the file already exists, it overwrites it.
This is not documented, and could cause data loss. It could even be
considered a security concern.

Also, it causes pngcrush to fail if the output is not in the same
filesystem as the current directory.

Regards,

-- 
  Nicolas George


-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (50, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pngcrush depends on:
ii  libc62.27-8
ii  libpng16-16  1.6.34-2
ii  zlib1g   1:1.2.11.dfsg-1

pngcrush recommends no packages.

pngcrush suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#913269: systemc FTBFS on !x86/arm64: configure: error: "sorry...architecture not supported"

[Adrian Bunk]

Source: systemc
Version: 2.3.2-1
Severity: important
Tags: ftbfs

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

...
checking for ar... ar
checking the archiver (ar) interface... ar
checking dependency style of g++... none
checking whether ln -s works... yes
configure: error: "sorry...architecture not supported"


configure.ac says:

  [linux|bsd|mingw|cygwin],dnl
[# check CPU architecture
 AS_CASE([${target_cpu}], dnl
   [x86_64|amd64], dnl
 [TARGET_ARCH="${TARGET_ARCH}64"
  QT_ARCH="x86_64"
  CPU_ARCH="-m64"],
   [x*86|i*86], dnl
 [QT_ARCH="iX86"
  CPU_ARCH="-m32"],
   [aarch64], dnl
 [TARGET_ARCH="linuxaarch64"
  QT_ARCH="aarch64"
  CPU_ARCH=""],
   [AC_MSG_ERROR("sorry...architecture not supported")])


With such a small set of supported architectures, please change
Architecture: to a list of actually supported architectures.

Bug#913267: ki18n FTCBFS: build dependency python3 not installable

[Helmut Grohne]

Source: ki18n
Version: 5.49.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ki18n fails to install its cross build dependencies. It requests the
host architecture python3, but that fails postinst. It actually wants to
run python3 during build, so it needs the build architcture python. That
can be achieved by annotating the dependency with :any or :native and
doing so makes ki18n cross buildable. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru ki18n-5.49.0/debian/changelog ki18n-5.49.0/debian/changelog
--- ki18n-5.49.0/debian/changelog   2018-08-17 16:18:34.0 +0200
+++ ki18n-5.49.0/debian/changelog   2018-11-08 21:02:47.0 +0100
@@ -1,3 +1,10 @@
+ki18n (5.49.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate python3 build dependency with :any. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 08 Nov 2018 21:02:47 +0100
+
 ki18n (5.49.0-1) unstable; urgency=medium
 
   * New upstream release (5.48.1).
diff --minimal -Nru ki18n-5.49.0/debian/control ki18n-5.49.0/debian/control
--- ki18n-5.49.0/debian/control 2018-08-17 16:18:34.0 +0200
+++ ki18n-5.49.0/debian/control 2018-11-08 21:02:45.0 +0100
@@ -11,7 +11,7 @@
graphviz,
libqt5sql5-sqlite,
pkg-kde-tools (>= 0.15.15ubuntu1~),
-   python3,
+   python3:any,
qtbase5-dev (>= 5.8.0~),
qtdeclarative5-dev (>= 5.8.0~),
qtscript5-dev (>= 5.8.0~),

Bug#913266: rustc fails to build many rust-* packages on arm64: LLVM ERROR: Only small and large code models are allowed on AArch64

[Adrian Bunk]

Package: rustc
Version: 1.30.0+dfsg1-2
Severity: serious

Example:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/rust-bytecount.html

...
   dh_auto_test -O--buildsystem=cargo
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ 
--print=file-names --crate-type bin --crate-type rlib --crate-type dylib 
--crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 
1)
--- stderr
LLVM ERROR: Only small and large code models are allowed on AArch64

dh_auto_test: cargo build --verbose --verbose -j8 --target 
aarch64-unknown-linux-gnu -Zavoid-dev-deps returned exit code 101
make: *** [debian/rules:3: build] Error 25

Bug#913265: update-resolv-conf: use systemd-resolve if it's available

[Simon Deziel]

Package: openvpn
Version: 2.4.6-1

Hello,

On machines using systemd-resolved, the recommended way to configure
per-link DNS and search domains is via the systemd-resolve command. As
such, I sent a merge request to implement this [1]. I'd be happy if you
could take a look at the merge request. I'll be pleased to address any
comments you may have about it.

Regards,
Simon

1: https://salsa.debian.org/debian/openvpn/merge_requests/2

Bug#913260: llvm-toolchain-7: Please drop sparc* from BINUTILS_GOLD_ARCHS

[Sylvestre Ledru]

Le 08/11/2018 à 19:54, John Paul Adrian Glaubitz a écrit :
> Source: llvm-toolchain-7
> Version: 1:7.0.1~+rc2-1
> Severity: normal
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
>
> Hi!
>
> After enabling the clang stage2 bootstrap, LLVM currently FTBFS on sparc*
> because of a bug in binutils which provokes unaligned access resulting
> in a "Bus Error" [1]:

ok, thanks.

Fixed in the repo!

S

Bug#910734: dpkg-source: please expand @builddeps@ in Testsuite-Triggers

[Paul Gevers]

Hi,

On 11-10-18 15:31, Paul Gevers wrote:
> I'll try to do a more thorough check, but if I read the code in britney2
> (both versions) correctly, britney2 is already safe for this change. It
> doesn't treat names in this list in any special way and will happily
> take invalid package names including packages named '@' or
> '@builddeps@'. Where the values are (currently) used it is iterating
> over real packages, so it will not actually use the invalid ones.

I just ran one of the testsuites with "Testsuite-Triggers: @builddeps@"
littered into all source packages. The suite ran fine, as expected.

So I think we are good to go. I think dpkg-source should just add all
the unique items found in the test dependencies to the
Testsuite-Triggers. That way, it doesn't need to know and adjust for any
future change in that field.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#912916: mysql-connector-java: CVE-2018-3258: allows low privileged attacker to compromise it

[Moritz Muehlenhoff]

On Thu, Nov 08, 2018 at 07:42:35PM +0100, Markus Koschany wrote:
> Am 08.11.18 um 19:34 schrieb Moritz Mühlenhoff:
> [...]
> > So upon a closer look this seems to only affect the 8.x releases of the
> > connector (Oracle only lists those affected release series which are
> > affected and this only lists 8.x, while 5.1.x is still supported; there's
> > a 5.1.47 release).
> > 
> > Still, this is good example why we should phase out mysql-connector-java
> > in favour of the more transparent mariadb-connector-java, so let's maybe
> > reuse this bug for tracking this? (Especially given Tony's experience
> > that the migration is rather straightforward).
> 
> I'm currently working on updating the affected packages. I intend to
> complete this at the weekend. Some packages are not maintained by the
> Java team, so I will retitle this bug report and file bugs for those
> packages that block the removal of mysql-connector-java. I will CC you
> once I have made some progress.

Great, thanks! Much appreciated.

Cheers,
Moritz

Bug#913262: germinate FTBFS: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 60

[Adrian Bunk]

Source: germinate
Version: 2.29
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=germinate=all=2.29=1541596482=0

...
Traceback (most recent call last):
  File "setup.py", line 20, in 
line = changelog.readline()
  File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 60: 
ordinal not in range(128)
make[1]: *** [debian/rules:16: override_dh_auto_build] Error 1

Bug#913263: meson: wrongly caches dependency() results

[Helmut Grohne]

Package: meson
Version: 0.48.1-1
User: helm...@debian.org
Usertags: rebootstrap

Meson wrongly caches the result of a dependency() call. If you need a
dependency for both the build architecture and host architecture, meson
caches uses the results from the first invocation for the other
invocation. Let me demonstrate the faulty behaviour with the following
meson file:


project('test', 'c')
# The following dependency call is unnecessary here, but its results
# leak into the next call.
glib = dependency('glib-2.0')
native_glib = dependency('glib-2.0', native: true)
gen = executable('gen', 'gen.c', dependencies: [native_glib], native: true)
out = custom_target('out', output: 'out', command: [gen], capture: true, 
build_by_default: true)

To actually build it, you need some gen.c file:

#include 
int main() { printf("success\n"); return 0; }

When cross building this project, the expected behaviour is generating a
file called "out" with the "content" success". To reproduce, create a
crossfile using /usr/share/meson/debcrossgen e.g. for ppc64el. Then
running meson yields the following output:

| WARNING: Unknown CPU family 'powerpc64le', please report this at 
https://github.com/mesonbuild/meson/issues/new
| The Meson build system
| Version: 0.48.1
| Source dir: .../source
| Build dir: .../source/build
| Build type: cross build
| Project name: test
| Project version: undefined
| Native C compiler: cc (gcc 8.2.0 "cc (Debian 8.2.0-9) 8.2.0")
| Cross C compiler: /usr/bin/powerpc64le-linux-gnu-gcc (gcc 8.2.0)
| Host machine cpu family: powerpc64le
| Host machine cpu: ppc64el
| Target machine cpu family: powerpc64le
| Target machine cpu: ppc64el
| Build machine cpu family: x86_64
| Build machine cpu: x86_64
| Cross dependency glib-2.0 found: YES 2.58.1
| Native dependency glib-2.0 found: YES 2.58.1
| Build targets in project: 2
| Found ninja-1.8.2 at /usr/bin/ninja

All looks well. Now run ninja -v.

| [1/3] cc -Igen@exe -I. -I.. -I/usr/include/glib-2.0 
-I/usr/lib/powerpc64le-linux-gnu/glib-2.0/include -fdiagnostics-color=always 
-pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g  -MD -MQ 'gen@exe/gen.c.o' 
-MF 'gen@exe/gen.c.o.d' -o 'gen@exe/gen.c.o' -c ../gen.c
| [2/3] cc  -o gen 'gen@exe/gen.c.o' -Wl,--no-undefined -Wl,--as-needed 
-Wl,--start-group /usr/lib/powerpc64le-linux-gnu/libglib-2.0.so -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/../../usr/lib/powerpc64le-linux-gnu' 
-Wl,-rpath-link,/usr/lib/powerpc64le-linux-gnu
| FAILED: gen
| cc  -o gen 'gen@exe/gen.c.o' -Wl,--no-undefined -Wl,--as-needed 
-Wl,--start-group /usr/lib/powerpc64le-linux-gnu/libglib-2.0.so -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/../../usr/lib/powerpc64le-linux-gnu' 
-Wl,-rpath-link,/usr/lib/powerpc64le-linux-gnu
| /usr/bin/ld: /usr/lib/powerpc64le-linux-gnu/libglib-2.0.so: error adding 
symbols: file in wrong format
| collect2: error: ld returned 1 exit status
| ninja: build stopped: subcommand failed.

You notice that the native compiler invocation is asked to link the host
architecture libglib-2.0.so. That's wrong.

To see that this is actually the first depenency() call leaking into the
next call, we can simply remove the first (unnecessary) call. After
doing so, the sample project crosses fine.

Helmut

Bug#913153: img2pdf: Corrupted PDF with some PNG files

[Rogério Brito]

Dear Johannes,

On Nov 08 2018, Johannes Schauer wrote:
> Quoting Rogério Brito (2018-11-07 17:43:00)
> > I am attaching both the original PNG file as well as the produced PDF
> > file. The invocation is the following:
> > 
> > img2pdf -o bar.pdf bar.png
> 
> thank you for your excellent bug report!

Thank you for your excellent program, BTW!

> I'm able to reproduce your problem with img2pdf 0.3.1.

Great!

> Fortunately, it seems that the problem is already fixed upstream.
(...)
> 
> If you like, you could try out the img2pdf binary from here and check if your
> problem persists or not:
> 
> https://gitlab.mister-muffin.de/josch/img2pdf/blob/master/src/img2pdf.py
> 
> It works for me (tm). Can you confirm?

Sure! It works for me also. I wasn't able to see which commit made things
work, though. :-) But the program just got better!


Thanks a lot,

Rogério.


-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#912768: hplip-data: hp-toolbox fsck

[Cristian Ionescu-Idbohrn]

On Tue, 6 Nov 2018, Till Kamppeter wrote:
> 
> After applying this change "scanimage -L" discovers also my scanner when
> connected to the network and I can scan from any SANE-based application
> without needing a print queue using the "hp" CUPS backend of HPLIP.

Till and Brian,

I now managed to test both printing and scanning with 3.18.10+dfsg0-2 
and both work out-of-the-box, no hax needed :)

Thanks.

Though, I experience some oddoties with hp-toolbox.  On both stretch 
and buster, the "Actions" tab looks like this upon startup:

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=912768;filename=ok.jpg;msg=27

and _all_ the other tabs show reasonable contents.

On sid, the "Actions" tab is completly empty, on startup.

The "Status" tab shows "No status history available.", "Status 
information not available for this device.".

The "Supplies" tab shows "Supplies information not available for this 
device.".

The "Print Settings" tab shows reasonable contents.  "Printer 
Control", the same.

Going back to "Actions", I see this now:

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=912768;filename=fsck.jpg;msg=27

This looks like a bug to me.  I can workaround the missing "Scan" 
action (by manually starting the `simple-scan' application), but that 
won't make my wife happy :)


Cheers,

-- 
Cristian

Bug#880047: postgrey: Regression - Postgrey doesn't start after installing new stable proposed-update

[Adrian Bunk]

Control: reopen -1
Control: found -1 1.36-5

On Mon, Nov 05, 2018 at 09:53:24PM +, Roger Lynn wrote:
> Package: postgrey
> Version: 1.36-3+deb9u1
> Followup-For: Bug #880047
> 
> On a Stable system installed about a year ago, Postgrey 1.36-3 has always run
> fine. When installing 1.36-3+deb9u1 I get:
> 
> Setting up postgrey (1.36-3+deb9u1) ...
> Installing new version of config file /etc/init.d/postgrey ...
> [] Starting postfix greylisting daemon: postgreymkdir: cannot create 
> directory ‘/var/run/postgrey/’: File exists
> invoke-rc.d: initscript postgrey, action "start" failed.
> 
> # /etc/init.d/postgrey stop
> [] Stopping postfix greylisting daemon: postgreystart-stop-daemon: unable 
> to open pidfile /var/run/postgrey/postgrey.pid (Not a directory)
> 
> # /etc/init.d/postgrey start
> [] Starting postfix greylisting daemon: postgreymkdir: cannot create 
> directory ‘/var/run/postgrey/’: File exists
> 
> $ ls -al /var/run/postgrey 
> srw-rw-rw- 1 postgrey postgrey 0 Oct 27 23:14 /var/run/postgrey
> 
> After deleting /var/run/postgrey Postgrey will start, although subsequent
> restarts give:
> 
> # /etc/init.d/postgrey start
> [] Starting postfix greylisting daemon: postgreyPid_file 
> "/var/run/postgrey/postgrey.pid" already exists.  Overwriting!
> . ok 

Tanks a lot for trying stretch-proposed-updates and reproting bugs you find!

This is a regression that is also in 1.36-5 in unstable.

The proposed 1.36-3+deb9u1 update has now been dropped from the upcoming
stretch point release.

> Thanks,
> 
> Roger

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#889885: reassign to qemu?

[dann frazier]

I think virt-manager maybe too high up the stack for this
dependency. I mean, it doesn't depend on seabios either - but that
gets installed through the dependency chain. It also isn't possible
for an architecture-independent package to depend on the correct EFI
firmware package for the target architecture (e.g. x86 wants ovmf, but
arm64 wants qemu-efi-aarch64).

I propose we reassign this to qemu, and ask that:
 1) qemu-system-x86 bump the ovmf relationship from suggests to
   recommends. I wonder if the "suggests" decision was made back when
   edk2 was non-free?
 2) qemu-system-arm replace the "qemu-efi" recommends with both
"qemu-efi-aarch64, qemu-efi-arm". qemu-efi is now just a dummy
package that depends on qemu-efi-aarch64.

 -dann

Bug#913261: RFS: chkboot/1.2-1 [ITP]

[Baptiste BEAUPLAT]

Package: sponsorship-requests
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  Dear mentors,

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

 * Package name: chkboot
   Version : 1.2-1
   Upstream Author : Giancarlo Razzolini 
 * URL : https://github.com/grazzolini/chkboot
 * License : GPL-2.0+
   Section : utils

  It builds those binary packages:

chkboot- detection of malicious changes for boot files

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/c/chkboot/chkboot_1.2-1.dsc

  This is the first release of the package.

  Debian source is hosted on salsa, at:

https://salsa.debian.org/debian/chkboot

  Regards,
Baptiste BEAUPLAT - lyknode

-BEGIN PGP SIGNATURE-

iIcEARYIAC8WIQQt4kiVMTxdp/CJ4U4XSUsQeV3XMwUCW+SOxhEcbHlrbm9kZUBj
aWxnLm9yZwAKCRAXSUsQeV3XM9WlAP93vo64ZSAwvMJ0cnxLBPMTUFGmgipjC6uJ
9rdGnmkKagD9GSoBOM674HGZ2kRlmEncJ6mLS0FKUdqXnc2hShdPRw4=
=nA8y
-END PGP SIGNATURE-

Bug#913229: release.debian.org: RC status of merged-/usr bugs?

[Holger Levsen]

On Thu, Nov 08, 2018 at 05:53:59PM +, Simon McVittie wrote:
> On Thu, 08 Nov 2018 at 15:50:48 +, Holger Levsen wrote:
> > On Thu, Nov 08, 2018 at 04:31:32PM +0100, Michael Biebl wrote:
> > > Wasn't there the idea to utilise the reproducible-build effort to detect
> > > binaries that differ depending on whether they were built in merged-usr
> > > environment or not?
> 
> 
> 
> > however, I would prefer a way which would prevent such
> > buggy binary packages from entering the archive in the first place...
> 
> Do you have a way in mind?
 
source only uploads, for one.

> Are you saying that buildds should stick to unmerged /usr until we are
> more confident that merged /usr buildds will not misbuild packages, as
> I suggested? Or something else?

that's probably something which would help a bit, yes. (but its of
course not enough.)

> For maintainer uploads, there's a lintian tag that would have caught

can we have autorejects based on that?


As said, I'll happily merge a fix for #901473, I just think it's
fundamentally wrong to use a CI system to detect bugs done by manual
mistakes if such mistakes can be systematically avoided. also these bugs
still need to be manually filed.

(and because jenkins.d.n had severe issues the last days which I only
managed to address today I'm a bit reluctant to merge that fix right now
or probably even tomorrow. give us two days of nicely working jenkins
again, first, please :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Elimar Riesebieter]

* Pedro Silva  [2018-11-08 17:21 +]:

> On Thu, 8 Nov 2018 17:56:28 +0100 Elimar Riesebieter 
> wrote:
> > * Pedro Silva  [2018-11-08 08:56 +]:
> > It seems that your HDMI device is your default sound device. If you
> > want to use your HDA-Intel to play sound you need a $HOME/.asoundrc:
> >
> > ###
> > pcm.!default {
> > type hw
> > card 1
> > }
> > ###
> >
> > To configure this system wide put it in /etc/asound.config
> >
> > Elimar
> 
> With the $HOME/.asoundrc, pointed to card 2, the sound is back and fully
> working, thank you.
> 
> You mean that a minor revision to this package caused it to now require
> a manual configuration file?  Why?

Hmm, the priority of the sequence of sond devices is done by the
kernel (udev|systemd). If you are interested please run a test as
follows:

Unplug your usb device and reboot. After reboot plug in your usb
device and run 'cat /proc/asound/cards'.


Boot with a plugged in usb device and run 'cat /proc/asound/cards'.

Is there any difference?

Elimar
-- 
  You cannot propel yourself forward by
  patting yourself on the back.


signature.asc
Description: PGP signature

Bug#912596: cpufrequtils: cpufreq-info only shows 31 CPUs

[Raymond Burkholder]

I might be missing something, but ...

0 - 31 means a count of 32.  Or do you have more than 32?

On 2018-11-08 11:01 a.m., Witold Baryluk wrote:

Package: linux-image-4.18
Followup-For: Bug #912596


# cpupower -c all frequency-info
analyzing CPU 0:

<- cut ->

...
analyzing CPU 30:

<- cut ->

analyzing CPU 31:

<- cut ->

#

Same issue, last CPU has missing info.

Thanks.

Missing file in sys indicate it is an issue with kernel or my
motherboard / CPU.

Bug#913260: llvm-toolchain-7: Please drop sparc* from BINUTILS_GOLD_ARCHS

[John Paul Adrian Glaubitz]

Source: llvm-toolchain-7
Version: 1:7.0.1~+rc2-1
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

After enabling the clang stage2 bootstrap, LLVM currently FTBFS on sparc*
because of a bug in binutils which provokes unaligned access resulting
in a "Bus Error" [1]:

[  4%] Linking C executable ../../bin/count
cd "/<>/build-llvm/tools/clang/stage2-bins/utils/count" && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/count.dir/link.txt --verbose=1
"/<>/build-llvm/./bin/clang"  -fuse-ld=gold -fPIC 
-Wno-unused-command-line-argument -Wno-unknown-warning-option -fPIC 
-Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings 
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-comment 
-ffunction-sections -fdata-sections -fPIC -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long 
-Wcovered-switch-default -Wdelete-non-virtual-dtor -Wstring-conversion 
-ffunction-sections -fdata-sections -O2 -g -DNDEBUG  -fuse-ld=gold -fPIC 
-Wno-unused-command-line-argument -Wno-unknown-warning-option 
-Wl,-allow-shlib-undefined  -Wl,-O3 -Wl,--gc-sections 
CMakeFiles/count.dir/count.c.o  -o ../../bin/count -Wl,-rpath,"\$ORIGIN/../lib" 
-lpthread 
clang-7: error: unable to execute command: Bus error
clang-7: error: linker command failed due to signal (use -v to see invocation)
make[8]: *** [utils/count/CMakeFiles/count.dir/build.make:87: bin/count] Error 
254

This can be worked around by removing sparc* from BINUTILS_GOLD_ARCHS in 
debian/rules
which is what we should be doing until the binutils issues has been resolved.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-7=sparc64=1%3A7.0.1%7E%2Brc2-2=1541692774=0

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