Bug#1040988: fixed in picom 10.2-2

[Vincent Bernat]

On Tue, 26 Dec 2023 16:19:12 + Debian FTP Masters 
 wrote:



   * Fix infinite loop with GNOME (Closes: #1040988)


Upstream also added: 
https://github.com/yshui/picom/commit/7366553be2b825495c5b1e09be09d0fabde4b9b4


Otherwise, picom won't start at the beginning of a session (no windows yet).

Bug#1027382: Please, minimize your build chroots

[Vincent Bernat]

On 2023-01-28 13:59, Adrian Bunk wrote:

I am not saying that trying to force maintainers to spend time on such
issues by making them release critical is better, but you are also
creating extra work and frustration for the people who are doing QA work
in Debian.


It also pushes some maintainers to give up on packages. I gave up on 
maintaining any Go package after the whole "everything should compile 
with only one CPU because policy says so" fiasco. The most rare resource 
we have is volunteer time. Creating artificial problems is not helping.

Bug#1027382: Please, minimize your build chroots

[Vincent Bernat]

On 2023-01-28 00:20, Santiago Vila wrote:

Release Policy exists as a canonical list of what should be RC and > what not, 
and it's intended to avoid stupid discussions like this one.


Extending build-essential is easier than asking many people to do 
pointless work to satisfy a set of non-existing users. It is not like we 
had several reports of people complaining they can't build a package 
because they are in an environment without tzdata. It is not OK to 
create problems to force many volunteers to do extra work.

Bug#1023697: Keep out of testing

[Vincent Bernat]

On Thu, 10 Nov 2022 22:45:57 +0100 Bastian Germann  wrote:

As a new maintainer has stepped up, this cannot be the reason anymore to dump 
the package.
Actually, with the next version of swupdate (one of those handful) I wanted to 
switch from OpenSSL
to SWUpdate.


As there are no real plan to provide QUIC support in OpenSSL 3 and the 
performance regressions of OpenSSL 3 are quite important, I may also 
switch HAProxy to WolfSSL.

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

[Vincent Bernat]

On 2022-10-29 09:23, Salvatore Bonaccorso wrote:

So question is,.. would it make sense to request that linux-image-amd64
depends on the signed | unsigned version?


No unfortunately we cannot do that. The reason is similar to what lead
to
https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71
or caused bugs like #916927.

In meanwhile furthermore linux-image-amd64 is anyway not anymore from
a separate metapackage but built from linux-signed-amd64.

The signed packages need always longer as this needs action of signing
them trough a seprate manual process of ftp-masters.


What about linux-image-amd64-unsigned?

Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot

[Vincent Bernat]

On Fri, 10 Sep 2021 10:35:31 +0200 Julian Andres Klode  
wrote:

Control: reassign -1 shim
Control: affects -1 fwupd

On Fri, Sep 10, 2021 at 09:27:11AM +0200, Norbert Schulz wrote:
> Package: fwupd
> Version: 1.2.14-1~deb10u1
> Followup-For: Bug #968997
> 
> Dear Maintainer,
> 
> this bug still exist for a long time. I removed all packages relating fwupd and install it from scratch but 
> no install of the firmware on reboot. 


Sure, that's expected, shim 15.4 is not able to load fwupd without
additional patches, which have not been applied yet, so it's
not going to get better by reinstalling fwupd.


shim-unsigned has been updated to 15.6 which has the right patches in. 
But for some reason, shim-signed is still at 15.4.

Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.

[Vincent Bernat]

Version: 3.19-9

On 6/24/22 13:39, Peter Pentchev wrote:

If this is the case, could you just request a binNMU?


Hm, that's actually an interesting idea... I'll look into it, and,
in that case, sorry for bothering you! :) So yeah, I will look into
it and probably close this bug accordingly.


I have uploaded a new version.

Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.

[Vincent Bernat]

On 6/24/22 13:05, Peter Pentchev wrote:

Source: xnee
Version: 3.19-8
Severity: serious
X-Debbugs-Cc: r...@debian.org

Hi,

First of all, thanks for taking care of cnee/xnee in Debian!

At some point recently, the XIQueryVersion() function from the X11 API
moved to a separate library, libXi.so.6, found in the libxi6 Debian package.
Since cnee 3.19-8 (in both unstable and testing) has not been linked
against libXi.so.6 at build time, it does not try to load it, resulting in
errors such as:

 [roam@straylight ~]$ cnee --replay -f /dev/null; echo "exit code $?"
 cnee: symbol lookup error: /lib/libxnee.so.0: undefined symbol: 
XIQueryVersion
 exit code 127

...which breaks any program that tries to invoke cnee, leading to e.g.
the wmanager tests breaking in #1013579.

I think that a simple rebuild should be enough - I tested it on my local
system and the cnee binary is now linked against libXi.so.6, too.


If this is the case, could you just request a binNMU?

Thanks.

Bug#1012275: closing 1012275

[Vincent Bernat]

 ❦  3 June 2022 20:48 +02, Salvatore Bonaccorso:

> close 1012275 101.0-1

Unfortunately, Firefox is not buildable due to depending on a version of
Cargo not available in unstable.
-- 
Don't diddle code to make it faster - find a better algorithm.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#1008323: bpftrace: fix FTBFS

[Vincent Bernat]

 ❦ 11 April 2022 21:14 +02, Hector Oron:

>   According to https://github.com/iovisor/bpftrace/issues/2068
>
>   I applied the following patch to make the package build:

Thanks! I will use the more minimal patch found here instead:
https://github.com/iovisor/bpftrace/pull/2174
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Vincent Bernat]

severity -1 important
fixed -1 1:2.2.7-1~bpo11+1
thanks

 ❦ 24 March 2022 17:24 +01, Arturo Borrero Gonzalez:

> This exact same setup was previously working, and actually, the next version 
> works just fine.
> Not sure if this has anything to do with the kernel version warning at the 
> beginning.
>
> In summary:
>
> | keepalived version  | Debian   | Works? |
> | |--||
> | 1:2.0.10-1  | buster   | yes|
> | 1:2.1.5-0.2+deb11u1 | bullseye | no |
> | 1:2.2.7-1~bpo11+1   | bullseye-bpo | yes|
>
> I'm opeining this bug report mostly so others can find it.
> Raelly appreciated the bpo package is ready to use.

Glad that the backport solves this issue. Unfortunately, I don't think
it's worth reporting the issue upstream as they don't like us lagging so
many versions late. I have used it myself with unicast_src, so it is not
broken for everyone.

After looking twice, I notice the VIP is in the same subnet as the peer.
If you don't have any other address on the subnet, I don't see how this
could work. If you have, maybe it would be better to use a /32 for the
VIP.
-- 
If one cannot enjoy reading a book over and over again, there is no use
in reading it at all.
-- Oscar Wilde

Bug#965696: libwhisker2-perl: diff for NMU version 2.5-1.2

[Vincent Bernat]

Thanks! If you want to take over this package, be my guest!

On January 1, 2022 6:35:04 PM GMT+01:00, gregor herrmann  
wrote:
>Control: tags 965696 + patch
>Control: tags 965696 + pending
>Control: tags 999044 + patch
>Control: tags 999044 + pending
>
>
>Dear maintainer,
>
>I've prepared an NMU for libwhisker2-perl (versioned as 2.5-1.2) and
>uploaded it to DELAYED/5. Please feel free to tell me if I
>should delay it longer.
>
>Regards.
>
>
>-- 
> .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
> : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
> `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
>   `-   

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995212: ungoogled-chromium? [

[Vincent Bernat]

 ❦ 14 December 2021 09:13 GMT, Jeff Blake:

> Unless there are licensing or technical objections, I would suggest building 
> with upstream 
> bundled clang to avoid all sorts of incompatibilities and obviate the need 
> for extra patching 
> (stable's clang is often too old and upstream currently uses clang-14 vs 
> unstable's 13). 
> As an added bonus, this is a prerequisite to, and allows building with PGO 
> enabled. Refer to 
> my rules file to see how download of upstream clang/llvm binaries can
> be automated [6].

Unfortunately, packages are not allowed to fetch external stuff during
build. You'll need to vendor clang, either directly in the source
tarball or as an additional tarball.

I just cite this part, but I agree with everything else you said.

> Finally, it's good to see some of the maintainability issues being
> discussed, as when debian chromium development was restarted a year or
> so ago, I became frustrated when my questions on the issue went
> unanswered. So many patches seemed to be superfluous, yet nobody
> seemed to have the motivation, authority or courage to delete them.

The situation didn't change that much. When a maintainer is inactive, it
is always a bit difficult to know how to move forward. The issue has now
gotten a bit more light, but it is still unclear on how to proceed. I
don't think we had a similar case in the past (pretty popular package,
totally unable to push security fixes). It is a pity the package got an
exception to go in Bullseye while it was pretty clear we would get into
this situation.
-- 
As flies to wanton boys are we to the gods; they kill us for their sport.
-- Shakespeare, "King Lear"

Bug#997218: keepalived: FTBFS: if.h:44:5: error: redeclaration of enumerator ‘IFF_UP’

[Vincent Bernat]

 ❦ 23 October 2021 21:13 +02, Lucas Nussbaum:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This bug has been fixed in later versions. I have uploaded 2.2.4-0.1 to
DELAYED/10. Here is the diff compared to what is actually in master on
Salsa.

diff --git a/debian/changelog b/debian/changelog
index a11fb75cca2d..f9c585865a56 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,17 @@
-keepalived (1:2.2.1-1) UNRELEASED; urgency=medium
+keepalived (1:2.2.4-0.1) unstable; urgency=medium
 
+  [ Alexander Wirt ]
   * [61cbc18] New upstream version 2.2.1
   * [ecf662d] Keepalived has now support for systemd notify
 
- -- Alexander Wirt   Mon, 25 Jan 2021 09:04:08 +0100
+  [ Vincent Bernat ]
+  * Non-maintainer upload.
+  * New upstream version 2.2.4. Closes: #980563.
+- Fix FTFBS. Closes: #997218.
+  * d/rules: enable systemd as an init to get systemd features.
+  * d/rules: remove use of custom-specified include directory for kernel.
+
+ -- Vincent Bernat   Sun, 07 Nov 2021 17:57:44 +0100
 
 keepalived (1:2.1.5-0.2) unstable; urgency=medium
 
diff --git a/debian/include/linux/linux/ip_vs.h b/debian/include/linux/linux/ip_vs.h
deleted file mode 100644
index 4102ddcb4e14..
--- a/debian/include/linux/linux/ip_vs.h
+++ /dev/null
@@ -1,474 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- *  IP Virtual Server
- *  data structure and functionality definitions
- */
-
-#ifndef _IP_VS_H
-#define _IP_VS_H
-
-#include 	/* For __beXX types in userland */
-
-#define IP_VS_VERSION_CODE	0x010201
-#define NVERSION(version)			\
-	(version >> 16) & 0xFF,			\
-	(version >> 8) & 0xFF,			\
-	version & 0xFF
-
-/*
- *  Virtual Service Flags
- */
-#define IP_VS_SVC_F_PERSISTENT	0x0001		/* persistent port */
-#define IP_VS_SVC_F_HASHED	0x0002		/* hashed entry */
-#define IP_VS_SVC_F_ONEPACKET	0x0004		/* one-packet scheduling */
-#define IP_VS_SVC_F_SCHED1	0x0008		/* scheduler flag 1 */
-#define IP_VS_SVC_F_SCHED2	0x0010		/* scheduler flag 2 */
-#define IP_VS_SVC_F_SCHED3	0x0020		/* scheduler flag 3 */
-
-#define IP_VS_SVC_F_SCHED_SH_FALLBACK	IP_VS_SVC_F_SCHED1 /* SH fallback */
-#define IP_VS_SVC_F_SCHED_SH_PORT	IP_VS_SVC_F_SCHED2 /* SH use port */
-
-/*
- *  Destination Server Flags
- */
-#define IP_VS_DEST_F_AVAILABLE	0x0001		/* server is available */
-#define IP_VS_DEST_F_OVERLOAD	0x0002		/* server is overloaded */
-
-/*
- *  IPVS sync daemon states
- */
-#define IP_VS_STATE_NONE	0x		/* daemon is stopped */
-#define IP_VS_STATE_MASTER	0x0001		/* started as master */
-#define IP_VS_STATE_BACKUP	0x0002		/* started as backup */
-
-/*
- *  IPVS socket options
- */
-#define IP_VS_BASE_CTL		(64+1024+64)		/* base */
-
-#define IP_VS_SO_SET_NONE	IP_VS_BASE_CTL		/* just peek */
-#define IP_VS_SO_SET_INSERT	(IP_VS_BASE_CTL+1)
-#define IP_VS_SO_SET_ADD	(IP_VS_BASE_CTL+2)
-#define IP_VS_SO_SET_EDIT	(IP_VS_BASE_CTL+3)
-#define IP_VS_SO_SET_DEL	(IP_VS_BASE_CTL+4)
-#define IP_VS_SO_SET_FLUSH	(IP_VS_BASE_CTL+5)
-#define IP_VS_SO_SET_LIST	(IP_VS_BASE_CTL+6)
-#define IP_VS_SO_SET_ADDDEST	(IP_VS_BASE_CTL+7)
-#define IP_VS_SO_SET_DELDEST	(IP_VS_BASE_CTL+8)
-#define IP_VS_SO_SET_EDITDEST	(IP_VS_BASE_CTL+9)
-#define IP_VS_SO_SET_TIMEOUT	(IP_VS_BASE_CTL+10)
-#define IP_VS_SO_SET_STARTDAEMON (IP_VS_BASE_CTL+11)
-#define IP_VS_SO_SET_STOPDAEMON (IP_VS_BASE_CTL+12)
-#define IP_VS_SO_SET_RESTORE(IP_VS_BASE_CTL+13)
-#define IP_VS_SO_SET_SAVE   (IP_VS_BASE_CTL+14)
-#define IP_VS_SO_SET_ZERO	(IP_VS_BASE_CTL+15)
-#define IP_VS_SO_SET_MAX	IP_VS_SO_SET_ZERO
-
-#define IP_VS_SO_GET_VERSION	IP_VS_BASE_CTL
-#define IP_VS_SO_GET_INFO	(IP_VS_BASE_CTL+1)
-#define IP_VS_SO_GET_SERVICES	(IP_VS_BASE_CTL+2)
-#define IP_VS_SO_GET_SERVICE	(IP_VS_BASE_CTL+3)
-#define IP_VS_SO_GET_DESTS	(IP_VS_BASE_CTL+4)
-#define IP_VS_SO_GET_DEST	(IP_VS_BASE_CTL+5)	/* not used now */
-#define IP_VS_SO_GET_TIMEOUT	(IP_VS_BASE_CTL+6)
-#define IP_VS_SO_GET_DAEMON	(IP_VS_BASE_CTL+7)
-#define IP_VS_SO_GET_MAX	IP_VS_SO_GET_DAEMON
-
-
-/*
- *  IPVS Connection Flags
- *  Only flags 0..15 are sent to backup server
- */
-#define IP_VS_CONN_F_FWD_MASK	0x0007		/* mask for the fwd methods */
-#define IP_VS_CONN_F_MASQ	0x		/* masquerading/NAT */
-#define IP_VS_CONN_F_LOCALNODE	0x0001		/* local node */
-#define IP_VS_CONN_F_TUNNEL	0x0002		/* tunneling */
-#define IP_VS_CONN_F_DROUTE	0x0003		/* direct routing */
-#define IP_VS_CONN_F_BYPASS	0x0004		/* cache bypass */
-#define IP_VS_CONN_F_SYNC	0x0020		/* entry created by sync */
-#define IP_VS_CONN_F_HASHED	0x0040		/* hashed entry */
-#define IP_VS_CONN_F_NOOUTPUT	0x0080		/* no output packets */
-#define IP_VS_CONN_F_INACTIVE	0x0100		/* not established */
-#define IP_VS_CONN_F_OUT_SEQ	0x0200		/* must do output seq adjust */
-#define IP_VS_CONN_F_IN_SEQ	0x0400		/* must do input seq adjust */
-#define IP_VS_CONN_F_SEQ_MASK	0x0600		/* in/out sequence mask */
-#define IP_VS_CONN_F_NO_CPORT	0x0

Bug#998108: Tracking this bug down

[Vincent Bernat]

 ❦  4 November 2021 23:39 +01, Eugen Dedu:

> Maybe I am wrong, but, for me, the simplest method to track this bug
> down is to check the changes between the two versions, 93.0 and 
> 93.0-1+b1.  Firefox code has not changed, only one or some libraries
> it depends on.  I thought that the only change is in libvpx version,
> but, surprisingly, a previous comment mentions that rebuilding firefox
> with old vpx (libvpx6) still exhibits the bug.  I think that libc6 is
> out of question, because the last package is 19 Sep, too old wrt this
> bug; the same for gcc-11, the last package being on 21 Oct.  Doesn't
> this (checking the changes) sound like a good approach to find the
> cause of the problem?

There are a lot of changes between the two builds:

- automake (= 1:1.16.5-1),
+ automake (= 1:1.16.4-2),
- bash (= 5.1-3+b2),
+ bash (= 5.1-3+b1),
- bsdextrautils (= 2.37.2-4),
- bsdutils (= 1:2.37.2-4),
+ bsdextrautils (= 2.37.2-3),
+ bsdutils (= 1:2.37.2-3),
- cargo (= 0.57.0-3),
+ cargo (= 0.47.0-3+b1),
- cpp (= 4:11.2.0-2),
- cpp-11 (= 11.2.0-10),
- dash (= 0.5.11+git20210120+802ebd4-2),
- dbus (= 1.12.20-3),
- dbus-bin (= 1.12.20-3),
- dbus-daemon (= 1.12.20-3),
- dbus-session-bus-common (= 1.12.20-3),
- dbus-system-bus-common (= 1.12.20-3),
- dbus-user-session (= 1.12.20-3),
+ cpp (= 4:10.2.1-1),
+ cpp-10 (= 10.3.0-11),
+ dash (= 0.5.11+git20210120+802ebd4-1),
+ dbus (= 1.12.20-2),
+ dbus-user-session (= 1.12.20-2),
- debconf (= 1.5.78),
+ debconf (= 1.5.77),
- dh-strip-nondeterminism (= 1.12.0-2),
+ dh-strip-nondeterminism (= 1.12.0-1),
- g++ (= 4:11.2.0-2),
- g++-11 (= 11.2.0-10),
- gcc (= 4:11.2.0-2),
+ g++ (= 4:10.2.1-1),
+ g++-10 (= 10.3.0-11),
+ gcc (= 4:10.2.1-1),
+ gcc-10 (= 10.3.0-11),
- gcc-11 (= 11.2.0-10),
- gcc-11-base (= 11.2.0-10),
+ gcc-11-base (= 11.2.0-8),
- lib32gcc-s1 (= 11.2.0-10),
- lib32stdc++6 (= 11.2.0-10),
+ lib32gcc-s1 (= 11.2.0-8),
+ lib32stdc++6 (= 11.2.0-8),
- libapparmor1 (= 3.0.3-5),
+ libapparmor1 (= 3.0.3-2),
- libasan6 (= 11.2.0-10),
+ libasan6 (= 11.2.0-8),
- libatomic1 (= 11.2.0-10),
+ libatomic1 (= 11.2.0-8),
- libaudit-common (= 1:3.0.6-1),
- libaudit1 (= 1:3.0.6-1),
+ libaudit-common (= 1:3.0.5-1),
+ libaudit1 (= 1:3.0.5-1),
- libblkid-dev (= 2.37.2-4),
- libblkid1 (= 2.37.2-4),
+ libblkid-dev (= 2.37.2-3),
+ libblkid1 (= 2.37.2-3),
- libc-ares2 (= 1.18.1-1),
+ libc-ares2 (= 1.17.2-1),
- libcc1-0 (= 11.2.0-10),
+ libcc1-0 (= 11.2.0-8),
- libcryptsetup12 (= 2:2.4.1-1),
+ libcryptsetup12 (= 2:2.4.0-1),
- libdatrie-dev (= 0.2.13-2),
- libdatrie1 (= 0.2.13-2),
+ libdatrie-dev (= 0.2.13-1),
+ libdatrie1 (= 0.2.13-1),
- libdbus-1-3 (= 1.12.20-3),
- libdbus-1-dev (= 1.12.20-3),
+ libdbus-1-3 (= 1.12.20-2),
+ libdbus-1-dev (= 1.12.20-2),
- libdeflate-dev (= 1.8-1),
- libdeflate0 (= 1.8-1),
+ libdeflate-dev (= 1.7-2),
+ libdeflate0 (= 1.7-2),
- libegl-mesa0 (= 21.2.4-1),
+ libegl-mesa0 (= 21.2.3-1),
- libegl1-mesa-dev (= 21.2.4-1),
+ libegl1-mesa-dev (= 21.2.3-1),
- libepoxy-dev (= 1.5.9-2),
- libepoxy0 (= 1.5.9-2),
+ libepoxy-dev (= 1.5.9-1),
+ libepoxy0 (= 1.5.9-1),
- libexpat1 (= 2.4.1-3),
- libexpat1-dev (= 2.4.1-3),
- libffi-dev (= 3.4.2-3),
- libffi8 (= 3.4.2-3),
- libfile-stripnondeterminism-perl (= 1.12.0-2),
+ libexpat1 (= 2.4.1-2+b1),
+ libexpat1-dev (= 2.4.1-2+b1),
+ libffi-dev (= 3.4.2-2),
+ libffi7 (= 3.3-6),
+ libffi8 (= 3.4.2-2),
+ libfile-stripnondeterminism-perl (= 1.12.0-1),
- libfreetype-dev (= 2.11.0+dfsg-1),
- libfreetype6 (= 2.11.0+dfsg-1),
- libfreetype6-dev (= 2.11.0+dfsg-1),
+ libfreetype-dev (= 2.10.4+dfsg-1),
+ libfreetype6 (= 2.10.4+dfsg-1),
+ libfreetype6-dev (= 2.10.4+dfsg-1),
- libgbm1 (= 21.2.4-1),
+ libgbm1 (= 21.2.3-1),
- libgcc-11-dev (= 11.2.0-10),
- libgcc-s1 (= 11.2.0-10),
+ libgcc-s1 (= 11.2.0-8),
- libgdbm-compat4 (= 1.22-1),
- libgdbm6 (= 1.22-1),
+ libgdbm-compat4 (= 1.21-1),
+ libgdbm6 (= 1.21-1),
- libgl1-mesa-dri (= 21.2.4-1),
- libglapi-mesa (= 21.2.4-1),
+ libgl1-mesa-dri (= 21.2.3-1),
+ libglapi-mesa (= 21.2.3-1),
- libglib2.0-0 (= 2.70.0-3),
- libglib2.0-bin (= 2.70.0-3),
- libglib2.0-data (= 2.70.0-3),
- libglib2.0-dev (= 2.70.0-3),
- libglib2.0-dev-bin (= 2.70.0-3),
+ libglib2.0-0 (= 2.70.0-1+b1),
+ libglib2.0-bin (= 2.70.0-1+b1),
+ libglib2.0-data (= 2.70.0-1),
+ libglib2.0-dev (= 2.70.0-1+b1),
+ libglib2.0-dev-bin (= 2.70.0-1+b1),
- libglx-mesa0 (= 21.2.4-1),
+ libglx-mesa0 (= 21.2.3-1),
- libgomp1 (= 11.2.0-10),
+ libgomp1 (= 11.2.0-8),
- libisl23 (= 0.24-2),
- libitm1 (= 11.2.0-10),
+ libisl23 (= 0.23-1),
+ libitm1 (= 11.2.0-8),
- libllvm12 (= 1:12.0.1-15),
- libllvm13 (= 1:13.0.0-8),
- liblsan0 (= 11.2.0-10),
+ libllvm12 (= 1:12.0.1-9),
+ libllvm13 (= 1:13.0.0-2),
+ liblsan0 (= 11.2.0-8),
- libmount-dev (= 2.37.2-4),
- libmount1 (= 2.37.2-4),
- libmpc3 (= 1.2.1-1),
+ libmount-dev (= 2.37.2-3),
+ libmount1 (= 2.37.2-3),
+ libmpc3 (= 1.2.0-1),
- libnode72 (= 12.22.7~dfsg-2),
+ libnode72 (= 12.22.5~dfsg-5),
- libobjc4 (= 11.2.0-10),
+ libobjc4 (= 11.2.0-8),
- libp11-kit0 (= 0.24.0-5),
+ libp11-kit0 (= 0.24.0-3),
- 

Bug#993658: qemu-user-static does not work through binfmt since 6.0

[Vincent Bernat]

 ❦  4 September 2021 15:49 +03, Michael Tokarev:

>> Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads)
>
> Can you please check if it works with not-so-fresh kernel
> (eg the one from bullseye)?
>
> I wont able to do this until late evening today.
>
> I'm guessing this is the upstream way to detect if we were
> called from binfmt subsystem (they done it within kernel)
> interferes with my way of doing the same without touching
> the kernel. Kernel side is a recent addition.

It works fine with 5.10.0-8-amd64 from bullseye. Thanks!
-- 
The Public is merely a multiplied "me."
-- Mark Twain

Bug#993658: qemu-user-static does not work through binfmt since 6.0

[Vincent Bernat]

Package: qemu-user-static
Version: 1:6.1+dfsg-4
Severity: critical

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Since 6.0, qemu-user-static does not seem to work properly through
binfmt. I am a bit lost on how to diagnose that:

 13:23 ❱ cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/libexec/qemu-binfmt/aarch64-binfmt-P
flags: POCF
offset 0
magic 7f454c46020101000200b700
mask ff00feff
 13:23 ❱ ./bin/busybox ls
BusyBox v1.30.1 (Debian 1:1.30.1-7) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.
[...]
 13:25 ❱ file bin/busybox
bin/busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), 
statically linked, BuildID[sha1]=6a67fd6d086c703062f3be2d751adf619aa67bc6, for 
GNU/Linux 3.7.0, stripped

When invoked through binfmt, the binaries seem to go from "I display
something wrong" to "I will wipe your entire home". That's what
happened to me when using cowbuilder. The chroot was not able to be
setup correctly and during the clean phase, cowbuilder did not detect
the bind mount and/or was not able to undo them, rm -rfing everything
that was mounted.

Downgrading qemu-user-static to 1:5.2+dfsg-11 fixes the issue.

 13:30 ❱ cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/libexec/qemu-binfmt/aarch64-binfmt-P
flags: POCF
offset 0
magic 7f454c46020101000200b700
mask ff00feff
 13:31 ❱ ./bin/busybox ls
bin  usr


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

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

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.2.1-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.9.5p2-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmEzWXASHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5QgoQAKCvyj4ZvK38O+U4JczjZgEyFr1F3L91
04eRxVhienFsserUx+8qE50kQvAjFXt7iqjugF65o+UpsgC0YCG7f8Ri5KAynHWx
X5ChFgyZtjU3W9ZOs/zGBa9g2Dw8v3FcXO4AvjZnlmXHzLM7Xh7OhcmUjnQe5U1s
JPXw8tojzJA6gaqjCZRmkBuVZMfLteUSeb/yxbopdUCqlv89bFF5VyHS/Agoxj8Q
iRyo8qcyAhur/oqMe0tTCoLP9IWtisF1mO0TZoFe82qzSL/WTayn9nvJ7mhCS/s/
2PyuVa9z1z4NprnZj4f6L3DFszbIB/rlkZng1/GNd9VwAbFqlgGltHZbww1mAOhP
2+ssNF7TDWuFeNQbUwk/YJyzySM/t9fL+O21onahLOR/Hc+Z+tD0f91AdOhBOxM0
D14cqYjKiyQ3Td+N46ZyEkJXW1ThNE2PLU+tnkyXFJGOCfgVLZdPyIeyV77We/MF
9yV9Jy3XrvwuSuqaZZSmlqTp5HzY86AgfEesYTB7diyBTeFwKPE8qnNKOIBXLakG
yqH19GtqReRK4zImsQ+/0UU9qxuvrpwGgaAsClZtAxyeBLLdffsXi2kb4EAJ9B2C
HFHwSOF+zC91xm8x1wbezCJf9newuQRxvciAIPcXKmKwut9oLqI/zSDRk5LoZLwy
VjloaV/64hIA
=15C8
-END PGP SIGNATURE-

Bug#990079: tagging 935548, tagging 986803, tagging 989479, tagging 990079, tagging 990528, tagging 990525 ...

[Vincent Bernat]

 ❦ 17 July 2021 23:30 +02, Sebastian Ramacher:

> # can be fixed via DSAs
> tags 935548 + bullseye-ignore
> tags 986803 + bullseye-ignore
> tags 989479 + bullseye-ignore
> tags 990079 + bullseye-ignore
> tags 990528 + bullseye-ignore
> tags 990525 + bullseye-ignore
> tags 990691 + bullseye-ignore
> tags 990835 + bullseye-ignore
> tags 991046 + bullseye-ignore
> tags 991040 + bullseye-ignore
> thanks

Maybe we should reconsider shipping a browser who has been often late in
shipping security fixes?
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#984767: dh-virtualenv: Can't build packages with compat >= 12 as --buildsystem doesn't work

[Vincent Bernat]

severity 984767 normal
tag 984767 + moreinfo
thanks

 ❦  8 mars 2021 08:55 +01, Johann Queuniet:

> I have issues with building packages with dh-virtualenv using a compat
> of 12 or higher, ending up with the following error:
>
> ```
>  debian/rules binary
> dh binary --with python-virtualenv --python /usr/bin/python3
>dh_update_autotools_config -O--python=/usr/bin/python3
>dh_autoreconf -O--python=/usr/bin/python3
>dh_auto_configure -O--python=/usr/bin/python3
> dh_auto_configure: warning: Please use the third-party "pybuild" build system 
> instead of python-distutils
> dh_auto_configure: error: This feature was removed in compat 12.
> make: *** [debian/rules:4: binary] Error 255
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
> ```
>
> If I try to ask for pybuild with --buildsystem, the build goes a bit
> further, but still fails:
>
> ```
>  debian/rules binary
> dh binary --with python-virtualenv --builtin-venv --python /usr/bin/python3 
> --buildsystem=pybuild
>dh_update_autotools_config -O--builtin-venv -O--python=/usr/bin/python3 
> -O--buildsystem=pybuild
>dh_autoreconf -O--builtin-venv -O--python=/usr/bin/python3 
> -O--buildsystem=pybuild
>dh_auto_configure -O--builtin-venv -O--python=/usr/bin/python3 
> -O--buildsystem=pybuild
> I: pybuild base:232: python3.9 setup.py config
> running config
>create-stamp debian/debhelper-build-stamp
>dh_testroot -O--builtin-venv -O--python=/usr/bin/python3 
> -O--buildsystem=pybuild
>dh_prep -O--builtin-venv -O--python=/usr/bin/python3 
> -O--buildsystem=pybuild
>dh_installdocs -O--builtin-venv -O--python=/usr/bin/python3 
> -O--buildsystem=pybuild
>dh_installchangelogs -O--builtin-venv -O--python=/usr/bin/python3 
> -O--buildsystem=pybuild
>dh_virtualenv -O--builtin-venv -O--python=/usr/bin/python3 
> -O--buildsystem=pybuild
> Usage: dh_virtualenv [options]
>
> dh_virtualenv: error: no such option: --buildsystem
> make: *** [debian/rules:4: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
> ```

I am able to build with compatibility 12:

%:
dh $@ --buildsystem=pybuild --with python-virtualenv
override_dh_virtualenv:
dh_virtualenv --python python3

I don't remember if you tried that. So, while it could work out of the
box without overriding dh_virtualenv, it works good enough to be in a
release, with two solutions:

 - use compatibility 11
 - override dh_virtualenv invocation to not chocke on
   --buildsystem=pybuild

Also, it seems you pass --builtin-venv to dh, you only need to pass it
to dh_virtualenv.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#984939: marked as pending in python-netaddr

[Vincent Bernat]

Control: tag -1 pending

Hello,

Bug #984939 in python-netaddr reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/python-netaddr/-/commit/49d864914fc7f3796cfff07dc21beabd0b391dbd


d/rules: do not build documentation

The package downloaded from Pypi does not contain all the files to
generate the documentation. Let's just not build it.

Closes: #984939


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/984939

Bug#980438: do not depend on the non-public binutils ABI

[Vincent Bernat]

 ❦ 19 janvier 2021 10:57 +01, Vincent Bernat:

>> bpftrace should not depend on the non-public binutils ABI. This always 
>> generated
>> an upper dependency on libbinutils.  If you think it's worth having this
>> dependency, please statically link with libbinutils and record the the 
>> version
>> used in a Built-Using flag.
>
> I am not familiar enough with CMake to understand how to statically link
> to a given library while using dynamic linking for the remaining. Also,
> why provide dynamic libraries we cannot use?

OK, I see this is stated in the description of the package:

Description: GNU binary utilities (BFD development files)
 This package includes header files and static libraries necessary to build
 programs which use the GNU BFD library, which is part of binutils.  Note
 that building Debian packages which depend on the shared libbfd is Not
 Allowed.

I'll remove need of using libbfd-dev since it seems to be an optional
safety feature.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#980438: do not depend on the non-public binutils ABI

[Vincent Bernat]

 ❦ 19 janvier 2021 08:33 +01, Matthias Klose:

> bpftrace should not depend on the non-public binutils ABI. This always 
> generated
> an upper dependency on libbinutils.  If you think it's worth having this
> dependency, please statically link with libbinutils and record the the version
> used in a Built-Using flag.

I am not familiar enough with CMake to understand how to statically link
to a given library while using dynamic linking for the remaining. Also,
why provide dynamic libraries we cannot use?
-- 
The better part of valor is discretion.
-- William Shakespeare, "Henry IV"

Bug#977549: bpftrace: all programs fail with Segmentation fault

[Vincent Bernat]

clone 977549 -1
reassign -1 libbpfcc
retitle -1 libbpfcc: please compile with -DENABLE_LLVM_SHARED=on
severity -1 normal
found -1 0.17.0-8
block 977549 by -1
thanks

 ❦ 16 décembre 2020 16:48 +01, Emanuele Rocca:

> Package: bpftrace
> Version: 0.11.3-3
> Severity: grave
> Justification: renders package unusable
>
> Any attempt of running bpftrace programs fails on my sid workstation:
>
>  $ sudo bpftrace -e 'kprobe:do_nanosleep { printf("PID %d sleeping\n", pid); 
> }'
>  Two passes with the same argument (-tti) attempted to be registered!
>  Segmentation fault
>
> The issue isn't limited to kprobes, uprobes fail too:
>
>  $ sudo bpftrace -e 'uprobe:/bin/bash:readline { printf("Hello\n") }'
>  Two passes with the same argument (-tti) attempted to be registered!
>  Segmentation fault
>
> Even bpftrace -V fails, though with a different error:
>
>  $ sudo bpftrace -V
>  bpftrace v0.11.3
>  free(): double free detected in tcache 2
>  Aborted
>
> I'm running linux-image-5.9.0-4-amd64 5.9.11-1 and libllvm11
> 1:11.0.0-5+b1.

Downgrading libbpfcc to 0.17.0-7 fixes this issue. The change between
this version and 0.17.0-8 seems not related to this regression. I think
this is more a change from LLVM 9 to LLVM 11 that triggered that: the
versions used by libbcc and bpftrace are the same and the initialization
is done twice, once for the dynamic initialization from bpftrace and
once for static initialization from libbcc.

This can be fixed by compiling libbcc with -DENABLE_LLVM_SHARED=on
(tested by adding this flag in debian/rules, no other change). I
don't know if there is a drawback to that.
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it

[Vincent Bernat]

 ❦  1 décembre 2020 22:28 +01, Moritz Mühlenhoff:

> Michael has been heroically keeping up with this beast of a codebase for 
> years,
> but we clearly need a broader base to sustain it going forward.

In the past, it was team-maintained. I don't remember exactly, but I
think there was a disagreement between Michael and Riku over
some items, including collaborating on the git repository. Maybe Riku
can reconsider helping with Chromium?
-- 
Make the coupling between modules visible.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#970810: python3-venv is gone

[Vincent Bernat]

 ❦  6 octobre 2020 12:32 +03, Jyrki Pulliainen:

> Now, python3.8-venv contains the ensurepip module. But to me it is very
> unclear if python3.8-venv is going to disappear? It also makes depending on
> these packages generally a lot more brittle: I'd rather depend on
> python3-venv than python3.8-venv. We are not depending on the
> /usr/bin/pyvenv binary, but executing the module with "python -m venv", so
> it does not matter if the python3-venv just drops the binary.
>
> Could you please clarify what is going to be removed, which packages are
> going to stay?

>From my understanding, only the pyvenv command will disappear.

Doko, why is python3.x-venv a separate package? It seems `python3 -m
venv` doesn't work without the ensurepip module shipped in
`python3.x-venv`.

python3-venv package was useful to pull the dependencies to get a
working venv module. Can we either keep the python3-venv as a
metapackage for this purpose and integrate back the ensurepip module
(300 bytes) into libpython3.x-stdlib?

Thanks.
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#972138: error: The name org.freedesktop.Accounts was not provided by any .service files

[Vincent Bernat]

Package: flatpak
Version: 1.8.2-2
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

After upgrading to 1.8.2-2, I cannot run any Flatpak. I have tried
com.spotify.Client and us.zoom.Zoom and both of them are returning the
following error:

error: The name org.freedesktop.Accounts was not provided by any .service files

Downgrading to 1.8.2-1 fixes this problem.

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

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

Versions of packages flatpak depends on:
ii  adduser3.118
ii  bubblewrap 0.4.1-1
ii  libappstream-glib8 0.7.17-1
ii  libarchive13   3.4.3-2
ii  libc6  2.31-4
ii  libdconf1  0.38.0-1
ii  libfuse2   2.9.9-3
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii  libglib2.0-0   2.66.1-1
ii  libgpgme11 1.14.0-1
ii  libjson-glib-1.0-0 1.6.0-1
ii  libmalcontent-0-0  0.9.0-2
ii  libostree-1-1  2020.6-1
ii  libpolkit-agent-1-00.105-29
ii  libpolkit-gobject-1-0  0.105-29
ii  libseccomp22.4.4-1
ii  libsoup2.4-1   2.72.0-2
ii  libsystemd0246.6-1
ii  libxau61:1.0.8-1+b2
ii  libxml22.9.10+dfsg-6
ii  libzstd1   1.4.5+dfsg-4
ii  xdg-dbus-proxy 0.1.2-1

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.26-1
ii  gtk-update-icon-cache3.24.23-2
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   246.6-1
ii  p11-kit  0.23.21-2
ii  policykit-1  0.105-29
ii  shared-mime-info 2.0-1
ii  xdg-desktop-portal   1.8.0-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.8.0-1

Versions of packages flatpak suggests:
ii  avahi-daemon0.8-3
pn  malcontent-gui  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl+FS9ISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5U2cQAI2kacZSFRvURLJGiVhXn6FoNL1aLQnJ
cVm8HfVbJ3Glf3yadvX6PWFRfs6deh2Z3V7gjKgHUhFwj6C+LhZb2Wd9YkC4Dl3K
HgFmLE57NnYysA/AQ9cOq3quCGFGMfv4/t4M3r0omTMT1GREAz8WfnqSWFb5c+d1
k7TSq2jF5rg/+8kuEXxcmtGQz/Xd5DXK6VudEfYmBOrqFXCH71SRnICcLywjlFYw
HimicbNaSP0Bdx9ZSInfMGYg5O4bRTr/DSrVViw/MlUf7PNJAgQyOp7sDwzffSJg
G+SBROq5qKzdwBTTuTLSo3PlFxPLkZGR5jj7e1432IuJrzRdhdEXdln37I7rs6RR
dOHEitpe399qUI+RNXg93ORiE8BR5XPs4Fth28V32bsgaLa87dWqivhXl3gwmqtz
wJpHP7MU3vsf2D0r7MWqIEsfZJNWLMCot58tTLUB0Hut7DScjsqJBnF5lWEK+LZ0
/CHUr5I6D8xyKj7Skf1GKN6OT2ZtKA/xubF/Lx1V08Q5xJ/IlrVrvU1Pk+3p+AdY
UrC+wB7a+0uTog6RD1aRRAhWT8i48PvaPvbxRAD2z99/Hy4ZhAjnINEsOEu/+4g/
iw4YBBWDtpFLRg4dbc1ttyEsH3jCOkB63RGXZzQfPNIm6mdhHwtlKZfi+2sDxAIA
yipW/zOzeoSX
=Vgzd
-END PGP SIGNATURE-

Bug#957989: xnee: ftbfs with GCC-10

[Vincent Bernat]

 ❦ 23 juillet 2020 12:59 +03, Peter Pentchev:

>> > If you add "-fcommon" to gcc-10 it should work.
>> 
>> this would be a work-around, not a fix.
>
> Hi,
>
> Fix proposed:
>
> https://savannah.gnu.org/bugs/index.php?58810
>
> https://salsa.debian.org/debian/xnee/-/merge_requests/1

Thanks! I'll wait a few days to check if upstream has any objection on
your patch.
-- 
He that breaks a thing to find out what it is has left the path of wisdom.
-- J.R.R. Tolkien


signature.asc
Description: PGP signature

Bug#962320: facter crashes with "free(): invalid pointer"

[Vincent Bernat]

Package: libfacter3.11.0
Version: 3.11.0-4.1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 1431634051, 94476679444720, 139623352393688, 0, 
94476679915560, 94476680133744, 139623355011525, 17, 94476679449080, 6481, 
94476679118894, 272, 256, 4, 94476679118984}}
pid = 
tid = 
ret = 
#1  0x7efc9e30f55b in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0, 511101108348, 390842024046, 140728013449808, 2, 44, 
18446744073709551504, 140728013450096, 13742199053743279360, 0, 
140728013450112, 94476682378416,
  140728013450304, 140728013450096, 140728013449824, 0}}, sa_flags 
= -1643662843, sa_restorer = 0x0}
sigs = {__val = {32, 0 }}
#2  0x7efc9e368038 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7efc9e474f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
ap = {{gp_offset = 24, fp_offset = 32765, overflow_arg_area = 
0x7ffdcb406b50, reg_save_area = 0x7ffdcb406ae0}}
fd = 
list = 
nlist = 
cp = 
written = 
#3  0x7efc9e36f3da in malloc_printerr (str=str@entry=0x7efc9e4730e0 
"free(): invalid pointer") at malloc.c:5339
No locals.
#4  0x7efc9e370dcc in _int_free (av=, p=, 
have_lock=0) at malloc.c:4173
size = 0
fb = 
nextchunk = 
nextsize = 
nextinuse = 
prevsize = 
bck = 
fwd = 
__PRETTY_FUNCTION__ = "_int_free"
#5  0x7efc9e7c75d4 in __gnu_cxx::new_allocator::deallocate 
(this=0x7ffdcb406c60, __p=) at 
/usr/include/c++/9/ext/new_allocator.h:119
No locals.
#6  std::allocator_traits >::deallocate (__a=..., 
__n=, __p=) at 
/usr/include/c++/9/bits/alloc_traits.h:470
No locals.
#7  std::__cxx11::basic_string, 
std::allocator >::_M_destroy (__size=, 
this=0x7ffdcb406c60) at /usr/include/c++/9/bits/basic_string.h:237
No locals.
#8  std::__cxx11::basic_string, 
std::allocator >::_M_dispose (this=0x7ffdcb406c60) at 
/usr/include/c++/9/bits/basic_string.h:232
No locals.
#9  std::__cxx11::basic_string, 
std::allocator >::~basic_string (this=0x7ffdcb406c60, 
__in_chrg=) at /usr/include/c++/9/bits/basic_string.h:658
No locals.
#10 facter::facts::collection::add_external_facts_dir (this=0x7ffdcb4071a0, 
resolvers=std::vector of length 4, capacity 4 = {...}, dir=..., warn=) at ./lib/src/facts/collection.cc:160
msg = ""
found = false
ec = {m_val = 2, m_cat = 0x7efc9e093070}
search_dir = {static separator = 47 '/', static preferred_separator = 
47 '/', static dot = 46 '.', m_pathname = 
"/home/bernat/.puppetlabs/opt/facter/facts.d"}
#11 0x7efc9e7c7bd8 in facter::facts::collection::add_external_facts 
(this=0x7ffdcb4071a0, directories=std::vector of length 0, capacity 0) at 
./lib/src/facts/collection.cc:197
dir = "/home/bernat/.puppetlabs/opt/facter/facts.d"
__for_range = @0x7ffdcb406d80: std::vector of length 2, capacity 2 = 
{"/home/bernat/.puppetlabs/opt/facter/facts.d", "/home/bernat/.facter/facts.d"}
__for_begin = 
__for_end = 
resolvers = std::vector of length 4, capacity 4 = 
{std::unique_ptr = {get() = 0x55ed1117bbf0}, 
std::unique_ptr = {get() = 0x55ed1117bc30},
  std::unique_ptr = {get() = 
0x55ed1117bc10}, std::unique_ptr = {get() = 
0x55ed1117bc50}}
found = false
#12 0x55ed1001f54c in main (argc=, argv=) at 
./exe/facter.cc:350
inside_facter = ""
external_directories = std::vector of length 0, capacity 0
positional_options = {m_names = std::vector of length 0, capacity 0, 
m_trailing = "query"}
ignore_cache = 
vm = 
lvl = 
blocklist = std::set with 0 elements
custom_directories = std::vector of length 0, capacity 0
hidden_options = {static m_default_line_length = 80, m_caption = "", 
m_line_length = 80, m_min_description_length = 40, m_options = std::vector of 
length 1, capacity 1 = {{px = 0x55ed10eacd80, pn = {pi_ = 0x55ed10e6bae0}}},
  belong_to_group = std::vector of length 1, capacity 64 = 
{false}, groups = std::vector of length 0, capacity 0}
ruby = 
ruby_cleanup = {_callback = 
{> = {}, 
 = {static _M_max_size = 16, static _M_max_align = 8, 
_M_functor = {_M_unused = {_M_object = 0x55ed10e8fc01,
  _M_const_object = 0x55ed10e8fc01, _M_function_pointer = 
0x55ed10e8fc01, _M_member_pointer =  table offset 94476679314432, this 
adjustment 42}, _M_pod_data = 
"\001\374\350\020\355U\000\000*\000\000\000\000\000\000"},
  _M_manager = 0x55ed100200d0 
 
>::_M_manager(std::_Any_data &, const std::_Any_data &, 
std::_Manager_operation)>},
_M_invoker = 0x55ed10020100  >::_M_invoke(const std::_Any_data &)>}}
fmt = 
ttls = std::unordered_map with 0 elements
   

Bug#958450: chromium: Please update chromium to 81.0.4044.113 for security reasons

[Vincent Bernat]

On Wed, 22 Apr 2020 11:55:00 +0300 jim_p  wrote:

> As the title suggests, please update chromium to 81.0.4044.113 (or later),
> because it includes a patch for CVE-2020-6457, which is a critical security
> issue. More info here
> https://chromereleases.googleblog.com/2020/04/stable-channel-update-for-
> desktop_15.html

In the meantime, another major version of Chromium was released with many
high profile security fixes:

 - High CVE-2020-6465: Use after free in reader mode. Reported by Woojin 
Oh(@pwn_expoit) of STEALIEN on 2020-04-21
 - High CVE-2020-6466: Use after free in media. Reported by Zhe Jin from cdsrc 
of Qihoo 360 on 2020-04-26
 - High CVE-2020-6467: Use after free in WebRTC. Reported by ZhanJia Song on 
2020-04-06
 - High CVE-2020-6468: Type Confusion in V8. Reported by Chris Salls and Jake 
Corina of Seaside Security, Chani Jindal of Shellphish on 2020-04-30
 - High CVE-2020-6469: Insufficient policy enforcement in developer tools. 
Reported by David Erceg on 2020-04-02

Also, from previous releases:

 - High CVE-2020-6464: Type Confusion in Blink. Reported by Looben Yang on 
2020-04-15
 - High CVE-2020-6462: Use after free in task scheduling. Reported by Zhe Jin 
from cdsrc of Qihoo 360 on 2020-03-26
 - High CVE-2020-6461: Use after free in storage. Reported by Zhe Jin from 
cdsrc of Qihoo 360 on 2020-04-21
 - High CVE-2020-6459: Use after free in payments. Reported by Zhe Jin from 
cdsrc of Qihoo 360 on 2020-03-27
 - High CVE-2020-6460: Insufficient data validation in URL formatting.  
Reported by Anonymous on 2020-03-21
 - High CVE-2020-6463: Use after free in ANGLE. Reported by Pawel Wylecial of 
REDTEAM.PL on 2020-03-26
 - High CVE-2020-6458: Out of bounds read and write in PDFium. Reported by 
Aleksandar Nikolic of Cisco Talos on 2020-04-02
-- 
Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#937429: pyeos: Python2 removal in sid/bullseye

[Vincent Bernat]

 ❦ 24 avril 2020 20:54 +02, Moritz Mühlenhoff:

>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
>> 
>> Python2 becomes end-of-live upstream, and Debian aims to remove
>> Python2 from the distribution, as discussed in
>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>> 
>> Your package either build-depends, depends on Python2, or uses Python2
>> in the autopkg tests.  Please stop using Python2, and fix this issue
>> by one of the following actions.
>
> Hi Vincent,
> https://github.com/spotify/pyeos/ has been archived (and prior to that not 
> seen
> an update for five years), let's remove it from the archive or are you 
> planning
> to port it to Python 3 yourself?

Hello Moritz,

Yes, we can remove it from the archive. It has been superseded by
pyeapi. Do you want me to file a bug for removal?
-- 
The smallest worm will turn being trodden on.
-- William Shakespeare, "Henry VI"


signature.asc
Description: PGP signature

Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot

[Vincent Bernat]

Package: libgcc1
Version: 1:10-20200202-1
Followup-For: Bug #950551

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

On both my systems running unstable, libgcc-s1 is installed, but I
don't have /usr/lib/x86_64-linux-gnu/libgcc_s.so.1. So, it seems
something removes it. I have no clue on why. Reinstalling libgcc-s1
fixes the problem.

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

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

Versions of packages libgcc1 depends on:
ii  gcc-10-base  10-20200202-1
ii  libc62.29-9
ii  libgcc-s110-20200202-1

libgcc1 recommends no packages.

libgcc1 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl45Bb4SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5MDkP/AoeAopCOY4NEL8+GG5qC/4xiQk4SKWY
tBqFKmEhrex/46+idUV9AmY5G7BGJQad1i0L551vcuyNye2utz6dP/2XIgSJk3Ai
HVSjApSGDdo8MDVW6w2C0GucGSQAX55XPGtC6BU7I5C5ukny+MZx6Z0R/5cOYjy9
BWL8KejRawltzKIZpPIT7DuA+OG1tAQ6njdfbQxn5ihNGIHXoEcgEShEVlBhx48I
lIadw5jKJkhK6LDYWmzfvigVo9NIC/IIgepvzapNrMirjjsQE6Q/OpsxMjakfk+t
+dI4kiBbPqXNqDyaSMgUG3nKYZcIjgMU14fMC2JbRKIOOvXMHzgn5I/oj3zxau50
qZ5l1Yk1Rkds0u9mGVxmrGefxEd5IWet2HVwsqhDXNz+xyHH0yZE59UbXcdO+mfq
JVn2vbbXUBpYaAVmKyaocinDlgUYMg987j+HCNQYtmbyXfgD0GobVc3yDJykHiRj
T3Isk2ZbwLZhT5yb2p4KTbodZO1AWbGW2wabODjgAfeCtOM3tJjUioVYvXlHCnVm
hxReC7+c81CvzkNA95hT23TL4GKu21KXUpD60TWUv3i6VFp2dvDs4YV2JGzPjXbB
zIlSk04AhOlzLP8N3gRRW0J+vLQdLB+7USeyDlNgbf7HPhuNlvekPsAwh/BxDxdf
bClIfmr3peYd
=lto4
-END PGP SIGNATURE-

Bug#949178: linux-image-5.4.0-2-amd64: system freeze with i915 with error: 0000:00:02.0: Resetting rcs0 for hang on rcs0

[Vincent Bernat]

 ❦ 17 janvier 2020 20:23 +01, Davide Prina :

> Jan 15 11:37:33 prinad03 kernel: [ 9354.966794] i915 :00:02.0: GPU
> HANG: ecode 9:1:0x, hang on rcs0

You may want to follow this thread. 5.3 and 5.4 seem to be difficult
kernels for Intel graphic cards. It's unknown if 5.5 will fix it once
and for all.

https://gitlab.freedesktop.org/drm/intel/issues/451

On an old generation of hardware, I had issue on 5.3, fixed on 5.4. On a
new generation, I have issue with 5.4 and not 5.3.
-- 
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1

[Vincent Bernat]

Hello Michael,

I was able to hit the bug again. It seems I have to go to another wifi
network, then back to my home network to hit the bug. On the
client-side, I get:

janv. 06 18:57:13 zoro NetworkManager[75721]:   [1578333433.9474] dhcp4 
(wlp3s0): activation: beginning transaction (timeout in 45 seconds)
janv. 06 18:57:13 zoro NetworkManager[75721]:  [1578333433.9532] dhcp4 
(wlp3s0): sent REQUEST to 255.255.255.255
janv. 06 18:57:13 zoro NetworkManager[75721]:  [1578333433.9571] dhcp4 
(wlp3s0): received NACK from 0.0.0.0
janv. 06 18:57:13 zoro NetworkManager[75721]:   [1578333433.9572] dhcp4 
(wlp3s0): state changed unknown -> fail

On the server-side, I am using dnsmasq. Logs say:

Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPREQUEST(lan-trusted) 
192.168.117.40 3e:55:59:b2:a3:b9
Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPNAK(lan-trusted) 192.168.117.40 
3e:55:59:b2:a3:b9 address in use

I am a bit puzzled why dnsmasq says that, but it didn't happen with
older versions of Network Manager. If I capture the request and
response, I get:

18:57:13.952425 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP 
(17), length 317)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
3e:55:59:b2:a3:b9, length 289, xid 0xa9a8ed40, Flags [none] (0x)
  Client-Ethernet-Address 3e:55:59:b2:a3:b9
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 3e:55:59:b2:a3:b9
Parameter-Request Option 55, length 18:
  Subnet-Mask, Time-Zone, Domain-Name-Server, Hostname
  Domain-Name, MTU, BR, Classless-Static-Route
  Default-Gateway, Static-Route, YD, YS
  NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft
  Option 252, RP
MSZ Option 57, length 2: 576
Requested-IP Option 50, length 4: 192.168.117.40
Hostname Option 12, length 4: "zoro"
END Option 255, length 0
18:57:13.952596 IP (tos 0xc0, ttl 64, id 26751, offset 0, flags [none], proto 
UDP (17), length 328)
192.168.117.1.67 > 255.255.255.255.68: [bad udp cksum 0x36ef -> 0x0984!] 
BOOTP/DHCP, Reply, length 300, xid 0xa9a8ed40, Flags [Broadcast] (0x8000)
  Client-Ethernet-Address 3e:55:59:b2:a3:b9
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Server-ID Option 54, length 4: 192.168.117.1
MSG Option 56, length 14: "address in use"
END Option 255, length 0
PAD Option 0, length 0, occurs 34

But if I look at the lease file from dnsmasq, I see:

1578382414 e8:2a:ea:05:c0:df 192.168.117.40 zoro 01:e8:2a:ea:05:c0:df

So, I suppose this is a because of randomizatio of the MAC address on
wifi networks. I don't see anytrhing special in the NEWS file about
this. Previously, the hardware MAC address was used to do the DHCP
request.

When using dhcp=dhclient, I am getting the same NAK, but then the ISC
DHCP client is using DISCOVER and gets a new IP address.

RFC says "If the client receives a DHCPNAK message, the client
restarts the configuration process." So, I think the bug is more in the
fact that the DHCP client doesn't restart configuration when receiving a
NAK but just gives up.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1

[Vincent Bernat]

 ❦ 29 décembre 2019 13:40 +01, Michael Biebl :

> Can you provide a full, verbose debug log:
>
> https://wiki.gnome.org/Projects/NetworkManager/Debugging
>
> Which dhcp client do you use: internal, isc-dhcp-client, ...?

I am using the internal client. Unfortunately, I am not able to
reproduce the problem anymore. Once I get it again, I'll send the logs.
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1

[Vincent Bernat]

Package: network-manager
Followup-For: Bug #947613

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

I've got the same problem. Comparing the output of "journalctl -u
NetworkManager" on both versions, the only difference I am able to
spot is that with 1.22.2-1, I have these lines:

déc. 29 07:30:48 zoro NetworkManager[1333]:   [1577601048.8881] dhcp4 
(wlp3s0): activation: beginning transaction (timeout in 45 seconds)
déc. 29 07:30:48 zoro NetworkManager[1333]:   [1577601048.8938] dhcp4 
(wlp3s0): state changed unknown -> fail

While in 1.22.0-2, I have:

déc. 29 07:44:13 zoro NetworkManager[5959]:   [1577601853.3663] dhcp4 
(wlp3s0): activation: beginning transaction (timeout in 45 seconds)
déc. 29 07:44:13 zoro NetworkManager[5959]:   [1577601853.3860] dhcp4 
(wlp3s0): option dhcp_lease_time  => '86400'
déc. 29 07:44:13 zoro NetworkManager[5959]:   [1577601853.3863] dhcp4 
(wlp3s0): option domain_name  => 'home'
[...]

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  init-system-helpers1.57
ii  libaudit1  1:2.8.5-2+b1
ii  libbluetooth3  5.50-1+b1
ii  libc6  2.29-6
ii  libcurl3-gnutls7.67.0-2
ii  libglib2.0-0   2.62.3-2
ii  libgnutls303.6.11.1-2
ii  libjansson42.12-1
ii  libmm-glib01.10.4-0.1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.21-4
ii  libnm0 1.22.0-2
ii  libpam-systemd 244-3
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libpsl50.20.2-2
ii  libreadline8   8.0-3
ii  libselinux13.0-1
ii  libsystemd0244-3
ii  libteamdctl0   1.29-1
ii  libudev1   244-3
ii  libuuid1   2.34-0.1
ii  policykit-10.105-26
ii  udev   244-3
ii  wpasupplicant  2:2.9-3+b1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1.1
ii  iptables 1.8.4-1
ii  modemmanager 1.10.4-0.1
ii  ppp  2.4.7-2+4.1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2
ii  libteam-utils1.29-1

- -- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
dns=dnsmasq
monitor-connection-files=true
[keyfile]
unmanaged-devices=interface-name:docker0
[ifupdown]
managed=false


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4IUSMSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX54w0QAJCyATfvRu6DwWwZE1xvF4xnCFaPAbhl
90iLRubdSb8vBcU7Z5l1A1dtqndFdrx5mbs+iZmwROA+fM71nWfN084iAIiA/tfl
CGVVY5ORlw/ZfcUwhk1MtABwIJVlxt05UoHvqHrgB3W1KTSOFw8oKISOFA3gcgUA
MRpwAPbwj0mjr8XW2l+7v/E+qcxDfO4B0wFu44udv+xRKBLaDjs3bUC3jXAidDgX
EoLfSjvmHwZYYy4yEMnp2jFeiu3En9eCdt6pqIiN0Qo3wcg4OJe/e3yd4RJo2Lsr
Bm3Gdu3IPjxlCZuDOKBcxWkxQpgKweguxxui1sUslUNFxFmvz3C4S+KB3WH33fYR
JsMzEbG/aGDUPC2V+U3qthaPLaw7nJh94JLRgVUBqhyefwIFmCr2j1Xg972QAUvY
5XT4tcRd6JBmVCdPD9gwaa6eRBHGqErQCr0sx+qKks6TGK3Y/CVMn2qqsInxo9uy
iuwqBjcQq6HqWUIvNXOhnZJy1gOCvMqATKyI/yPPa6Dbp+wTyC7dGZNuja1y1qVb
pf7Cl6z480qFqc5kbiN3dHh++yXFjlkLn4CR6aDqXkoDIREdb4LLP59E6+PpM6ax
kACEsbdgZKtfegd5TbWRubDUNtqx+q4N+XEQiEPpuUeP8wFjCpKZ2v8y7X5lsY89
4zCuQ8SydOMK
=c1Pt
-END PGP SIGNATURE-

Bug#923782: Relax dependency on faraday to allow updating ruby-faraday

[Vincent Bernat]

Package: ruby-puppet-forge
Followup-For: Bug #923782

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

With the provided patch, I am able to use librarian-puppet without any
issue. Unless someone protests, I'll do a NMU next week to fix this
bug.

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

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

Versions of packages ruby-puppet-forge depends on:
ii  ruby 1:2.5.1
ii  ruby-faraday 0.15.4-3
ii  ruby-faraday-middleware  0.12.2-1
ii  ruby-gettext-setup   0.30-2
ii  ruby-minitar 0.6.1-1
ii  ruby-semantic-puppet 1.0.2-1

ruby-puppet-forge recommends no packages.

ruby-puppet-forge suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlyG0dsSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX50hsP/2mkf0f5yvdlrXBQk/lVQKoNNEKpqUGV
Gm2dyXPENL5dUrbq6L/5R6T8RpqIYmTbjs5Y2/AYl73DJflFI3veeHZ/VLly36QN
QDeHMyIVwLxA0n002Gj7jTOsRkHzfgAxgGYkplyg6OObYA4ol4Jw8VMyOt2a3DLj
29kYKTmR8MXvuAGBSiedj9cp7wcsk61jaYlB+4NGko/BDHIzjG2rTr/xTwMyBI8r
nREX3uNtsCx3OEJMujedZsksZ2lq0bNA5pihnSkZTOWC6rzjMvei13pN+3iHA3GW
nXRq07u9yh2AR5jPBvv75T7gFfRwI+qpi5QXWHieho+LOvg8Usn0NoMIpiywEITN
a1D/0WO8Cxkc8h7UXENv5L9wUtMGbqdF64qO/e4ryWw9AtkcySI+WECDzXjXL0cz
3brEywRCOnyjGKZuzZNgaFgh9Ml0R2iv1WrAskx5TsO/VUQYvHdj06Pa6W+lB+1X
gRke6GlZh7RK3DsZf34+fLNqx4oz/S47PO/pfs9i/M+r/AeytdCovb0hBIV2KDK9
cRnPq9HNEMtD4IFnN3Pquw9yAegmkb4Qctva11sCj66muY7lEYs3onF3pPxfJ4rB
wv90TSpDALJ4Do9ZPH2hk8ZkYob/NZ5C5ThX7rvTfUpDKKa9H5iK94mWFNY/rOJl
zwWAAw6WfAxj
=wiVz
-END PGP SIGNATURE-

Bug#921484: Origin of background.js and manifest.json not documented?

[Vincent Bernat]

Package: webext-browserpass
Version: 2.0.22-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

I am curious to know why there is a debian/background.js as well as a
debian/manifest.json? They are not documented in debian/copyright. The
manifest seems to have a bogus version numbre (2.1.19 instead of
2.0.22) and is different from the manifest shipped in
{firefox/chrome}/manifest.json. The background.js is also different
(fillLoginForm doesn't have the right signature for example).

Thanks.

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

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

Versions of packages webext-browserpass depends on:
ii  libc6  2.28-5

Versions of packages webext-browserpass recommends:
ii  chromium  72.0.3626.81-1
ii  firefox   65.0-1

webext-browserpass suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlxaN5kSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5hMsP/0Z/JrWfOJLZzSy5/0QIzJYlzkhtcpsI
iehpCZuAoMn5vkmthZT7drdUUclHGKk6QHhnpWRi0nk2d5CF7wFhKdn7VUx32oKD
h0rIxDA+8O17SqZxNNBcykiKbODVpRqIu3L04BqrlVnNMIJotyQmf+ddAq41Bast
IXL0tENdNNOXtuUXAaU6//wBvKChe0Mnq4L5m084Jj8do+enDELiMO9Eu3/fs/EL
nOdOrltMS+6UAik4K3cA/8l/ZX5wsYJbQTmrFizkyNNqWRnx83imbPHmPsMhPsAA
M4LL5XMsMNEeY0VYyQHgtONkb0J8XMGO2hOODvx5xhoEx71PA+/NgP/IN2XDbUaz
8SXc5UIoR/ATHreN05DyG55eiQGMJo8AdQmAsyJdULn7vMLU00HawutMW62M324+
gyJY00h+9ZB6lP8crNtR2a4rR/tHxQef4zhNC0zuJqMEV0LDltefqOas9PAVPBzB
T0k2jPlbmGqX60aqCQYKL+LYEZd2ZZnAdEDIeqXiQ2kpEabLYaQDoUpepDiVXYpj
Sr3xXYFYDvUVylbEdqAqR5nQ6t8xHVwcriq9JkaXFqJfUj1W80dMLd/bhrd/E5dP
xgx8j0jJuLf2jX/KT5VNUymWyCLPpEvZHm/0NDiJmnQ9TigtIJrZx8tt5e7HvzxU
Wb2keYQ6r02I
=8GJn
-END PGP SIGNATURE-

Bug#915636: python3-virtualenv: incompatible with python3-pip 18.1 - AttributeError pip.main - please upgrade to 16.1.0

[Vincent Bernat]

 ❦ 13 décembre 2018 11:54 +0100, Vincent Bernat :

>> find attached my NMU .debian.tar using the updated 16.1.0 version.
>> As I found no documentation what you +ds version removed from the
>> upstream TAR ball, I'm using the pristine upstream TAR ball.
>>
>> Upstream moved most files to the src/ sub-directory, so all 3 patches
>> did no longer apply and several files in debian/ need updating.
>>
>> Whith that new version I'm again able to use "virtualenv".
>
> I am planning to do a team upload to fix this today. As I am not
> familiar with the package, I will simply use the route of least change
> and apply a patch to try to get "main" from "pip._internal" (like this
> is done upstream). I don't think your NMU is valid as pip is expected to
> not be shipped inside this package (excluded in debian/copyright). There
> are also additional changes in git.

I pushed a fix to the git repository. It works fine for me. I'll upload
that later today.

 
https://salsa.debian.org/python-team/modules/python-virtualenv/commit/61347bcae01e8cbaf1eae619803435757875a4da
-- 
Instrument your programs.  Measure before making "efficiency" changes.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#915636: python3-virtualenv: incompatible with python3-pip 18.1 - AttributeError pip.main - please upgrade to 16.1.0

[Vincent Bernat]

 ❦  5 décembre 2018 15:12 +0100, Philipp Hahn :

> find attached my NMU .debian.tar using the updated 16.1.0 version.
> As I found no documentation what you +ds version removed from the
> upstream TAR ball, I'm using the pristine upstream TAR ball.
>
> Upstream moved most files to the src/ sub-directory, so all 3 patches
> did no longer apply and several files in debian/ need updating.
>
> Whith that new version I'm again able to use "virtualenv".

I am planning to do a team upload to fix this today. As I am not
familiar with the package, I will simply use the route of least change
and apply a patch to try to get "main" from "pip._internal" (like this
is done upstream). I don't think your NMU is valid as pip is expected to
not be shipped inside this package (excluded in debian/copyright). There
are also additional changes in git.
-- 
Make sure input cannot violate the limits of the program.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#915043: nikto: missing build on all

[Vincent Bernat]

 ❦ 29 novembre 2018 16:51 -0200, Eriberto Mota :

> I've prepared an NMU for nikto (versioned as 1:2.1.5-3.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

Thanks. You can upload it right now if you want.
-- 
What I tell you three times is true.
-- Lewis Carroll


signature.asc
Description: PGP signature

Bug#906978: Bug is in pysnmp4

[Vincent Bernat]

 ❦ 10 septembre 2018 14:32 +0200, Thomas Goirand :

> Upstream updated the issue and write it's an problem with pysnmp4:
>
> https://github.com/etingof/pysnmp/issues/193
>
> The issue is fixed in the master branch of pysnmp, but there's no
> release for it yet.
>
> Should we reasign the bug? I'll let you do that Vincent.

Done. I suppose 4.4.6 will be released soon.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#906955: isync: can't verify some ssl certificate(e.g. imap.gmail.com)

[Vincent Bernat]

Package: isync
Version: 1.3.0-1
Followup-For: Bug #906955

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

I run into the same problem. Here is a patch fixing the issue for me:
 https://sourceforge.net/p/isync/isync/merge-requests/2/

I don't know why it worked with OpenSSL 1.1.0. I didn't find anything
related in OpenSSL changelog.

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

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

Versions of packages isync depends on:
ii  libc6   2.27-5
ii  libdb5.35.3.28+dfsg1-0.1
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3.1
ii  libssl1.1   1.1.1~~pre9-1
ii  zlib1g  1:1.2.11.dfsg-1

isync recommends no packages.

Versions of packages isync suggests:
ii  mutt  1.10.1-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlt9nXwSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5xhAP/RxvZrXeA4BaGMuTAH0FzZFFvE+1d7FY
HNt2SdTHH/yOjvdWVqZxRHdQdqL8Cu5NI840E51FP0s3x7lJNjiVBgQN/SUxnmNM
TCIsOvME1rlo0XdsWq9hdlwBKpSiewly1NPjsVqqa5t0YucKeM5Ml2EpQcwJbrS5
+XKrL9d4PIZ+Jn4v3Irbi4uHQ+lBL0hdEpbJoAiMMIIOIX3g57Zgagjh3u54JAwL
6Q7sFQWTYHOYs/BCxrFLVN62/TLc9KB0BmFZziBgSO/cymSYhaw5IvaX7eCkQyLj
M7l6uOWv0U/XNDSZ8AaR3cLqOBvLYZimUs9JkySLsecNTEdfnnshmmzKwvyMNDgZ
eFhHbKcoVdhfFdC1lvb77bE50fXtQXxGsLamZ5VBPstSHFLAitFgIylt+KskXPQm
QI2vHi7Nal6DOPRyqzGb72dKdaef1IotOvtcJAQSOtR5xGhSuFb2C+wAhk+h7JIr
aEpN5PePCAdKqmvMyw8wXOqXz59c0i8P5+aCvJQ27OzKp2A+XRuv68wkDj2kADXN
9dkD9vNPDkS86lmruGOPMpK3rhlB4e7+izVYAnaLd6zG4/XXEzPKNYxQ/8L6Jf4X
G0a5L4XfFvI9EbHJcZWfp1skxmFopr9YD3tDcNbCZyN49GHxA7IPx98uOZswCl0c
ksjSAptefI4+
=GudL
-END PGP SIGNATURE-

Bug#905403: graphite-api ftbfs

[Vincent Bernat]

 ❦  4 août 2018 07:33 +0200, Matthias Klose :

> Package: src:graphite-api
> Version: 1.1.3-3
> Severity: serious
> Tags: sid buster
>
> missing build dependencies?
>
> running build_ext
> tests (unittest.loader._FailedTest) ... ERROR
>
> ==
> ERROR: tests (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: tests
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/unittest/loader.py", line 153, in loadTestsFromName
> module = __import__(module_name)
>   File "/<>/tests/__init__.py", line 15, in 
> from graphite_api.app import app
>   File "/<>/graphite_api/app.py", line 24, in 
> from .render.glyph import GraphTypes
>   File "/<>/graphite_api/render/glyph.py", line 15, in 
> import cairocffi as cairo
>   File "/usr/lib/python3/dist-packages/cairocffi/__init__.py", line 18, in 
> 
> from ._ffi import ffi
>   File "/usr/lib/python3/dist-packages/cairocffi/_ffi.py", line 3, in 
> from xcffib._ffi import ffi as _ffi0
> ModuleNotFoundError: No module named 'xcffib'

I don't quite understand how the cairocffi can be imported interactively
without xcffib being installed (it's only a recommends) but not during
tests. I'll just add the appropriate build dependency to ensure it's
here.
-- 
It were not best that we should all think alike; it is difference of opinion
that makes horse-races.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Bug#903663: python3-numpy: Should not depend on python3.7

[Vincent Bernat]

Package: python3-numpy
Followup-For: Bug #903663

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Why does python3-numpy depend on Python 3.7? It should work with any
Python 3.x package. As a number of packages are uninstalled when
python3.7 is installed, it would be convenient to not have a
dependency on it.

Thanks

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

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

Versions of packages python3-numpy depends on:
ii  libatlas3-base [liblapack.so.3]  3.10.3-7+b1
ii  libblas3 [libblas.so.3]  3.8.0-1+b1
ii  libc62.27-5
ii  liblapack3 [liblapack.so.3]  3.8.0-1+b1
ii  python3  3.6.6-1
ii  python3.63.6.6-1
ii  python3.73.7.0-2

python3-numpy recommends no packages.

Versions of packages python3-numpy suggests:
ii  gcc4:8.1.0-1
ii  gfortran   4:8.1.0-1
pn  python-numpy-doc   
ii  python3-dev3.6.6-1
ii  python3-nose   1.3.7-4
pn  python3-numpy-dbg  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAltg5hoSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5Y8EQAIuFF9KPC1dscACAnpLfe2tmVOG2vf1h
JM2tX4/l5pKBe8XRiUXIESS7/p3difPwmisQTLSOPzXNs+tpHbHo3BOMHSNWfI7p
xoeoIsuu3mRQ4tszaluLae0Pz9VRtUzg/iceDfMdRRUEXMUKmC+VAInvngeuYTHj
VOaUFyduA53lLWry82rRgx1zzKZMfw0cMY9bxBt0WsurfGRYyYHizpPFF0LGeoOh
e8u+pc+zVqFoamR2qOXjB9URqhlW7nqRADTA0iFSHCX5JBZqHBQFmhXjw2PjxLIN
lR0be6bioVO40cnbbe07MjRrA1Z3MyugDdnSQ8yeGP3leGiwTgjdho4/dfbpRnj7
aIdihnt31nLDyathfqeCXyinfQRr+46UhHGFhoMdbQxnN8Iv+eCljyBQVrivKmwc
mWpwtDVEDrYQ0vDWD4AAGpq5QzBpXZrhQzlq9oCatHkGPGwFDFIdK+5gQfin0qLx
Xueo6ZDzLn9E9s3/djqKvXAF5KCq+eEIqDObVuUpd8hqu0JcfWYv2uzQiqmjV/qw
X/DFsO918TeAtRqsZ1nih46EKpvaPodzRxx7wGKutshB1pD2A07sdUDvPyKYS9XX
m3yPaKM5lhkayvOuhyNDWS9eFoLEY0rFSUO/1xhLmq7Nw5cjaCRNtJ7g694nB6dJ
nM9bvO+FqMjG
=8IQi
-END PGP SIGNATURE-

Bug#872413: kpatch: Please package new upstream version

[Vincent Bernat]

 ❦ 15 avril 2018 09:58 +0200, Simon Ruderich  :

>> As the package is not currently usable with our kernel, or even the
>> one in stable, I am bumping the severity. Since you already worked a
>> lot on this, would you be interested to prepare an upload for 0.5.0? If
>> yes, we could sort out how to organize that.

> Thanks for your initiative. Patch to update to 0.5.0 (as diff
> from the current version in Debian Sid) is attached. It's based
> on the upstream kpatch tarball from github with the following
> sha512 checksum:
>
> 
> d7e45a4395a8c7632187ca5c8b837bad0d7583f66ce5f5d2b8f1acabf9ff2539d038a16986f9846818183f5c3268a613580a98ad72f3766e286e6273d57ddc78
> kpatch_0.5.0.orig.tar.gz

Simon, your patch looks OK to me. I'll change the changelog entry to
say:

 * Non-maintainer upload.
 * New upstream release. Closes: #872413.

Chris, do you object to an upload to update kpatch?
-- 
Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Bug#894533: cookiecutter: please drop catchlog dependency

[Vincent Bernat]

 ❦  5 avril 2018 09:25 +0200, Gianfranco Costamagna  :

> I uploaded the package in deferred/5, as Team upload.
>
> Unfortunately I can't push because the 1.6.0-1 upload hasn't been
> pushed yet, so I'll attach the debdiff between the current package in
> unstable and the one in deferred/5
>
> please let me know if I can speed it up, this is the last blocker for
> catchlog removal

Hi!

I have just pushed the content of my git repository. Unfortunately, as I
didn't do it earlier, the debian/1.6.0-1 tag is not part of the tree. I
could move it, but it wouldn't match the upload. I think this is better
to keep it as is.

You should now be able to rebase and push if you want to.

I am in the "Maintainer" field by accident. This is what "py2dsp
--profile dpmt" does and I just noticed that lately. I consider all "my"
packages to be team-maintained. I'll try to fix that in future uploads.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#887579: marked as pending

[Vincent Bernat]

tag 887579 pending
thanks

Hello,

Bug #887579 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/binaryornot.git/commit/?id=82dfdb4

---
commit 82dfdb4c190f9ae7e3a0dd99c6e88333e8fa38c5
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Thu Jan 18 08:53:38 2018 +0100

Fix crashing test with recent python-hypothesis

diff --git a/debian/changelog b/debian/changelog
index 0378bc0..e5e57f8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+binaryornot (0.4.4+dfsg-2) unstable; urgency=medium
+
+  * Fix crashing test with recent python-hypothesis. Closes: #887579.
+
+ -- Vincent Bernat <ber...@debian.org>  Thu, 18 Jan 2018 08:53:35 +0100
+
 binaryornot (0.4.4+dfsg-1) unstable; urgency=medium
 
   * New upstream version.

Bug#880352: marked as pending

[Vincent Bernat]

tag 880352 pending
thanks

Hello,

Bug #880352 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/python-aiohttp.git/commit/?id=072b988

---
commit 072b98813bec20e0ded34389e91078fd369270d9
Author: Vincent Bernat <ber...@debian.org>
Date:   Sun Nov 26 19:06:57 2017 +0100

d/rules: clean generated C files. Closes: #880352

diff --git a/debian/changelog b/debian/changelog
index 6f64715..94ade01 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python-aiohttp (2.2.3-2) unstable; urgency=medium
+
+  * d/rules: clean generated C files. Closes: #880352.
+
+ -- Vincent Bernat <ber...@debian.org>  Sun, 26 Nov 2017 19:06:47 +0100
+
 python-aiohttp (2.2.3-1) unstable; urgency=medium
 
   * New upstream release

Bug#881096: marked as pending

[Vincent Bernat]

tag 881096 pending
thanks

Hello,

Bug #881096 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/python-asyncssh.git/commit/?id=30e52d3

---
commit 30e52d38eb1f96ae111049aefca3871bba47ab4d
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sat Nov 11 21:23:48 2017 +0100

d/patches: remove tests using deprecated ciphers. Closes: #881096

diff --git a/debian/changelog b/debian/changelog
index 33bae7b..be7f973 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python-asyncssh (1.11.0-2) unstable; urgency=medium
+
+  * d/patches: remove tests using deprecated ciphers. Closes: #881096.
+
+ -- Vincent Bernat <ber...@debian.org>  Sat, 11 Nov 2017 21:23:44 +0100
+
 python-asyncssh (1.11.0-1) unstable; urgency=medium
 
   * New upstream version.

Bug#881096: marked as pending

[Vincent Bernat]

tag 881096 pending
thanks

Hello,

Bug #881096 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/python-asyncssh.git/commit/?id=fd7facb

---
commit fd7facb7998eee7e7eea9c74335ab5b9c8e28104
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sat Nov 11 21:39:41 2017 +0100

d/changelog: still a bug to be fixed

diff --git a/debian/changelog b/debian/changelog
index be7f973..2079fc5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
-python-asyncssh (1.11.0-2) unstable; urgency=medium
+python-asyncssh (1.11.0-2) UNRELEASED; urgency=medium
 
   * d/patches: remove tests using deprecated ciphers. Closes: #881096.
+  * TODO: second error in #881096 (killing SSH agent).
 
  -- Vincent Bernat <ber...@debian.org>  Sat, 11 Nov 2017 21:23:44 +0100
 

Bug#882125: incompatible with pidgin apparmor profile

[Vincent Bernat]

Package: pidgin-sipe
Version: 1.23.0-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

AppArmor is now enabled by default in Debian and pidgin comes with an
AppArmor profile. When pidgin-sipe is installed, we get this error:

/usr/bin/pidgin: line 7: /etc/default/pidgin-sipe: Permission denied
/usr/bin/pidgin: line 10: /usr/bin/pidgin.orig: Permission denied

And the following audit trace:

[24779.428556] audit: type=1400 audit(1511089685.134:32848): apparmor="DENIED" 
operation="open" profile="/usr/bin/pidgin" name="/dev/tty" pid=18727 
comm="pidgin" requested_mask="wr" denied_mask="wr" fsuid=500 ouid=0
[24779.428637] audit: type=1400 audit(1511089685.134:32849): apparmor="DENIED" 
operation="open" profile="/usr/bin/pidgin" name="/dev/pts/1" pid=18727 
comm="pidgin" requested_mask="wr" denied_mask="wr" fsuid=500 ouid=500
[24779.429361] audit: type=1400 audit(1511089685.135:32850): apparmor="DENIED" 
operation="open" profile="/usr/bin/pidgin" name="/etc/default/pidgin-sipe" 
pid=18727 comm="pidgin" requested_mask="r" denied_mask="r" fsuid=500 ouid=0
[24779.429583] audit: type=1400 audit(1511089685.135:32851): apparmor="DENIED" 
operation="exec" profile="/usr/bin/pidgin" name="/usr/bin/pidgin.orig" 
pid=18728 comm="pidgin" requested_mask="x" denied_mask="x" fsuid=500 ouid=0
[24779.429586] audit: type=1400 audit(1511089685.135:32852): apparmor="DENIED" 
operation="open" profile="/usr/bin/pidgin" name="/usr/bin/pidgin.orig" 
pid=18728 comm="pidgin" requested_mask="r" denied_mask="r" fsuid=500 ouid=0


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

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

Versions of packages pidgin-sipe depends on:
ii  libc6   2.25-1
ii  libcomerr2  1.43.7-1
ii  libdbus-1-3 1.12.2-1
ii  libfarstream-0.2-5  0.2.8-2
ii  libglib2.0-02.54.2-1
ii  libgssapi-krb5-21.15.2-2
ii  libgstreamer-plugins-base1.0-0  1.12.3-1
ii  libgstreamer1.0-0   1.12.3-1
ii  libk5crypto31.15.2-2
ii  libkrb5-3   1.15.2-2
ii  libnice10   0.1.14-1
ii  libnspr42:4.16-1
ii  libnss3 2:3.34-1
ii  libpurple0  2.12.0-1+b1
ii  libxml2 2.9.4+dfsg1-5.1

Versions of packages pidgin-sipe recommends:
ii  gstreamer1.0-libav  1.12.3-1
ii  gstreamer1.0-x  1.12.3-1
ii  remmina-plugin-rdp  1.2.0-rcgit.24-3

pidgin-sipe suggests no packages.

- -- Configuration Files:
/etc/default/pidgin-sipe changed:
export NSS_SSL_CBC_RANDOM_IV=0


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAloRZjcSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX505wQAIkEk+vD1JooOFNdVhcTeNiXd0PxszOT
EFYdV/hrcU1iGkY9Az+PGu9aDwRRknoeAR2XXiE4PsEjz+KE4M/xbFAZmHETJbna
eNW7HT9yZXI2EUb8lyrB96VPO1uT56973BEvw9u7wV+gH74ROe417XMflV/iUw54
NrIsbr04piJiALOipmjTv/vBhNSlQtI7Yz/Xx8PA/IdJiIglYS3WVPWItAL5EZrT
mVmk8srhejNw2zwlnzUXFTJh1um2iSMDRMDGtRSsQT+nXNYRvWzcBOdkfyR/v5rg
/dzrE3kTLNOgk5zFEaoAfj8lzpegvevuiHBgGkNgnXa6D+Vlf8CK9KE280wai7ah
SzyJ6P+i5GJWbhP6ffE4aAGZXmZHX2susd/2ut74yPU83MRcsKgdqlyp8XlZRxmc
WdPGJxbzAQqT1ExoY4W+WVRGTBIMfoAQQYdr8pw+OnEF8IMx1BX/Voxe9qVssfmv
SRhHmvxMk9qr6HIsU3TqLnQLwuLN1Vte1RRgqALPphdwZCUOh4nClCBilctyLt9y
K0k5DRrw+90gHa9I37INdUpPrYmP63oE9g+APZOgWKyfzWzTumtLfE9upuDf4MzS
YvjMM7b/ynl28MjwSJP8T8ZfDRJddjP/SCeMsBRZCeDK1YPmT60TEQs/9o6TJS8l
zqKzbwbMQFiy
=ipen
-END PGP SIGNATURE-

Bug#871127: marked as pending

[Vincent Bernat]

tag 871127 pending
thanks

Hello,

Bug #871127 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/pytest-mock.git/commit/?id=e3f36df

---
commit e3f36dfe611bae5e6e4424762b3bd0300f01a73c
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Mon Sep 18 19:15:52 2017 +0200

New upstream version

diff --git a/debian/changelog b/debian/changelog
index 1420be4..8abb790 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pytest-mock (1.6.3-1) UNRELEASED; urgency=medium
+
+  * New upstream release. Closes: #872618.
++ Fix FTBFS due to deprecated use of mock fixture. Closes: #871127.
+
+ -- Vincent Bernat <ber...@debian.org>  Mon, 18 Sep 2017 19:14:32 +0200
+
 pytest-mock (1.3.0-1) unstable; urgency=medium
 
   * New upstream release.

Bug#854701: python-asyncssh: FTBFS randomly (failing tests)

[Vincent Bernat]

 ❦  7 mars 2017 14:04 +0100, Santiago Vila  :

> To double-check, I just build this package today 100 times and it
> failed 72 times.

Could you try again with 1.11.0-1 in unstable? I am unable to get any
failure, but wasn't able to get them in the first place.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#871692: [pkg-go] Bug#871692: gobgp FTBFS on arm64: Test killed with quit: ran too long (10m0s).

[Vincent Bernat]

 ❦ 10 août 2017 20:29 +0300, Adrian Bunk  :

> https://buildd.debian.org/status/fetch.php?pkg=gobgp=arm64=1.22-1=1502350034=0

time="2017-08-10T07:25:14Z" level=debug msg="failed to connect: function not 
implemented" Key=127.0.0.1 Topic=Peer 

I suspect the running kernel doesn't have CONFIG_TCP_MD5SIG=y. Could you 
confirm?
-- 
He that breaks a thing to find out what it is has left the path of wisdom.
-- J.R.R. Tolkien


signature.asc
Description: PGP signature

Bug#867396: marked as pending

[Vincent Bernat]

tag 867396 pending
thanks

Hello,

Bug #867396 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/cerealizer.git/commit/?id=3010d92

---
commit 3010d920ae44d29f03aa9acd93f9de897864cc6c
Author: Vincent Bernat <ber...@debian.org>
Date:   Thu Jul 6 20:00:24 2017 +0200

Fix python3-cerealizer Depends field. Closes: #867396

diff --git a/debian/changelog b/debian/changelog
index 7204666..962493d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
-cerealizer (0.8.1-2) UNRELEASED; urgency=medium
+cerealizer (0.8.1-2) unstable; urgency=medium
 
+  [ Ondřej Nový ]
   * Fixed VCS URL (https)
 
- -- Ondřej Nový <n...@ondrej.org>  Tue, 29 Mar 2016 21:24:25 +0200
+  [ Vincent Bernat ]
+  * Fix python3-cerealizer Depends field. Closes: #867396.
+
+ -- Vincent Bernat <ber...@debian.org>  Thu, 06 Jul 2017 19:59:17 +0200
 
 cerealizer (0.8.1-1) unstable; urgency=low
 

Bug#840516: patterns are deprecated

[Vincent Bernat]

 ❦  8 mai 2017 10:38 GMT, Stephane Bortzmeyer  :

> There are several reasons why graphite-web does not work with Django
> 1.10 (the current version in sid). One of them is that it uses the
> "patterns" variable:

This seems to have been fixed upstream (but unreleased):

https://github.com/graphite-project/graphite-web/commit/bf8e53b15b957d63cf2b85e679d931093c764e9d
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#861388: [Pkg-roundcube-maintainers] Bug#861388: roundcube: CVE-2017-8114: security issue in virtualmin and sasl drivers

[Vincent Bernat]

 ❦  1 mai 2017 23:57 +0200, Guilhem Moulin  :

>> the following vulnerability was published for roundcube.
>> 
>> CVE-2017-8114[0]:
>> security issue in virtualmin and sasl drivers
>
> Thanks, pushed.  Sandro, Vincent, would you mind tagging & uploading?

Done. Thanks!
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#861366: Etherpuppet, unusuable on systems with unsigned char.

[Vincent Bernat]

 ❦ 28 avril 2017 02:04 +0100, peter green  :

> Etherpuppet has a bug with it's command line parsing that makes it
> unusable on systems with unsigned char. Someone found an upstream fix
> for me and submitted it to a raspbian bug report.
>
> A debdiff can be found at 
> http://debdiffs.raspbian.org/main/e/etherpuppet/etherpuppet_0.3-2%2brpi1.debdiff
>
> If there is no maintainer response to this bug report a NMU is likely
> to follow.

Feel free to NMU. Otherwise, I'll do that in the next days.
-- 
Avoid unnecessary branches.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#859655: [pkg-go] Bug#859655: golang-go.crypto: CVE-2017-3204

[Vincent Bernat]

 ❦ 14 avril 2017 15:07 -0400, anarcat  :

> I looked into this during the Montreal BSP, and it's unclear what we
> should do here, considering there has been multiple new uploads since
> the stretch freeze. 
>
> The patch is pretty long:
>
> https://github.com/golang/crypto/commit/e4e2799dd7aab89f583e1d898300d96367750991
>
> ... and there's no way to just backport it into stretch at this point
> (IIRC).

The patch is not that big. Most of its content is in tests and
examples. The only problem is that it exposes a behavioral change that
may break reverse dependencies at runtime.

> So I'm wondering if the next step here would not just be to ask for an
> exception to unblock this for stretch, or just tell the release team to
> just ignore this and drop the package from stretch.

There are many reverse dependencies that would be removed by removing
this package, including some high profile ones, like etcd, rkt,
influxdb. Their removal will in turn remove a lot of additional
packages.
-- 
A is for Apple.
-- Hester Pryne


signature.asc
Description: PGP signature

Bug#857473: [Pkg-roundcube-maintainers] Bug#857473: roundcube: XSS issue in handling of a style tag inside of an svg element

[Vincent Bernat]

 ❦ 14 mars 2017 04:16 +0100, Guilhem Moulin  :

>> 1.2.4 roundcube release fixed a XSS issue in handling of a style tag
>> inside of an svg element.
>
> Thanks for the ping and the pointers!  I applied the fix to 1.2.3
> (unstable) and 1.1.5 (jessie-backports).
>
> Could someone else in the team upload the two source packages?  I don't
> have upload privileges :-P  (Also I didn't tag the releases.)

Both of them uploaded.
-- 
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Vincent Bernat]

 ❦ 10 mars 2017 09:29 GMT, Simon McVittie  :

>> I suppose that's why I am in copy (the other actions are pretty obvious
>> and I suppose Scott will apply them soon; I can also do that if he's
>> unavailable).
>
> The other reason I wanted to Cc you is because as sponsor, you were
> responsible for checking that the package split proposed by the
> maintainer was Policy-compliant. I would have expected a sponsor to
> query the current library packaging and not upload without changes,
> because as it stands at the moment, it isn't correct for either
> private/internal libraries or public libraries; it's somewhere in
> between.
>
> (In particular, seeing the Lintian overrides in the diff should probably
> have been a warning sign.)

During the first upload, the packaging was policy compliant as all
libraries were sharing the same version. There was no override. The
change in SO name for libzebra was done during a minor version
update. At this time, I suggested to solve the problem by ignoring
lintian instead of being overly complicated for a library without
reverse dependencies. My bad.

>> Acting like it is a
>> "0" versioning in the packaging shows there is no real guarantee in
>> that and is less invasive than patching the source.
>
> No, acting like it is a "0" version is saying that this library is fully
> compatible with all previous versions of libquagga0. This is clearly
> not true: anything with a DT_NEEDED entry for libzebra.so.0 would now
> fail to load, because there is no longer a libzebra.so.0 in the
> package.

That's the technical side. 0 can also mean that upstream doesn't
care about versioning (because that's also the default value).

> If a library offers development files and is placed on the default
> search path for the linker, then its maintainer is effectively saying
> it is a normal public shared library and will be managed accordingly,
> including package renames, ABI transitions and going through the NEW
> queue if it becomes necessary. If that isn't the intention, then the
> library shouldn't be on the default search path.
>


>>  - removing libquagga0 and libquagga-dev and put the libraries in
>>quagga-core and in /usr/lib/quagga. Not shipping the development
>>files. This is a change that would likely to be accepted by the
>>release team.
>
> I would recommend this route. As you say, splitting libquagga0 into
> 5 library packages seems like overkill if nobody is going to use it.
>
> If it is going to be treated as a public shared library in a future
> version, at that point you will have no choice but to split it (at
> least the parts whose SONAMES end with a nonzero version, but it
> would be safer to do the full split). But it sounds as though that
> is more appropriate for the future, or perhaps never, than for
> stretch.

OK with that.
-- 
Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Vincent Bernat]

 ❦ 10 mars 2017 00:18 GMT, Simon McVittie  :

> Third bug: libraries with different SONAME versioning packaged together
> ---
>
> Lintian has done its best to advise the maintainer not to do this, but
> unfortunately the warning has been overridden.
>
> If these are public libraries, I would recommend not overriding
> "package-name-doesnt-match-sonames", and instead doing as Lintian suggests.
> This will require a trip through the NEW queue, unfortunately.

I suppose that's why I am in copy (the other actions are pretty obvious
and I suppose Scott will apply them soon; I can also do that if he's
unavailable). There are two (combined) reasons I asked for the override:

 1. It's quite unclear why upstream started to use a non-zero version
for the ABI numbering of libzebra. Maybe they will start enforcing
an ABI (it's the library that external projects should be the most
interested in using), maybe it's an oversight. Acting like it is a
"0" versioning in the packaging shows there is no real guarantee in
that and is less invasive than patching the source.

 2. The change is pretty recent and a major overhaul of the packaging
would have pushed past the deadline for the freeze (due to NEW). It
would have been difficult to explain why libquagga0 split in 5
packages is useful (no reverse dependencies).

I would favor the following corrective actions (in this order):

 - leaving libquagga0 package as is and fixing the other bugs

 - removing libquagga0 and libquagga-dev and put the libraries in
   quagga-core and in /usr/lib/quagga. Not shipping the development
   files. This is a change that would likely to be accepted by the
   release team. But maybe the reporter of #705306 would find that not
   helpful (it's unclear if he is a user of the actual libquagga-dev or
   if he was just asking from a policy point of view).
-- 
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#855906: [pkg-go] Bug#855906: golang-codegangsta-cli: FTBFS: FAIL: TestCommandYamlFileTestDefaultValueFileWins (0.00s) helpers_test.go:10: Expected 15 (type int) - Got 7 (type int)

[Vincent Bernat]

 ❦  4 mars 2017 17:38 -0300, Martín Ferrari  :

> Vincent, are you requesting an unblock exception for this package? There
> are a bunch of other packages that are going to be removed from testing
> if this does not migrate.

I just sent the unblock request.
-- 
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#855906: golang-codegangsta-cli: FTBFS: FAIL: TestCommandYamlFileTestDefaultValueFileWins (0.00s) helpers_test.go:10: Expected 15 (type int) - Got 7 (type int)

[Vincent Bernat]

 ❦ 23 février 2017 16:57 +0800, Chris Lamb  :

>   dh_auto_test: go test -v -p 1 github.com/codegangsta/cli 
> github.com/codegangsta/cli/altsrc returned exit code 1
>   debian/rules:4: recipe for target 'build' failed
>   make: *** [build] Error 1
>   dpkg-buildpackage: error: debian/rules build gave error exit status
>   2

Bisected to
https://github.com/urfave/cli/commit/d71794de198717467a8f053036b5620ccb0d613c.

Confirmed the bug is still in 1.18.1 and gone from 1.19.0. The patch is
quite invasive and doesn't apply cleanly on top of 1.18.x because it
relies on a totally different approach (with code generation). I don't
see any "[aA]pplyWithError" function in the current code that could be
patched. I have also no clue why this problem happens now and not
before. I suppose a change in the dependencies.

I would propose to turn this package as a semi-transitional package to
golang-github-urfave-cli-dev (just a symlink). However,
golang-github-urfave-cli-dev in testing has exactly the same problem but
it doesn't happen because it is ignoring the "altsrc" directory. In
unstable, it doesn't work either if we remove the altsrc directory
(because it is missing a symlink for gopkg.in/urfave/cli.v1).

As a quick workaround, as there is absolutely no use of
github.com/codegangsta/cli/altsrc in Debian, I'll just exclude it from
the package too.
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#855208: [pkg-go] Bug#855208: docker still broken

[Vincent Bernat]

 ❦ 24 février 2017 12:34 -0800, Norbert Kiesel  :

> What else can I do to get docker working again?

You can install the one from experimental. It works fine with runc and
containerd from unstable. At this point, Tim should just upload it to
unstable.
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#854851: marked as pending

[Vincent Bernat]

tag 854851 pending
thanks

Hello,

Bug #854851 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/binaryornot.git;a=commitdiff;h=385c858

---
commit 385c8581cbe96b4a3c44e6a4ab10c2b13c1a879a
Merge: b20c951 ba65b70
Author: Roger Shimizu <rogershim...@gmail.com>
Date:   Wed Feb 15 21:07:15 2017 +0900

Import Debian changes 0.4.0+dfsg-0.1

binaryornot (0.4.0+dfsg-0.1) unstable; urgency=medium

  * Non-maintainer upload.

  [ Ondřej Nový ]
  * Fixed VCS URL (https)

  [ Roger Shimizu ]
  * Remove non-free image files, and repack as +dfsg.
  * Add patch to remove tests regarding to non-free image files.
(Closes: #854851)

diff --cc debian/changelog
index b9926cd,000..4fbdcd7
mode 100644,00..100644
--- a/debian/changelog
+++ b/debian/changelog
@@@ -1,35 -1,0 +1,43 @@@
- binaryornot (0.4.0-2) UNRELEASED; urgency=medium
++binaryornot (0.4.0+dfsg-0.1) unstable; urgency=medium
 +
++  * Non-maintainer upload.
++
++  [ Ondřej Nový ]
 +  * Fixed VCS URL (https)
 +
-  -- Ondřej Nový <n...@ondrej.org>  Tue, 29 Mar 2016 21:23:36 +0200
++  [ Roger Shimizu ]
++  * Remove non-free image files, and repack as +dfsg.
++  * Add patch to remove tests regarding to non-free image files.
++(Closes: #854851)
++
++ -- Roger Shimizu <rogershim...@gmail.com>  Wed, 15 Feb 2017 21:07:15 +0900
 +
 +binaryornot (0.4.0-1) unstable; urgency=medium
 +
 +  * New upstream release.
 +  * Bump Standards-Version.
 +  * Use PYBUILD_NAME in d/rules.
 +  * Add missing Build-Depends on python-{chardet,hypothesis}.
 +
 + -- Vincent Bernat <ber...@debian.org>  Sun, 15 Nov 2015 23:05:18 +0100
 +
 +binaryornot (0.3.0-1) unstable; urgency=medium
 +
 +  * New upstream release.
 +  * Bump Standards-Version.
 +  * Run unit tests.
 +
 + -- Vincent Bernat <ber...@debian.org>  Mon, 26 May 2014 16:30:25 +0200
 +
 +binaryornot (0.2.0-1) unstable; urgency=low
 +
 +  * New upstream release.
 + + Codebase has been improved. Closes: #722502.
 +
 + -- Vincent Bernat <ber...@debian.org>  Sun, 29 Sep 2013 12:29:42 +0200
 +
 +binaryornot (0.1.1-1) unstable; urgency=low
 +
 +  * Initial release. Closes: #722156.
 +
 + -- Vincent Bernat <ber...@debian.org>  Sun, 08 Sep 2013 16:41:15 +0200

Bug#854084: binaryornot: Non-determistically FTBFS due to unreliable timing in tests

[Vincent Bernat]

Control: severity -1 normal

<#secure method=pgpmime mode=sign>
 ❦  4 février 2017 09:25 +1300, Chris Lamb  :

>   […]
>   
>   ==
>   ERROR: test_never_crashes (tests.test_check.TestDetectionProperties)
>   --
>   Traceback (most recent call last):
> File "«BUILDDIR»/tests/test_check.py", line 180, in test_never_crashes
>   def test_never_crashes(self, data):
> File "/usr/lib/python2.7/dist-packages/hypothesis/core.py", line 438, in 
> wrapped_test
>   HealthCheck.too_slow,
> File "/usr/lib/python2.7/dist-packages/hypothesis/core.py", line 306, in 
> fail_health_check
>   raise FailedHealthCheck(message)
>   FailedHealthCheck: Data generation is extremely slow: Only produced 10 
> valid examples in 0.33 seconds (0 invalid ones and 1 exceeded maximum size). 
> Try decreasing size of the data you're generating (with e.g.average_size or 
> max_leaves parameters).
>   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for more 
> information about this. If you want to disable just this health check, add 
> HealthCheck.too_slow to the suppress_health_check settings for this test.
>   
>   --
>   Ran 43 tests in 0.557s

I have slowed down my own machine in a such ways tests are now taking 6s
to execute. I cannot reproduce this. I need to slow it down such that
tests take 20s to get this error (and it says 10 valid examples in 1.30
seconds and the test suite took 2.9s). Runing the tests in a loop
without CPU limitation (tests run in 1.88 seconds) doesn't trigger the
bug.

I don't intend disabling this test which seems important because there
is not enough CPU to run the test (even if this is not a timing-related
test). Like for memory and disk, I understand that test suites have some
expectation on how much CPU the environment should provide (otherwise,
we have to disable all timing related tests).
-- 
"You have been in Afghanistan, I perceive."
-- Sir Arthur Conan Doyle, "A Study in Scarlet"

Bug#851707: [pkg-gnupg-maint] Bug#851707: pinentry-gtk-2 frequently fails to grab the keyboard under awesome

[Vincent Bernat]

 ❦  3 février 2017 12:14 +0100, Werner Koch  :

>> I am fixing with this patch. Only lightly tested.
>
> FWIW, I forgot to push a fix I had in my local repo.  Just did this, put
> also not tested.  This is basically the same as yours but w/o any
> delay.

I think your patch is about #850708. In #851707, I don't get the
"already grabbed" error, I get:

** (pinentry-gtk-2:21583): CRITICAL **: could not grab keyboard: not viewable 
(3)
** (pinentry-gtk-2:21583): WARNING **: it took 4097 tries to grab the keyboard
-- 
Keep it right when you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#851707: pinentry-gtk-2 frequently fails to grab the keyboard under awesome

[Vincent Bernat]

Control: tags -1 + patch

 ❦  2 février 2017 10:50 +0200, Lauri Niskanen <a...@ape3000.com> :

> I can reproduce this bug with awesomewm on Arch Linux. I get the same
> error message as Vincent Bernat.
>
> As a workaround I changed my pinentry program to pinentry-gnome3.

I am fixing with this patch. Only lightly tested.

Index: pinentry-1.0.0/gtk+-2/pinentry-gtk-2.c
===
--- pinentry-1.0.0.orig/gtk+-2/pinentry-gtk-2.c
+++ pinentry-1.0.0/gtk+-2/pinentry-gtk-2.c
@@ -166,7 +166,7 @@ static int
 grab_keyboard (GtkWidget *win, GdkEvent *event, gpointer data)
 {
   GdkGrabStatus err;
-  int tries = 0, max_tries = 4096;
+  int tries = 0, max_tries = 256;
   (void)data;
 
   if (! pinentry->grab)
@@ -175,7 +175,8 @@ grab_keyboard (GtkWidget *win, GdkEvent
   do
 err = gdk_keyboard_grab (gtk_widget_get_window (win),
  FALSE, gdk_event_get_time (event));
-  while (tries++ < max_tries && err == GDK_GRAB_NOT_VIEWABLE);
+  while (tries++ < max_tries && err == GDK_GRAB_NOT_VIEWABLE
+ && (usleep(1000), TRUE));
 
   if (err)
 {
@@ -199,7 +200,7 @@ grab_pointer (GtkWidget *win, GdkEvent *
 {
   GdkGrabStatus err;
   GdkCursor *cursor;
-  int tries = 0, max_tries = 4096;
+  int tries = 0, max_tries = 256;
   (void)data;
 
   /* Change the cursor for the duration of the grab to indicate that
@@ -221,7 +222,8 @@ grab_pointer (GtkWidget *win, GdkEvent *
 cursor,
 gdk_event_get_time (event));
   while (tries++ < max_tries && (err == GDK_GRAB_NOT_VIEWABLE
- || err == GDK_GRAB_ALREADY_GRABBED));
+ || err == GDK_GRAB_ALREADY_GRABBED)
+ && (usleep(1000), TRUE));
 
   if (err)
 {

-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#851020: marked as pending

[Vincent Bernat]

tag 851020 pending
thanks

Hello,

Bug #851020 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/python-asyncssh.git;a=commitdiff;h=ebe72f7

---
commit ebe72f778cded72cd09bcbc99f80e446c2fd3535
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sat Jan 21 21:00:28 2017 +0100

Add a patch to fix FTBFS due to agent-related test failure

diff --git a/debian/changelog b/debian/changelog
index ecd7f31..31ebb61 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-asyncssh (1.8.1-2) unstable; urgency=medium
+
+  * Add a patch to fix FTBFS due to agent-related test failure.
+Closes: #851020.
+
+ -- Vincent Bernat <ber...@debian.org>  Sat, 21 Jan 2017 21:00:14 +0100
+
 python-asyncssh (1.8.1-1) unstable; urgency=medium
 
   * New upstream version.

Bug#850708: [pkg-gnupg-maint] Bug#850708: gpg: decryption failed: No secret key

[Vincent Bernat]

Control: clone -1 -2
Control: retitle -2 pinentry-gtk-2 frequently fails to grab the keyboard under 
awesome

<#secure method=pgpmime mode=sign>
 ❦ 17 janvier 2017 20:34 +0100, Vincent Lefevre  :

>> ** (pinentry-gtk-2:21583): CRITICAL **: could not grab keyboard: not 
>> viewable (3)
>> 
>> ** (pinentry-gtk-2:21583): WARNING **: it took 4097 tries to grab the 
>> keyboard
>> 
>> ** (pinentry-gtk-2:21583): WARNING **: it took 990 tries to grab the pointer
>> ERR 83886179 Operation cancelled 
>
> This is a different bug (or not a bug at all). The problem you have is
> that it cannot grab the keyboard (while this bug was about an incorrect
> test about the pointer grab), and all the expected 4096 tries are done.
> This may not be enough (IMHO the tries should be time-based, with a
> nanosleep between them, until some timeout).

OK, let me clone this bug and continue from here.
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#850708: [pkg-gnupg-maint] Bug#850708: gpg: decryption failed: No secret key

[Vincent Bernat]

 ❦ 17 janvier 2017 12:13 +0100, Vincent Lefevre  :

>> I have the same behaviour with awesome. My setup didn't change since
>> quite some time but this behaviour is recent while neither awesome nor
>> pinentry-gtk2 has been updated. I got the behavior immediately after
>> rebooting. Applying the patch from Werner doesn't fix the problem for
>> me.
>
> What warning and error messages do you get with the following test?
>
>   echo getpin | pinentry-gtk-2
>
> (This is the one suggested by GI, the easiest way to reproduce the bug
> and get the warning and error messages.)

Here is the output I get:

OK Pleased to meet you

** (pinentry-gtk-2:21583): CRITICAL **: could not grab keyboard: not viewable 
(3)

** (pinentry-gtk-2:21583): WARNING **: it took 4097 tries to grab the keyboard

** (pinentry-gtk-2:21583): WARNING **: it took 990 tries to grab the pointer
ERR 83886179 Operation cancelled 
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#850708: [pkg-gnupg-maint] Bug#850708: gpg: decryption failed: No secret key

[Vincent Bernat]

 ❦ 11 janvier 2017 01:47 -0500, Daniel Kahn Gillmor  :

> On Tue 2017-01-10 20:58:16 -0500, Vincent Lefevre wrote:
>> On 2017-01-10 18:26:57 -0500, Daniel Kahn Gillmor wrote:
>>> what window manager are you using?
>>
>> fvwm
>
> hm, both Vincent and gi1242 are using fvwm.  can you try installing
> openbox or some other comparable minimalist window manager and let me
> know whether you still see the same misbehavior?  it sounds to me like
> y'all might have hit on a combination of tools (fvwm + pinentry-gtk2)
> that don't work well together.

I have the same behaviour with awesome. My setup didn't change since
quite some time but this behaviour is recent while neither awesome nor
pinentry-gtk2 has been updated. I got the behavior immediately after
rebooting. Applying the patch from Werner doesn't fix the problem for
me.
-- 
It has long been an axiom of mine that the little things are infinitely
the most important.
-- Sir Arthur Conan Doyle, "A Case of Identity"


signature.asc
Description: PGP signature

Bug#850023: marked as pending

[Vincent Bernat]

tag 850023 pending
thanks

Hello,

Bug #850023 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/ruamel.yaml.git;a=commitdiff;h=a0a9ef3

---
commit a0a9ef3eebe1fd45a60af6b4e8c29ec04c276077
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sat Jan 7 08:43:18 2017 +0100

Build-Depends on python-typing

diff --git a/debian/changelog b/debian/changelog
index 4850af3..49f2d76 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
-ruamel.yaml (0.13.4-2) UNRELEASED; urgency=medium
+ruamel.yaml (0.13.4-2) unstable; urgency=medium
 
+  [ Ondřej Nový ]
   * Enable autopkgtest-pkg-python testsuite
 
- -- Ondřej Nový <on...@debian.org>  Tue, 03 Jan 2017 10:48:33 +0100
+  [ Vincent Bernat ]
+  * Build-Depends on python-typing. Closes: #850023.
+
+ -- Vincent Bernat <ber...@debian.org>  Sat, 07 Jan 2017 08:43:02 +0100
 
 ruamel.yaml (0.13.4-1) unstable; urgency=medium
 

Bug#850023: ImportError when importing ruamel.yaml

[Vincent Bernat]

 ❦  6 janvier 2017 22:51 GMT, Chris Lamb  :

> So, the binary package is missing a Depends on `python-typing`.
>
> However, it looks like this "should" work:
>
>install_requires=dict(
>[…]
>py27=["ruamel.ordereddict", "typing"],
>[…]
>)

This seems to only work if the package is installed at build time. I'll push a
fixed version soon.
-- 
The naked truth of it is, I have no shirt.
-- William Shakespeare, "Love's Labour's Lost"


signature.asc
Description: PGP signature

Bug#849994: [Pkg-roundcube-maintainers] Bug#849994: roundcube-core: install fails; Class 'Patchwork\Utf8\Bootup' not found

[Vincent Bernat]

 ❦  3 janvier 2017 11:13 +0200, Guilhem Moulin  :

> If that's indeed the case, we should lower the severity as if this bug
> doesn't apply to 1.2.3+dfsg.1-1 it shouldn't prevent its inclusion in
> Stretch.

The Version: is correctly set, so it shouldn't be needed.
-- 
Be careful of reading health books, you might die of a misprint.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#824738: marked as pending

[Vincent Bernat]

tag 824738 pending
thanks

Hello,

Bug #824738 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/simpleparse.git;a=commitdiff;h=087e956

---
commit 087e956bbdb6bda9de89037998bcbca3bfc7e238
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sun Dec 25 10:49:00 2016 +0100

Switch to pybuild

diff --git a/debian/changelog b/debian/changelog
index 459e56d..5299080 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,8 @@ simpleparse (2.2.0-1) unstable; urgency=medium
   [ Vincent Bernat ]
   * New upstream release.
 - drop "with"-keyword patch
+- fix FTBFS (Closes: #824738)
+  * Switch to pybuild.
 
  -- Vincent Bernat <ber...@debian.org>  Sun, 25 Dec 2016 10:39:11 +0100
 

Bug#847325: Unable to copy symlinks with copy_file

[Vincent Bernat]

 ❦  8 décembre 2016 02:08 GMT, Ben Hutchings  :

> (Annoyingly, I couldn't reproduce this at first because I tried just
> adding nouveau to /etc/initramfs-tools/modules.  Since mkinitramfs does
> *not* use 'set -e' (unlike most hooks), the 'failure' of copy_file was
> not fatal.)

I should have said that I got the error through plymouth hook.
-- 
Civilization is the limitless multiplication of unnecessary necessities.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#847287: [Pkg-roundcube-maintainers] Bug#847287: roundcube: Roundcube 1.2.2: Remote command execution via malicious email composing

[Vincent Bernat]

 ❦  7 décembre 2016 12:08 +0100, Guilhem Moulin  :

>> Is the tag for debian/1.1.5+dfsg.1-1_bpo8+1? The diff for it is pretty
>> big.
>
> 1.1.5+dfsg.1-1_bpo8+1 is the current version from jessie-backports (since
> April 29).  The diff between 1.1.5+dfsg.1-1_bpo8+1 and 1.1.5+dfsg.1-1_bpo8+2
> is merely the upstream fix
>
> 
> https://anonscm.debian.org/cgit/pkg-roundcube/roundcube.git/diff/?id=debian/1.1.5%2bdfsg.1-1_bpo8%2b2=debian/1.1.5%2bdfsg.1-1_bpo8%2b1

I deleted the tag on my side, fetched it again and the diff is now
OK. I'll upload in the next hour.
-- 
How apt the poor are to be proud.
-- William Shakespeare, "Twelfth-Night"


signature.asc
Description: PGP signature

Bug#847287: [Pkg-roundcube-maintainers] Bug#847287: roundcube: Roundcube 1.2.2: Remote command execution via malicious email composing

[Vincent Bernat]

 ❦  7 décembre 2016 11:27 +0100, Guilhem Moulin  :

>>> Unfortunately 1.2.x has many dependencies that aren't in
>>> jessie-backports yet.  I personally don't have the time nor energy to
>>> maintain said dependencies, so we asked backports folks for an exception
>>> to stick to 1.1.x for the bpo version, exception which was rejected.
>>> I'm afraid the remaining alternative is to take remove the package from
>>> jessie-backports :-(
>> 
>> Since the problem is quite serious, could you push the fix in bpo8+2
>> nonetheless? Then wait a bit before asking for removal from backports to
>> let actual users get an updated version. It seems far better than just
>> leaving some people with vulnerable versions on their systems.
>
> Just tagged and pushed ‘debian/1.1.5+dfsg.1-1_bpo8+2’.  Note that I
> moved jessie-backports's HEAD to its parent first as is was on
> debian/1.1.6+dfsg.1-1_bpo8+1 which didn't make it to bpo.  Running
>
> git branch jessie-backports debian/1.1.5+dfsg.1-1_bpo8+1
>
> before pull should fix this.  Sorry for the inconvenience.

Is the tag for debian/1.1.5+dfsg.1-1_bpo8+1? The diff for it is pretty
big.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#847312: [Pkg-roundcube-maintainers] Bug#847312: roundcube: maintainer address bounces

[Vincent Bernat]

 ❦  7 décembre 2016 09:52 +0100, Chris Lamb  :

> I tried to send an email to this package address, and I got:
>
>Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
> Post by non-member to a members-only list
>
> As per Policy §3.3: “The email address given in the ‘Maintainer’ control 
> field must accept mail from those role accounts in Debian used to send 
> automated mails regarding the package. This includes non-spam mail from 
> the bug-tracking system, […].”

Well, this is the case. The BTS is able to post in the mailing
list. And many other people seem to be able to post to it. I don't have
access to the administration interface of this mailing list, so I can't
check what are the rules exactly. I know there is some level of
filtering since I receive daily reminders for spam (but I can't process
them, and I don't want to either).
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#847287: [Pkg-roundcube-maintainers] Bug#847287: roundcube: Roundcube 1.2.2: Remote command execution via malicious email composing

[Vincent Bernat]

 ❦  7 décembre 2016 00:30 +0100, Guilhem Moulin  :

>> Version: 1.1.4+dfsg.1-1~bpo8+1
>> […]
>> So probably it is important to update to upstream version 1.2.3
>
> Unfortunately 1.2.x has many dependencies that aren't in
> jessie-backports yet.  I personally don't have the time nor energy to
> maintain said dependencies, so we asked backports folks for an exception
> to stick to 1.1.x for the bpo version, exception which was rejected.
> I'm afraid the remaining alternative is to take remove the package from
> jessie-backports :-(

Since the problem is quite serious, could you push the fix in bpo8+2
nonetheless? Then wait a bit before asking for removal from backports to
let actual users get an updated version. It seems far better than just
leaving some people with vulnerable versions on their systems.
-- 
"Not Hercules could have knock'd out his brains, for he had none."
-- Shakespeare


signature.asc
Description: PGP signature

Bug#843853: Uninstallabel due to dependency on libgstreamer-plugins-bad1.0-0 (< 1.8.4)

[Vincent Bernat]

Package: gstreamer1.0-vaapi
Version: 1.8.3-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

gstreamer-vaapi is currently uninstallable (in unstable only) due to
its dependency on libgstreamer-plugins-bad1.0-0.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQIvBAEBCAAZBQJYJDS4EhxiZXJuYXRAZGViaWFuLm9yZwAKCRCVpC/oNTUl+aWB
D/wI7YyskAtgE9TT4hz/nQv1n86qCfZDhWehl0nz+mMTfOGG9vi01hmkYBL1eTz7
o5ElIiJaVPZgUFoUyiOPM3+inytAplePM94Mj/VD1ps1CP/l9kM/cLhC8Nskcsah
d0uQhRIpS0NHOpxyYo9fMGeGTCjAxWkZVm5JPG23VKTXIsdmfX3qiC6KzAUr6p+t
lNhcO5WvEpFCIdHZbspmIBXuj1s3B6m51PrUpxI6WHQKIJUgDIBhDfpMX/WfROOM
bUutKd+ap+xmfZHwigTe7EKKZxWU6m8Q8/4zwzqN7Xc3/JVjsft1tO71AY2WEp7q
9ONzZJWCXVditU5tCAmLxt+U0OEMhRy9BvuzXck7D1F/ChqA17cgPuX0uxxTMTO9
lxED53tAgraHnBqlK6myLxG/wAwF/ddEIvctHrxKF6uPX8lSaB7oD3G8yc9tF/iR
PfPcRaoFIiBKn4jup6ggv/nabPvVF3eioKtBq/LE+ViOMbFpQyvRmRiVfvEDxchA
GWKiuY7e1K0RU6/GuE8HV6qq5cIhqlaVG66wG2UdBGMOsFwzH+e4Srmx3yB5XDQ6
P6Dgy7os4/ID2bCdjS9TP1JsmMDGevh9KsUV/0L7Yxg1bJYjmCgyL7PkGl/B1scI
JgNExSQ8pXLR/qp58TtojtWH7kjsBTOFf8BDm0ERFlwR0A==
=M1yr
-END PGP SIGNATURE-

Bug#843644: Root cause

[Vincent Bernat]

 ❦  9 novembre 2016 11:32 +0100, Vincent Bernat <ber...@debian.org> :

>> Sandro: I don't think I can fix this properly from the cryptography
>> side since these constants are actually gone from libssl, but since
>> they only need to _exist_ and not actually _work_ in order to import
>> the "OpenSSL" module, I could try to implement a workaround that
>> defines them to some nonsense value if you think that would be better
>> than waiting on an updated python-openssl.
>
> Oh, please, don't do that. If there things using those constants, this
> could have advert effects!

FYI, just updating the package to 16.2.0 works for me.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#843644: Root cause

[Vincent Bernat]

 ❦  8 novembre 2016 18:35 GMT, Tristan Seligmann  :

> Sandro: I don't think I can fix this properly from the cryptography
> side since these constants are actually gone from libssl, but since
> they only need to _exist_ and not actually _work_ in order to import
> the "OpenSSL" module, I could try to implement a workaround that
> defines them to some nonsense value if you think that would be better
> than waiting on an updated python-openssl.

Oh, please, don't do that. If there things using those constants, this
could have advert effects!
-- 
As flies to wanton boys are we to the gods; they kill us for their sport.
-- Shakespeare, "King Lear"


signature.asc
Description: PGP signature

Bug#842979: Missing dependency on python-jtextfsm

[Vincent Bernat]

Package: python-napalm-base
Version: 0.18.0-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have missed this dependency (which replaces gtextfsm). Will package it 
shortly.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-napalm-base depends on:
ii  python-jinja2   2.8-1
ii  python-netaddr  0.7.18-2
pn  python:any  

python-napalm-base recommends no packages.

python-napalm-base suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIvBAEBCAAZBQJYGi+6EhxiZXJuYXRAZGViaWFuLm9yZwAKCRCVpC/oNTUl+b1w
EACT/8g5O7xshyAXy4k17IgXUo465S1McyOci2AXn3LbjRst5iYYz+Cb+SDhRmyB
dpz62Qfy3iENfp/amjcvuY0UbqWoAhnfVamjh1RRaHR37MFAA6cWzeplZPg+0Etg
YhdFMjHgSfXbRKQG1wLqYlFUNHBt0B63KSYZwX3F2SL129pZStpFEMM26xk8IzVE
Sqc0fIbDgdODFI5X/3n9xq9ns/FAJ9mrEKT2KefjKQCsXA7KjSW9MvWhQ4QYqMxa
n93bea6kwjKpMJm428TasksZggwoNhi8LComIQ2xljoT0Ur2rCHOUgIN9M2AeE++
17GdEIucjl9aohA6waodJ724CxjXEVVJnpJhmsoKQOMp1xl/x1XwiqWgMa5xLqz5
eXWdeVpejAlmP4sE+ZH5dfdqZ9hh8AE/MIdBMlnTsFg6XOI8wMM6KM9/qUUoezsx
ou3kwHyXwe+6NIn+vGgegjRu4NHvGxfgobFVbt8LIn0Gr3IbL9f97BIs9tfvt2Df
sgd0wnXFA4cvW+wKXjICVXgarKpW7fVgkoXhunH1bL6svbS1Gy2ovVcesvhv/B+j
BP/m9YuHBfrB7euBBY9XsPDQRLwIvMT6GkVlEBLh4ff5BuNlMl6mvo1x9HGFaYxc
0LlGtimwIUWy8fCsFtDbNOfZB7oSAFy0Y+EnnjCrUgCYmg==
=Gy9A
-END PGP SIGNATURE-

Bug#835241: marked as pending

[Vincent Bernat]

tag 835241 pending
thanks

Hello,

Bug #835241 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/pytest-mock.git;a=commitdiff;h=f3e6ab3

---
commit f3e6ab3d77a427bf97e5fdcf11fdd1aa525439e9
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sat Sep 3 12:32:16 2016 +0200

New upstream release

diff --git a/debian/changelog b/debian/changelog
index 9e742d0..b4f4f0d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pytest-mock (1.2-1) UNRELEASED; urgency=medium
+
+  * New upstream release.
++  Still no support of pytest 3. Not closes: #835241.
+
+ -- Vincent Bernat <ber...@debian.org>  Sat, 03 Sep 2016 12:31:59 +0200
+
 pytest-mock (1.1-1) unstable; urgency=medium
 
   [ Vincent Bernat ]

Bug#835241: bug 835241 is forwarded to https://github.com/pytest-dev/pytest-mock/issues/61

[Vincent Bernat]

 ❦ 11 octobre 2016 11:10 CEST, Petter Reinholdtsen  :

> The upstream fix for this is available as
> https://github.com/pytest-dev/pytest-mock/pull/36 >.
>
> There do not seem to be a new upstream release with the
> fix included.

I was expecting a new release soon, but since Debian freezes soon, I'll
make an upload with the patch shortly.
-- 
Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#839393: exabgp: FTBFS sometimes (failing tests)

[Vincent Bernat]

 ❦  1 octobre 2016 14:17 CEST, Santiago Vila  :

> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
>
> 
> [...]
>
> debian/rules:11: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 1
> make[1]: Leaving directory '/<>'
> debian/rules:4: recipe for target 'build-indep' failed
> make: *** [build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
> 
>
> It does not always fail, but it does not always build ok, and this
> failure is an example. Sorry, I don't know how to reproduce the
> failure, but the build log (which is attached) gives a very good hint
> about why this can happen, as it contains a line like this:
>
> failed, a test is taking more than the allocated time
>
> An autobuilder does not necessarily have a constant and predictable
> CPU speed. The same machine could be doing other things in parallel.
> Therefore, any test which tries to check that things are ok by
> measuring execution times should better be disabled.

Conversation tests may randomly deadlock. It happens to me from time to
time but I didn't find way. I'll disable them.
-- 
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#830609: marked as pending

[Vincent Bernat]

tag 830609 pending
thanks

Hello,

Bug #830609 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/python-structlog.git;a=commitdiff;h=f5a148c

---
commit f5a148c97a4d2b5f050f09970a6258f0a0b8b3ff
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sat Sep 17 09:48:28 2016 +0200

d/rules: prevent network access by defining https_proxy

diff --git a/debian/changelog b/debian/changelog
index 9ed029b..5954e5b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,8 +3,9 @@ python-structlog (16.1.0-1) UNRELEASED; urgency=medium
   * New upstream release.
   * d/control: add myself to uploaders.
   * d/control: bump Standards-Version.
+  * d/rules: prevent network access by defining https_proxy. Closes: #830609.
 
- -- Vincent Bernat <ber...@debian.org>  Sat, 17 Sep 2016 09:41:11 +0200
+ -- Vincent Bernat <ber...@debian.org>  Sat, 17 Sep 2016 09:48:23 +0200
 
 python-structlog (16.0.0-1) unstable; urgency=medium
 

Bug#837025: marked as pending

[Vincent Bernat]

tag 837025 pending
thanks

Hello,

Bug #837025 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/pyasn1.git;a=commitdiff;h=cb45779

---
commit cb45779f6fb7ffdd0b3c6d7cab4012a023b635a9
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sat Sep 10 14:23:55 2016 +0200

Fix FTBFS due to a target having both ":" and "::" variants

This is likely due to a change in cdbs.

diff --git a/debian/changelog b/debian/changelog
index 643ebad..cef484f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,13 @@
-pyasn1 (0.1.9-2) UNRELEASED; urgency=medium
+pyasn1 (0.1.9-2) unstable; urgency=medium
 
+  [ Ondřej Nový ]
   * Fixed VCS URL (https)
 
- -- Ondřej Nový <n...@ondrej.org>  Tue, 29 Mar 2016 21:47:53 +0200
+  [ Vincent Bernat ]
+  * Fix FTBFS due to a target having both ":" and "::" variants.
+Closes: #837025.
+
+ -- Vincent Bernat <ber...@debian.org>  Sat, 10 Sep 2016 14:22:55 +0200
 
 pyasn1 (0.1.9-1) unstable; urgency=medium
 

Bug#814696: marked as pending

[Vincent Bernat]

tag 814696 pending
thanks

Hello,

Bug #814696 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/python-netaddr.git;a=commitdiff;h=fbe03c7

---
commit fbe03c704a5516d314935eae15be37088ab05430
Author: Vincent Bernat <vinc...@bernat.im>
Date:   Sat Sep 10 14:08:26 2016 +0200

Replace manual use of localedef by localehelper package

diff --git a/debian/changelog b/debian/changelog
index b2233c9..641d3ae 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,13 @@
 python-netaddr (0.7.18-2) UNRELEASED; urgency=medium
 
+  [ Ondřej Nový ]
   * Fixed VCS URL (https)
 
- -- Ondřej Nový <n...@ondrej.org>  Tue, 29 Mar 2016 22:12:17 +0200
+  [ Vincent Bernat ]
+  * Replace manual use of localedef by localehelper package. Should also
+closes: #814696.
+
+ -- Vincent Bernat <ber...@debian.org>  Sat, 10 Sep 2016 14:07:34 +0200
 
 python-netaddr (0.7.18-1) unstable; urgency=medium
 

Bug#830568: python-asyncssh: accesses the internet during build

[Vincent Bernat]

 ❦  4 septembre 2016 10:13 CEST, Chris Lamb  :

>> > Oh! I thought we were discussing whether it was a bug at all […] not the
>> > severity of the bug itself.
>>
>> This is why I think the issue should be discussed more broadly.
>
> To be clear, I was referring to that it was regrettable — in general — that
> you would ignore any bug submitted against any package of yours.

I would ignore that bug as I don't thing fixing it would achieve
anything valuable. I would not of course ignore any non-serious bug. I
have always fixed the reproducibility issues for example.
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#830568: python-asyncssh: accesses the internet during build

[Vincent Bernat]

 ❦  3 septembre 2016 23:37 CEST, Chris Lamb  :

>> If your bug was wishlist, I would just ignore it. It is severity serious
>> and I have to handle it. Maybe it is legitimate. Maybe not.
>
> Oh! I thought we were discussing whether it was a bug at all — hence the
> time you spent addressing whether privacy leaking is valuable — not the
> severity of the bug itself.
>
> As I probably dislike "bug severity wars" even more than Debian Policy
> wording debates, free to change it to whatever you feel is appropriate… :)
>
> Howevever, it does feel regrettable you readily admit you might completely
> ignore a bug.

This is why I think the issue should be discussed more broadly. I am
pretty sure many people will agree with you, but I am also pretty sure
some will agree with me. I can start the thread on debian-devel@ if you
don't mind.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#830568: python-asyncssh: accesses the internet during build

[Vincent Bernat]

 ❦  4 septembre 2016 01:03 CEST, Santiago Vila  :

>> [...] information leak [...]
>
> This is not just a privacy issue but also a reproducibility issue.
>
> It is bad that a package leaks information to the external world,
> but it is even worse, I would say, that information from the outside
> world is being used in any way by the package during the build.
>
> If we allow packages to communicate with the external world during the
> build, then a sentence like "this is the source for this binary package"
> becomes completely meaningless, as the source package stops being all
> you need to build the package.

In this case, there is no reproducibility issue. The worst that can
happen is the unit tests to fail if you have a host called "fail" on
your network. Something that is plausible but should stay quite rare.

I am totally OK with the general rule that a package must build without
having access to the network. This is the case with python-asyncssh. It
builds fine without access to the network.
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#830568: python-asyncssh: accesses the internet during build

[Vincent Bernat]

 ❦  3 septembre 2016 21:22 CEST, Chris Lamb  :

>> The policy says "may not". I am not a native speaker, but for me, this
>> is not like "must not". Since you are a native speaker, I think you know
>> better: is it optional or not?
>
> May I suggest an alternative approach…? We have two cases here:
>
>  a) Debian Policy states it is a bug in python-asyncssh.
>
>  b) Debian Policy does not state it is a bug python-asyncssh.
>
> In both cases it would be perfectly legitimate to continue discussing
> whether it *should* be a bug in python-asyncssh.
>
> In other words, tedious haggling over the wording and intention of a
> document neither of us wrote is unproductive to the goal of improving
> Debian. So, let's just skip all of that.

Well, what you think is productive/improvement, I think this is a waste
of time. Let's say I disable the test.  Next release, I will have to
rebase the patch. Next release, upstream will have added a test, I don't
notice it, you'll file another bug, another upload to fix that. Upstream
may notice that I am crippling its test suite. I'll have to
explain. They may or may not understand. I don't want to do all that.

The time I can spend on Debian is limited. If your bug was wishlist, I
would just ignore it. It is severity serious and I have to handle
it. Maybe it is legitimate. Maybe not. That's why I would have feeled
more comfortable if this was discussed on debian-devel@.
-- 
There is a great discovery still to be made in Literature: that of
paying literary men by the quantity they do NOT write.


signature.asc
Description: PGP signature

Bug#830568: python-asyncssh: accesses the internet during build

[Vincent Bernat]

 ❦  3 septembre 2016 15:46 CEST, Chris Lamb  :

>> Was this MBF discussed somewhere?
>
> I don't consider it to be a MBF — I haven't been systematically working
> my way through the archive and I've really only filed a handful of bugs;
> mostly quasi-duplicates due to Sphinx stuff (which is arguably more a
> QA thing than to do with violation of any policy).

Well, that's a lot of bugs, so it should have been discussed. But
whatever, I was just asking to not repeat something already discussed.

The policy says "may not". I am not a native speaker, but for me, this
is not like "must not". Since you are a native speaker, I think you know
better: is it optional or not?

While I understand why the policy says no network access, in the case of
python-asyncssh, the network access is to access a non-existing host
From a DNS point of view. It's something that would be far more complex
to setup a DNS in the chroot and LD_PRELOAD something to ensure it is
used in place of the regular resolver part. Not running the test would
just reduce the test coverage. If upstream wrote this test, I suppose it
is useful. If we run tests as part of our build, I suppose this is also
useful. And there is no positive side. Nowadays, we have little risk to
have a package that access the network in a meaningful way during the
build: both pbuilder and sbuild are running in a separate network
namespace and I believe many official builders also have restricted
access. People which are really concerned about information leak during
build should do the same.

Of course, another solution would be to use 127.0.0.1:discard which
would be almost equivalent since the goal of the test seems to be
broader than just DNS failures.

What do you think?
-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#830568: python-asyncssh: accesses the internet during build

[Vincent Bernat]

 ❦  9 juillet 2016 15:26 CEST, Chris Lamb  :

> Source: python-asyncssh
> Version: 1.5.6-1
> Severity: serious
> Justification: Policy 4.9
> User: la...@debian.org
> Usertags: network-access
>
> Dear Maintainer,
>
> Whilst python-asyncssh builds successfully on unstable/amd64, according to
> Debian Policy 4.9 packages may not attempt network access during
> a build.
>
>   00:00:00.00 IP f8fc55487205.58764 > dnscache.uct.ac.za.domain: 33265+ 
> A? fail.uct.ac.za. (32)
>   00:00:00.46 IP f8fc55487205.58764 > dnscache.uct.ac.za.domain: 12531+ 
> ? fail.uct.ac.za. (32)
>   00:00:00.001320 IP dnscache.uct.ac.za.domain > f8fc55487205.58764: 33265 
> NXDomain* 0/1/0 (86)
>   00:00:00.001523 IP dnscache.uct.ac.za.domain > f8fc55487205.58764: 12531 
> NXDomain* 0/1/0 (86)
>   00:00:00.001604 IP f8fc55487205.47627 > dnscache.uct.ac.za.domain: 56301+ 
> A? fail.chris-lamb.co.uk. (39)
>   00:00:00.001620 IP f8fc55487205.47627 > dnscache.uct.ac.za.domain: 35318+ 
> ? fail.chris-lamb.co.uk. (39)
>
>   [..]
>
> The full build log (including tcpdump output) is attached.

Hey!

Was this MBF discussed somewhere?

I am dubious about this bug and think it should have been discussed on
debian-devel@ (but I may have missed the thread).
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#834367: systemctl daemon-reexec (as run on systemd upgrade) causes all keystrokes to go to text console in addition to X (including passwords)

[Vincent Bernat]

 ❦ 15 août 2016 00:53 CEST, Josh Triplett  :

> [Severity and tag due to the likely possibility of exposing user
> passwords this way.  If this occurs with the version in jessie as well,
> it'll require a security update.]

I think this is fairly recent. I stumbled upon your bug report while
searching why Alt + "left arrow" switched to another VT. It started to
happen to me today. Therefore, I think this only happens with 231-2 but
not with 231-1 (assuming this is the same cause).
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#832118: ruby-puppet-forge: FTBFS: psych.rb:471:in `initialize': No such file or directory @ rb_sysopen - /usr/lib/ruby/locales/config.yaml (Errno::ENOENT)

[Vincent Bernat]

 ❦ 22 juillet 2016 16:11 CEST, Chris Lamb  :

> ruby-puppet-forge fails to build from source in unstable/amd64:

It also fails to run. This seems due to the introduction of
ruby-gettext-setup. The config.yaml file from locales/config.yaml should
be installed in /usr/lib/ruby/locales but it is application
specific. So, I suppose that ruby-puppet-forge should be patched as well
to search inside its own locales directory.

The problem doesn't seem limited to
ruby-puppet-forge. ruby-semantic-puppet has the same problem. Commenting
the Gettext.initialize() call fix the problem for me.
-- 
There is an old time toast which is golden for its beauty.
"When you ascend the hill of prosperity may you not meet a friend."
-- Mark Twain


signature.asc
Description: PGP signature