Bug#893172: python-sagenb depends on cruft package python-flask-autoindex

[peter green]

Package: python-sagenb
Severity: serious
Tags: buster,sid

python-sagenb depends on python-flask-autoindex which is no longer built by 
source package flask-autoindex

Bug#893171: it is just an older version of grpc I think

[Pirate Praveen]

Control: retitle -1 Update golang-google-grpc-dev to new upstream release
Control: reassign -1 golang-google-grpc-dev
Control: found -1 1.6.0-3

Correcting bug meta data.



signature.asc
Description: OpenPGP digital signature

Bug#893171: Support non git packages

[Pirate Praveen]

Package: dh-make-golang
Version: 0.0~git20180129.37f630a-1+b1
severity: wishlist

I'm trying to update gitaly to new upstream version.

I got
src/gitlab.com/gitlab-org/gitaly/internal/rubyserver/balancer/balancer.go:24:2:
cannot find package "google.golang.org/grpc/resolver" in any of:

/<>/gitaly-0.88.0+debian/obj-x86_64-linux-gnu/src/gitlab.com/gitlab-org/gitaly/vendor/google.golang.org/grpc/resolver
 (vendor tree)
/usr/lib/go-1.10/src/google.golang.org/grpc/resolver (from $GOROOT)

/<>/gitaly-0.88.0+debian/obj-x86_64-linux-gnu/src/google.golang.org/grpc/resolver
 (from $GOPATH)

So I try to package it.

$ dh-make-golang google.golang.org/grpc/resolver
2018/03/17 05:52:13 Downloading "google.golang.org/grpc/resolver/..."
2018/03/17 05:52:21 Could not create a tarball of the upstream source:
Not a git repository, dh-make-golang currently only supports git

I think I will keep the vendored files for now.



signature.asc
Description: OpenPGP digital signature

Bug#893170: terminal spammed with return code

[Chillfan]

package: mksh
version: 54-2+b4

When running a command from the shell that isn't found mksh will spam the 
terminal with a return code.

The configuration setup for this is when the users default login shell is set 
to /bin/mksh in which case the .mkshrc is copied over from /etc/skel/.mkshrc 
into the users home directory.

This will give an output like this:

root@debian:~ # sl
mksh: sl: not found
127|root@debian:~ #

Note the bottom line that should just be: root@debian:~ #

Bug#893169: rkhunter won't update definitions: Invalid WEB_CMD

[Chillfan]

package: rkhunter
version: 1.4.2-6+deb9u1
severity: grave

When trying to do rkhunter --update it returns the following:

Invalid WEB_CMD configuration option: Relative pathname: "/bin/false"

wget is installed as per the manpage suggestion for using the --update argument

Bug#707033: debootstrap: deootstrap fails to finish if a vfat partition is mounted at /mnt/home

[Hideki Yamane]

tags -1 +unreproducible

On Tue, 07 May 2013 10:10:58 +0900 Super  Nathan Weber 
 wrote:
> Package: debootstrap
> Version: 1.0.49
> Severity: normal
> 
> Dear Maintainer,
> I was trying to install a debian system using debootstrap to a USB key. I
> formatted 2 partitions, a root (ext4) and a home (fat32) I then mounted the
> root at /mnt and the home at /mnt/home but debootstrap failed halfway through.
> If i unmount the home folder debootstrap works as expected.

 I cannot reproduce it with debootstrap both 1.0.49 and 1.0.93+nmu1
 
$ df -h
(snip)
/dev/sdb1 14G  302M   13G3% /mnt
/dev/sdb2736M  4.0K  736M1% /mnt/home

$ sudo mount -t ext4 /dev/sdb1 /mnt
$ sudo mkdir /mnt/home
$ sudo mount -t vfat /dev/sdb2 /mnt/home
$ sudo debootstrap sid /mnt http://debian-mirror.sakura.ne.jp/debian
(snip)
$ echo $?
0

Bug#884339: RFS: deepin-movie-reborn/3.1.1-1 [ITP]

[Yangfl]

control: tags -1 - moreinfo

Repacked.

On Fri, 15 Dec 2017 13:22:34 +0100 Adam Borowski  wrote:
> On Thu, Dec 14, 2017 at 02:27:53PM +0800, Yangfl wrote:
> >  * Package name: deepin-movie-reborn
> >Version : 3.1.1-1
> >
> >   It builds those binary packages:
> >
> > deepin-movie - Deepin movie player
> >  libdmr-dev - Deepin movie player - widget library (development files)
> >  libdmr0.1  - Deepin movie player - widget library
>
> Alas, fails to build:
> Could not find a package configuration file provided by "Qt5LinguistTools"
>
> Full log attached.
>
>
> 喵!
> --
> // If you believe in so-called "intellectual property", please immediately
> // cease using counterfeit alphabets.  Instead, contact the nearest temple
> // of Amon, whose priests will provide you with scribal services for all
> // your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#893168: cln: fix ftbfs on mips r6

[YunQiang Su]

Package: src:cln
Version: 1.3.4-2
Control: forward -1
https://www.ginac.de/pipermail/cln-list/2018-March/000710.html

We are working on MIPS release 6 port of Debian, and fix a problem of cln.

MIPS release 6 is not full compatible with the previous releases, it removes
some instructions and changes encoding of some instruction.
the `multu' is included.

MIPS r6 drops `lo' and `hi' registers, and then removes `multu'/`mfhi'/`mflo'.
Instead it uses `mulu' to compute the low part and `muhu' to compute
the high part.


Index: cln-1.3.4/src/base/cl_low.h
===
--- cln-1.3.4.orig/src/base/cl_low.h
+++ cln-1.3.4/src/base/cl_low.h
@@ -273,10 +273,15 @@ inline uint32 mulu32_unchecked (uint32 a
unused (hi_zuweisung _hi); lo_zuweisung _lo;  \
  })
 #elif defined(__GNUC__) && defined(__mips__) && !defined(NO_ASM)
+ #if __mips_isa_rev >= 6
+  #define MULTU_HI_LO "mulu %1,%3,%2 ; muhu %0,%3,%2"
+ #else
+  #define MULTU_HI_LO "multu %3,%2 ; mfhi %0 ; mflo %1"
+ #endif
   #define mulu32(x,y,hi_zuweisung,lo_zuweisung)  \
 ({ var register uint32 _hi;   \
var register uint32 _lo;   \
-   __asm__("multu %3,%2 ; mfhi %0 ; mflo %1"  \
+   __asm__(MULTU_HI_LO\
: "=r" (_hi), "=r" (_lo)   \
: "r" ((uint32)(x)), "r" ((uint32)(y)) \
   );  \
Index: cln-1.3.4/src/base/digitseq/cl_asm_mips_.cc
===
--- cln-1.3.4.orig/src/base/digitseq/cl_asm_mips_.cc
+++ cln-1.3.4/src/base/digitseq/cl_asm_mips_.cc
@@ -88,9 +88,14 @@
 DECLARE_FUNCTION(mulu32_)
 .ent mulu32_ // Input in $4,$5, Output in $2,mulu32_high
 mulu32_:
+#if __mips_isa_rev >= 6
+mulu $2,$5,$4   // arg1 * arg2, lo
+muhu $6,$5,$4   // arg1 * arg2, hi
+#else
 multu $5,$4 // arg1 * arg2
 mfhi $6 // hi
 mflo $2 // lo
+#endif
 sw $6,mulu32_high   // hi abspeichern // Adressierung??
Deklaration??
 j $31   // return
 .end mulu32_




-- 
YunQiang Su

Bug#893167: Stack smashing protection trigged in eboard

[Chillfan]

Package: eboard
Version: 1.1.1-6.1+b1
Severity: grave

Bug is present in stable/stretch, others not tested.

Stock 4.9 kernel on amd64.

If you need any more info than this please let me know. I've been able to 
reproduce on two different systems both amd64.

To reproduce:

When eboard is started go to settings > preferences > click squares to change 
the colours for > choose any colour from the palet> click OK

This will result in a crash.

The output:

\*\*\* stack smashing detected ***: eboard terminated

=== Backtrace: =

/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)\[0x7f8923036bfb\]

/lib/x86\_64-linux-gnu/libc.so.6(\_\_fortify_fail+0x37)\[0x7f89230bf1f7\]

/lib/x86\_64-linux-gnu/libc.so.6(\_\_fortify_fail+0x0)\[0x7f89230bf1c0\]

eboard(+0x92e8c)\[0x55aeeb1fce8c\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_closure_invoke+0x145)\[0x7f8924645f75\]

/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x21f82)\[0x7f8924657f82\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_signal\_emit\_valist+0xe3c)\[0x7f8924660bdc\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_signal_emit+0x8f)\[0x7f8924660fbf\]

/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8d0c5)\[0x7f8925d2e0c5\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_closure_invoke+0x145)\[0x7f8924645f75\]

/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x2195c)\[0x7f892465795c\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_signal\_emit\_valist+0xe3c)\[0x7f8924660bdc\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_signal_emit+0x8f)\[0x7f8924660fbf\]

/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8c029)\[0x7f8925d2d029\]

/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x1317bc)\[0x7f8925dd27bc\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_closure_invoke+0x145)\[0x7f8924645f75\]

/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x2237d)\[0x7f892465837d\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_signal\_emit\_valist+0x8df)\[0x7f892466067f\]

/usr/lib/x86\_64-linux-gnu/libgobject-2.0.so.0(g\_signal_emit+0x8f)\[0x7f8924660fbf\]

/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x2498ac)\[0x7f8925eea8ac\]

/usr/lib/x86\_64-linux-gnu/libgtk-x11-2.0.so.0(gtk\_propagate_event+0xc4)\[0x7f8925dd0f84\]

/usr/lib/x86\_64-linux-gnu/libgtk-x11-2.0.so.0(gtk\_main\_do\_event+0x2cb)\[0x7f8925dd133b\]

/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5acbc)\[0x7f8925a46cbc\]

/lib/x86\_64-linux-gnu/libglib-2.0.so.0(g\_main\_context\_dispatch+0x2a7)\[0x7f892436c7f7\]

/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4aa60)\[0x7f892436ca60\]

/lib/x86\_64-linux-gnu/libglib-2.0.so.0(g\_main\_loop\_run+0xc2)\[0x7f892436cd82\]

/usr/lib/x86\_64-linux-gnu/libgtk-x11-2.0.so.0(gtk\_main+0xb7)\[0x7f8925dd03b7\]

eboard(+0x25cb2)\[0x55aeeb18fcb2\]

/lib/x86\_64-linux-gnu/libc.so.6(\_\_libc\_start\_main+0xf1)\[0x7f8922fe62e1\]

eboard(+0x2645a)\[0x55aeeb19045a\]

=== Memory map: 

55aeeb16a000-55aeeb23 r-xp  fe:01 1179928    
/usr/games/eboard

55aeeb42f000-55aeeb433000 r--p 000c5000 fe:01 1179928    
/usr/games/eboard

55aeeb433000-55aeeb43c000 rw-p 000c9000 fe:01 1179928    
/usr/games/eboard

55aeeb43c000-55aeeb441000 rw-p  00:00 0

55aeec46d000-55aeec835000 rw-p  00:00 0  
\[heap\]

7f891e2f5000-7f891e3f5000 rw-s  00:05 421101572  
/SYSV (deleted)

7f891e3f5000-7f891e449000 r--p  fe:01 1310053    
/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf

7f891e449000-7f891e46c000 rw-p  00:00 0

7f891e4af000-7f891e55c000 r--p  fe:01 1310050    
/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf

7f891e55c000-7f891e615000 r--p  fe:01 1310051    
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf

7f891e659000-7f891e6b9000 rw-s  00:05 419561475  
/SYSV (deleted)

7f891e6b9000-7f891e6bf000 r-xp  fe:01 1184048    
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so

7f891e6bf000-7f891e8be000 ---p 6000 fe:01 1184048    
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so

7f891e8be000-7f891e8bf000 r--p 5000 fe:01 1184048    
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so

7f891e8bf000-7f891e8c rw-p 6000 fe:01 1184048    
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so

7f891e8c-7f891e8c4000 r-xp  fe:01 261221 
/lib/x86_64-linux-gnu/libuuid.so.1.3.0

7f891e8c4000-7f891eac3000 ---p 4000 fe:01 261221 
/lib/x86_64-linux-gnu/libuuid.so.1.3.0

7f891eac3000-7f891eac4000 r--p 3000 fe:01 261221 
/lib/x86_64-linux-gnu/libuuid.so.1.3.0

7f891eac4000-7f891eac5000 rw-p 4000 fe:01 261221 

Bug#892779: libu2f-udev: Please support non-systemd

[Nicolas Braud-Santoni]

Control: severity -1 important
Control: tag -1 upstream
Control: forward -1 https://github.com/Yubico/libu2f-host/issues/96

Hi,

On Mon, Mar 12, 2018 at 04:05:44PM -0400, Robbie Harwood wrote:
> 
> The provided udev rules don't work if the system isn't running systemd.

Indeed, the `uaccess` tag only works with systemd-logind.
Thanks for the catch.  :)


> Instead, we have to do something like:
> 
> ATTRS{idVendor}=="1050", GROUP="plugdev", MODE="0660"
> ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", GROUP="plugdev", 
> MODE="0660"
> 
> I'm not sure this is the best solution, but feature parity should be possible
> here.

I suggested upstream to make the devices accessible to group `plugdev` *and*
use tag `uaccess`, so it should work as transparently as possible in both cases.


Best,

  nicoo

Bug#893166: libexo-helpers: i386 helpers refer to wrong arch path /usr/lib/x86_64-linux-gnu/xfce4/exo-1/

[Nemo Inis]

Package: libexo-helpers
Version: 0.12.0-1
Severity: important

Dear Maintainer,

The following helpers installed in /usr/share/xfce4/helpers by libexo-
helpers_0.12.0-1
all refer to /usr/lib/x86_64-linux-gnu/xfce4/exo-1/exo-compose-mail-1 which
does not
exist on i386 installations:

balsa.desktop
evolution.desktop
geary.desktop
icedove.desktop
kmail.desktop
mozilla-mailer.desktop
mutt.desktop
muttng.desktop
sylpheed-claws.desktop
sylpheed.desktop
thunderbird.desktop

Proper path on for i386 is /usr/lib/i386-linux-gnu/xfce4/exo-1/



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

Kernel: Linux 4.14.0-3-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, 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 libexo-helpers depends on:
ii  libexo-common  0.12.0-1

libexo-helpers recommends no packages.

libexo-helpers suggests no packages.

-- no debconf information

Bug#886914: systemd: Kernel Panic on systemctl daemon-relaod, unit enable/disable when libvirt vms are running

[Michael Biebl]

On Thu, 11 Jan 2018 11:01:03 +0200 "Plamen K. Kosseff"
 wrote:
> Package: systemd
> Version: 236-2
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> This is new debian buster install on HP z600 workstation (for hardware spec 
> see below).
> The issue has manifested first during normal "apt-get upgrade" over ssh the 
> system would free during processing systemd triggers.
> Upon local investigation there was Kernel panic - not synching: Attempted to 
> kill init exitcode=0x9. I'll try to attach picture of the full panic message.
> 
> After some more investigation it looks like the probelm is reproducible only 
> when there are libvirt VMs running.
> If I stop the VMs before systemctl daemon-reload, enable disable it works as 
> expected

Is this problem still reproducible?
Might this actually be a kernel/kvm bug triggered by the reload of libvirt?

CCing Guido, maybe he has an idea.

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



signature.asc
Description: OpenPGP digital signature

Bug#870301: systemd: Touchpad fix Dell Inspiron Mini 1012

[Michael Biebl]

On Tue, 30 Jan 2018 04:30:58 -0500 (EST) bw  wrote:

> I'll go back and read your earlier posts, and see what I need to do.  I 
> guess you are recommending that I upgrade systemd and use upstream bug 
> reporting instead of debian bugtracker?

Yes, please upgrade to v238, try to reproduce your (libinput) problem,
if it still exists, file a bug report upstream at
https://github.com/systemd/systemd/issues
and report back with the bug number.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#884784: systemd-network segfaults

[Michael Biebl]

On Tue, 19 Dec 2017 19:50:49 +0200 =?utf-8?q?R=C3=A9mi_Denis-Courmont?=
 wrote:
> Package: systemd
> Version: 235-3
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> systemd-networkd from version 236-1 systematically segfaults at start-up.

Could you test with v238 please and report back with your results.

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



signature.asc
Description: OpenPGP digital signature

Bug#893046: transition: evolution-data-server 3.28

[Jeremy Bicha]

The gnome-desktop3/libgweather/mutter transitions are done now.

Thanks,
Jeremy Bicha

Bug#892321: attempts to suspend failing after crash

[Michael Biebl]

On Thu, 8 Mar 2018 10:02:32 + Daniel Pocock  wrote:
> Package: systemd
> Version: 232-25+deb9u1
> Severity: important
> 
> 
> Laptop was connected to a Thunderbolt dock, lid closed, using desktop
> monitor and keyboard, everything connected through the dock.  It is a
> laptop with encrypted LVM and swap on LVM.
> 
> Laptop's thunderbolt cable was bumped very slightly without coming out
> completely and then pushed back in.  As the lid was down, it appears the
> laptop tried to suspend
> 
> It didn't really suspend though, it became frozen with a blank screen.
> 
> After a hard reboot, every subsequent attempt to close the lid or undock
> also failed, the screen would go blank and it wouldn't come back.
> 
> journalctl and /var/log/messages provided no clues.
> 
> Guessing it was a problem with the swap partition, tried the following:
> 
>  swapoff /dev/mapper/vg00--vg-swap_1
>  mkswap /dev/mapper/vg00--vg-swap_1
> mkswap: /dev/mapper/vg00--vg-swap_1: warning: wiping old swap signature.
> Setting up swapspace version 1, size = 23.8 GiB (25513947136 bytes)
> no label, UUID=
> swapon /dev/mapper/vg00--vg-swap_1
> 
> In this case, the swap partition is named in /etc/fstab, not the UUID. 
> For somebody with the UUID in fstab it would be necessary to update
> there too and also run update-initramfs
> 
> This is not hard for an experienced user to resolve but very annoying as
> you only discover you have a problem after the second attempt to sleep.
> 
> Can systemd or whatever else is involved in the suspend/sleep mechanism
> be improved to detect problems like this, give some kind of error to the
> user and maybe even help them automatically correct it?

It's unclear to me what exactly your specific problem is/how and how
systemd should detect that.

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



signature.asc
Description: OpenPGP digital signature

Bug#872059: No longer creates /dev/console.

[Hideki Yamane]

On Mon, 14 Aug 2017 02:05:37 +0100 brsr.alternat...@gmail.com wrote:
> 1179a1180
> > mknod -m 600 $TARGET/dev/console c 5 1

 Does anyone oppose to apply above patch to debootstrap?
 


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#892738: consolekit: consolekit removal causes a regression

[Michael Biebl]

On Mon, 12 Mar 2018 12:51:35 +0100 Benedikt Spranger
 wrote:
> Package: consolekit
> Version: 0.4.6-6
> Severity: serious
> 
> Dear Maintainer,
> 
> please readd consolekit to the archive. Without consolekit the
> dependency to libpam-systemd as alternative to consolekit forces me to
> install systemd without any further benefit.
> 
> Since my systems works fine before (and till now, since consolekit
> 0.4.6-6 is installed) the removal of consolekit from the archive causes
> a regression. As my understanding of init system dependencies this is a
> serious bug, since it forces a dependency to a special system init
> system without any need. 

This is incorrect. The removal of consolekit does not enforce a switch
to a different init system. You are probably mistaking systemd with
systemd-sysv. Please read the package descriptions carefully.

So please readd consolekit to the archive.

Since this bug report is based on a false premise, I'm closing it.
Please read why consolekit was removed from Linux-architectures in the
first place.



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



signature.asc
Description: OpenPGP digital signature

Bug#855666: ITP: peek -- create animated GIF screencasts

[Boyuan Yang]

X-Debbugs-CC: kretc...@gmail.com>
Control: owner -1 !


Hi kretcheu,

As previously said in upstream repository, I intend to take over this
ITP bug. This ITP hasn't seen any activity for over 1 year thus this
looks reasonable.

I will now proceed with packaging. If you have any idea, don't
hesitate to tell me.

--
Regards,
Boyuan Yang

Bug#833525: debootstrap: Deleted my entire /home partition using "mostly harmless" debootstrap --print-debs option

[Hideki Yamane]

On Wed, 14 Mar 2018 07:21:38 +0100
Ansgar Burchardt  wrote:
> That doesn't work:
> 
> +---
> | $ dash -c '[ -e /bin/* ]'
> | dash: 1: [: /bin/2to3-2.7: unexpected operator
> +---

 Thanks for the catch, fixed version here.


diff --git a/debootstrap b/debootstrap
index a257e09..083473d 100755
--- a/debootstrap
+++ b/debootstrap
@@ -434,7 +434,7 @@ fi
 ###
 
 TARGET_EMPTY=true
-if [  -e "$TARGET"/* ]; then
+if [ "$(ls -A "$TARGET")" ]; then
TARGET_EMPTY=false
 fi

Bug#893165: ITP: node-capnp -- Cap'n Proto bindings for Node.js

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 
Control: block 893103 by -1

* Package name: node-capnp
  Version : 0~20180209
  Upstream Author : Kenton Varda 
* URL : https://github.com/capnproto/node-capnp
* License : BSD-2
  Programming Lang: C++, JS
  Description : Cap'n Proto bindings for Node.js

node-capnp is a wrapper around the Cap'n Proto C++ library.
Both the serialization and the RPC layer are exposed.

This is a dependency of sandstorm.io

Bug#893164: ITP: ekam -- ekam build system

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 
Control: block 893103 by -1

* Package name: ekam
  Version : 0~20180111
  Upstream Author : Kenton Varda 
* URL : https://github.com/sandstorm-io/ekam
* License : Apache 2.0
  Programming Lang: C++
  Description : ekam build system

Ekam ("make" backwards) is a build system which automatically figures out what 
to
build and how to build it purely based on the source code.  It is a build
dependency of sandstorm.io.

Bug#827568: marked as done (twine: please ship README)

[Stefano Rivera]

Control: reopen -1

Bah. We have the HTML, but I would like to ship the RST too.

Oh well, 1.11 is coming out next week, it can be fixed in that upload.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#893120: debian-edu-install: uninstallable on ahrd disk thrice the size mentioned in manual

[Holger Levsen]

hi, 

from irc:

< Natureshadow> 78 GiB reserved for "debianfreespace"
< Natureshadow> And /var only 5.2 GiB
< h01ger> Natureshadow: mybe put that in the bug? i know, ranting 
on irc is fun, but
< h01ger> and then you could also resize /var during installing...
< h01ger> debian-edu-autofsresize will do the job nicely and is documented


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#891698: cause removed, but not closing it myself

[Adam Borowski]

I wrote:
> The daemon's init script has the following line:
> apm_available || exit 0
> which makes it always silently fail, as apm_available contains:

> # APM support was removed from kernel 2.6.40 in 2011.
> exit 1

> The comment is untrue:
> ./config/i386/config:CONFIG_APM=m
> but regardless whether APM still works or not, the daemon will not.

I've changed apm_available to actually check /proc/apm again, which on the
face value fixes this bug.  However: the daemon was completely unusable for
4 years, yet no one said a thing.  Thus, I'll leave it to you to actually
close the bug (or do nothing and let the package get autoremoved from
Buster).

Also, laptops have a much shorter lifespan than desktops or servers: the
chances of a 20 years battery to still work are about nil, other components
are also more fragile and harder to replace.  Thus, if any such laptops are
still alive, they probably are stationary, thus without much use for APM.

Having APM in the kernel is still useful (needed for poweroff), but, with no
one noticing the daemon broken, you might consider sending it off to a nice
pasture.  You know your package far better than me...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#875251: [scidavis] Future Qt4 removal from Buster

[Steve Langasek]

Control: severity -1 grave
Control: tags -1 sid

Since qwtplot3d has now dropped the libqwtplot3d-qt4-0v5 binary package in
sid, scidavis is uninstallable.  Raising the severity of this bug.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#893154: #893154: installation-reports: pine64+ difficult install

[Ben Hutchings]

Control: reassign -1 src:linux 4.13~rc5-1~exp1

On Fri, 2018-03-16 at 16:02 -0700, Vagrant Cascadian wrote:
> On 2018-03-16, Vagrant Cascadian wrote:
> > I'm looking into enabling EFI emulation in u-boot to allow this
> > part to "just work" with the current grub-EFI images.
> 
> I built a new version of u-boot with EFI emulation support enabled, and
> successfully booted the mini.iso, but still have the problems with
> missing modules in the installer. These modules were insufficient to get
> the USB network adapter to work:
[...]
> That could be compared against the list from the initial report to see
> if anything obvious is missing.

phy_sun4i_usb is missing.  That used to be included in usb-modules by
this pattern:

drivers/phy/phy-*-usb* ?

Unfortunately in 4.13 most of the USB PHY drivers were moved into per-
vendor sudbirectories, so this pattern stopped matching them.  (A few
were still included due to static module dependencies; more on armhf
than on arm64.)

Ben.

> Interestingly enough, the microSD is detected; there must be differences
> in the device-tree that u-boot loads when doing EFI emulation and the
> one provided with the kernel package.

-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.


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

Bug#882934: Crash debugging

[Dima Kogan]

Let's move this back to the bug list.

Thanks for the debugging traces. I didn't see any smoking gun, but
there're things I'd like to follow-up on to isolate the issue and then
to hopefully allow me to reproduce it.

1. You have a customized gtk configuration that uses a theme no longer
   in Debian. Can you please try to rename your ~/.gtkrc-2.0 file to
   something else to see if that makes the crash go away? I'm guessing
   this doesn't matter, but checking would be good.

2. The crash makes me suspect that something related to graphics is at
   fault. You have a radeon graphics card of some sort it looks like,
   which could explain why I can't reproduce (my hardware is different).
   How old/new is your graphics drivers? Can you try to run pcb without
   hardware acceleration? You can do this with

 LIBGL_ALWAYS_SOFTWARE=true pcb-gtk

   Also please try

 LIBGL_ALWAYS_INDIRECT=true pcb-gtk

Hopefully one of these resolves the crash, which would tell us where to
look next.

Thanks!

Bug#893163: caja-dropbox: drop down menu does not appears when clicking on icon (left or right click) in version 1.20

[Tedo Vrbanec]

Package: caja-dropbox
Version: 1.16.0-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Regular update of package caja-dropbox from 1.16 to 1.20 at Debian buster
(testing), MATE DE

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I just installed update. Btw, when downgrade to 1.16, everything is OK again. I
tried few times to be completely sure that caja-dropbox is the cose of this
behaviour. Now I have freezed the package.

   * What was the outcome of this action?
Dropbox options and actions from dropdown (actually, for me it is rising menu,
because I have panel in bottom of desktop) menu are not usable. There is only
pixel or two of visible menu, hardly even seen.

   * What outcome did you expect instead?
Dropdown menu with options.



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

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

Versions of packages caja-dropbox depends on:
ii  dbus-x11 1.12.6-2
ii  libatk1.0-0  2.26.1-3
ii  libc62.27-2
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libcaja-extension1   1.20.0-2
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-2
ii  libgtk-3-0   3.22.28-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  policykit-1  0.105-18
ii  procps   2:3.3.12-4
ii  python   2.7.14-4
ii  python-gpgme 0.3-1.2
ii  python-gtk2  2.24.0-5.1+b1

caja-dropbox recommends no packages.

Versions of packages caja-dropbox suggests:
ii  caja  1.20.0-2

-- no debconf information

Bug#888189: [DRE-maint] Bug#888189: ruby-innertube: FTBFS on ruby2.5: undefined method mock

[Hector Oron]

Hello,

2018-03-16 23:05 GMT+01:00 Georg Faerber :
> On 18-01-23 20:31:56, Chris West (Faux) wrote:
>> This package fails to build against ruby2.5. Soon, there will be a
>> transition to ruby2.5, and this package will FTBFS in sid.
>
> Upstream seems rather dead, popcon lists 11 installations.

Indeed, upstream seems dead.

> @Héctor: You've tagged this help: Are you using it personally, or DSA?

Open Build Service (obs-api) needs it for the webUI ruby on rails
application, that's why I am interested on getting it fixed.

It has nothing to do with DSA, for those see
  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-ad...@lists.debian.org

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.



-- Would you like to make a donation towards the upcoming Debian conference?
   Brochure: 
https://media.debconf.org/dc18/fundraising/debconf18_sponsorship_brochure_en.pdf

   ** https://debconf18.debconf.org/sponsors/become-a-sponsor/ **

Bug#893162: ITP: libhsts -- library for checking HSTS preload list

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 
Control: block -1 with 893159

* Package name: libhsts
  Version : 0.0.1
  Upstream Author : Tim Rühsen 
* URL : https://www.gitlab.com/rockdaboot/libhsts
* License : BSD
  Programming Lang: C
  Description : library for checking HSTS preload list

The HSTS preload list offers a way for http clients to automatically
opt into encrypted connections.  libhsts offers a way for any http
client to easily access information about the preload list.

Note that the preload list itself should be shipped separately, since
it is likely to be updated more frequently than libhsts itself (see
https://bugs.debian.org/893159).

AIUI, future versions of wget will want to use something like libhsts
to improve communications security for the user.

   --dkg

Bug#893052: RFS: btrfsmaintenance/0.4.1-1 [I maintain the package]

[Nicholas D Steeves]

Control: tags -1 -moreinfo

I've uploaded to mentors a package minus this commit:
  * Change architecture to linux-any, because btrfs is Linux-only

Sadly linux-all is not an available architecture, and "all" explicitly
prohibits adding arch-specific dependencies like:

   Depends: ${misc:Depends}
  -   , btrfs-progs
  +   , btrfs-progs [!kfreebsd-amd64]
  +   , btrfs-progs [!kfreebsd-i386]
  +   , btrfs-progs [!hurd-i386]

Oh well...for now!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#893161: linux-image-4.9.0-6-amd64: Fix for suspend on amdgpu chipsets on Debian stable

[composer]

Package: src:linuxVersion: 4.9.82-1+deb9u3Severity: importantDear Maintainer,I 
tracked down an issue I've been having on my Debian Stable machine with 
suspending. Other users reported it goes away when applying the patchset found 
at: https://patchwork.kernel.org/patch/9489859/ Please back port it to 4.9 when 
possible.TIA

Bug#893159: src:chromium-browser: Please ship an Architecture: all hstspreload package

[Daniel Kahn Gillmor]

Package: src:chromium-browser
Version: 65.0.3325.146-4
Severity: wishlist

The chromium source package contains an up-to-date version of the
chromium "HSTS preload list".  for example:

https://sources.debian.org/src/chromium-browser/65.0.3325.146-4/net/http/transport_security_state_static.json/

Other software besideds chromium can make use of this file to provide
users with an up-to-date way to avoid cleartext http connections.

It'd be great to ship a copy of this file in a separate debian
package, for other packages to depend on.

my thought is that it could ship the latest version of
transport_security_state_static.json in a package named "hstspreload"
somewhere in /usr/share/hstspreload/.

Even better would be to use net/tools/dafsa/make_dafsa.py to produce a
compact, rapid-access .dafsa binary file that could be loaded and
searched rapidly by other software.  I believe the dafsa file would be
significantly smaller than the .json, so perhaps it should be in its
own package, hsts-preload-dafsa.

the .dafsa data would be useful for
https://gitlab.com/rockdaboot/libhsts, which i'm hoping to package and
put into debian.  (it has a copy of hsts-make-dafsa, which should be
pretty close to chromium's make-dafsa.

This package would be equivalent to publicsuffix, dns-root-data,
ca-certificates, and tzata -- information about the state of the world
or the global network that really should be updated regularly in the
same way that we expect packages to be updated.

If the chromium maintainers aren't interested in shipping this from
the chromium package, i can always make a new hstspreload source
package, but i'd prefer to avoid the embedded code copies if we can.
let me know what you think!

Regards,

--dkg

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

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

Bug#893160: debhelper: dh_installinfo does not record files in a way that dh_missing can see

[Daniel Kahn Gillmor]

Package: debhelper
Version: 11.1.5
Severity: normal
Control: affects -1 src:libgpg-error

libgpg-error's debian/libgpg-error-dev.info contains:

 debian/tmp/usr/share/info/gpgrt.info

but if i use dh_missing --fail-missing, it fails with:

dh_missing --fail-missing
dh_missing: usr/share/info/gpgrt.info exists in debian/tmp but is not installed 
to anywhere
dh_missing: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libgpg-error-dev (11), libgpg-error-mingw-w64-dev (18), 
libgpg-error0 (3), libgpg-error0-udeb (2)
 * dh_installdocs: libgpg-error-dev (2), libgpg-error-mingw-w64-dev 
(1), libgpg-error0 (1)
 * dh_installman: libgpg-error-dev (3), libgpg-error-mingw-w64-dev (0), 
libgpg-error0 (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
For a short-term work-around: Add the files to debian/not-installed
debian/rules:34: recipe for target 'override_dh_missing' failed
make[1]: *** [override_dh_missing] Error 2

Please update dh_installinfo to report info files so that dh_missing
can know about them!

thanks for maintaining debhelper,

--dkg

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf16
ii  dh-strip-nondeterminism  0.040-1
ii  dpkg 1.19.0.5
ii  dpkg-dev 1.19.0.5
ii  file 1:5.32-2
ii  libdpkg-perl 1.19.0.5
ii  make 4.1-9.1
ii  man-db   2.8.2-1
ii  perl 5.26.1-5
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  
pn  dwz  

-- no debconf information

Bug#890848: 1.75g -> 0.24g (Was: A smaller test ...)

[Kingsley G. Morse Jr.]

On 03/16/2018 22:38, Dan Dennedy wrote:
> [...]
> reduced from 1.75g RES to
> [...]
> 0.24g

Looks good, Dan.

Thank you very much,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#893158: httpunit FTBFS with openjdk-9

[Adrian Bunk]

Source: httpunit
Version: 1.7+dfsg-12
Severity: serious
Tags: buster sid

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

...
compile:
[mkdir] Created dir: /build/1st/httpunit-1.7+dfsg/build/classes
[javac] /build/1st/httpunit-1.7+dfsg/build.xml:136: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Compiling 195 source files to 
/build/1st/httpunit-1.7+dfsg/build/classes
[javac] Using ant.build.javac.target 1.5 is no longer supported, switching 
to 1.6
[javac] Using ant.build.javac.target 1.5 is no longer supported, switching 
to 1.6
[javac] Using ant.build.javac.source 1.5 is no longer supported, switching 
to 1.6
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/1st/httpunit-1.7+dfsg/src/com/meterware/httpunit/HttpWebResponse.java:92:
 error: unmappable character (0xF6) for encoding US-ASCII
[javac] // by Roger Lindsj?
[javac]   ^
[javac] 
/build/1st/httpunit-1.7+dfsg/src/com/meterware/servletunit/ServletUnitServletContext.java:127:
 error: unmappable character (0xE4) for encoding US-ASCII
[javac] // by Timo Westk?mper
[javac] ^
[javac] 2 errors
[javac] 4 warnings

BUILD FAILED
/build/1st/httpunit-1.7+dfsg/build.xml:136: Compile failed; see the compiler 
error output for details.

Total time: 2 seconds
make[1]: *** [debian/rules:14: override_dh_auto_build] Error 1

Bug#893154: #893154: installation-reports: pine64+ difficult install

[Vagrant Cascadian]

On 2018-03-16, Vagrant Cascadian wrote:
> I'm looking into enabling EFI emulation in u-boot to allow this
> part to "just work" with the current grub-EFI images.

I built a new version of u-boot with EFI emulation support enabled, and
successfully booted the mini.iso, but still have the problems with
missing modules in the installer. These modules were insufficient to get
the USB network adapter to work:

# lsmod
Module  Size  Used by
ohci_platform  16384  0
ohci_hcd   61440  1 ohci_platform
ehci_platform  16384  0
ehci_hcd   90112  1 ehci_platform
dwmac_sun8i20480  0
mdio_mux   16384  1 dwmac_sun8i
stmmac_platform20480  1 dwmac_sun8i
usbcore   274432  4
ehci_hcd,ohci_hcd,ehci_platform,ohci_platform
stmmac131072  2 stmmac_platform,dwmac_sun8i
ptp24576  1 stmmac
pps_core   20480  1 ptp
of_mdio16384  3 stmmac,mdio_mux,stmmac_platform
fixed_phy  16384  1 of_mdio
fixed  16384  1
libphy 65536  4 of_mdio,stmmac,mdio_mux,fixed_phy
sunxi_mmc  28672  0


That could be compared against the list from the initial report to see
if anything obvious is missing.


Interestingly enough, the microSD is detected; there must be differences
in the device-tree that u-boot loads when doing EFI emulation and the
one provided with the kernel package.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#893157: planet-venus: django.template.exceptions.TemplateDoesNotExist

[beuc]

Package: planet-venus
Version: 0~git9de2109-4
Tags: patch

Hi,

When processing a .dj template with planet-venus under Debian 9.4/Stretch, I 
got:
 DEBUG:planet.runner:Processing template 
/var/www/planet.gnu.org/git/debian/templates/index.html.dj using dj
Traceback (most recent call last):
  File "./code/venus/planet.py", line 158, in 
splice.apply(doc.toxml('utf-8'))
  File "/usr/lib/python2.7/dist-packages/planet/splice.py", line 142, in apply
output_file = shell.run(template_file, doc)
  File "/usr/lib/python2.7/dist-packages/planet/shell/__init__.py", line 66, in 
run
module.run(template_resolved, doc, output_file, options)
  File "/usr/lib/python2.7/dist-packages/planet/shell/dj.py", line 41, in run
t = get_template(script)
  File "/usr/lib/python2.7/dist-packages/django/template/loader.py", line 25, 
in get_template
raise TemplateDoesNotExist(template_name, chain=chain)
django.template.exceptions.TemplateDoesNotExist: 
/var/www/planet.gnu.org/git/debian/templates/index.html.dj

AFAICS this is related to:
https://docs.djangoproject.com/fr/1.10/ref/templates/upgrading/

The attached patch applies that documentation and fixes the issue:
--- dj.py~  2018-03-16 20:34:34.019196399 +
+++ dj.py   2018-03-16 22:37:35.015027892 +
@@ -23,7 +23,24 @@
 try:
 settings.configure(
 DEBUG=True, TEMPLATE_DEBUG=True, 
-TEMPLATE_DIRS=(os.path.dirname(script),)
+TEMPLATES = [
+{
+'BACKEND': 
'django.template.backends.django.DjangoTemplates',
+'DIRS': (os.path.dirname(script),),
+'APP_DIRS': True,
+'OPTIONS': {
+'context_processors': [
+'django.contrib.auth.context_processors.auth',
+'django.template.context_processors.debug',
+'django.template.context_processors.i18n',
+'django.template.context_processors.media',
+'django.template.context_processors.static',
+'django.template.context_processors.tz',
+
'django.contrib.messages.context_processors.messages',
+],
+},
+},
+]
 )
 except RuntimeError:
 pass


Works for me.

Cheers!
Sylvain

--- dj.py~	2018-03-16 20:34:34.019196399 +
+++ dj.py	2018-03-16 22:37:35.015027892 +
@@ -23,7 +23,24 @@
 try:
 settings.configure(
 DEBUG=True, TEMPLATE_DEBUG=True, 
-TEMPLATE_DIRS=(os.path.dirname(script),)
+TEMPLATES = [
+{
+'BACKEND': 'django.template.backends.django.DjangoTemplates',
+'DIRS': (os.path.dirname(script),),
+'APP_DIRS': True,
+'OPTIONS': {
+'context_processors': [
+'django.contrib.auth.context_processors.auth',
+'django.template.context_processors.debug',
+'django.template.context_processors.i18n',
+'django.template.context_processors.media',
+'django.template.context_processors.static',
+'django.template.context_processors.tz',
+'django.contrib.messages.context_processors.messages',
+],
+},
+},
+]
 )
 except RuntimeError:
 pass

Bug#893156: Request to reset src:mariadb-10.1 to previous known working state in Debian testing/unstable archives

[Otto Kekäläinen]

Package: ftp.debian.org


I am aware that this is a very unusual request, but I feel it is my
last resort, so I am doing it anyhow. Please try to understand the
problem and suggested solution before dismissing the request.


## Request

In the name of avoiding a quality catastrophe, please
- remove from the Debian testing/unstable repos the source package and
all binary packages of mariadb-10.1 version 1:10.1.29-6
- reset the dak/ftp-system archive database records related to this
package so the systems accept 10.1.28-2 and forgets about the newer
versions that needed to be reverted
- re-introduce last known good version mariadb-10.1 10.1.28-2


## Motivation

I am the primary maintainer of the MariaDB packages in Debian. I
foresee a significant quality problem with the current mariadb-10.1
package version 1:10.1.29-6 in Debian (which I did not create) and I
am asking your help to get it reverted to the last known good version,
which is mariadb-10.1 version 10.1.28-2.

There was a series of misguided uploads of mariadb-10.1 and
mariadb-10.2 in November 2017 by another Debian Developer, who had
good intentions, but ended up causing a lot of havoc. I have discussed
the incident with him privately and he is unlikely to do any more bad
uploads of the mariadb-* packages.

If this issues is not fixed, a large amount of existing MariaDB
installations will stop working when upgrading from a previous version
of Debian to the testing/unstable or next stable version, and users
with fresh installations will not be able to install from 3rd party
repositories any other versions of MariaDB than this 1:10.1.29-6.

The use of 3rd party repositories is very common and breaking all of
them I think is unacceptable and against the general sentiment that
Debian is supposed to help people get technically empowered and
advance society. Also, the epoch in the version is ugly. Personally I
am motivated to help Debian because of the ability to create something
technically advanced and elegant, and because of how that work
potentially helps any human anywhere. If we proceed with this
1:10.1.29-6 then both of those motivations fall off, as this version
in counterproductive to both goals.


## Extra motivation why we should not require the whole world to adapt
to this "bug"

I agree that the Debian policy is sacred, and that we can require the
world to follow it wherever somebody does any .deb packaging. The
policy changes and heavily discussed and reviewed and all happen
because of good reasons. However I don't agree that _any_ decision
done by _any_ Debian Developer is something that we can or should
require the whole world to adapt to.

We have now at hand a mistake done by a single Debian Developer that
needs to be fixed before it spreads. The fix is quite unusual
(manually modifying dak/ftp records) but not impossible, and from a
larger perspective the most elegant fix that can be executed by a
single person in a short time to avoid forcing multiple persons to
suffer from the bug and forcing people to fix packaging in many places
over a period of months or years.


## Technical details

- mariadb-10.1 10.1.28-2 is the last known good version of the package
- In mariadb-10.1 10.1.29-1 quality decreased, because certain
non-applying patches were removed instead of updated, which causes
build failures on certain Debian architectures. Also the
mariadb-test-packages were removed from the packaging without a solid
motivation.
- At this point in time badly prepared mariadb-10.2 packages were
uploaded, which made the QA systems for this package itself raise tens
of flags, and in addition caused dependent packages to  fail in many
ways.
- mariadb-10.1 with epoch version 1:10.1.29-2 was uploaded to Debian
in an attempt to revert the bad mariadb-10.2 upload. This was the
worst mistake made in the series of mistakes.
- An epoch in the version string was introduced against the Debian
policy to force 10.1 to override 10.2.
- Then a series of revision uploads from -2 up until -6 where made
trying to fix build issues, basically using the Debian archive proper
as a testbed for things like make flags.

Doing a git revert now and uploading a fixed 10.1.29-7 does not help
here, since the epoch was introduced, and the epoch itself is a bug
that should be reverted.

It is very for users of Debian (and its derivates) run a newer version
of MariaDB which they have installed the MariaDB.org repositories or a
PPA or some other 3rd party repository. Because of the epoch, anybody
running for example mariadb-server version 10.3.x will have their
packages either break (leaving dpkg and the entire system in a broken
state) or it will downgrade the binaries to mariadb-server
1:10.1.29-2, and a 10.1 binary will naturally not be able to start
using binary data files from a future 10.3 version. MariaDB (nor any
other database system) is not able to downgrade data-files in place,
which is quite natural when you think about it (developers of version
1 cannot predict 

Bug#892956: Request for testing

[Jussi Pakkanen]

Hi

We have a proposed patch (not yet ready for merging but almost there)
available here:

https://github.com/mesonbuild/meson/pull/3251

Could people who who encountered this issue test if that fixes the
issue for them? Thanks.

Also, earlier in this someone said this:

> -llibinput-util would be liblibinput-util.a, that's clearly bogus.

That's not actually true. If you look at the build definitions of
libinput, it uses the following declaration:

static_library('libinput-util', ...

Meson automatically adds the library prefix to the target name so the
file name is indeed "liblibinput-util" and the contents of the
pkg-config file are correct in this regard (of course the library
should not be in the output at all but that is a different issue).

Bug#780706: Arduino reference

[Geert Stappers]

>  [4]: https://anonscm.debian.org/git/collab-maint/arduino-reference.git

That git repository has been moved to another location

It is now located under
https://salsa.debian.org/electronics-team/arduino/reference-en


To update the remote url in your local repository run (for ssh):
  git remote set-url origin 
g...@salsa.debian.org:electronics-team/arduino/reference-en.git
or for http(s):
  git remote set-url origin 
https://salsa.debian.org/electronics-team/arduino/reference-en.git

Bug#893155: openstack-pkg-tools: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: openstack-pkg-tools 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of openstack-pkg-
tools debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#893154: installation-reports: pine64+ difficult install

[Vagrant Cascadian]

Package: installation-reports
Severity: normal

This install, while successful, was a bit of a challenge. I had to
manually create the boot media, customize the initrd to append
additional kernel modules, and the microSD wasn't available to install
the OS. More details below.

live well,
  vagrant

Boot method: microSD image
Image version: 
https://d-i.debian.org/daily-images/arm64/20180314-02:10/netboot/netboot.tar.gz
Date: 2018-03-16

Machine: Pine64+
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs980740   0980740   0% /dev
tmpfs  tmpfs   2050322800202232   2% /run
/dev/sda3  ext4   9546944 1477040   7565228  17% /
tmpfs  tmpfs  1025144   0   1025144   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs  1025144   0   1025144   0% /sys/fs/cgroup
tmpfs  tmpfs   205028   0205028   0% /run/user/1000


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[E]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [E]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E]

Comments/Problems:

I had to manually craft the microSD image used to boot this, by
downloading the netboot.tar.gz image for the
linux/initrd.gz. Separately, I had to download the .dtb for this
board, which is available, but not included in the netboot.tar.gz.
Had to use the install-sunxi64 script from atf-allwinner and install
u-boot-sunxi:arm64 in order to make the image bootable.

Since this doesn't support EFI boot out of the box, I had to manually
craft an extlinux.conf (or boot.scr), since those are not provided on
arm64. I'm looking into enabling EFI emulation in u-boot to allow this
part to "just work" with the current grub-EFI images.

The on-board network card didn't detect at all, and using a
usb-ethernet adapter didn't detect at all either; I don't think USB
was working. Appending all the kernel modules to the initrd allowed it
to detect the USB ethernet adapter and proceed with the install.

It failed to detect the microSD card as a disk to install to; worked
around by installing to a USB SSD.

-- 

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20180314-02:07"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux p64z 4.15.0-1-arm64 #1 SMP Debian 4.15.4-1 (2018-02-18) aarch64 
GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.15.0-1-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.15.0-1-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.15.0-1-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 04 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.15.0-1-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 04 Device 02: USB 2.0 Hub [MTT] [1a40:0201]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 02
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 02 Driver hub
usb-list: 
usb-list: Bus 04 Device 03: USB 10/100 LAN [0bda:8152]
usb-list:Level 02 Parent 02 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: Realtek
usb-list:Interface 00: Class ff(vend.) Subclass ff Protocol 00 Driver r8152
usb-list: 
usb-list: Bus 04 Device 04: FX-C0002 [174c:55aa]
usb-list:Level 02 Parent 02 Port 01  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: FX
usb-list:Interface 00: Class 08(mstor) Subclass 06 Protocol 50 Driver 
usb-storage
lsmod: Module  Size  Used by
lsmod: dm_mod143360  0

Bug#893120: debian-edu-install: uninstallable on ahrd disk thrice the size mentioned in manual

[Wolfgang Schweer]

Am 2018 3 16 16:19:01 UTC schrieb Dominik George :
>Source: debian-edu-install
>Version: 1.916
>Severity: grave
>Justification: renders package unusable
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>I spent two days trying to install Debian Edu (combined server) in a
>virtual machine. I started with 100 GiB hard disk, then tried 150 GiB,
>and finally 220 GiB. The LTSP chroot installation always fails with no
>space left in /opt/var/cache/apt.
>
>Installing Debain Edu is not possible.

Hi Dominik,
iirc 64 GiB has always been enough to install a default combi server (Stretch) 
w/o any space problems. Anything special about your installation?

Wolfgang
(via phone; no access to serious hardware atm)

Bug#893153: geronimo-interceptor-3.0-spec FTBFS with openjdk-9

[Adrian Bunk]

Source: geronimo-interceptor-3.0-spec
Version: 1.0.1-3
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/geronimo-interceptor-3.0-spec.html

...
compile:
[mkdir] Created dir: 
/build/1st/geronimo-interceptor-3.0-spec-1.0.1/build/classes
[javac] /build/1st/geronimo-interceptor-3.0-spec-1.0.1/debian/build.xml:31: 
warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds
[javac] Using javac -source 1.5 is no longer supported, switching to 1.6
[javac] Using javac -target 1.5 is no longer supported, switching to 1.6
[javac] Compiling 7 source files to 
/build/1st/geronimo-interceptor-3.0-spec-1.0.1/build/classes
[javac] 
/build/1st/geronimo-interceptor-3.0-spec-1.0.1/src/main/java/javax/interceptor/InterceptorBinding.java:31:
 error: unmappable character (0xC2) for encoding US-ASCII
[javac]  * @version $Rev$??$Id: InterceptorBindingType.java 782259 
2009-06-06 13:31:32Z gerdogdu $
[javac]  ^
[javac] 
/build/1st/geronimo-interceptor-3.0-spec-1.0.1/src/main/java/javax/interceptor/InterceptorBinding.java:31:
 error: unmappable character (0xA0) for encoding US-ASCII
[javac]  * @version $Rev$??$Id: InterceptorBindingType.java 782259 
2009-06-06 13:31:32Z gerdogdu $
[javac]   ^
[javac] 2 errors

BUILD FAILED
/build/1st/geronimo-interceptor-3.0-spec-1.0.1/debian/build.xml:31: Compile 
failed; see the compiler error output for details.

Total time: 36 seconds
make: *** [/usr/share/cdbs/1/class/ant.mk:39: debian/stamp-ant-build] Error 1

Bug#888189: [DRE-maint] Bug#888189: ruby-innertube: FTBFS on ruby2.5: undefined method mock

[Georg Faerber]

On 18-01-23 20:31:56, Chris West (Faux) wrote:
> This package fails to build against ruby2.5. Soon, there will be a
> transition to ruby2.5, and this package will FTBFS in sid.

Upstream seems rather dead, popcon lists 11 installations.
@Héctor: You've tagged this help: Are you using it personally, or DSA?

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#892480: abcde-musicbrainz-tool broken

[Steve McIntyre]

On Sat, Mar 10, 2018 at 12:43:27AM +0900, Norbert Preining wrote:
>Hi Steve,
>
>Thanks to you for keeping abcde alive, I use it since long.

Cool - it seems lots of people do!

>Before falling asleep here, there was another problem with this CD: I edited
>the CD info but at the end the mp3s didn't contain any tag information
>whatsoever.
>
>My guess is that the problem lies with the fact that all entries were in
>Japanese and that dinner configuration is necessary to get this working.

Hmmm, OK. Difficult to diagnose from here - if you could help debug a
little, that would be great! It might be a problem in the tagging
program, or in the character sets possibly. Lots of tools have
particular assumptions about encodings that are not very clear or
helpful...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier

Bug#852856: what is the point of this bug

[Geert Stappers]

> 
> I'm trying to understand what the point of this bug is.
> 
> Originally I thought it was that urjtag has no adapter list and wants
> some udev rules for access and wanted to piggy back on OpenOCD's list.

Yes, correct.


> Subsequently it sounds that while this might be part of the reason it is
> additionally desired to just have a "list of JTAG adapter udev rules"
> that do not correspond to either OpenOCD or urjtag but include aspects
> of both.

Incorrect.

 
> I still don't understand why each package can't manage the pieces of
> hardware that they support, instead of having a new very small package
> that ultimately will require work on both sides to ensure it stays valid
> for all adapters

The "staying valid" is done upstream, not in Debian or it's devirates.


> (rather than, say, just being able to be a copy of the
> OpenOCD upstream list, if urjtag had been a strict subset).

There is no reason for thinking in subsets.

> There's no
> issue with multiple udev rules files covering the same rule - the last
> one will win and I'm assuming both packages will be adding them as
> plugdev anyway so they'll be the same. In the same was as there is a
> /lib/udev/rules.d/60-openocd.rules there can be a
> /lib/udev/rules.d/60-urjtag.rules?

It is the "last one will win" that should be avoided.

A package with /lib/udev/rules.d/60-openocd.rules used by
_both openocd and urjtag_ will prevent a fight about who is last.


Groeten
Geert Stappers

P.S.
In an ideal world, or on the long run, there would be an upstream
project that collects all VID:PID of JTAG-adapters.
-- 
Leven en laten leven

Bug#890848: Well, well, well! (Was: A smaller test case ...)

[Kingsley G. Morse Jr.]

O Dan who can and has began!

Thank you very much for focusing your laser like
skilz on my bug.

I like your plan to take a closer look at what can
be done to reduce memory usage.

So,
Kingsley

On 03/16/2018 19:52, Dan Dennedy wrote:
> I took some time today to build kdenlive (master branch) and test this
> out...
> 
> On Thu, Feb 22, 2018 at 12:20 AM Jean-Baptiste Mardelle 
> wrote:
> 
> > On 17.02.2018 05:55, Kingsley G. Morse Jr. wrote:
> > > I'm happy to provide you with an even smaller and
> > > easier test case.
> > >
> > > Just
> > >
> > >  1.) copy the attached tar archive "bug.2.tar"
> > >  to the /tmp directory and
> > >
> > >  2.) do what the attached video shows
> > >
> > >  $ cd /tmp
> > >
> > >  $ tar -xvf bug.2.tar
> > >
> > >  $ kdenlive bug.2.kdenlive
> > >
> > >  Select track Video 3's Affine transition
> > >  by clicking on it with the mouse
> > >
> > >  Click on the "Go to next key frame"
> > >  button.
> > >
> > >  Wait a moment for
> > >
> > >  "[mlt_pool] out of memory"
> > >
> > >  in the console.
> >
> 
> I did not get the above error even though my system only has 6 GiB RAM and
> only 2.7 free at this time with Gnome Shell, Firefox with 2 tabs, and a
> terminal window open. However, running top in the terminal I do observe the
> RES going up to about 2.4g when running this test.
> 
> 
> >
> > Hi all,
> >
> > Sorry for the late feedback. So I made a few tests and found some
> > interesting facts.
> > The problem seems related to frame buffer.
> >
> > When setting the "buffer" property to 0 on the consumer (sdl2_audio) in
> > Kdenlive, the memory usage stays stable (around 500Mb).
> >
> > When setting the buffer to 25 (default in Kdenlive), I get 2 different
> > situations:
> > - When using an HD 25fps profile, memory usage goes to about 700Mb
> > - When using a SD NTSC profile, memory usage quickly goes up to 2.3Gb.
> >
> >
> The only way I was able to reproduce the above was by using the Project
> Settings dialog in Kdenlive to change the profile because in that case, for
> me, images no longer load and all I get is black in the preview area. If I
> edit the .kdenlive file to change the profile element, then I still
> reproduce a high memory usage. Curiously, the lower resolution does use
> about 200 MiB more than 1280x720 in my tests. The frame rate did not make a
> difference. Also, it is not really necessary to select the Affine effect
> and click next keyframe. Simply scrubbing the timeline or switching to
> Project Monitor and playing the project through also uses up to ~2.4g RES.
> 
> 
> > These tests were done with the image attached in the latest email
> > (3800x2500 jpeg).
> >
> 
> At this point, I should point out that, in MLT, using high resolution
> images with affine generally requires a lot of memory. This is because
> affine requests the full source resolution from the source producer and
> bypasses the automatic scaling to project resolution. It does this so you
> can use affine to crop and scale and take advantage of all the available
> resolution. Imagine a heavy cropping scenario like a portrait photo
> included in a 16:9 video resolution and wanting little-to-no black bars.
> Best to do that by cropping from the original image instead of scaling
> original image down to 1280x720, cropping top and bottom to achieve 16:9,
> and then scaling that up to fill the video frame.
> 
> Affine works in RGBA such that there are 4 bytes per pixel. As a result
> 3800 * 2500 * 4 = ~36.24 MiB. If for some reason - for example, lack of
> optimizations - there are 2 of these per MLT frame (after all there are 2
> affine effects in the project), and there are 25 MLT frames in the consumer
> buffer JB mentions above; then 36.24 MiB * 2 * 25 ~= 1.8 GiB. Add to that
> memory used by the MLT  and Kdenlive, and we start to approach the RES
> number I was seeing. I should also point out that the RES number stays
> around this high level and does not grow excessively while scrubbing,
> playing, and clicking next keyframe.
> 
> Playing the project with "melt -consumer sdl2 buffer=1" uses ~1.5g RES
> where buffer=25 makes it shoot up to 2.8g.
> Now I can take a closer look at what can be done to reduce memory usage.
> 
> I will try to make more tests but wondering if the frame caching bugs
> > when using profile with a non integer fps profile..
> >
> > Regards
> > jb
> >
> >
> > > So,
> > > Kingsley
> > >
> >
> >
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mlt-devel mailing list
> > mlt-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mlt-devel
> >

-- 
Time is the fire in which we all burn.

Bug#893152: needrestart: leaks a file descriptor into restarted services

[Stephen Rothwell]

Package: needrestart
Version: 3.0-1
Severity: normal

Dear Maintainer,

Services restarted by needrestart have a unexpected file descriptor
open (on /usr/share/perl5/NeedRestart/UI/Debconf.pm).  Manually
restarting the service gets rid of it.

For example: lvcreate when used from a cron job after cron has been
restarted by needrestart reports:

File descriptor 4 (/usr/share/perl5/NeedRestart/UI/Debconf.pm) leaked on 
lvcreate invocation. Parent PID 9376: /bin/sh

-- Package-specific info:
needrestart output:
Your outdated processes:
dtach[28687], qemu-system-x86[28688], znc[5268]

checkrestart output:


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

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

Versions of packages needrestart depends on:
ii  binutils   2.30-7
ii  dpkg   1.19.0.5
ii  gettext-base   0.19.8.1-4
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.24-1
ii  libproc-processtable-perl  0.55-1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.37-1+b2
ii  perl   5.26.1-5
ii  xz-utils   5.2.2-1.3

Versions of packages needrestart recommends:
ii  sysvinit-core  2.88dsf-59.10

Versions of packages needrestart suggests:
pn  needrestart-session | libnotify-bin  

-- no debconf information

-- 
Cheers,
Stephen Rothwell


pgpqgtLIf1Q6t.pgp
Description: OpenPGP digital signature

Bug#893151: xapers: cannot import PDF filenames with multiple consecutive spaces

[Nathaniel Morck Beaver]

Package: xapers
Version: 0.7.1-1
Severity: normal
Tags: upstream

Some filenames have multiple consecutive spaces. For example:

'this  filename   ismultiply spaced.pdf'

Pybtex, like BibTeX, removes multiple consecutive spaces:

'this filename is multiply spaced.pdf'

This means that xapers cannot import a BibTeX file containing paths with 
multiple consecutive spaces.


I've attached an example error message when attempting to import an 
actual file (err.txt) as well as a python script that runs a minimal 
working example.


If the file is imported using "xapers add" instead of "xapers import", 
the bibtex file in the subdirectory of ~/.xapers/docs/ will contain the 
wrong path, since the consecutive spaces have been removed.


I've reproduced this bug with the latest git revision:

e4131c21bb8222bea6b896e8efe9571aaef87063

from here:

https://finestructure.net/git/xapers

Besides changing the filename, I have not discovered a workaround.

Sincerely,

Nathaniel Beaver

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xapers depends on:
ii  poppler-utils 0.48.0-2+deb9u2
ii  pybtex0.20.1-1
ii  python-pkg-resources  33.1.1-1
ii  python-urwid  1.3.1-2+b1
ii  python-xapian 1.4.3-1
pn  python:any

Versions of packages xapers recommends:
ii  python-pycurl  7.43.0-2
ii  xclip  0.12+svn84-4+b1
ii  xdg-utils  1.1.1-1

xapers suggests no packages.

-- no debconf information
frank_struktur_1975
  Adding file: 
/home/nathaniel/.zotero/zotero/vt5s686l.default/zotero/storage/H3Q2PJGT/Frank 
et al. - 1975 - Die Struktur der Phase Li5Sn2 The Crystal Struct.pdf
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
  File "/usr/lib/python2.7/dist-packages/xapers/__main__.py", line 227, in 

cli.importbib(db, bibfile, tags=tags)
  File "/usr/lib/python2.7/dist-packages/xapers/cli.py", line 353, in importbib
doc.add_file(filepath)
  File "/usr/lib/python2.7/dist-packages/xapers/documents.py", line 274, in 
add_file
with open(infile, 'r') as f:
IOError: [Errno 2] No such file or directory: 
u'/home/nathaniel/.zotero/zotero/vt5s686l.default/zotero/storage/H3Q2PJGT/Frank 
et al. - 1975 - Die Struktur der Phase Li5Sn2 The Crystal Struct.pdf'
#! /usr/bin/python

import xapers.bibtex

myexample = u"""
@article{myexample,
	file = {this  filename   ismultiply spaced.pdf:this  filename   ismultiply spaced.pdf:application/pdf}
}
"""

if __name__ == '__main__':

original_filename = u'this  filename   ismultiply spaced.pdf'
mybib = xapers.bibtex.Bibtex(myexample)
myent = next(mybib)
print(original_filename)
print(myent.get_file())

Bug#893150: fop FTBFS with openjdk-9

[Adrian Bunk]

Source: fop
Version: 1:2.1-7
Severity: serious

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

...
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/complexscripts/bidi/DelimitedTextRange.java:41:
 error: unmappable character (0xC2) for encoding US-ASCII
[javac]  * by XML-FO 1.1 ??5.8, which contains a flattened sequence of 
characters. Any FO that generates
[javac]  ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/complexscripts/bidi/DelimitedTextRange.java:41:
 error: unmappable character (0xA7) for encoding US-ASCII
[javac]  * by XML-FO 1.1 ??5.8, which contains a flattened sequence of 
characters. Any FO that generates
[javac]   ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/intermediate/ArcToBezierCurveTransformer.java:50:
 error: unmappable character (0xC3) for encoding US-ASCII
[javac] //  Drawing an elliptical arc using polylines, 
quadratic or cubic B??zier curves
[javac] 
   ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/intermediate/ArcToBezierCurveTransformer.java:50:
 error: unmappable character (0xA9) for encoding US-ASCII
[javac] //  Drawing an elliptical arc using polylines, 
quadratic or cubic B??zier curves
[javac] 
^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java:39:
 error: unmappable character (0xC3) for encoding US-ASCII
[javac]  * Boris Poud??rous (boris.pouder...@eads-telecom.com),
[javac]  ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java:39:
 error: unmappable character (0xA9) for encoding US-ASCII
[javac]  * Boris Poud??rous (boris.pouder...@eads-telecom.com),
[javac]   ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java:40:
 error: unmappable character (0xC3) for encoding US-ASCII
[javac]  * Normand Mass??, and
[javac]^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java:40:
 error: unmappable character (0xA9) for encoding US-ASCII
[javac]  * Normand Mass??, and
[javac] ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/TextAttributesConverter.java:55:
 error: unmappable character (0xC3) for encoding US-ASCII
[javac]  * Boris Poud??rous (boris.pouder...@eads-telecom.com),
[javac]  ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/TextAttributesConverter.java:55:
 error: unmappable character (0xA9) for encoding US-ASCII
[javac]  * Boris Poud??rous (boris.pouder...@eads-telecom.com),
[javac]   ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/TextAttributesConverter.java:57:
 error: unmappable character (0xC3) for encoding US-ASCII
[javac]  * Normand Mass??,
[javac]^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/TextAttributesConverter.java:57:
 error: unmappable character (0xA9) for encoding US-ASCII
[javac]  * Normand Mass??,
[javac] ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/IRtfTableContainer.java:35:
 error: unmappable character (0xC3) for encoding US-ASCII
[javac]  * and Boris Poud??rous.
[javac]  ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/IRtfTableContainer.java:35:
 error: unmappable character (0xA9) for encoding US-ASCII
[javac]  * and Boris Poud??rous.
[javac]   ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfAfterBeforeBase.java:111:
 error: unmappable character (0xC3) for encoding US-ASCII
[javac]  * @param tc added by Boris Poud??rous on july 2002 in order to 
process
[javac] ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfAfterBeforeBase.java:111:
 error: unmappable character (0xA9) for encoding US-ASCII
[javac]  * @param tc added by Boris Poud??rous on july 2002 in order to 
process
[javac]  ^
[javac] 
/build/1st/fop-2.1/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfContainer.java:44:
 error: unmappable character (0xC3) 

Bug#852856: collaborate

[Geert Stappers]

On Thu, Mar 15, 2018 at 01:41:26PM +, Jonathan McDowell wrote:
> On Wed, Mar 14, 2018 at 04:07:54PM +0100, Geert Stappers wrote:
> > On Mon, Mar 12, 2018 at 10:37:28PM +, Jonathan McDowell wrote:
> > > If you want to work together you have to have a discussion. I appreciate
> > > the bug has been languishing without a response but it pre-dates my
> > > involvement with the OpenOCD package and it's not been as high priority
> > > as getting the package up to date with upstream or dealing with security
> > > issues.
> > 
> > Yes, I'm here for working together, for having a discussion.
> > 
> > For creating concence.
> } For creating consensus.
> 
> I don't understand. Can you rephrase?

Something that was transmitted as answer to
> > > If you want to work together you have to have a discussion.
seemed to be recieved very mangled.

Can I rephrase it?
An attempt follows, mindset is "I come in peace"

Hello OpenOCD maintainers,

Here a fellow Debian Developer, the maintainer of urjtag.
Infact the fresh maintainer of urjtag.

Packages OpenOCD and UrJTAG both use "JTAG adapters".

Those adapters need some permission setting.
Such setting can be done by udev rules.
OpenOCD already does that.  UrJTAG doesn't.

By re-use of the udev rule file can bugs
like #851428 access permission on device
 ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851428 )
be fixed.

All that is needed is putting the udev rules in separate package.

I could do this by doing so and see who would complain,
but I prefer for discussion first. So I opened this bugreport.

First there was silence, now we are beyond that.
The actual working together has started.
There is this discussion.


Cheers
Geert Stappers
-- 
End of rephrased transmit  :-)

Bug#893149: ceph FTBFS with openjdk-9

[Adrian Bunk]

Source: ceph
Version: 10.2.5-7
Severity: serious
Tags: buster sid

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

...
Making all in java
make[4]: Entering directory '/build/1st/ceph-10.2.5/src/java'
export CLASSPATH=java/ ; \
javac -classpath java -source 1.5 -target 1.5 -Xlint:-options 
java/com/ceph/fs/*.java
error: Source option 1.5 is no longer supported. Use 1.6 or later.
error: Target option 1.5 is no longer supported. Use 1.6 or later.
make[4]: *** [Makefile:647: java/com/ceph/fs/CephMount.class] Error 2

Bug#827569: twine: HTML documentation is useless

[Sumana Harihareswara]

As of Twine 1.10.0 (earlier this month) the HTML documentation is
useful. (I fixed the Sphinx configuration.)

New release: https://pypi.org/project/twine/1.10.0/

Read the Docs copy of HTML docs: http://twine.readthedocs.io/

Bug#893148: ycmd: Please update to newer upstream snapshot

[Mirosław Zalewski]

Package: ycmd
Version: 0+20161219+git486b809-2.1
Severity: normal

Dear Maintainer,

current ycmd in Debian is git snapshot made in December 2016. Since
then, upstream had around 400 commits introducing new features and bug
fixes.

One such bug that I have personally experienced is ycmd crashing tsserver,
needed for TypeScript completion. Updating ycmd/completers/typescript/
directory with content of mirror directory from current git fixed
this issue.

Thank you,
Mirosław Zalewski


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

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

Versions of packages ycmd depends on:
ii  libboost-filesystem1.62.0  1.62.0+dfsg-5
ii  libboost-python1.62.0  1.62.0+dfsg-5
ii  libboost-regex1.62.0   1.62.0+dfsg-5
ii  libboost-system1.62.0  1.62.0+dfsg-5
ii  libc6  2.27-2
ii  libclang1-3.9  1:3.9.1-19
ii  libgcc11:8-20180218-1
ii  libpython2.7   2.7.14-6
ii  libstdc++6 8-20180218-1
ii  python 2.7.14-4
ii  python-bottle  0.12.13-1
ii  python-frozendict  0.5-1
ii  python-future  0.15.2-4
ii  python-jedi0.11.1-1
ii  python-requests2.18.4-2
ii  python-waitress1.0.1-1
ii  python2.7  2.7.14-6

Versions of packages ycmd recommends:
pn  libclang-common-3.9-dev  
pn  node-typescript  
ii  vim-youcompleteme0+20161219+git194ff33-1

ycmd suggests no packages.

-- no debconf information

Bug#893147: linux: ath5k wlan0: authentication timed out with 4.9 kernel works with 3.16

[Gregor Horvath]

Source: linux
Severity: normal

# lspci | grep Wireless
02:05.0 Ethernet controller: Qualcomm Atheros AR2413/AR2414 Wireless Network
Adapter [AR5005G(S) 802.11bg] (rev 01)


* Not Working:

root@siemens:~# uname -r
4.9.0-5-686-pae

root@siemens:~# dmesg | grep wlan0
[   47.026184] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   47.037285] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   47.051527] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   48.461244] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   80.971528] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   82.161931] wlan0: authenticate with 00:22:6b:86:98:67
[   82.176367] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[   82.199329] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[   82.214417] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[   82.227411] wlan0: authentication with 00:22:6b:86:98:67 timed out
[   83.322021] wlan0: authenticate with 00:22:6b:86:98:67
[   83.336345] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[   83.353973] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[   83.371073] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[   83.390738] wlan0: authentication with 00:22:6b:86:98:67 timed out
[   84.885203] wlan0: authenticate with 00:22:6b:86:98:67
[   84.904195] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[   84.916481] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[   84.932480] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[   84.948901] wlan0: authentication with 00:22:6b:86:98:67 timed out
[   86.889101] wlan0: authenticate with 00:22:6b:86:98:67
[   86.903476] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[   86.919199] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[   86.940616] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[   86.957311] wlan0: authentication with 00:22:6b:86:98:67 timed out
[   98.845892] wlan0: authenticate with 00:22:6b:86:98:67
[   98.860593] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[   98.875774] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[   98.894621] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[   98.910664] wlan0: authentication with 00:22:6b:86:98:67 timed out
[  106.026329] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  106.044128] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  107.115869] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  107.180088] wlan0: authenticate with 00:22:6b:86:98:67
[  107.185138] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[  107.200363] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[  107.214567] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[  107.233627] wlan0: authentication with 00:22:6b:86:98:67 timed out
[  118.245122] wlan0: authenticate with 00:22:6b:86:98:67
[  118.262568] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[  118.279023] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[  118.296099] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[  118.308844] wlan0: authentication with 00:22:6b:86:98:67 timed out
[  132.023727] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  132.051571] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  132.998515] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  133.222015] wlan0: authenticate with 00:22:6b:86:98:67
[  133.227178] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[  133.241787] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[  133.260417] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[  133.276863] wlan0: authentication with 00:22:6b:86:98:67 timed out
[  144.186250] wlan0: authenticate with 00:22:6b:86:98:67
[  144.213781] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[  144.234815] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[  144.255020] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[  144.273189] wlan0: authentication with 00:22:6b:86:98:67 timed out
[  158.045614] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  158.097995] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  159.057346] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  159.221921] wlan0: authenticate with 00:22:6b:86:98:67
[  159.226570] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[  159.240533] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[  159.255092] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[  159.274127] wlan0: authentication with 00:22:6b:86:98:67 timed out
[  176.177250] wlan0: authenticate with 00:22:6b:86:98:67
[  176.195678] wlan0: send auth to 00:22:6b:86:98:67 (try 1/3)
[  176.211879] wlan0: send auth to 00:22:6b:86:98:67 (try 2/3)
[  176.229956] wlan0: send auth to 00:22:6b:86:98:67 (try 3/3)
[  176.244622] wlan0: authentication with 00:22:6b:86:98:67 timed out
[  184.055996] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  184.111578] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

* Working:

root@siemens:/etc/grub.d# uname -r
3.16.0-5-686-pae

Same with both kernels:
# lsmod | grep ath
ath5k 131413  0
ath21707  1 

Bug#893146: ITP: python-numpysane -- more-reasonable core functionality for numpy

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: python-numpysane
  Version : 0.13
  Upstream Author : Dima Kogan 
* URL or Web page : https://github.com/dkogan/numpysane
* License : LGPL-3+
  Description : more-reasonable core functionality for numpy

Numpy is widely used, relatively polished, and has a wide range of
libraries available. At the same time, some of its very core
functionality is strange, confusing and just plain wrong. This module
intends to improve the developer experience by providing alternate APIs
to some core numpy functionality that is much more reasonable.

Bug#893110: gupnp-igd: FTBFS (randomly?) testsuite failures - gupnp-simple-igd SIGTRAP

[Jeremy Bicha]

On Fri, Mar 16, 2018 at 11:42 AM, James Cowgill  wrote:
> While it built on amd64 on the buildds, the package fails with the same
> error when I locally rebuild it. I notice it build fine on all the
> Ubuntu builders. I'm afraid I have no idea what is going on here.

Thank you for taking the time to file this bug.

I think the tests are flaky and I may have needed to retry some of
those builds on Ubuntu. It's a bit easier for an Ubuntu Developer to
retry builds than for a Debian Developer to do it in Debian.

I don't really care that much about this package and I intend to do
another upload where I just ignore test failures. (Before this upload,
the tests weren't even being run.)

Thanks,
Jeremy Bicha

Bug#893142: dogtag-pki FTBFS with openjdk-9

[Adrian Bunk]

Source: dogtag-pki
Version: 10.5.5-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dogtag-pki.html

...
netscape/security/x509/RevocationReasonAdapter.java:20: error: package 
javax.xml.bind.annotation.adapters is not visible
import javax.xml.bind.annotation.adapters.XmlAdapter;
^
  (package javax.xml.bind.annotation.adapters is declared in module 
java.xml.bind, which is not in the module graph)

Bug#893145: excalibur-logkit FTBFS with openjdk-9

[Adrian Bunk]

Source: excalibur-logkit
Version: 2.0-11
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/excalibur-logkit.html

...
compile:
[mkdir] Created dir: /build/1st/excalibur-logkit-2.0/target/classes
[javac] /build/1st/excalibur-logkit-2.0/build.xml:34: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Compiling 61 source files to 
/build/1st/excalibur-logkit-2.0/target/classes
[javac] Using ant.build.javac.target 1.4 is no longer supported, switching 
to 1.6
[javac] Using ant.build.javac.target 1.4 is no longer supported, switching 
to 1.6
[javac] Using ant.build.javac.source 1.4 is no longer supported, switching 
to 1.6
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:32: 
error: unmappable character (0xEF) for encoding US-ASCII
[javac]  * caller ??? 
???-com.biz.MyCaller.method(MyCaller.java:18)
[javac]   ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:32: 
error: unmappable character (0xBF) for encoding US-ASCII
[javac]  * caller ??? 
???-com.biz.MyCaller.method(MyCaller.java:18)
[javac]^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:32: 
error: unmappable character (0xBD) for encoding US-ASCII
[javac]  * caller ??? 
???-com.biz.MyCaller.method(MyCaller.java:18)
[javac] ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:32: 
error: unmappable character (0xEF) for encoding US-ASCII
[javac]  * caller ??? 
???-com.biz.MyCaller.method(MyCaller.java:18)
[javac]   ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:32: 
error: unmappable character (0xBF) for encoding US-ASCII
[javac]  * caller ??? 
???-com.biz.MyCaller.method(MyCaller.java:18)
[javac]^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:32: 
error: unmappable character (0xBD) for encoding US-ASCII
[javac]  * caller ??? 
???-com.biz.MyCaller.method(MyCaller.java:18)
[javac] ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:33: 
error: unmappable character (0xEF) for encoding US-ASCII
[javac]  * source ??? ???-1.6.3.2:33
[javac]   ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:33: 
error: unmappable character (0xBF) for encoding US-ASCII
[javac]  * source ??? ???-1.6.3.2:33
[javac]^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:33: 
error: unmappable character (0xBD) for encoding US-ASCII
[javac]  * source ??? ???-1.6.3.2:33
[javac] ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:33: 
error: unmappable character (0xEF) for encoding US-ASCII
[javac]  * source ??? ???-1.6.3.2:33
[javac]   ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:33: 
error: unmappable character (0xBF) for encoding US-ASCII
[javac]  * source ??? ???-1.6.3.2:33
[javac]^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/ContextMap.java:33: 
error: unmappable character (0xBD) for encoding US-ASCII
[javac]  * source ??? ???-1.6.3.2:33
[javac] ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/Logger.java:298: error: 
unmappable character (0xEF) for encoding US-ASCII
[javac]  * Determine if messages of priority ???will be logged.
[javac]  ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/Logger.java:298: error: 
unmappable character (0xBF) for encoding US-ASCII
[javac]  * Determine if messages of priority ???will be logged.
[javac]   ^
[javac] 
/build/1st/excalibur-logkit-2.0/src/java/org/apache/log/Logger.java:298: error: 
unmappable character (0xBD) for encoding US-ASCII
[javac]  * Determine if messages of priority ???will be logged.
[javac]^
[javac] 15 errors
[javac] 4 warnings

BUILD FAILED
/build/1st/excalibur-logkit-2.0/build.xml:34: Compile failed; see the compiler 
error output for details.

Total time: 1 second

Bug#893143: easyconf FTBFS with openjdk-9

[Adrian Bunk]

Source: easyconf
Version: 0.9.5-5
Severity: serious
Tags: buster sid

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

...
compile:
[mkdir] Created dir: /build/1st/easyconf-0.9.5/target/classes
[javac] /build/1st/easyconf-0.9.5/build.xml:36: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Compiling 27 source files to 
/build/1st/easyconf-0.9.5/target/classes
[javac] Using ant.build.javac.target 1.5 is no longer supported, switching 
to 1.6
[javac] Using ant.build.javac.target 1.5 is no longer supported, switching 
to 1.6
[javac] Using ant.build.javac.source 1.5 is no longer supported, switching 
to 1.6
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/ClassParameter.java:25:
 error: unmappable character (0xE9) for encoding US-ASCII
[javac]  * M?todos de utilidad para trabajar con par?metros de 
configuraci?n que representan
[javac] ^
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/ClassParameter.java:25:
 error: unmappable character (0xE1) for encoding US-ASCII
[javac]  * M?todos de utilidad para trabajar con par?metros de 
configuraci?n que representan
[javac] ^
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/ClassParameter.java:25:
 error: unmappable character (0xF3) for encoding US-ASCII
[javac]  * M?todos de utilidad para trabajar con par?metros de 
configuraci?n que representan
[javac]   ^
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/ClassParameter.java:28:
 error: unmappable character (0xFA) for encoding US-ASCII
[javac]  * @author Jes?s J?imez Rodr?guez 
[javac]   ^
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/ClassParameter.java:28:
 error: unmappable character (0xE1) for encoding US-ASCII
[javac]  * @author Jes?s J?imez Rodr?guez 
[javac]   ^
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/ClassParameter.java:28:
 error: unmappable character (0xED) for encoding US-ASCII
[javac]  * @author Jes?s J?imez Rodr?guez 
[javac] ^
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/jmx/ComponentConfigurationDynamicMBean.java:49:
 error: unmappable character (0xEF) for encoding US-ASCII
[javac]  * @author Alvaro Gonz???lez
[javac]   ^
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/jmx/ComponentConfigurationDynamicMBean.java:49:
 error: unmappable character (0xBF) for encoding US-ASCII
[javac]  * @author Alvaro Gonz???lez
[javac]^
[javac] 
/build/1st/easyconf-0.9.5/src/java/com/germinus/easyconf/jmx/ComponentConfigurationDynamicMBean.java:49:
 error: unmappable character (0xBD) for encoding US-ASCII
[javac]  * @author Alvaro Gonz???lez
[javac] ^
[javac] 9 errors
[javac] 4 warnings

BUILD FAILED
/build/1st/easyconf-0.9.5/build.xml:36: Compile failed; see the compiler error 
output for details.

Total time: 9 seconds
make: *** [/usr/share/cdbs/1/class/ant.mk:39: debian/stamp-ant-build] Error 1

Bug#893144: entagged FTBFS with openjdk-9

[Adrian Bunk]

Source: entagged
Version: 0.35-5
Severity: serious
Tags: buster sid

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

...
compile:
[javac] /build/1st/entagged-0.35/build.xml:55: warning: 'includeantruntime' 
was not set, defaulting to build.sysclasspath=last; set to false for repeatable 
builds
[javac] Using javac -source 1.5 is no longer supported, switching to 1.6
[javac] Compiling 338 source files
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] /build/1st/entagged-0.35/entagged/audioformats/AudioFile.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/AudioFileFilter.java:3: error: 
unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] /build/1st/entagged-0.35/entagged/audioformats/AudioFileIO.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] /build/1st/entagged-0.35/entagged/audioformats/EncodingInfo.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] /build/1st/entagged-0.35/entagged/audioformats/Tag.java:3: error: 
unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] /build/1st/entagged-0.35/entagged/audioformats/Tag.java:48: error: 
unmappable character (0xEB) for encoding US-ASCII
[javac]  * @author Rapha?l Slinckx
[javac] ^
[javac] /build/1st/entagged-0.35/entagged/audioformats/ape/ApeTag.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/MonkeyFileReader.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/MonkeyFileWriter.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/util/ApeTagBinaryField.java:3:
 error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/util/ApeTagCreator.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/util/ApeTagField.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/util/ApeTagReader.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/util/ApeTagTextField.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/util/ApeTagWriter.java:3: 
error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 
/build/1st/entagged-0.35/entagged/audioformats/ape/util/MonkeyDescriptor.java:3:
 error: unmappable character (0xEB) for encoding US-ASCII
[javac]  * Copyright (c) 2003-2005 Rapha?l Slinckx 
[javac] ^
[javac] 

Bug#893141: dumbster FTBFS with openjdk-9

[Adrian Bunk]

Source: dumbster
Version: 1.6+debian-3
Severity: serious

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

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/dumbster-1.6+debian'
dh_auto_build -- test
ant -propertyfile ./debian/ant.properties -Duser.name debian test
Buildfile: /build/1st/dumbster-1.6+debian/build.xml

init:

compile-tests:
[javac] /build/1st/dumbster-1.6+debian/build.xml:82: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Compiling 4 source files to 
/build/1st/dumbster-1.6+debian/build/test

test:
[junit] Running com.dumbster.smtp.SimpleSmtpServerTest
[junit] Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 
0.233 sec

BUILD FAILED
/build/1st/dumbster-1.6+debian/build.xml:89: Test 
com.dumbster.smtp.SimpleSmtpServerTest failed

Total time: 3 seconds
dh_auto_build: ant -propertyfile ./debian/ant.properties -Duser.name debian 
test returned exit code 1
make[1]: *** [debian/rules:13: override_dh_auto_test] Error 2

Bug#893140: secpanel: depends on deprecated Tcl/Tk 8.5

[Sergei Golovan]

Package: secpanel
Version: 1:0.6.1-2
Severity: important
Tags: patch

Dear Maintainer,

Tcl/Tk 8.5 has reached its end-of-life, and I'm planning to remove it from 
Debian.
I'd like to suggest a patch (with possible NMU if you don't mind) which would
replaces tcl8.5 and tk8.5 by tcl and tk (the current default Tcl/Tk version)
and remove a patch to restore calling wish and not wish8.5.

-- System Information:
Debian Release: 9.4
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable'), (1, 
'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages secpanel depends on:
ii  openssh-client   1:7.4p1-10+deb9u3
ii  rxvt [x-terminal-emulator]   1:2.7.10-7+b1
ii  rxvt-unicode-256color [x-terminal-emulator]  9.22-1+b1
ii  ssh-askpass  1:1.2.4.1-9+b2
ii  tcl  8.6.0+9
ii  tk   8.6.0+9
ii  xfce4-terminal [x-terminal-emulator] 0.8.3-1
ii  xterm [x-terminal-emulator]  327-2

Versions of packages secpanel recommends:
ii  chromium [www-browser] 64.0.3282.119-1~deb9u1
ii  elinks [www-browser]   0.12~pre6-12
ii  firefox-esr [www-browser]  52.6.0esr-1~deb9u1
ii  links [www-browser]2.14-2+b1
ii  lynx [www-browser] 2.8.9dev11-1
ii  w3m [www-browser]  0.5.3-34+deb9u1

secpanel suggests no packages.

-- no debconf information
diff -Nru secpanel-0.6.1/debian/changelog secpanel-0.6.1/debian/changelog
--- secpanel-0.6.1/debian/changelog 2013-11-02 08:35:50.0 +0400
+++ secpanel-0.6.1/debian/changelog 2018-03-16 23:40:07.0 +0300
@@ -1,3 +1,11 @@
+secpanel (1:0.6.1-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Switch to the default Tcl/Tk version because Tcl/Tk 8.5 is to be removed
+from Debian.
+
+ -- Sergei Golovan   Fri, 16 Mar 2018 23:40:07 +0300
+
 secpanel (1:0.6.1-2) unstable; urgency=low
 
   * debian/control
diff -Nru secpanel-0.6.1/debian/control secpanel-0.6.1/debian/control
--- secpanel-0.6.1/debian/control   2013-11-02 08:08:40.0 +0400
+++ secpanel-0.6.1/debian/control   2018-03-16 23:39:07.0 +0300
@@ -8,7 +8,7 @@
 
 Package: secpanel
 Architecture: all
-Depends: tcl8.5 | tclsh, tk8.5, openssh-client, ssh-askpass, xterm | 
x-terminal-emulator, ${misc:Depends}
+Depends: tcl, tk, openssh-client, ssh-askpass, xterm | x-terminal-emulator, 
${misc:Depends}
 Recommends: www-browser
 Description: graphical user interface for SSH and SCP
  SecPanel is a graphical user interface for managining
diff -Nru secpanel-0.6.1/debian/patches/04_use_wish8.5.diff 
secpanel-0.6.1/debian/patches/04_use_wish8.5.diff
--- secpanel-0.6.1/debian/patches/04_use_wish8.5.diff   2013-11-02 
08:17:57.0 +0400
+++ secpanel-0.6.1/debian/patches/04_use_wish8.5.diff   1970-01-01 
03:00:00.0 +0300
@@ -1,26 +0,0 @@
-Description: Use /usr/bin/wish8.5
-Author: Daniel Echeverry 
-Forwarded: no
-Last-Update: 2013-11-01
 secpanel-0.6.1.orig/local/bin/secpanel
-+++ secpanel-0.6.1/local/bin/secpanel
-@@ -1,7 +1,7 @@
- #!/bin/sh
- #  -*- tcl -*-
- # Executing wish #\
--exec wish "$0" "$@"
-+exec /usr/bin/wish8.5 "$0" "$@"
- 
- ###
- #
 secpanel-0.6.1.orig/local/lib/secpanel/dppw.tcl
-+++ secpanel-0.6.1/local/lib/secpanel/dppw.tcl
-@@ -1,7 +1,7 @@
- #!/bin/sh
- #  -*- tcl -*-
- # Executing wish #\
--exec wish "$0" "$@"
-+exec /usr/bin/wish8.5 "$0" "$@"
- 
- 
- 
diff -Nru secpanel-0.6.1/debian/patches/series 
secpanel-0.6.1/debian/patches/series
--- secpanel-0.6.1/debian/patches/series2013-11-02 07:46:56.0 
+0400
+++ secpanel-0.6.1/debian/patches/series2018-03-16 23:40:07.0 
+0300
@@ -1,4 +1,3 @@
 03_use_x-terminal-emulator.diff
 02_add_interpreted_sequence.diff
 01_path_fix.diff
-04_use_wish8.5.diff

Bug#854149: affected fonts

[Horst Schirmeier]

My test case: echo -e 'a\u0308a'

Correct rendering: äa
(That's what I see with: Courier, Cousine, DejaVu Sans Mono, FreeMono)

Incorrect rendering: aä
(That's what I see with: Andale Mono, Bitstream Vera Sans Mono, Courier
10 Pitch, Courier New, Hack Mono, Liberation Mono, Mitra Mono, Nimbus
Mono L, Noto Mono, Oxygen Mono, Tlwg Mono, Tlwg Typo, Ubuntu Mono)

-- 
PGP-Key 0xD40E0E7A


signature.asc
Description: Digital signature

Bug#893139: anarchism: typo in d/doc-base

[Lev Lamberov]

Package: anarchism
Version: 15.1-5
Severity: minor
Tags: patch

Dear Maintainer,

d/doc-base contains a typo: the document title is "An Anarchist FAQ",
where d/doc-base defines title as "An Anarquist FAQ". Because of that
the documentation is registered in the local documentation database
under a misspelled title.

Please find attached patch to fix it.

Regards,
Lev Lamberov


-- 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

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

Versions of packages anarchism depends on:
ii  xdg-utils  1.1.2-2

anarchism recommends no packages.

Versions of packages anarchism suggests:
ii  chromium [www-browser]  62.0.3202.89-1
ii  elinks [www-browser]0.12~pre6-13
ii  firefox [www-browser]   59.0-1
pn  fortune-anarchism   
ii  lynx [www-browser]  2.8.9dev16-3
ii  yelp3.26.0-2

-- no debconf information
>From 1400cf996024170f05b2fb6a934298e3144dd153 Mon Sep 17 00:00:00 2001
From: Lev Lamberov 
Date: Sat, 17 Mar 2018 01:42:00 +0500
Subject: [PATCH] Fix typo in d/doc-base

---
 debian/doc-base | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/doc-base b/debian/doc-base
index 0fdfab3..f76cd6d 100644
--- a/debian/doc-base
+++ b/debian/doc-base
@@ -1,7 +1,7 @@
 Document: anarchism
-Title: An Anarquist FAQ
+Title: An Anarchist FAQ
 Author: Iain McKay, Gary Elkin, Dave Neal, Ed Boraas
-Abstract: An exhaustive exploration of Anarchist theory and practice 
+Abstract: An exhaustive exploration of Anarchist theory and practice
 Section: Help/FAQ
 
 Format: HTML
-- 
2.16.2

Bug#816750: uswsusp: suspend-keygen missing

[Alberto Garcia]

Control: merge 816750 824464
Control: severity -1 important

On Fri, Mar 04, 2016 at 10:16:31PM +0100, Marc Lehmann wrote:
> Package: uswsusp
> Version: 1.0+20120915-6.1
> Severity: normal
> 
> Dear Maintainer,
> 
> the package contains the manpage for suspend-keygen, but the actual
> suspend-keygen comamnd is missing:

So it seems that this package needs an old version of gcrypt (#758995)
and because of that encryption support was disabled (#763260).

Raising severity to important because I believe that this is an
important feature.

Berto

Bug#892861: libglm-dev: removal of default type initialization breaking packages

[Guus Sliepen]

tags 892861 + wontfix
thanks

On Wed, Mar 14, 2018 at 10:48:33AM +1300, Andrew Caudwell wrote:

> The packaged version of GLM, 0.9.9~a2 is an alpha (the current release is 
> still
> 0.9.8.5) and removes the default initialization of vector, matrix and
> quaternion types. Because of this code written against any earlier versions of
> GLM may now have uninitialized value bugs introduced by this change (e.g. 
> where
> GLM types are member variables of a class) or now behave differently (mat4()
> previously gave you an identity matrix, now this gives you a zero'd matrix).
> Several issues have been raised upstream (including by myself) to re-add
> initialization or at least make it optional.
> Additionally the requirement in this version to define GLM_ENABLE_EXPERIMENTAL
[...]
> to use simple functions like length2() has broken multiple packages. I have 
> put
> off fixing this since making it compile just exposes the user to the
> uninitialized value bugs. Unfortunately this has now meant my gource and
> logstalgia debian packages have been removed from debian since they don't
> complile with this GLM version.

I believe these are intentional changes by the author of GLM. I expect
that GLM 1.0.0 will be released before the next release of Debian, and
any packages that depend on GLM should instead be fixed to handle the
new behavior.

Unless I am mistaken, projects depending on GLM can just #define
GLM_ENABLE_EXPERIMENTAL and provide explicit default initializers, which
will be backwards compatible with older versions of GLM.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#890905: Pending fixes for bugs in the jabref package

[pkg-java-maintainers]

tag 890905 + pending
thanks

Some bugs in the jabref package are closed in revision
eb5c1b0e2c48612c16198e34f244bea501e59e56 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/jabref.git/commit/?id=eb5c1b0

Commit message:

Force openjdk-8 at buildtime and runtime.

JabRef doesn't work and run with openjdk-9 which is the default now.

Closes: #890905

Bug#780706: Arduino packaging

[Rock Storm]

Hi guys, so good to see some activity around here!

I tried to package Arduino a while ago but failed miserably and got
distracted with some other projects. I’ll return to it when I find the
time.

I’m sorry but I don’t remember exactly in what state did I leave the
packaging. IIRC, I made preliminary packages for three dependencies:

 * liblistSerials [0]
 * arduino-builder [1]
- golang-go-errors-errors [2]

And I was using Ignacio's package for MrBean [3]. Tried to use Geert's
package of the reference files [4] but I wasn't able to build it. But
since they are "only" reference files I went on without it.

 [0]: https://github.com/rockstorm101/listserialportsc-debian-pkg
 [1]: https://github.com/rockstorm101/arduino-builder-debian-pkg
 [2]: https://github.com/rockstorm101/go-errors-errors-debian-pkg
 [3]: https://github.com/HuayraLinux/pkg-jackson-module-mrbean
 [4]: https://anonscm.debian.org/git/collab-maint/arduino-reference.git


I could, if you wish, upload the repository as it is right now, however
it doesn’t even build, so I’m a little bit reluctant to upload
anything. A quick first try to build today failed with the following
error:

compile:
[mkdir] Created dir: /build/arduino-1.8.5+dfsg/arduino-core/bin
[javac] Compiling 129 source files to /build/arduino-
1.8.5+dfsg/arduino-core/bin
[javac] warning: [options] bootstrap class path not set in
conjunction with -source 1.8
[javac] /build/arduino-1.8.5+dfsg/arduino-
core/src/cc/arduino/contributions/GPGDetachedSignatureVerifier.java:62:
error: cannot access Iterable
[javac] nextObject = pgpObjectFactory.nextObject();
[javac]  ^
[javac]   class file for org.bouncycastle.util.Iterable not found
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
[javac] 1 warning

At first sight it seems the class ‘org.bouncycastle.util.Iterable’ is
found on the version of the Bouncy Castle Crypto package shipped with
Arduino (version 1.52, a jar file named ‘bcpg-jdk15on-152.jar’) but is
not found on the Debian package ‘libbcpg-java’ (currently at version
1.59).

On Wed, 2018-03-14 at 15:15 +0100, Geert Stappers wrote:
> During my first scan couldn't I see how keeping in sync with upstream
> is done  (or planned).
> 
> What are the ideas about such a sychronisation?
> 
> 

Well, the idea was that the packages, once uploaded to Debian, would
keep track of upstream movements via uscan and the debian/watch file.
And of course the repositories would be moved to Salsa, either to
collab-maint or under the umbrella of Debian Science or the Electronics
teams.

Cheers,
-- 
Rock

Bug#893137: ITP: haskell-libiw -- wlib is a thin wrapper over the iw C library

[Aggelos Avgerinos]

Package: wnpp
Severity: wishlist
Owner: Aggelos Avgerinos 

* Package name: haskell-libiw
  Version : 0.1.0
  Upstream Author : Jose A. Ortega Ruiz 
* URL : https://github.com/jaor/iwlib
* License : BSD 3-clause
  Programming Lang: Haskell
  Description : wlib is a thin wrapper over the iw C library

  This used to be inside xmobar source code but the upstream has moved
  it to this project and it's a dependency of the latest xmobar version.

  I intent to package and maintain it in order to upgrade xmobar.

Bug#893024: Manual entry into UI date widget is broken

[Jeffrey Ratcliffe]

Thanks for the report. Fixed in the next release.


pgpFvlwpYal1L.pgp
Description: OpenPGP digital signature

Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

On Fri, Mar 16, 2018 at 09:43:26AM -0500, Kurt Kremitzki wrote:
> 
> 
> On 03/15/2018 04:37 PM, Tobias Frost wrote:
> > On Wed, Mar 14, 2018 at 11:46:28AM +0100, Tobias Frost wrote:
> > > What is still missing from my side is a complete d/copyright review,
> > > but I need a break right now... Will continue later.
> > 
> > Ok, went over the package for a copyright review.
> > One part of the result resulted in a MR [1], but not all could
> > be fixed with that; could be that we need to repack the source
> > and/or ask upstream to fix that in their repo too.
> > 
> > I fear that we have some problematic files:
> > - There are some files from QT examples, but the license header seems to
> >be "old" and unfortunatly not distributeable.
> >Affected are some files in samples/qt/FuncDemo/src, e.g edge.cpp
> >(Later versions of this file seems to be dual-licensed, so likely
> >the remedy is to "update" to a newer version by upstream.
> >But for now, I guess this samples can be removed from the tarball
> >by repacking.
> 
> These were the files I opened an upstream bug about [1] which they've
> already provided a commit for [2], but the bug is tagged for 7.3.0 so I'll
> make a patch to apply it here.

Unfortuantly a patch is not enough, as the problematic sources would
still be in the tarball, which'd be not ok for copyright issues as we
would still distribute them. (actually, we should remove them from
the repository to be safe... git-filter can do that, I guess or 
nuke the repo and regenerate it from scratch. The latter would also 
fix another small issue with the repo: It'd be nice to import all old
versions of Debian packaging from opencascade, using gbp import-dscs --debsnap)

> > - src/NCollection/NCollection_UtfIterator.lxx
> >Is also copyrighted by Unicode Inc. We'll need to have a dedicated
> >section in d/copyright for it
> > - src/OpenGl/glext.h needs also to be documented in d/copyright.
> 
> Roger that.
> 
> > - samples/ios/UIKitSample/UIKitSample/ViewController.* are
> >"copyright ... all rights reserverd.".
> >I guess we need to delete the iOS example from the tarball...
> > - opencascade/samples/mfc/standard/06_Ocaf/src/DebugBrowser.hxx
> >(example, there are others as well) scares me license wise.
> >We will have to delete them (no big loss, as MFC examples are
> >not really useful for us) or ask upstream to clarify.
> > 
> > When we're repackaging anyway, we should also remove all those
> > Windows-Only samples (and their VS project files)
> 
> There are also some .bat files in the top-level directory that are not
> needed. What is the proper procedure for getting rid of them all when
> packaging with git?

I guess we'll need to repack the source, so the removal would be done
while creation of the orig.tar, before importing it into the git repo.
(We need repacking because of the problematic sources; I would not 
bother with the extra files otherwise)

One way would be to use the Files-Excluded: feature of d/copyright,
picked up by uscan or an get-orig-source target for d/rules when you
want to package from a git-commit. (I use the latter for some of my
packages, look at dhewm3 or rbdoom3bfg -- IIRC the latter takes the
list of files to be removed from Files-Excluded for get-orig-source)

> > 
> > Otherwise were some years not accurate (fixed in [1]) and some copyright
> > holders not "verbabitmly" coppied, but else there not much to fix
> > left...
> > 
> > 
> > [1] https://salsa.debian.org/kkremitzki-guest/opencascade/merge_requests/1
> > 
> > --
> >   tobi
> > 
> 
> 
> 1. https://tracker.dev.opencascade.org/view.php?id=29559
> 2. 
> http://git.dev.opencascade.org/gitweb/?p=occt.git;a=commitdiff;h=dd0fae1d0f3ad5faea55e78dee07d735730a2c61;hp=726b5d9e920db065d98ad1b79fc2ab1beb24ba49

Bug#893136: newt-tcl: depends on deprecated Tcl/Tk (8.3-8.5)

[Sergei Golovan]

Package: newt-tcl
Version: 0.52.20-3
Severity: important
Tags: patch

Dear Maintainer,

As I can see, newt-tcl is built using Tcl/Tk 8.6, but depends on tcl8.3 |
tcl8.4 | tcl8.5. Please, replace them by tcl8.6 (8.3 and 8.4 are already
dropped from Debian, and tcl8.5 is about to be). If it's okay to you, I
could upload the package with the attached patch (it just fixes the
dependencies).

-- System Information:
Debian Release: 9.4
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable'), (1, 
'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages newt-tcl depends on:
ii  libc62.24-11+deb9u3
ii  libnewt0.52  0.52.19-1+b1
ii  libpopt0 1.16-10+b2
ii  libslang22.3.1-5
ii  tcl8.5   8.5.19-2+b1

newt-tcl recommends no packages.

newt-tcl suggests no packages.
diff -Nru newt-0.52.20/debian/changelog newt-0.52.20/debian/changelog
--- newt-0.52.20/debian/changelog   2018-03-07 18:31:56.0 +0300
+++ newt-0.52.20/debian/changelog   2018-03-16 22:21:39.0 +0300
@@ -1,3 +1,11 @@
+newt (0.52.20-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace dependency of newt-tcl from tcl8.3 | tcl8.4 | tcl8.5 to tcl8.6
+since the package is built using Tcl 8.6.
+
+ -- Sergei Golovan   Fri, 16 Mar 2018 22:21:39 +0300
+
 newt (0.52.20-3) unstable; urgency=medium
 
   * Create udeb. Closes: #871033
diff -Nru newt-0.52.20/debian/control newt-0.52.20/debian/control
--- newt-0.52.20/debian/control 2018-03-07 18:31:56.0 +0300
+++ newt-0.52.20/debian/control 2018-03-16 22:21:01.0 +0300
@@ -59,7 +59,7 @@
 Package: newt-tcl
 Architecture: any
 Section: interpreters
-Depends: libnewt0.52 (=${binary:Version}) , tcl8.3 | tcl8.4 | tcl8.5, 
${misc:Depends}, ${shlibs:Depends}
+Depends: libnewt0.52 (=${binary:Version}) , tcl8.6, ${misc:Depends}, 
${shlibs:Depends}
 Description: NEWT module for Tcl
  This module allows you to build a text UI for your Tcl scripts
  using newt.

Bug#893135: ITP: libobject-forkaware-perl -- module to make an object aware of process forks and threads

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libobject-forkaware-perl
  Version : 0.005
  Upstream Author : Karen Etheridge 
* URL : https://metacpan.org/release/Object-ForkAware
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to make an object aware of process forks and threads

Object::ForkAware invisibly wraps your object and makes it fork-aware,
automatically checking $$ on every access and recreating the object if the
process id changes. (The object is also thread-aware; if the thread id
changes, the object is recreated in the same manner.)

The object can be safely used with type checks and various type constraint
mechanisms, as isa() and can() respond as if they were being called against
the contained object itself.

Rationale: If you've ever had an object representing a network connection to
some server, or something else containing a socket, a filehandle, etc, and
used it in a program that forks, and then forgot to close and reopen your
socket/handle etc. in the new process, you'll know what chaos can ensue.
Depending on the type of connection, you can have multiple processes trying
to write to the same resource at once, or simultaneous reads getting each
other's data, dogs and cats living together... It's horrible, and it's an
easy problem to run into.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly with Radeon R9 270X since upgrade from 4.9.0-3 to 4.9.0-4

[besy]

The kernel update "4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3
(2018-03-02) x86_64 GNU/Linux" didn't fix the problem for my Dell U2415
(connected to AMD Radeon R9 270X).

Bug#893131: I know the mount process you have outlined in the manpage

[shirish शिरीष]

Dear Lazlo,

Before you share but I have put -

 ntfs-3g /dev/sda1 /mnt/windows or one of the other examples

I wanted for them to be able to see ntfs partitions without doing that
extra step although do agree it makes it a bit more appealing

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#893133: Could we maintain compatibility with older debhelpers to ease backporting

[Yaroslav Halchenko]

On Fri, 16 Mar 2018, Afif Elghraoui wrote:

> >Thanks for maintaining and updating the package through the latest
> >releases.
> >But I wondered -- since you also had similar (minor but still) pains --
> >could
> >we retain/maintain compatibility with previous versions of debhelper,
> >e.g. 10
> >(or even better 9, which I believe still supported by debhelper in
> >sid).


> Yes, you're right. I'm sorry about that. Go ahead with 9. I think 10 was 
> still causing trouble the way I tried to use it in the 
> jessie-backports-sloppy build.

Awesome! thanks -- I have pushed the "fix" to master (no need to upload
ATM I guess), building backports now for neurodebian.

Thanks again and cheers! ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#890381: Why unattended updates are enabled by default?

[Mikko Rapeli]

Hi,

I have been wondering why my sid laptop is sometimes spinning the fan and
I've seen apt running in the background. I though that was only an
update of the package index and not actual upgrades. Then I've lately had
several odd system lockups on Gnome desktop running on wayland. And
crashes of various applications. Then today I saw that unattended-updates
were running dpkg automatically, which I have not enabled since this
is sid/unstable. I traced this back to apt daily systemd timers.

Why are these updates enabled by default?

To me it does not make sense on sid/unstable to enable automatic updates
by default. Even on stable I would expect that just installing some
packages does not automatically enable installing updates which may
break things on a running system which needs reboots and restart anyway
to make the updates effective.

And yes, I've been on expensive mobile broadband when traveling lately
and am a bit afraid of getting expensive bills in a few weeks...

-Mikko

Bug#893134: openjdk-11-source: inconsistent place for src.zip

[Patrice Duroux]

Package: openjdk-11-source
Version: 11~4-2
Severity: normal

Dear Maintainer,

It seems to be provided there:
/usr/lib/jvm/openjdk-11/lib/src.zip
and so the symlink in /usr/lib/jvm/java-11-openjdk-amd64/
is broken, looking /usr/lib/jvm/openjdk-11/src.zip

Regards,
Patrice

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

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

Versions of packages openjdk-11-source depends on:
ii  openjdk-11-jdk  11~4-2

openjdk-11-source recommends no packages.

openjdk-11-source suggests no packages.

-- no debconf information

Bug#891490: u-boot-sunxi: please integrate install-sunxi64 from atf-allwinner

[Vagrant Cascadian]

On 2018-02-25, Adam Borowski wrote:
> atf-allwinner has finally passed NEW

Thanks for that!


> I'd suggest the following changes to
> u-boot-sunxi:
>
> * move /usr/share/doc/u-boot-sunxi/mksunxi_fit_atf.sh to a proper
>   directory and chmod it +x (it's invoked by my script)

The case could even be made to put this in u-boot-tools.


> * move /usr/sbin/install-sunxi64 to u-boot-sunxi (any changes like the
>   above require tedious coordination, it's better if such logic is not
>   split between packages)
>   + this would add Replaces: atf-allwinner (<= 1.0.apritzel.81-1)

I think it might be worth including it in u-boot-tools and renaming it
u-boot-install-sunxi64, then the Replaces dance would be unnecessary.

It seems to be hard-coded for using pine64 at the moment, but wouldn't
be hard to adapt with support for additional boards.

I didn't find licensing associated with install-sunxi64, though.


> It could be good to add a dependency from u-boot-sunxi:arm64 on
> atf-allwinner as well; almost everyone wants the ATF, and wasting 33KB for
> those with own ATF but stock u-boot is probably better than complexity of
> handling it being missing.

I'm thinking Recommends would be appropriate, yes.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#880014: Technical committee appointment

[Gunnar Wolf]

Chris Lamb dijo [Fri, Mar 16, 2018 at 06:14:37PM +]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear fellow developers,
> 
> As defined by our constitution (§6.2.2), the Debian Technical Committee
> has recommended the appointment of Simon McVittie (smcv).

Yay! Welcome on board!

> I am extremely happy to follow their recommendation and hereby appoint
> Simon as a member of the Technical Committee, effective immediately.>
 
> For reference, the nomination of Simon may be followed at
>  and the Committee now consists of:
> 
>   * Didier Raboud (chairman)
> (...)

I have to pick a nit here - I know this mail probably comes from a template
and you are repeating what used to be true here. But, according to GR
003 in 2016¹, Didier is the "Chair" of the Technical Committee, not
the "Chairman".

¹ https://www.debian.org/vote/2016/vote_003

Thanks!


signature.asc
Description: PGP signature

Bug#887557: www.debian.org: tech-ctte membership updates

[Niko Tyni]

On Wed, Jan 17, 2018 at 11:07:41PM +0200, Niko Tyni wrote:

> Hi, please find attached a patch to update
>  https://www.debian.org/intro/organization 
> for the recent tech-ctte membership changes.
> 
> It also updates the rather outdated list of past members on
>  https://www.debian.org/devel/tech-ctte

Updated patch attached after today's nomination.
-- 
Niko
Index: english/devel/tech-ctte.wml
===
RCS file: /cvs/webwml/webwml/english/devel/tech-ctte.wml,v
retrieving revision 1.71
diff -u -r1.71 tech-ctte.wml
--- english/devel/tech-ctte.wml	29 Jan 2017 03:32:44 -	1.71
+++ english/devel/tech-ctte.wml	16 Mar 2018 18:31:13 -
@@ -316,6 +316,12 @@
 Thanks to the following people who have served on the committee:
 
 
+Keith Packard (2013-11-29 - 2017-12-31)
+Sam Hartman (2015-03-08 - 2017-11-09)
+Don Armstrong (2009-09-11 - 2016-12-31)
+Andreas Barth (2006-01-04 - 2016-12-31)
+Steve Langasek (2006-01-04 - 2015-12-31)
+Bdale Garbee (2001-04-17 - 2015-12-31)
 Colin Watson (2011-08-24 - 2015-03-05)
 Ian Jackson (to 2014-11-19)
 Russ Allbery (2009-01-11 - 2014-11-16)
Index: english/intro/organization.data
===
RCS file: /cvs/webwml/webwml/english/intro/organization.data,v
retrieving revision 1.564
diff -u -r1.564 organization.data
--- english/intro/organization.data	21 Dec 2017 06:52:58 -	1.564
+++ english/intro/organization.data	16 Mar 2018 18:31:13 -
@@ -65,15 +65,15 @@
 
   Leader> 
 
-  Technical Committee> 
+  Technical Committee>   
 Didier Raboud
 Philip Hands
-Sam Hartman
 Tollef Fog Heen
-Keith Packard
 Margarita Manterola
 David Bremner
 Niko Tyni
+Gunnar Wolf
+Simon McVittie
   Secretary>  
 Kurt Roeckx
 

Bug#893133: Could we maintain compatibility with older debhelpers to ease backporting

[Yaroslav Halchenko]

Package: singularity-container
Version: 2.4.2-4
Severity: wishlist

Dear Afif

Thanks for maintaining and updating the package through the latest releases.
But I wondered -- since you also had similar (minor but still) pains -- could
we retain/maintain compatibility with previous versions of debhelper, e.g. 10
(or even better 9, which I believe still supported by debhelper in sid).

I am asking because we try to autobuild backports of singularity for all still
supported debian and ubuntu releases in neurodebian:
http://neuro.debian.net/pkgs/singularity-container.html and that is why I
am typically trying to maintain compatibility to avoid need to patch etc, which
becomes painful and thus inefficient.

I see that motivation to jump to 11 from 9 was:

$> git log debian/compat
commit 01fd7b1b0ab23b03b424e567342dec180b45e2d7
Author: Afif Elghraoui 
Date:   Sat Feb 17 15:55:58 2018 -0500

debhelper compat 11

Since 10, it's no longer necessary to manually pass `--with-autoreconf`
or explicitly depend on the autoreconf debhelper plugin.
The package build is also parallel by default. We'll have to force
serial build if that becomes a problem.

which I would think is just to make better use of available features of recent
debhelper, and not really due to "demand/necessity".  Would you mind if I
revert it, and thus simplify backporting for both of us? ;)

Thanks in advance for the consideration

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages singularity-container depends on:
ii  libc6   2.27-1
ii  python  2.7.14-4
ii  squashfs-tools  1:4.3-5

Versions of packages singularity-container recommends:
ii  e2fsprogs  1.43.9-2

singularity-container suggests no packages.

-- no debconf information

Bug#893131: ntfs-3g should have gvfs and gvfs-fuse either in recommends or in suggests

[shirish शिरीष]

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

Dear Laszlo,

Thank you for maintaining and updating ntfs-3g. To help out in some scenarios
with students, made the systems dual-boot. The scenario is an MS-Windows 10
partitions and ext4 parititons as can be envisisioned as below -

$ sudo fdisk -l
Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: x-xx-xx

Device  StartEndSectors   Size Type
/dev/sda1204810239991021952   499M Windows recovery environment
/dev/sda2 10240001228799 204800   100M EFI System
/dev/sda3 12288001261567  3276816M Microsoft reserved
/dev/sda4 1261568 3718037503 3716775936   1.7T Microsoft basic data
/dev/sda5  3718037504 3843037183  124999680  59.6G Linux swap
/dev/sda6  3843037184 38449909751953792   954M Linux filesystem
/dev/sda7  3844990976 5212178431 1367187456 651.9G Linux filesystem
/dev/sda8  5212178432 7814035455 2601857024   1.2T Linux filesystem

While I'm not sure of the MS-Windows build on the students systems, it
definitely was one of the recentish redstone builds.

https://www.computerworld.com/article/3118132/microsoft-windows/windows-10-redstone-a-guide-to-the-builds.html

I had received complaints that even after installing ntfs-3g it didn't
lead them to
being able to view/use MS-Windows partitions.

I checked it out myself and for sure all I got was “No object for
D-Bus interface”
in caja. I am/was running mate and saw the same thing in caja.

A little bit of searching led me to
https://askubuntu.com/questions/627621/no-object-for-d-bus-interface-when-mounting-with-nautilus

I saw that for some reason gvfs-fuse was not installed. Looking at ntfs-3g saw
that there is nothing in depends and no recommends or even suggests to
tell that
you need the virtual file system in order to see, write, copy etc. on the ntfs
partitions by a user.

FWIW, I had rebooted after installing ntfs-3g and still got no partitions
and another after which I installed gvfs . For safety purposes, I also killed
and relaunched the daemon before rebooting as shared in

https://askubuntu.com/questions/627621/no-object-for-d-bus-interface-when-mounting-with-nautilus/993314#993314

And lo-behold was able to play with the ntfs partitions as before.

If need be, I can do some experiments on it if you need some more info. or want
me to try some other ways.

Doing bit of experimentation on led me to this -

/dev/sda4 on /media/shirish/xx type fuseblk
(ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

Let me know if I can be of any help.

And btw could you whenever you push the next update, could you give a
better link to tuxera as in
https://www.tuxera.com/community/open-source-ntfs-3g/

or rather 
https://www.tuxera.com/community/open-source-ntfs-3g/#tab-1414502534642-3-2

specifically in the manpage as it still shows the old vagueish link.

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

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

Versions of packages ntfs-3g depends on:
ii  fuse   2.9.7-1
ii  libc6  2.27-2
ii  libgcrypt201.8.1-4
ii  libgnutls303.5.18-1
ii  libgpg-error0  1.27-6
ii  libntfs-3g88   1:2017.3.23-2

ntfs-3g recommends no packages.

ntfs-3g suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#893132: libvorbisidec: CVE-2018-5147: out-of-bounds memory write

[Salvatore Bonaccorso]

Source: libvorbisidec
Version: 1.0.2+svn18153-0.2
Severity: grave
Tags: patch security upstream

Hi,

the following vulnerability was published for libvorbisidec.

CVE-2018-5147[0]:
out-of-bounds memory write

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-5147
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5147
[1] https://www.mozilla.org/en-US/security/advisories/mfsa2018-08/

Regards,
Salvatore

Bug#893130: libvorbis: CVE-2018-5146: out-of-bounds memory write

[Salvatore Bonaccorso]

Source: libvorbis
Version: 1.3.4-2
Severity: grave
Tags: patch security upstream
Control: fixed -1 1.3.4-2+deb8u1
Control: fixed -1 1.3.5-4+deb9u2

Hi,

the following vulnerability was published for libvorbis.

CVE-2018-5146[0]:
out-of-bounds memory write

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-5146
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146
[1] https://www.mozilla.org/en-US/security/advisories/mfsa2018-08/
[2] 
https://git.xiph.org/?p=vorbis.git;a=commit;h=667ceb4aab60c1f74060143bb24e5f427b3cce5f

Regards,
Salvatore

Bug#880014: Technical committee appointment

[Chris Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear fellow developers,

As defined by our constitution (§6.2.2), the Debian Technical Committee
has recommended the appointment of Simon McVittie (smcv).

I am extremely happy to follow their recommendation and hereby appoint
Simon as a member of the Technical Committee, effective immediately.

For reference, the nomination of Simon may be followed at
 and the Committee now consists of:

  * Didier Raboud (chairman)
  * Philip Hands 
  * Tollef Fog Heen 
  * Margarita Manterola 
  * David Bremner 
  * Niko Tyni
  * Gunnar Wolf
  * Simon McVittie


Task Description
- 

The Technical Committee is established by the Debian Constitution,
section 6. It is the body which makes the final decision on technical
disputes in the Debian project.

More info about the Technical Committee, including recent decisions,
discussion and advice, may be found here:

  https://www.debian.org/devel/tech-ctte


Regards,

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAlqsCXcACgkQHpU+J9Qx
HlgkTw/+NzHFbwBh0aXFANJCvXfShsv1NJMWhKsL4wjuwyWqjMzUNmotkaEzjPIy
ehvqklegJ22wDFdG9b9bW0b+o7ar97N3cGmIQW4Re/tSFRG91EUP8zKOHXfpZwIF
dm21jhNKK4hpqe5qGiSzoqyNqpBYkqSamQv/sJD5WHtuSAO62GhtBQPKkogkm0MF
VbOoLS3E4XV/5B33PYxB8eKf/39uqB8/HEd46ITMS1pTpcvE3c3+/QXTWPPMYD4G
GuM9kWLhK5Gvdbhc4mQAK01Pa5WPr/LlTJLrtw9ZjloYTdKDeJEM2t28qifPhq1X
0rKRhq8vI86ICFll/IldBw7gBEuBJSb5uwpRuhnuRSzsVw52A0X5ayEa4EM/nE+9
bRDquQhwJw1u4FyINebkJso79wqxHPOynrYtSeNLtIs0PtNvZfwvG7ZtJcEB9ggq
F0U/pkl1KnjEkDXrikMKh4vAJtUAaDraeTYiGW88eeStoq30spzx15obg7hxyiAG
rJ6LhKdkrXxj2nXUfI9I4XBGkQCXuu2hwXTLFOPEnnmylXqPV7DxAzdtQOMfVkCz
03G887R6xps4eCmGhVt1/sQMyOzfcL2CKYlFh8I1hZ3/KEvtmUfa9ViH/6hSKaDK
thEbAOaSYMnExhGAwFAagYoe8KfvQqZNJ+xgaTDqfhX9W/2XSfw=
=RtmF
-END PGP SIGNATURE-

Bug#893128: cortado FTBFS with openjdk-9

[Adrian Bunk]

Source: cortado
Version: 0.6.0-3
Severity: serious
Tags: buster sid

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

...
compile-jheora:
[javac] /build/1st/cortado-0.6.0/build.xml:337: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Using javac -source 1.3 is no longer supported, switching to 1.6
[javac] Using javac -target 1.1 is no longer supported, switching to 1.6
[javac] Compiling 26 source files to 
/build/1st/cortado-0.6.0/output/build/stripped
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:52: 
error: unmappable character (0xC3) for encoding US-ASCII
[javac] /* A 2 ?? 3 array containing the number of quant ranges for a
[javac]^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:52: 
error: unmappable character (0x97) for encoding US-ASCII
[javac] /* A 2 ?? 3 array containing the number of quant ranges for a
[javac] ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:56: 
error: unmappable character (0xC3) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 63 array of the sizes of each quant range for a
[javac]^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:56: 
error: unmappable character (0x97) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 63 array of the sizes of each quant range for a
[javac] ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:56: 
error: unmappable character (0xC3) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 63 array of the sizes of each quant range for a
[javac] ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:56: 
error: unmappable character (0x97) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 63 array of the sizes of each quant range for a
[javac]  ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:61: 
error: unmappable character (0xC3) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 64 array of the bmi ???s used for each quant
[javac]^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:61: 
error: unmappable character (0x97) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 64 array of the bmi ???s used for each quant
[javac] ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:61: 
error: unmappable character (0xC3) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 64 array of the bmi ???s used for each quant
[javac] ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:61: 
error: unmappable character (0x97) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 64 array of the bmi ???s used for each quant
[javac]  ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:61: 
error: unmappable character (0xE2) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 64 array of the bmi ???s used for each quant
[javac]^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:61: 
error: unmappable character (0x80) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 64 array of the bmi ???s used for each quant
[javac] ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:61: 
error: unmappable character (0x99) for encoding US-ASCII
[javac] /* A 2 ?? 3 ?? 64 array of the bmi ???s used for each quant
[javac]  ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:283: 
error: unmappable character (0xE2) for encoding US-ASCII
[javac]   (2 ??? (QIEND ??? qi ) ??? BMS[bmi ][ci ]
[javac]  ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:283: 
error: unmappable character (0x88) for encoding US-ASCII
[javac]   (2 ??? (QIEND ??? qi ) ??? BMS[bmi ][ci ]
[javac]   ^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:283: 
error: unmappable character (0x97) for encoding US-ASCII
[javac]   (2 ??? (QIEND ??? qi ) ??? BMS[bmi ][ci ]
[javac]^
[javac] /build/1st/cortado-0.6.0/src/com/fluendo/jheora/Quant.java:283: 
error: unmappable character (0xE2) for encoding US-ASCII
[javac]  

Bug#893129: dita-ot FTBFS with openjdk-9

[Adrian Bunk]

Source: dita-ot
Version: 1.5.3-2
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dita-ot.html

...
compile:
 [copy] Copying 216 files to /build/1st/dita-ot-1.5.3/output2/build
[javac] /build/1st/dita-ot-1.5.3/buildPackage.xml:75: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Using javac -source 1.5 is no longer supported, switching to 1.6
[javac] Using javac -target 1.5 is no longer supported, switching to 1.6
[javac] Compiling 133 source files to /build/1st/dita-ot-1.5.3/output2
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0xE2) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac]   ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0x80) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac]^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0x99) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac] ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0xE2) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac]   ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0x80) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac]^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0x99) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac] ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0xE2) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac] ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0x80) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac]  ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0x99) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac]   ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0xE2) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac] ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0x80) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac]  ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:332:
 error: unmappable character (0x99) for encoding US-ASCII
[javac]  * token ::= ( alphanum | ???_??? | ???-??? )+
[javac]   ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:343:
 error: unmappable character (0xE2) for encoding US-ASCII
[javac]  * qualifier ::= ( alphanum | ???_??? | '-' )+
[javac]   ^
[javac] 
/build/1st/dita-ot-1.5.3/output2/build/org/dita/dost/platform/Integrator.java:343:
 error: unmappable character (0x80) for encoding US-ASCII
[javac]  * qualifier ::= ( alphanum | ???_??? | '-' )+
[javac]^
[javac] 

Bug#844688: Firefox - compile with jack audio output support

[Javier Ortega Conde (Malkavian)]

I have got it compiled an packaged with jack support using the script and
works fine

https://github.com/rowanthorpe/build-jack-fox


--
Bye: Javier Ortega Conde (Malkavian)

MetaUniversidad: E-learning services - http://metauniversidad.com

Bug#813442: cannot reproduce

[Jeffrey Cliff]

cannot reproduce

Bug#880991: chapel-1.16/1.16.0-1 [ITP]

[Ben Albrecht]

Control: tags -1 moreinfo

Hello,

>> I am looking for a sponsor for the package "chapel-1.16".  This is the
>> compiler for Chapel, the productive parallel programming language.
>>
>>  * Package name: chapel-1.16
>>Version : 1.16.0-1
>
>Hi!
>I'm afraid the package fails to build in a clean chroot, it apparently tries
>to create ~/.chpl and dies if it can't do so.  A package build is not
>allowed to do so -- but you can give it another $HOME.  Log attached.
>
>I did not even start the review proper.

Adam,

Thanks for taking a look. Sorry about the pbuilder error.
We have made some changes to address this error:

https://github.com/chapel-lang/chapel-packaging/pull/15
https://github.com/chapel-lang/chapel-packaging/pull/16

At this point, pbuilder is working for us. The package should now be updated on
both GitHub and Debian mentors. Could you have another look?

https://mentors.debian.net/package/chapel-1.16

https://github.com/chapel-lang/chapel-packaging/tree/master/debian

> Control: tags -1 moreinfo
>
> I can confirm the FTBFS in a pbuilder environment.
>
> Please fix and remove the "moreinfo" tag one you're ready for the
> next round of review.

Tobias,

I have attempted to remove the moreinfo tag. I am not well-acquainted with the
Debian Bug Tracking System, so let me know if this did not work.

Best,
Ben

Bug#893127: ITP: ruby-minitest-focus -- provides ability to focus on a few tests easily

[Balasankar C]

Package: wnpp
Owner: Balasankar C 
Severity: wishlist

* Package name: ruby-minitest-focus
  Version : 1.1.2
  Upstream Author : Ryan Davis
* URL : https://github.com/seattlerb/minitest-focus
* License : Expat
  Programming Lang: Ruby
  Description : provides ability to focus on a few tests easily



signature.asc
Description: OpenPGP digital signature

Bug#890783: Autopkgtest for prodigal (#890783)

[Andreas Tille]

On Fri, Mar 16, 2018 at 05:48:35PM +0100, Andreas Tille wrote:
> 
> >  Please, have a look at this commit
> > 
> > .
> 
> I'll check soon.

The test itself seems technically OK.  Once we have the proper copyright
for it I'd upload.
  
> > I included a genome sequence from NCBI as test data. Should I indicate the
> > source of this data somewhere in the package (e.g., in Readme.tests)?
> 
> I think the best place would be debian/copyright since a data file
> should come with a license.  I would say something like
> 
> 
> Files: debian/tests/test-data
> Copyright: - Copyright-Owner
> License:
> Comment:
>   This file was obtained by
> wget URL

Please let us know here on the list if you spot any problem to fill
in the details.
 
Kind regards

   Andreas. 

-- 
http://fam-tille.de

Bug#853189: tracker.debian.org: Encoding issue / Code injection through Maintainer field (and probably others)

[Christophe Siraut]

Control: retitle -1 tracker.debian.org: Encoding issue / Code injection through 
Maintainer field (and probably others)


Hi Pierre-Elliott,

Thanks for looking into this. If you have a plan in mind please go
for it. I wont be able to give much attention before a week or two.

Christophe

Bug#811766: scim-unikey: FTBFS with GCC 6: narrowing conversion

[James Cowgill]

Control: tags -1 pending

Hi,

On Tue, 19 Jan 2016 17:55:39 -0800 Martin Michlmayr  wrote:
> Package: scim-unikey
> Version: 0.3.1+debian-3.1
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6 gcc-6-narrowing
> 
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.

I've uploaded the attached NMU to DELAYED/2 which fixes this bug by
applying the upstream patch already mentioned in this bug report. I have
also taken the opportunity to add the mandatory build-{arch,indep}
targets to debian/rules. Please tell me if I should cancel it / delay it
longer.

Thanks,
James
diff -Nru scim-unikey-0.3.1+debian/debian/changelog 
scim-unikey-0.3.1+debian/debian/changelog
--- scim-unikey-0.3.1+debian/debian/changelog   2012-07-12 16:51:22.0 
+0100
+++ scim-unikey-0.3.1+debian/debian/changelog   2018-03-16 17:26:15.0 
+
@@ -1,3 +1,13 @@
+scim-unikey (0.3.1+debian-3.2) unstable; urgency=medium
+
+  * debian/patches:
+- Add upstream patch to fix FTBFS with GCC 6 due to narrowing conversions.
+  (Closes: #811766)
+  * debian/rules:
+- Add mandatory build-{arch,indep} targets.
+
+ -- James Cowgill   Fri, 16 Mar 2018 17:26:15 +
+
 scim-unikey (0.3.1+debian-3.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru scim-unikey-0.3.1+debian/debian/patches/gcc6.patch 
scim-unikey-0.3.1+debian/debian/patches/gcc6.patch
--- scim-unikey-0.3.1+debian/debian/patches/gcc6.patch  1970-01-01 
01:00:00.0 +0100
+++ scim-unikey-0.3.1+debian/debian/patches/gcc6.patch  2018-03-16 
17:02:48.0 +
@@ -0,0 +1,269 @@
+Description: Fix FTBFS with GCC 6 caused by narrowing conversions
+Author: marguerite 
+Origin: upstream, 
https://github.com/scim-im/scim-unikey/commit/dcc2ef6057a72d5babc49c51c1a5f998c9a31131
+Bug-Debian: https://bugs.debian.org/811766
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+--- a/ukengine/data.cpp
 b/ukengine/data.cpp
+@@ -96,145 +96,145 @@ See TCVN3 & VPS below for examples
+ unsigned char SingleByteTables[][TOTAL_VNCHARS] = 
+ 
+ // TCVN3
+-{{'A','a','¸','¸','µ','µ','¶','¶','·','·','¹','¹',  // 0: a
+-  '¢','©','Ê','Ê','Ç','Ç','È','È','É','É','Ë','Ë',// 1: a^
+-  '¡','¨','¾','¾','»','»','¼','¼','½','½','Æ','Æ',// 2: a(
+-  'B','b','C','c','D','d',
+-  '§','®',
+-  'E','e','Ð','Ð','Ì','Ì','Î','Î','Ï','Ï','Ñ','Ñ',// 3: e
+-  '£','ª','Õ','Õ','Ò','Ò','Ó','Ó','Ô','Ô','Ö','Ö',  // 4: e^
+-  'F','f','G','g','H','h',
+-  'I','i','Ý','Ý','×','×','Ø','Ø','Ü','Ü','Þ','Þ',// 5: i
+-  'J','j','K','k','L','l','M','m','N','n',
+-  'O','o','ã','ã','ß','ß','á','á','â','â','ä','ä',// 6: o
+-  '¤','«','è','è','å','å','æ','æ','ç','ç','é','é',// 7: o^
+-  '¥','¬','í','í','ê','ê','ë','ë','ì','ì','î','î',// 8: o+
+-  'P','p','Q','q','R','r','S','s','T','t',
+-  'U','u','ó','ó','ï','ï','ñ','ñ','ò','ò','ô','ô',// 9: u
+-  '¦','­','ø','ø','õ','õ','ö','ö','÷','÷','ù','ù',//10: u+ 
+-  'V','v','W','w','X','x',
+-  'Y','y','ý','ý','ú','ú','û','û','ü','ü','þ','þ',//11: y
+-  'Z','z',
++{{static_cast('A'),static_cast('a'),static_cast('¸'),static_cast('¸'),static_cast('µ'),static_cast('µ'),static_cast('¶'),static_cast('¶'),static_cast('·'),static_cast('·'),static_cast('¹'),static_cast('¹'), 
 // 0: a
++  static_cast('¢'),static_cast('©'),static_cast('Ê'),static_cast('Ê'),static_cast('Ç'),static_cast('Ç'),static_cast('È'),static_cast('È'),static_cast('É'),static_cast('É'),static_cast('Ë'),static_cast('Ë'), 
   // 1: a^
++  static_cast('¡'),static_cast('¨'),static_cast('¾'),static_cast('¾'),static_cast('»'),static_cast('»'),static_cast('¼'),static_cast('¼'),static_cast('½'),static_cast('½'),static_cast('Æ'),static_cast('Æ'), 
   // 2: a(
++  static_cast('B'),static_cast('b'),static_cast('C'),static_cast('c'),static_cast('D'),static_cast('d'),
++  static_cast('§'),static_cast('®'),
++  static_cast('E'),static_cast('e'),static_cast('Ð'),static_cast('Ð'),static_cast('Ì'),static_cast('Ì'),static_cast('Î'),static_cast('Î'),static_cast('Ï'),static_cast('Ï'),static_cast('Ñ'),static_cast('Ñ'), 
   // 3: e
++  static_cast('£'),static_cast('ª'),static_cast('Õ'),static_cast('Õ'),static_cast('Ò'),static_cast('Ò'),static_cast('Ó'),static_cast('Ó'),static_cast('Ô'),static_cast('Ô'),static_cast('Ö'),static_cast('Ö'), 
 // 4: e^
++  static_cast('F'),static_cast('f'),static_cast('G'),static_cast('g'),static_cast('H'),static_cast('h'),
++  static_cast('I'),static_cast('i'),static_cast('Ý'),static_cast('Ý'),static_cast('×'),static_cast('×'),static_cast('Ø'),static_cast('Ø'),static_cast('Ü'),static_cast('Ü'),static_cast('Þ'),static_cast('Þ'), 
   // 5: i
++  

Bug#890905: jabref: does not launch

[gregor herrmann]

Control: retitle -1 jabref: fails to build and start with openjdk-9
Control: severity -1 serious
Control: tag -1 + patch

On Fri, 23 Feb 2018 14:38:04 +0100, gregor herrmann wrote:

> Good. Now we at least know that the current jabref doesn't run with
> openjdk9. Let's see if we earlier find the deeper problem or get a
> newer jabref into debian :)

Now that default-jdk and default-jre point to openjdk-9, the problem
of the wrong default java runtime becomes more pressing, but jabref
also doesn't build anymore.

While the build failure looks like a gradle(-debian-helper) problem
...

dh build --buildsystem=gradle
   dh_update_autotools_config -O--buildsystem=gradle
   dh_autoreconf -O--buildsystem=gradle
   dh_auto_configure -O--buildsystem=gradle
   dh_auto_build -O--buildsystem=gradle
mkdir -p .gradle/init.d
cp /usr/share/gradle-debian-helper/init.gradle .gradle/init.d/
gradle --info --console plain --offline --stacktrace --no-daemon 
--refresh-dependencies --gradle-user-home .gradle -Duser.home=. 
-Duser.name=debian -Ddebian.package=jabref -Dfile.encoding=UTF-8 --parallel 
--max-workers=4 jar
Initialized native services in: /build/jabref-3.8.2+ds/.gradle/native

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine java version from '9.0.1'.

* Try:
Run with --debug option to get more log output.

* Exception is:
java.lang.IllegalArgumentException: Could not determine java version from 
'9.0.1'.
at org.gradle.api.JavaVersion.toVersion(JavaVersion.java:70)
at org.gradle.api.JavaVersion.current(JavaVersion.java:80)
at 
org.gradle.internal.jvm.UnsupportedJavaRuntimeException.assertUsingVersion(UnsupportedJavaRuntimeException.java:29)
at 
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:32)
at 
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at 
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at 
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at 
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:210)
at 
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:174)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
at 
org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)

dh_auto_build: gradle --info --console plain --offline --stacktrace --no-daemon 
--refresh-dependencies --gradle-user-home .gradle -Duser.home=. 
-Duser.name=debian -Ddebian.package=jabref -Dfile.encoding=UTF-8 --parallel 
--max-workers=4 jar returned exit code 1
make: *** [debian/rules:6: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


... we know from upstream that the build would fail later anyway.


I guess forcing openjdk-8 at buildtime and runtime would be ok for
now? I've come up with the following patch, which seems to work. Any
comments?


#v+
diff --git a/debian/control b/debian/control
index 2d5b97e05..2b2890755 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends-Indep: ant,
  antlr,
  antlr3,
  antlr4,
- default-jdk (>= 2:1.8),
+ openjdk-8-jdk,
  junit4,
  libandroid-json-java,
  libantlr3-runtime-java,
@@ -45,7 +45,7 @@ Homepage: https://www.jabref.org/
 Package: jabref
 Architecture: all
 Depends: ${misc:Depends},
- default-jre (>= 2:1.8) | java8-runtime,
+ openjdk-8-jre,
  java-wrappers,
  libandroid-json-java,
  libantlr3-runtime-java,
diff --git a/debian/jabref-wrapper b/debian/jabref-wrapper
index adbe78582..f13ec262d 100755
--- a/debian/jabref-wrapper
+++ b/debian/jabref-wrapper
@@ -4,7 +4,8 @@
 . /usr/lib/java-wrappers/java-wrappers.sh

 # We need a java8 runtime
-find_java_runtime java8
+# as this is also provided by openjdk9, we hardcode openjdk8 here
+find_java_runtime openjdk8

 find_jars \
jabref \
diff --git a/debian/rules b/debian/rules
index d1809cdef..f71523da5 100755
--- a/debian/rules
+++