Bug#912196: abgate FTCBFS: multiple reasons

[Helmut Grohne]

Source: abgate
Version: 1.1.9-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

abgate fails to cross build from source for multiple reasons:

 * The upstream Makefile hard codes build architecture tools such as g++
   or pkg-config.
 * The upstream Makefile directly runs qmake, which lacks cross flags as
   well.

The attached patch fixes that. In part, the Makefile is fixed. For qt,
it is simply sidestepped. After doing so, abgate cross builds
successfully. Please consider applying it.

Helmut
diff --minimal -Nru abgate-1.1.9/debian/changelog abgate-1.1.9/debian/changelog
--- abgate-1.1.9/debian/changelog   2017-11-01 12:38:10.0 +0100
+++ abgate-1.1.9/debian/changelog   2018-10-29 06:15:39.0 +0100
@@ -1,3 +1,12 @@
+abgate (1.1.9-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Build abGateQt directly via dh_auto_* before the Makefile can do it.
++ cross.patch: Honour cross tools.
+
+ -- Helmut Grohne   Mon, 29 Oct 2018 06:15:39 +0100
+
 abgate (1.1.9-1) unstable; urgency=medium
 
   * New upstream version 1.1.9
diff --minimal -Nru abgate-1.1.9/debian/patches/cross.patch 
abgate-1.1.9/debian/patches/cross.patch
--- abgate-1.1.9/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ abgate-1.1.9/debian/patches/cross.patch 2018-10-29 06:15:35.0 
+0100
@@ -0,0 +1,23 @@
+--- abgate-1.1.9.orig/Makefile
 abgate-1.1.9/Makefile
+@@ -3,6 +3,7 @@
+ BUNDLE = abGate.lv2
+ PREFIX = /usr
+ INSTALL_DIR = $(DESTDIR)$(PREFIX)/lib/lv2
++PKG_CONFIG ?= pkg-config
+ 
+ $(BUNDLE): manifest.ttl gate.ttl gate.so gate_gui.so bypass_on.png 
bypass_off.png knob.png background.png abGateQt/libabGateQt.so
+   rm -rf $(BUNDLE)
+@@ -13,10 +14,10 @@
+   cd abGateQt; qmake; make
+ 
+ gate.so: gate.cpp
+-  g++ $(LDFLAGS) $(CPPFLAGS) $(CFLAGS) -g -O3 -shared -fPIC -DPIC 
-Wl,--as-needed gate.cpp `pkg-config --cflags --libs lv2` -o gate.so
++  $(CXX) $(LDFLAGS) $(CPPFLAGS) $(CFLAGS) -g -O3 -shared -fPIC -DPIC 
-Wl,--as-needed gate.cpp `$(PKG_CONFIG) --cflags --libs lv2` -o gate.so
+ 
+ gate_gui.so: gate_gui.cpp main_window.cpp main_window.h knob.cpp knob.h 
toggle.cpp toggle.h preset_widget.cpp preset_widget.h presets.cpp presets.h 
preset.cpp preset.h gate_const.h plugin_configuration.h
+-  g++ $(LDFLAGS) $(CPPFLAGS) $(CFLAGS) -g -O3 -shared -fPIC -DPIC 
-Wl,--as-needed gate_gui.cpp main_window.cpp knob.cpp toggle.cpp 
preset_widget.cpp presets.cpp preset.cpp `pkg-config --cflags gtkmm-2.4 --libs 
lv2 gthread-2.0` -o gate_gui.so
++  $(CXX) $(LDFLAGS) $(CPPFLAGS) $(CFLAGS) -g -O3 -shared -fPIC -DPIC 
-Wl,--as-needed gate_gui.cpp main_window.cpp knob.cpp toggle.cpp 
preset_widget.cpp presets.cpp preset.cpp `$(PKG_CONFIG) --cflags gtkmm-2.4 
--libs lv2 gthread-2.0` -o gate_gui.so
+ 
+ all: $(BUNDLE)
+ 
diff --minimal -Nru abgate-1.1.9/debian/patches/series 
abgate-1.1.9/debian/patches/series
--- abgate-1.1.9/debian/patches/series  2017-10-11 16:19:02.0 +0200
+++ abgate-1.1.9/debian/patches/series  2018-10-29 06:14:55.0 +0100
@@ -1 +1,2 @@
 0002-flags.patch
+cross.patch
diff --minimal -Nru abgate-1.1.9/debian/rules abgate-1.1.9/debian/rules
--- abgate-1.1.9/debian/rules   2017-11-01 12:25:19.0 +0100
+++ abgate-1.1.9/debian/rules   2018-10-29 06:15:39.0 +0100
@@ -8,3 +8,10 @@
 
 %:
dh $@
+
+override_dh_auto_configure:
+   dh_auto_configure --sourcedirectory=abGateQt
+
+override_dh_auto_build:
+   dh_auto_build --sourcedirectory=abGateQt
+   dh_auto_build

Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3

[Daniel Kahn Gillmor]

On Sun 2018-10-28 21:58:55 +, Adam D. Barratt wrote:
> I don't have any objections if you want to upload already, but it won't
> get accepted into p-u from stable-new until it's had the d-i ack.

OK, it's uploaded now, in stable-new, waiting for the d-i ack.

thanks for your work on the stable release, Adam.

--dkg

Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3

[Daniel Kahn Gillmor]

On Sun 2018-10-28 10:58:17 -0400, Daniel Kahn Gillmor wrote:
> On Sat 2018-10-27 16:47:27 +0100, Adam D. Barratt wrote:
>> Are you planning on handling the enigmail upload as well? I can't see
>> an open p-u bug for it so, given the timings, would suggest that start
>> getting progressed ASAP so that we can make sure that it makes the
>> point release.
>
> I didn't want to propose the enigmail update until i knew that this
> change would go through.  I'll do that today.  Thanks!

The proposed upgrade to enigmail is #912194.  thanks!

--dkg


signature.asc
Description: PGP signature

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[jim_p]

Package: openssl
Version: 1.1.1-1
Followup-For: Bug #912087

Now that by bug report has been switched to the openssl package, I would like
to add that after seeing the above post about entropy, I installed haveged and
now openssh-server starts in a fraction of the mentioned time.

On top of that, lightdm also starts faster (= it gets me to the login prompt
quicker) than what it used to a few days ago.
I was about to open a new bug report for it, but I do not know if it is related
to this issue.



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

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

Versions of packages openssl depends on:
ii  libc6  2.27-6
ii  libssl1.1  1.1.1-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20170717

-- no debconf information

Bug#294919: closed by Ondřej Surý (There are no -xpm/-noxpm packages nor gd 2.0.x in (old)stable)

[Petter Reinholdtsen]

Control: reopen -1
Control: reassign -1 libgd-dev
Control: found -1 2.2.5-4
Control: found -1 2.1.0-5
Control: found -1 2.0.33-1

[Ondřej Surý]
> Just cleaning up old bugreports…
>
> If you believe that the bug is still present in stable version of
> Debian, please update the bug accordingly and reopen it.

Blindly closing bugs that have available all the information required to
still reproduce it seem like bad form to me.

I tested the example code and can confirm that the problem is still
there.

-- 
Happy hacking
Petter Reinholdtsen

Bug#909638: pngcheck: build with USE_ZLIB

[Kevin Ryde]

I wrote:
>
> https://www.gutenberg.org/files/16713/16713-h/images/q248.png

This image file has been rectified at Gutenberg (so passing pngcheck in
all cases).  The previous offending copy attached below to test or try.

Bug#912195: mark bf-utf-source Multi-Arch: foreign

[Helmut Grohne]

Package: bf-utf-source
Version: 0.08
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:debian-install src:bterm-unifont

The affected packages fail to cross build from source, because their
dependency on bf-utf-source is unsatisfiable. In general, Architecture:
all packages can never satisfy cross Build-Depends unless marked
Multi-Arch: foreign. In this case, such a marking is correct, because
bf-utf-source entirely lacks dependencies and maintainer scripts. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru bf-utf-0.08/debian/changelog 
bf-utf-0.08+nmu1/debian/changelog
--- bf-utf-0.08/debian/changelog2018-06-12 20:49:46.0 +0200
+++ bf-utf-0.08+nmu1/debian/changelog   2018-10-29 06:05:37.0 +0100
@@ -1,3 +1,10 @@
+bf-utf (0.08+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark bf-utf-source Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Oct 2018 06:05:37 +0100
+
 bf-utf (0.08) unstable; urgency=medium
 
   * Update Vcs-* fields to salsa.debian.org
diff --minimal -Nru bf-utf-0.08/debian/control bf-utf-0.08+nmu1/debian/control
--- bf-utf-0.08/debian/control  2018-06-12 20:49:46.0 +0200
+++ bf-utf-0.08+nmu1/debian/control 2018-10-29 06:05:35.0 +0100
@@ -9,6 +9,7 @@
 
 Package: bf-utf-source
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: source for fonts needed to build Debian installers
  This package contains fonts needed to build the debian-installer and

Bug#893685: Segfault after higher number of connections

[Josue Abarca]

Sorry for the late reply.
Thanks for the additional details. I will look for the fix in upstream
commit history, and will work to add the version in debian unstable to
the backports for stable.

Regards,

Josue

Bug#890468: lintian: source-is-missing false positive when d/missing-sources/foo has no known suffix

[Chris Lamb]

tags 890468 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/3cebb74533aa4d45e150b6bdfc60282ece015ccc

  checks/cruft.pm   |  6 ++
  debian/changelog  |  4 
  .../debian/debian/control.in  | 15 +++
  .../debian/debian/source/format   |  1 +
  t/tests/cruft-source-is-missing-unrel/desc| 10 ++
  t/tests/cruft-source-is-missing-unrel/orig/main.c |  8 
  t/tests/cruft-source-is-missing-unrel/pre_build   | 11 +++
  t/tests/cruft-source-is-missing-unrel/pre_upstream| 11 +++
  t/tests/cruft-source-is-missing-unrel/tags|  2 ++
  9 files changed, 68 insertions(+)


Regards,

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

Bug#912193: samba: Ignores UNIX groups

[Paul Szabo]

Package: samba
Version: 2:4.5.12+dfsg-2+deb9u3
Severity: normal
Tags: patch

Dear Maintainer,

Samba ignores the UNIX secondary groups of the UNIX user; then file
permissions (based on those secondary groups) fail. (Instead, Samba
adds the "Windows groups" that the "Windows user" belongs to, but
that is probably useless or wrong for file accesses.)

The following patch seems to solve the issue.

(Seems to me that Samba4.9 suffers from the same issue.)

Cheers, Paul

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


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

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

Versions of packages samba depends on:
ii  adduser  3.115
ii  dpkg 1.18.25
ii  init-system-helpers  1.48
ii  libbsd0  0.8.3-1
ii  libc62.24-11+deb9u3
ii  libldb1  2:1.1.27-1+b1
ii  libpam-modules   1.1.8-3.6
ii  libpam-runtime   1.1.8-3.6
ii  libpopt0 1.16-10+b2
ii  libpython2.7 2.7.13-2+deb9u3
ii  libtalloc2   2.1.8-1
ii  libtdb1  1.3.11-2
ii  libtevent0   0.9.31-1
ii  libwbclient0 2:4.5.12+dfsg-2+deb9u3
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3+deb9u1
ii  python   2.7.13-2
ii  python-dnspython 1.15.0-1
ii  python-samba 2:4.5.12+dfsg-2+deb9u3
ii  python2.72.7.13-2+deb9u3
ii  samba-common 2:4.5.12+dfsg-2+deb9u3
ii  samba-common-bin 2:4.5.12+dfsg-2+deb9u3
ii  samba-libs   2:4.5.12+dfsg-2+deb9u3
ii  tdb-tools1.3.11-2
ii  update-inetd 4.44

Versions of packages samba recommends:
ii  attr1:2.4.47-2+b2
ii  logrotate   3.11.0-0.1
ii  samba-dsdb-modules  2:4.5.12+dfsg-2+deb9u3
ii  samba-vfs-modules   2:4.5.12+dfsg-2+deb9u3

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p10+dfsg-3+deb9u2
pn  smbldap-tools  
pn  ufw
ii  winbind2:4.5.12+dfsg-2+deb9u3

-- no debconf information
--- ./samba-4.5.12/source3/auth/auth_util.c.orig2016-12-09 
01:09:52.0 +1100
+++ ./samba-4.5.12/source3/auth/auth_util.c 2018-10-29 08:53:21.216263177 
+1100
@@ -531,6 +531,7 @@
/* Just copy the token, it has already been finalised
 * (nasty hack to support a cached guest/system session_info
 */
+   /* PSz - I have not noticed that this copy would succeed... */
 
session_info->security_token = dup_nt_token(session_info, 
server_info->security_token);
if (!session_info->security_token) {
@@ -551,6 +552,16 @@
return NT_STATUS_OK;
}
 
+/*
+ * DEBUG(10, ("PSz - as things were after copy of 
server_info->security_token\n"));
+ * security_token_debug(DBGC_AUTH, 10, session_info->security_token);
+ * debug_unix_user_token(DBGC_AUTH, 10,
+ *   session_info->unix_token->uid,
+ *   session_info->unix_token->gid,
+ *   session_info->unix_token->ngroups,
+ *   session_info->unix_token->groups);
+ */
+
/*
 * If winbind is not around, we can not make much use of the SIDs the
 * domain controller provided us with. Likewise if the user name was
@@ -578,47 +589,93 @@
  
_info->security_token);
}
 
+/*
+ * DEBUG(10, ("PSz - as things were after 
create_token_from_username/create_local_nt_token_from_info3\n"));
+ * security_token_debug(DBGC_AUTH, 10, session_info->security_token);
+ * debug_unix_user_token(DBGC_AUTH, 10,
+ *   session_info->unix_token->uid,
+ *   session_info->unix_token->gid,
+ *   session_info->unix_token->ngroups,
+ *   session_info->unix_token->groups);
+ */
+
if (!NT_STATUS_IS_OK(status)) {
return status;
}
 
/* Convert the SIDs to gids. */
 
+   /*
+* PSz - Why zero them here? May have initialized them already,
+* in copy of security_token. Was that wrong (wasted)?
+*/
session_info->unix_token->ngroups = 0;
session_info->unix_token->groups = NULL;
 
-   t = session_info->security_token;
-
-   ids = talloc_array(talloc_tos(), struct unixid,
-  t->num_sids);
-   if (ids == NULL) {
-   return NT_STATUS_NO_MEMORY;
-   }
-
-   if (!sids_to_unixids(t->sids, 

Bug#907372: needrestart: complains about microcode updates on systems with microcode for multiple CPUs in initramfs

[Paul Wise]

On Sun, 2018-10-28 at 19:57 +0100, Thomas Liske wrote:

> ... please provide the output of the following commands:
> 
> cat /sys/devices/system/cpu/cpu0/microcode/version
> sh -x /usr/lib/needrestart/iucode-scan-versions

$ sudo cat /sys/devices/system/cpu/cpu0/microcode/version
0xa
$ sudo sh -x /usr/lib/needrestart/iucode-scan-versions
+ [  = 1 ]
+ iucode_tool+  --scan-system
grep -oE [^[:space:]]+$
+ filter=0x000106e5
+ [ -r /sys/devices/system/cpu/cpu0/microcode/processor_flags ]
+ cat /sys/devices/system/cpu/cpu0/microcode/processor_flags
+ filter=-s 0x000106e5,0x2
+ type bsdtar
+ IUCODE_TOOL_EXTRA_OPTIONS=
+ test -r /etc/default/intel-microcode
+ . /etc/default/intel-microcode
+ IUCODE_TOOL_SCANCPUS=no
+ IUCODE_TOOL_EXTRA_OPTIONS=-s 0x000106e5,0x13 -s 0x00020655,0x92
+ test  = no
+ [ -r /usr/share/misc/intel-microcode* ]
+ exec iucode_tool -l -s 0x000106e5,0x2 -s 0x000106e5,0x13 -s 0x00020655,0x92 
-tb /lib/firmware/intel-ucode
microcode bundle 1: /lib/firmware/intel-ucode/06-3f-02.initramfs
microcode bundle 2: /lib/firmware/intel-ucode/06-17-06
microcode bundle 3: /lib/firmware/intel-ucode/06-3e-07
microcode bundle 4: /lib/firmware/intel-ucode/06-56-02.initramfs
microcode bundle 5: /lib/firmware/intel-ucode/06-25-05
microcode bundle 6: /lib/firmware/intel-ucode/06-16-01
microcode bundle 7: /lib/firmware/intel-ucode/06-2d-06
microcode bundle 8: /lib/firmware/intel-ucode/06-5c-0a
microcode bundle 9: /lib/firmware/intel-ucode/06-4e-03
microcode bundle 10: /lib/firmware/intel-ucode/06-8e-0a
microcode bundle 11: /lib/firmware/intel-ucode/06-9e-0a
microcode bundle 12: /lib/firmware/intel-ucode/06-55-04
microcode bundle 13: /lib/firmware/intel-ucode/06-1a-05
microcode bundle 14: /lib/firmware/intel-ucode/06-55-03
microcode bundle 15: /lib/firmware/intel-ucode/0f-06-05
microcode bundle 16: /lib/firmware/intel-ucode/06-5c-02
microcode bundle 17: /lib/firmware/intel-ucode/06-3d-04.initramfs
microcode bundle 18: /lib/firmware/intel-ucode/06-1e-05
microcode bundle 19: /lib/firmware/intel-ucode/06-5c-09
microcode bundle 20: /lib/firmware/intel-ucode/06-3c-03.initramfs
microcode bundle 21: /lib/firmware/intel-ucode/06-9e-0b
microcode bundle 22: /lib/firmware/intel-ucode/06-3a-09.initramfs
microcode bundle 23: /lib/firmware/intel-ucode/06-1c-0a
microcode bundle 24: /lib/firmware/intel-ucode/06-1d-01
microcode bundle 25: /lib/firmware/intel-ucode/0f-04-04
microcode bundle 26: /lib/firmware/intel-ucode/0f-06-04
microcode bundle 27: /lib/firmware/intel-ucode/0f-06-02
microcode bundle 28: /lib/firmware/intel-ucode/0f-04-0a
microcode bundle 29: /lib/firmware/intel-ucode/06-0f-07
microcode bundle 30: /lib/firmware/intel-ucode/06-0f-02
microcode bundle 31: /lib/firmware/intel-ucode/06-56-05
microcode bundle 32: /lib/firmware/intel-ucode/06-0f-0b
microcode bundle 33: /lib/firmware/intel-ucode/06-7a-01
microcode bundle 34: /lib/firmware/intel-ucode/06-2f-02
microcode bundle 35: /lib/firmware/intel-ucode/06-17-07
microcode bundle 36: /lib/firmware/intel-ucode/06-5f-01
microcode bundle 37: /lib/firmware/intel-ucode/06-17-0a
microcode bundle 38: /lib/firmware/intel-ucode/06-3e-04
microcode bundle 39: /lib/firmware/intel-ucode/0f-04-03
microcode bundle 40: /lib/firmware/intel-ucode/06-9e-09
microcode bundle 41: /lib/firmware/intel-ucode/0f-06-08
microcode bundle 42: /lib/firmware/intel-ucode/06-56-03
microcode bundle 43: /lib/firmware/intel-ucode/06-56-04
microcode bundle 44: /lib/firmware/intel-ucode/06-1a-04
microcode bundle 45: /lib/firmware/intel-ucode/06-3e-06
microcode bundle 46: /lib/firmware/intel-ucode/0f-04-01
microcode bundle 47: /lib/firmware/intel-ucode/0f-04-08
microcode bundle 48: /lib/firmware/intel-ucode/06-0f-0a
microcode bundle 49: /lib/firmware/intel-ucode/06-46-01.initramfs
microcode bundle 50: /lib/firmware/intel-ucode/06-2d-07
microcode bundle 51: /lib/firmware/intel-ucode/06-2e-06
microcode bundle 52: /lib/firmware/intel-ucode/0f-04-07
microcode bundle 53: /lib/firmware/intel-ucode/06-0f-06
microcode bundle 54: /lib/firmware/intel-ucode/06-8e-09
microcode bundle 55: /lib/firmware/intel-ucode/06-0f-0d
microcode bundle 56: /lib/firmware/intel-ucode/06-2a-07
microcode bundle 57: /lib/firmware/intel-ucode/06-25-02
microcode bundle 58: /lib/firmware/intel-ucode/0f-04-09
microcode bundle 59: /lib/firmware/intel-ucode/06-45-01.initramfs
microcode bundle 60: /lib/firmware/intel-ucode/06-47-01.initramfs
microcode bundle 61: /lib/firmware/intel-ucode/06-4f-01.initramfs
microcode bundle 62: /lib/firmware/intel-ucode/06-3f-04.initramfs
microcode bundle 63: /lib/firmware/intel-ucode/0f-03-04
microcode bundle 64: /lib/firmware/intel-ucode/06-5e-03
microcode bundle 65: /lib/firmware/intel-ucode/06-1c-02
selected microcodes:
  018/001: sig 0x000106e5, pf_mask 0x13, 2018-05-08, rev 0x000a, size 9216
  005/001: sig 0x00020655, pf_mask 0x92, 2018-04-23, rev 0x0007, size 4096

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#815497: Brauchen Sie einen dringenden Kredit?

[Northern Trust]

--
Schönen Tag.
Brauchen Sie einen dringenden Kredit?

Wir bieten Kredite an Unternehmen für Geschäftsausweitungen, 
Investitionen und Projekte an und stellen Privatkredite zu einem 
Zinssatz von 1,1% zur Verfügung. Und Sie können eine Genehmigung für 
Ihre Transaktion ohne Verzögerung erhalten, wenn Sie sich jetzt 
bewerben.


Für die Antragstellung reichen Sie unten Ihre Kreditanfrage ein und wir 
melden uns umgehend bei Ihnen.


Vollständiger Name:...
Land:...
Darlehensbetrag:...
Darlehensdauer:...
Darlehen Zweck:...
Telefonnummer:...

Wir erwarten Ihre schnelle Antwort.

Freundliche Grüße.

Hector Laurence.
Berater / Kundendienst

50 Bank St, Canary Wharf, London E14 5NT, UK

Bug#912152: radon: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> I've forwarded this upstream here:
> 
>   https://github.com/rubik/radon/pull/157

.. this has now been merged.


Regards,

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

Bug#912192: dvtm: Confusing current directory of editor, invoked by Mod-p

[Dmitry Bogatov]

Package: dvtm
Version: 0.15-3
Severity: wishlist
Tags: upstream

When editor is invoked by Mod-p, it inherits current directory of dvtm,
instead of shell in dvtm tab. Definitely, dvtm has no simple (POSIX-compatible)
means to track of currently active process in tab, but maybe it worth
add command to pipe interface allowing processes notify about their
current working directory?

Also, temporary directory seems to be created in current directory of
dvtm, instead of ${TMPDIR:-/tmp}.

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

Awesome -- thank you Tony!

On Sun, Oct 28, 2018 at 11:27 AM tony mancill  wrote:

> owner 911732 tmanc...@debian.org
> thanks
>
> Hi All,
>
> The backport to stretch-backports is trivial - I only have to downgrade
> debhelper from 11 to 10 to build against stretch - and so I plan to do
> the bpo upload once 0.14.0-2 hits testing.
>
> Cheers,
> tony
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#871717: xfce4-sensors-plugin: Newer version available / Memory leak

[Adam Bolte]

I'm hitting a rather significant memory leak too. My HDD started
trashing and my machine became incredibly slow. At this point I
noticed xfce4-sensors-plugin was using about 2Gb of RAM.

$ uptime
 11:15:14 up 51 days, 18:10,  1 user,  load average: 3.30, 3.91, 3.68

$ top
  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 2652 user  20   0 2343876 1.865g   4968 S   0.0  7.9  71:09.88 
xfce4-sensors-p

$ ps auxf
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root  1279  0.0  0.0 309732  1312 ?SLsl Sep07   0:00 
/usr/sbin/lightdm
root  1521 13.3  0.3 1407696 90544 tty7Rsl+ Sep07 9952:48  \_ 
/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp 
vt7 -novtswitch
root  1924  0.0  0.0 267788   624 ?Sl   Sep07   0:00  \_ lightdm 
--session-child 14 23
user  1988  0.0  0.0   4292 8 ?Ss   Sep07   0:00  |   \_ 
/bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
user  2375  0.0  0.0  11148   176 ?Ss   Sep07   0:32  |   \_ 
/usr/bin/ssh-agent /home/user/.xsession
user  2569  0.0  0.0 345872  6188 ?Sl   Sep07   6:15  |   \_ 
xfce4-session
user  2602  0.3  0.0 421048 16400 ?Sl   Sep07 295:09  |   
\_ xfwm4 --display :0.0 --sm-client-id 25f8d8283-7988-4b29-a508-3819f2dea688
user  2603  0.0  0.0 362164  5796 ?Sl   Sep07   0:00  |   
\_ Thunar --sm-client-id 24d5a28e0-b5f9-4268-96b7-ebb4742aec3d --daemon
user  2605  0.0  0.0 457208 19264 ?Sl   Sep07  17:22  |   
\_ xfce4-panel --display :0.0 --sm-client-id 2f7fea66a-cc58-4e2f-bf2c-8f1068a
user  2652  0.0  7.9 2343876 192 ? Sl   Sep07  71:09  |   | 
  \_ /usr/lib/x86_64-linux-gnu/xfce4/panel-plugins/xfce4-sensors-plugin  30 
16777254 xfce4-sensors-plugin Sensor plugin Show sensor values.

$ apt-cache policy xfce4-sensors-plugin
xfce4-sensors-plugin:
  Installed: 1.2.6-1+b1
  Candidate: 1.2.6-1+b1
  Version table:
 1.3.0-2 50
 50 http://ftp.debian.org/debian sid/main amd64 Packages
 *** 1.2.6-1+b1 500
500 http://ftp.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status


signature.asc
Description: PGP signature

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Colin Watson]

Control: reassign -1 openssl 1.1.1-1
Control: affects -1 openssh

On Mon, Oct 29, 2018 at 12:48:32AM +0100, Bernhard Übelacker wrote:
> Am 28.10.2018 um 19:23 schrieb Colin Watson:
> > Thanks for the investigation.  (Note also that the OpenSSH version in
> > question is the one that switched from OpenSSL 1.0 to 1.1, which was a
> > big change.)
> > 
> > There were some significant changes in this area in OpenSSL 1.1.1.
> > Would it be possible to try running OpenSSH with OpenSSL 1.1.0h to see
> > if that makes a difference?  Unfortunately this is a little complicated
> > as it will require doing a local build of the Debian OpenSSH source
> > package in order to reduce the dependency; let me know if you need help
> > with setting this up.
> 
> Hello Colin Watson,
> I built a local package OpenSSH 7.9p1-1 against OpenSSL 1.1.0h like
> described in the upper half of attached file.
> This shows an normal start of the ssh service and login is
> immediately after a restart possible,
> running on linux-image-4.18.0-2-amd64 4.18.10-2.
> 
> Because in another bug suggested to test the previous kernel
> with a similar issue with the login manager (that I cannot find right
> now), I reverted back to regular OpenSSH 7.9p1-1 with OpenSSL 1.1.1-1
> and it shows the same delay when runnging with kernel
> linux-image-4.17.0-3-amd64 4.17.17-1.
> 
> Just found the possibly somehow related bug #910504, that proposes
> the installation of rng-tools - but this just fails to start because
> of "Cannot find a hardware RNG device to use.", with OpenSSH 7.9p1-1
> with OpenSSL 1.1.1-1 at linux-image-4.18.0-2-amd64 4.18.10-2.

Thanks for testing; it does look as though this problem is mainly due to
the changes to the OpenSSL random generator in 1.1.1, and the appearance
of it being an OpenSSH regression was caused by OpenSSH switching to
OpenSSL 1.1.x at around the same time.

Reassigning to OpenSSL - could the OpenSSL maintainers please have a
look and advise what's best to do?  (See the start of the bug, reporting
a delay of more than one minute in system boot in some cases, mainly
waiting for sshd to start.)

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#908171: sssd: please package for stretch-backports

[Steven Jones]

Hi,


I have been trying to Make Debian Stretch work with Redhat [free]IPA server for 
a cross domain trust. I have RHEL7.5 clients, Ubuntu18LTS clients and 
Centos7.5 all fo which are using sssd 1.16.  Debian stretch has 1.15 and fails 
on a cross forest environment while the other 3 all work over 100,000's of ssh 
login tests.Adding 1.16.3 from unstable fixes this issue so eith add a 
backport or upgrade Stretch to sssd 1.16


regards

Steven Jones

B.Eng (Hons)

Technical Specialist - Linux RHCE

Victoria University ITS,

Level 8 Rankin Brown Building,

Wellington, NZ

6012

0064 4 463 6272

Bug#912191: stretch-pu: package serf/1.3.9-3+deb9u1

[James McCoy]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Serf's testsuite uses some pre-generated SSL certs, which have an expiry
of 3 years.  The timebomb has gone off, and serf is currently FTBFS
(#911714).  The pending upstream release now has a script which
generates the certs, so I've backported that and run it every build.

Since an upload was needed, I also included a NULL pointer dereference
fix (#893688).

The package has already been uploaded.

Cheers,
James

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

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

Bug#886178: An extra trailing slash is added to ZFS root pool and it's not bootable

[Colin Watson]

On Tue, Jan 02, 2018 at 10:15:09PM +0100, Fejes József wrote:
> I have my root filesystem on ZFS. I'm using a ZFS pool's root dataset
> (rpool) as opposed to a sub-dataset (eg. rpool/foo or rpool/foo/bar).
> 
> update-grub calls calls /etc/grub.d/10_linux which sets the root=ZFS=
> parameter for grub/initrd. In this case, it sets it as
> root=ZFS=rpool/. Note the trailing slash. This is invalid and makes
> the system unbootable.
> 
> I already filed this bug at https://savannah.gnu.org/bugs/?52746 . But
> that bugtracker looks completely abandoned for months. I'm pretty sure
> it only needs a small fix to remove extra trailing slashes.

I think this patch would be sufficient (since in non-root-dataset cases
$bootfs has no trailing slash).  Could you test this?

diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index 61ebd7dc7..4532266be 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -73,7 +73,7 @@ case x"$GRUB_FS" in
 xzfs)
rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 
2>/dev/null || true`
bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
-   LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
+   LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
;;
 esac
 
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index e8143b079..d22626e30 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -81,7 +81,7 @@ case x"$GRUB_FS" in
 xzfs)
rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 
2>/dev/null || true`
bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
-   LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
+   LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
;;
 esac
 

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#912190: mixx uses inappropriate compiler flags on arm.

[peter green]

package: mixxx
version: 2.1.3~dfsg-1
severity: serious
tags: patch

mixxx unconditionally uses -mfloat-abi=hard and -mfpu=neon on arm*. These are 
inappropriate in Debian.

On armhf "-mfloat-abi=hard" is redundant but not harmful "-mfpu=neon" will 
likely result in binaries that will break on the baseline CPU level for the port.

On armel "-mfloat-abi=hard" breaks the build (the error message shown in the 
build log does not show the real cause but inspecting config.log after a build attempt 
does). I think -mfpu is a no-op on armel unless -mfloat-abi is also used but it is still 
not good practice to use it.

On arm64 "-mfloat-abi=hard" and "-mfpu=neon" both break the build.

I did my research with version 2.1.4~dfsg-1 but looking at the build logs it 
looks like 2.1.3~dfsg-1 was probably affected by the same issue.

While working on the above issue I also found that the clean target was not 
cleaning up properly.

Attached is a debdiff that removes the offending compiler flags and fixes the 
clean target.

diff -Nru mixxx-2.1.4~dfsg/debian/changelog mixxx-2.1.4~dfsg/debian/changelog
--- mixxx-2.1.4~dfsg/debian/changelog   2018-10-07 13:15:30.0 +
+++ mixxx-2.1.4~dfsg/debian/changelog   2018-10-28 03:49:20.0 +
@@ -1,3 +1,11 @@
+mixxx (2.1.4~dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove inappropriate compiler flags on arm.
+  * Fix clean target.
+
+ -- Peter Michael Green   Sun, 28 Oct 2018 03:49:20 +
+
 mixxx (2.1.4~dfsg-1) unstable; urgency=medium
 
   [ Olivier Humbert ]
diff -Nru 
mixxx-2.1.4~dfsg/debian/patches/0004-remove-inapprorpriate-arm-compiler-flags.patch
 
mixxx-2.1.4~dfsg/debian/patches/0004-remove-inapprorpriate-arm-compiler-flags.patch
--- 
mixxx-2.1.4~dfsg/debian/patches/0004-remove-inapprorpriate-arm-compiler-flags.patch
 1970-01-01 00:00:00.0 +
+++ 
mixxx-2.1.4~dfsg/debian/patches/0004-remove-inapprorpriate-arm-compiler-flags.patch
 2018-10-28 03:38:36.0 +
@@ -0,0 +1,31 @@
+Description: Remove inappropriate compiler flags on arm.
+ The flags used by this package result in build failures
+ and violations of the minimum CPU baseline. Remove them.
+Author: Peter Micheal Green 
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: , 
+Bug: 
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Reviewed-By: 
+Last-Update: 2018-10-28
+
+--- mixxx-2.1.4~dfsg.orig/build/features.py
 mixxx-2.1.4~dfsg/build/features.py
+@@ -1163,8 +1163,8 @@ class Optimize(Feature):
+ build.env.Append(CCFLAGS='-mfpmath=sse')
+ elif build.architecture_is_arm:
+ self.status = self.build_status(optimize_level)
+-build.env.Append(CCFLAGS='-mfloat-abi=hard')
+-build.env.Append(CCFLAGS='-mfpu=neon')
++#build.env.Append(CCFLAGS='-mfloat-abi=hard')
++#build.env.Append(CCFLAGS='-mfpu=neon')
+ else:
+ self.status = self.build_status(optimize_level)
+ # this sets macros __SSE2_MATH__ __SSE_MATH__ __SSE2__ __SSE__
diff -Nru mixxx-2.1.4~dfsg/debian/patches/series 
mixxx-2.1.4~dfsg/debian/patches/series
--- mixxx-2.1.4~dfsg/debian/patches/series  2018-08-23 20:58:34.0 
+
+++ mixxx-2.1.4~dfsg/debian/patches/series  2018-10-28 03:36:48.0 
+
@@ -1,3 +1,4 @@
 0001-disable_soundsourcem4a.patch
 0002-desktop_file.patch
 0003-soundtouch.patch
+0004-remove-inapprorpriate-arm-compiler-flags.patch
diff -Nru mixxx-2.1.4~dfsg/debian/rules mixxx-2.1.4~dfsg/debian/rules
--- mixxx-2.1.4~dfsg/debian/rules   2018-05-02 15:02:09.0 +
+++ mixxx-2.1.4~dfsg/debian/rules   2018-10-28 03:49:20.0 +
@@ -54,6 +54,7 @@
dh_clean .sconsign.dblite cachecustom.py \
config.log src/build.h build/*.pyc mixxx.1
dh_auto_clean
+   rm -rf lin*_build/
 
 override_dh_auto_install:
scons $(SCONS_OPTS) install

Bug#906429: closed by Michael Biebl (Bug#906429: fixed in systemd 239-11)

[Manuel A. Fernandez Montecelo]

Hi,

Em dom, 28 de out de 2018 às 15:51, Debian Bug Tracking System
 escreveu:
>
> This is an automatic notification regarding your Bug report
> which was filed against the src:systemd package:
>
> #906429: systemd: Please raise timeout for tests (for riscv64)
>
> It has been closed by Michael Biebl .
> [...]
>[ Manuel A. Fernandez Montecelo ]
>* Run "meson test" instead of "ninja test"
>  Upstream developers of meson recommend to run it in this way, because
>  "ninja test" just calls "meson test", and by using meson directly and
>  using extra command line arguments it is possible to control aspects of
>  how the tests are run.
>* Increase timeout for test in riscv64.
>  The buildds for the riscv64 arch used at the moment are slow, so increase
>  the timeouts for this arch by a factor of 10, for good measure.
>  (Closes: #906429)

It now built successfully for the first time, unmodified:

  https://buildd.debian.org/status/logs.php?pkg=systemd=riscv64

Ironically, it was built in the slowest of the buildds active at the
moment.  But it built correctly, passing all the tests and unatteded,
which is the important thing.

Thanks for merging and uploading!

systemd was one of the last two packages preventing "debootstrap" from
working straight away (that is, producing useful/self-sufficient
chroots without extra steps), due to some packages being in
"unreleased" part of the archive rather than all being in the same
one.  Now only libffi remains.

Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#741464: grub-pc-bin: hangs after displaying boot menu

[Colin Watson]

On Sun, Feb 01, 2015 at 11:16:59PM +0100, Marco Gamberoni wrote:
> I see this same at_keyboard behaviour: working in VirtualBox, delivering 
> garbage on this real hardware:
>  - an HP Proliant DL380 Gen5 machine
>  - with a Compaq PS/2 keyboard italian layout attached
>  - booted from an iso image made with grub-mkrescue (GRUB) 2.02~beta2-15, 
> containing a keyboard layout file made with
>   ckbcomp -model pc105 -layout it | grub-mklayout -o pc105-it.gkb
[...]
> Having read
> 
> http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html
> it is obvious what's going on: at_keyboard is using scankey set 1 but the 
> keyboard is using set 2 and the keyboard controller is not translating.

Sorry for the long delay.  Are you still in a position to test this?

I just ran across this upstream commit:

  
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=c4b8bec5fee4e30a165fd14a188cf3ab8eccd095

Ignoring the specific hardware mentioned here, it seems like this could
be a plausible cause: if GRUB manages to get out of sync with the
keyboard controller on the command/data sequence, then it could easily
end up confused about which is the current scan code set (see the
changes to query_mode in particular) and so end up using the wrong set,
or possibly even send a nonsense command somehow.  It seems worth
testing if you can.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#891434: grub-efi: System fails to boot after "No space left on device" on EFI variable storage

[Colin Watson]

On Sun, Feb 25, 2018 at 04:13:13PM +0100, Ralf Jung wrote:
> earlier today I did a system update, which completed successfully (as in, dpkg
> didn't stop due to an error).  I then rebooted my machine.  This left Linux
> unable to boot; only the Windows entry was left in the boot menu.  After some
> hours of debugging, the problem turned out to be that writing an EFI variable
> fails with "No space left on the device".  I did a firmware update (from
> Windows), to no avail.  In the end I booted into a live system, deleted some 
> of
> the "dump-type0-*" variables, rebooted, and then ran "grub-install" from a
> chroot to fix the situation.
> 
> I'm not exactly sure what went wrong here, but clearly the system shouldn't be
> put into an unbootable state ever.  I see two bugs here:
> 
> * First, it looks like something is filling up the EFI variable space.  I've
>   added an `ls -lah` of the evivars folder below.  This is after I deleted
>   roughly 20-30 "dump-type0-*" variables.  Is this the kernel dumping
>   information (about crashes or so)?  If yes, it seems to do so without ever
>   cleaning up or taking free space into account, which I'd consider a serious
>   bug.  Should I report this against the kernel?  I don't even know what 
> creates
>   those EFI variables.

Those are created by the efi_pstore_write function in the kernel.
Beyond that I'm not really familiar with what's going on - you should
ask Debian's kernel folks if you need to pursue this.

> * Second, does grub-install really have to delete and create EFI variables 
> even
>   when nothing changed?  It seems to me that writing an EFI variable is only
>   necessary when initially installing GRUB.  Even if writing is necessary, a
>   check could be done *before* deleting the boot entry whether it will be
>   possible to write it again later.  Right now, it seems that grub will 
> happily
>   delete the debian boot entry and then fail to create it again -- and this
>   doesn't even make the system update fail.

Fixing this does seem like it would be a good idea for general
robustness against dodgy firmware (this is not the first iteration of
problems along these lines).  It would take some development work, but
hopefully not too much.

Things that GRUB can't do, as far as I can tell:

 * I don't think there's a way for GRUB to check whether it will be
   possible to recreate a boot entry later; as I understand it, that
   depends on various low-level details, including firmware-specific
   quirks.
   
 * Even detecting that nothing changed would require cooperation from
   efibootmgr, since the encoding of the EFI variable is an
   implementation detail there (so we can't just read it out and
   compare), and efibootmgr doesn't expose a way for GRUB to say "set
   this configuration, but only if it's different from what's already
   there".

However, I think GRUB can at least manage to delete all but one entry
from the same distributor rather than all of them, and if it finds one
remaining entry then it can modify that rather than writing a brand new
variable.  As I understand it, that would probably be enough to fix this
bug?

-- 
Colin Watson   [cjwat...@debian.org]

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

[Samuel Thibault]

Control: reassign -1 dh-python
Control: tags -1 + patch

Samuel Thibault, le mar. 16 oct. 2018 22:13:59 +0200, a ecrit:
> Samuel Thibault, le mar. 16 oct. 2018 03:04:16 +0200, a ecrit:
> > This is driving me crazy :)
> > 
> > I have uploaded the VM images on
> > https://people.debian.org/~sthibault/tmp/fails.img.gz
> > https://people.debian.org/~sthibault/tmp/works.img.gz
> > 
> > Booting one or the other does not matter. What does matter is the
> > disk image used to store the chroot. Each VM image has its own
> > /var/cache/pbuilder/sphinxbase-build directory (almost exactly the
> > same), and it does not matter which of the two I copy, if I copy it
> > inside the fails.img disk I'm getting the lintian issue, and if it's
> > inside the works.img disk I'm not getting it (there's a fresh checkout
> > of sphinbase in /tmp/sphinxbase inside the chroots). And of course my
> > own main system is in the fails case, thus preventing me from building
> > the package :) tune2fsk does not show any difference between the two
> > filesystem options, just creation time, mount count & such.
> > 
> > Any other idea of what could be different between the two filesystems?
> 
> It could very well be e.g. the resulting inode numbers and such, thus my
> hypothesis at the top of the quotes above. Python people can have a look
> at the fails.img.gz image, where the issue is notably reproducible from
> the chroot in /var/cache/pbuilder/sphinxbase-build , building for
> instance in /tmp/sphinxbase.

I overrided dh_python3 into /bin/false to catch the result just before
running dh_python3, the two build trees are similar except the .pyc
timestamps which are a few seconds apart in the 2.7 and 3.6 trees.

I then tried to pass -v to dh_python3, and got differing results,
as attached.  It seems in the failure case it indeed doesn't do
everything for 3.6: there are 4 lines less which rename the .so to a 36
variant.  I looked deeper in fs.py, and I found that in the succeeding
case, the main loop inside share_files sees _sphinbase.so before
_sphinxbase.so.0.0.0, and thus renames it, and in the failing case, that
loop sees _sphinxbase.so.0.0.0 before _sphinxbase.so.0, and when it
looks at _sphinxbase.so.0, exits() fails, because the target was moved,
and thus the symlink is now broken. I changed that exists() call into
lexists() to allow for broken symlinks, as the attached patch does, and
things got fixed. This seems like a logical thing to do, and possibly
needed in a few other places in fs.py

Samuel
D: dh_python3 dh_python3:161: version: 3.20180927
D: dh_python3 dh_python3:162: argv: ['/usr/bin/dh_python3', '-v']
D: dh_python3 dh_python3:163: options: {'guess_deps': True, 'skip_private': 
False, 'verbose': True, 'arch': None, 'package': None, 'no_package': None, 
'compile_all': False, 'vrange': None, 'regexpr': None, 
'accept_upstream_versions': False, 'depends': None, 'depends_section': None, 
'recommends': None, 'recommends_section': None, 'suggests': None, 
'suggests_section': None, 'requires': None, 'shebang': None, 'ignore_shebangs': 
False, 'clean_dbg_pkg': True, 'no_ext_rename': False, 'no_shebang_rewrite': 
False, 'O': None}
D: dh_python3 dh_python3:164: args: []
D: dh_python3 dh_python3:166: supported Python versions: 3.6,3.7 (default=3.6)
D: dh_python3 debhelper:100: skipping package libsphinxbase-doc (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package libsphinxbase-dev (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package sphinxbase-utils (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:100: skipping package libsphinxbase3 (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:107: skipping package: python-sphinxbase
D: dh_python3 debhelper:100: skipping package swig-sphinxbase (missing 
${python3:Depends} in Depends)
D: dh_python3 debhelper:153: source=sphinxbase, binary 
packages=['python3-sphinxbase']
D: dh_python3 dh_python3:183: processing package python3-sphinxbase...
D: dh_python3 fs:49: moving files from 
debian/python3-sphinxbase/usr/lib/python3.6/site-packages to 
debian/python3-sphinxbase/usr/lib/python3/dist-packages/
I: dh_python3 fs:312: removing symlink: 
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so
I: dh_python3 fs:314: renaming 
debian/python3-sphinxbase/usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so.0.0.0
 to _sphinxbase.so
D: dh_python3 tools:230: invoking: python3.6 -c 'import sysconfig as 
s;print("__SEP__".join(i or "" for i in s.get_config_vars("SOABI", "MULTIARCH", 
"INCLUDEPY", "LIBPL", "LDLIBRARY")))'
I: dh_python3 fs:329: renaming _sphinxbase.so to 
_sphinxbase.cpython-36m-x86_64-linux-gnu.so
D: dh_python3 fs:49: moving files from 
debian/python3-sphinxbase/usr/lib/python3.7/site-packages to 
debian/python3-sphinxbase/usr/lib/python3/dist-packages/
I: dh_python3 fs:312: removing symlink: 

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Bernhard Übelacker]

Am 28.10.2018 um 19:23 schrieb Colin Watson:
> 
> Thanks for the investigation.  (Note also that the OpenSSH version in
> question is the one that switched from OpenSSL 1.0 to 1.1, which was a
> big change.)
> 
> There were some significant changes in this area in OpenSSL 1.1.1.
> Would it be possible to try running OpenSSH with OpenSSL 1.1.0h to see
> if that makes a difference?  Unfortunately this is a little complicated
> as it will require doing a local build of the Debian OpenSSH source
> package in order to reduce the dependency; let me know if you need help
> with setting this up.
> 

Hello Colin Watson,
I built a local package OpenSSH 7.9p1-1 against OpenSSL 1.1.0h like
described in the upper half of attached file.
This shows an normal start of the ssh service and login is
immediately after a restart possible,
running on linux-image-4.18.0-2-amd64 4.18.10-2.

Because in another bug suggested to test the previous kernel
with a similar issue with the login manager (that I cannot find right
now), I reverted back to regular OpenSSH 7.9p1-1 with OpenSSL 1.1.1-1
and it shows the same delay when runnging with kernel
linux-image-4.17.0-3-amd64 4.17.17-1.

Just found the possibly somehow related bug #910504, that proposes
the installation of rng-tools - but this just fails to start because
of "Cannot find a hardware RNG device to use.", with OpenSSH 7.9p1-1
with OpenSSL 1.1.1-1 at linux-image-4.18.0-2-amd64 4.18.10-2.

Kind regards,
Bernhard


apt install fakeroot
apt build-dep openssh-server




# http://snapshot.debian.org/package/openssl/1.1.0h-4/
wget 
http://snapshot.debian.org/archive/debian/20180523T153942Z/pool/main/o/openssl/libssl-dev_1.1.0h-4_amd64.deb
wget 
http://snapshot.debian.org/archive/debian/20180523T153942Z/pool/main/o/openssl/libssl1.1_1.1.0h-4_amd64.deb
wget 
http://snapshot.debian.org/archive/debian/20180523T153942Z/pool/main/o/openssl/openssl_1.1.0h-4_amd64.deb

dpkg -i *.deb




mkdir openssh/orig -p
cdopenssh/orig
apt source openssh
cd ../..




cd openssh
cp -a orig try1
cd try1/openssh-7.9p1
dpkg-buildpackage

dpkg -i openssh-client_7.9p1-1_amd64.deb openssh-server_7.9p1-1_amd64.deb 
openssh-sftp-server_7.9p1-1_amd64.deb

reboot

# SSH login immediately possible

# "[  OK  ] Started OpenBSD Secure Shell server." takes "no" time.





##





apt install --reinstall libssl-dev libssl1.1 openssl openssh-client 
openssh-server openssh-sftp-server

reboot

# SSH not immediately possible:
#   ssh_exchange_identification: Connection closed by remote host
#   ssh_exchange_identification: read: Connection reset by peer

# "[ *** ] A start job is running for OpenBSD Secure Shell server (1 min 28s / 
1 min 30s)



# http://snapshot.debian.org/package/linux/

wget 
http://snapshot.debian.org/archive/debian/20180818T210445Z/pool/main/l/linux/linux-image-4.17.0-3-amd64_4.17.17-1_amd64.deb

dpkg -i linux-image-4.17.0-3-amd64_4.17.17-1_amd64.deb

# booting with 4.17

# The same waiting with 4.17 as with 4.18






#




qemu-system-x86_64 -m 3G -enable-kvm -smp 8 -monitor stdio -usb -device 
usb-tablet \
-drive file=system.img,format=raw,cache=writeback \
-device e1000,netdev=net0 -netdev 
user,id=net0,hostfwd=tcp:127.0.254.34:-:22,hostfwd=tcp:127.0.254.34:3389-:3389,tftp=/home/bernhard/data/pxeboot,bootfile=/boot/grub/i386-pc/core.0
 \
-boot c -no-shutdown -snapshot

Bug#911864: lintian gives E: statically-linked-binary for golang project's binary

[Chris Lamb]

tags 911864 + pending
thanks

Hi Jeffrey,

> 8) debuild -uc -us -b
 ^^

Ahh, so in this case Lintian does not access to the source package
and thus cannot determine the build-depends. Fixed in Git, pending
upload:

  
https://salsa.debian.org/lintian/lintian/commit/e59e44ec0d648b66b30ab52c08f3def9224c7373

  checks/binaries.pm | 2 ++
  debian/changelog   | 5 +
  2 files changed, 7 insertions(+)

(Please prefer to send plaintext email in future; whilst I am not
too fussy, many others in Debian are quite sensitive on this! Thanks
again.)


Regards,

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

Bug#909007: stretch-pu: package firetray/0.6.1+dfsg-1

[Adam Borowski]

On Sat, Oct 27, 2018 at 09:46:19PM +0100, Adam D. Barratt wrote:
> On Sat, 2018-10-27 at 22:44 +0200, Adam Borowski wrote:
> > On Sat, Oct 27, 2018 at 04:21:09PM +0100, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > 
> > In the meantime, another upload of thunderbird broken the version check,
> > which was "up to 60.0".  Turns out 60.2.1 does not match that anymore. 
> > Details in #910973; no one from the maintainer team responded thus I
> > scheduled a NMU, it'll go in tomorrow evening.
> 
> It sounds fine, as long as it's uploaded in time.

I've uploaded as 0.6.1+dfsg-1.2~deb9u1 -- with a changelog written to be a
backport of the unstable version rather than as one patch.  There's no
actual difference, as there were no unrelated uploads between stretch and
current buster.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Bug#912189: libpthread: man pthread_mutex_init doesn't find a man page

[Joshua]

Package: libpthread-stubs0-dev
Version: 0.3-4
Severity: normal
File: libpthread
Tags: newcomer

It's possible I don't quite have the right package.

man pthread_init does not find a man page but should. I'm not certain but I 
think one can be thrown
together pretty quickly from the one on the open group.


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

Kernel: Linux 4.9.0-7-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#908085: leiningen-clojure: FTBFS randomly (clojure.lang.PersistentVector cannot be cast to java.base.etc.etc)

[Santiago Vila]

Version: 2.8.1-9

Hi. I can't reproduce this anymore in buster (where I was trying),
so I'm marking this issue as fixed in the current version.

(I'm not sure, however, if this is due to some change in the code or
maybe because of some behaviour change in one of the build-dependencies).

Thanks.

Bug#911712: [Pkg-tigervnc-devel] Bug#911712: tigervnc: diff for NMU version 1.9.0+dfsg-1.1

[Joachim Falk]

Hi Christoph,

On 28.10.18 11:53, Christoph Biedl wrote:
> tags 911712 + patch
> tags 911712 + pending
> user debian-rele...@lists.debian.org
> usertags -1 + bsp-2018-10-de-karlsruhe
> thanks
> 
> Dear maintainer,
> 
> I've prepared a NMU for tigervnc (versioned as 1.9.0+dfsg-1.1) and will
> upload it to DELAYED/5 in a moment. Please feel free to tell me if I
> should delay it longer.
I have prepared 1.9.0+dfsg-2 integrating the fix as well as a bug fix for
the missing icons and desktop file.

@Yaroslav or @Mike, can you upload. Please replace
1.9.0+dfsg-2~RC3 with 1.9.0+dfsg-2 and release to unstable.

Regards,

Joachim Falk




signature.asc
Description: OpenPGP digital signature

Bug#858938: fixed in kopete 4:18.04.1-1

[Sebastian Andrzej Siewior]

On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote:
> On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > > > Source: kopete
> > > > Source-Version: 4:18.04.1-1
> > > > 
> > > > We believe that the bug you reported is fixed in the latest version of
> > > > kopete, which is due to be installed in the Debian FTP archive.
> > > 
> > > Any plans to upload this to unstable?
> > 
> > There are just two packages left in testing which use openssl1.0. The
> > last kopete upload was in mid June. Is there anything blocking an upload
> > to unstable?
> 
> The other one just got fixed in unstable, so this will soon be the
> only package in testing still depending on libssl1.0.2.

kopete is the only package in testing still using libssl1.0.2. Could
someone please comment on this?

> Kurt

Sebastian

Bug#897882: Bug#859784: NMU for validns

[Sebastian Andrzej Siewior]

On 2018-10-27 18:36:12 [+0200], Christoph Biedl wrote:
> +--- a/ipseckey.c
>  b/ipseckey.c
> +@@ -111,8 +111,11 @@
> + default:
> + strcpy(gw, "??");
> + }
> ++#pragma GCC diagnostic push
> ++#pragma GCC diagnostic ignored "-Wformat-truncation"
> + snprintf(s, 1024, "( %d %d %d %s ... )",
> +  rr->precedence, rr->gateway_type, rr->algorithm, gw);
> ++#pragma GCC diagnostic pop

This looks odd. There has to be a better way of dealing with this than
just shutting off the warning so things compile again.

> diff -Nru validns-0.8+git20160720/debian/patches/use-openssl-1.1.patch 
> validns-0.8+git20160720/debian/patches/use-openssl-1.1.patch
> --- validns-0.8+git20160720/debian/patches/use-openssl-1.1.patch  
> 1970-01-01 01:00:00.0 +0100
> +++ validns-0.8+git20160720/debian/patches/use-openssl-1.1.patch  
> 2018-10-27 18:13:35.0 +0200
> +--- a/dnskey.c
>  b/dnskey.c
> +@@ -154,6 +154,7 @@
> + unsigned int e_bytes;
> + unsigned char *pk;
> + int l;
> ++   BIGNUM *n, *e;
> + 
> + rsa = RSA_new();
> + if (!rsa)
> +@@ -174,11 +175,12 @@
> + if (l < e_bytes) /* public key is too short */
> + goto done;
> + 
> +-rsa->e = BN_bin2bn(pk, e_bytes, NULL);
> ++   e = BN_bin2bn(pk, e_bytes, NULL);

BN_bin2bn() and EVP_MD_CTX_new() which were introduced as part of this
patch may return NULL. Not a single instance in the patch checks the
return value. This is just sloppy.

> + pk += e_bytes;
> + l -= e_bytes;
> + 
> +-rsa->n = BN_bin2bn(pk, l, NULL);
> ++   n = BN_bin2bn(pk, l, NULL);
> ++   RSA_set0_key(rsa, n, e, NULL);
> + 
> + pkey = EVP_PKEY_new();
> + if (!pkey)
> +--- a/rrsig.c
>  b/rrsig.c
> +@@ -374,7 +374,7 @@
> + static pthread_mutex_t *lock_cs;
> + static long *lock_count;
> + 
> +-static unsigned long pthreads_thread_id(void)
> ++unsigned long pthreads_thread_id(void)

not only there is no need for this hunk IMHO the thread locking used
here is not required for openssl 1.1.0+.

> + {
> + unsigned long ret;
> + 

Sebastian

Bug#911632: found 911632 in 2.7.4+reloaded3-6

[Wolfgang Schweer]

While testing Debian Edu Buster I noticed that gosa failed to install 
due to the reported bug. As gosa hasn't seen a new version recently, I 
guess the failure might be due to a recently updated dependency (or even 
a chain of those). As far as I was able to find out, the missing 
function imageCreateFromPng() should be provided by php-gd. But also 
that package doesn't seem to have been updated recently.

Wolfgang


signature.asc
Description: PGP signature

Bug#590895: Bug#717531: marked as done (/sbin/shutdown: shutdown -P sets INIT_HALT to POWERDOWN instead of POWEROFF) [and 1 more messages]

[Ian Jackson]

Control: reopen -1 =
Control: tag -1 + fixed-upstream

> From: Jesse Smith 
> To: n-cl...@bugs.debian.org
> Subject: Fixed upstream
> Date: Sun, 28 Oct 2018 16:20:36 -0300
> 
> This bug has been address upstream.

Thanks, it's great that you're taking an interest, but I'm afriad
closing the bug in the Debian BTS this way is premature.  The fix is
not in Debian yet.

These bugs will be marked closed by the corresponding upload to
Debian, assuming that the debian/changelog mentions them.

The `fixed-upstream' tag is used for this state.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#890594: salsa script ready to review

[Xavier]

Le 28/10/2018 à 09:47, Xavier a écrit :
> Le 28/10/2018 à 08:43, Xavier a écrit :
>> Le 27/10/2018 à 14:24, Xavier a écrit :
>>> Le 25/10/2018 à 11:33, Raphael Hertzog a écrit :
 Hi,
>>>
>>> Hello,
>>>
 On Fri, 19 Oct 2018, Xavier wrote:
> first version of salsa script is ready to review. Documentation is here:
> https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl

 Thanks for working on this!
>>>
>>> You're welcome ;-)
>>>
 My first comment is that we should not have to work with numerical
 identifiers. I want to modify the group "pkg-security-team" and not
 the team-id 1234. The tool should do the lookup for me. I don't have to
 know internal identifiers.
>>>
>>> Fixed: you can use --group. If more than one group has this name, you'll
>>> be invited to use --group-id (results are displayed on this error).
>>>
>>> I added a cache file to minimize Gitlab queries (with a purge_cache
>>> command). Default to ~/.cache/salsa.json
>>>
 Furthermore "team-id" is really not consistent with the the gitlab
 vocabulary. They use "group id".
>>>
>>> Fixed: team and group is now equivalent (commands and options)
>>>
>  - manage repos

 The set of commands that you propose are really tailored to the current
 hooks that we are using. This is convenient to use but it is not
 future-proof. I would rather have a configuration file describing all
 parameters that we want to see configured and be able to pass that
 configuration file to the tool.
>>>
>>> I'm going to add a --conf-file for this
>>
>> Done
>>
 I would love also if the tool could enforce things like:
 - rename "master" into "debian/master" (when debian/master doesn't exist)
>>
>> I don't understand this proposition.
> 
> This is the last point to do but I need to understand it.

Mattia explained me dep14. I found a way to do it: create branch from
master, update project to set default_branch to debian/master then
remove master. It works as expected.

$ salsa update_repo node-mongodb --group js-team --rename-head

$ salsa update_repo --all --rename-head --no-fail # all user projects

Manpage updated:
https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L339

 - define protected branches (including the possibility to disable all
   protections)
>>
>> This is my next step ;-)
> 
> Done
> 
> Of course, most of options can be set in ~/.devscripts. Example:
>
>   SALSA_KGB=yes
>   SALSA_IRC_CHANNEL=debian-perl
>   SALSA_TEAM_ID=2665
>   SALSA_DESC=yes
>   SALSA_DESC_PATTERN="Perl team package %p"
>   SALSA_TOKEN=abcdef

 This looks like a misfeature. It's too easy to forget about those and
 apply unwanted settings to other repositories.
>>>
>>> I'm going to add a --conf-file for this
>>
>> Done
>>
 Only SALSA_TOKEN is fine (and even there, this is private data and it
 might be better handled through some other mechanism?).
>>>
>>> Fixed, you can choose SALSA_TOKEN or SALSA_TOKEN_FILE or --token or
>>> --token-file
>>>
> QUESTION 1: is "salsa" a good name?

 Something more explicit would be better. I'm not good at names. Maybe
 "debsalsa" or "salsa-configure". But then it could be designed as a
 generic gitlab configuration tool and you could entirely avoid the salsa
 marker in the name...
>>>
>>> gitlab-cfg ? Is it a good idea to ask to debian-devel@l.d.o ?
>>>
> QUESTION 2: I think --all should fail unless current user is owner,
> isn't it?

 You might want to have some interactive confirmation. "You are about to
 modify the configuration of 245 repositories. Do you want to continue ?".

 But otherwise I don't think that you need to handle any access control,
 let gitlab take care of this part.
>>>
>>> Fixed: question unless --yes
>>>
 Cheers,
>>>
>>> Regards,
>>> Xavier
> 

Bug#908612: stretch-pu: package ganeti/2.15.2-7+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2018-09-11 at 22:16 +0300, Apollon Oikonomopoulos wrote:
> I'd like to update ganeti in Stretch once more, fixing the following 
> issues:
> 
>  - The fix for #895599 that was included in +deb9u2 unfortunately
> was incomplete; I failed to cherry-pick an additional patch rendering
> the fix ineffective.
[...]
>  Since SHA-1 is weak and deprecated anyway, I would like
> to backport a change from unstable to make the CA use SHA-256 for 
>    certificate signatures, to allow cluster administrators to
> upgrade their crypto before actually upgrading to Buster. See #907216
> and 
>    #907569 for more information.
> 
>  - The bash completion script shipped in Stretch is ineffective.  

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3

[Adam D. Barratt]

On Sun, 2018-10-28 at 10:58 -0400, Daniel Kahn Gillmor wrote:
> On Sat 2018-10-27 16:47:27 +0100, Adam D. Barratt wrote:
[...]
> > I know you mentioned that the changes shouldn't affect gpgv
> > (particularly as used in d-i), but the udeb still means that the
> > upload
> > needs an explicit ack, so I've CCed KiBi and tagged the bug
> > appropriately.
> 
> thank you!  should i go ahead with the upload to land it in proposed,
> or should i wait for kibi's review+ack?

I don't have any objections if you want to upload already, but it won't
get accepted into p-u from stable-new until it's had the d-i ack.

Regards,

Adam

Bug#912187: Wrong jvm options for armhf

[Gero Müller]

Package: ca-certificates-java
Version: 20170531+nmu1

On armhf the server JVM is not available. But the postinst script
assumes so and uses it to setup a temporary configuration in
/etc/java-8-openjdk/jvm-armhf.cfg
The installation of openjdk-8-jre-headless therefore fails!


Running hooks in /etc/ca-certificates/update.d...

Error: missing `server' JVM at
`/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'.
Please install or use the JRE or JDK that contains these missing components.
E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.
done.
Errors were encountered while processing:
 ca-certificates-java
 openjdk-8-jre-headless:armhf
 openjdk-9-jre-headless:armhf
E: Sub-process /usr/bin/dpkg returned an error code (1)


Please use the client defaults instead (jvm.cfg-client_default from the
openjdk sources):

-client KNOWN
-server ALIASED_TO -client

Thanks!

Bug#912159: stretch-pu: package libmspack/0.5-1+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-10-28 at 16:37 +0100, Thorsten Alteholz wrote:
> there are two open CVEs for libmspack in Stretch:
>    * CVE-2018-18584
>    * CVE-2018-18585
> As the security team does not rate them as appropriate for an own
> DSA, but
> want to see an update in Stretch, I would like to ask for an update
> via PU.

Please go ahead.

Regards,

Adam

Bug#814798: Workaround for debian-installer

[Justin Vallon]

I was able to get encrypted /boot working by partitioning (ESP
partition, crypt partition ( LVM ( root, home, swap ) ) ).  When the
grub install failed, switch to "execute shell", and:

$ cd /target/etc/default

$ echo 'GRUB_ENABLE_CRYPTODISK=y' >> grub

$ exit

Then re-execute the grub install.  Install completed.  Got EFI password
prompt, grub, kernel password prompt, 'login:'.

-- 
-Justin
justinval...@gmail.com

Bug#912185: mkfs.ext4 spanish translation incomplete cause problems

[H . Gabriel Máculus]

Package: e2fsprogs
Version: 1.43.4-2

When I run mkfs.ext4 to overwrite existing filesystem it prompt in
english  (last line) and you need reply in spanish (S, n)

root@debian:/home/gabriel/Descargas# mkfs.ext4 myfiledisk.raw
mke2fs 1.43.4 (31-Jan-2017)
Descartando los bloques del dispositivo: hecho
Se está creando un sistema de ficheros con 102400 bloques de 1k y 25688 nodos-i
UUID del sistema de ficheros: da615e2d-0ed8-4480-b975-6bf37442558d
Respaldo del superbloque guardado en los bloques:
8193, 24577, 40961, 57345, 73729

Reservando las tablas de grupo: hecho
Escribiendo las tablas de nodos-i: hecho
Creando el fichero de transacciones (4096 bloques): hecho
Escribiendo superbloques y la información contable del sistema de
ficheros: hecho

root@debian:/home/gabriel/Descargas# mkfs.ext4 myfiledisk.raw
mke2fs 1.43.4 (31-Jan-2017)
myfiledisk.raw contiene un sistema de ficheros ext4
fecha de creación Sun Oct 28 18:28:54 2018
Proceed anyway? (y,N)

I suggest fix this translation
Proceeed anyway? (y, N)
to
Continuar de todas formas? (s, N)

TIA
-- 
H. Gabriel Máculus

https://gabrielmaculus.blogspot.com.ar/
https://prism-break.org/

Bug#912186: debbugs: correct favicon location in HTML header

[Chris Lamb]

Source: debbugs
Version: 2.6.0
Severity: normal
Tags: patch

Hi,

Currently we render this to pages:

  

Unfortunately, this actually represents a protocol-relative URI
instead of an path-absolute link, causing lookups to a location
such as "https://favicon.png/; or "http://favicon.png/;.

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/templates/en_US/html/pre_title.tmpl 
b/templates/en_US/html/pre_title.tmpl
index cff5bbc..6c165f8 100644
--- a/templates/en_US/html/pre_title.tmpl
+++ b/templates/en_US/html/pre_title.tmpl
@@ -1,4 +1,4 @@
 
 
-
+
 
\ No newline at end of file

Bug#912184: python-testfixtures FTBFS with python 3.7 as supported version

[Adrian Bunk]

Source: python-testfixtures
Version: 4.14.3-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-testfixtures.html

...
I: pybuild base:217: python3.7 /usr/bin/zope-testrunner 
--path=/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build
 testfixtures
Running zope.testrunner.layer.UnitTests tests:
  Set up zope.testrunner.layer.UnitTests in 0.000 seconds.


Failure in test test_exception_diff 
(testfixtures.tests.test_compare.TestCompare)
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 615, in run
testMethod()
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/tests/test_compare.py",
 line 170, in test_exception_diff
"ValueError('some message',) != ValueError('some other message',)"
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/tests/test_compare.py",
 line 51, in check_raises
compare(actual, expected=message, show_whitespace=True)
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/comparison.py",
 line 485, in compare
raise AssertionError(message)
AssertionError: 
"ValueError('some message',) != ValueError('some other message',)" (expected)
!=
"ValueError('some message') != ValueError('some other message')" (actual)



Failure in test test_exception_diff_c_wrapper 
(testfixtures.tests.test_compare.TestCompare)
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 615, in run
testMethod()
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/tests/test_compare.py",
 line 184, in test_exception_diff_c_wrapper
).format(exception_module))
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/tests/test_compare.py",
 line 51, in check_raises
compare(actual, expected=message, show_whitespace=True)
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/comparison.py",
 line 485, in compare
raise AssertionError(message)
AssertionError: 
--- expected
+++ actual
@@ -1,4 +1,4 @@
 '\n'
 '  \n'
 "  args:('some message',) != ('some other message',)\n"
-"   != ValueError('some other message',)"
+"   != ValueError('some other message')"



Failure in test test_exception_different_object 
(testfixtures.tests.test_compare.TestCompare)
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 615, in run
testMethod()
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/tests/test_compare.py",
 line 157, in test_exception_different_object
"ValueError('some message',) != ValueError('some message',)"
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/tests/test_compare.py",
 line 51, in check_raises
compare(actual, expected=message, show_whitespace=True)
  File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/comparison.py",
 line 485, in compare
raise AssertionError(message)
AssertionError: 
"ValueError('some message',) != ValueError('some message',)" (expected)
!=
"ValueError('some message') != ValueError('some message')" (actual)



Failure in test 
/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/docs/warnings.txt

--
File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/docs/warnings.txt",
 line 26, in warnings.txt
Failed example:
with ShouldWarn(UserWarning('you should fix that')):
warn("sorry dave, I can't let you do that")
Differences (ndiff with -expected +actual):
  Traceback (most recent call last):
- ...
+   File "/usr/lib/python3.7/doctest.py", line 1329, in __run
+ compileflags, 1), test.globs)
+   File "", line 2, in 
+ warn("sorry dave, I can't let you do that")
+   File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/shouldwarn.py",
 line 43, in __exit__
+ compare(self.expected, actual=[wm.message for wm in self.recorded])
+   File 
"/build/1st/python-testfixtures-4.14.3/.pybuild/cpython3_3.7_testfixtures/build/testfixtures/comparison.py",
 line 485, in compare
+ raise AssertionError(message)
  AssertionError: sequence not as expected:
  
  same:
  []
  
  expected:
  [
-   
?  ^^^
+   
?  
 

Bug#912019: homebank: new homebank 5.2.2

[Francesco Namuri]

Hello,
thanks for the report, I'm working on it.

I hope to do the upload in the next two days.

Best Regards,
Francesco

On 2018-10-27 12:35, Jonatan Nyberg wrote:

package: homebank
severity: normal

Dear Maintainer,

Please consider to upgrade to the current upstream version of homebank
(5.2.2).

Kind regards,
Jonatan Nyberg

Bug#912183: python-cookies FTBFS with python 3.7 as supported version

[Adrian Bunk]

Source: python-cookies
Version: 2.2.1-1
Severity: serious
Tags: ftbfs buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-cookies.html

...
= test session starts ==
platform linux -- Python 3.7.1, pytest-3.6.4, py-1.6.0, pluggy-0.6.0
rootdir: /build/1st/python-cookies-2.2.1, inifile:
collected 67 items

test_cookies.py  [ 83%]
..F  [100%]

=== FAILURES ===
__ test_encoding_assumptions ___

check_unicode = False

def test_encoding_assumptions(check_unicode=False):
"Document and test assumptions underlying URL encoding scheme"
# Use the RFC 6265 based character class to build a regexp matcher that
# will tell us whether or not a character is okay to put in cookie 
values.
cookie_value_re = re.compile("[%s]" % Definitions.COOKIE_OCTET)
# Figure out which characters are okay. (unichr doesn't exist in Python 
3,
# in Python 2 it shouldn't be an issue)
cookie_value_safe1 = set(chr(i) for i in range(0, 256) \
if cookie_value_re.match(chr(i)))
cookie_value_safe2 = set(unichr(i) for i in range(0, 256) \
if cookie_value_re.match(unichr(i)))
# These two are NOT the same on Python3
assert cookie_value_safe1 == cookie_value_safe2
# Now which of these are quoted by urllib.quote?
# caveat: Python 2.6 crashes if chr(127) is passed to quote and safe="",
# so explicitly set it to b"" to avoid the issue
safe_but_quoted = set(c for c in cookie_value_safe1
  if quote(c, safe=b"") != c)
# Produce a set of characters to give to urllib.quote for the safe parm.
dont_quote = "".join(sorted(safe_but_quoted))
# Make sure it works (and that it works because of what we passed)
for c in dont_quote:
assert quote(c, safe="") != c
assert quote(c, safe=dont_quote) == c

# Make sure that the result of using dont_quote as the safe characters 
for
# urllib.quote produces stuff which is safe as a cookie value, but not
# different unless it has to be.
for i in range(0, 255):
original = chr(i)
quoted = quote(original, safe=dont_quote)
# If it is a valid value for a cookie, that quoting should leave it
# alone.
if cookie_value_re.match(original):
assert original == quoted
# If it isn't a valid value, then the quoted value should be valid.
else:
assert cookie_value_re.match(quoted)

>   assert set(dont_quote) == set("!#$%&'()*+/:<=>?@[]^`{|}~")
E   assert {'!', '#', '$...'&', "'", ...} == {'!', '#', '$'...'&', "'", ...}
E Extra items in the right set:
E '~'
E Use -v to get the full diff

test_cookies.py:2228: AssertionError
= 1 failed, 66 passed in 1.07 seconds ==
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/build/1st/python-cookies-2.2.1/.pybuild/cpython3_3.7_cookies/build; python3.7 
-m pytest 
dh_auto_test: pybuild --test -i python{version} -p "3.7 3.6" returned exit code 
13
make: *** [debian/rules:8: build] Error 25

Bug#912182: python-txaio FTBFS withpython3.7 as supported version

[Adrian Bunk]

Source: python-txaio
Version: 2.8.1-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-txaio.html

...
= test session starts ==
platform linux -- Python 3.7.1, pytest-3.6.4, py-1.6.0, pluggy-0.6.0
rootdir: /build/1st/python-txaio-2.8.1, inifile:
collected 65 items / 5 errors

 ERRORS 
___ ERROR collecting test/test_as_future.py 
/usr/lib/python3/dist-packages/_pytest/python.py:468: in _importtestmodule
mod = self.fspath.pyimport(ensuresyspath=importmode)
/usr/lib/python3/dist-packages/py/_path/local.py:668: in pyimport
__import__(modname)
:983: in _find_and_load
???
:967: in _find_and_load_unlocked
???
:668: in _load_unlocked
???
:638: in _load_backward_compatible
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:226: in load_module
py.builtin.exec_(co, mod.__dict__)
test/test_as_future.py:30: in 
from util import run_once
E File "/build/1st/python-txaio-2.8.1/test/util.py", line 60
E   def await(future):
E   ^
E   SyntaxError: invalid syntax
___ ERROR collecting test/test_call_later.py ___
/usr/lib/python3/dist-packages/_pytest/python.py:468: in _importtestmodule
mod = self.fspath.pyimport(ensuresyspath=importmode)
/usr/lib/python3/dist-packages/py/_path/local.py:668: in pyimport
__import__(modname)
:983: in _find_and_load
???
:967: in _find_and_load_unlocked
???
:668: in _load_unlocked
???
:638: in _load_backward_compatible
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:226: in load_module
py.builtin.exec_(co, mod.__dict__)
test/test_call_later.py:32: in 
from util import run_once
E File "/build/1st/python-txaio-2.8.1/test/util.py", line 60
E   def await(future):
E   ^
E   SyntaxError: invalid syntax
 ERROR collecting test/test_callback.py 
/usr/lib/python3/dist-packages/_pytest/python.py:468: in _importtestmodule
mod = self.fspath.pyimport(ensuresyspath=importmode)
/usr/lib/python3/dist-packages/py/_path/local.py:668: in pyimport
__import__(modname)
:983: in _find_and_load
???
:967: in _find_and_load_unlocked
???
:668: in _load_unlocked
???
:638: in _load_backward_compatible
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:226: in load_module
py.builtin.exec_(co, mod.__dict__)
test/test_callback.py:29: in 
from util import run_once
E File "/build/1st/python-txaio-2.8.1/test/util.py", line 60
E   def await(future):
E   ^
E   SyntaxError: invalid syntax
 ERROR collecting test/test_errback.py _
/usr/lib/python3/dist-packages/_pytest/python.py:468: in _importtestmodule
mod = self.fspath.pyimport(ensuresyspath=importmode)
/usr/lib/python3/dist-packages/py/_path/local.py:668: in pyimport
__import__(modname)
:983: in _find_and_load
???
:967: in _find_and_load_unlocked
???
:668: in _load_unlocked
???
:638: in _load_backward_compatible
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:226: in load_module
py.builtin.exec_(co, mod.__dict__)
test/test_errback.py:29: in 
from util import run_once
E File "/build/1st/python-txaio-2.8.1/test/util.py", line 60
E   def await(future):
E   ^
E   SyntaxError: invalid syntax
_ ERROR collecting test/test_gather.py _
/usr/lib/python3/dist-packages/_pytest/python.py:468: in _importtestmodule
mod = self.fspath.pyimport(ensuresyspath=importmode)
/usr/lib/python3/dist-packages/py/_path/local.py:668: in pyimport
__import__(modname)
E File "/build/1st/python-txaio-2.8.1/test/test_gather.py", line 29
E   from util import await
E^
E   SyntaxError: invalid syntax
=== warnings summary ===
test/test_logging.py::TestHandler
  cannot collect test class 'TestHandler' because it has a __init__ constructor

-- Docs: http://doc.pytest.org/en/latest/warnings.html
!!! Interrupted: 5 errors during collection 
= 1 warnings, 5 error in 1.13 seconds ==
make[1]: *** [debian/rules:16: override_dh_auto_test] Error 2

Bug#911334: Create /dev/ptmx like debootstrap does

[Andreas Beckmann]

Thanks!

ACK


Andreas

Bug#912150: Processed: Joining with the existing scipy bug

[Michael Hudson-Doyle]

FWIW we fixed most of the problems in the scipy/imexam/s390x area on Ubuntu
by building scipy with gfortran-7 rather than gfortran-8 on s390x. AFAIK we
haven't gotten around to working out what it is gfortran-8 is doing wrong
yet.

Bug#912033: bugs.debian.org: Control pseudo-header does not support usertag command

[Don Armstrong]

severity 912033 wishlist
retitle 912033 consider supporting usertag/user in Control: psuedo-header
reassign 912033 debbugs
user debb...@packages.debian.org
usertag 912033 control


On Sat, 27 Oct 2018, Dominik George wrote:
> the user and usertag command are unknown to the BTS when processed from a
> Control pseudo header in regular bug mail:
> 
> > user debian-rele...@lists.debian.org
> Unknown command or malformed arguments to command.
> 
> > usertags -1 + bsp-2018-10-de-karlsruhe
> Unknown command or malformed arguments to command.
> 
> The exact same commands work when mailed directly to control@, though.

That's correct, and is documented: "Allows for any of the commands which
must be sent to cont...@bugs.debian.org to work". That said, I probably
should require usertags to be sent to control, and change how that is
parsed. I haven't yet done so, though.


-- 
Don Armstrong  https://www.donarmstrong.com

[C]haos is found in greatest abundance wherever order is being sought.
It always defeats order, because it is better organized.
 -- Terry Pratchett _Interesting Times_ p4

Bug#911341: libedit2:amd64.symbols is missing -debianversion in version numbers and hence dysfunctional

[Christoph Berg]

Re: Sylvestre Ledru 2018-10-28 

> are you still investigating?

Hi,

I was at PGconf.eu for the last week, will take care over the next
days.

Thanks for the prod,
Christoph

Bug#912181: python-jedi FTBFS: error: [Errno 36] File name too long

[Adrian Bunk]

Source: python-jedi
Version: 0.12.0-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/history/python-jedi.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-jedi.html

...
Copying jedi.egg-info to 
/build/1st/python-jedi-0.12.0/debian/tmp/usr/lib/python3.7/dist-packages/jedi-_Jedi.is.a.static.analysis.tool.for.Python.that.can.be.used.in.IDEs_editors..Its_historic.focus.is.autocompletion_.but.does.static.analysis.for.now.as.well._Jedi.is.fast.and.is.very.well.tested..It.understands.Python.on.a.deeper.level_than.all.other.static.analysis.frameworks.for.Python._Jedi.has.support.for.two.different.goto.functions..It_s.possible.to.search.for_related.names.and.to.list.all.names.in.a.Python.file.and.infer.them..Jedi_understands.docstrings.and.you.can.use.Jedi.autocompletion.in.your.REPL.as_well._Jedi.uses.a.very.simple.API.to.connect.with.IDE_s..There_s.a.reference_implementation.as.a._VIM_Plugin._https_github.com_davidhalter_jedi_vim_which.uses.Jedi_s.autocompletion...We.encourage.you.to.use.Jedi.in.your.IDEs._It_s.really.easy._To.give.you.a.simple.example.how.you.can.use.the.Jedi.library_.here.is.an_example.for.the.autocompletion.feature_.import.jedi_.source._._import.datetime_datetime.da_.script._.jedi.Script_source_.3_.len_datetime.da_._example.py_.script_Script_._example.py_.completions._.script.completions_.completions._doctest_._ELLIPSIS_Completion_.date_._Completion_.datetime__.print_completions_0_.complete_te_.print_completions_0_.name_date_As.you.see.Jedi.is.pretty.simple.and.allows.you.to.concentrate.on.writing.a_good.text.editor_.while.still.having.very.good.IDE.features.for.Python._.egg-info
Skipping SOURCES.txt
error: [Errno 36] File name too long: 
'/build/1st/python-jedi-0.12.0/debian/tmp/usr/lib/python3.7/dist-packages/jedi-_Jedi.is.a.static.analysis.tool.for.Python.that.can.be.used.in.IDEs_editors..Its_historic.focus.is.autocompletion_.but.does.static.analysis.for.now.as.well._Jedi.is.fast.and.is.very.well.tested..It.understands.Python.on.a.deeper.level_than.all.other.static.analysis.frameworks.for.Python._Jedi.has.support.for.two.different.goto.functions..It_s.possible.to.search.for_related.names.and.to.list.all.names.in.a.Python.file.and.infer.them..Jedi_understands.docstrings.and.you.can.use.Jedi.autocompletion.in.your.REPL.as_well._Jedi.uses.a.very.simple.API.to.connect.with.IDE_s..There_s.a.reference_implementation.as.a._VIM_Plugin._https_github.com_davidhalter_jedi_vim_which.uses.Jedi_s.autocompletion...We.encourage.you.to.use.Jedi.in.your.IDEs._It_s.really.easy._To.give.you.a.simple.example.how.you.can.use.the.Jedi.library_.here.is.an_example.for.the.autocompletion.feature_.import.jedi_.source._._import.datetime_datetime.da_.script._.jedi.Script_source_.3_.len_datetime.da_._example.py_.script_Script_._example.py_.completions._.script.completions_.completions._doctest_._ELLIPSIS_Completion_.date_._Completion_.datetime__.print_completions_0_.complete_te_.print_completions_0_.name_date_As.you.see.Jedi.is.pretty.simple.and.allows.you.to.concentrate.on.writing.a_good.text.editor_.while.still.having.very.good.IDE.features.for.Python._.egg-info'
E: pybuild pybuild:338: install: plugin distutils failed with: exit code=1: 
/usr/bin/python3.7 setup.py install --root 
/build/1st/python-jedi-0.12.0/debian/tmp 
dh_auto_install: pybuild --install --test-pytest -i python{version} -p "3.7 
3.6" --dest-dir /build/1st/python-jedi-0.12.0/debian/tmp returned exit code 13
make: *** [debian/rules:6: binary] Error 25

Bug#911867: RFS: frr/6.0.1-1 [ITP]

[Yavor Doganov]

David Lamparter wrote:
> On Sun, Oct 28, 2018 at 06:00:08PM +0200, Yavor Doganov wrote:
> > Hmm, if a shared library does not provide a stable ABI it should not
> > be shipped as public library.
> 
> Good point, done, latest version on mentors uses /usr/lib/$multiarch/frr/
> However, now I have package-has-unnecessary-activation-of-ldconfig-trigger
> to deal with...

This appears to be debhelper #204975.  You can use an override like:

override_dh_makeshlibs:
dh_makeshlibs --noscripts

Bug#912077: libbiod FTBFS on i386: Error: cannot implicitly convert expression

[Andreas Tille]

Control: forwarded -1 https://github.com/biod/BioD/issues/43

Bug#911334: Create /dev/ptmx like debootstrap does

[Mathieu Parent]

Hi Andreas,

Le mer. 24 oct. 2018 à 10:29, Andreas Beckmann  a écrit :
>
> So the underlying problem is
>
> # mkdir foo
> # touch foo/file
> # mknod foo/null c 1 3
> # touch foo/bindmntoverfile
> # mount --bind foo/null foo/bindmntoverfile
> # ls -lis foo
> total 0
> 3857271640 0 crw-r--r-- 1 root root 1, 3 Oct 24 07:50 bindmntoverfile
> 3857120264 0 -rw-r--r-- 1 root root0 Oct 24 07:49 file
> 3857271640 0 crw-r--r-- 1 root root 1, 3 Oct 24 07:50 null
> # find foo -type f -ls
> 3857271640  0 crw-r--r--   1 root root   1,   3 Oct 24 07:50 
> foo/bindmntoverfile
> 3857120264  0 -rw-r--r--   1 root root0 Oct 24 07:49 
> foo/file
>
> please find/file a bug against findutils
>
> and the commit message should not mention debootstrap but
> something like
> """
> p: use mknod instead of touch to create missing /dev/ptmx mountpoint
>
> working around findutils bug #xx
>
> mkdir foo
> mknod foo/null c 1 3
> touch foo/bindmntoverfile
> mount --bind foo/null foo/bindmntoverfile
> find foo -type f -ls
> 3857271640  0 crw-r--r--   1 root root   1,   3 Oct 24 07:50 
> foo/bindmntoverfile
> """

Thanks. I've done the findutils bug (#912180, with even a patch) and
I've updated the MR (see also the attached patch).

If the commit message is too verbose, you can amend it.

Regards
-- 
Mathieu Parent
From a99ecade05aeb855c5e17528403956300ee280c7 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Wed, 17 Oct 2018 04:49:18 +
Subject: [PATCH] p: use mknod instead of touch to create missing /dev/ptmx
 mountpoint (Closes: #911334)

Working around findutils bug #912180:

mkdir foo
mknod foo/null c 1 3
touch foo/bindmntoverfile
mount --bind foo/null foo/bindmntoverfile
find foo -type f -ls
3857271640  0 crw-r--r--   1 root root   1,   3 Oct 24 07:50 foo/bindmntoverfile

When using piuparts on a chroot without /dev/ptmx [noptmx],
scripts/pre_remove_50_find_bad_permissions fails with:

ERROR: BAD PERMISSIONS
crw-rw-rw-. 1 root root 5, 2 Oct 16 03:49 /dev/ptmx

In this case, piuparts does something like this:

touch /dev/ptmx # if not exists
mount -o bind /dev/pts/ptmx /dev/ptmx # if dev/ptmx was not a symlink

The kernel doc [devpts.txt] recommends instead:

mknod /dev/ptmx c 5 2

And this is what debootstrap does [debootstrap].

After this change, piuparts will do:

mknod /dev/ptmx c 5 2 # if not exists
mount -o bind /dev/pts/ptmx /dev/ptmx # if dev/ptmx was not a symlink

The behavior of piuparts called after debootstrap will not change.
The only behavior changing is when dev/ptmx doesn't exist at all.

[noptmx]: This is the case when chroot comes from the debian:unstable Docker image
[devpts.txt]: https://www.kernel.org/doc/Documentation/filesystems/devpts.txt
[debootstrap] https://salsa.debian.org/installer-team/debootstrap/blob/6f3f6f8b76e2d1a24ddbf05f065439412c3b81a1/functions#L1263-1268, introduced by https://salsa.debian.org/installer-team/debootstrap/commit/c997b80c064c6c1d36ec69da1850722f795f43e4
---
 debian/changelog | 4 
 piuparts.py  | 3 +--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 308905e4..1d174cd5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,10 @@ piuparts (0.94) UNRELEASED; urgency=medium
 - Handle /etc/nsswitch.conf stretch -> buster upgrade if modifications
   from libnss-myhostname and friends are present.
 
+  [ Mathieu Parent ]
+  * piuparts.py: Use mknod instead of touch to create missing /dev/ptmx
+mountpoint, working around findutils bug #912180 (Closes: #911334)
+
  -- Holger Levsen   Sun, 21 Oct 2018 14:03:22 +0200
 
 piuparts (0.93) unstable; urgency=medium
diff --git a/piuparts.py b/piuparts.py
index a6279e4e..a8400fb6 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -1755,8 +1755,7 @@ class Chroot:
 dev_ptmx_rel_path = self.relative("dev/ptmx")
 if not os.path.islink(dev_ptmx_rel_path):
 if not os.path.exists(dev_ptmx_rel_path):
-with open(dev_ptmx_rel_path, 'w'):
-pass
+os.mknod(dev_ptmx_rel_path, 0666 | stat.S_IFCHR, os.makedev(5, 2))
 self.mount(self.relative("dev/pts/ptmx"), "/dev/ptmx", opts="bind", no_mkdir=True)
 p = subprocess.Popen(["tty"], stdout=subprocess.PIPE)
 stdout, _ = p.communicate()
-- 
2.11.0

Bug#911836: pytest-localserver: autopkgtest needs update for new version of openssl

[Paul Gevers]

Control: tags -1 ftbfs
Control: severity -1 serious
Control: retitle -1 pytest-localserver: FTBFS & autopkgtest regression

On Thu, 25 Oct 2018 11:52:02 +0200 Paul Gevers  wrote:
> With a recent upload of python3-defaults the autopkgtest of
> pytest-localserver fails in testing when that autopkgtest is run with
> the binary packages of python3-defaults from unstable.

The same error message can now be seen in the build logs on
reproducible-builds [1], hence the severity bump and tags.

Paul

[1]
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pytest-localserver.html



signature.asc
Description: OpenPGP digital signature

Bug#909857: fixed upstream

[Friedrich Beckmann]

tags 909857 + fixed-upstream
thanks

This is fixed upstream in

https://savannah.gnu.org/bugs/?52072 

Bug#912180: find: "-type " wrong on bind-mounted char device

[Mathieu Parent (Debian)]

Package: findutils
Version: 4.6.0+git+20181018-1
Tags: upstream patch
Affects: piuparts
X-Debbugs-CC: Andreas Beckmann 

Hi,

The following testcase [1]:

mkdir foo
mknod foo/null c 1 3
touch foo/bindmntoverfile
mount --bind foo/null foo/bindmntoverfile
find foo -type f -ls
3857271640  0 crw-r--r--   1 root root   1,   3 Oct 24
07:50 foo/bindmntoverfile

i.e "-type f" wrongly matches a char device.

The attached patch fixes this.

Regards

-- 
Mathieu Parent

[1]: Thanks Andreas: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911334#25
From 54684823679197afcaa25d1a2ea136281fd7ca72 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Sun, 28 Oct 2018 21:13:21 +0100
Subject: [PATCH] Ensure type is checked with FTS_NSOK and FTS_NS

Before this patch:
  mkdir foo
  mknod foo/null c 1 3
  touch foo/bindmntoverfile
  mount --bind foo/null foo/bindmntoverfile
  find foo -type f -ls
  3857271640  0 crw-r--r--   1 root root   1,   3 Oct 24 07:50 foo/bindmntoverfile

More info and context at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911334#25
---
 find/ftsfind.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/find/ftsfind.c b/find/ftsfind.c
index f9b03e2..1b9c841 100644
--- a/find/ftsfind.c
+++ b/find/ftsfind.c
@@ -577,7 +577,11 @@ find (char *arg)
 
 	  state.already_issued_stat_error_msg = false;
 	  state.have_stat = false;
-	  state.have_type = !!ent->fts_statp->st_mode;
+	  if (ent->fts_info != FTS_NSOK && ent->fts_info != FTS_NS) {
+	state.have_type = !!ent->fts_statp->st_mode;
+	  } else {
+	state.have_type = false;
+	  }
 	  state.type = state.have_type ? ent->fts_statp->st_mode : 0;
 	  consider_visiting (p, ent);
 	}
-- 
2.11.0

Bug#912179: gbrainy: Bug in problem logic

[Jon Daley]

Package: gbrainy
Version: 2.3.6
Severity: normal

In the logic problem "two men", it describes a pythagorean theorem
problem of two men each walking 8 feet and 6 feet away from each
other, but the solution is incorrect.  It says the answer is that
they end up 10 feet away from each other, but actually, they end
up 10 feet away from their starting point, and 20 feet away
from each other.

-- System Information:
Debian Release: 6.0.10
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

On 2018-09-25 10:15 AM, John David Anglin wrote:

I will test the proposed change once this bug is fixed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909440

I had a successful build of systemd 239-11 with the attached change.  See:
https://buildd.debian.org/status/fetch.php?pkg=systemd=hppa=239-11=1540757105=0

Dave

--
John David Anglin  dave.ang...@bell.net

Index: systemd-239/meson.build
===
--- systemd-239.orig/meson.build
+++ systemd-239/meson.build
@@ -341,7 +341,7 @@ possible_link_flags = [
 # enable it when we are linking against them
 if not fuzzer_build
 possible_cc_flags += '-fPIE'
-possible_link_flags += '-pie'
+possible_link_flags += [ '-fPIE', '-pie', ]
 endif
 
 if cc.get_id() == 'clang'

Bug#912040: lintian: please detect usage of the variable PIUPARTS_TEST in maintainer scripts

[Chris Lamb]

tags 912040 + pending
thanks

Holger Levsen wrote:

> some maintainers seem to want to work around their packages being
> properly being tested by piuparts.debian.org

Ew.

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/47b1aae3bc72229377aaebd7c197427f1b462292

  checks/scripts.desc   | 13 +
  data/scripts/maintainer-script-bad-command|  1 +
  debian/changelog  |  3 +++
  t/tests/scripts-maintainer-general/debian/debian/postinst |  8 
  t/tests/scripts-maintainer-general/desc   |  1 +
  t/tests/scripts-maintainer-general/tags   |  6 ++
  6 files changed, 32 insertions(+)


Regards,

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

Bug#912057: getting winehq's wine-mono to work

[Alexandre Viau]

Hello Jens and Austin,

On 2018-10-28 2:36 p.m., Jens Reyer wrote:
>>> On 28.10.18 01:22, Alexandre Viau wrote:
>> Can you reproduce this?
>>
>>  - rm -rf ~/wine
>>  - wine explorer
>>  - browse c:\\windows\mono
> 
> Tested: No, no mono folder at all.

>> It could be that wine picks-up wine-mono from an unknown location on my
>> system without me noticing...
> 
> Check for ~/.cache/wine/wine-mono-4.7.1.msi.  That will be installed
> automatically and result in a full c:\\windows\mono folder.  You might
> have downloaded it accidentally if you used another Wine (not from
> Debian, where we removed the installer download).

AHH! I did compile wine from upsteam's sources a few times. It must have
downloaded wine-gecko and wine-mono the first time I ran it and
/usr/bin/wine must have picked it up from the cache.

This definitely explains why I couldn't find apps that didn't run
without wine-mono and that ran with it. I **always** has wine-mono
installed when testing.

Thank you!

>>> btw, the command is always "wine" (not wine64 or wine32), e.g. "wine
>>> msiexec /i winemono.msi".  Wine will then figure out internally which
>>> Wine loader to use.  This is true both upstream and in Debian.
>>
>> Sure, I specified wine64 because this is what WineHQ's wiki specifically
>> says so, for 64bit prefixes:
>>  - https://wiki.winehq.org/Mono
>>
>> It also yields totally different results, if we trust wine uninstaller.
>> Note that the .msi is supposed to install both 32 and 64bit versions of
>> mono. It could be that installing it with just wine will install only
>> the 32bit version and skip the 64bit version.
> 
> Ok, that's new to me.  I'd need to look into that more deeply (no
> promise, tell me if you need more help).

Will do. I'll need to re-evaluate these findings since I might get
totally different results now that I removed the wine-mono msi from the
cache. I'll also get back to you on whether or not we need to extend the
addon patch.

On 2018-10-28 2:53 p.m., Austin English wrote:> On Sat, Oct 27, 2018 at
6:22 PM Alexandre Viau  wrote:
>> Does one of you have happen to know an example of a program that does
>> not work using Debian's wine but works when installing the wine-mono
>> .msi at:
>>  - https://dl.winehq.org/wine/wine-mono/ ?
>
> For testing, using a C# hello world is easy:
> austin@debian-desktop:~/debian-mono$ cat hello.cs
> // A Hello World! program in C#.
> using System;
> namespace HelloWorld
> {
> class Hello
> {
> static void Main()
> {
> Console.WriteLine("Hello World!");
> }
> }
> }
>
> # Compile it (needs mono-mcs package):
> $ mcs hello.cs
>
> # Then run it. Without mono:
> austin@debian-desktop:~/debian-mono$ wine-development hello.exe
> 0009:err:mscoree:CLRRuntimeInfo_GetRuntimeHost Wine Mono is not installed
>
> # With mono:
> $ msiexec /i ~/.cache/wine/wine-mono-4.7.1.msi
> ...
> $ austin@debian-desktop:~/debian-mono$ wine-development hello.exe
> Hello World!

This will be helpful, thank you! I had been looking for such an
application for a while, but the fact that wine-mono was installed by
default in my prefixes must have made my research impossible.

On 2018-10-28 3:03 p.m., Jens Reyer wrote:> On 28.10.18 19:53, Austin
English wrote:
>> For testing, using a C# hello world is easy:
> [...]
>
> For completeness, someone else from winehq just told me (and it seems
> they would really be happy to see wine-mono packaged as that would
> ease their support burden

Oh, I'll definitely get this done. It find it very impressive that we
can run dotnet apps without Microsoft's implementation, in Wine. Even if
the number of apps that work with this are limited, I am happy that we
can run them with less proprietary software.

> .NET apps that work with wine-mono are mostly older ones (v2.0). The
> MS Office 2007 and 2010 installers come to mind. (Note that the Office
> 2010 installer doesn't work in current Wine for other reasons.)

I might try them out to confirm that Debian's wine-mono build works fine.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#912178: muttprint: Please add homepage link to d/control

[Petter Reinholdtsen]

Package: muttprint
Version: 0.73-8
Severity: wishlist

Please add a link to the upstream project in d/control, pointing to
http://muttprint.sourceforge.net/ >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#912177: ITP: r-cran-rcmdcheck -- Run 'R CMD check' from 'R' and Capture Results

[Dylan Aïssi]

Package: wnpp
Owner: Dylan Aïssi 
Severity: wishlist

* Package name: r-cran-rcmdcheck
  Version : 1.3.0
  Upstream Author : Mango Solutions, Gábor Csárdi, RStudio
* URL : https://cran.r-project.org/package=rcmdcheck
* License : MIT
  Programming Lang: GNU R
  Description : Run 'R CMD check' from 'R' and Capture Results
 Run 'R CMD check' from 'R' programmatically, and capture the
 results of the individual checks.

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

Bug#912176: biomaj3-core: missing build dependency on python3-requests

[Adrian Bunk]

Source: biomaj3-core
Version: 3.0.14-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/biomaj3-core.html

...
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd 
/build/1st/biomaj3-core-3.0.14/.pybuild/cpython3_3.7_biomaj-core/build; 
python3.7 -m nose -v tests
Failure: ModuleNotFoundError (No module named 'requests') ... ERROR

==
ERROR: Failure: ModuleNotFoundError (No module named 'requests')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 417, in 
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.7/imp.py", line 234, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.7/imp.py", line 171, in load_source
module = _load(spec)
  File "", line 696, in _load
  File "", line 677, in _load_unlocked
  File "", line 728, in exec_module
  File "", line 219, in _call_with_frames_removed
  File 
"/build/1st/biomaj3-core-3.0.14/.pybuild/cpython3_3.7_biomaj-core/build/tests/biomaj_tests.py",
 line 10, in 
from biomaj_core.utils import Utils
  File 
"/build/1st/biomaj3-core-3.0.14/.pybuild/cpython3_3.7_biomaj-core/build/biomaj_core/utils.py",
 line 12, in 
import requests
ModuleNotFoundError: No module named 'requests'

--
Ran 1 test in 0.052s

FAILED (errors=1)
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/build/1st/biomaj3-core-3.0.14/.pybuild/cpython3_3.7_biomaj-core/build; 
python3.7 -m nose -v tests
dh_auto_test: pybuild --test --test-nose -i python{version} -p "3.7 3.6" 
returned exit code 13
make: *** [debian/rules:5: build] Error 25

Bug#912169: stretch-pu: package systemd/232-25+deb9u6

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Sun, 2018-10-28 at 20:09 +0100, Michael Biebl wrote:
> a recently discovered vulnerability allows a malicious dhcp6 server
> to overwrite heap memory in systemd-networkd. This can lead to a
> crash (DoS) of networkd or in worst case a remote code execution [1].
> I was contacted by the security team about this issue. As networkd is
> not enabled by default, it wasn't deemed severe enough to be fixed
> via a stable-security upload and a fix via a regular stable upload
> seemed sufficient.
> I already asked for a stable upload for 9.6 in [2]. I'm not sure what
> the procedure is in such a case. Should I reupload 232-25+deb9u5 with
> this fix included or make a 232-25+deb9u6 upload?

+deb9u5 is already effectively released, as p-u is mirrored and used,
so this would want to be +deb9u6 (once KiBi-acked).

Regards,

Adam

Bug#912174: polymake FTBFS: test failure

[Adrian Bunk]

Source: polymake
Version: 3.2r2-3
Severity: serious
Tags: ftbfs

Some recent change in unstable makes polymake FTBFS:

https://tests.reproducible-builds.org/debian/history/polymake.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/polymake.html

...
*** Failed tests ***

./apps/polytope/src/tensor.cc:61: testcase 1
expected:
=== BEGIN ===
1 1 1 1 1
1 -1 1 -1 1
1 1 -1 1 -1
1 -1 1 1 -1
1 1 1 -1 -1
1 1 -1 -1 1
1 -1 -1 1 1
1 -1 -1 -1 -1
=== END # 1 ===
got:
=== BEGIN ===
1 1 1 1 1
1 -1 -1 -1 -1
1 -1 -1 1 1
1 -1 1 1 -1
1 1 1 -1 -1
1 1 -1 -1 1
1 1 -1 1 -1
1 -1 1 -1 1
=== END # 1 ===

make[2]: *** [debian/rules:41: override_dh_auto_test] Error 1

Bug#912175: RM: ori -- ROM; unmaintained upstream and not fit for release

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


The latest upstream commit is from late 2016 [1]. The RC bug related to openssl 
1.1 has never been addressed [2,3].

regards
Afif


1. https://bitbucket.org/orifs/ori/commits/all
2. https://bugs.debian.org/828481
3. https://bitbucket.org/orifs/ori/issues/22/ftbfs-with-openssl-110

Bug#912170: stretch-pu: package grub2/2.02~beta3-5+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Sun, 2018-10-28 at 19:23 +, Colin Watson wrote:
> I have a couple of patches queued for stretch's grub2 which I think
> are low-risk and worth including: one of the fixed bugs makes it
> difficult to construct GRUB-based netboot environments on arm64, and
> the other makes it impossible to boot on Intel Apollo Lake
> systems.  The proposed debdiff is attached.

This looks OK to me, but will need a KiBi-ack; tagging and CCing
accordingly.

Thanks,

Adam

Bug#897925: Web browsers do not work with armhf

[eHenry Berg]

My KInfocenter shows:
KDE Plasma Verson:  5.13.5
KDE Frameworks Version: 5.49.0
Qt Version: 5.11.2
Kernel Version: 4.18.0-1-armmp
OS Type:32-bit

About Falkon:
Application version 3.0.0
QtWebEngine version 5.11.2

About Konqueror:
Version 5.0.97

I made an apt-get upgrade yesterday and both Falkon and Konqueror
browsers work now! I assume that the upgrade of QtWebEngine from
5.11.1 to 5.11.2 solved the problem.
This bug can therefore be closed.

Bug#912173: ring FTCBFS: multiple reasons

[Helmut Grohne]

Source: ring
Version: 20180816.2.e26b79f~ds1-3
User: helm...@debian.org
Usertags: rebootstrap

ring fails to cross build from source. Actually it simply performs a
native build and breaks when expected dependencies are unavailable. The
attached patch fixes quite a bit of that:

 * daemon/contrib/bootstrap recognizes the standard flags --build and
   --host. However debian/rules does not yet pass them.

 * The Makefile in daemon/contrib somehow insists that pkg-config cannot
   be used during cross building and considers all dependencies as
   needed. That's stupid.

 * The Makefile in daemon/contrib somehow thinks that the
   $(CROSS_COMPILE) prefix only applies to pkg-config when building for
   windows. The prefix is generally useful however. It also insists that
   cross building requires static linking, which is similarly stupid.

 * debian/rules runs cmake and configure manually. Those manual
   invocations lack any cross parameters. Using dh_auto_configure
   simplifies them and makes cross compilation just work.

After applying it, ring still fails to cross build, because it fails
finding symbols from pjproject while linking. The relevant libraries
show up on the linker invocation. I have no clue how to fix that:

| ../doltlibtool  --tag=CXX   --mode=link mips-linux-gnu-g++ -I../src 
-DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/dbus-c++-1 -I/usr/include/dbus-1.0 
-I/usr/lib/mips-linux-gnu/dbus-1.0/include -I../src/dring -DTOP_BUILDDIR=\"$(cd 
".."; pwd)\" -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -DPJ_AUTOCONF=1  
-I/<>/daemon/contrib/mips-linux-gnu/include -DNDEBUG=1  
-Wl,-z,relro -Wl,-z,now -Wl,-Bsymbolic -ldl 
-L/<>/daemon/contrib/mips-linux-gnu/lib -L/usr/lib/mips-linux-gnu 
-ljsoncpp -o dring dring-main.o dbus/libclient_dbus.la 
-L/usr/lib/mips-linux-gnu -ldbus-c++-1 -ldbus-1 ../src/libring.la -ldl -lnatpmp 
-lrestbed  -lssl -lcrypto
| libtool: link: mips-linux-gnu-g++ -I../src -DDBUS_API_SUBJECT_TO_CHANGE 
-I/usr/include/dbus-c++-1 -I/usr/include/dbus-1.0 
-I/usr/lib/mips-linux-gnu/dbus-1.0/include -I../src/dring 
"-DTOP_BUILDDIR=\"/<>/daemon\"" -g -O2 
"-fdebug-prefix-map=/<>=." -fstack-protector-strong -Wformat 
-Werror=format-security -DPJ_AUTOCONF=1 
"-I/<>/daemon/contrib/mips-linux-gnu/include" -DNDEBUG=1 -Wl,-z 
-Wl,relro -Wl,-z -Wl,now -Wl,-Bsymbolic -o dring dring-main.o  
-L/<>/daemon/contrib/mips-linux-gnu/lib -L/usr/lib/mips-linux-gnu 
dbus/.libs/libclient_dbus.a -ldbus-c++-1 -ldbus-1 ../src/.libs/libring.a 
-lpjsua2-mips-unknown-linux-gnu -lpjsua-mips-unknown-linux-gnu 
-lpjsip-ua-mips-unknown-linux-gnu -lpjsip-simple-mips-unknown-linux-gnu 
-lpjsip-mips-unknown-linux-gnu -lpjmedia-codec-mips-unknown-linux-gnu 
-lpjmedia-videodev-mips-unknown-linux-gnu 
-lpjmedia-audiodev-mips-unknown-linux-gnu -lpjmedia-mips-unknown-linux-gnu 
-lpjnath-mips-unknown-linux-gnu -lpjlib-util-mips-unknown-linux-gnu 
-lsrtp-mips-unknown-linux-gnu -lpj-mips-unknown-linux-gnu -lopus -luuid -lrt 
-lpthread -lasound -lpulse -lyaml-cpp -lupnp -lthreadutil -lixml -lopendht 
-lnettle -lgnutls -largon2 -lsecp256k1 -lz -lpcre -lavfilter -lswresample 
-lspeexdsp -ljsoncpp -lavcodec -lavformat -lavdevice -lswscale -lavutil -ludev 
-lX11 -lvdpau -lva-drm -lva-x11 -lva -ldl -lnatpmp -lrestbed -lssl -lcrypto 
-pthread
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 
../src/.libs/libring.a(libsiplink_la-sipcall.o): in function 
`ring::SIPCall::getDetails[abi:cxx11]() const':
| ./daemon/src/sip/sipcall.cpp:1125: undefined reference to `pj_ssl_cipher_name'
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 
./daemon/src/sip/sipcall.cpp:1127: undefined reference to `pj_ssl_cipher_name'
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 
../src/.libs/libring.a(libsiplink_la-sipaccount.o): in function 
`ring::SIPAccount::trimCiphers()':
| ./daemon/src/sip/sipaccount.cpp:1154: undefined reference to 
`pj_ssl_cipher_name'
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 
./daemon/src/sip/sipaccount.cpp:1154: undefined reference to 
`pj_ssl_cipher_name'
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 
../src/.libs/libring.a(libsiplink_la-sipaccount.o): in function 
`ring::SIPAccount::initTlsConfiguration()':
| ./daemon/src/sip/sipaccount.cpp:1170: undefined reference to 
`pj_ssl_cipher_get_availables'
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 
./daemon/src/sip/sipaccount.cpp:1170: undefined reference to 
`pj_ssl_cipher_get_availables'
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 
./daemon/src/sip/sipaccount.cpp:1181: undefined reference to `pj_ssl_cipher_id'
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 
./daemon/src/sip/sipaccount.cpp:1181: undefined reference to `pj_ssl_cipher_id'
| /usr/lib/gcc-cross/mips-linux-gnu/8/../../../../mips-linux-gnu/bin/ld: 

Bug#912172: RM: pyqwt3d -- NBS; Package updated to Python3, Qt5

[Gudjon I. Gudjonsson]

Package: ftp.debian.org
Severity: normal

Bug#907372: needrestart: complains about microcode updates on systems with microcode for multiple CPUs in initramfs

[Thomas Liske]

tags 907372 upstream
thanks


Hi Paul,

Paul Wise  writes:

> Package: needrestart
> Version: 3.3-1
> Severity: normal
> File: /usr/lib/needrestart/iucode-scan-versions
>
> I have a system that changes between two different CPUs occasionally.
> I have a system that boots a different computer at almost every boot.
>
> To get the right microcode loaded, both turn off CPU scanning:
>
> /etc/default/intel-microcode:
> IUCODE_TOOL_SCANCPUS=no
>
> The first one also restricts installed microcode to the used CPUs:
>
> /etc/default/intel-microcode:
> IUCODE_TOOL_EXTRA_OPTIONS="-s 0x000X,0xXX -s 0x000X,0xXX"

I fear that this code path (using -s in IUCODE_TOOL_EXTRA_OPTIONS) is
hardly tested. For the beginning could you please provide the output of
the following commands:

cat /sys/devices/system/cpu/cpu0/microcode/version
sh -x /usr/lib/needrestart/iucode-scan-versions


Thanks,
Thomas

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#910227: installation-reports: installation on DELL XPS 13 9370

[Samuel Thibault]

Hello,

Samuel Thibault, le dim. 28 oct. 2018 20:22:52 +0100, a ecrit:
> Samuel Thibault, le mer. 03 oct. 2018 19:07:38 +0200, a ecrit:
> > samy, le mer. 03 oct. 2018 18:51:32 +0200, a ecrit:
> > > One problem, however, is that since laptop has a HiDPI screen. The font 
> > > used by
> > > console-setup is far from being big enough, see bug 816111 about this. I 
> > > manage
> > > to read it but I have good eyes, most people won't be able to read it.
> > 
> > And it's the same in graphical mode, the fonts are extremely tiny (and
> > the banner at the top is very compressed).
> > 
> > I have attached photos of what it looks like (sorry it's so awful, but
> > you get the idea).
> 
> I'll commit a fix to debian-installer to keep the 800x600 resolution
> from the grub menu.

I propose to include this in stretch too, because on 4K laptops the
current debian installer is hardly usable (I can myself hardly read the
text).

Samuel
commit 78c74a9d53e5f929bac8921ed02ef39a6bb84a3d
Author: Samuel Thibault 
Date:   Sun Oct 28 20:27:54 2018 +0100

Keep grub resolution in EFI boot, to avoid tiny fonts (closes: #910227)

diff --git a/build/boot/hurd/grub-hurd-cdrom.cfg 
b/build/boot/hurd/grub-hurd-cdrom.cfg
index d6a25c7a6..31ecfa3eb 100644
--- a/build/boot/hurd/grub-hurd-cdrom.cfg
+++ b/build/boot/hurd/grub-hurd-cdrom.cfg
@@ -12,6 +12,7 @@ insmod chain
 
 if loadfont /boot/grub/font.pf2 ; then
set gfxmode=640x480
+   set gfxpayload=keep
insmod vbe
insmod gfxterm
terminal_output gfxterm
diff --git a/build/boot/hurd/grub-hurd-pxe.cfg 
b/build/boot/hurd/grub-hurd-pxe.cfg
index 6f9d274d8..045a2629f 100644
--- a/build/boot/hurd/grub-hurd-pxe.cfg
+++ b/build/boot/hurd/grub-hurd-pxe.cfg
@@ -3,6 +3,7 @@ set timeout=-1
 
 if loadfont $prefix/font.pf2 ; then
set gfxmode=640x480
+   set gfxpayload=keep
insmod vbe
insmod gfxterm
terminal_output gfxterm
diff --git a/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg 
b/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg
index db3b592ba..30c11d25d 100644
--- a/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg
+++ b/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg
@@ -12,6 +12,7 @@ insmod chain
 
 if loadfont /boot/grub/font.pf2 ; then
set gfxmode=640x480
+   set gfxpayload=keep
insmod vbe
insmod gfxterm
terminal_output gfxterm
diff --git a/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg 
b/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
index c2108f22a..bc4b72e64 100644
--- a/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
+++ b/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
@@ -3,6 +3,7 @@ set timeout=-1
 
 if loadfont $prefix/font.pf2 ; then
set gfxmode=640x480
+   set gfxpayload=keep
insmod vbe
insmod gfxterm
terminal_output gfxterm
diff --git a/build/boot/x86/grub/grub-efi.cfg b/build/boot/x86/grub/grub-efi.cfg
index 7ddbcafd6..9fe5563c1 100644
--- a/build/boot/x86/grub/grub-efi.cfg
+++ b/build/boot/x86/grub/grub-efi.cfg
@@ -1,5 +1,6 @@
 if loadfont $prefix/font.pf2 ; then
   set gfxmode=800x600
+  set gfxpayload=keep
   insmod efi_gop
   insmod efi_uga
   insmod video_bochs
diff --git a/debian/changelog b/debian/changelog
index 27de9a63d..c29a28318 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -26,6 +26,9 @@ debian-installer (20180622) UNRELEASED; urgency=medium
   [ Karsten Merker ]
   * Add basic riscv64 support.
 
+  [ Samuel Thibault ]
+  * Keep grub resolution in EFI boot, to avoid tiny fonts (closes: #910227).
+
  -- Andreas B. Mundt   Fri, 22 Jun 2018 17:25:42 +0200
 
 debian-installer (20180610) unstable; urgency=medium

Bug#759176: v1 instead of v0

[Jeffrey Cliff]

any hope of getting v1 instead of v0 packaged?  Or would that be a separate
issue?

Jeff Cliff

Bug#912171: pcsxr: Cannot configure/use 2nd joypad

[Alessandro Grassi]

Package: pcsxr
Version: 1.9.94-4
Severity: normal
Tags: patch

Dear Maintainer,

when pcsxr is started with two USB joypads connected, it is not possible to 
configure
them (the configuration window does not open). With only one joypad,
everything works fine.
I tracked the cause to the /pcsxr/plugins/dfinput/cfg-gtk.c file at line 610:

sprintf(buf, "%d: %s", j + 1, SDL_JoystickName(j));

The call to SDL_JoystickName() was correct with SDL 1.2, but it is not anymore
with SDL 2. In fact, in the upstream code I find this code instead of that 
single line:

#if SDL_VERSION_ATLEAST(2, 0, 0)
SDL_Joystick *joystick = SDL_JoystickOpen(j);
sprintf(buf, "%d: %s", j + 1, SDL_JoystickName(joystick));
#else
sprintf(buf, "%d: %s", j + 1, SDL_JoystickName(j));
#endif

By replacing with this code and recompiling the package, the problem is solved.


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

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

Versions of packages pcsxr depends on:
ii  libc6   2.27-5
ii  libgdk-pixbuf2.0-0  2.36.12-1
ii  libgl1  1.0.0+git20180308-3
ii  libglib2.0-02.58.1-2
ii  libgtk-3-0  3.24.0-3
ii  libpango-1.0-0  1.42.4-3
ii  libsdl2-2.0-0   2.0.8+dfsg1-1+b1
ii  libx11-62:1.6.5-1
ii  libxext62:1.3.3-1+b2
ii  libxtst62:1.2.3-1
ii  libxv1  2:1.0.11-1
ii  libxxf86vm1 1:1.1.4-1+b2
ii  zlib1g  1:1.2.11.dfsg-1

pcsxr recommends no packages.

pcsxr suggests no packages.

-- no debconf information

Bug#910227: installation-reports: installation on DELL XPS 13 9370

[Samuel Thibault]

Control: retitle -1 unreadably tiny fonts in installer
Control: reassign -1 debian-installer

Samuel Thibault, le mer. 03 oct. 2018 19:07:38 +0200, a ecrit:
> samy, le mer. 03 oct. 2018 18:51:32 +0200, a ecrit:
> > One problem, however, is that since laptop has a HiDPI screen. The font 
> > used by
> > console-setup is far from being big enough, see bug 816111 about this. I 
> > manage
> > to read it but I have good eyes, most people won't be able to read it.
> 
> And it's the same in graphical mode, the fonts are extremely tiny (and
> the banner at the top is very compressed).
> 
> I have attached photos of what it looks like (sorry it's so awful, but
> you get the idea).

I'll commit a fix to debian-installer to keep the 800x600 resolution
from the grub menu.

Samuel

Bug#796795: grub-pc-bin: Please use a bigger font

[Samuel Thibault]

Samuel Thibault, le lun. 08 oct. 2018 20:34:36 +0200, a ecrit:
> Samuel Thibault, le lun. 24 août 2015 18:00:40 +0200, a ecrit:
> > Screen DPI (at last!) gets bigger, and thus the font currently used by
> > grub becomes too small, making it very hard to read the boot menu.
> 
> I now have a HiDPI display, and the font is now simply unreadable.

Perhaps grub should just do by default what we do in the installer:

set gfxmode=800x600
set gfxpayload=keep

or perhaps 1024x768.

Samuel

Bug#912170: stretch-pu: package grub2/2.02~beta3-5+deb9u1

[Colin Watson]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I have a couple of patches queued for stretch's grub2 which I think are
low-risk and worth including: one of the fixed bugs makes it difficult
to construct GRUB-based netboot environments on arm64, and the other
makes it impossible to boot on Intel Apollo Lake systems.  The proposed
debdiff is attached.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
diff -Nru grub2-2.02~beta3/debian/.git-dpm grub2-2.02~beta3/debian/.git-dpm
--- grub2-2.02~beta3/debian/.git-dpm2017-02-11 15:03:45.0 +
+++ grub2-2.02~beta3/debian/.git-dpm2018-10-28 19:16:13.0 +
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-9bf24c661aac96f62a7aef6ee41da4ca5ccf9b7a
-9bf24c661aac96f62a7aef6ee41da4ca5ccf9b7a
+f088c5a77750ef243888de09fd8cc979da9244bb
+f088c5a77750ef243888de09fd8cc979da9244bb
 422889f9199d539926099fc5c1ceeeda51ab7f53
 422889f9199d539926099fc5c1ceeeda51ab7f53
 grub2_2.02~beta3.orig.tar.xz
diff -Nru grub2-2.02~beta3/debian/changelog grub2-2.02~beta3/debian/changelog
--- grub2-2.02~beta3/debian/changelog   2017-02-11 15:09:19.0 +
+++ grub2-2.02~beta3/debian/changelog   2018-10-28 19:18:13.0 +
@@ -1,3 +1,11 @@
+grub2 (2.02~beta3-5+deb9u1) stable; urgency=medium
+
+  * grub-mknetdir: Add support for ARM64 EFI (closes: #871772).
+  * Cherry-pick upstream patch to change the default TSC calibration method
+to pmtimer on EFI systems (closes: #908852).
+
+ -- Colin Watson   Sun, 28 Oct 2018 19:18:13 +
+
 grub2 (2.02~beta3-5) unstable; urgency=medium
 
   [ Steve McIntyre ]
diff -Nru grub2-2.02~beta3/debian/patches/mknetdir_arm64.patch 
grub2-2.02~beta3/debian/patches/mknetdir_arm64.patch
--- grub2-2.02~beta3/debian/patches/mknetdir_arm64.patch1970-01-01 
01:00:00.0 +0100
+++ grub2-2.02~beta3/debian/patches/mknetdir_arm64.patch2018-10-28 
19:16:13.0 +
@@ -0,0 +1,28 @@
+From 17c207ea005d5faaff9224d3aee34c0ee705a07d Mon Sep 17 00:00:00 2001
+From: Dirk Mueller 
+Date: Tue, 11 Oct 2016 22:19:02 +0200
+Subject: grub-mknetdir: Add support for ARM64 EFI
+
+Origin: upstream, 
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0d663b50b9abf830fd10de384606a0632a605b77
+Bug-Debian: https://bugs.debian.org/871772
+Last-Update: 2017-08-26
+
+Patch-Name: mknetdir_arm64.patch
+---
+ util/grub-mknetdir.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/util/grub-mknetdir.c b/util/grub-mknetdir.c
+index 3813e8bc0..82073d5cc 100644
+--- a/util/grub-mknetdir.c
 b/util/grub-mknetdir.c
+@@ -106,7 +106,8 @@ static const struct
+ [GRUB_INSTALL_PLATFORM_I386_EFI] = { "i386-efi", "efinet", ".efi" },
+ [GRUB_INSTALL_PLATFORM_X86_64_EFI] = { "x86_64-efi", "efinet", ".efi" },
+ [GRUB_INSTALL_PLATFORM_IA64_EFI] = { "ia64-efi", "efinet", ".efi" },
+-[GRUB_INSTALL_PLATFORM_ARM_EFI] = { "arm-efi", "efinet", ".efi" }
++[GRUB_INSTALL_PLATFORM_ARM_EFI] = { "arm-efi", "efinet", ".efi" },
++[GRUB_INSTALL_PLATFORM_ARM64_EFI] = { "arm64-efi", "efinet", ".efi" }
+   };
+ 
+ static void
diff -Nru grub2-2.02~beta3/debian/patches/series 
grub2-2.02~beta3/debian/patches/series
--- grub2-2.02~beta3/debian/patches/series  2017-02-11 15:03:45.0 
+
+++ grub2-2.02~beta3/debian/patches/series  2018-10-28 19:16:13.0 
+
@@ -57,3 +57,5 @@
 efinet_set_network_from_uefi_devpath.patch
 efinet_set_dns_from_uefi_proto.patch
 grub-install-efibootmgr-check.patch
+mknetdir_arm64.patch
+tsc_efi_default_to_pmtimer.patch
diff -Nru grub2-2.02~beta3/debian/patches/tsc_efi_default_to_pmtimer.patch 
grub2-2.02~beta3/debian/patches/tsc_efi_default_to_pmtimer.patch
--- grub2-2.02~beta3/debian/patches/tsc_efi_default_to_pmtimer.patch
1970-01-01 01:00:00.0 +0100
+++ grub2-2.02~beta3/debian/patches/tsc_efi_default_to_pmtimer.patch
2018-10-28 19:16:13.0 +
@@ -0,0 +1,34 @@
+From f088c5a77750ef243888de09fd8cc979da9244bb Mon Sep 17 00:00:00 2001
+From: "David E. Box" 
+Date: Fri, 15 Sep 2017 15:37:05 -0700
+Subject: tsc: Change default tsc calibration method to pmtimer on EFI systems
+
+On efi systems, make pmtimer based tsc calibration the default over the
+pit. This prevents Grub from hanging on Intel SoC systems that power gate
+the pit.
+
+Signed-off-by: David E. Box 
+Reviewed-by: Daniel Kiper 
+
+Origin: upstream, 
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=446794de8da4329ea532cbee4ca877bcafd0e534
+Bug-Debian: https://bugs.debian.org/883193
+Last-Update: 2018-10-28
+
+Patch-Name: tsc_efi_default_to_pmtimer.patch
+---
+ grub-core/kern/i386/tsc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
+index 2e85289d8..f266eb131 100644
+--- a/grub-core/kern/i386/tsc.c
 b/grub-core/kern/i386/tsc.c
+@@ -68,7 +68,7 @@ grub_tsc_init (void)
+ #ifdef 

Bug#903119: needrestart lists both gdm and gdm3

[Thomas Liske]

tags 903119 upstream moreinfo
thanks


Hi Laurent,

Laurent Bigonville  writes:

> Package: needrestart
> Version: 3.3-1
> Severity: normal
>
> Hi,
>
> needrestart lists both gdm and gdm3 when proposing the services to
> restart
>
> gdm3.service is a symlink to gdm.service to mask the gdm3 initscript. So
> it seems that needrestart gets confused by these symlinks

since it uses systemd to look for the service names I did not expect such
behavoir. Could you please provide the output of `needrestart -vr l`
reporting both services?


Thanks,
Thomas

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#906958: needrestart: Complains when the microcode is newer than what Debian has

[Thomas Liske]

tags 906958 upstream fixed-upstream
thanks


Hi Maik,


Maik Zumstrull  writes:

> Package: needrestart
> Version: 3.3-1
>
> On this box, needrestart gives this message:
>
> The currently running processor microcode revision is 0x20 which is
> not the expected microcode revision 0x1f.
>
> Unless I'm misunderstanding the versioning scheme, this release is
> newer than what intel-microcode 3.20180703.2 ships. It's uploaded to
> the CPU pre-boot thanks to a mainboard firmware update.
>
> The check should probably be adjusted to warn about versions smaller
> than what's available from the OS, not just different.

I've patched upstream to parse and compare the revision hex strings as
numbers so this case is handled as up-to-date.


Regards,
Thomas


-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#912169: stretch-pu: package systemd/232-25+deb9u6

[Michael Biebl]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

a recently discovered vulnerability allows a malicious dhcp6 server
to overwrite heap memory in systemd-networkd. This can lead to a crash
(DoS) of networkd or in worst case a remote code execution [1].
I was contacted by the security team about this issue. As networkd is
not enabled by default, it wasn't deemed severe enough to be fixed via a
stable-security upload and a fix via a regular stable upload seemed
sufficient.
I already asked for a stable upload for 9.6 in [2]. I'm not sure what
the procedure is in such a case. Should I reupload 232-25+deb9u5 with
this fix included or make a 232-25+deb9u6 upload?
Assuming the latter is less work for the SRM team, I prepared a debdiff
for 232-25+deb9u6.
Please let me know, what you prefer and how to proceed here.

I've also CCed kibi, as usual, for his ack. Since this only touches
networkd, d-i should not be affected.

The fix has also been uploaded to unstable a few hours ago, so hasn't
seen any real world testing. But given that it's only a one-line change,
the regression potential is rather small.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912008
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908913

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 740787b..176bb0f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+systemd (232-25+deb9u6) stretch; urgency=medium
+
+  * dhcp6: Make sure we have enough space for the DHCP6 option header.
+Fixes out-of-bounds heap write in systemd-networkd dhcpv6 option
+handling.
+(CVE-2018-15688, LP: #1795921, Closes: #912008)
+
+ -- Michael Biebl   Sun, 28 Oct 2018 18:02:10 +0100
+
 systemd (232-25+deb9u5) stretch; urgency=medium
 
   * networkd: Do not fail manager_connect_bus() if dbus is not active yet
diff --git 
a/debian/patches/dhcp6-make-sure-we-have-enough-space-for-the-DHCP6-option.patch
 
b/debian/patches/dhcp6-make-sure-we-have-enough-space-for-the-DHCP6-option.patch
new file mode 100644
index 000..3a4ee04
--- /dev/null
+++ 
b/debian/patches/dhcp6-make-sure-we-have-enough-space-for-the-DHCP6-option.patch
@@ -0,0 +1,29 @@
+From: Lennart Poettering 
+Date: Fri, 19 Oct 2018 12:12:33 +0200
+Subject: dhcp6: make sure we have enough space for the DHCP6 option header
+
+Fixes a vulnerability originally discovered by Felix Wilhelm from
+Google.
+
+CVE-2018-15688
+LP: #1795921
+https://bugzilla.redhat.com/show_bug.cgi?id=1639067
+
+(cherry picked from commit 4dac5eaba4e419b29c97da38a8b1f82336c2c892)
+---
+ src/libsystemd-network/dhcp6-option.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/libsystemd-network/dhcp6-option.c 
b/src/libsystemd-network/dhcp6-option.c
+index 5462e03..c12d008 100644
+--- a/src/libsystemd-network/dhcp6-option.c
 b/src/libsystemd-network/dhcp6-option.c
+@@ -101,7 +101,7 @@ int dhcp6_option_append_ia(uint8_t **buf, size_t *buflen, 
DHCP6IA *ia) {
+ return -EINVAL;
+ }
+ 
+-if (*buflen < len)
++if (*buflen < offsetof(DHCP6Option, data) + len)
+ return -ENOBUFS;
+ 
+ ia_hdr = *buf;
diff --git a/debian/patches/series b/debian/patches/series
index 3c1ebbe..605f8cb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -85,6 +85,7 @@ 
login-change-variable-type-of-enable_wall_messages-as-it-.patch
 login-do-not-wall-message-on-cancelling-shutdown-when-Man.patch
 networkd-do-not-fail-manager_connect_bus-if-dbus-is-not-a.patch
 network-resolve-remove-comments-related-to-kdbus.patch
+dhcp6-make-sure-we-have-enough-space-for-the-DHCP6-option.patch
 debian/Use-Debian-specific-config-files.patch
 debian/don-t-try-to-start-autovt-units-when-not-running-wit.patch
 debian/Make-logind-hostnamed-localed-timedated-D-Bus-activa.patch

Bug#912057: getting winehq's wine-mono to work

[Jens Reyer]

On 28.10.18 19:53, Austin English wrote:
> For testing, using a C# hello world is easy:
[...]

For completeness, someone else from winehq just told me (and it seems
they would really be happy to see wine-mono packaged as that would ease
their support burden):

.NET apps that work with wine-mono are mostly older ones (v2.0). The MS
Office 2007 and 2010 installers come to mind. (Note that the Office 2010
installer doesn't work in current Wine for other reasons.)

Bug#912057: getting winehq's wine-mono to work

[Austin English]

On Sat, Oct 27, 2018 at 6:22 PM Alexandre Viau  wrote:
>
> Hello,
>
> Before further work on packaging wine-mono, I wanted to get winehq's
> wine-mono build to work.

Great!

> Does one of you have happen to know an example of a program that does
> not work using Debian's wine but works when installing the wine-mono
> .msi at:
>  - https://dl.winehq.org/wine/wine-mono/ ?

For testing, using a C# hello world is easy:
austin@debian-desktop:~/debian-mono$ cat hello.cs
// A Hello World! program in C#.
using System;
namespace HelloWorld
{
class Hello
{
static void Main()
{
Console.WriteLine("Hello World!");
}
}
}

# Compile it (needs mono-mcs package):
$ mcs hello.cs

# Then run it. Without mono:
austin@debian-desktop:~/debian-mono$ wine-development hello.exe
0009:err:mscoree:CLRRuntimeInfo_GetRuntimeHost Wine Mono is not installed

# With mono:
$ msiexec /i ~/.cache/wine/wine-mono-4.7.1.msi
...
$ austin@debian-desktop:~/debian-mono$ wine-development hello.exe
Hello World!

I do know that there are some mono apps that works, but I don't have a
list handy. Keep in mind though that if the app is moderately complex,
it likely will run into a mono limitation.

> I have been trying to find an example for a while now, without success.
> Most installers that I have tried do not detect dotnet as already
> installed and claim it is missing.

Yeah, it's missing a lot of functionality compared to native..

> Also, I notice that C:\\windows\mono exists in prefixes by default, even
> when wine-mono is not installed. That is expected?

I don't think so. I just tried in a self compiled wine upstream, then
I cancelled the gecko/mono installs. There's no C:\windows\mono.

-- 
-Austin
GPG: 267B CC1F 053F 0749 (expires 2021/02/18)

Bug#912168: node-marked breaks node-marked-man autopkgtest

[Paul Gevers]

Source: node-marked, node-marked-man
Control: found -1 node-marked/0.5.1+dfsg-1
Control: found -1 node-marked-man/0.3.0-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of node-marked the autopkgtest of node-marked-man
fails in testing when that autopkgtest is run with the binary packages
of node-marked from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
node-markedfrom testing0.5.1+dfsg-1
node-marked-manfrom testing0.3.0-2
all others from testingfrom testing

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

Currently this regression is contributing to the delay of the migration
of node-marked to testing [1]. Due to the nature of this issue, I filed
this bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

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

Paul

[1] https://qa.debian.org/excuses.php?package=node-marked

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-marked-man/1217246/log.gz
autopkgtest [15:11:44]: test command1: nodejs test/compare.js 2>&1
autopkgtest [15:11:44]: test command1: [---
Test failure, result written in
/tmp/autopkgtest-lxc.5tk1t2ff/downtmp/build.vNp/src/test/man/links.err
Test failure, result written in
/tmp/autopkgtest-lxc.5tk1t2ff/downtmp/build.vNp/src/test/man/markdown_syntax.err
Test failure, result written in
/tmp/autopkgtest-lxc.5tk1t2ff/downtmp/build.vNp/src/test/man/table.err
Test failure, result written in
/tmp/autopkgtest-lxc.5tk1t2ff/downtmp/build.vNp/src/test/man/underline_spacing_test.err
Test failure, result written in
/tmp/autopkgtest-lxc.5tk1t2ff/downtmp/build.vNp/src/test/out/links.err
Test failure, result written in
/tmp/autopkgtest-lxc.5tk1t2ff/downtmp/build.vNp/src/test/out/markdown_syntax.err
Test failure, result written in
/tmp/autopkgtest-lxc.5tk1t2ff/downtmp/build.vNp/src/test/out/underline_spacing_test.err
:173: warning [p 1, 2.0i, div `3tbd17,3', 0.0i]: cannot
adjust line
:272: warning [p 1, 2.0i, div `3tbd28,3', 0.2i]: cannot
adjust line
:671: warning [p 1, 2.0i, div `3tbd73,0', 0.0i]: cannot
adjust line
warning: file `', around line 18:
  table wider than line width
warning: file `', around line 13:
  table squeezed horizontally to fit line length

Test failure, result written in
/tmp/autopkgtest-lxc.5tk1t2ff/downtmp/build.vNp/src/test/out/table.err
Failed tests:  4
Succeeded tests:  8
autopkgtest [15:11:45]: test command1: ---]




signature.asc
Description: OpenPGP digital signature

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Colin Watson]

On Sun, Oct 28, 2018 at 11:41:14AM +0100, Bernhard Übelacker wrote:
> Now it takes some time until that line "random: crng init done"
> appears in dmesg.
> With logging in in the qemu window this line appears just after a
> few seconds, when just trying via ssh it takes much longer.
> 
> 
> I tried to find out where it blocks exactly and came to that location:
> 
> #0  0x7fb515b1803a in getentropy (buffer=0x56285633d440, 
> length=length@entry=32) at ../sysdeps/unix/sysv/linux/getentropy.c:45
> #1  0x7fb5161e3603 in syscall_random (buflen=32, buf=) at 
> ../crypto/rand/rand_unix.c:277
> #2  rand_pool_acquire_entropy (pool=pool@entry=0x5628563394e0) at 
> ../crypto/rand/rand_unix.c:469
> #3  0x7fb5161e2d8d in rand_drbg_get_entropy (drbg=0x562856339e80, 
> pout=0x7ffd1c2bce60, entropy=, min_len=, 
> max_len=, prediction_resistance=0) at ../crypt$
> #4  0x7fb5161e11b2 in RAND_DRBG_instantiate 
> (drbg=drbg@entry=0x562856339e80, pers=pers@entry=0x7fb516289d20 
>  "OpenSSL NIST SP 800-90A DRBG", perslen=perslen@entry=28) 
> at ../crypto/$
> #5  0x7fb5161e21a8 in drbg_setup (parent=parent@entry=0x0) at 
> ../crypto/rand/drbg_lib.c:870
> #6  0x7fb5161e222f in do_rand_drbg_init () at 
> ../crypto/rand/drbg_lib.c:899
> #7  do_rand_drbg_init_ossl_ () at ../crypto/rand/drbg_lib.c:884
> #8  0x7fb5150c9827 in __pthread_once_slow (once_control=0x7fb5163118f8 
> , init_routine=0x7fb5161e21d0 ) at 
> pthread_once.c:116
> #9  0x7fb5150c98e5 in __GI___pthread_once 
> (once_control=once_control@entry=0x7fb5163118f8 , 
> init_routine=init_routine@entry=0x7fb5161e21d0 ) at 
> pthread_once.$
> #10 0x7fb516221329 in CRYPTO_THREAD_run_once 
> (once=once@entry=0x7fb5163118f8 , 
> init=init@entry=0x7fb5161e21d0 ) at 
> ../crypto/threads_pthread.c:113
> #11 0x7fb5161e2327 in RAND_DRBG_get0_master () at 
> ../crypto/rand/drbg_lib.c:1010
> #12 0x7fb5161e235d in drbg_status () at ../crypto/rand/drbg_lib.c:992
> #13 0x5628556a253f in seed_rng () at ../../entropy.c:238
> #14 0x56285564b13c in main (ac=2, av=0x56285631b970) at ../../sshd.c:1696
> 
> Most of the stack is inside /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
> e.g libssl1.1 that got also a new upload at that time.

Thanks for the investigation.  (Note also that the OpenSSH version in
question is the one that switched from OpenSSL 1.0 to 1.1, which was a
big change.)

There were some significant changes in this area in OpenSSL 1.1.1.
Would it be possible to try running OpenSSH with OpenSSL 1.1.0h to see
if that makes a difference?  Unfortunately this is a little complicated
as it will require doing a local build of the Debian OpenSSH source
package in order to reduce the dependency; let me know if you need help
with setting this up.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#912057: getting winehq's wine-mono to work

[Jens Reyer]

On 28.10.18 18:45, Alexandre Viau wrote:
> On 2018-10-28 12:49 p.m., Jens Reyer wrote:
>> great to see you working on wine-mono (although personally I never
>> needed it).
> 
> Is this because you use Microsoft's proprietary implementation?

I don't use Wine very often, and the apps that I use it for, just don't
require it.  Last time I needed it, it was for Adobe Digital Editions -
back then I used the proprietary solution (iirc wine-mono didn't work
for it, not sure).


>> On 28.10.18 01:22, Alexandre Viau wrote:
>>> Also, I notice that C:\\windows\mono exists in prefixes by default, even
>>> when wine-mono is not installed. That is expected?
>>
>> I've seen empty gecko/mono folders before, but didn't worry/investigate.
> 
> Mono's folder is full, however. It contains many .exes and .dlls.
> 
> Can you reproduce this?
> 
>  - rm -rf ~/wine
>  - wine explorer
>  - browse c:\\windows\mono

Tested: No, no mono folder at all.


> It could be that wine picks-up wine-mono from an unknown location on my
> system without me noticing...

Check for ~/.cache/wine/wine-mono-4.7.1.msi.  That will be installed
automatically and result in a full c:\\windows\mono folder.  You might
have downloaded it accidentally if you used another Wine (not from
Debian, where we removed the installer download).

All search paths (see the gecko and mono entries in our Debian.readme):
- /usr/share/wine-mono/
- /usr/share/wine-development/mono/ (only if you are using wine-development)
- /usr/share/wine/mono
- $XDG_CACHE_HOME/wine/
- $HOME/.cache/wine/ (if XDG_CACHE_HOME is not set)



>>> On a side note, Wine has a feature that installs mono automatically when
>>> it is in /usr/share/wine-development/mono. However it checks for shasums
>>> and exact filenames so we will probably have to patch it in Debian.
>>> (dlls/appwiz.cpl/addons.c). That said, it shouldn't prevent us from
>>> installing it manually with ``wine64 msiexec /i winemono.msi``.
>>
>> When I worked on disable/addons-download.patch I figured that the
>> checksums are only checked if the wine-gecko/mono installer is loaded
>> from home, but not when loaded from /usr/share.  That's what I put into
>> README.debian.  Please verify.
> 
> I'll verify when I get to that. I read it quickly and never really
> managed to get it installed from /usr/share, but before I jump to the
> conclusion that it didn't work, I want to find a reliable way to test
> whether or not wine-mono is installed.
> 
> Looking at wine uninstaller isn't enough as it produces results that are
> hard to explain, like mono/gecko showing as present even when they were
> not installed.

Ok, I haven't looked into this more deeply.  Make sure you don't have
mono/gecko installed accidentally, see above.
Which Wine are you using?



>> btw, the command is always "wine" (not wine64 or wine32), e.g. "wine
>> msiexec /i winemono.msi".  Wine will then figure out internally which
>> Wine loader to use.  This is true both upstream and in Debian.
> 
> Sure, I specified wine64 because this is what WineHQ's wiki specifically
> says so, for 64bit prefixes:
>  - https://wiki.winehq.org/Mono
> 
> It also yields totally different results, if we trust wine uninstaller.
> Note that the .msi is supposed to install both 32 and 64bit versions of
> mono. It could be that installing it with just wine will install only
> the 32bit version and skip the 64bit version.

Ok, that's new to me.  I'd need to look into that more deeply (no
promise, tell me if you need more help).

Greets
jre

Bug#880245: New version of statsmodels is out possibly fixing important bug - any volunteer

[Andreas Tille]

Hi Julian,

On Sat, Oct 27, 2018 at 06:05:39PM +0200, Julian Taylor wrote:
> I have pushed an update to git that fixes the build for me and filed
> https://github.com/statsmodels/statsmodels/pull/5348 for the problem.

I've uploaded statsmodels 0.9.0-1 to experimental.  No idea whether we
might need a formal transition or whether we simply should upload to
unstable and "see what happens with dependencies".  I'd welcome if
maintaniers with rdepends would give it a try and decide what might be
the best strategy.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#818850: developers-reference: Join the two chapters about the 'default' field

[Holger Wansing]

Control: tags -1 - pending


Maintainers, what do you think about
https://salsa.debian.org/debian/developers-reference/merge_requests/8/diffs to 
fix this bug?

Any objections against me merging this?

BTW: I'm removing the pending tag for now, since this is not yet committed 
(at least not to master)



Holger


-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#912016: liborcus: Please package the tools

[Rene Engelhard]

On Sun, Oct 28, 2018 at 06:25:25PM +0100, Rene Engelhard wrote:
> > Can you please consider packaging these tools?
> 
> And have 1 month waiting time in NEW? :(
> Had that with libetonyek lately...

Uploaded (as said, will be in NEW)

Regards,
 
Rene

Bug#912167: dpuser FTBFS on arm64: Segmentation fault

[Adrian Bunk]

Source: dpuser
Version: 3.3+p1+dfsg-2
Severity: serious
Tags: ftbfs

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

...
Executing selfmade procedure # 6
>>> "addquad" exists already as stored function!
>>> "factorial" exists already as stored function!
>>> "cropdata" exists already as stored function!
***
CONGRATULATIONS: All tests were successful!
***
DPUSER> fgrep -q CONGRATULATIONS test.log
make[1]: Leaving directory '/build/1st/dpuser-3.3+p1+dfsg'
 fakeroot debian/rules binary
dh  binary
   dh_testroot
   dh_prep
   dh_install
   debian/rules override_dh_installdocs
make[1]: Entering directory '/build/1st/dpuser-3.3+p1+dfsg'
cd dpuser/doc && echo @makehelp.dpuser | ../../dpuser/dpuser
     _   _   _   
|  _ \|  _ \| | | / ___|| |  _ \ 
| | | | |_) | | | \___ \|  _| | |_) |
| |_| |  __/| |_| |___) | |___|  _ < 
|/|_|\___/|/|_|_| \_\ - The Next Generation 3.3
Rev. 
Written since 1999 by Thomas Ott
Inspired by the original MPE dp_user speckle data reduction software
 
For basic information, type "help" at the DPUSER> prompt.
Online documentation available at: http://www.mpe.mpg.de/~ott/dpuser
230 functions registered.
99 procedures registered.
126 pgplot procedures registered.
DPUSER> @makehelp.dpuser
Segmentation fault
make[1]: *** [debian/rules:20: override_dh_installdocs] Error 139

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[tony mancill]

owner 911732 tmanc...@debian.org
thanks

Hi All,

The backport to stretch-backports is trivial - I only have to downgrade
debhelper from 11 to 10 to build against stretch - and so I plan to do
the bpo upload once 0.14.0-2 hits testing.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#912166: libiio FTBFS on i386: python3: can't open file 'obj-i386-linux-gnu/bindings/python/setup.py'

[Adrian Bunk]

Source: libiio
Version: 0.15-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libiio=i386=0.15-3=1539190371=0

...
make[4]: Leaving directory '/<>/obj-i686-linux-gnu'
[100%] Built target iiod
make[3]: Leaving directory '/<>/obj-i686-linux-gnu'
/usr/bin/cmake -E cmake_progress_start 
/<>/obj-i686-linux-gnu/CMakeFiles 0
make[2]: Leaving directory '/<>/obj-i686-linux-gnu'
python3 obj-i386-linux-gnu/bindings/python/setup.py build
python3: can't open file 'obj-i386-linux-gnu/bindings/python/setup.py': [Errno 
2] No such file or directory
make[1]: *** [debian/rules:13: override_dh_auto_build] Error 2

Bug#911867: RFS: frr/6.0.1-1 [ITP]

[Vincent Bernat]

 ❦ 27 octobre 2018 14:54 +0200, David Lamparter :

> The lib is an integral part of a FRRouting version;  the daemons and the
> .so must match up.  As noted above on the symbols file, the .so version
> is not currently used since the ABI is not stable.  The "0" does not
> convey any useful information.

Look how the Quagga package is done: libs are shipped in
/usr/lib/quagga. If the build system didn't change too much, it should
be quite easy to do the same thing with FRR.
-- 
Debian package sponsoring guidelines:
 https://vincent.bernat.im/en/debian-package-sponsoring


signature.asc
Description: PGP signature

Bug#911867: RFS: frr/6.0.1-1 [ITP]

[David Lamparter]

On Sun, Oct 28, 2018 at 06:00:08PM +0200, Yavor Doganov wrote:
> David Lamparter wrote:
> > Symbols files are only applicable to libraries providing a stable ABI.
> > This is explicitly not the case for FRRouting (hence also the 0.0.0
> > .so version.)
> 
> Hmm, if a shared library does not provide a stable ABI it should not
> be shipped as public library.  Please consider installing it at
> /usr/lib/frr or something similar.  That way, you won't clutter
> /usr/lib, your package will be compliant with Policy and as a bonus
> you'd get rid of the (legitimate) lintian warnings.

Good point, done, latest version on mentors uses /usr/lib/$multiarch/frr/
However, now I have package-has-unnecessary-activation-of-ldconfig-trigger
to deal with...


-David

Bug#912165: File /etc/vim/vimrc is outdated

[Corcodel Marian]

Package: vim-common
Version: 2:8.0.0197-4+deb9u1
Severity: minor

 Follows variable set defaults on $VIMRUNTIME/defaults.vim  exist also on
 /etc/vim/vimrc:

 if ("autocmd")
   filetype plugin intend on
 endif

 au BufReadPost /jump already on last position when reopening vim.
  

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

Kernel: Linux 4.19.0+ (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vim-common depends on:
ii  xxd  2:8.0.0197-4+deb9u1

Versions of packages vim-common recommends:
ii  vim   2:8.0.0197-4+deb9u1
ii  vim-tiny  2:8.0.0197-4+deb9u1

vim-common suggests no packages.

-- no debconf information

Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient

[Sean Whitton]

Hello,

On Sun 28 Oct 2018 at 04:04PM GMT, Niels Thykier wrote:

>> Well, more specifically debhelper.
>>
>
> FTR, I would be happy if the solution was not specific to "debhelper" in
> the long term.  In particular, there is a world of difference between
> "debhelper", "cdbs with debhelper", "dh-style debhelper", and
> "dhmk-style debhelper".

Indeed, but the shading will get a lot less useful if it merely
indicates that there is /some/ common tool that implements the
requirement.  We probably want to restrict the shading to dh-style
debhelper.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#188731: debian-policy: "strip --strip-unneeded" is insufficient

[Sean Whitton]

control: tag -1 -patch +pending

Hello,

On Sun 28 Oct 2018 at 03:51PM GMT, Niels Thykier wrote:

>>  .. [#]
>> -   You might also want to use the options ``--remove-section=.comment``
>> -   and ``--remove-section=.note`` on both shared libraries and
>> -   executables, and ``--strip-debug`` on static libraries.
>> +   You might also want to use the option ``--strip-debug`` on static
>> +   libraries.
>>
>
> For static libraries, you want to use --strip-debug *instead* of
> --strip-unneeded (as opposed to "also" as the text implies) AFAICT.  At
> least, debhelper always used --strip-debug without --strip-unneeded on
> static libraries.
>
> Note that for static libraries, it might be prudent to remind people to
> use "-D" / "--enable-deterministic-archives" to ensure a deterministic
> result (and thereby comply with the policy's recommendation to support
> reproducible builds).

I've updated the footnote.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#911341: libedit2:amd64.symbols is missing -debianversion in version numbers and hence dysfunctional

[Sylvestre Ledru]

Myon,

Le 18/10/2018 à 22:19, Sylvestre Ledru a écrit :
> Le 18/10/2018 à 22:12, Christoph Berg a écrit :
>> Source: libedit
>> Version: 3.1-20180525-1
>> Severity: serious
>>
>> Hi,
>>
>> IRC user ikcalB just reported missing "append_history" symbol in
>> /usr/lib/postgresql/10/bin/psql when installing postgresql-10 from
>> buster on stretch. The problem goes away when libedit2 is upgraded to
>> the buster version.

are you still investigating?

Thanks
S

Bug#912057: getting winehq's wine-mono to work

[Alexandre Viau]

On 2018-10-28 12:49 p.m., Jens Reyer wrote:
> great to see you working on wine-mono (although personally I never
> needed it).

Is this because you use Microsoft's proprietary implementation?

> I guess you'll put this under the wine-team umbrella?

That would be my plan, yes.

> On 28.10.18 01:22, Alexandre Viau wrote:
>> Also, I notice that C:\\windows\mono exists in prefixes by default, even
>> when wine-mono is not installed. That is expected?
> 
> I've seen empty gecko/mono folders before, but didn't worry/investigate.

Mono's folder is full, however. It contains many .exes and .dlls.

Can you reproduce this?

 - rm -rf ~/wine
 - wine explorer
 - browse c:\\windows\mono

It could be that wine picks-up wine-mono from an unknown location on my
system without me noticing...

>> On a side note, Wine has a feature that installs mono automatically when
>> it is in /usr/share/wine-development/mono. However it checks for shasums
>> and exact filenames so we will probably have to patch it in Debian.
>> (dlls/appwiz.cpl/addons.c). That said, it shouldn't prevent us from
>> installing it manually with ``wine64 msiexec /i winemono.msi``.
> 
> When I worked on disable/addons-download.patch I figured that the
> checksums are only checked if the wine-gecko/mono installer is loaded
> from home, but not when loaded from /usr/share.  That's what I put into
> README.debian.  Please verify.

I'll verify when I get to that. I read it quickly and never really
managed to get it installed from /usr/share, but before I jump to the
conclusion that it didn't work, I want to find a reliable way to test
whether or not wine-mono is installed.

Looking at wine uninstaller isn't enough as it produces results that are
hard to explain, like mono/gecko showing as present even when they were
not installed.

> btw, the command is always "wine" (not wine64 or wine32), e.g. "wine
> msiexec /i winemono.msi".  Wine will then figure out internally which
> Wine loader to use.  This is true both upstream and in Debian.

Sure, I specified wine64 because this is what WineHQ's wiki specifically
says so, for 64bit prefixes:
 - https://wiki.winehq.org/Mono

It also yields totally different results, if we trust wine uninstaller.
Note that the .msi is supposed to install both 32 and 64bit versions of
mono. It could be that installing it with just wine will install only
the 32bit version and skip the 64bit version.

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature