Bug#874307: Correction

[Daniel Haid]

Can you show "systemctl status openvpn-server@first.service" and
"systemctl status openvpn-server@second.service", both before and after
the restart?

Actually, the whole directory seems to be removed as it gets a new
inode number. Note that first I have to completely restart "first"
and then restart "second".

This is the complete sequence of commands I ran, including the
requested information.

# ls -di /run/openvpn-server
13067 /run/openvpn-server

# ls /run/openvpn-server
status-first.log  status-second.log

# systemctl status openvpn-server@first.service
● openvpn-server@first.service - OpenVPN service for first
   Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Tue 2017-10-10 05:42:12 UTC; 54s ago
 Docs: man:openvpn(8)
   https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
   https://community.openvpn.net/openvpn/wiki/HOWTO
 Main PID: 1361 (openvpn)
   Status: "Initialization Sequence Completed"
Tasks: 1 (limit: 4915)
   CGroup: 
/system.slice/system-openvpn\x2dserver.slice/openvpn-server@first.service
   └─1361 /usr/sbin/openvpn --status 
/run/openvpn-server/status-first.log --status-version 2 --suppress-timestamps 
--config first.conf

Oct 10 05:42:12 box openvpn[1361]: WARNING: --keepalive option is missing from 
server config
Oct 10 05:42:12 box openvpn[1361]: NOTE: the current --script-security setting 
may allow this configuration to call user-defined scripts
Oct 10 05:42:12 box openvpn[1361]: TUN/TAP device tap9 opened
Oct 10 05:42:12 box openvpn[1361]: Could not determine IPv4/IPv6 protocol. 
Using AF_INET
Oct 10 05:42:12 box openvpn[1361]: UDPv4 link local (bound): 
[AF_INET][undef]:12345
Oct 10 05:42:12 box openvpn[1361]: UDPv4 link remote: [AF_UNSPEC]
Oct 10 05:42:12 box openvpn[1361]: GID set to nogroup
Oct 10 05:42:12 box systemd[1]: Started OpenVPN service for first.
Oct 10 05:42:12 box openvpn[1361]: UID set to nobody
Oct 10 05:42:12 box openvpn[1361]: Initialization Sequence Completed

# systemctl status openvpn-server@second.service
● openvpn-server@second.service - OpenVPN service for second
   Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Tue 2017-10-10 05:42:22 UTC; 3min 49s ago
 Docs: man:openvpn(8)
   https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
   https://community.openvpn.net/openvpn/wiki/HOWTO
 Main PID: 1407 (openvpn)
   Status: "Initialization Sequence Completed"
Tasks: 1 (limit: 4915)
   CGroup: 
/system.slice/system-openvpn\x2dserver.slice/openvpn-server@second.service
   └─1407 /usr/sbin/openvpn --status 
/run/openvpn-server/status-second.log --status-version 2 --suppress-timestamps 
--config second.conf

Oct 10 05:42:22 box openvpn[1407]: WARNING: --keepalive option is missing from 
server config
Oct 10 05:42:22 box openvpn[1407]: NOTE: the current --script-security setting 
may allow this configuration to call user-defined scripts
Oct 10 05:42:22 box openvpn[1407]: TUN/TAP device tap8 opened
Oct 10 05:42:22 box openvpn[1407]: Could not determine IPv4/IPv6 protocol. 
Using AF_INET
Oct 10 05:42:22 box openvpn[1407]: UDPv4 link local (bound): 
[AF_INET][undef]:12346
Oct 10 05:42:22 box openvpn[1407]: UDPv4 link remote: [AF_UNSPEC]
Oct 10 05:42:22 box openvpn[1407]: GID set to nogroup
Oct 10 05:42:22 box openvpn[1407]: UID set to nobody
Oct 10 05:42:22 box openvpn[1407]: Initialization Sequence Completed
Oct 10 05:42:22 box systemd[1]: Started OpenVPN service for second.

# systemctl restart openvpn-server@first

# systemctl restart openvpn-server@second

# ls -di /run/openvpn-server
20235 /run/openvpn-server

# ls /run/openvpn-server
status-second.log

# systemctl status openvpn-server@first.service
● openvpn-server@first.service - OpenVPN service for first
   Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Tue 2017-10-10 05:47:01 UTC; 3min 46s ago
 Docs: man:openvpn(8)
   https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
   https://community.openvpn.net/openvpn/wiki/HOWTO
 Main PID: 1488 (openvpn)
   Status: "Initialization Sequence Completed"
Tasks: 1 (limit: 4915)
   CGroup: 
/system.slice/system-openvpn\x2dserver.slice/openvpn-server@first.service
   └─1488 /usr/sbin/openvpn --status 
/run/openvpn-server/status-first.log --status-version 2 --suppress-timestamps 
--config first.conf

Oct 10 05:47:01 box openvpn[1488]: WARNING: --keepalive option is missing from 
server config
Oct 10 05:47:01 box openvpn[1488]: NOTE: the current --script-security setting 
may allow this configuration to call user-defined scripts
Oct 10 05:47:01 box openvpn[1488]: TUN/TAP device tap9 opened
Oct 10 05:47:01 box openvpn[1488]: Could not determine IPv4/IPv6 protocol. 
Using AF_INET
Oct 10 05:47:01 box openvpn[1488]: UDPv4 

Bug#821194: [PATCH] avoid segfault on exit

[Petter Reinholdtsen]

This issue block the build of slic3r on hurd.  Did anyone have a chance
to check out the patch yet?

-- 
Happy hacking
Petter Reinholdtsen

Bug#877461: Re : [nore...@release.debian.org: logol is marked for autoremoval from testing]

[Olivier Sallou]

Sure, will do. 
Logol optionally depends on drmaa
Can work without functionally, but need jar as dependency.

Have always been the case, so i wobder if at some time there was some changes 
in libdrmaa-java. Anyway, will look soon.

- Andreas Tille  a écrit :
> Hi Olivier,
> 
> could you please care (as I said logol was moved to Git) and
> at least one part of the bug report is fixed
> 
> ANdreas.
> 
> - Forwarded message from Debian testing autoremoval watch 
>  -
> 
> Date: Tue, 10 Oct 2017 04:39:10 +
> From: Debian testing autoremoval watch 
> To: lo...@packages.debian.org
> Subject: logol is marked for autoremoval from testing
> 
> logol 1.7.5-1 is marked for autoremoval from testing on 2017-10-31
> 
> It is affected by these RC bugs:
> 877461: logol: broken symlinks: /usr/share/logol/lib/{activation,drmaa}.jar 
> -> ../../java/*.jar
> 
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 
> 
> - End forwarded message -
> 
> -- 
> http://fam-tille.de

Bug#873628: systemd: Apparent regression on #825394, logind.conf accepts upstream default of KillUserProcesses=yes

[intrigeri]

Control: fixed -1 234-3

Hi,

Felipe Sateler:
> This has already been fixed in git[1] but not yet uploaded. It should be
> part of the next upload.

> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=6bd0dab41

It's now been uploaded (234-3) but apparently debian/changelog missed
the required "Closes: #nn".

Thanks!

Cheers,
-- 
intrigeri

Bug#878103: Pending fixes for bugs in the maven-debian-helper package

[pkg-java-maintainers]

tag 878103 + pending
thanks

Some bugs in the maven-debian-helper package are closed in revision
26335a5583f7f827290050f8711ba40c47f3601d in branch 'master' by
Christopher Hoskin

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/maven-debian-helper.git/commit/?id=26335a5

Commit message:

Team upload.

* Team upload.
* Fix "Wrong package name for -doc packages" use unless instead of &&
  (Closes: #878103)

Bug#764730: dh_systemd_start: un-escapes - in unit/directory names

[Niels Thykier]

Control: reopen -1

Bernd Zeimetz:
> Hi Niels,
> 
>> I may have accidentally fixed as a side effect of another change in
>> debhelper/10.7.  Can you please check whether this bug has been fixed in
>> 10.7 (or later)?
> 
> well, I've put a second workaround in place since then ;)
> https://github.com/bzed/pkg-open-vm-tools/commit/bf07ae8dbb38731dde932b64dcdf31c8f49ed595
> 
> It is esacped once now, but there are no '' around the unit
> name when it is called in the maintainer scripts, so it is
> unescaped once by the shell and then we have a normal x as
> result.
> 
> So I think the fix you've done is correct, but the maintainer
> script generation still needs to be fixed.
> 
> Thanks for your work,
> 
> Bernd
> 
> 

Thanks for testing. :)

I have reopened it and will look at the autoscript soon. :)

Thanks,
~Niels

Bug#877687: pidgin: (xmpp) checks wrong certificate when connecting to explicit server

[Richard Hector]

On 07/10/17 13:15, Ari Pollak wrote:
> Are you sure this isn't intended behavior? Why should pidgin trust the
> hostname on a certificate just because it matches the ID? If anything,
> it seems like having that behavior for a SRV record would be a bug.

I'm pretty sure it's supposed to match the cert to the id.

https://wiki.xmpp.org/web/Securing_XMPP
https://prosody.im/doc/certificates (Which domain? - note the
VirtualHosts in prosody are for the domains your ids are in)

The SRV record could be viewed similarly to a CNAME record for a
website, where they server may use name-based virtual hosting (with SNI)
- the website cert needs to match what the browser asks for in the GET
request, and it could have found the ip address from a CNAME chain, or a
hosts file entry or anything.

I realise now the title, at least, is decidedly misleading. It should
probably say "... checks the certificate against the wrong domain ..."

Richard

Bug#878115: plymouthd: random crash (SIGSEGV) during shutdown for reboot

[Paul Wise]

Package: plymouth
Version: 0.9.3-1
Severity: normal
File: /sbin/plymouthd
Usertags: crash

During the shutdown process for rebooting I got a random crash
(SIGSEGV) of the plymouthd process. If the below information isn't
useful, please close this bug report.

Here is the systemd journal log for the crash:

Oct 09 09:51:44 chianamo systemd[1]: plymouth-reboot.service: Failed with 
result 'core-dump'.
Oct 09 09:51:44 chianamo systemd[1]: plymouth-reboot.service: Unit entered 
failed state.
Oct 09 09:51:44 chianamo systemd[1]: Failed to start Show Plymouth Reboot 
Screen.
Oct 09 09:51:44 chianamo systemd[1]: plymouth-reboot.service: Main process 
exited, code=dumped, status=11/SEGV
Oct 09 09:51:44 chianamo plymouth[25859]: error: unexpectedly disconnected from 
boot status daemon

Here is the gdb backtrace for the crash:

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core /var/crash/0/25858-0-0-11-1507513903-chianamo--sbin-plymouthd.core 
/sbin/plymouthd
[New LWP 25858]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `@sbin/plymouthd --mode=shutdown --attach-to-session'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
#0  0x7f061f7b1676 in strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7f061f7b13ae in __GI___strdup (s=0x0) at strdup.c:41
#2  0x7f061fadcfb0 in ply_renderer_load_plugin (module_path=0x7f061fae12b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so", renderer=0x5561e1c6da60) 
at ply-renderer.c:160
#3  0x7f061fadcfb0 in ply_renderer_open_plugin (plugin_path=0x7f061fae12b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so", renderer=0x5561e1c6da60) 
at ply-renderer.c:238
#4  0x7f061fadcfb0 in ply_renderer_open 
(renderer=renderer@entry=0x5561e1c6da60) at ply-renderer.c:281
#5  0x7f061fad4b82 in create_devices_for_terminal_and_renderer_type 
(manager=0x5561e1c6c440, device_path=0x0, terminal=0x5561e1c6c4e0, 
renderer_type=PLY_RENDERER_TYPE_AUTO) at ply-device-manager.c:683
#6  0x5561e013453b in load_devices 
(flags=PLY_DEVICE_MANAGER_FLAGS_IGNORE_UDEV, state=0x7fff545ebed0) at 
main.c:1130
#7  0x5561e013453b in main (argc=3, argv=0x7fff545ed0b8) at main.c:2368

Thread 1 (Thread 0x7f06200e9b80 (LWP 25858)):
#0  0x7f061f7b1676 in strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7f061f7b13ae in __GI___strdup (s=0x0) at strdup.c:41
len = 
new = 
#2  0x7f061fadcfb0 in ply_renderer_load_plugin (module_path=0x7f061fae12b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so", renderer=0x5561e1c6da60) 
at ply-renderer.c:160
get_renderer_backend_interface = 
i = 
known_plugins = {{type = PLY_RENDERER_TYPE_X11, path = 0x7f061fae12b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so"}, {type = 
PLY_RENDERER_TYPE_DRM, path = 0x7f061fae12f0 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so"}, {type = 
PLY_RENDERER_TYPE_FRAME_BUFFER, path = 0x7f061fae1328 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so"}, {type = 
PLY_RENDERER_TYPE_NONE, path = 0x0}}
__func__ = "ply_renderer_open"
#3  0x7f061fadcfb0 in ply_renderer_open_plugin (plugin_path=0x7f061fae12b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so", renderer=0x5561e1c6da60) 
at ply-renderer.c:238
i = 
known_plugins = {{type = PLY_RENDERER_TYPE_X11, path = 0x7f061fae12b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so"}, {type = 
PLY_RENDERER_TYPE_DRM, path = 0x7f061fae12f0 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so"}, {type = 
PLY_RENDERER_TYPE_FRAME_BUFFER, path = 0x7f061fae1328 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so"}, {type = 
PLY_RENDERER_TYPE_NONE, path = 0x0}}
__func__ = "ply_renderer_open"
#4  0x7f061fadcfb0 in ply_renderer_open 
(renderer=renderer@entry=0x5561e1c6da60) at ply-renderer.c:281
i = 
known_plugins = {{type = PLY_RENDERER_TYPE_X11, path = 0x7f061fae12b8 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/x11.so"}, {type = 
PLY_RENDERER_TYPE_DRM, path = 0x7f061fae12f0 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so"}, {type = 
PLY_RENDERER_TYPE_FRAME_BUFFER, path = 0x7f061fae1328 
"/usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so"}, {type = 
PLY_RENDERER_TYPE_NONE, path = 0x0}}
__func__ = "ply_renderer_open"
#5  0x7f061fad4b82 in create_devices_for_terminal_and_renderer_type 
(manager=0x5561e1c6c440, device_path=0x0, terminal=0x5561e1c6c4e0, 
renderer_type=PLY_RENDERER_TYPE_AUTO) at ply-device-manager.c:683
old_renderer = 0x0
renderer = 0x5561e1c6da60
keyboard = 0x0
__func__ = "create_devices_for_terminal_and_renderer_type"
#6  0x5561e013453b in load_devices 
(flags=PLY_DEVICE_MANAGER_FLAGS_IGNORE_UDEV, 

Bug#878114: racket: Print Definitions does not work, creates empty pages instead

[James Lu]

Package: racket
Version: 6.10.1+dfsg1-1

Dear maintainer,

I recently noticed that the "Print Definitions" option in Racket does
not work, and creates empty files instead. Regardless of the printer I
pick (I tried GTK's "Print to File", cups-pdf, and my physical printer's
Preview), the only output I get is empty page(s).

I've attached a sample .rkt file and the PDF file I got when trying to
print it.

Best,
James


test.pdf
Description: Adobe PDF document
;; The first three lines of this file were inserted by DrRacket. They record 
metadata
;; about the language level of this file in a form that our tools can easily 
process.
#reader(lib "htdp-beginner-reader.ss" "lang")((modname test) 
(read-case-sensitive #t) (teachpacks ()) (htdp-settings #(#t constructor 
repeating-decimal #f #t none #f () #f)))
; this is a comment
(define abc 123)

signature.asc
Description: OpenPGP digital signature

Bug#878105: release-notes: problems building the release-notes (jessie) for the Debian website

[victory]

On Mon, 09 Oct 2017 22:44:15 +0200
Laura Arjona Reina wrote:

> Those errors appear for any architecture except armel and any language, for 
> the
> jessie release notes.
> file jessie/en/whats-new.dbk
> 
>   
> Support for iop32x was dropped
> 
>   
> On armel, support for
> the iop32x subarchitecture was dropped. Other
> armel subarchitectures
> continue to be supported, including ixp4xx, kirkwood, orion
> and versatile.
>   
> 
>   
> 

> file jessie/en/installing.dbk
> 
...
> 
...
> 

instead of adding useless item for old distribution,
maybe 

works for jessie?

-- 
victory
no need to CC me :-)

Bug#258096: REPLY

[GIDEON JARIKRE]

 - This mail is in HTML. Some elements may be ommited in plain text. -

Hello Sir/Ma
I am Mr.Gideon Jarikre from Providus bank Plc, i called your phone yesterday as 
i was mandated to call you in regards to your fund but i could not get you on 
phone as the phone number failed to connect. If you are able to read this 
message pls reply with your name in full, address and phone number, so we can 
email you full information and genuine reasons for contacting you.
Mr.Gideon Jarikre

Bug#878111: sparkleshare: Switch to webkit2

[Jeremy Bicha]

I tweaked the changelog entry in the second patch.

Thanks,
Jeremy Bicha
From dfd1c1919d2b2f648234c6e766fbf46585317224 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Mon, 9 Oct 2017 19:28:21 -0400
Subject: [PATCH 2/2] releasing package sparkleshare version 1.5.0-2.1

---
 debian/changelog | 12 
 1 file changed, 12 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 6bf13e5..413a11d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+sparkleshare (1.5.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add 06-move_to_webkit2.patch:
+- Cherry-picked patch borrowed from Fedora 27 to use the supported
+  webkit2gtk library (Closes: #878111)
+  * debian/control:
+- Build-depend on libwebkit2-sharp-4.0-cil-dev instead of
+  libwebkitgtk3.0-cil-dev
+
+ -- Jeremy Bicha   Mon, 09 Oct 2017 18:47:08 -0400
+
 sparkleshare (1.5.0-2) unstable; urgency=medium
 
   * Fetch updates from the upstream's master branch.
-- 
2.14.1

Bug#878113: cabal-install hangs after "hGetContents: invalid argument (invalid byte sequence)"

[Ximin Luo]

Package: cabal-install
Version: 1.24.0.2-2
Severity: important

Dear Maintainer,

| $ /usr/bin/cabal install cabal
| ghc: fd:12: hGetContents: invalid argument (invalid byte sequence)
| ^C
| 130

| $ /usr/bin/cabal install cabal --verbose
| /usr/bin/alex --version
| /usr/bin/gcc -dumpversion
| looking for tool haddock near compiler in /usr/bin
| found haddock in /usr/bin/haddock
| /usr/bin/haddock --version
| /usr/bin/happy --version
| /usr/bin/hpc version
| looking for tool hsc2hs near compiler in /usr/bin
| found hsc2hs in /usr/bin/hsc2hs
| /usr/bin/hsc2hs --version
| /usr/bin/ghc -hide-all-packages -c /tmp/16816927771714636915.c -o 
/tmp/1957747793424238335.o
| ghc: fd:12: hGetContents: invalid argument (invalid byte sequence)
| ^C
| 130

After some googling, I found [1] and [2], which helped me figure out a 
work-around:

| $ LC_ALL=en_US.iso88591 /usr/bin/cabal install cabal-install
| Resolving dependencies...
| Downloading Cabal-2.0.0.2...
| Downloading base16-bytestring-0.1.1.6...
| Configuring base16-bytestring-0.1.1.6...
| [..]
| Installed cabal-install-2.0.0.0

Obviously this isn't ideal since the user should be able to see error messages
in their own language.

[1] https://github.com/koalaman/shellcheck/issues/324
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786781

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

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

Versions of packages cabal-install depends on:
ii  ghc   8.0.2-10
ii  libc6 2.24-17
ii  libffi6   3.2.1-6
ii  libgmp10  2:6.1.2+dfsg-1
ii  zlib1g1:1.2.8.dfsg-5

cabal-install recommends no packages.

cabal-install suggests no packages.

-- no debconf information

Bug#878112: ghc-mod: Could not find $libexecdir/cabal-helper-wrapper

[Ximin Luo]

Package: ghc-mod
Version: 5.7.0.0-1
Severity: normal
Tags: patch

Dear Maintainer,

| $ ghc-mod debug
| ghc-mod: ghc-mod: Could not find $libexecdir/cabal-helper-wrapper
| 
| If you are a developer set the environment variable
| `cabal_helper_libexecdir' to override $libexecdir[..]

It seems that users should not have to do this, perhaps a configure flag is
missing from the Debian packaging?

As a temporary workaround this works:

| $ export cabal_helper_libexecdir=/usr/lib
| $ ghc-mod debug
| Version:  ghc-mod-5.7.0.0
| Library GHC Version:  8.0.2
| System GHC Version:   8.0.2
| [..]

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

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

Versions of packages ghc-mod depends on:
ii  cabal-helper  0.7.3.0-2+b1
ii  ghc   8.0.2-10
ii  libc6 2.24-17
ii  libffi6   3.2.1-6
ii  libgmp10  2:6.1.2+dfsg-1

Versions of packages ghc-mod recommends:
ii  ghc-mod-el  5.7.0.0-1

ghc-mod suggests no packages.

-- no debconf information

Bug#878111: sparkleshare: Switch to webkit2

[Jeremy Bicha]

From 4dd627bc9f4539796f1a8b162f0578efd16af67e Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Mon, 9 Oct 2017 19:25:08 -0400
Subject: [PATCH 1/2] Build with webkit2-sharp

Closes: #878111
---
 debian/control  |   2 +-
 debian/patches/06-move_to_webkit2.patch | 101 
 debian/patches/series   |   1 +
 3 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/06-move_to_webkit2.patch

diff --git a/debian/control b/debian/control
index 3bc56e4..4b2c892 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends-Indep: dh-autoreconf,
  libappindicator3-0.1-cil-dev,
  libgtk3.0-cil-dev,
  libnotify3.0-cil-dev,
- libwebkitgtk3.0-cil-dev,
+ libwebkit2-sharp-4.0-cil-dev,
  mono-devel (>= 3.2.8),
  python-nautilus
 Standards-Version: 3.9.6
diff --git a/debian/patches/06-move_to_webkit2.patch b/debian/patches/06-move_to_webkit2.patch
new file mode 100644
index 000..3bec00e
--- /dev/null
+++ b/debian/patches/06-move_to_webkit2.patch
@@ -0,0 +1,101 @@
+Description: Build with webkit2
+Source: https://src.fedoraproject.org/rpms/sparkleshare/blob/master/f/SparkleShare-1.5.0-move_to_webkit2.patch
+diff -up SparkleShare-1.5.0/build/build.environment.mk.move_to_webkit2 SparkleShare-1.5.0/build/build.environment.mk
+--- SparkleShare-1.5.0/build/build.environment.mk.move_to_webkit2	2015-12-22 15:21:47.0 +0100
 SparkleShare-1.5.0/build/build.environment.mk	2017-10-07 15:48:37.719880936 +0200
+@@ -12,7 +12,7 @@ LINK_MONO_POSIX = -r:Mono.Posix
+ LINK_GLIB = $(GLIBSHARP_LIBS)
+ LINK_GTK = $(GTKSHARP_LIBS)
+ LINK_GNOME = $(GNOME_SHARP_LIBS)
+-LINK_WEBKIT = $(WEBKITGTK_SHARP_LIBS)
++LINK_WEBKIT = $(WEBKIT2_SHARP_LIBS)
+ LINK_APP_INDICATOR = $(APP_INDICATOR_LIBS)
+ 
+ REF_SPARKLELIB = $(LINK_SYSTEM) $(LINK_MONO_POSIX)
+diff -up SparkleShare-1.5.0/configure.ac.move_to_webkit2 SparkleShare-1.5.0/configure.ac
+--- SparkleShare-1.5.0/configure.ac.move_to_webkit2	2015-12-22 15:21:47.0 +0100
 SparkleShare-1.5.0/configure.ac	2017-10-07 16:08:53.666097084 +0200
+@@ -66,12 +66,12 @@ if test "$OSNAME" = "Linux" ; then
+ 
+ 	PKG_CHECK_MODULES(NOTIFY_SHARP, notify-sharp-3.0)
+ 
+-	dnl check for webkitgtk-sharp
+-	PKG_CHECK_MODULES(WEBKITGTK_SHARP, webkitgtk-sharp-3.0, have_webkitgtk_sharp=yes, have_webkitgtk_sharp=no)
+-	if test "x$have_webkitgtk_sharp" = "xno" ; then
+-		AC_ERROR("webkitgtk-sharp is a required dependency: you need to install the appropriate devel package before you can compile")
++	dnl check for webkit2-sharp
++	PKG_CHECK_MODULES(WEBKIT2_SHARP, webkit2-sharp-4.0, have_webkit2_sharp=yes, have_webkit2_sharp=no)
++	if test "x$have_webkit2_sharp" = "xno" ; then
++		AC_ERROR("webkit2-sharp is a required dependency: you need to install the appropriate devel package before you can compile")
+ 	fi
+-	AC_SUBST(WEBKITGTK_SHARP_LIBS)
++	AC_SUBST(WEBKIT2_SHARP_LIBS)
+ 
+ 	APPINDICATOR_REQUIRED=0.1
+ 
+diff -up SparkleShare-1.5.0/SparkleShare/Linux/SparkleEventLog.cs.move_to_webkit2 SparkleShare-1.5.0/SparkleShare/Linux/SparkleEventLog.cs
+--- SparkleShare-1.5.0/SparkleShare/Linux/SparkleEventLog.cs.move_to_webkit2	2015-12-22 15:21:47.0 +0100
 SparkleShare-1.5.0/SparkleShare/Linux/SparkleEventLog.cs	2017-10-07 16:21:12.318399060 +0200
+@@ -18,7 +18,7 @@
+ using System;
+ 
+ using Gtk;
+-using WebKit;
++using WebKit2;
+ 
+ namespace SparkleShare {
+ 
+@@ -71,7 +71,7 @@ namespace SparkleShare {
+ 
+ this.web_view = new WebView () { Editable = false };
+ 			this.web_view.Settings.EnablePlugins = false;
+-this.web_view.NavigationRequested += WebViewNavigationRequested;
++//this.web_view.NavigationRequested += WebViewNavigationRequested;
+ 
+ this.scrolled_window.Add (this.web_view);
+ 
+@@ -263,12 +264,22 @@ namespace SparkleShare {
+ html = html.Replace ("", "file://" + new string [] {icons_path, "document-moved.png"}.Combine ());
+ 
+ this.spinner.Stop ();
+-this.scrolled_window.Remove (this.web_view);
++this.scrolled_window.Remove (this.scrolled_window.Child);
+ this.web_view.Dispose ();
+ 
+ this.web_view = new WebView () { Editable = false };
+-this.web_view.LoadString (html, "text/html", "UTF-8", "file://");
+-this.web_view.NavigationRequested += WebViewNavigationRequested;
++this.web_view.LoadHtml (html, "file:///");
++ 
++
++
++web_view.DecidePolicy += delegate(object o, DecidePolicyArgs args) {
++Console.WriteLine (" " + (args.Decision as NavigationPolicyDecision).NavigationAction.Request.Uri);
++  //  if (args.Decision. == PolicyDecisionType.NavigationAction) {
++   

Bug#878111: sparkleshare: Switch to webkit2

[Jeremy Bicha]

Source: sparkleshare
Version: 1.5.0-2
Severity: serious
Tags: patch pending

sparkleshare was removed from Debian Testing a month ago because it
depends on webkitgtk-sharp3 which uses the unmaintained webkitgtk
library that is being removed from Debian.

webkit-sharp2 has recently been uploaded to Debian as a replacement
for webkitgtk-sharp3.

I am uploading a NMU now that is numbered as sparkleshare 1.5.0-2.1
which uses a patch applied in Fedora 27 (slightly modified to apply in
Debian) to build against the new library so that sparkleshare can
return to Debian Testing. I am uploading to DELAYED/7. Please let me
know if I should delay this fix any further.

I'll be attaching the patches in the follow-up to this bug.

Thanks,
Jeremy Bicha

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

On 09/10/17 23:06, Adrian Bunk wrote:

On Mon, Oct 09, 2017 at 12:28:22PM +0100, Ghislain Vaillant wrote:

...
I was complaining about the insufficiencies behind this RC, more than the
situation with Sphinx. No offense to Adrian, but getting an RC bug reported
without much context to work with is just plain frustrating. Without your
intervention, this RC could have dragged for a long time.


Ghis, I do consider our repeated attempts to blame me for not fixing a bug in
your package VERY offensive.


I don't recall saying anywhere in this thread that I expected *you* to 
provide a patch for this. I complained about the lack of context of the 
initial bug report, albeit too bluntly to your taste.



I did not break it, I am not the maintainer of the package that broke,
and I have zero knowledge about either package.


Neither did I explicitly or implicitly held you responsible for the 
issue leading up to this RC bug. Please read again.



And the fact that I even did the extra work of finding the exact change
that broke your package makes it even more insulting - for a large part
of the FTBFS I report I do not even have a clue what broke it.



The only thing I regret is that I tried to be helpful after your initial
email, and I am seriously considering giving you a permanent entry in my
killfile so that I won't have to read another email from you for the rest
of my life.


Let's not reach such extremes yet. We are all working towards the same 
goal, i.e. making Debian a quality Linux distribution. Please accept my 
sincere apologies if I did hurt your feelings in any way.


Now, let's just move on shall we.

Ghis

Bug#878085: simple-cdd: Creating the mirror is failing due to missing files

[David Touzeau]

Thanks, fixed for our side " ftp.fr.debian.org/debian"



-Message d'origine-
De : Vagrant Cascadian [mailto:vagr...@debian.org] 
Envoyé : lundi 9 octobre 2017 21:21
À : Andre Rodier ; David Touzeau 
Cc : 878...@bugs.debian.org
Objet : Re: Bug#878085: simple-cdd: Creating the mirror is failing due to
missing files

Control: merge 877987 878085
Control: reassign 878085 mirrors
Control: affects 878085 simple-cdd

On 2017-10-09, Andre Rodier wrote:
> When running simple-cdd --do-mirror, the program fails with one 
> missing file. I have tried with multiple mirrors, but the file is 
> missing on all of them.

It appears to be a problem on the mirrors.


> simple-cdd --do-mirror --locale en_US --dist stable
>
> [...]
>
> 2017-10-09 18:09:27,290 DEBUG skipping download: 
> /home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedicat
> ion-5.0.txt checksum matched
> 2017-10-09 18:09:27,290 DEBUG skipping download: 
> /home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedicat
> ion-5.0.vi.txt checksum matched
> 2017-10-09 18:09:27,290 DEBUG downloading: 
> /home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedicat
> ion-9.0.bn.txt
> Traceback (most recent call last):

Several doc/dedication/dedication-9.0.* files present in extrafiles[1] are
missing from the mirrors. Since simple-cdd uses extrafiles to determine
which files to download, missing files cause it to fail.

You can workaround the issue by setting mirror_files='README tools/' in
profiles/default.conf until it gets fixed.

I've mentioned this on the #debian-mirrors IRC channel, and waldi fixed it;
it may take several hours to propegate.

[1] https://cdn-aws.deb.debian.org/debian/extrafiles


live well,
  vagrant

Bug#877963: u-boot: FTBFS on armel with gcc-7

[Vagrant Cascadian]

On 2017-10-09, Adrian Bunk wrote:
> On Sat, Oct 07, 2017 at 08:15:50PM -0700, Vagrant Cascadian wrote:
>>...
>> Though this obviously doesn't seem like a good long-term solution, I've
>> been able to work around the issue by patching u-boot to use gcc-6 only
>> on armel, see patch below.
>
> A proper fix is attached.

Thanks, that's much better! Tested and uploaded...

Would you consider pushing this upstream? Or give my permission to add
with signed-off-by?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#872088: Pending fixes for bugs in the libwww-perl package

[pkg-perl-maintainers]

tag 872088 + pending
thanks

Some bugs in the libwww-perl package are closed in revision
b3603d4051648e9d052c98793062eb4817b69611 in branch 'master' by
Florian Schlichting

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libwww-perl.git/commit/?id=b3603d4

Commit message:

Mark package Multi-Arch: foreign (closes: #872088)

Bug#878110: dpkg-buildpackage: Generate _arch.changes for all-only packages

[Julian Andres Klode]

Package: dpkg-dev
Version: 1.18.24
Severity: minor
File: /usr/bin/dpkg-buildpackage

If a package is Architecture: all only (or I guess has some non-all binaries
that don't build for the current arch), then building the package produces a
_arch.changes, rather than an _all.changes.

This is slightly underdocumented in the manual page, it says:
"for  a  build  that  includes  any  the  name  will  be  
source-name_source-version_arch.changes"

without mentioning that build actually means --build. 

It might be a better idea to produce _all.changes files if no non-all binaries
are produced though (and _all buildinfo files).

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.29.1-4
ii  bzip2 1.0.6-8.1
ii  libdpkg-perl  1.18.24
ii  make  4.1-9.1
ii  patch 2.7.5-1+b2
ii  perl  5.26.0-8
ii  tar   1.29b-2
ii  xz-utils  5.2.2-1.3

Versions of packages dpkg-dev recommends:
ii  build-essential  12.4
ii  clang-3.8 [c-compiler]   1:3.8.1-24
ii  fakeroot 1.22-1
ii  gcc [c-compiler] 4:7.2.0-1d1
ii  gcc-5 [c-compiler]   5.4.1-14
ii  gcc-6 [c-compiler]   6.4.0-7
ii  gcc-7 [c-compiler]   7.2.0-8
ii  gnupg2.2.1-1
ii  gnupg2   2.2.1-1
ii  gpgv 2.2.1-1
ii  gpgv22.2.1-1
pn  libalgorithm-merge-perl  
ii  tcc [c-compiler] 0.9.27~git20161217.cd9514ab-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2017.08.28

-- no debconf information

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#866041: anacron: may execute daily/weekly/monthly jobs shortly after midnight

[Francesco Poli]

On Sun, 1 Oct 2017 11:59:50 +0200 Francesco Poli wrote:

> On Sun, 27 Aug 2017 11:37:45 +0200 Francesco Poli wrote:
> 
> > On Fri, 30 Jun 2017 19:52:10 +0200 Francesco Poli wrote:
> > 
> > > On Thu, 29 Jun 2017 00:16:52 +0200 Michael Biebl wrote:
> > [...]
> > > > Afaics, this would basically reopen #744753.
> > > > Take a laptop for example, which is charged over night and then booted
> > > > in the morning while unplugged. We'd never trigger anacron because of
> > > > ConditionACPower=true in anacron.service
> > > > By triggering anacron.service hourly it's much more likely we hit a time
> > > > window where the system is plugged in.
> > > 
> > > Fair enough.
> > > 
> > > What about the attached patch?
> > > 
> > > It would at least exclude the time interval between midnight and early
> > > morning, while retaining the hourly-repeated-attempts behavior from
> > > 07:30 to 23:30.
> > 
> > Hello again,
> > have you had time to think about my second patch?
> > Do you consider it acceptable?
> > 
> > I hope you may incorporate it soon.
> > Thanks for your time!
> > 
> > Bye.
> 
> Ping?

Second ping?


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


pgpUNjm3yL1L9.pgp
Description: PGP signature

Bug#878109: openvpn@.service should not pull in network-online.target unconditionally

[Bernhard Schmidt]

Package: src:openvpn
Version: 2.4.3-4
Severity: normal

With 
https://anonscm.debian.org/git/collab-maint/openvpn.git/commit/?id=5fe7875501a2560542b462f9af5bb3346214147f
 
openvpn@.service pulls in network-online.target (to keep in sync with the
upstream openvpn-server@.service and openvpn-client@.service).

While this helps some issues (i.e. binding to a specific IP address, see
#876979) it should generally be avoided. Normal configurations should
not need this.

Pulling in network-online.target might lead to a boot-time regression. See
also https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ .

One possible solution would be to change the generator to only add
Wants/After=network-online.target when a configuration option mandating
it is found (for example "local ").

Bug#818152: [Pkg-xfce-devel] Bug#818152: lightdm: can no longer manage multiple X servers

[Oleg Kostyuk]

Hi Yves-Alexis Perez,

Very sorry but you are wrong, there are more users that need that.
Not much but still.
Personally I wanted to configure multi-session support in Xorg (not
multi-seat).
As I see, there is no way to do that on Debian 9.

What about to "nobody complained" - well, I'm complaining now, and just
because I've got new hardware and tried to setup fresh system. I had no
need to complain earlier because my old system (Debian 7) still works fine
and does what I needed. Now I see no other option to get what I want on new
hardware except to setup Debian 7.

I will be glad if I understood something wrong, and Xorg multi-session is
possible on current Debian 9 (any DM will be fine for me).
If so, please reply here or into my message in users mailing list:
https://lists.debian.org/debian-user/2017/10/msg00335.html

Hope this will be solved.
Thank you!

On Mon, 14 Mar 2016 17:20:45 +0100 Yves-Alexis Perez 
wrote:
> On lun., 2016-03-14 at 11:00 +0100, Christian Pernegger wrote:
>
> Hi,
>
> > […]
>
> First you should try to investigate whether it's possible to port your
setup
> to logind.
>
> > This should at the very least be documented in the default config file
> > and NEWS (not buried in the changelog for 1.11.7), better yet ignored
> > configuration should throw a warning.
>
> We might add a NEWS entry, but honestly I have the feeling you might be
the
> only user of that feature (nobody complained so far; I know it didn't
reach a
> Debian stable release yet, but it did in Ubuntu).
> > Any chance to add manual configuration back?
>
> You need to port your case directly upstream (see the last paragraph of
the
> mail)
>
> Regards,
> --
> Yves-Alexis
>

-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

Bug#877965: elpa-org: Fails to configure upon upgrade from 9.0.9+dfsg-4 to 9.1.2+dfsg-1

[Axel Beckert]

Version: 9.1.2+dfsg-2

Hi intrigeri,

intrig...@debian.org wrote:
> In org-babel-variable-assignments:julia:
> ob-julia.el:140:54:Warning: ‘org-number-sequence’ is an obsolete function (as
> of Org 9.0); use ‘number-sequence’ instead.
> 
> In org-babel-prep-session:mathematica:
> ob-mathematica.el:69:8:Warning: function org-babel-prep-session:mathematica
> used to take 2 arguments, now takes 3
> ob-mathematica.el:69:8:Warning: function ‘org-babel-prep-session:mathematica’
> defined multiple times in this file

Even though this bug report has been reported first and it has been
reported against the correct package (not the transitional package
org-mode), only the second bug report about that issue against the
IMHO wrong (binary) package (https://bugs.debian.org/878017) has been
marked as fixed. The according changelog entry:

 org-mode (9.1.2+dfsg-2) sid; urgency=medium

   * Remove ob-sclang.el for now (Closes: #878017)

Since I don't want to reassign already closed bug reports (even not
within the same source package) and I neither want to reassign bugs
reported against the correct package to the wrong package to
be able to merge then, I'm closing this bug report manually.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Adrian Bunk]

On Mon, Oct 09, 2017 at 12:28:22PM +0100, Ghislain Vaillant wrote:
>...
> I was complaining about the insufficiencies behind this RC, more than the
> situation with Sphinx. No offense to Adrian, but getting an RC bug reported
> without much context to work with is just plain frustrating. Without your
> intervention, this RC could have dragged for a long time.

Ghis, I do consider our repeated attempts to blame me for not fixing a bug in 
your package VERY offensive.

I did not break it, I am not the maintainer of the package that broke,
and I have zero knowledge about either package.

And the fact that I even did the extra work of finding the exact change
that broke your package makes it even more insulting - for a large part
of the FTBFS I report I do not even have a clue what broke it.

The only thing I regret is that I tried to be helpful after your initial 
email, and I am seriously considering giving you a permanent entry in my 
killfile so that I won't have to read another email from you for the rest
of my life.

> Ghis

Adrian

Bug#872087: Pending fixes for bugs in the liburi-perl package

[pkg-perl-maintainers]

tag 872087 + pending
thanks

Some bugs in the liburi-perl package are closed in revision
3d45d9faf1a6fcf00ac4646d8aa20a81cd3e24f7 in branch 'master' by
Florian Schlichting

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/liburi-perl.git/commit/?id=3d45d9f

Commit message:

Mark package Multi-Arch: foreign (closes: #872087)

...and annotate Perl dependency with :any, as suggested by the Multiarch
hinter.

Bug#877963: u-boot: FTBFS on armel with gcc-7

[Adrian Bunk]

On Sat, Oct 07, 2017 at 08:15:50PM -0700, Vagrant Cascadian wrote:
>...
> Though this obviously doesn't seem like a good long-term solution, I've
> been able to work around the issue by patching u-boot to use gcc-6 only
> on armel, see patch below.

A proper fix is attached.

> live well,
>   vagrant
>...

cu
Adrian

-- 

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

Description: jffs2/mini_inflate.c: use "static inline" instead of "inline"
 This makes gcc no longer expect an out-of-line version of the
 functions being present elsewhere.
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/877963

--- u-boot-2017.09+dfsg1.orig/fs/jffs2/mini_inflate.c
+++ u-boot-2017.09+dfsg1/fs/jffs2/mini_inflate.c
@@ -16,7 +16,7 @@
 static unsigned char huffman_order[] = {16, 17, 18,  0,  8,  7,  9,  6, 10,  5,
 	11,  4, 12,  3, 13,  2, 14,  1, 15};
 
-inline void cramfs_memset(int *s, const int c, size n)
+static inline void cramfs_memset(int *s, const int c, size n)
 {
 	n--;
 	for (;n > 0; n--) s[n] = c;
@@ -65,8 +65,8 @@ static void init_stream(struct bitstream
 /* pull 'bits' bits out of the stream. The last bit pulled it returned as the
  * msb. (section 3.1.1)
  */
-inline unsigned long pull_bits(struct bitstream *stream,
-			   const unsigned int bits)
+static inline unsigned long pull_bits(struct bitstream *stream,
+  const unsigned int bits)
 {
 	unsigned long ret;
 	int i;
@@ -85,7 +85,7 @@ inline unsigned long pull_bits(struct bi
 	return ret;
 }
 
-inline int pull_bit(struct bitstream *stream)
+static inline int pull_bit(struct bitstream *stream)
 {
 	int ret = ((*(stream->data) >> stream->bit) & 1);
 	if (stream->bit++ == 7) {

Bug#861923: openvpn: arbitrary process limit

[Bernhard Schmidt]

Control: tags -1 - unreproducible

On 09.10.2017 22:45, Michael Stone wrote:

Hi Michael,

> On Mon, Oct 09, 2017 at 09:47:49PM +0200, Bernhard Schmidt wrote:
>> I'm not exactly sure why it was chosen this low, but I cannot reproduce
>> your issue. I think LimitNPROC=10 is _per_ _instance_. I could start
>> 20 server
>> instances just fine
> 
> Could you run scripts? IIRC, it's not the startup that's the problem,
> it's actually using them once they're running. Probably also requires
> running as a non-root user (I don't think nproc applies to root). So the
> processes start fine as root, then setuid something else, then can not
> fork subsequently.

Okay, I could reproduce it this way

for i in `seq 1 20`; do  echo -e "dev tun\nifconfig 10.0.$i.1
10.0.$i.2\nsecret static.key\nport 200$i\nscript-security 2\nup
'/usr/local/bin/sleep-5.sh'\n" > server$i.conf; systemctl
restart openvpn@server$i; done

with /usr/local/bin/sleep-5.sh

===
/bin/su -c "/bin/sleep 5" -s /bin/sh nobody
===

Doing this 3 of the OpenVPN instances start, the others fail.

Replacing nobody with root makes all start, so you are probably right
about the limit being system-wide and only for non-root commands.
Removing the "unreproducible" tag.

I also do see several reports about this

https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1631104
https://github.com/systemd/systemd/issues/6011#issuecomment-304617744

I'm actually not sure what LimitNPROC is really limiting (the Lennart
comment about this counting processes on other containers really made me
think that this might have been the wrong knob from the beginning).

Bernhard

Bug#878062: RM: r-cran-knitr [armel hurd-i386 powerpc] -- ROM; node.js not available

[Sébastien Villemot]

Control: block -1 by 877839
Control: block -1 by 877832

Additional info:

sebastien@coccia:~$ dak rm -Rn -a armel,powerpc,hurd-i386 r-cran-knitr
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

r-cran-knitr |   1.15.1-2 | source
r-cran-knitr | 1.15.1-2+b1 | armel, hurd-i386
r-cran-knitr |   1.15.1-3 | source, powerpc
r-cran-knitr |   1.15.1-4 | source

Maintainer: Debian Science Team 


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
r-cran-htmltable: r-cran-htmltable
rgl: r-cran-rgl [powerpc]

# Broken Build-Depends:
r-bioc-deseq2: r-cran-knitr
r-cran-htmltable: r-cran-knitr
r-cran-rglwidget: r-cran-knitr
rgl: r-cran-knitr

Dependency problem found.



- r-cran-htmltable and r-cran-rglwidget are arch:all
- partial removal of rgl and r-bioc-deseq2 already requested (see blocking 
bugs).

Thanks,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#871729: libembperl-perl: FTBFS when debhelper does not export PERL_USE_UNSAFE_INC

[Florian Schlichting]

On Thu, Aug 10, 2017 at 06:45:02PM -0400, Dominic Hargreaves wrote:
> The relevant build failure logs are below:
> 
> PERL_DL_NONLAZY=0 "/usr/bin/perl" "-Iblib/lib" "-Iblib/arch" test.pl 
> 
> loading...do "test/conf/config.pl" failed, '.' is no 
> longer in @INC; did you mean do "./test/conf/config.pl"? at test.pl line 1326.
> Use of uninitialized value $EPSESSIONVERSION in pattern match (m//) at 
> test.pl line 1332.
> Use of uninitialized value $EPSESSIONVERSION in numeric ge (>=) at test.pl 
> line 1332.
> Can't locate test/testapp.pl in @INC (@INC contains: 
> /<>/blib/lib /<>/blib/arch /etc/perl 
> /usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
> /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
> /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
> /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at test.pl line 
> 1426.
> 
> Test terminated with fatal error

to get there with dh compat 11, I had to patch Makefile.PL and disable parallel
builds, but then adding '.' in two places seemed to be all that's needed:


--- a/debian/rules
+++ b/debian/rules
@@ -14,7 +14,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-bindnow
pod2text < $< > $@
 
 %:
-   dh $@
+   dh $@ --no-parallel
 
 override_dh_auto_configure:
. /etc/apache2/envvars && yes y | EPHTTPD=/usr/sbin/apache2 
dh_auto_configure


8<-


--- a/test.pl
+++ b/test.pl
@@ -1316,7 +1316,7 @@
 
  read config 
 
-do ($opt_config || "$confpath/config.pl") ; 
+do ($opt_config || "./$confpath/config.pl") ; 
 
 die $@ if ($@) ;
 
@@ -1416,7 +1416,7 @@
 $vmhttpdsize = 0 ;
 $vmhttpdinitsize = 0 ;
 
-require 'test/testapp.pl' ;
+require './test/testapp.pl' ;
 
 
 #
--- a/Makefile.PL
+++ b/Makefile.PL
@@ -1346,7 +1346,7 @@
 
 close FH ;
 
-$i .= " -I$EPPATH/xs" ;
+$i .= " -I$EPPATH/xs -I." ;
 
 if ($mp2cfg && $mp2cfg->{'MP_INCLUDE_DIR'})
 {


Florian

Bug#860360: okular: I can confirm the bug with czech accents. Create a folder with accents, place a pdf file inside, cannot open the pdf from Dolphin. If immediately try to open from okular, the p

[Michael Weghorn]

On 2017-10-09 19:49, lp...@centrum.cz wrote:
> I can confirm that this helped resolve the issue. Thank you very much!
> Leos

You're welcome. Thanks for the confirmation that this solved the issue!



@Máximo: Do you still have the issue with Okular not being able to open
PDF files if the path contains accents? Do the steps described below
possibly also fix the problem for you?

>  Can you please try the following:
>  
>  * open a terminal
>  * run the following command there: "sudo dpkg-reconfigure locales"
>  * select "cs_CZ.UTF-8" and confirm so that the respective locale is
>  generated
>  
>  (There may be ways to generate the locales using the graphical user
>  interface instead, but that depends on the specific desktop environment
>  in use. Please let me know in case the above steps are not clear enough.)
> 

Instead of selecting "cs_CZ.UTF-8", that might be something else in your
case. Can you possibly post the output you get when you type the command
"locale" on the command line?

Regards,
  Michael

Bug#871835: another improvement

[Thomas Lange]

Here's another patch which makes debootstrap a little bit faster.


0009-in-this-part-we-only-need-the-package-name-and-prior.patch
Description: Binary data

-- 
regards Thomas

Bug#878108: python3-guzzle-sphinx-theme: links jquery.js to minified version, causing dh_sphinxdoc to fail

[Sven Hartge]

Package: python3-guzzle-sphinx-theme
Version: 0.7.11-1
Severity: normal

Hi!

During compilation (in a clean pbuilder chroot) of the new borgbackup
1.1.0 packages based on the current Debian packages I stumbled upon the
following problem:

At buildtime dh_sphinxdoc fails like this:

make[1]: Leaving directory '/build/borgbackup-1.1.0'
   dh_sphinxdoc -O--buildsystem=pybuild
dh_sphinxdoc: error: unknown JavaScript code: 
debian/borgbackup-doc/usr/share/doc/borgbackup-doc/html/_static/jquery.js
debian/rules:44: recipe for target 'binary' failed

The reason is python3-guzzle-sphinx-theme links its jquery.js to the
minified version:

lrwxrwxrwx 1 root root 55 Jun 25 01:28 
/usr/lib/python3/dist-packages/guzzle_sphinx_theme/guzzle_sphinx_theme/static/jquery.js
 -> ../../../../../../share/javascript/jquery/jquery.min.js

Because of this, dh_sphinxdoc fails to compare the copied jquery.js with the 
unminified version in
/usr/share/javascript/jquery/jquery.js and aborts.

Proposed solution:

diff -Nru guzzle-sphinx-theme-0.7.11/debian/links 
guzzle-sphinx-theme-0.7.11/debian/links
--- guzzle-sphinx-theme-0.7.11/debian/links 2017-06-25 01:28:28.0 
+0200
+++ guzzle-sphinx-theme-0.7.11/debian/links 2017-10-09 22:42:03.0 
+0200
@@ -10,4 +10,5 @@
 usr/share/javascript/bootstrap/fonts/glyphicons-halflings-regular.woff2
usr/lib/python3/dist-packages/guzzle_sphinx_theme/guzzle_sphinx_theme/static/fonts/glyphicons-halflings-regular.woff2
 usr/share/javascript/bootstrap/js/bootstrap.js 
usr/lib/python3/dist-packages/guzzle_sphinx_theme/guzzle_sphinx_theme/static/js/bootstrap.js
 usr/share/javascript/bootstrap/js/bootstrap.min.js 
usr/lib/python3/dist-packages/guzzle_sphinx_theme/guzzle_sphinx_theme/static/js/bootstrap.min.js
-usr/share/javascript/jquery/jquery.min.js  
usr/lib/python3/dist-packages/guzzle_sphinx_theme/guzzle_sphinx_theme/static/jquery.js
+usr/share/javascript/jquery/jquery.min.js  
usr/lib/python3/dist-packages/guzzle_sphinx_theme/guzzle_sphinx_theme/static/jquery.min.js
+usr/share/javascript/jquery/jquery.js  
usr/lib/python3/dist-packages/guzzle_sphinx_theme/guzzle_sphinx_theme/static/jquery.js

This is essentially the same linkage as already done for bootstrap.js and 
bootstrap.min.js.

Grüße,
Sven.

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

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

Versions of packages python3-guzzle-sphinx-theme depends on:
ii  dpkg  1.18.24
ii  fonts-liberation  1:1.07.4-4
ii  libjs-bootstrap   3.3.7+dfsg-2
ii  libjs-jquery  3.2.1-1
ii  python3   3.5.3-3
ii  python3-sphinx1.6.4-2

python3-guzzle-sphinx-theme recommends no packages.

python3-guzzle-sphinx-theme suggests no packages.

-- no debconf information

Bug#878107: src:pcre3: stack frame size detection is broken

[Ondřej Surý]

Package: src:pcre3
Version: 2:8.39-5
Severity: grave

Dear Maintainer,

the system-wide pcre3 library stack frame size detection is broken as described 
in
https://bugs.exim.org/show_bug.cgi?id=2173

and that breaks at least ppc64el and s390x build causing segfaults in the test 
suite (+ autopkgtest).

The patch from Sergei @ MariaDB is quite simple at it should pose no risk 
applying it:

diff --git a/pcre/pcre_exec.c b/pcre/pcre_exec.c
--- a/pcre/pcre_exec.c
+++ b/pcre/pcre_exec.c
@@ -509,6 +509,12 @@
  (e.g. stopped by repeated call or recursion limit)
 */
 
+#ifdef __GNUC__
+static int
+match(REGISTER PCRE_PUCHAR eptr, REGISTER const pcre_uchar *ecode,
+  PCRE_PUCHAR mstart, int offset_top, match_data *md, eptrblock *eptrb,
+  unsigned int rdepth) __attribute__((noinline,noclone));
+#endif
 static int
 match(REGISTER PCRE_PUCHAR eptr, REGISTER const pcre_uchar *ecode,
 PCRE_PUCHAR mstart, int offset_top, match_data *md, eptrblock *eptrb,

Please apply the patch in the next maintenance window for PCRE3,
including stable and possibly oldstable as this causes segfaults (at
least) in src:mariadb-10.1 on affected platforms (and both ppc64el and
s390x are our release architectures).

Cheers,
Ondrej

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

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

Bug#878098: libneo4j-client: FTBFS on hurd-i386: PATH_MAX undeclared

[Chris Leishman]

I'll take a look. Supporting Hurd isn't a priority for this project, but
happy to try to get it to work sometime. Upstream patches are also
gratefully accepted.

/c

On 9 October 2017 at 21:31, Aaron M. Ucko  wrote:

> Source: libneo4j-client
> Version: 2.2.0-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source
> User: debian-h...@lists.debian.org
>
> Builds of libneo4j-client for hurd-i386 (admittedly not a release
> architecture) have been failing:
>
>   dotdir.c:37:15: error: 'PATH_MAX' undeclared (first use in this
> function); did you mean 'INT8_MAX'?
>
> The Hurd has no fixed PATH_MAX.  Best practice is to avoid blindly
> preallocating buffers, which typically results in wasting memory or
> else truncation (or, worse, buffer overflows).  However, if that's not
> feasible, you can look up _PC_PATH_MAX via pathconf, or supply your
> own fallback constant (traditionally 4096).
>
> Could you please take a look?
>
> Thanks!
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/
> finger/?a...@monk.mit.edu
>

Bug#878034: ejabberd: please include erlang options into debconf

[Philipp Huebner]

Hi,

> please consider to make ERL_OPTIONS configurable with debconf. Specifically,
> this would allow to set ERL_OPTIONS="-env ERL_CRASH_DUMP_BYTES 0"

we have discussed it and intend make this setting the default as well as
a configurable debconf value.

Thank you for this very sensible suggestion!

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#857169: furter investigation

[Bernhard Schmidt]

Control: tags -1 wontfix

Hi Erik,

first of all, thanks for your detailed analysis.

> Mär 09 08:53:47 m2 systemd[1]: Started OpenVPN connection to client. <<< this 
> is what notifyhelper.sh does!
> Mär 09 08:53:47 m2 systemd[1]: Mounting /home... 
> Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 /sbin/ip route del 
> 0.0.0.0/0
> Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 /sbin/ip route add 
> 0.0.0.0/0 via 192.100.100.1 
> Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 Initialization 
> Sequence Completed
> 
> as you see from the journalctl excerpt above,
> some routes are set AFTER notifyhelper.sh gets called.
> so we have an order problem here.
> I do not find a way to specify that notifyhelper.sh must be called VERY LAST.
> if I read my logs longer i see that mounting /home fails because the routes 
> have not been set...
> 
> Second major problem:
> 
> Mär 09 08:53:44 m2 openvpn[664]: Thu Mar  9 08:53:44 2017 Multiple --up 
> scripts defined. The previously configured script is overridden.
> 
> In my case this leads to the problem that /etc/openvpn/update-resolv-conf
> does not get called which is specified from my /etc/openvpn/client.conf file.

Only one "up" script is supported. You can hack something locally with
either a wrapper script or run-parts(8), but this won't be supported
upstream.

> Conclusion:
> 
> It does not seem to be easy to make openvpn call some script at the very end
> without interfering with the way the user thinks its own config file works
> (i.e. the user has his own --up calls there.)
> 
> 
> 
> The clean way would be to have openvpn call systemctl sd_notify(...READY=1)
> at the absolute end of initialization. upstream someone?

In fact upstream has changed this to emit READY=1 a lot earlier than
before, which will completely break any assumptions about having an
established connection when the systemd unit is running.

https://github.com/OpenVPN/openvpn/commit/e83a8684f0a0d944e9d53cdad2b543cfd1b6fbae

Unfortunately I don't have any good advise here, but since this is
something that cannot be sanely be done in a generic configuration we
cannot fix it in Debian, hence marking the bug "wontfix".

One possible option could also be to add the routes inside the up script
before starting the mount. But again, this would be a very specific
local configuration.

> meanwhile I will continue by writing a custom systemd service
> which waits until openvpn is ready by doing dns lookups and or pings.
> then i will add the neccessary dependencies to make my boot work.
> But for now I will give up on the idea of doing it the right way.

Bernhard

Bug#861923: openvpn: arbitrary process limit

[Michael Stone]

On Mon, Oct 09, 2017 at 09:47:49PM +0200, Bernhard Schmidt wrote:

I'm not exactly sure why it was chosen this low, but I cannot reproduce
your issue. I think LimitNPROC=10 is _per_ _instance_. I could start 20 server
instances just fine


Could you run scripts? IIRC, it's not the startup that's the problem, 
it's actually using them once they're running. Probably also requires 
running as a non-root user (I don't think nproc applies to root). So the 
processes start fine as root, then setuid something else, then can not 
fork subsequently.


Mike Stone

Bug#878095: [Pkg-freeipa-devel] Bug#878095: python-ipalib installation fails because of a syntax error in odsmgr.py

[Timo Aaltonen]

On 09.10.2017 21:35, David Heitman wrote:
> Package: python-ipalib
> Version: 4.4.4-2
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>  Attempted to upgrade to lastest pages, which included an update for
>  freeipa* and python-ipalib.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  Fixed the syntax in odsmgr.py on line 135, adding a missing colon
>  to the end of the line
>* What was the outcome of this action?
>  Able to complete the installation after the edit
> 
> @@ -132,7 +132,7 @@
> 
>  def get_ods_zonelist(self):
>  stdout = self.ksmutil(['zonelist', 'export'])
> -with open(paths.OPENDNSSEC_ZONELIST_FILE) as f:
> +with open(paths.OPENDNSSEC_ZONELIST_FILE) as f
>  reader = ODSZoneListReader(f.read())
>  return reader

Ouch, sorry about that, the same typo was on the upstream bug tracker..
I'll fix that in a minute.



-- 
t

Bug#878105: release-notes: problems building the release-notes (jessie) for the Debian website

[Laura Arjona Reina]

Package: release-notes
Severity: normal
Tags: patch

Dear release-notes maintainers
Thanks for your work in the release notes for every Debian release!

The script that automatically builds the release notes for the Debian website
throws some errors when building the release notes in PDF format.

Those errors appear for any architecture except armel and any language, for the
jessie release notes.

The errors are of the type:
---
Build stdin.pdf
xelatex failed
stdin.tex:292: Something's wrong--perhaps a missing \item.
stdin.tex:292: leading text: \end{description}
Unexpected error occured
Error: xelatex compilation failed
Makefile:214: recipe for target 'en/release-notes.amd64.pdf' failed
---

I've checked the "stdin.tex" generated file, did some tests, and probably the
culprit is this:

file jessie/en/whats-new.dbk


  
Support for iop32x was dropped

  
On armel, support for
the iop32x subarchitecture was dropped. Other
armel subarchitectures
continue to be supported, including ixp4xx, kirkwood, orion
and versatile.
  

  


The above code produces this LaTeX output:
\begin{description}
\end{description}
in all the architectures except armel, and then xelatex complains about a
missing \item inside the {description} block.

I searched for similar paragraphs in the dbk files and found this:

file jessie/en/installing.dbk
















[...]

I'm attaching a diff for the file
svn.debian.org/svn/ddp/manuals/branches/release-notes/jessie/en/
that adds a similar empty paragraph to fix the issue.

Please merge it if you find it useful, and I'll check the logs of the
subsequent website builds to see if the error dissapear for jessie/en. If yes,
then I would try to produce another patch for the rest of the languages.

Best regards

Laura Arjona Reina
https://wiki.debian.org/LauraArjona



-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Index: en/whats-new.dbk
===
--- en/whats-new.dbk	(revisión: 11716)
+++ en/whats-new.dbk	(copia de trabajo)
@@ -107,6 +107,19 @@
 
 
 
+
+
+
+  
+   
+   
+
+
+
+   
+  
+
   
 Support for iop32x was dropped
 

Bug#792653: Probably related to CapabilityBoundingSet

[Bernhard Schmidt]

Control: tags -1 wontfix
Control: summary -1 CapabilityBoundingSet prevents "Unprivileged mode", needs 
override

On Fri, May 13, 2016 at 09:01:20AM -0400, Simon Deziel wrote:

Hi,

> Hi Jim,
> 
> On 2016-05-13 08:19 AM, BARBER, Jim wrote:
> > I tried Simon Deziel's technique first.
> > I ran: systemctl edit openvpn@.service
> > It opened a blank editor and I added the following lines:
> > 
> > [Service]
> > CapabilityBoundingSet=
> 
> I'm sorry to have induce you in error. Apparently you need to set it
> like that to properly under any previous effect:
> 
>   [Service]
>   CapabilityBoundingSet=~
> 
> This is explained here [1]:
> 
> > If set to "~" (without any further argument), the bounding set is
> > reset to the full set of available capabilities, also undoing any
> > previous settings.

So, as far as I understand this bug the systemd CapabilityBoundingSet
prevents "sudo" from working

I'm marking this as "wontfix" since you can override it locally if
necessary, and the default protection with the capabilities is more
important 

Bernhard

Bug#877702: redis-server: Easily run multiple instances with systemd

[Chris Lamb]

Hey,

> I just executed the generate-systemd-service-files that you wrote on my
> local machine, and there is no notable differences between my local
> redis-server@.service and the generated one. Only the comments I wrote
> were stripped.

Excellent! I'll upload this change when the fix for #877989 lands. :)


Regards,

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

Bug#878104: debugfs: out-of-bounds read in ext2fs_inode_csum_verify()

[Jakub Wilk]

Package: e2fsprogs
Version: 1.43.6-1

$ gzip -d oob.ext2.gz
$ valgrind -q /sbin/debugfs -R ls oob.ext2 > /dev/null
debugfs 1.43.6 (29-Aug-2017)
==9681== Invalid read of size 4
==9681==at 0x486E2F0: crc32_body (crc32c.c:116)
==9681==by 0x486E2F0: crc32_le_generic (crc32c.c:180)
==9681==by 0x486E2F0: ext2fs_crc32c_le (crc32c.c:188)
==9681==by 0x486EA8A: ext2fs_inode_csum.isra.10 (csum.c:651)
==9681==by 0x486F573: ext2fs_inode_csum_verify (csum.c:674)
==9681==by 0x48826A0: ext2fs_read_inode_full (inode.c:821)
==9681==by 0x4882774: ext2fs_read_inode (inode.c:845)
==9681==by 0x114DD5: debugfs_read_inode (util.c:441)
==9681==by 0x1163D1: do_list_dir (ls.c:245)
==9681==by 0x48C3215: check_request_table (execute_cmd.c:105)
==9681==by 0x48C3215: really_execute_command (execute_cmd.c:143)
==9681==by 0x48C33EA: ss_execute_line (execute_cmd.c:224)
==9681==by 0x10E216: main (debugfs.c:2553)
==9681==  Address 0x4b07fa8 is 0 bytes after a block of size 128 alloc'd
==9681==at 0x482E2BC: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==9681==by 0x4881512: ext2fs_get_mem (ext2fs.h:1741)
==9681==by 0x4881512: ext2fs_create_inode_cache (inode.c:125)
==9681==by 0x48826F6: ext2fs_read_inode_full (inode.c:759)
==9681==by 0x4882774: ext2fs_read_inode (inode.c:845)
==9681==by 0x114DD5: debugfs_read_inode (util.c:441)
==9681==by 0x1163D1: do_list_dir (ls.c:245)
==9681==by 0x48C3215: check_request_table (execute_cmd.c:105)
==9681==by 0x48C3215: really_execute_command (execute_cmd.c:143)
==9681==by 0x48C33EA: ss_execute_line (execute_cmd.c:224)
==9681==by 0x10E216: main (debugfs.c:2553)
...


Found using American Fuzzy Lop:
http://lcamtuf.coredump.cx/afl/

-- System Information:
Architecture: i386

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.43.6-1
ii  libblkid1   2.29.2-5+b1
ii  libc6   2.24-17
ii  libcomerr2  1.43.6-1
ii  libss2  1.43.6-1
ii  libuuid12.29.2-5+b1

--
Jakub Wilk


oob.ext2.gz
Description: application/gzip

Bug#874307: Correction

[Bernhard Schmidt]

Control: tags -1 unreproducible

On Tue, Sep 05, 2017 at 10:04:05AM +0200, Daniel Haid wrote:
> Actually, this only happens when using
> "systemctl restart", not "systemctl start".

I cannot reproduce this.

Can you show "systemctl status openvpn-server@first.service" and
"systemctl status openvpn-server@second.service", both before and after
the restart?

Bernhard

Bug#878103: maven-debian-helper: Wrong package name for -doc packages

[Christopher Hoskin]

Package: maven-debian-helper
Version: 2.2.5
Severity: normal

Dear Maintainer,

Following commit cafc9403b0da58c789ed95e5d8ff3b165bcde76f, when the
DEB_BUILD_OPTIONS variable does not include nodoc, maven-debian-helper
mistakenly uses "1" as the packagename instead of the actual name of the doc
package. A consequence of this is that a file debian/1.substvar is created
instead of debian/-doc.substvar.

The reason for this appears to be that share/perl/maven.pm has the following
modification:

-   $this->{doc_package} = (grep /-doc$/, @packages)[0];
+   $this->{doc_package} = (grep /-doc$/, @packages)[0] && 
(get_buildoption("nodoc") != 1);

When the DEB_BUILD_OPTIONS variable does not include nodoc, 
get_buildoption("nodoc") returns undef and (get_buildoption("nodoc") != 1) 
evaluates to 1. However,
(grep /-doc$/, @packages)[0] && (get_buildoption("nodoc") != 1) evaluates to 1, 
not
to (grep /-doc$/, @packages)[0].

Christopher

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

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

Versions of packages maven-debian-helper depends on:
ii  default-jdk 2:1.8-59
ii  default-jdk-headless2:1.8-59
ii  libmaven-clean-plugin-java  3.0.0-2
ii  libmaven-compiler-plugin-java   3.6.2-2
ii  libmaven-jar-plugin-java3.0.2-2
ii  libmaven-resources-plugin-java  3.0.2-1
ii  libmaven-site-plugin-java   3.6-1
ii  libplexus-velocity-java 1.2-3
ii  libsurefire-java2.20.1-3
ii  libxml2-utils   2.9.4+dfsg1-4
ii  maven   3.5.0-6
ii  maven-repo-helper   1.9.2
ii  unzip   6.0-21
ii  velocity1.7-5

maven-debian-helper recommends no packages.

Versions of packages maven-debian-helper suggests:
ii  apt-file  3.1.4
ii  libmaven-javadoc-plugin-java  3.0.0~M1-4
ii  licensecheck  3.0.31-2
ii  subversion1.9.7-2

-- no debconf information

Bug#877992: postfix: Postfix does not start services after upgrade to stretch 9.2 and reboot

[Daniel Haid]

I have the same problem:

/lib/systemd/system-generators/postfix-instance-generator

does not generate the required links on boot, but it does on reinstall.

Bug#878101: more info

[Paul Devaney]

This sounds so much like this report I have read from the linux mint bugs

nemo-file.c: add EFAULT as a valid exception to the access_ok

https://github.com/linuxmint/nemo/commit/b58bea5384436fda9cb6b31f7010f72d3c74e76a#diff-53011b366ae6f19d5347ce06d362d6ca

Bug#808578: Acknowledgement (openvpn client adds wrong routes and blackholes a big chunk of networks)

[Bernhard Schmidt]

Control: tags -1 moreinfo

On Mon, Dec 21, 2015 at 08:41:58AM +0100, tob...@systemsoft.se wrote:
> On 2015-12-21 08:36, ow...@bugs.debian.org wrote:
> > Thank you for filing a new Bug report with Debian.
> > 
> > This is an automatically generated reply to let you know your message
> > has been received.
> > 
> > Your message is being forwarded to the package maintainers and other
> > interested parties for their attention; they will reply in due course.
> > 
> > Your message has been sent to the package maintainer(s):
> >  Alberto Gonzalez Iniesta 
> > 
> > If you wish to submit further information on this problem, please
> > send it to 808...@bugs.debian.org.
> > 
> > Please do not send mail to ow...@bugs.debian.org unless you wish
> > to report a problem with the Bug-tracking system.
> 
> Seems like it creates the interface with a 10.8.0.22/6 address which
> explains why the route is like that.
> inet 10.8.0.22/6 brd 255.255.255.254 scope global tap0
> 
> Don't know what causes this thought, since I have a the "server" directive
> in the server config.
> server 10.8.0.0 255.255.255.0

Can you please show logs from the client, at least the PUSH REPLY and
the ifconfig/route commands being executed?

Best Regards,
Bernhard

-- 

Bug#878101: nemo: Nemo segfault on thumbnailing of a moved file over smb

[pauldev]

Package: nemo
Version: 3.2.2-3
Severity: grave
Tags: upstream
Justification: causes non-serious data loss

Dear Maintainer,

   * What led up to the situation?
I use nemo to browse photos uploaded from family members to a SMB share and
sort them according to occasion etc.
I have thumbnailing turned on for networked files upto any size.

This is repeatable every time - when I move a photo from one folder to another,
the "A problem has been detected with your thumbnail cache. Fixing it will will
required administrative privleges" message appears.
Either allowing this, or ignoring results in a segfault to nemo when browsing
either to the target folder, or the original folder again.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
This does not affect nautilus, or local files - or if I turn off thumbnailing
on network drives.


   * What was the outcome of this action?
nemo segfault

   * What outcome did you expect instead?
It realises there has been move file move, and regenerates the thumbnail.



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

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

Versions of packages nemo depends on:
ii  desktop-file-utils 0.23-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  gvfs   1.30.4-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-11+deb9u1
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libcinnamon-desktop4   3.2.4-4
ii  libexempi3 2.4.1-1
ii  libexif12  0.6.21-2+b2
ii  libgail-3-03.22.11-1
ii  libgdk-pixbuf2.0-0 2.36.5-2+deb9u1
ii  libglib2.0-0   2.50.3-2
ii  libglib2.0-data2.50.3-2
ii  libgtk-3-0 3.22.11-1
ii  libnemo-extension1 3.2.2-3
ii  libnotify4 0.7.7-2
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-2.2+deb9u1
ii  nemo-data  3.2.2-3
ii  shared-mime-info   1.8-1

Versions of packages nemo recommends:
ii  cinnamon-l10n3.2.2-2
ii  gvfs-backends1.30.4-1
ii  gvfs-fuse1.30.4-1
ii  librsvg2-common  2.40.16-1+b1
ii  nemo-fileroller  3.2.1-2

Versions of packages nemo suggests:
ii  eog  3.20.5-1+b1
ii  evince [pdf-viewer]  3.22.1-3+deb9u1
ii  totem3.22.1-1
ii  xdg-user-dirs0.15-2+b1

-- no debconf information

Bug#878102: measurement-kit: FTBFS on powerpc: 15 tests segfault

[Aaron M. Ucko]

Source: measurement-kit
Version: 0.7.1-2
Severity: important
Justification: fails to build from source
User: debian-powe...@lists.debian.org

Thanks for taking care of the two measurement-kit FTBFS bugs I
reported last week.  Alas, the build for powerpc (admittedly not a
release architecture) is failing because 15 tests segfault, per the
below excerpt from
https://buildd.debian.org/status/fetch.php?pkg=measurement-kit=powerpc=0.7.1-2=1507421270=0.

Could you please take a look?  I don't have details beyond what's in
the log, but perhaps you can reproduce the errors on a porter box.

Thanks!

./test-driver: line 107: 28971 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/common/continuation
[...]
./test-driver: line 107: 29089 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/common/every
[...]
./test-driver: line 107: 29177 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/common/fcompose
[...]
./test-driver: line 107: 29331 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/common/parallel
[...]
./test-driver: line 107: 30207 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/dns/system_resolver
[...]
./test-driver: line 107: 30273 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/http/request
[...]
./test-driver: line 107: 30361 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/libevent/poller
./test-driver: line 107: 30383 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/mlabns/mlabns
[...]
./test-driver: line 107: 30449 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/ndt/protocol
[...]
./test-driver: line 107: 30603 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/net/connect
[...]
./test-driver: line 107: 31024 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/ooni/bouncer
./test-driver: line 107: 31046 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/ooni/collector_client
./test-driver: line 107: 31068 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/ooni/orchestrate
./test-driver: line 107: 31090 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/ooni/resources
PASS: test/ooni/templates
./test-driver: line 107: 31134 Segmentation fault  "$@" > $log_file 2>&1
FAIL: test/ooni/utils
[...]

# TOTAL: 75
# PASS:  60
# SKIP:  0
# XFAIL: 0
# FAIL:  15
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test/common/continuation
==


~~~
continuation is a Catch v1.10.0 host application.
Run with -? for options

---
The continuation works as expected
---
test/common/continuation.cpp:29
...

test/common/continuation.cpp:29: FAILED:
due to a fatal error condition:
  SIGSEGV - Segmentation violation signal

===
test cases: 1 | 1 failed
assertions: 1 | 1 failed

FAIL test/common/continuation (exit status: 139)

FAIL: test/common/every
===


~~~
every is a Catch v1.10.0 host application.
Run with -? for options

---
The every() template works
  When the delay is negative we get an error
---
test/common/every.cpp:19
...

test/common/every.cpp:19: FAILED:
due to a fatal error condition:
  SIGSEGV - Segmentation violation signal

===
test cases: 1 | 1 failed
assertions: 1 | 1 failed

FAIL test/common/every (exit status: 139)

FAIL: test/common/fcompose
==


~~~
fcompose is a Catch v1.10.0 host application.
Run with -? for options

---
fcompose() works as expected with async policy
  For deferred callbacks
---
test/common/fcompose.cpp:71
...

test/common/fcompose.cpp:71: FAILED:
due to a fatal error condition:
  SIGSEGV - Segmentation violation signal

===
test cases: 2 | 1 passed | 1 failed
assertions: 9 | 8 passed | 1 failed

FAIL test/common/fcompose (exit status: 139)

FAIL: test/common/parallel
==


~~~
parallel is a 

Bug#854612: openvpn: When an openvpn client is failing, it gets killed

[Bernhard Schmidt]

Control: fixed -1 2.4.3-1
Control: tags -1 upstream

On Wed, Feb 08, 2017 at 06:12:01PM +0100, Serge Pouliquen wrote:

Hi,

> When an openvpn client is failing, it gets killed.
> 
> openvpn 2.4 is arriving with a client folder '/etc/openvpn/client/' (and a 
> server folder).
> So I put client files and the server files in their own folder.
> 
> I found that the matching systemd commands are :
> systemctl enable openvpn-client@yyy.service
> systemctl enable openvpn-server@xxx.service
> 
> At boot, if server is not reachable, the service is killed:
> # Feb  7 21:08:57 lemon openvpn[4925]: SIGTERM[hard,init_instance] received, 
> process exiting
> # Feb  7 21:08:57 lemon systemd[1]: openvpn-client@yyy.service: Unit entered 
> failed state.
> # Feb  7 21:08:57 lemon systemd[1]: openvpn-client@yyy.service: Failed with 
> result 'timeout'.
> 
> Expected result : service not killed
> If server is not started/reachable at startup, but became later. I expect the 
> client to attempt later.

openvpn-client@.service and openvpn-server@.service are provided by
upstream. They use Type=notify to signal systemd the proper startup.

Unfortunately in upstream version 2.4.0 READY=1 is only emitted after
the client (or a server in p2p mode) has established the connection. See

https://github.com/OpenVPN/openvpn/commit/e83a8684f0a0d944e9d53cdad2b543cfd1b6fbae

for the fix. This has been fixed in a later version, but I'm not sure we
can backport this sanely without the risk of regressions (i.e. people
relying on this behaviour, as seen in #857169).

Please use the standard Debian config (/etc/openvpn/xxx.conf,
openvpn@xxx.service)

Bernhard

Bug#877702: redis-server: Easily run multiple instances with systemd

[Adrien CLERC]

> In the meantime, what would be the easiest way for you to test the result
> of this change? Shall I attach the 4 .service files it now generates?
I just executed the generate-systemd-service-files that you wrote on my
local machine, and there is no notable differences between my local
redis-server@.service and the generated one. Only the comments I wrote
were stripped.
The original redis-server.service are (obviously) identical to the
generated one.

I cannot test sentinel, but since it is generated from the same
template, it should work.

Many thanks for integrating that changes into the redis package!

Adrien

Bug#878100: iputils-ping: Please mark iputils-ping as Multi-Arch: foreign

[Ian Campbell]

Package: iputils-ping
Version: 3:20161105-1
Severity: wishlist
Tags: patch

I have an i386 system which I would like to update a subset of to amd64 (a
partial cross-grade). One of the packages which I need to install is
libmyth-29:amd64 (from dmo) which has a dependency on iputils-ping which cannot
be satisfied.

Marking the package as Multi-Arch: foreign would allow the i386 version to
satisfy the dependency.

>From https://wiki.ubuntu.com/MultiarchSpec, Multi-Arch: foreign means:

The package is not co-installable and should be allowed to satisfy the
dependencies of a package of another architecture than its own.

Since iputils-ping provides /bin/ping which behaves the same whether it is i386
or amd64 I think foreign is appropriate.

The patch is so trivial I almost hesitate to attach it, but here it is. I've
tested that with this iputils-ping:i386 installed libmyth-29:amd64's dependency
is satisfied.

I've not considered it, but I suspect that most of the other binary packages
produced by this source could be similarly annotated.

Thanks,
Ian.

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

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

Versions of packages iputils-ping depends on:
ii  libc6   2.24-17
ii  libcap2 1:2.25-1
ii  libidn111.33-2
ii  libnettle6  3.3-2

Versions of packages iputils-ping recommends:
ii  libcap2-bin  1:2.25-1

iputils-ping suggests no packages.

-- no debconf information
diff --git a/debian/control b/debian/control
index 275bf93..11752e2 100644
--- a/debian/control
+++ b/debian/control
@@ -12,6 +12,7 @@ Architecture: any
 Provides: ping
 Priority: important
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Multi-Arch: foreign
 Recommends: libcap2-bin
 Description: Tools to test the reachability of network hosts
  The ping command sends ICMP ECHO_REQUEST packets to a host in order to

Bug#878099: libhdhomerun: Please make libhdhomerun4 Multi-Arch: same

[Ian Campbell]

Source: libhdhomerun
Version: 20170930-1
Severity: wishlist
Tags: patch

Dear Maintainer,

Please move the libraries to /usr/lib/${DEB_HOST_MULTIARCH} and mark the
package as Multi-Arch: same to allow coinstallation of libhdhomerun4:i386 and
libhdhomerun4:amd64 (for example).

I've tested the attached and it works for me.

Note that I _removed_ the Multi-Arch: same annotation from libhdhomerun-dev,
since this installs files in /usr/include (rather than
/usr/include/${DEB_HOST_MULTIARCH}) I don't think libhdhomerun-dev:amd64 and
libhdhomerun-dev:i386 would be coinstallable as required. I don't need to
coinstall those though so feel free to ignore that change.

Thanks,
Ian.

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

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/control b/debian/control
index a2e8aee..56b81e4 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: libs
 Priority: optional
 Homepage: https://www.silicondust.com/support/linux/
 Maintainer: Francois Marier 
-Build-Depends: debhelper (>= 10), po-debconf
+Build-Depends: debhelper (>= 10), dh-exec (>=0.3), po-debconf
 Standards-Version: 4.1.1
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/libhdhomerun.git
 Vcs-Browser: https://anonscm.debian.org/git/collab-maint/libhdhomerun.git
@@ -27,6 +27,7 @@ Description: Configuration utility for Silicon Dust HD HomeRun
 Package: libhdhomerun4
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Multi-Arch: same
 Description: Library for Silicon Dust HD HomeRun
  This package supports the Silicon Dust HDHomeRun.
  The HDHomeRun is a networked, two tuner digital TV tuner compatible with
@@ -40,7 +41,6 @@ Section: libdevel
 Depends: libhdhomerun4 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
-Multi-Arch: same
 Description: Development library for Silicon Dust HD HomeRun
  This package supports the Silicon Dust HDHomeRun.
  The HDHomeRun is a networked, two tuner digital TV tuner compatible with
diff --git a/debian/libhdhomerun4.install b/debian/libhdhomerun4.install
old mode 100644
new mode 100755
index 6165713..72318fb
--- a/debian/libhdhomerun4.install
+++ b/debian/libhdhomerun4.install
@@ -1 +1,2 @@
-libhdhomerun.so.* /usr/lib
+#! /usr/bin/dh-exec
+libhdhomerun.so.* /usr/lib/${DEB_HOST_MULTIARCH}

Bug#861923: openvpn: arbitrary process limit

[Bernhard Schmidt]

On Fri, May 05, 2017 at 05:39:24PM -0400, Michael Stone wrote:

Control: tags -1 unreproducible

> Package: openvpn
> Version: 2.4.0-4
> Severity: normal
> 
> The systemd unit files for openvpn set LimitNPROC=10. This process limit
> applies to all processes started by a particular unit, so (for example) if
> there are 11 server .conf files the last one won't run. Or, with a smaller
> number of .conf files, subprocesses (scripts) could randomly fail. There is a
> note about this in README.Debian, but that note doesn't mention a likely error
> message associated with nproc issues (generally something about a fork error).
> I'd suggest adding a mention of fork errors as a symptom of the nproc limit
> being too low, but I'd also suggest a much higher default limit. It is not
> clear to me what problem a limit of 10 solves that wouldn't be solved by a
> limit of 1000, while a higher limit is much less likely to be hit through
> legitimate use.

The LimitNPROC=10 definition comes from the upstream units, i.e.
https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/openvpn-client%40.service.in

I'm not exactly sure why it was chosen this low, but I cannot reproduce
your issue. I think LimitNPROC=10 is _per_ _instance_. I could start 20 server 
instances just fine

for i in `seq 1 20`; do 
echo -e "dev tun\nifconfig 10.0.$i.1 10.0.$i.2\nsecret static.key\nport 
200$i" > server$i.conf
systemctl start openvpn@server$i
done

# pgrep openvpn | wc -l
20

Bernhard

Bug#871469: transition: ocaml

[Ximin Luo]

Simon McVittie:
> Control: block 871469 by 877548
> 
> On Mon, 25 Sep 2017 at 10:05:02 +0200, Stéphane Glondu wrote:
>> On 23/09/2017 15:52, Emilio Pozuelo Monfort wrote:
>>> That's alright. I see this is already started and binNMUs are needed. Is 
>>> someone
>>> from the ocaml team handling these, or should I?
>>
>> I am handling these.
> 
> Hi,
> Would it be possible to prioritize the rebuilds of lwt and ocaml-ctypes?
> They seem to be in the critical path to make llvm-toolchain-5.0 buildable
> again, which is breaking cross-architecture installability of Mesa, a
> relatively common configuration for i386 packages on amd64.
> 
> Unfortunately lwt currently fails to build from source (#877548). I notice
> that the test rebuild at 
> has a newer upstream release of lwt which hopefully addresses that?
> 

I'd support this too, since one of my other packages (rustc) is blocked on LLVM 
as well.

Is a new source upload of LWT all that's needed? I'd be happy to take care of 
that.

X

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

Bug#876885: fvwm: FvwmConsole can't be configured with X resources

[Jaimos Skriletz]

On Tue, Sep 26, 2017 at 11:05 PM, Danek Duvall  wrote:
>> I see this as a bug in the man page to clarify this. Namely the
>> default is FvwmConsole's resource is that of the terminal
>> x-terminal-emulator points uses. Also clarify that the example
>> resources were written for xterm with the -name FvwmConsole flag.
>
> I figured that would be the likely outcome.  That'd be okay by me.  But see
> below.
>
>> > For now, my workaround is to simply run FvwmConsole with the -name
>> > option explictly added to the commandline.
>>
>> I don't see this as a workaround, but how it should be handled in
>> Debian. If you want FvwmConsole's terminal to use a different resource
>> than your default terminal's resource for configuration, that is what
>> the -name feature is for. You can also use it in conjunction with the
>> -terminal option to ensure you are running a terminal that supports
>> it.
>
> I see it as a workaround because it requires explicit configuration where
> none should be necessary.  It seems obvious to me that one would want to
> use a different configuration from one's normal terminal emulator, since
> that's not really what's needed here.

This is a lot of personal opinion. To me I would rather not have a
separate terminal to configure for FvwmConsole by default, but the
option to create a separate config if I wanted. But I can see your way
too, which is more in the essence of the current upstream code.

> However, it occurred to me that there might be another way to do this.  I
> discovered the RESOURCE_NAME environment variable, which I'd never used
> before, but if I put
>
> setenv("RESOURCE_NAME", "FvwmConsole", 1);
>
> right before the execvp() call, it works perfectly, and should be
> completely ignored by non-X11-toolkit programs.  Using the environment
> makes sense here, since the process tree involved here is extremely minimal
> -- only FvwmConsoleC in addition to the terminal emulator, and it doesn't
> care.  In fact, I think this change (along with the one to remove -name)
> might be worth sending upstream.

This might overall be a better way to do it. This way FvwmConsole
won't pass the -name option, which is present in some (but not all)
terminals, to set the resource. To me this wouldn't remove -name
option from FvwmConsole, but only from FvwmConsole's call to the
terminal.

I am open for adapting the Debian patch to use this. I don't know
enough details here to help with the patch. If you would like to
submit a patch that does just this, I will forward it to upstream.

jaimos

Bug#865866: Bug still exists

[Angela B]

Hi, i must inform you that this bug exists with 
linux-image-4.9.0-4-686-pae and 4.9.0-3

-- System Information:
Debian Release: 9.2
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 libreoffice-writer depends on:
ii  dpkg   1.18.24
ii  libabw-0.1-1   0.1.1-4
ii  libc6  2.24-11+deb9u1
ii  libe-book-0.1-1    0.1.2-4
ii  libetonyek-0.1-1   0.1.6-5
ii  libgcc1    1:6.3.0-18
ii  libicu57   57.1-6
ii  libmwaw-0.3-3  0.3.9-2
ii  libodfgen-0.1-1    0.1.6-2
ii  libreoffice-base-core  1:5.2.7-1
ii  libreoffice-core   1:5.2.7-1
ii  librevenge-0.0-0   0.0.4-6
ii  libstdc++6 6.3.0-18
ii  libwpd-0.10-10 0.10.1-5+deb9u1
ii  libwpg-0.3-3   0.3.1-3
ii  libwps-0.4-4   0.4.5-1
ii  libxml2    2.9.4+dfsg1-2.2+deb9u1
ii  uno-libs3  5.2.7-1
ii  ure    5.2.7-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:5.2.7-1

Versions of packages libreoffice-writer suggests:
ii  default-jre [java5-runtime]    2:1.8-58
ii  fonts-crosextra-caladea    20130214-1
ii  fonts-crosextra-carlito    20130920-1
ii  libreoffice-base   1:5.2.7-1
pn  libreoffice-gcj    
ii  libreoffice-java-common    1:5.2.7-1
ii  openjdk-8-jre [java5-runtime]  8u141-b15-1~deb9u1

Versions of packages libreoffice-core depends on:
ii  fontconfig    2.11.0-6.7+b1
ii  fonts-opensymbol  2:102.7+LibO5.2.7-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-4
ii  libc6 2.24-11+deb9u1
ii  libcairo2 1.14.8-1
ii  libclucene-contribs1v5    2.3.3.4+dfsg-1
ii  libclucene-core1v5    2.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.1-8
ii  libcurl3-gnutls   7.52.1-5+deb9u1
ii  libdbus-1-3   1.10.22-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libdconf1 0.26.0-2+b1
ii  libeot0   0.01-4+b1
ii  libexpat1 2.2.0-2+deb9u1
ii  libexttextcat-2.0-0   3.4.4-2+b1
ii  libfontconfig1    2.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglew2.0    2.0.0-3+b1
ii  libglib2.0-0  2.50.3-2
ii  libgltf-0.0-0v5   0.0.2-5
ii  libglu1-mesa [libglu1]    9.0.0-2.1
ii  libgraphite2-3    1.3.10-1
ii  libharfbuzz-icu0  1.4.2-1
ii  libharfbuzz0b 1.4.2-1
ii  libhunspell-1.4-0 1.4.1-2+b2
ii  libhyphen0    2.8.8-5
ii  libice6   2:1.0.9-2
ii  libicu57  57.1-6
ii  libjpeg62-turbo   1:1.5.1-2
ii  liblangtag1   0.6.2-1
ii  liblcms2-2    2.8-4
ii  libldap-2.4-2 2.4.44+dfsg-5+deb9u1
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-2
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1.1
ii  libodfgen-0.1-1   0.1.6-2
ii  libpcre3  2:8.39-3
ii  libpng16-16   1.6.28-1
ii  librdf0   1.0.17-1.1
ii  libreoffice-common    1:5.2.7-1
ii  librevenge-0.0-0  0.0.4-6
ii  libsm6    2:1.2.2-1+b3
ii  libstdc++6    6.3.0-18
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxml2   2.9.4+dfsg1-2.2+deb9u1
ii  libxrandr2    2:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.1    1.1.29-2.1
ii  uno-libs3 5.2.7-1
ii  ure   5.2.7-1
ii  zlib1g    1:1.2.8.dfsg-5

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.24+nmu5

-- no debconf information

Bug#865866: Bug still exists

[Angela B]

Hi, i would like to inform you that this bug  still exists with 
linux-image-4.9.0-4-686-pae and 4.9.0-3

Bug#878098: libneo4j-client: FTBFS on hurd-i386: PATH_MAX undeclared

[Aaron M. Ucko]

Source: libneo4j-client
Version: 2.2.0-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org

Builds of libneo4j-client for hurd-i386 (admittedly not a release
architecture) have been failing:

  dotdir.c:37:15: error: 'PATH_MAX' undeclared (first use in this function); 
did you mean 'INT8_MAX'?

The Hurd has no fixed PATH_MAX.  Best practice is to avoid blindly
preallocating buffers, which typically results in wasting memory or
else truncation (or, worse, buffer overflows).  However, if that's not
feasible, you can look up _PC_PATH_MAX via pathconf, or supply your
own fallback constant (traditionally 4096).

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#878085: simple-cdd: Creating the mirror is failing due to missing files

[Vagrant Cascadian]

Control: merge 877987 878085
Control: reassign 878085 mirrors
Control: affects 878085 simple-cdd

On 2017-10-09, Andre Rodier wrote:
> When running simple-cdd --do-mirror, the program fails with one
> missing file. I have tried with multiple mirrors, but the file is
> missing on all of them.

It appears to be a problem on the mirrors.


> simple-cdd --do-mirror --locale en_US --dist stable
>
> [...]
>
> 2017-10-09 18:09:27,290 DEBUG skipping download: 
> /home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedication-5.0.txt
>  checksum matched
> 2017-10-09 18:09:27,290 DEBUG skipping download: 
> /home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedication-5.0.vi.txt
>  checksum matched
> 2017-10-09 18:09:27,290 DEBUG downloading: 
> /home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedication-9.0.bn.txt
> Traceback (most recent call last):

Several doc/dedication/dedication-9.0.* files present in extrafiles[1]
are missing from the mirrors. Since simple-cdd uses extrafiles to
determine which files to download, missing files cause it to fail.

You can workaround the issue by setting mirror_files='README tools/' in
profiles/default.conf until it gets fixed.

I've mentioned this on the #debian-mirrors IRC channel, and waldi fixed
it; it may take several hours to propegate.

[1] https://cdn-aws.deb.debian.org/debian/extrafiles


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#876979: openvpn@.service is missing network-online.target

[Bernhard Schmidt]

Control: found -1 2.4.0-6
Control: fixed -1 2.4.3-4

On 09.10.2017 20:50, Bernhard Schmidt wrote:

Hi,

>> Package: openvpn
>> Version: 2.4.0-6+deb9u1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> the provided openvpn@.service script is missing 2 lines:
>> After=syslog.target network-online.target
>> Wants=network-online.target
>>
>> Without these lines the openvpn starts too early and doesn't find
>> available network devices it could bind to.
> 
> Do you bind your OpenVPN instance to a specific IP address (i.e. by
> using the "local" configuration option)?
> 
> Otherwise OpenVPN should start just fine even when only "lo" is
> configured at this point.
> 
> I'm not sure we want to fix this globally. As far as I understood
> depending on "network-online.target" should be avoided if possible,
> since the point of "external connectivity is available" is not easily
> determined.
> 
> You can add this locally by executing
> 
> $ sudo systemctl add-wants openvpn@.service network-online.target

I fear I have to change my answer a bit.

1.) The requested change has already been done in Buster, in 2.4.3-4

2.) add-wants does not help a lot here, since we don't only need a
"Wants" but also an "After" relationship to order it. Can you please try
to add a file

/etc/systemd/system/openvpn@.service.d/after-network-online.conf

with the following content?

===
[Unit]
After=network-online.target
Wants=network-online.target
===

Bernhard

Bug#877196: Please fix lintian warnings

[Ghislain Vaillant]

On 09/10/17 19:14, Andreas Tille wrote:

Hi Ghislain

Please fix the following issues:

W: nfft source: unnecessary-testsuite-autopkgtest-header
W: libnfft3-2: transitional-package-should-be-oldlibs-optional oldlibs/extra


Both of these are already addressed. Are you building from the right 
tag? Otherwise, these could be false positives I guess?



W: libnfft3-doc: embedded-javascript-library 
usr/share/doc/libnfft3-doc/html/jquery.js please use libjs-jquery


That's the classic issue with the copy of jquery generated by doxygen. 
The Debian maintainer for src:doxygen recommends to not act on it, and I 
was told before to leave the warning as is instead of using an override.


Ghis

Bug#872611: lintian: Please warn on package using sensible-utils w/o relationship

[Chris Lamb]

Hi Guillem, et al.,

>   $ strings /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0.0 \
> | grep sensible-

Hm, is "strings" safe for this kind of thing? :)  As in, I fear too many
false-positives...


Best wishes,

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

Bug#878097: curl: FTBFS on kfreebsd-amd64: test 1061 hangs

[Aaron M. Ucko]

Source: curl
Version: 7.55.1-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org

Builds of curl for kfreebsd-amd64 (admittedly not a release
architecture) recently started failing:

  test 1060...OK (681 out of 1097, remaining: 03:16)
  test 1061...E: Caught signal ‘Terminated’: terminating immediately
  debian/rules:65: recipe for target 'override_dh_auto_test' failed
  make[1]: [override_dh_auto_test] Terminated (ignored)
  Makefile:1355: recipe for target 'test' failed
  make[2]: *** [test] Terminated
  debian/rules:23: recipe for target 'build-arch' failed
  make: *** [build-arch] Terminated
  Somebody sent me a SIGTERM at ./runtests.pl line 345.
  runtests.pl received SIGTERM, exiting
  Makefile:789: recipe for target 'quiet-test' failed
  make[3]: *** [quiet-test] Error 2
  Build killed with signal TERM after 150 minutes of inactivity

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#878086: Please fix "appstream-metadata-in-legacy-location usr/share/appdata/pyzo.appdata.xml"

[Ghislain Vaillant]

Hi Andreas,

On 09/10/17 19:09, Andreas Tille wrote:

Hi Ghislain,

please fix

W: pyzo: appstream-metadata-in-legacy-location 
usr/share/appdata/pyzo.appdata.xml
N:
N:AppStream metadata file was found in /usr/share/appdata/. The AppStream
N:XML files should be placed in /usr/share/metainfo/.
N:
N:Refer to https://wiki.debian.org/AppStream/Guidelines for details.
N:
N:Severity: minor, Certainty: certain
N:
N:Check: appstream-metadata, Type: binary


Done and retagged.


and may be also these

I: pyzo: font-in-non-font-package 
usr/share/pyzo/pyzo/resources/fonts/SourceCodePro-Bold.otf
N:
N:This package contains a *.ttf, *.otf, or *.pfb file, file extensions
N:used by TrueType, OpenType, or Type 1 fonts, but the package does not
N:appear to be a dedicated font package. Dedicated font package names
N:should begin with fonts-. (Type 1 fonts are also allowed in packages
N:starting with xfonts-.) If the font is already packaged, you should
N:depend on that package instead. Otherwise, normally the font should be
N:packaged separately, since fonts are usually useful outside of the
N:package that embeds them.
N:
N:Severity: wishlist, Certainty: possible
N:
N:Check: files, Type: binary, udeb
N:
I: pyzo: font-in-non-font-package 
usr/share/pyzo/pyzo/resources/fonts/SourceCodePro-Regular.otf


I remembered looking at packaging the SourceCodePro fonts for Debian. 
The build process was utterly horrible and I eventually gave up.



Kind regards and thanks for your work on these packages

  Andreas.

PS: Here comes my regular question about your DM application. :-P


I know I know XD

Cheers,
Ghis

Bug#878096: ayatana-indicator-session: FTBFS on alpha: test-actions fails

[Aaron M. Ucko]

Source: ayatana-indicator-session
Version: 0.4.0-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-al...@lists.debian.org

The build of ayatana-indicator-session for alpha (admittedly not a
release architecture) failed because test-actions encountered errors,
per the below excerpts from
https://buildd.debian.org/status/fetch.php?pkg=ayatana-indicator-session=alpha=0.4.0-2=1507406931=0.

Could you please take a look?

Thanks!



[ RUN  ] Actions.Reboot
/<>/tests/backend-dbus/test-actions.cc:225: Failure
  Expected: "reboot"
To be equal to: login1_manager->last_action()
  Which is: ""

** (process:5584): WARNING **: Unable to reboot: Operation was cancelled
[  FAILED  ] Actions.Reboot (883 ms)
[ RUN  ] Actions.PowerOff
/<>/tests/backend-dbus/test-actions.cc:238: Failure
Value of: end_session_dialog->is_open()
  Actual: false
Expected: true
[  FAILED  ] Actions.PowerOff (413 ms)
[ RUN  ] Actions.LogoutUnity
/<>/tests/backend-dbus/test-actions.cc:276: Failure
Value of: end_session_dialog->is_open()
  Actual: false
Expected: true
[  FAILED  ] Actions.LogoutUnity (463 ms)
[ RUN  ] Actions.LogoutGnome

** (process:5584): WARNING **: /<>/src/backend-dbus/actions.c:540 
on_desktop_logout_response: 
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 
'org.ayatana.Desktop.Session' on object at path /org/ayatana/Desktop/Session
/<>/tests/backend-dbus/test-actions.cc:314: Failure
Value of: end_session_dialog->is_open()
  Actual: false
Expected: true
[  FAILED  ] Actions.LogoutGnome (471 ms)
[...]
[--] Global test environment tear-down
[==] 18 tests from 1 test case ran. (7819 ms total)
[  PASSED  ] 14 tests.
[  FAILED  ] 4 tests, listed below:
[  FAILED  ] Actions.Reboot
[  FAILED  ] Actions.PowerOff
[  FAILED  ] Actions.LogoutUnity
[  FAILED  ] Actions.LogoutGnome

 4 FAILED TESTS

Start 3: test-guest
3/4 Test #3: test-guest ...   Passed1.02 sec
Start 4: test-users
4/4 Test #4: test-users ...   Passed1.52 sec

75% tests passed, 1 tests failed out of 4

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#878095: python-ipalib installation fails because of a syntax error in odsmgr.py

[David Heitman]

Package: python-ipalib
Version: 4.4.4-2
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?
 Attempted to upgrade to lastest pages, which included an update for
 freeipa* and python-ipalib.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Fixed the syntax in odsmgr.py on line 135, adding a missing colon
 to the end of the line
   * What was the outcome of this action?
 Able to complete the installation after the edit

@@ -132,7 +132,7 @@

 def get_ods_zonelist(self):
 stdout = self.ksmutil(['zonelist', 'export'])
-with open(paths.OPENDNSSEC_ZONELIST_FILE) as f:
+with open(paths.OPENDNSSEC_ZONELIST_FILE) as f
 reader = ODSZoneListReader(f.read())
 return reader

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

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

Versions of packages python-ipalib depends on:
ii  freeipa-common   4.4.4-2
ii  gnupg-agent  2.2.1-1
ii  gnupg2   2.2.1-1
ii  gpg-agent [gnupg-agent]  2.2.1-1
ii  keyutils 1.5.9-9
ii  python   2.7.14-1
ii  python-cffi  1.9.1-2
ii  python-cryptography  1.9-1
ii  python-custodia  0.1.0-6
ii  python-dbus  1.2.4-1+b2
ii  python-dnspython 1.15.0-1
ii  python-gssapi1.2.0-1+b2
ii  python-jwcrypto  0.3.2-1
ii  python-ldap  2.4.41-1
ii  python-libipa-hbac   1.15.3-1
ii  python-lxml  4.0.0-1
ii  python-memcache  1.57-2
ii  python-netaddr   0.7.18-2
ii  python-netifaces 0.10.4-0.1+b3
ii  python-nss   1.0.0-1+b1
ii  python-pyasn10.1.9-2
ii  python-qrcode5.3-1
ii  python-requests  2.18.1-1
ii  python-setuptools36.2.7-2
ii  python-six   1.11.0-1
ii  python-usb   1.0.0-1
ii  python-yubico1.3.2-1

python-ipalib recommends no packages.

python-ipalib suggests no packages.

-- no debconf information


-- PRIVILEGED AND CONFIDENTIAL This transmission may contain privileged, 
proprietary or confidential information. If you are not the intended recipient, 
you are instructed not to review this transmission. If you are not the intended 
recipient, please notify the sender that you received this message and delete 
this transmission from your system.

Bug#878094: ayatana-indicator-power: FTBFS on non-Linux: No package 'gudev-1.0' found

[Aaron M. Ucko]

Source: ayatana-indicator-power
Version: 2.0.91-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org

Builds of ayatana-indicator-power for hurd-i386 and kfreebsd-*
(admittedly not release architectures) have been failing:

  -- Checking for modules 
'glib-2.0>=2.36;gio-2.0>=2.36;gio-unix-2.0>=2.36;gudev-1.0>=204;libnotify>=0.7.6'
  --   No package 'gudev-1.0' found

The build dependency on libgudev-1.0-dev specifies [linux-any], but
CMakeLists.txt evidently expects gudev-1.0 on non-Linux architectures
too.  I suspect the same goes for systemd, but haven't specifically
checked.  Could you please take a look and resolve any discrepancies
one way or another?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#876979: openvpn@.service is missing network-online.target

[Bernhard Schmidt]

On 27.09.2017 12:05, Markus Kolb wrote:

Hi Markus,

> Package: openvpn
> Version: 2.4.0-6+deb9u1
> Severity: normal
> 
> Dear Maintainer,
> 
> the provided openvpn@.service script is missing 2 lines:
> After=syslog.target network-online.target
> Wants=network-online.target
> 
> Without these lines the openvpn starts too early and doesn't find
> available network devices it could bind to.

Do you bind your OpenVPN instance to a specific IP address (i.e. by
using the "local" configuration option)?

Otherwise OpenVPN should start just fine even when only "lo" is
configured at this point.

I'm not sure we want to fix this globally. As far as I understood
depending on "network-online.target" should be avoided if possible,
since the point of "external connectivity is available" is not easily
determined.

You can add this locally by executing

$ sudo systemctl add-wants openvpn@.service network-online.target

Bernhard

Bug#771885: closed by Jörg Frings-Fürst <deb...@jff-webhosting.net> (reply to deb...@jff-webhosting.net) (Re: openvpn service script restarted, ignoring LSB header)

[Bernhard Schmidt]

Hi Harald,

On 09.10.2017 07:30, Harald Dunkel wrote:
> Sorry to say, but you missunderstood the problem: openvpn was 
> not supposed to be run in runlevel 2 in my setup. The run level 
> definition must not be ignored.
> 
> About screen: I got locked out due to changed routing, not due 
> to a lost terminal connection. The ssh connection was cut off 
> and couldn't be established anymore. I don't see how screen 
> could have helped here.
> 
> Please reopen and fix.

Can you still reproduce this with a supported version (preferably stretch)?

Bernhard

Bug#878093: ayatana-indicator-power: FTBFS on arm64: test-notify fails

[Aaron M. Ucko]

Source: ayatana-indicator-power
Version: 2.0.91-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org

The arm64 build of ayatana-indicator-power failed, apparently because
test-notify had trouble connecting to DBusMock, per the below excerpts
from

https://buildd.debian.org/status/fetch.php?pkg=ayatana-indicator-power=arm64=2.0.91-2=1507411792=0

Could you please take a look?

Thanks!



1/3 Test #1: test-notify ..***Failed   25.80 sec
Running main() from gtest_main.cc
[==] Running 4 tests from 1 test case.
[--] Global test environment set-up.
[--] 4 tests from NotifyFixture
[ RUN  ] NotifyFixture.HelloWorld
DBus daemon: 
unix:abstract=/tmp/dbus-9LBD5PIEgl,guid=553a17948d5360f883f7522c59d946e2
DBusMock: Started with PID: 11819
DBusMock: Shutting down
DBus daemon: Shutdown
[   OK ] NotifyFixture.HelloWorld (5297 ms)
[ RUN  ] NotifyFixture.PercentageToLevel
DBus daemon: 
unix:abstract=/tmp/dbus-fNiLXGc7Jw,guid=674296bcb05145b08cd2a3ff59d946e7
DBusMock-1: Started with PID: 11829
DBusMock-1: Shutting down
DBus daemon: Shutdown
/<>/tests/glib-fixture.h:51: Failure
  Expected: expected_log[level]
  Which is: 0
To be equal to: n
  Which is: 3
4 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
4 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
4 libdbustest:8 "Unable to build proxy to DBusMock: The connection is closed"
[  FAILED  ] NotifyFixture.PercentageToLevel (5020 ms)
[ RUN  ] NotifyFixture.LevelsDuringBatteryDrain
DBus daemon: 
unix:abstract=/tmp/dbus-VAZWJ0oWwB,guid=773c7afede9f99f6b61665b659d946ed
DBusMock-2: Started with PID: 11838
/<>/tests/test-notify.cc:313: Failure
  Expected: FIELD_POWER_LEVEL
  Which is: 1
To be equal to: (changed_params.fields & FIELD_POWER_LEVEL)
  Which is: 0
[...]
DBusMock-2: Shutting down
DBus daemon: Shutdown
/<>/tests/glib-fixture.h:51: Failure
  Expected: expected_log[level]
  Which is: 0
To be equal to: n
  Which is: 21
22 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
22 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
22 libdbustest:8 "Unable to build proxy to DBusMock: The connection is closed"
22 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
[...]
22 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
/<>/tests/glib-fixture.h:51: Failure
  Expected: expected_log[level]
  Which is: 0
To be equal to: n
  Which is: 1
2 libnotify:16 "Failed to connect to proxy"
[  FAILED  ] NotifyFixture.LevelsDuringBatteryDrain (10140 ms)
[ RUN  ] NotifyFixture.EventsThatChangeNotifications
DBus daemon: 
unix:abstract=/tmp/dbus-XhvKyL4bqT,guid=11e02c6b76f9815002710fc259d946f7
DBusMock-3: Started with PID: 11848
/<>/tests/test-notify.cc:376: Failure
  Expected: FIELD_POWER_LEVEL|FIELD_IS_WARNING
  Which is: 3
To be equal to: changed_params.fields
  Which is: 0
[...]
23 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
23 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
23 libdbustest:8 "Unable to build proxy to DBusMock: The connection is closed"
23 libdbustest:8 "dbus_test_dbus_mock_object_add_method: assertion 'proxy != 
NULL' failed"
23 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
[...]
23 GLib-GIO:8 "Error while sending AddMatch() message: The connection is closed"
/<>/tests/glib-fixture.h:51: Failure
  Expected: expected_log[level]
  Which is: 0
To be equal to: n
  Which is: 1
2 libnotify:16 "Failed to connect to proxy"
[  FAILED  ] NotifyFixture.EventsThatChangeNotifications (5327 ms)
[--] 4 tests from NotifyFixture (25784 ms total)

[--] Global test environment tear-down
[==] 4 tests from 1 test case ran. (25784 ms total)
[  PASSED  ] 1 test.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] NotifyFixture.PercentageToLevel
[  FAILED  ] NotifyFixture.LevelsDuringBatteryDrain
[  FAILED  ] NotifyFixture.EventsThatChangeNotifications

 3 FAILED TESTS

Start 2: dear-reader-the-next-test-takes-80-seconds
2/3 Test #2: dear-reader-the-next-test-takes-80-seconds ...   Passed0.01 sec
Start 3: test-device
3/3 Test #3: test-device ..   Passed   80.23 sec

67% tests passed, 1 tests failed out of 3

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#876398: mysqltest can't read config proberly

[Ondřej Surý]

Control: severity -1 minor

Hi Jörg,

thank you for filling the bug. I am going to investigate the bug, I'll just
downgrade the severity. A configuration error in regression test suite that
can be fixed by editing the configuration is hardly a grave bug.

Ondrej

On Thu, 21 Sep 2017 at 20:15 Jörg Frings-Fürst 
wrote:

> Package: mariadb-test
> Version: 10.1.26-0+deb9u1
> Severity: grave
>
> Hello,
>
>
> if I run mysqltest I get:
>
> > mysqltest
> mysqltest: unknown variable 'default-character-set=utf8mb4'
>
> mysqltest stops after that message and isn't useable.
>
> CU
> Jörg
>
>
>
> -- System Information:
> Debian Release: 9.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-3-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)
>
> Versions of packages mariadb-test depends on:
> ii  libaio1  0.3.110-3
> ii  libc62.24-11+deb9u1
> ii  libmariadbclient18   10.1.26-0+deb9u1
> ii  libpcre3 2:8.39-3
> ii  libstdc++6   6.3.0-18
> ii  mariadb-client-10.1  10.1.26-0+deb9u1
> ii  mariadb-server-10.1  10.1.26-0+deb9u1
> ii  mariadb-test-data10.1.26-0+deb9u1
> ii  zlib1g   1:1.2.8.dfsg-5
>
> mariadb-test recommends no packages.
>
> Versions of packages mariadb-test suggests:
> ii  patch  2.7.5-1+b2
>
> -- no debconf information
>
-- 
Ondřej Surý 

Bug#878091: jq: accepts invalid JSON

[Thorsten Glaser]

Package: jq
Version: 1.5+dfsg-2
Severity: important
Tags: upstream

jq silently accepts illegal JSON:

tglase@tglase:~ $ jq <<<'[0,01,2]'
[
  0,
  1,
  2
]
tglase@tglase:~ $ jsn <<<'[0,01,2]'
JSON decoding of input failed: {
  "input": "[0,01,2]\n",
  "message": "missing comma in Array at offset 0x4"
}

A Number may not have a leading zero. Secondary reference:
http://www.json.org/JSON_checker/test.zip

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

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

Versions of packages jq depends on:
ii  libc6 2.24-17
ii  libjq11.5+dfsg-2
ii  libonig4  6.6.1-1

jq recommends no packages.

jq suggests no packages.

-- no debconf information

Bug#878092: linux-image-4.13.0-1-amd64: hung thread(s) : Workqueue: phy0 ieee80211_ba_session_work [mac80211]

[Eric Côté]

Package: src:linux
Version: 4.13.4-1
Severity: normal

Not running the kernel affected:
a) too many tolerable issues, constant journal spam with wpa_supplicant
and hung threads (will paste the kernel msg dump I had before)
b) issues with email now resolved (hopefully)

Sorry about this, but can't be helped.

Patch found in this LKML thread:

https://lkml.org/lkml/2017/9/6/489

WLAN module: ath10k_pci :03:00.0

I started getting this as sson as I connected the WLAN.

= >8 =
Oct  9 13:27:34 asuslap kernel: [  967.645932] INFO: task kworker/u8:1:119 
blocked for more than 120 seconds.
Oct  9 13:27:34 asuslap kernel: [  967.645936]   Not tainted 4.13.0-1-amd64 
#1 Debian 4.13.4-1
Oct  9 13:27:34 asuslap kernel: [  967.645937] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct  9 13:27:34 asuslap kernel: [  967.645938] kworker/u8:1D0   119 
 2 0x
Oct  9 13:27:34 asuslap kernel: [  967.645963] Workqueue: phy0 
ieee80211_ba_session_work [mac80211]
Oct  9 13:27:34 asuslap kernel: [  967.645965] Call Trace:
Oct  9 13:27:34 asuslap kernel: [  967.645970]  ? __schedule+0x3c8/0x860
Oct  9 13:27:34 asuslap kernel: [  967.645971]  ? schedule+0x32/0x80
Oct  9 13:27:34 asuslap kernel: [  967.645972]  ? 
schedule_preempt_disabled+0xa/0x10
Oct  9 13:27:34 asuslap kernel: [  967.645973]  ? 
__mutex_lock.isra.1+0x2c3/0x4f0
Oct  9 13:27:34 asuslap kernel: [  967.645984]  ? 
__ieee80211_start_rx_ba_session+0x167/0x500 [mac80211]
Oct  9 13:27:34 asuslap kernel: [  967.645993]  ? 
__ieee80211_start_rx_ba_session+0x167/0x500 [mac80211]
Oct  9 13:27:34 asuslap kernel: [  967.645995]  ? sched_clock+0x5/0x10
Oct  9 13:27:34 asuslap kernel: [  967.645997]  ? sched_clock_cpu+0xc/0xb0
Oct  9 13:27:34 asuslap kernel: [  967.646007]  ? 
ieee80211_ba_session_work+0x154/0x240 [mac80211]
Oct  9 13:27:34 asuslap kernel: [  967.646009]  ? __schedule+0x3d0/0x860
Oct  9 13:27:34 asuslap kernel: [  967.646011]  ? process_one_work+0x181/0x370
Oct  9 13:27:34 asuslap kernel: [  967.646012]  ? worker_thread+0x4d/0x3a0
Oct  9 13:27:34 asuslap kernel: [  967.646014]  ? kthread+0xfc/0x130
Oct  9 13:27:34 asuslap kernel: [  967.646015]  ? process_one_work+0x370/0x370
Oct  9 13:27:34 asuslap kernel: [  967.646017]  ? 
kthread_create_on_node+0x70/0x70
Oct  9 13:27:34 asuslap kernel: [  967.646019]  ? ret_from_fork+0x25/0x30
= >8 =


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: X756UAK
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: X756UAK.307
board_vendor: ASUSTeK COMPUTER INC.
board_name: X756UAK
board_version: 1.0   

** Network interface configuration:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core 
Processor Host Bridge/DRAM Registers [8086:5904] (rev 02)
Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v6/7th Gen Core Processor 
Host Bridge/DRAM Registers [1043:14d0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 620 
[8086:5916] (rev 02) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. HD Graphics 620 [1043:14d0]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Skylake 
Processor Thermal Subsystem [8086:1903] (rev 02)
Subsystem: ASUSTeK Computer Inc. Skylake Processor Thermal Subsystem 
[1043:14d0]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device

00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller [8086:9d2f] (rev 21) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Sunrise Point-LP USB 3.0 xHCI 
Controller [1043:201f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP 
Thermal subsystem [8086:9d31] (rev 21)
Subsystem: ASUSTeK Computer Inc. Sunrise Point-LP Thermal subsystem 

Bug#878090: xchain: Couldn't execute /usr/bin/wish

[Andrej Mernik]

Package: xchain
Version: 1.0.1-7
Severity: grave
Justification: renders package unusable

Dear Maintainer,

when trying to run the game it fails to run and outputs:

Couldn't execute /usr/bin/wish

The executable present in Stretch seems to be named differently:

$ ls /usr/bin/wish*
/usr/bin/wish8.5

The path to the executable seems to be hardcoded in xchain.c line 32

Best Regards,
Andrej Mernik



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

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

Versions of packages xchain depends on:
ii  libc6  2.24-11+deb9u1
ii  tk8.5  8.5.19-1+b1

xchain recommends no packages.

xchain suggests no packages.

-- no debconf information

Bug#877196: Please fix lintian warnings

[Andreas Tille]

Hi Ghislain

Please fix the following issues:

W: nfft source: unnecessary-testsuite-autopkgtest-header
W: libnfft3-2: transitional-package-should-be-oldlibs-optional oldlibs/extra
W: libnfft3-doc: embedded-javascript-library 
usr/share/doc/libnfft3-doc/html/jquery.js please use libjs-jquery

Thanks again for working on these packages - thanks even more if gaining
upload permissions to free me from sponsoring your packages :-P

   Andreas.

-- 
http://fam-tille.de

Bug#878087: qemu-system-x86: xmodmap + qemu, keyboard settings is ignored

[Michael Tokarev]

09.10.2017 20:34, Antonio wrote:
> Package: qemu-system-x86
> Version: 1:2.10.0+dfsg-2
> 
> Dear Maintainer,
> 
> if you modify some keys with xmodmap (eg: xmodmap -e "keycode 91=Delete" -e 
> "keycode 90=Insert" -e "keycode 79=Home" -e "keycode 87=End" -e "keycode 
> 81=Prior" -e "keycode 89=Next")
> and then run qemu-system-x86_64, keyboard setting (-k it) is ignored and 
> en-us keyboard is set as default.
> 
> With previous version 1:2.10.0+dfsg-1 there was no problem.

It looks like this is a wontfix bug. The "problem" seems to be that
more recent ui frontends (sdl2 which is enabled in -2 compared to
obsolete sdl1 used before, and gtk to be enabled later), keyboard
handling has been reworked, and qemu now always uses raw keycodes,
not preprocessed by modmap and other tools, with guest being able
to see all keyboard keys.  You have to use xmodmap INSIDE the guest
to achieve what you want.

Thanks,

/mjt

Bug#878086: Please fix "appstream-metadata-in-legacy-location usr/share/appdata/pyzo.appdata.xml"

[Andreas Tille]

Hi Ghislain,

please fix

W: pyzo: appstream-metadata-in-legacy-location 
usr/share/appdata/pyzo.appdata.xml
N: 
N:AppStream metadata file was found in /usr/share/appdata/. The AppStream
N:XML files should be placed in /usr/share/metainfo/.
N:
N:Refer to https://wiki.debian.org/AppStream/Guidelines for details.
N:
N:Severity: minor, Certainty: certain
N:
N:Check: appstream-metadata, Type: binary


and may be also these

I: pyzo: font-in-non-font-package 
usr/share/pyzo/pyzo/resources/fonts/SourceCodePro-Bold.otf
N: 
N:This package contains a *.ttf, *.otf, or *.pfb file, file extensions
N:used by TrueType, OpenType, or Type 1 fonts, but the package does not
N:appear to be a dedicated font package. Dedicated font package names
N:should begin with fonts-. (Type 1 fonts are also allowed in packages
N:starting with xfonts-.) If the font is already packaged, you should
N:depend on that package instead. Otherwise, normally the font should be
N:packaged separately, since fonts are usually useful outside of the
N:package that embeds them.
N:
N:Severity: wishlist, Certainty: possible
N:
N:Check: files, Type: binary, udeb
N: 
I: pyzo: font-in-non-font-package 
usr/share/pyzo/pyzo/resources/fonts/SourceCodePro-Regular.otf


Kind regards and thanks for your work on these packages

 Andreas.

PS: Here comes my regular question about your DM application. :-P


-- 
http://fam-tille.de

Bug#860360: okular: I can confirm the bug with czech accents. Create a folder with accents, place a pdf file inside, cannot open the pdf from Dolphin. If immediately try to open from okular, the p

[lpohl]

I can confirm that this helped resolve the issue. Thank you very much!
Leos
__
> Od: Michael Weghorn 
> Komu: lp...@centrum.cz, 860...@bugs.debian.org
> Datum: 05.10.2017 22:25
> Předmět: Re: Bug#860360: okular: I can confirm the bug with czech accents.
>
Thanks for the additional information. As far as I understand it so far,
 this is not really an Okular problem, but one of your locale settings.
 
 Can you please try the following:
 
 * open a terminal
 * run the following command there: "sudo dpkg-reconfigure locales"
 * select "cs_CZ.UTF-8" and confirm so that the respective locale is
 generated
 
 (There may be ways to generate the locales using the graphical user
 interface instead, but that depends on the specific desktop environment
 in use. Please let me know in case the above steps are not clear enough.)
 
 Regards,
  Michael
 
 
 
 
 
 On 2017-10-05 18:21, lp...@centrum.cz wrote:
 > 
 > I have more details. In my case, I had in System settings -> Regional
 > settings -> Formats:
 > Region: United States - American English (en_US)
 > Detailed settings enabled and time format set to Czech (cs_CZ). With
 > this particular settings I can reproduce the problem plus I get the
 > errors with locale. Once I switch this settings to "No change" are
 > logout and log back in, Okular opens pdf files in a path with accents
 > without a problem. I have confirmed it twice.
 > 
 >  
 > 
 > The locale outputs with the time set to "No change":
 > 
 > LANG=en_US.UTF-8
 > LANGUAGE=
 > LC_CTYPE="en_US.UTF-8"
 > LC_NUMERIC="en_US.UTF-8"
 > LC_TIME="en_US.UTF-8"
 > LC_COLLATE="en_US.UTF-8"
 > LC_MONETARY="en_US.UTF-8"
 > LC_MESSAGES="en_US.UTF-8"
 > LC_PAPER="en_US.UTF-8"
 > LC_NAME="en_US.UTF-8"
 > LC_ADDRESS="en_US.UTF-8"
 > LC_TELEPHONE="en_US.UTF-8"
 > LC_MEASUREMENT="en_US.UTF-8"
 > LC_IDENTIFICATION="en_US.UTF-8"
 > LC_ALL=
 > 
 >  and this is the output of locale when I change time format to czech
 > (with region en_US):
 > 
 > locale: Cannot set LC_ALL to default locale: No such file or directory
 > LANG=en_US.UTF-8
 > LANGUAGE=
 > LC_CTYPE="en_US.UTF-8"
 > LC_NUMERIC="en_US.UTF-8"
 > LC_TIME=cs_CZ.UTF-8
 > LC_COLLATE="en_US.UTF-8"
 > LC_MONETARY="en_US.UTF-8"
 > LC_MESSAGES="en_US.UTF-8"
 > LC_PAPER="en_US.UTF-8"
 > LC_NAME="en_US.UTF-8"
 > LC_ADDRESS="en_US.UTF-8"
 > LC_TELEPHONE="en_US.UTF-8"
 > LC_MEASUREMENT="en_US.UTF-8"
 > LC_IDENTIFICATION="en_US.UTF-8"
 > LC_ALL=
 > 
 >  
 > 
 > Leos
 > 
 >  
 > 
 > __
 >> Od: Michael Weghorn 
 >> Komu: Leoš Pohl , 860...@bugs.debian.org
 >> Datum: 04.10.2017 21:18
 >> Předmět: Re: Bug#860360: okular: I can confirm the bug with czech accents.
 >>
 > Hi Leoš,
 > 
 > thanks for reporting that you also have this issue.
 > 
 > On 2017-10-04 18:42, Leoš Pohl wrote:
 >>
 >> -- debconf information:
 >> perl: warning: Setting locale failed.
 >> perl: warning: Please check that your locale settings:
 >> LANGUAGE = "",
 >> LC_ALL = (unset),
 >> LC_TIME = "cs_CZ.UTF-8",
 >> LANG = "en_US.UTF-8"
 >>     are supported and installed on your system.
 >> perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
 >> locale: Cannot set LC_ALL to default locale: No such file or directory
 >>
 > 
 > The above output indicates that something seems to be wrong with your
 > locale settings.
 > 
 > Can you please post the output of the command "locale"?
 > 
 > Does the problem go away if the respective locales are generated?
 > You can have them generated by running the command "dpkg-reconfigure"
 > (with root privileges) and selecting the corresponding locales. (The
 > above output suggests that those are "cs_CZ.UTF-8" and "en_US.UTF-8" in
 > your case.)
 > 
 > 
 > Regards,
 >  Michael
 >

Bug#878089: RFS: dcm2niix/1.0.20170923-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name    : dcm2niix
  Version : 1.0.20170923-1
  Upstream Author : Chris Rorden
* URL : https://github.com/rordenlab/dcm2niix
* License : BSD
  Section : science

One can check out the package by visiting the following URL:

https://anonscm.debian.org/cgit/debian-med/dcm2niix.git

Changes since the last upload:

  * New upstream version 1.0.20170923
  * Bump the standards version to 4.1.1

Regards,
Ghis

Bug#878069: [Pkg-xfce-devel] Bug#878069: lightdm: xdmcp broken

[Anton Ivanov]

This looks related.

https://ubuntuforums.org/showthread.php?t=2332313

It smells like something similar - not doing the correct auth for the X 
connection resulting in an IO error which immediately terminates the 
session. Anything else would have been less immediate (it returns to the 
login screen straight away).


A

On 10/09/17 15:02, Yves-Alexis Perez wrote:

On Mon, 2017-10-09 at 14:03 +0100, Anton Ivanov wrote:

After upgrade to stretch XDMCP no longer works. Setup has worked
virtually unchanged for a decade, with the last 5+ years using
lightdm.

Lightdm shows a greeter, you can enter username and password
after which it bombs out straight back to greeter.

Hi,

thanks for the report. Unfortunately I don't have an XDMCP setup so I can't
really test that, you'll have to investigate that by yourself.

Regards,

Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Markus Koschany]

Package: reportbug
Version: 7.1.7
Severity: wishlist
Tags: patch


Hi,

the Debian LTS Team and the Debian Security Team would like to propose
a new feature for reportbug.

We discussed this at DebConf 17 during the LTS BoF and shortly on
debian-lts [1] that it would make sense to inform both teams about
regressions introduced by security updates. We usually receive
word from the maintainer or users who report issues directly to
our mailing lists or IRC channels.

However we have also discovered that some regressions were never
reported to us. Hence we propose the following feature for reportbug:

If the bug is reported against a package with a version number that
indicates a security update like +deb7u1 or ~deb8u3, both team mailing
lists should be added to CC after the bug reporter confirms that this
is a regression caused by a security update. The confirmation check is
necessary to prevent too many false positives since similar version
strings are used for regular stable updates. However the default is true
because it is better to receive one e-mail too many as to miss the
regression. Of course this could be changed if it turns out that we
receive too many unwarranted reports.

Please find attached my proposed patch.

Regards,

Markus

[1] https://lists.debian.org/debian-lts/2017/08/msg00034.html
diff -Nru reportbug-7.1.7/bin/reportbug reportbug-7.1.7+nmu1/bin/reportbug
--- reportbug-7.1.7/bin/reportbug   2017-05-29 22:00:17.0 +0200
+++ reportbug-7.1.7+nmu1/bin/reportbug  2017-10-09 01:26:16.0 +0200
@@ -1926,6 +1926,22 @@
 listcc += ui.get_multiline(
 'Enter any additional addresses this report should be sent to; 
press ENTER after each address.')
 
+# If the bug is reported against a package with a version that
+# indicates a security update add the security and lts teams to CC
+# after user confirmation
+is_security_update = False
+if pkgversion:
+regex = re.compile('(\+|~)deb\d+u\d+')
+if regex.search(pkgversion):
+if ui.yes_no('Do you want to report a regression because of a 
security update? ',
+ 'Yes, please inform the LTS and security teams.',
+ 'No or I am not sure.', True):
+is_security_update = True
+
+if is_security_update:
+email_address = 
['debian-...@lists.debian.org','t...@security.debian.org']
+listcc.extend(email_address)
+
 if severity and rtype:
 severity = debbugs.convert_severity(severity, rtype)
 

Bug#878072: [Pkg-mozext-maintainers] Bug#878072: Please upgrade to more recent version to be compatible with Firefox 57

[Sean Whitton]

control: forcemerge 877040 -1

Hello Laurent,

On Mon, Oct 09 2017, Laurent Bigonville wrote:

> Firefox 57 is now in experimental and ublock-origin currently in
> debian is not compatible with that version.
>
> Could you please upgrade to an higher version? 1.14.14 seems to work.

Please see discussion in #877040.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#878087: qemu-system-x86: xmodmap + qemu, keyboard settings is ignored

[Antonio]

Package: qemu-system-x86
Version: 1:2.10.0+dfsg-2

Dear Maintainer,

if you modify some keys with xmodmap (eg: xmodmap -e "keycode
91=Delete" -e "keycode 90=Insert" -e "keycode 79=Home" -e "keycode
87=End" -e "keycode 81=Prior" -e "keycode 89=Next")
and then run qemu-system-x86_64, keyboard setting (-k it) is ignored
and en-us keyboard is set as default.

With previous version 1:2.10.0+dfsg-1 there was no problem.

Thanks

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

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

Versions of packages qemu depends on:
pn  qemu-system  
pn  qemu-user
pn  qemu-utils   

qemu recommends no packages.

Versions of packages qemu suggests:
pn  qemu-user-static  

-- no debconf information

Bug#878086: RFS: pyzo/4.4.3-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: pyzo
  Version : 4.4.3-1
  Upstream Author : Almar Klein
* URL :http://www.pyzo.org/
* License : BSD
  Section : science

Please check out the package by visiting the following URL:

  https://anonscm.debian.org/cgit/debian-science/packages/pyzo.git

Changes since the last upload:

  * Add recommended get-orig-source target
  * New upstream version 4.4.3
  * Move iep package to oldlibs/optional
  * Bump the standards version to 4.1.1

Best regards,
Ghis

Bug#878084: xserver-xorg-core: XShmGetImage() improperly crops returned image (regression from 1.18.4)

[Dmitry Shachnev]

Package: xserver-xorg-core
Version: 2:1.19.3-2
Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=101730
Affects: gnome-flashback

Dear maintainers,

As the upstream bug says, in xorg-server 1.19.3, XShmGetImage() incorrectly
crops the image grab to the absolute region (x,y)-(x+w,y+h). The comments in
that bug also contain instructions on how to reproduce it.

This affects gnome-flashback, where screenshots of CSD windows get broken.

If there is no easy way to fix it, maybe you can temporarily revert upstream
commit [1] or at least part of it?

[1]: https://cgit.freedesktop.org/xorg/xserver/commit/?id=6c6f09aac7f1d136

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#878085: simple-cdd: Creating the mirror is failing due to missing files

[Andre Rodier]

Package: simple-cdd
Version: 0.6.5
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

When running simple-cdd --do-mirror, the program fails with one missing file. I 
have tried with multiple mirrors, but the file is missing on all of them.

Below an example on what is happening.

---
simple-cdd --do-mirror --locale en_US --dist stable

[...]

2017-10-09 18:09:27,290 DEBUG skipping download: 
/home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedication-5.0.txt
 checksum matched
2017-10-09 18:09:27,290 DEBUG skipping download: 
/home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedication-5.0.vi.txt
 checksum matched
2017-10-09 18:09:27,290 DEBUG downloading: 
/home/seequestor/Projects/simple-cdd/tmp/mirror/doc/dedication/dedication-9.0.bn.txt
Traceback (most recent call last):
  File "/usr/bin/simple-cdd", line 658, in 
scdd.build_mirror()
  File "/usr/bin/simple-cdd", line 270, in build_mirror
self.run_tool("mirror", tool)
  File "/usr/bin/simple-cdd", line 367, in run_tool
tool.run()
  File "/usr/lib/python3/dist-packages/simple_cdd/tools/mirror_wget.py", line 
93, in run
_download(x["url"], x["absname"], checksums=extrafile_sums, 
relname=x["relname"])
  File "/usr/lib/python3/dist-packages/simple_cdd/tools/mirror_wget.py", line 
55, in _download
request.urlretrieve(url, filename=output)
  File "/usr/lib/python3.5/urllib/request.py", line 188, in urlretrieve
with contextlib.closing(urlopen(url, data)) as fp:
  File "/usr/lib/python3.5/urllib/request.py", line 163, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python3.5/urllib/request.py", line 472, in open
response = meth(req, response)
  File "/usr/lib/python3.5/urllib/request.py", line 582, in http_response
'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.5/urllib/request.py", line 504, in error
result = self._call_chain(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 444, in _call_chain
result = func(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 696, in http_error_302
return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.5/urllib/request.py", line 472, in open
response = meth(req, response)
  File "/usr/lib/python3.5/urllib/request.py", line 582, in http_response
'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.5/urllib/request.py", line 510, in error
return self._call_chain(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 444, in _call_chain
result = func(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 590, in http_error_default
raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 404: Not Found

---

*** End of the template - remove these template lines ***


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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-2+b1
ii  debian-cd   3.1.20
ii  lsb-release 9.20161125
ii  python3 3.5.3-1
ii  python3-simple-cdd  0.6.5
ii  reprepro5.1.1-1
ii  rsync   3.1.2-1
ii  wget1.18-5

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-8

Versions of packages simple-cdd suggests:
ii  qemu-kvm 1:2.8+dfsg-6+deb9u3
ii  qemu-system  1:2.8+dfsg-6+deb9u3

-- no debconf information

Bug#878074: Update virtualbox-guest-* will remove a well running ntp

[Jörg Frings-Fürst]

reopen 878074 
thanks

Hello,

Am Montag, den 09.10.2017, 16:56 +0200 schrieb Gianfranco Costamagna:
> On Mon, 09 Oct 2017 16:48:00 +0200 =?utf-8?q?J=C3=B6rg_Frings-F=C3=BCrst?= 
>  wrote:
> > Package: virtualbox-guest-utils
> > Version: 5.1.28-dfsg-1
> > Severity: serious
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Hello,
> > 
> > on update I get :
> > 
> > [quote]
> > $ sudo apt-get install virtualbox-guest-dkms
> > Paketlisten werden gelesen... Fertig
> > Abhängigkeitsbaum wird aufgebaut.
> > Statusinformationen werden eingelesen Fertig
> > Die folgenden Pakete wurden automatisch installiert und werden nicht mehr
> > benötigt:
> >   gir1.2-nm-1.0 sntp
> > Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
> > The following additional packages will be installed:
> >   virtualbox-guest-utils virtualbox-guest-x11
> > Die folgenden Pakete werden ENTFERNT:
> >   ntp
> > Die folgenden Pakete werden aktualisiert (Upgrade):
> >   virtualbox-guest-dkms virtualbox-guest-utils virtualbox-guest-x11
> > 3 aktualisiert, 0 neu installiert, 1 zu entfernen und 193 nicht 
> > aktualisiert.
> > Es müssen noch 0 B von 2.082 kB an Archiven heruntergeladen werden.
> > Nach dieser Operation werden 1.980 kB Plattenplatz freigegeben.
> > Möchten Sie fortfahren? [J/n] n
> > Abbruch.
> > [/quote]
> > 
> > The same with virtualbox-guest-x11 and virtualbox-guest-utils.
> > 
> > I have set the severity to serious, because with the deletion of an 
> > important
> > system tool the stability is significantly disturbed.
> > 
> 
> This is not a bug, but a design thing.
> NTP can't work with virtualbox, because virtualbox is in charge of keeping 
> the time up-to-date, with the guest-utils tools
> e.g. with VBoxService.
> 
> Having two different timeservers will make things behave badly, and the 
> upstream documentation forbids this.
> 

I think if virtualbox-guest-utils has problems with ntp, virtualbox-
guest-utils should fix this problem instead of uninstalling a standard
program used for years.

On the other hand I find it impossible that neither a reference to the
deletion of ntp in the changelog is present nor in the NEWS.

I have absolutely nothing against that virtualbox-guest-utils use its
own time synchronization, but system-wide only if no other time server
runs.

It is also incomprehensible for users to install virtualbox-guest-utils 
as a time server.

Therefore, I reopen the bug again.

> 
> see #873263 if you want more background on the issue
> 
> I think I won't remove that conflict for now, unless you have some good 
> explanation for me :)
> 
> G.
> 

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#878083: RM: libgwenhywfar/stretch-backports bitlbee-facebook/stretch-backports qmapshack/stretch-backports -- RoQA; decrufting *-dbgsym from stretch-backports

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

looks like the first uploads to stretch-backports put their -dbgsym
packages into stretch-backports instead of stretch-backports-debug.
This seems to be fixed now, but needs manual decrufting to clean up the
letovers.

this is cruft:

gwenhywfar-tools-dbgsym   | 4.17.0-4~bpo9+1  | stretch-backports   | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libgwengui-cpp0-dbgsym| 4.17.0-4~bpo9+1  | stretch-backports   | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libgwengui-fox16-0-dbgsym | 4.17.0-4~bpo9+1  | stretch-backports   | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libgwengui-gtk2-0-dbgsym  | 4.17.0-4~bpo9+1  | stretch-backports   | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libgwengui-qt4-0-dbgsym   | 4.17.0-4~bpo9+1  | stretch-backports   | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libgwengui-qt5-0-dbgsym   | 4.17.0-4~bpo9+1  | stretch-backports   | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libgwenhywfar | 4.17.0-4~bpo9+1  | stretch-backports   | 
source
libgwenhywfar-data| 4.17.0-4~bpo9+1  | stretch-backports   | all
libgwenhywfar-doc | 4.17.0-4~bpo9+1  | stretch-backports   | all
libgwenhywfar60-dbgsym| 4.17.0-4~bpo9+1  | stretch-backports   | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

the good upload is:

libgwenhywfar | 4.18.0-1~bpo9+1  | stretch-backports   | 
source
libgwenhywfar | 4.18.0-1~bpo9+1  | stretch-backports-debug | 
source

cruft:

bitlbee-facebook   | 1.1.1-1~bpo9+1 | stretch-backports   | 
source
bitlbee-plugin-facebook-dbgsym | 1.1.1-1~bpo9+1 | stretch-backports   | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

good:

bitlbee-facebook   | 1.1.2-1~bpo9+1 | stretch-backports   | 
source
bitlbee-facebook   | 1.1.2-1~bpo9+1 | stretch-backports-debug | 
source

cruft:

qmapshack| 1.9.0-1~bpo9+1 | stretch-backports   | source
qmapshack-dbgsym | 1.9.0-1~bpo9+1 | stretch-backports   | amd64, arm64, 
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

good:

qmapshack| 1.9.1-1~bpo9+1 | stretch-backports   | source, amd64, 
arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
qmapshack| 1.9.1-1~bpo9+1 | stretch-backports-debug | source


Andreas

Bug#831076: libkqueue: patch for bool-compare issue, now FTBFS with test failures

[Andreas Moog]

Dear maintainer,

attached is a patch from upstream to fix this particular build failure. Sadly
the package still FTBFS, now with test failures:

Running 1 iterations
1: test_peer_close_detection()
2: test_kqueue()
3: test_kevent()
4: test_ev_receipt()
5: test_kevent_socket_add()
6: test_kevent_socket_del()
7: test_kevent_socket_add_without_ev_add()
8: test_kevent_socket_get()
9: test_kevent_socket_disable_and_enable()
10: test_kevent_socket_oneshot()
11: test_kevent_socket_clear()
12: test_kevent_socket_dispatch()
13: test_kevent_socket_listen_backlog()
14: test_kevent_socket_eof()
15: test_kevent_regular_file()
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
* ERROR: Program received signal 6 *
*** TEST FAILED ***

I didn't investigate this any further, seems it might be best to update to 
a newer upstream release instead of cherrypicking fixes.

Regards.

-- 
PGP-encrypted mails preferred
PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624
diff -Nru libkqueue-2.0.3/debian/changelog libkqueue-2.0.3/debian/changelog
--- libkqueue-2.0.3/debian/changelog	2014-09-11 13:55:27.0 +0200
+++ libkqueue-2.0.3/debian/changelog	2017-10-09 19:03:38.0 +0200
@@ -1,3 +1,11 @@
+libkqueue (2.0.3-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from upstream git to fix incorrect boolean logic 
+(Closes: #831076)
+
+ -- Andreas Moog   Mon, 09 Oct 2017 19:03:38 +0200
+
 libkqueue (2.0.3-1.1) unstable; urgency=medium
 
   * Non maintainer upload.
diff -Nru libkqueue-2.0.3/debian/patches/fix-ftbfs-gcc6.patch libkqueue-2.0.3/debian/patches/fix-ftbfs-gcc6.patch
--- libkqueue-2.0.3/debian/patches/fix-ftbfs-gcc6.patch	1970-01-01 01:00:00.0 +0100
+++ libkqueue-2.0.3/debian/patches/fix-ftbfs-gcc6.patch	2017-10-09 19:03:38.0 +0200
@@ -0,0 +1,16 @@
+Description: Fix incorrect boolean logic to allow building with GCC6
+Author: marcos69
+Bug-Debian: https://bugs.debian.org/831076
+Origin: upstream, https://github.com/mheily/libkqueue/commit/fd76168ac6018d5ae99ce9778ba1ef4de524b632.patch
+
+--- libkqueue-2.0.3.orig/src/linux/read.c
 libkqueue-2.0.3/src/linux/read.c
+@@ -204,7 +204,7 @@ evfilt_read_knote_delete(struct filter *
+ if (kn->kev.flags & EV_DISABLE)
+ return (0);
+ 
+-if ((kn->kn_flags & KNFL_REGULAR_FILE && kn->kdata.kn_eventfd != -1) < 0) {
++if ((kn->kn_flags & KNFL_REGULAR_FILE) && (kn->kdata.kn_eventfd != -1)) {
+ if (epoll_ctl(kn->kn_epollfd, EPOLL_CTL_DEL, kn->kdata.kn_eventfd, NULL) < 0) {
+ dbg_perror("epoll_ctl(2)");
+ return (-1);
diff -Nru libkqueue-2.0.3/debian/patches/series libkqueue-2.0.3/debian/patches/series
--- libkqueue-2.0.3/debian/patches/series	2014-09-11 13:55:59.0 +0200
+++ libkqueue-2.0.3/debian/patches/series	2017-10-09 19:03:38.0 +0200
@@ -1 +1,2 @@
 replace-64bit-knote.patch
+fix-ftbfs-gcc6.patch


signature.asc
Description: PGP signature

Bug#877481: casacore-data-tai-utc: trigger problem during upgrade from stretch to buster

[Andreas Beckmann]

Followup-For: Bug #877481

Hi,

I think there are more similar problems left. If there are missing
dependencies in stretch, you may have to use Breaks smewhere as well ...

Attached is a new log still showing the issue.
This is from a stretch system with --install-recommends enabled and
libcasa-measures2 instealled.

The failure happens during 
apt-get upgrade
from stretch to buster. The followup comand would have been
apt-get dist-upgrade
The upgrade process runs smooth if there is no separate apt-get upgrade
run first.


Andreas


libcasa-measures2_2.3.0-4+b1.log.gz
Description: application/gzip

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

It looks like Ultimaker dropped official 32 bit support:
https://github.com/Ultimaker/CuraEngine/issues/547

@pere fixed a few obvious bugs, but testing and more patches (if required) are
welcome.
cura-engine 2.5.0 is available in sid.

Note that it's currently missing libArcus for integration into Cura, because
the package still needs to go through QA first.

Bug#823508: Useless in Debian

[Gianfranco Costamagna]

control: retitle -1 RFA: python-guzzle-sphinx-theme
control: severity -1 normal

> > I packaged python-guzzle-sphinx-theme in order to build php-guzzle-doc,
> > but php-guzzle is going away, see #821698. There is a priori little
> > point in shipping python-guzzle-sphinx-theme in any Debian stable
> > release anymore.
> >
> > I intend to follow up with an RM request once php-guzzle is gone, unless
> > anyone objects (but feel free to beat me to it).
> >

nobody seems to have objected, and I also need it for borgbackup 1.0.

Closing this RC bug then

G.



signature.asc
Description: OpenPGP digital signature

Bug#872434: gitlab: Global search/repository file search javascript error 'fuzzaldrinPlus is not defined'

[Patrik Hagedorn]

Hi @all,

the same issue renders it impossibile to create a wildcard for protected 
branches.

Same stacktrace:
Uncaught ReferenceError: fuzzaldrinPlus is not defined
at t.filter 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:30601)
at t. 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:30573)
at HTMLInputElement.dispatch 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:2437)
at HTMLInputElement.g.handle 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:2370)
Uncaught ReferenceError: fuzzaldrinPlus is not defined
at t.filter 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:30601)
at t. 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:30573)
at HTMLInputElement.dispatch 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:2437)
at HTMLInputElement.g.handle 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:2370)
at Object.trigger 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:3458)
at HTMLInputElement. 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:3483)
at Function.each 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:845)
at ot.fn.init.each 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:746)
at ot.fn.init.trigger 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:3482)
at Object.options.data._.isObject._.isFunction.remote.n.success 
(application-75235e16c6e3c6bdb1c0e5faa7df7173630b99eed0e2133ec0079ae73e5c0758.js:formatted:30686)

Please help.

Best

-- 
Patrik Hagedorn
System Developer - Data Center Automation

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: patrik.haged...@profitbricks.com
URL:   https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg

Bug#878077: apt: miscomputes apt-get upgrade from stretch to buster with libkf5bookmarks5 installed

[Andreas Beckmann]

On 10/09/2017 06:05 PM, Julian Andres Klode wrote:
> upgrade failures are not serious bugs in apt. They are serious bugs in
> the affected packages, and possibly wishlist or normal for apt - after
> all any fixes in apt are basically fixes to not need the workaround in
> the _next_ release cycle, we don't fix upgrade problems by fixing stable
> apt releases.
> 
> The next step is to figure out what is causing the issue, and then
> reincrease the severity and reassign the bug (or a clone) to the
> package that needs to be fixed.

What I don't understand in this case is that

apt-get dist-upgrade

succeeds (so the packages seem to be fine) but

apt-get upgrade
apt-get dist-upgrade

fails (during apt-get upgrade).


Andreas

Bug#876752: Workaround

[Aigars Mahinovs]

While the CLang migration is still ongoing the workaround would be to
install libllvm5.0:i386=1:5.0~+rc2-1  libllvm5.0=1:5.0~+rc2-1 from testing.
This then allows to install the other packages needed to get GL
acceleration working in both 64bit and 32bit applications (like
libgl1-mesa-dri:i386).

Bug#878082: python3-pip: TypeError: unorderable types: Version() > SetuptoolsVersion()

[Laurent Bonnaud]

Package: python3-pip
Version: 9.0.1-2
Severity: normal


Dear Maintainer,

here is the problem:

$ pip3 list --outdated
DEPRECATION: The default format will switch to columns in the future. You can 
use --format=(legacy|columns) (or define a format=(legacy|columns) in your 
pip.conf under the [list] section) to disable this warning.
Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 215, in main
status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 157, in run
packages = self.get_outdated(packages, options)
  File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 168, in 
get_outdated
dist for dist in self.iter_packages_latest_infos(packages, options)
  File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 169, in 

if dist.latest_version > dist.parsed_version
TypeError: unorderable types: Version() > SetuptoolsVersion()

According to comments in this bug report:

  https://github.com/pypa/pip/issues/3057

the problem comes from Debian modifications to pip.


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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pip depends on:
ii  ca-certificates  20170717
ii  python-pip-whl   9.0.1-2
ii  python3  3.5.3-3

Versions of packages python3-pip recommends:
ii  build-essential 12.4
ii  python3-dev 3.5.3-3
ii  python3-setuptools  36.2.7-2
ii  python3-wheel   0.29.0-2

python3-pip suggests no packages.

-- no debconf information

-- 
Laurent.

Bug#878081: ITP: node-preact -- React alternative with the same ES6 API

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-preact
  Version : 8.2.5
  Upstream Author : Jason Miller 
* URL : https://github.com/developit/preact
* License : Expat
  Programming Lang: JavaScript
  Description : React alternative with the same ES6 API

 This module is a fast 3kb React alternative with the same ES6 API.
Components
 & Virtual DOM.
 .
 This module claims to have all the power of Virtual DOM components, without
 the overhead.
 .
 Node.js is an event-based server-side JavaScript engine.

In dependency chain of gitlab 9.5



signature.asc
Description: OpenPGP digital signature