Bug#859157: multipath-tools: after bootup multipathd timeout on commands - requires daemon restart

[Ritesh Raj Sarraf]

On Thu, 2018-05-31 at 15:29 +0200, Chris Hofstaedtler wrote:
> > For Debian, this could be a good candidate for a Stable update,
> > later after the
> > Stretch release. We should continue to keep this bug open until
> > that is done.
> 
> Did you find time to possibly upload this to stable?
> Can I offer any help with this?

No. I haven't done anything on this bug at all. Please feel free to
prepare/test the patch. I'll include it as is.

FYI, I moved the multipath-tools packaging to salsa. You can also join
the team here.
https://salsa.debian.org/linux-blocks-team

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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

Bug#901185: [Debconf-devel] Bug#901185: me too

[Colin Watson]

On Mon, Jun 11, 2018 at 08:52:11PM +0200, Andreas Metzler wrote:
> On 2018-06-11 Colin Watson  wrote:
> > On Sun, Jun 10, 2018 at 04:04:13PM +0200, Andreas Metzler wrote:
> > > yes, resetting IFS to its default value in confmodule helps.
> 
> > Thanks.  For completeness, could you try this variant patch?  If shells
> > are going to be unreliable about setting IFS in this way, then I'd
> > rather just separate out the assignments altogether.
> [snip]
> 
> Yes, this variant of the patch also works.
> 
> Thanks to your handholding we now have a minimal reproducer for the
> issue:

Thanks.  Now that you have a reproducer that doesn't involve debconf and
so I won't be interfering with debugging, I've uploaded debconf 1.5.67
with that confmodule patch.  I know it's a bash5 bug and will hopefully
be fixed, but we might as well be conservative in debconf when it's easy
to do so.

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

Bug#900449: kpartx -d fails with no error when disk path is using more than 63 characters

[Ritesh Raj Sarraf]

Hello Julien,

Thank you for the bug report.

You've tagged it upstream. Does the issue occur with the latest version
(0.7.4) too ?

Thanks,
Ritesh

On Wed, 2018-05-30 at 15:22 -0700, Julien Langlois wrote:
> Package: kpartx
> Version: 0.6.4-5
> Severity: normal
> Tags: upstream
> 
> Hi,
> 
> The problem happens when using the disk path instead of the loop
> device (/dev/loopXX) to delete partition mappings.
> 
> == Reproduction steps  ==
> 
> Consider the following script:
> 
> DIR1=/tmp/test1/123456789/abcdefghi/123456789/abcdefghi/123456789  #
> 60 characters long
> mkdir -p $DIR1
> dd if=/dev/zero of=$DIR1/$FILE1 bs=1 count=0 seek=10M
> parted --script $DIR1/$FILE1 mklabel msdos
> kpartx -sav $DIR1/$FILE1
> kpartx -v -d $DIR1/$FILE1
> 
> When exceuted with FILE=t1 (63 characters long file path), there is
> no problem, the partition mappings is added (creating a /dev/loop)
> and then deleted (releasing the /dev/loop).
> 
> But, when exceuted with FILE=t12 (64 characters long file path), the
> partition mappings is properly added and but not deleted: 
>   * losetup -a still shows the resource
>   * kpartx does not print the same message as usual in verbose mode
> (del devmap : loop0p2) but stop with return code 0
> 
> 
> == Workaround ==
> 
> Use the /dev/loop path instead of the drive path to delete the
> mapping
>   kpartx -d -v /dev/loop0
>   losetup -d /dev/loop0
> 
> 
> I also reproduced this bug on Ubuntu 14.04 using kpartx version
> 0.4.9-3ubuntu7.
> 
>   Julien
> 
> 
> -- System Information:
> Debian Release: 9.4
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8),
> LANGUAGE=en_CA.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages kpartx depends on:
> ii  dmsetup 2:1.02.137-2
> ii  libc6   2.24-11+deb9u3
> ii  libdevmapper1.02.1  2:1.02.137-2
> ii  udev232-25+deb9u2
> 
> kpartx recommends no packages.
> 
> kpartx suggests no packages.
> 
> -- no debconf information
> 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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

Bug#886065:

[Willem van den Akker]

Hi,

Please remove Gyrus from unstable.

The package is abadoned upstream so there will be
never any new versions.

/Willem

Bug#901187: Please drop explicit dependency against systemd

[Ritesh Raj Sarraf]

Hello Laurent,

On Sun, 2018-06-10 at 00:52 +0200, Laurent Bigonville wrote:
> iio-sensor-proxy has an explicit dependency against systemd, but that
> seems to be useless.
> 
> systemd package doesn't garantee that you have systemd running as
> PID1.

How about systemd-sysv ? I believe, from the description of it, that it
should be the effective system init daemon.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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

Bug#901367: maildrop FTCBFS: cannot detect locking method

[Helmut Grohne]

Source: maildrop
Version: 2.9.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

maildrop fails to cross build from source, because ./configure gives up
trying to decide on a locking method. For all native builds on release
and ports architectures, the locking method is fcntl, so I think it
would make sense to just make that choice explicit. After doing so,
maildrop cross builds successfully. Please consider applying the
attached patch.

This patch bears a certain similarity to #884630. Please also look into
whether maybe there is an embedded code copy at work and register[1] it
if necessary.

Helmut

[1] https://wiki.debian.org/EmbeddedCodeCopies
diff --minimal -Nru maildrop-2.9.3/debian/changelog 
maildrop-2.9.3/debian/changelog
--- maildrop-2.9.3/debian/changelog 2017-12-23 17:43:23.0 +0100
+++ maildrop-2.9.3/debian/changelog 2018-06-12 06:28:56.0 +0200
@@ -1,3 +1,10 @@
+maildrop (2.9.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Explicitly choose locking method. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 12 Jun 2018 06:28:56 +0200
+
 maildrop (2.9.3-1) unstable; urgency=medium
 
   * New upstream releases. (2.8.5, 2.9.0, 2.9.1, 2.9.2, 2.9.3)
diff --minimal -Nru maildrop-2.9.3/debian/rules maildrop-2.9.3/debian/rules
--- maildrop-2.9.3/debian/rules 2016-03-17 11:28:08.0 +0100
+++ maildrop-2.9.3/debian/rules 2018-06-12 06:28:54.0 +0200
@@ -28,7 +28,8 @@
--enable-sendmail=/usr/sbin/sendmail \
--enable-maildirquota \
--enable-authlib-tempreject=0 \
-   --with-db=gdbm
+   --with-db=gdbm \
+   --with-locking-method=fcntl
 
 override_dh_install:
dh_install

Bug#901366: activemq fails to start

[Chris Donoghue]

Package: activemq
Version: 5.15.4-1
Severity: important

Dear Maintainer,

ActiveMQ failed to start. A quick search on the latest release page and I found

https://issues.apache.org/jira/browse/AMQ-6930

Meaning that ACTIVEMQ_OUT variable is now requred when using bin/activemq start

Currently every start of activemq results in

$ systemctl status activemq
● activemq.service - LSB: ActiveMQ instance
   Loaded: loaded (/etc/init.d/activemq; generated)
   Active: active (exited) since Tue 2018-06-12 14:21:44 AEST; 1s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 25865 ExecStop=/etc/init.d/activemq stop (code=exited,
status=0/SUCCESS)
  Process: 27015 ExecStart=/etc/init.d/activemq start (code=exited,
status=0/SUCCESS)

Jun 12 14:21:39 homerl systemd[1]: Starting LSB: ActiveMQ instance...
Jun 12 14:21:44 homerl activemq[27015]: Starting ActiveMQ instance :
activemq main (failed?).
Jun 12 14:21:44 homerl systemd[1]: Started LSB: ActiveMQ instance.




Apending into /usr/share/activemq/activemq-options file the following:

ACTIVEMQ_OUT="/dev/null"

activemq now starts without issue.

Bug#901364: frotz: Frotz home Git server changed to Gitlab

[David Griffith]

Package: frotz
Version: 2.44-0.1+b1
Severity: normal

I have changed the upstream location for Frotz.
It now lives at https://gitlab.com/DavidGriffith/frotz


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

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

Versions of packages frotz depends on:
ii  libc62.24-11+deb9u3
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libtinfo56.0+20161126-1+deb9u2

frotz recommends no packages.

frotz suggests no packages.

Bug#901365: inform6-library: Inform6 Library has been updated to 6.12.2

[David Griffith]

Package: inform6-library
Version: 6.12~dfsg.1
Severity: normal

I updated the Inform6 Standard Library to version 6.12.2.  This release 
focuses almost entirely on bug fixes.  A minor backport from Inform7's 
PArser.i6t has been added.

Bugs fixed
--

* Removed last vestiges of modules.

* Fixed problem with invalid wordnum in Refers and NextWord.

* Moved some responses to verbs into the language file.

* Added notes about language-customized code for banner, version, and error
  messages.

* Fixed tenses problems in CTheyreorThats().

* Fixed problem with ImplicitOpen() calling after routines on wrong object.

* Backported Glulx 16-bit verb numbers from I7's Parser.i6t

* Patched up infix.h with 16-bit Glulx verbnums, even though Glulx
  doesn't support Infix.  Maybe someday Glulx will support it.

Bug#901363: ntp: time drifting badly with recent kernels

[Arthur Marsh]

Package: ntp
Version: 1:4.2.8p11+dfsg-1
Followup-For: Bug #901363

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

Attaching syslog since most recent restart.

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


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

Kernel: Linux 4.17.0+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ntp depends on:
ii  adduser3.117
ii  libc6  2.27-3
ii  libcap21:2.25-1.2
ii  libedit2   3.1-20180525-1
ii  libopts25  1:5.18.12-4
ii  libssl1.1  1.1.0h-4
ii  lsb-base   9.20170808
ii  netbase5.4
ii  tzdata 2018e-1

Versions of packages ntp recommends:
ii  perl  5.26.2-6
ii  sntp  1:4.2.8p11+dfsg-1

Versions of packages ntp suggests:
pn  ntp-doc  

-- Configuration Files:
/etc/init.d/ntp changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
. /lib/lsb/init-functions
DAEMON=/usr/sbin/ntpd
PIDFILE=/var/run/ntpd.pid
test -x $DAEMON || exit 5
if [ -r /etc/default/ntp ]; then
. /etc/default/ntp
fi
if [ -e /run/ntp.conf.dhcp ]; then
NTPD_OPTS="$NTPD_OPTS -c /run/ntp.conf.dhcp"
fi
LOCKFILE=/run/lock/ntpdate
RUNASUSER=ntp
UGID=$(getent passwd $RUNASUSER | cut -f 3,4 -d:) || true
if test "$(uname -s)" = "Linux"; then
NTPD_OPTS="$NTPD_OPTS -u $UGID"
fi
case $1 in
start)
log_daemon_msg "Starting NTP server" "ntpd"
if [ -z "$UGID" ]; then
log_failure_msg "user \"$RUNASUSER\" does not exist"
exit 1
fi
ntpdate 192.231.203.132
(
flock -w 180 9
start-stop-daemon --start --quiet --oknodo --pidfile 
$PIDFILE --startas $DAEMON -- -p $PIDFILE $NTPD_OPTS
) 9>$LOCKFILE
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping NTP server" "ntpd"
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE 
--retry=TERM/30/KILL/5 --exec $DAEMON
log_end_msg $?
rm -f $PIDFILE
;;
restart|force-reload)
$0 stop && sleep 2 && $0 start
;;
try-restart)
if $0 status >/dev/null; then
$0 restart
else
exit 0
fi
;;
reload)
exit 3
;;
status)
status_of_proc $DAEMON "NTP server"
;;
*)
echo "Usage: $0 
{start|stop|restart|try-restart|force-reload|status}"
exit 2
;;
esac


-- no debconf information
Jun 12 12:36:42 localhost kernel: [0.024000] Mountpoint-cache hash table 
entries: 16384 (order: 5, 131072 bytes)
Jun 12 12:36:47 localhost ntpdate[1509]: step time server 220.233.156.30 offset 
2.485796 sec
Jun 12 12:37:10 localhost ntpd[3016]: ntpd 4.2.8p11@1.3728-o (1): Starting
Jun 12 12:37:10 localhost ntpd[3016]: Command line: /usr/sbin/ntpd -p 
/var/run/ntpd.pid -g -u 108:112
Jun 12 12:37:10 localhost ntpd[3059]: proto: precision = 0.086 usec (-23)
Jun 12 12:37:10 localhost ntpd[3059]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Jun 12 12:37:10 localhost ntpd[3059]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2018-12-28T00:00:00Z 
last=2017-01-01T00:00:00Z ofs=37
Jun 12 12:37:10 localhost ntpd[3059]: Listen and drop on 0 v6wildcard [::]:123
Jun 12 12:37:10 localhost ntpd[3059]: Listen and drop on 1 v4wildcard 
0.0.0.0:123
Jun 12 12:37:10 localhost ntpd[3059]: set_wildcard_reuse: 
setsockopt(SO_REUSEADDR, on) failed: Structure needs cleaning
Jun 12 12:37:10 localhost ntpd[3059]: bind(18) AF_INET 127.0.0.1#123 flags 0x5 
failed: Address already in use
Jun 12 12:37:10 localhost ntpd[3059]: unable to create socket on lo (2) for 
127.0.0.1#123
Jun 12 12:37:10 localhost ntpd[3059]: failed to init interface for address 
127.0.0.1
Jun 12 12:37:10 localhost ntpd[3059]: set_wildcard_reuse: 
setsockopt(SO_REUSEADDR, on) failed: Structure needs cleaning
Jun 12 12:37:10 localhost ntpd[3059]: bind(18) AF_INET 192.168.1.101#123 flags 
0x19 failed: Address already in use
Jun 12 12:37:10 localhost ntpd[3059]: unable to create socket on eth0 (3) for 
192.168.1.101#123
Jun 12 12:37:10 localhost ntpd[3059]: failed to init interface for address 
192.168.1.101
Jun 12 12:37:10 localhost ntpd[3059]: set_wildcard_reuse: 
setsockopt(SO_REUSEADDR, on) 

Bug#901284: RFS: deepin-movie-reborn/3.2.7-2

[Yanhao Mo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "deepin-movie-reborn"

* Package name: deepin-movie-reborn
  Version : 3.2.7-2
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://github.com/linuxdeepin/deepin-movie-reborn
* License : GPL-3+
  Section : video

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

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

  https://mentors.debian.net/package/deepin-movie-reborn

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/deepin-movie-reborn/deepin-movie-reborn_3.2.7-2.dsc

More information about hello can be obtained from 
https://salsa.debian.org/pkg-deepin-team/deepin-movie-reborn

Changes since the last upload:

deepin-movie-reborn (3.2.7-2) unstable; urgency=medium

  * Reconfirm symbol information using buildd logs.

-- 
Yanhao Mo


signature.asc
Description: PGP signature

Bug#901363: ntp: time drifting badly with recent kernels

[Arthur Marsh]

Package: ntp
Version: 1:4.2.8p11+dfsg-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Noticing that time had drifted when running new kernels:

12 Jun 12:07:53 
ntpdate[5469]: step time server 192.231.203.132 offset 142.937367 sec

12 Jun 12:20:18 
ntpdate[6483]: step time server 192.231.203.132 offset 1.474986 sec

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

As shown above, drifted close to 1.5 seconds in less than 15 minutes.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.17.0+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ntp depends on:
ii  adduser3.117
ii  libc6  2.27-3
ii  libcap21:2.25-1.2
ii  libedit2   3.1-20180525-1
ii  libopts25  1:5.18.12-4
ii  libssl1.1  1.1.0h-4
ii  lsb-base   9.20170808
ii  netbase5.4
ii  tzdata 2018e-1

Versions of packages ntp recommends:
ii  perl  5.26.2-6
ii  sntp  1:4.2.8p11+dfsg-1

Versions of packages ntp suggests:
pn  ntp-doc  

-- Configuration Files:
/etc/init.d/ntp changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
. /lib/lsb/init-functions
DAEMON=/usr/sbin/ntpd
PIDFILE=/var/run/ntpd.pid
test -x $DAEMON || exit 5
if [ -r /etc/default/ntp ]; then
. /etc/default/ntp
fi
if [ -e /run/ntp.conf.dhcp ]; then
NTPD_OPTS="$NTPD_OPTS -c /run/ntp.conf.dhcp"
fi
LOCKFILE=/run/lock/ntpdate
RUNASUSER=ntp
UGID=$(getent passwd $RUNASUSER | cut -f 3,4 -d:) || true
if test "$(uname -s)" = "Linux"; then
NTPD_OPTS="$NTPD_OPTS -u $UGID"
fi
case $1 in
start)
log_daemon_msg "Starting NTP server" "ntpd"
if [ -z "$UGID" ]; then
log_failure_msg "user \"$RUNASUSER\" does not exist"
exit 1
fi
ntpdate 192.231.203.132
(
flock -w 180 9
start-stop-daemon --start --quiet --oknodo --pidfile 
$PIDFILE --startas $DAEMON -- -p $PIDFILE $NTPD_OPTS
) 9>$LOCKFILE
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping NTP server" "ntpd"
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE 
--retry=TERM/30/KILL/5 --exec $DAEMON
log_end_msg $?
rm -f $PIDFILE
;;
restart|force-reload)
$0 stop && sleep 2 && $0 start
;;
try-restart)
if $0 status >/dev/null; then
$0 restart
else
exit 0
fi
;;
reload)
exit 3
;;
status)
status_of_proc $DAEMON "NTP server"
;;
*)
echo "Usage: $0 
{start|stop|restart|try-restart|force-reload|status}"
exit 2
;;
esac


-- no debconf information

Bug#819488: libparted2: parted crash with a libparted backtrace

[Antos Andras]

Package: libparted2
Version: 3.2-17
Followup-For: Bug #819488

I also confirm this bug still exists. Here is the output of

# fdisk -l -u /dev/sda
Disk /dev/sda: 465,8 GiB, 500107862016 bytes, 976773168 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: dos
Disk identifier: 0x1baf0215

Device BootStart   End   Sectors   Size Id Type
/dev/sda1   2048  10567679  10565632 5G 83 Linux
/dev/sda3  *10567680  31930287  21362608  10,2G 83 Linux
/dev/sda4   31930366 976771071 944840706 450,5G  5 Extended
/dev/sda5  *31932416  48338943  16406528   7,8G 83 Linux
/dev/sda6   48338944  52535295   4196352 2G 82 Linux swap / Solaris
/dev/sda7   52537344 976771071 924233728 440,7G 83 Linux

Partition 4 does not start on physical sector boundary.

Indeed, there is no unallocated sector between my logical partitions 
sda5 and sda6.

 If I recall correctly, I have used only fdisk, cfdisk and/or Debian/Ubuntu
installers (using parted itself?) to manipulate the partition table.
I have not used any Windows tool.

Here upstream maintainers discuss if it is actually a bug:
https://lists.gnu.org/archive/html/bug-parted/2015-09/msg00021.html
I also consider it an important bug. (Any program aborting and suggesting 
to report a bug instead of executing a basic functionality, by definiton, 
has a bug.) Parted should instead handle the partition table and give a 
warning about the non-standard EBR arrangement. Or if it cannot be made 
robust enough to handle such partition table (though, this does not look 
impossible), it should at least give a proper error message about that, 
rather than abort with a failure.


Btw, there are now quite a lot reports about this:
https://google.com/search?q=Assertion+add_logical_part_metadata+failed ,
some of which blaming parted of fdisk for the "non-standard" EBR arrangement,
e.g.:
https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1543704/comments/13
https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1543704/comments/14

Is there any advance with the fix? Is there plans for a new upstream release?

FYI, here is the output of
# parted /dev/sda print
and
# parted /dev/sda unit co print unit s print
Backtrace has 14 calls on stack:
  14: /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x45) [0x7fd2a2274fc5]
  13: /lib/x86_64-linux-gnu/libparted.so.2(+0x23b3f) [0x7fd2a228bb3f]
  12: /lib/x86_64-linux-gnu/libparted.so.2(+0x119fa) [0x7fd2a22799fa]
  11: /lib/x86_64-linux-gnu/libparted.so.2(ped_disk_add_partition+0x283) 
[0x7fd2a227a313]
  10: /lib/x86_64-linux-gnu/libparted.so.2(+0x233ec) [0x7fd2a228b3ec]
  9: /lib/x86_64-linux-gnu/libparted.so.2(+0x23480) [0x7fd2a228b480]
  8: /lib/x86_64-linux-gnu/libparted.so.2(+0x23426) [0x7fd2a228b426]
  7: /lib/x86_64-linux-gnu/libparted.so.2(+0x24455) [0x7fd2a228c455]
  6: /lib/x86_64-linux-gnu/libparted.so.2(ped_disk_new+0x48) [0x7fd2a2279f18]
  5: parted(+0x73fe) [0x55a4b69f33fe]
  4: parted(non_interactive_mode+0x92) [0x55a4b69f91c2]
  3: parted(main+0x12bf) [0x55a4b69f207f]
  2: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fd2a1a722e1]
  1: parted(_start+0x2a) [0x55a4b69f224a]


You found a bug in GNU Parted! Here's what you have to do:

Don't panic! The bug has most likely not affected any of your data.
Help us to fix this bug by doing the following:

Check whether the bug has already been fixed by checking
the last version of GNU Parted that you can find at:

http://ftp.gnu.org/gnu/parted/

Please check this version prior to bug reporting.

If this has not been fixed yet or if you don't know how to check,
please visit the GNU Parted website:

http://www.gnu.org/software/parted

for further information.

Your report should contain the version of this release (3.2)
along with the error message below, the output of

parted DEVICE unit co print unit s print

and the following history of commands you entered.
Also include any additional information about your setup you
consider important.

Assertion (metadata_length > 0) at ../../../libparted/labels/dos.c:2313 in
function add_logical_part_metadata() failed.

Aborted 
---
And here is the first 4 sectors of my extended partition (with EBRs?) 
omitting the 0-only lines:


# dd if=/dev/sda skip=31930366 count=4 2>/dev/null|xxd |grep -v "    
   "

01b0:        80b2  
01c0: f0c3 83f4 f4c0 0208  0058 fa00 0092  ...X
01d0: d0c3 052b 25c6 0200  0068 3a01   ...+%..h:...

01f0:        55aa  ..U.

05b0:        00fe  
05c0:  82fe  0060 fa00 0008 4000 002b  ...`@..+
05d0: 26c6 052f 6e81 0268 3a01 00b8 1637   &../n..h:7..

05f0:        55aa  

Bug#891636: latexmk: NMU for new upstream

[Norbert Preining]

Dear Ohura-san

I have now uploaded latexmk 4.56 to DELAYED/7 queue.
You can see that packaging and changes at
  https://salsa.debian.org/tex-team/latexmk

Sincerely yours

Norbert

On Mon, 11 Jun 2018, Paride Legovini wrote:
> Just a friendly ping: do you have any news on this? Will you proceed
> with the NMU?

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#891042: ETA?

[Soren Stoutner]

Does anyone have any sense of when a newer firmware package will be uploaded?  
There is a lot of newer hardware that would be very happy.  ;)

-- 
Soren Stoutner
Small Business Tech Solutions
623-262-6169
so...@smallbusinesstech.net

Bug#901362: RFS: jag/0.3.5-2 -- arcade and puzzle 2D game

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: jag
   Version : 0.3.5-2
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/jag
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  jag   - arcade and puzzle 2D game
  jag-data  - arcade and puzzle 2D game (data file)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/j/jag/jag_0.3.5-2.dsc

  More information about JAG can be obtained from 
https://gitlab.com/coringao/jag/wikis.

  Changes since the last upload:

  * debian/control:
+ Declare compliance with Debian Policy: 4.1.4
+ Changed homepage URL to GitLab
  * debian/copyright:
+ Update source URL move to GitLab
  * Updated d/upstream/metadata URLs move to GitLab
  * Updated d/watch file upstream move to GitLab

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#900718: rsyslog: FTBFS on hurd-i386

[Samuel Thibault]

Michael Biebl, le jeu. 07 juin 2018 13:40:45 +0200, a ecrit:
> Am 07.06.2018 um 13:37 schrieb Samuel Thibault:
> > Michael Biebl, le jeu. 07 juin 2018 13:34:48 +0200, a ecrit:
> >> Anyway, such patches should best be sent upstream.
> > 
> > We don't have the manpower to chase all upstream bugtrackers and
> > whatnot.
> 
> Same is true for me. I don't have the man power to keep maintaining
> distro specific patches which belong upstream or playing bug proxy.

So, does anybody on debian-hurd have time for upstreaming?

Samuel

Bug#901361: RM: wvstreams -- unmaintained, dead upstream, depends on libssl1.0.2

[Sebastian Andrzej Siewior]

Package: ftp.debian.org

wvstreams is rc-buggy due to its libssl1.0.2 requirement, QA maintained.
I asked about its status on d-qa-packages@l.d.o [0] and later on
d-devel@l.d.o [1].

wvstreams is dead upstream, last github commit is from 2011.
Its only reverse dependency is wvdial (Debian maintainer on Cc:).

wvdial is dead upstream (homepage not reachable), last upload in 2012.
Its only reverse dependency is gnome-ppp.

gnome-ppp is dead upstream, not part of the gnome project (explained in
[2]). Last upload moved the package to QA in 2017 and the upload before
that was in 2012. Alexey Loginov asked to replace it with a fork in
#813804 and he has been added Cc.

It looks to me that gnome-ppp could be removed without hesitation.
People interested in wvdial should also show interest in wvstreams,
too.

Alternatives as suggested in [2]:
|Alternatives to wvdial include pppconfig (orphaned) or configuring
|pppd by writing configuration files directly (hardly user-friendly,
|but probably enough for retrocomputing enthusiasts).

and [3] added:
|If someone is really enthusiastic, they might want to write a
|plugin for MM supporting their favourite ZyXEL or whatever.
|Shouldn't be hard and would automatically integrate into the
|wonderful world of NM. Needs C and glib knowledge.

Based on popcon the reason for wvstreams is wvdial.
With that background I am asking for the removal of wvstreams and its
reverse dependencies. I could also clone this bug as an O: bug against
each package and if nobody adopts the package (especially wvstreams)
within one Month I would reassign it back here.

[0] 
https://lists.debian.org/msgid-search/20180531220103.p56ajmkirte3p...@breakpoint.cc
[1] 
https://lists.debian.org/msgid-search/20180605194636.igsc6xuhpbm2b...@breakpoint.cc
[2] 
https://lists.debian.org/msgid-search/20180605221528.ga32...@espresso.pseudorandom.co.uk
[3] https://lists.debian.org/msgid-search/20180605222635.GA29088@fama

Sebastian

Bug#893912: firmware-realtek: Failed to load rtl_bt/rtl8821a_config.bin

[Altug Yildirim]

Hello,

This is also what I am dealing with right now. My computer fails to load
three files; rtlwifi/rtl8821aefw_wowlan.bin
rtl_bt/rtl8821a_config.bin
rtl_bt/rtl8821a_fw.bin

Even though, rtl_bt/rtl8821a_fw.bin can be located in
/lib/firmware/rtl_bt/ and rtlwifi/rtl8821aefw_wowlan.bin can be located
in /lib/firmware/rtlwifi/ . For the completeness "dmesg | grep firmware"
gives me this;
[   11.605280] rtl8821ae: Using firmware rtlwifi/rtl8821aefw.bin
[   11.605290] rtl8821ae: Using firmware rtlwifi/rtl8821aefw_wowlan.bin
[   11.630704] rtl8821ae :02:00.0: firmware: failed to load
rtlwifi/rtl8821aefw_wowlan.bin (-2)
[   11.630712] rtl8821ae :02:00.0: Direct firmware load for
rtlwifi/rtl8821aefw_wowlan.bin failed with error -2
[   11.642658] rtl8821ae :02:00.0: firmware: direct-loading firmware
rtlwifi/rtl8821aefw.bin
[   12.685508] bluetooth hci0: firmware: failed to load
rtl_bt/rtl8821a_config.bin (-2)
[   12.685511] bluetooth hci0: Direct firmware load for
rtl_bt/rtl8821a_config.bin failed with error -2
[   12.685526] bluetooth hci0: firmware: failed to load
rtl_bt/rtl8821a_fw.bin (-2)
[   12.685527] bluetooth hci0: Direct firmware load for
rtl_bt/rtl8821a_fw.bin failed with error -2
[   23.375275] r8169 :03:00.0: firmware: direct-loading firmware
rtl_nic/rtl8106e-1.fw

Best,
Altug


On Wed, 09 May 2018 12:51:31 +0200 Francisco M Neto 
wrote:
> This happens on my machine as well.
>
> I'm running buster with 4.16 kernel and firmware-realtek is installed.
> It seems that this file should be in the package but it hasn't been
> include for some reason, even though it is available from https://githu
> b.com/lwfinger/rtl8723au_bt/.
>
> Installing the file on /lib/firmware/rtl_bt/ solves the issue.
>
>
> On Fri, 23 Mar 2018 19:02:48 +0100 "Rathorian" 
> wrote:
> > Package: firmware-realtek
> > Version: 20161130-3
> > Severity: important
> >
> > Dear Maintainer,
> >
> > Every time I start Debian, I get an error message saying:
> > "bluetooth hci0: firmware: failed to load rtl_bt/rtl8821a_config.bin"
> >
> > I have also tried to install the package since stretch-backports,
> without
> > any success.
> >
> > Cordially
> > Rathorian
> >
> > -- System Information:
> > Debian Release: 9.4
> > APT prefers stable-updates
> > APT policy: (500, 'stable-updates'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8),
> > LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > firmware-realtek depends on no packages.
> >
> > firmware-realtek recommends no packages.
> >
> > Versions of packages firmware-realtek suggests:
> > ii initramfs-tools 0.130
> >
> > -- no debconf information
> >
> --
> --
> []s,
>
> Francisco M Neto
>
>

Bug#901358: ups-monitor script needs to honor PWRFAILDIR

[Elliott Mitchell]

tags 901358 patch
quit

Need to attach the patch...


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445


--- ups-monitor.dpkg-new	2016-07-16 08:19:48.0 -0700
+++ ups-monitor	2017-10-25 12:05:43.462235341 -0700
@@ -20,7 +20,10 @@
 
 case "$1" in
 	poweroff | killpower)
-		if [ -f /etc/apcupsd/powerfail ]; then
+		faildir="$(grep -e^PWRFAILDIR /etc/apcupsd/apcupsd.conf)"
+		faildir="${faildir#PWRFAILDIR }"
+
+		if [ -f "${faildir:=/etc/apcupsd}/powerfail" ]; then
 			echo ""
 			echo -n "apcupsd: Ordering UPS to kill power... "
 			/etc/apcupsd/apccontrol killpower

Bug#901360: sbuild-createchroot manpage: bad path in example description

[Jakub Wilk]

Package: sbuild
Version: 0.76.0-1
Severity: minor
Tags: patch

--
Jakub Wilk
From b0223635b82c7a34ee02ed77a80dec05e708d8f3 Mon Sep 17 00:00:00 2001
From: Jakub Wilk 
Date: Mon, 11 Jun 2018 22:51:55 +0200
Subject: [PATCH] man/sbuild-createchroot.8.in: fix path in example description

The path in the example was updated in 6b644bb83e58, but it remained
intact in the description above.
---
 man/sbuild-createchroot.8.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/sbuild-createchroot.8.in b/man/sbuild-createchroot.8.in
index dbc31c79..89eb9e03 100644
--- a/man/sbuild-createchroot.8.in
+++ b/man/sbuild-createchroot.8.in
@@ -236,13 +236,13 @@ Generates a compressed tarball using lzip.
 Generates a compressed tarball using xz.
 .PP
 If no extension is specified, sbuild\-createchroot will rename \fIfile\fP to
 \fIfile.tar.gz\fP and generate \fIfile.tar.gz\fP as a compressed tarball using gzip.
 .SH EXAMPLES
 To create a bootstrapped file type sid (unstable) chroot ready for use with
-sbuild and saved in \fI/var/cache/sbuild/sbuild.tar.gz\fP using the
+sbuild and saved in \fI/srv/chroot/unstable-amd64.tar.gz\fP using the
 \fIhttpredir.debian.org\fP Debian http mirror redirector service and using a
 temporary directory as the target:
 .PP
 \f[CR]% \f[CB]sudo sbuild\-createchroot \fP\fP\\
 .br
 \-\-make\-sbuild\-tarball=/srv/chroot/unstable-amd64.tar.gz \fP\fP\\
-- 
2.17.1

Bug#901359: RFS: pokemmo-installer/1.4.6-2 -- Installer and Launcher for the PokeMMO emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "pokemmo-installer"

 * Package name: pokemmo-installer
   Version : 1.4.6-2
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/pokemmo-installer
 * License : GPL-3+
   Section : contrib/games

  It builds those binary packages:

  pokemmo-installer - Installer and Launcher for the PokeMMO emulator

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

  https://mentors.debian.net/package/pokemmo-installer

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

  dget -x 
https://mentors.debian.net/debian/pool/contrib/p/pokemmo-installer/pokemmo-installer_1.4.6-2.dsc

  More information about PokeMMO Installer can be obtained from 
https://gitlab.com/coringao/pokemmo-installer/wikis.

  Changes since the last upload:

  * Updated d/watch file upstream move to GitLab
  * Updated d/upstream/metadata URLs move to GitLab
  * debian/control:
+ Changed homepage URL to GitLab
+ Declare compliance with Debian Policy: 4.1.4
  * debian/copyright:
+ Update source URL after move to GitLab
- Removed Debian Games Team in files: debian/*

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#901358: ups-monitor script needs to honor PWRFAILDIR

[Elliott Mitchell]

Package: apcupsd
Version: 3.14.14-0.3

If the value PWRFAILDIR is modified in /etc/apcupsd/apcupsd.conf, the
/etc/apcupsd/ups-monitor script WILL fail.  The attached patch should
solve this.

PWRFAILDIR should likely default to "/run" or "/run/apcupsd" as those
are STRONGLY prefered for runtime state.  This allows `apcupsd` to
function on a system with read-only root.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#901357: xsane: Failed to start scanner: Invalid argument, but scanimage works and xsane works as root

[Julian Gilbey]

Package: xsane
Version: 0.999-5
Severity: normal

Hello!

Last night, I scanned an image using xsane with my USB-connected
printer without difficulty.  This morning, I upgraded some packages
with aptitude, and now I can't do so.  Here's what I changed:

** Aptitude log:

Aptitude 0.8.10: log report
Mon, Jun 11 2018 18:07:26 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 57 packages, and remove 1 packages.
613 kB of disk space will be used

[REMOVE, NOT USED] libmaa3:amd64 1.3.2-3+b2
[INSTALL, DEPENDENCIES] libmaa4:amd64 1.4.2-1
[UPGRADE] cups:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] cups-bsd:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] cups-client:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] cups-common:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] cups-core-drivers:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] cups-daemon:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] cups-ipp-utils:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] cups-ppdc:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] cups-server-common:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] default-jdk:amd64 2:1.10-66 -> 2:1.10-67
[UPGRADE] default-jdk-headless:amd64 2:1.10-66 -> 2:1.10-67
[UPGRADE] default-jre:amd64 2:1.10-66 -> 2:1.10-67
[UPGRADE] default-jre-headless:amd64 2:1.10-66 -> 2:1.10-67
[UPGRADE] dict:amd64 1.12.1+dfsg-4 -> 1.12.1+dfsg-4+b1
[UPGRADE] dictd:amd64 1.12.1+dfsg-4 -> 1.12.1+dfsg-4+b1
[UPGRADE] dictzip:amd64 1.12.1+dfsg-4 -> 1.12.1+dfsg-4+b1
[UPGRADE] docbook-to-man:amd64 1:2.0.0-41 -> 1:2.0.0-42
[UPGRADE] encfs:amd64 1.9.2-2+b1 -> 1.9.5-1
[UPGRADE] fonts-urw-base35:amd64 20170801-2 -> 20170801.1-2
[UPGRADE] foomatic-db-compressed-ppds:amd64 20180306-1 -> 20180604-1
[UPGRADE] gap-grape:amd64 4r7+ds-3 -> 4r8+ds-1
[UPGRADE] java-common:amd64 0.66 -> 0.67
[UPGRADE] libcups2:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] libcups2:i386 2.2.7-5 -> 2.2.8-2
[UPGRADE] libcupscgi1:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] libcupsimage2:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] libcupsmime1:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] libcupsppdc1:amd64 2.2.7-5 -> 2.2.8-2
[UPGRADE] libdate-manip-perl:amd64 6.71-1 -> 6.72-1
[UPGRADE] libgif7:amd64 5.1.4-2 -> 5.1.4-3
[UPGRADE] libimage-exiftool-perl:amd64 10.97-1 -> 11.00-1
[UPGRADE] liblouis-bin:amd64 3.5.0-2 -> 3.5.0-3
[UPGRADE] liblouis-data:amd64 3.5.0-2 -> 3.5.0-3
[UPGRADE] liblouis14:amd64 3.5.0-2 -> 3.5.0-3
[UPGRADE] libpstoedit0c2a:amd64 3.72-1 -> 3.73-1
[UPGRADE] libx264-155:amd64 3:0.155.2901+git7d0ff22-dmo2 -> 
3:0.155.2901+git7d0ff22-dmo3
[UPGRADE] libx264-155:i386 3:0.155.2901+git7d0ff22-dmo2 -> 
3:0.155.2901+git7d0ff22-dmo3
[UPGRADE] mencoder:amd64 4:1.3.0~20171022.svn37997-dmo9 -> 
4:1.3.0~20171022.svn37997-dmo10
[UPGRADE] mplayer:amd64 4:1.3.0~20171022.svn37997-dmo9 -> 
4:1.3.0~20171022.svn37997-dmo10
[UPGRADE] mplayer-doc:amd64 4:1.3.0~20171022.svn37997-dmo9 -> 
4:1.3.0~20171022.svn37997-dmo10
[UPGRADE] node-yallist:amd64 2.0.0-1 -> 3.0.2-1
[UPGRADE] psf-unifont:amd64 1:10.0.07-1 -> 1:11.0.01-1
[UPGRADE] pstoedit:amd64 3.72-1 -> 3.73-1
[UPGRADE] python-numpy:amd64 1:1.14.3-2 -> 1:1.14.4-1
[UPGRADE] python-numpy-dbg:amd64 1:1.14.3-2 -> 1:1.14.4-1
[UPGRADE] python-psutil:amd64 5.4.2-1 -> 5.4.6-1
[UPGRADE] python3-numpy:amd64 1:1.14.3-2 -> 1:1.14.4-1
[UPGRADE] python3-numpy-dbg:amd64 1:1.14.3-2 -> 1:1.14.4-1
[UPGRADE] python3-psutil:amd64 5.4.2-1 -> 5.4.6-1
[UPGRADE] python3-redis:amd64 2.10.6-3 -> 2.10.6-4
[UPGRADE] ruby-jekyll-watch:amd64 1.3.0-1 -> 2.0.0-1
[UPGRADE] schroot:amd64 1.6.10-4 -> 1.6.10-5
[UPGRADE] schroot-common:amd64 1.6.10-4 -> 1.6.10-5
[UPGRADE] ttf-unifont:amd64 1:10.0.07-1 -> 1:11.0.01-1
[UPGRADE] unifont:amd64 1:10.0.07-1 -> 1:11.0.01-1
[UPGRADE] xfonts-unifont:amd64 1:10.0.07-1 -> 1:11.0.01-1


Now, I'm assuming that it is most likely to be something in one of the
cups packages which has caused the problem.

When I start xsane, it offers me two scanners, matching those reported
by scanimage -L:

device `brother4:net1;dev0' is a Brother HomePrinter DCP-9020CDW
device `brother4:bus1;dev3' is a Brother DCP-9020CDW USB scanner

These are the same physical device, but I am trying to use the USB
one.  The device is owned by lp:

erdos:~ $ ls -l /dev/bus/usb/002/003 
crw-rw-r--+ 1 root lp 189, 130 Jun 11 22:29 /dev/bus/usb/002/003

I am a member of the lp and scanner groups:
erdos:~ $ groups
jdg lp [...] scanner [...]


I looked on the internet for ideas, and figured that it might be a
permissions issue.  I already have brscan4 and brscan-skey installed:
$ dpkg -l br\*
[...]
ii  brscan-skey0.2.4-1  amd64Brother Linux scanner S-KEY tool
ii  brscan40.4.3-3  amd64Brother Scanner Driver

So I installed the package from Brother brother-udev-rule-type1 which
adds the following:

/etc/udev/rules.d/60-brother-libsane-type1.rules:

#
#   udev rules sample for Brother MFP
# version 1.0.0-1
#
#   Copyright (C) 2012 Brother. Industries, Ltd.
#
#   copy to /etc/udev/rules.d or 

Bug#901146: clementine still has qt4 dependency while linked with qt5

[Rogério Brito]

Hi, all.

On Jun 09 2018, Eric Valette wrote:
> While trying to get rid of qt4 on my computer I found that although using
> qt5, it still has libqt4-sql-sqlite dependency instead of
> libqt5sql5-sqlite

I noticed the same thing. Then, I went to the git repository and saw that
the Qt4 package in question is hardcoded as a dependency of the binary
package. :-(

So, this is trivial to resolve.

If you want, Thomas, I can send you a pull/merge request.

Oh, also, the long description still mentions something along the lines of
"using features of qt4", when comparing clementine to amarok 1.4.


Regards,

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

Bug#901356: r-cran-caret: new version pulls in loads of development packages

[Rogério Brito]

Package: r-cran-caret
Version: 6.0-80-1
Severity: normal

Hi.

Thanks for taking care of packaging R packages.

I noticed that the new version of r-cran-caret depends on libgdal-dev, which
pulls in a lot of development packages and frustrates my plans of creating a
small live CD/DVD/USB of development tools for data analysis.

In fact, looking more closely at the package relationships of r-cran-caret,
I see that it both Depends **and** also Suggests libgdal-dev, so, at least
one of thoses may be a mistake...

Similarly r-cran-testthat is listed both as a Recommends and as a
Suggests... (I may have missed other duplicate packages, if they exist).

Can this be fixed with a new upload?


Thanks,

Rogério Brito.


P.S: Please, ignore the dependencies listed below. They are for an outdated
version of the package.


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

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.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 r-cran-caret depends on:
ii  libc62.27-3
ii  libgcc1  1:8.1.0-5
ii  libstdc++6   8.1.0-5
ii  r-base-core [r-api-3.4]  3.4.4-1+b2
ii  r-cran-foreach   1.4.4-1
ii  r-cran-ggplot2   2.2.1-3
ii  r-cran-lattice   0.20-35-1+b1
ii  r-cran-modelmetrics  1.1.0-1+b1
ii  r-cran-nlme  3.1.137-1
ii  r-cran-plyr  1.8.4-1+b1
ii  r-cran-recipes   0.1.2-1
ii  r-cran-reshape2  1.4.3-1
ii  r-cran-withr 2.1.2-2

r-cran-caret recommends no packages.

Versions of packages r-cran-caret suggests:
ii  r-cran-bradleyterry2  1.0-8-1
ii  r-cran-e1071  1.6-8-2+b1
pn  r-cran-ellipse
pn  r-cran-fastica
ii  r-cran-gam1.15-1
ii  r-cran-ipred  0.9-6-1
ii  r-cran-kernlab0.9-26-1
ii  r-cran-knitr  1.20-2
ii  r-cran-mass   7.3-50-1
ii  r-cran-mgcv   1.8-23-1
pn  r-cran-mlbench
ii  r-cran-nnet   7.3-12-2+b1
ii  r-cran-randomforest   4.6-14-1
pn  r-cran-testthat   

-- no debconf information

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

Bug#900410: debian-installer: Please make the generated images reproducible

[Chris Lamb]

Dear Anibal,

> mtools: please make the output reproducible (uninitialised memory)
> mtools: please make the output reproducible (directory timestamps)

I'd dearly love to ensure there are no blockers to making the Debian
Installer images to be reproducible well in advance of the «buster»
release. :)

May I gently prod you to review and hopefully apply these patches?


Best wishes,

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

Bug#901355: stretch-pu: package llvm-4.0/1:4.0.1-10~deb9u1

[Moritz Muehlenhoff]

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

Firefox/Thunderbird ESR60 will require rustc 1.24 (which in turn
requires LLVM 4.0). llvm-4.0 is not yet in stretch, so this would
add a new package to it.

It's a straightforward rebuild. The debdiff against 1:4.0.1-10
from buster is very simple (with an additional build conflicts
I ran into when preparing the build).

Cheers,
Moritz

diff -Nru llvm-toolchain-4.0-4.0.1/debian/changelog 
llvm-toolchain-4.0-4.0.1/debian/changelog
--- llvm-toolchain-4.0-4.0.1/debian/changelog   2018-02-13 09:26:55.0 
+0100
+++ llvm-toolchain-4.0-4.0.1/debian/changelog   2018-05-15 00:07:58.0 
+0200
@@ -1,3 +1,11 @@
+llvm-toolchain-4.0 (1:4.0.1-10~deb9u1) stretch; urgency=medium
+
+  * Build for stretch-security to be used by Firefox ESR60
+  * Add Build-Conflicts: to golang-go (prevents build failure similar
+to #840208)
+
+ -- Moritz Mühlenhoff   Tue, 15 May 2018 00:07:58 +0200
+
 llvm-toolchain-4.0 (1:4.0.1-10) unstable; urgency=medium
 
   * Ignore the test tools/gold/X86/comdat.ll
diff -Nru llvm-toolchain-4.0-4.0.1/debian/control 
llvm-toolchain-4.0-4.0.1/debian/control
--- llvm-toolchain-4.0-4.0.1/debian/control 2018-02-11 10:18:48.0 
+0100
+++ llvm-toolchain-4.0-4.0.1/debian/control 2018-05-15 00:07:58.0 
+0200
@@ -14,7 +14,7 @@
 #ocaml-findlib [amd64 arm64 armel armhf i386],
 #libctypes-ocaml-dev [amd64 arm64 armel armhf i386],
 #dh-ocaml [amd64 arm64 armel armhf i386],
-Build-Conflicts: oprofile, ocaml, libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
+Build-Conflicts: oprofile, ocaml, libllvm-3.8-ocaml-dev, 
libllvm-3.9-ocaml-dev, golang-go
 Standards-Version: 4.1.1
 Homepage: http://www.llvm.org/
 Vcs-Svn: svn://anonscm.debian.org/svn/pkg-llvm/llvm-toolchain/branches/4.0/

Bug#901276: jessie-pu: package lame/3.99.5+repack1-7+deb8u2

[Moritz Mühlenhoff]

On Sun, Jun 10, 2018 at 02:59:49PM -0400, Hugo Lefeuvre wrote:
> 
> lame 3.99.5+repack1-7+deb8u1 is affected by several vulnerabilities in
> the code used to read the input file. These issues are not present in
> any Debian release after Jessie because the package switched to
> libsndfile to read and write audio files. The upstream code itself was
> recently fixed in 3.100.
 
FWIW, patch looks fine.

Cheers,
Moritz

Bug#900593: diffoscope: GNU tar xattrs result in: libarchive: Ignoring malformed pax extended attribute

[Tianon Gravi]

On Mon, 11 Jun 2018 at 01:29, Chris Lamb  wrote:
>
> Chris Lamb wrote:
>
> > Glad I could resolve your use-case. However, I assume there is still a
> > diffoscope bug here?
> >
> > ie. We certainly shouldn't be emitting "Ignoring malformed pax
> > extended attribute" to stderr and — as a possible improvement — we
> > should be emitting that as part of the "proper" output?
>
> Gentle ping on this Tianon? :-)

Apologies!  Yes, IMO there's definitely a diffoscope bug here.  The
_ideal_ case would be that it shows me useful data about the PaX
headers that don't match (so that I can narrow down why my tarballs
aren't reproducible).

For some slight context, I reach for diffoscope when I have two binary
objects that I expect to be the same and aren't because it's really
good at taking all that binary noise and converting it to something I
can make some sense out of with an eventual fallback to something like
"diff <(hexdump) <(hexdump)" if it can't find any useful signal in the
noise (or doesn't have the necessary tools installed).

In the case of these PaX headers, we get this misleading warning a few
times, then the "file(1)" diff output ("-POSIX tar archive" / "+POSIX
tar archive (GNU)") -- not even a note about how diffoscope couldn't
find any more meaningful differences between the two objects, so I
think this is at least a wishlist bug for diffoscope and possibly a
minor/normal issue depending on how important you think tar files
containing capabilities / extended attributes are. :)


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#877752: blocked by #839569

[Robert J. Clay]

This module package depends on the package
libselenium-remote-driver-perl, the ITP for which [1] is still
pending.
Note that because that is not available,  I have also not yet been
able to do a test build of this new module..

-- 
Robert J. Clay
rjc...@gmail.com
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839569

Bug#901354: RFP jackson-modules-base JAVA XML libraries

[Geert Stappers]

Package: wnpp
Severity: wishlist

Package name: jackson-modules-base
Version : 2.9.5
Upstream Author : i...@fasterxml.com / http://fasterxml.com/
URL : https://github.com/FasterXML/jackson-modules-base
License : Apache License 2.0
Programming Lang: Java
Description : Uber-project for foundational modules of Jackson

Jackson Project, formerly known as the standard JSON library for Java

jackson-modules-base provides these modules
* Afterburner
* Guice
* JAXB Annotations
* Mr Bean
* OSGi
* Paranamer

Module  'Mr Bean' is my reason for this Request For Packaging.

Mr Bean is an extension that implements support for "POJO type
materialization"; ability for databinder to construct implementation
classes for Java interfaces and abstract classes, as part of
deserialization.

Which is a dependency for Arduino.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#901352: unblock: ca-certificates/20180409

[Michael Shuler]

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

ca-certificates-udeb is blocked.

Please unblock the package ca-certificates to transition to testing.

We just downgraded the severity of a bug, since openssl was updated to 
fix an issue with the processing of CA certificates[0], in order to 
allow ca-certificates to transition to testing. The bug is intended to 
be closed after testing transition, just to be sure all is well, since 
the fix was really in openssl.


It appears that ca-certificates is now blocked due to udebs being 
frozen[1], as noted a couple days ago on d-d-announce (thank you for 
this note!).


Kind regards,
Michael Shuler

[0] https://bugs.debian.org/895482
[1] https://qa.debian.org/excuses.php?package=ca-certificates

Bug#901185: me too

[Eduardo Bustamante]

On Mon, Jun 11, 2018 at 1:52 PM, Andreas Metzler  wrote:
[..]
> Looking at the Open Group Base Specifications Issue 7 I also think this
> behavior is a bug, since "read" is not a "a special built-in utility or
> function".

FWIW, this is a bug in bash5, and has been reported to upstream
already: https://lists.gnu.org/archive/html/bug-bash/2018-05/msg00077.html

Bug#888373: libextractor: FTBFS with FFmpeg 4.0

[Bertrand Marc]

|forwarded 888373 https://gnunet.org/bugs/view.php?id=5343
thanks

Thanks for the patch. I fowarded it upstream, so that they would make it 
backward compatible.

Best regards,
Bertrand
|

Bug#901353: wmifs segfaults occasionally

[anomie]

Package: wmifs
Version: 1.8-1

I noticed that wmifs was randomly crashing on my laptop. I have no idea
how to reproduce it besides letting it run for a long time, it didn't
seem to be associated with hibernation or anything else obvious. If I
have multiple instances running, usually only one will crash while the
others continue without issue.

Running it under gdb with wmifs-dbgsym installed produced this trace:

  Program received signal SIGSEGV, Segmentation fault.
  _IO_fgets (buf=0x7fffd9d0 "\001", n=512, fp=0x0) at iofgets.c:47
  47iofgets.c: No such file or directory.
  (gdb) bt
  #0  _IO_fgets (buf=0x7fffd9d0 "\001", n=512, fp=0x0) at iofgets.c:47
  #1  0x6d1f in fgets (__stream=0x0, __n=512, __s=0x7fffd9d0 
"\001") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:263
  #2  get_statistics (devname=, ip=0x7fffdc70, 
op=0x7fffdc78, is=0x7fffdc80, os=0x7fffdc88) at wmifs.c:767
  #3  0x73b9 in wmifs_routine (argc=, 
argv=) at wmifs.c:555
  #4  0x5dbe in main (argc=5, argv=0x7fffe198) at wmifs.c:367

Apparently the fopen() on wmifs.c line 766 can fail in some cases, and
that needs to be checked for to avoid passing a NULL file pointer to
fgets(). It could be as simple as inserting

if (!fp) {
return -1;
}

to match the minimal error handling on subsequent lines when an fgets() fails.

Bug#901351: file: CVE-2018-10360

[Salvatore Bonaccorso]

Source: file
Version: 1:5.33-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for file.

CVE-2018-10360[0]:
| The do_core_note function in readelf.c in libmagic.a in file 5.33
| allows remote attackers to cause a denial of service (out-of-bounds
| read and application crash) via a crafted ELF file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10360
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10360
[1] https://github.com/file/file/commit/a642587a9c9e2dd7feacdf513c3643ce26ad3c22

Please adjust the affected versions in the BTS as needed, only
unstable checked at time of filling bug report.

Regards,
Salvatore

Bug#901350: RFP: django-rest-framework-httpsignature -- HTTP Signature support for Django REST framework

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist

* Package name: django-rest-framework-httpsignature
  Version : 1.0.0
* URL : 
https://github.com/etoccalino/django-rest-framework-httpsignature
* License : MIT
  Description : HTTP Signature support for Django REST framework

  The HTTP Signature package provides a way to achieve origin
  authentication and message integrity for HTTP messages. The HTTP
  Signature specification is currently an IETF draft.

It might be useful to maintain this package within the Debian Python
group.

This package depend on python-httpsig
(https://bugs.debian.org/901347 >) currently also missing in
Debian.

There has not been a new upstream release since 2015, so 
I've asked upstream in 
https://github.com/etoccalino/django-rest-framework-httpsignature/issues/21 >
if the package is still being developped.

-- 
Happy hacking,
Petter Reinholdtsen

Bug#885619: jessie-pu: package libextractor/1:1.3-2

[Bertrand Marc]

Le 08/06/2018 à 22:24, Adam D. Barratt a écrit :

Control: tags -1 + moreinfo

On Thu, 2017-12-28 at 17:32 +0100, Bertrand Marc wrote:

Would you allow an update of libextractor 1.3-2 in Jessie to fix
several minor security issues?
7 issues skipped by the security teams:


[...]

   * CVE-2017-15600 : In GNU Libextractor 1.4, there is a NULL Pointer
Dereference in the
 EXTRACTOR_nsf_extract_method function of plugins/nsf_extractor.c.


I assume the same issue that Julien raised for the stretch package
applies here.

Regards,

Adam

Indeed. The attached patch would fix the issue.

Regards,
Bertrand
diff -Nru libextractor-1.3/debian/changelog libextractor-1.3/debian/changelog
--- libextractor-1.3/debian/changelog	2014-09-30 22:56:54.0 +0200
+++ libextractor-1.3/debian/changelog	2017-12-27 19:01:53.0 +0100
@@ -1,3 +1,14 @@
+libextractor (1:1.3-2+deb8u1) jessie; urgency=medium
+
+  * Fix CVE-2017-15266, CVE-2017-15267, CVE-2017-15600, CVE-2017-15601,
+CVE-2017-15602, CVE-2017-15922 and CVE-2017-17440. Leon Zhao discovered
+several security vulnerabilities, NULL Pointer Dereferences, heap-based
+buffer overflows, integer signedness errors and out-of-bounds read that
+may lead to a denial-of-service (application crash) or have other
+unspecified impact.
+
+ -- Bertrand Marc   Wed, 27 Dec 2017 19:01:53 +0100
+
 libextractor (1:1.3-2) unstable; urgency=medium
 
   * Build-depend on libmagic-dev and libavresample-dev to enable additional
diff -Nru libextractor-1.3/debian/patches/CVE-2017-15266.patch libextractor-1.3/debian/patches/CVE-2017-15266.patch
--- libextractor-1.3/debian/patches/CVE-2017-15266.patch	1970-01-01 01:00:00.0 +0100
+++ libextractor-1.3/debian/patches/CVE-2017-15266.patch	2017-12-27 19:01:53.0 +0100
@@ -0,0 +1,17 @@
+From: Bertrand Marc 
+Subject: CVE-2017-15266
+
+Bug-Upstream: http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg2.html
+Bug-Debian: https://bugs.debian.org/878314
+Origin: https://gnunet.org/git/libextractor.git/commit/?id=b577d5452c5c4ee9d552da62a24b95f461551fe2
+--- a/src/plugins/wav_extractor.c
 b/src/plugins/wav_extractor.c
+@@ -109,6 +109,8 @@
+ return;/* invalid sample size found in wav file */
+   if (0 == channels)
+ return;/* invalid channels value -- avoid division by 0! */
++  if (0 == sample_rate)
++return;/* invalid sample_rate */
+   samples = data_len / (channels * (sample_size >> 3));
+ 
+   snprintf (scratch,
diff -Nru libextractor-1.3/debian/patches/CVE-2017-15267.patch libextractor-1.3/debian/patches/CVE-2017-15267.patch
--- libextractor-1.3/debian/patches/CVE-2017-15267.patch	1970-01-01 01:00:00.0 +0100
+++ libextractor-1.3/debian/patches/CVE-2017-15267.patch	2017-12-27 19:01:53.0 +0100
@@ -0,0 +1,22 @@
+From: Markus Koschany 
+Date: Mon, 4 Dec 2017 00:00:15 +0100
+Subject: CVE-2017-15267
+
+Bug-Upstream: http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg3.html
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878314
+Origin: https://gnunet.org/git/libextractor.git/commit/?id=6095d7132b57fc7368fc7a40bab2a71b735724d2
+---
+ src/plugins/flac_extractor.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/src/plugins/flac_extractor.c
 b/src/plugins/flac_extractor.c
+@@ -339,6 +339,8 @@
+ 	  {
+ 	entry = >comments[count];
+ 	eq = (const char*) entry->entry;
++	if (NULL == eq)
++			break;
+ 	len = entry->length;
+ 	ilen = 0;
+ 	while ( ('=' != *eq) && ('\0' != *eq) &&
diff -Nru libextractor-1.3/debian/patches/CVE-2017-15600.patch libextractor-1.3/debian/patches/CVE-2017-15600.patch
--- libextractor-1.3/debian/patches/CVE-2017-15600.patch	1970-01-01 01:00:00.0 +0100
+++ libextractor-1.3/debian/patches/CVE-2017-15600.patch	2017-12-27 19:01:53.0 +0100
@@ -0,0 +1,29 @@
+From: Bertrand Marc , Markus Koschany 
+Subject: CVE-2017-15600
+
+Bug-Upstream: http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg4.html
+Origin: https://gnunet.org/git/libextractor.git/commit/?id=38e8933539ee9d044057b18a971c2eae3c21aba7
+--- a/src/plugins/nsf_extractor.c
 b/src/plugins/nsf_extractor.c
+@@ -152,13 +152,17 @@
+   char nsfversion[32];
+   const struct header *head;
+   void *data;
++  ssize_t ds;
+ 
+-  if (sizeof (struct header) >
+-  ec->read (ec->cls,
+-		,
+-		sizeof (struct header)))
++  ds = ec->read (ec->cls,
++ ,
++ sizeof (struct header));
++  if ( (-1 == ds) ||
++   (sizeof (struct header) > ds) )
+ return;
+   head = data; 
++  if (NULL == head)
++return;
+ 
+   /* Check "magic" id bytes */
+   if (memcmp (head->magicid, "NESM\x1a", 5))
diff -Nru libextractor-1.3/debian/patches/CVE-2017-15601.patch libextractor-1.3/debian/patches/CVE-2017-15601.patch
--- libextractor-1.3/debian/patches/CVE-2017-15601.patch	1970-01-01 

Bug#890791: stretch-pu: package dpkg/1.18.25

[Vagrant Cascadian]

On 2018-05-12, Karsten Merker wrote:
> On Sun, Apr 22, 2018 at 12:39:42AM +0200, Manuel A. Fernandez Montecelo wrote:
>> 2018-04-20 1:52 GMT+02:00 Guillem Jover :
>> > On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote:
>> >> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
>> >> > 2018-02-18 22:26 Guillem Jover:
>> >> > > I'd like to update dpkg in stretch. This includes several fixes for
>> >> > > documentation, regressions, misbheavior, minor security issues, and
>> >> > > a new arch definition so that DAK can accept packages using it. The
>> >> > > fixes have been in sid/buster for a while now.
>> >> >
>> >> > We depend on this version being accepted and installed in the systems
>> >> > where DAK lives to learn about the new architecture.  After that,
>> >> > several other packages can add support for the architecture, without
>> >> > receiving an automatic reject when uploaded.
>> >> >
>> >> > It would be great if this update could enter in the next stable
>> >> > update, so we can make progress on that front.
>> >
>> >> We've been discussing this amongst the SRMs and are quite wary of a
>> >> dpkg update this close to the p-u freeze. We appreciate that the
>> >> changes individually seem self-contained but would like to have an
>> >> update of such a key package able to be tested more than is feasible in
>> >> the time available.
>> >>
>> >> (On a related note, in practical terms it's very unlikely that there
>> >> would be sufficient time to get the new strings that are introduced
>> >> translated.)
>> >
>> > Is there perhaps anything you are waiting for me to do here?
>> >
>> > For the strings I realized afterwards I can take the ones from sid.
>> > I've not yet checked how many, or if I'd really need a call for
>> > translation, but I'd rather do that only after I know which parts you
>> > are going to accept. :) But TBH, this being gettext I'm not sure it
>> > matters that much, as only those strings might end up not being
>> > translated and dpkg does not have 100% coverage for all languages
>> > anyway. :)
> [...]
>> So in the 2+ months since that original request, we went from
>> scattered packages outside the Debian infrastructure to having a port
>> in debian-ports infra, with >60% of packages built.
>> 
>> Unfortunately, important packages like binutils, glibc or linux-* have
>> to stay in the separate "unreleased" suite for that reason, so the
>> lack of support in dak for riscv64 is causing us to do this extra
>> work, which would be otherwise unneeded
>
> To add some further information: having to always manually build
> and upload a number of otherwise perfectly working essential
> riscv64 packages like glibc to unreleased due to the missing
> dpkg/stable update doesn't only cause unnecessary additional work
> for the riscv64 porters but also poses practical problems for
> package maintainers trying to sort out portability issues as they
> cannot simply debootstrap a current riscv64 chroot (and therefore
> easily use pbuilder) because debootstrap cannot handle pulling
> the base system from more than one suite (unstable+unreleased in
> this case).
>
> Previous stretch point releases have been published every 2.5-3
> months, and since the 9.4 release more than two months have
> passed already, so I would again like to ask the stable release
> managers what exactly they require to be done for the proposed
> dpkg update to be accepted into the 9.5 release.  Guillem had
> asked a similar question already three weeks ago (see above), but
> has AFAICS received no reply to it.  I would really like to avoid
> the dpkg/stable update necessary for proper riscv64 support being
> pushed back yet another release cycle because of communication
> issues...

I hear mumblings of preparation for the next stable point release, and
so wondering if there's any chance to get the dpkg patches necessary to
enable riscv64 in dak before that happens?

I had the impression the riscv64 patch of the patch was rather trivial.

The riscv64 port has been hovering around the 80% mark for built
packages, which is pretty exciting to see, and would be nice to keep
that momentum going!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#901349: Kernel 4.16 has no display support for Raven Ridge

[Keverik]

Package: linux-image
Version: 4.16.0-2-amd64 (4.16.12-1)

When upgrading my PC it is found that debian did not support the new AMD 
Raven Ridge series. I have the Ryzen 2200G on a MSI B350 PC MATE board.


I upgraded my debian stable to unstable and then to sed and now have a 
non working system with default settings.


This are the warnings and errors:
[ 9.874] (WW) AMDGPU(0): No outputs definitely connected, trying again...
[ 9.874] (WW) AMDGPU(0): Unable to find connected outputs - setting 
1024x768 initial framebuffer
[ 9.874] (EE) AMDGPU(0): No modes. [ 9.874] (EE) Screen(s) found, but 
none have a usable configuration.


I have reported the bug at freedesktop and they said that it is a debian 
kernel config problem.

( https://bugs.freedesktop.org/show_bug.cgi?id=106871 )

The CONFIG_DRM_AMD_DC_DCN1_0should be enabled. Can this be fixed in the 
kernel?


Thank you all!
Best regards,
Erik

Bug#889852: ca-certificates: piuparts failure causes piuparts failures in (all?) dependent packages

[Michael Shuler]

Control: tags -1 + moreinfo

On 02/07/2018 03:29 PM, Nicholas D Steeves wrote:

https://piuparts.debian.org/stretch2buster-rcmd/fail/ca-certificates_20170717.log

   1m9.6s DEBUG: Modified(user, group, mode, size, target): 
/etc/ca-certificates.conf expected(root, root, - 100644, 6488, None) != 
found(root, root, - 100644, 7694, None)
1m9.7s INFO: Warning: Package purging left files on system:
   /etc/ca-certificates.conf.dpkg-oldnot owned

1m9.7s ERROR: FAIL: After purging files have been modified:
   /etc/ca-certificates.conf not owned


I'm not really sure what piuparts is testing here, nor how to suppress 
this error. debian/ca-certificates.postrm in purge does:


  rm -f /etc/ca-certificates.conf*

This configuration file is nearly guaranteed to be modified, so it 
should be expected to have a different size.


On a fresh VM, installing and purging the package, the config files are 
removed as I would expect. If there is some reasonable way for piuparts 
to ignore a configuration file that is expected to be modified, I'd like 
to know how to add this exclusion to ca-certificate to prevent this 
error, particularly if it's affecting other packages.


--
Kind regards,
Michael

Bug#901337: darkplaces FTCBFS: uses the build architecture toolchain

[Simon McVittie]

On Mon, 11 Jun 2018 at 18:20:31 +0200, Helmut Grohne wrote:
> That mostly works except for the makefile hard coding the build
> architecture pkg-config.

This part is fixed in experimental, by modifying the patches that
introduced the use of pkg-config rather than adding a new one
(loosely based on what you contributed to quakespasm).

> Turns out the upstream makefile uses uname to vary what is being built

Yes. Game developers and their artisanal hand-crafted build systems :'-(

Thanks, I'll apply the rest (or something very similar) in the next
upload.

I know ioquake3 and yquake2 also need similar treatment, and they're in
my queue, so don't prioritize writing patches for those (ioquake3 also
can't currently cross-compile because opusfile isn't multiarch-friendly).

smcv

Bug#893861: thawab: Intent to remove from Debian

[Jeremy Bicha]

On Mon, Jun 11, 2018 at 9:28 AM, أحمد المحمودي (Ahmed El-Mahmoudy)
 wrote:
> On Thu, May 03, 2018 at 07:49:18AM -0400, Jeremy Bicha wrote:
>> If we don't hear back immediately, I will be converting this bug into
>> a Debian removal bug for thawab very soon.
> ---end quoted text---
>
> Sorry for the late reply.
> I have filed a bug upstream about this months ago. Still waiting for the
> reply.

Thank you for replying.

We're still blocked on eclipse. Someone needs to see how bad it breaks
if the webkitgtk support is disabled (probably with a hacky patch).
I'm hoping we can get this done this year.

So until eclipse is handled, there is no urgent need to remove thawab
from Debian, if removing thawab will cause you too much inconvenience.
(It's already been removed from Testing.)

But once eclipse is handled, I expect we will try to remove thawab
promptly if it's still not ported away from the old webkitgtk.

Thanks,
Jeremy Bicha

Bug#901185: remove unlisted bash dependecy

[Andreas Metzler]

On 2018-06-11 積丹尼 Dan Jacobson  wrote:
> Why use bash at all if e.g.,

> $ checkbashisms /usr/sbin/update-exim4.conf.template
> could not find any possible bashisms in bash script 
> /usr/sbin/update-exim4.conf.template

> means one can just use #!/bin/sh ?

Hello,

Exim, does use #!/bin/sh. However bash can provide /bin/sh (Run
"dpkg-reconfigure dash" to enable or disable), and bash5 is afaict
buggy, it is not /bin/sh-compliant. This specific bug severly breaks
scripting. It is not limited to exim, e.g. any debconf using package
has a good chance of breaking. 

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#901348: unalz FTCBFS: uses the build architecture C++ compiler

[Helmut Grohne]

Source: unalz
Version: 0.65-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

unalz fails to cross build from source, because it uses a non-standard
variable (CPP) for the C++ compiler and thus dh_auto_build does not
provide it. After renaming the variable, unalz cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru unalz-0.65/debian/changelog unalz-0.65/debian/changelog
--- unalz-0.65/debian/changelog 2017-12-27 09:38:44.0 +0100
+++ unalz-0.65/debian/changelog 2018-06-11 20:37:59.0 +0200
@@ -1,3 +1,10 @@
+unalz (0.65-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Provide a c++ compiler in $(CPP). (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 20:37:59 +0200
+
 unalz (0.65-6) unstable; urgency=medium
 
   * debian/{control,copyright,watch}: Correct the upstream URL
diff --minimal -Nru unalz-0.65/debian/rules unalz-0.65/debian/rules
--- unalz-0.65/debian/rules 2017-12-27 09:38:44.0 +0100
+++ unalz-0.65/debian/rules 2018-06-11 20:37:59.0 +0200
@@ -16,7 +16,7 @@
dh $@
 
 override_dh_auto_build:
-   dh_auto_build -- linux-utf8 CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
+   dh_auto_build -- linux-utf8 CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" 
'CPP=$$(CXX)'
$(XP) -o debian/unalz.1 $(DB2MAN) debian/unalz.dbk
iconv -f EUC-KR -t UTF-8 < readme.txt > debian/readme.txt
 

Bug#901185: me too

[Andreas Metzler]

On 2018-06-11 Colin Watson  wrote:
> On Sun, Jun 10, 2018 at 04:04:13PM +0200, Andreas Metzler wrote:
[...] 
> > yes, resetting IFS to its default value in confmodule helps.

> Thanks.  For completeness, could you try this variant patch?  If shells
> are going to be unreliable about setting IFS in this way, then I'd
> rather just separate out the assignments altogether.
[snip]

Yes, this variant of the patch also works.

Thanks to your handholding we now have a minimal reproducer for the
issue:

(sid)ametzler@argenau:~$ cat /tmp/reproducer.sh
#!/bin/sh
set -e

list="item1 item2"

ls -l /bin/sh
printf "IFS=[%s]" "$IFS" | od -a

IFS='
' read -r dummy

printf "IFS=[%s]" "$IFS" | od -a
for i in $list ; do
echo $i
done
# Error with bash5:
(sid)ametzler@argenau:~$ echo xxx | /tmp/reproducer.sh
lrwxrwxrwx 1 root root 4 Jun 11 18:41 /bin/sh -> bash
000   I   F   S   =   [  sp  ht  nl   ]
011
000   I   F   S   =   [  nl   ]
007
item1 item2
#normal behavior with bash4 or dash:
(sid)ametzler@argenau:~$ echo xxx | /tmp/reproducer.sh
lrwxrwxrwx 1 root root 4 Jun 11 18:41 /bin/sh -> bash
000   I   F   S   =   [  sp  ht  nl   ]
011
000   I   F   S   =   [  sp  ht  nl   ]
011
item1
item2


> (This does still seem like a bash bug though, unless there's some arcane
> interpretation of the standards that I'm unaware of.)

Looking at the Open Group Base Specifications Issue 7 I also think this
behavior is a bug, since "read" is not a "a special built-in utility or
function".

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#901347: RFP: python-httpsig -- sign HTTP requests according to IETF HTTP Signatures spec

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist

* Package name: python-httpsig
  Version : 1.2.0
* URL : https://github.com/ahknight/httpsig
* License : MIT
  Description : sign HTTP requests according to IETF HTTP Signatures spec

 Sign HTTP requests with secure signatures according to the IETF HTTP
 Signatures specification (`Draft 8`_).

I got a draft debian/ directory to build the package.  It might provide
a starting point.  Attaching a tarball of this.

It might be useful to maintain this package within the Debian Python
group.

I need the package to get django-rest-framework-httpsignature working.

-- 
Happy hacking,
Petter Reinholdtsen


python-httpsig-debian.tar.gz
Description: application/tarz

Bug#901346: RFS: reentry/1.2.1a2-1 -- plugin manager based on setuptools entry points

[Andrius Merkys]

Package: sponsorship-requests
Severity: normal

Hello,

I am looking for a sponsor for my package "reentry".

* Package name: reentry
  Version : 1.2.1a2
  Upstream Author : Rico Haeuselmann
* URL : https://pypi.org/project/reentry/
* License : MIT
  Programming Lang: Python
  Description : plugin manager based on setuptools entry points

It builds these binary packages:
  python-reentry   - plugin manager based on setuptools entry points (Python 2)
  python3-reentry  - plugin manager based on setuptools entry points (Python 3)

The packages are dependencies of AiiDA (http://www.aiida.net) and its plugins.
As AiiDA currently is Python 2-only, python-reentry package is needed.

The packages are not in the Mentors (due to #901025). The packaging is done in
Salsa repository at https://salsa.debian.org/python-team/modules/python-reentry
and can be reviewed there.

Many thanks,
Andrius

Bug#901345: elivs-tiny FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: elvis-tiny
Version: 1.4-24
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

elvis-tiny fails to cross build from source, because it does not pass
cross tools to make. Using dh_auto_build easily fixes that and makes
elvis-tiny cross build successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru elvis-tiny-1.4/debian/changelog 
elvis-tiny-1.4/debian/changelog
--- elvis-tiny-1.4/debian/changelog 2016-11-11 16:20:53.0 +0100
+++ elvis-tiny-1.4/debian/changelog 2018-06-11 20:26:19.0 +0200
@@ -1,3 +1,10 @@
+elvis-tiny (1.4-24.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 20:26:19 +0200
+
 elvis-tiny (1.4-24) unstable; urgency=low
 
   * remove bin/vi wrapper, incompatible with / + /usr merge (closes: 
#540928,#813857)
diff --minimal -Nru elvis-tiny-1.4/debian/rules elvis-tiny-1.4/debian/rules
--- elvis-tiny-1.4/debian/rules 2016-11-11 16:05:43.0 +0100
+++ elvis-tiny-1.4/debian/rules 2018-06-11 20:26:12.0 +0200
@@ -6,10 +6,10 @@
 endif
 
 %:
-   dh $@
+   dh $@ --buildsystem=makefile
 
 override_dh_auto_build:
-   make -f Makefile.mix EXTRA_CFLAGS="$(EXTRA_CFLAGS)"
+   dh_auto_build -- -f Makefile.mix EXTRA_CFLAGS="$(EXTRA_CFLAGS)"
 
 override_dh_auto_install:
install -m 755 -d $(tmp)/bin

Bug#900803: Debian in fongbé

[Marlene ATTOLOU]

hello,

I think that it is a very good idea. This project, will allow the valuation
of the language fongbé and will be known of all.

Bug#894987: libtommath: FBTFS in riscv64: Please increase the time for timeout of "testme.sh"

[Dominique Dumont]

Hi

Sorry for the delay.

I've added a patch to increase the test timeout as you suggested. This cchnage 
is now in Debian repo.

I plan to release this with next libtommath package (ETA unknown).

All the best

Bug#696178: git: "mmap: No such device" on broken .git tree

[Michał Mirosław]

Dear Git Maintainer,

This bug is present in git from testing/backports.

# LANG=C apt policy git
git:
  Installed: 1:2.17.1-1~bpo9+1
  Candidate: 1:2.17.1-1~bpo9+1
  Version table:
 *** 1:2.17.1-1~bpo9+1 500
500 http://ftp.pl.debian.org/debian stretch-backports/main amd64 
Packages
100 /var/lib/dpkg/status
 1:2.11.0-3+deb9u3 500
500 http://security.debian.org stretch/updates/main amd64 Packages
500 http://ftp.pl.debian.org/debian stretch-proposed-updates/main amd64 
Packages
 1:2.11.0-3+deb9u2 500
500 http://ftp.pl.debian.org/debian stretch/main amd64 Packages

A script to reproduce:

-
#!/bin/bash
git init foo
cd foo
touch bar
git add -A
git commit -mtest
for i in .git/objects/*/*; do rm -f $i; mkdir $i; break; done
git fsck
# fatal: mmap failed: No such device


Best Regards,
Michał Mirosław

Bug#901344: autofs: crashes when built with -Wl,-Bsymbolic-functions

[Andreas Hasenack]

Package: autofs
Version: 5.1.2-3
Severity: normal


Hi,

Ubuntu has had -Bsymbolic-functions enabled in its build flags for
quite some time. Some packages don't work with that flag set, and it's
then disabled on a case by case basis.. One such package is autofs.
There have been various bugs filed against Ubuntu whenever that flag
was inadvertently left in place:

https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1470687: Not
working properly with compile options "-symbolic-functions"
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1472115: autofs
start fails: segfault at 0 ip 
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1503034: Autofs
5.1.1-1ubuntu2 crashes with segfault on startup

Ubuntu has been carrying the following delta with Debian:

a) d/rules:
https://git.launchpad.net/ubuntu/+source/autofs/commit/?id=ae31d5b93d825d83a27a2032b8c031e6524d095b
- strip it from LDFLAGS:
LDFLAGS="$(dpkg-buildflags --get LDFLAGS | sed -e
's/-Wl,-Bsymbolic-functions//')"
(which is incorrect, it should be $$(.), but keep reading for my suggestion)

b) ldap lookup patch:
https://git.launchpad.net/ubuntu/+source/autofs/tree/debian/patches/fix-lookup-ldap-crash.patch

The reason the fix from (a), even when properly made, doesn't work and
the patch from (b) is still needed is that the build of the ldap
module eventually calls krb5-config --libs, and that has, incorrectly
or not, LDFLAGS in it. LDFLAGS that were used when building the
kerberos libraries. In Ubuntu, that includes -Bsymbolic-functions.

I submitted (b) upstream just now:
https://www.spinics.net/lists/autofs/msg01903.html

Would you please consider:
a) adopting the proper fix for (a), which right now I have as this (of
course the commenting can change):
--- a/debian/rules
+++ b/debian/rules
@@ -3,6 +3,11 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+# Taken from #1636781 as it's the same problem here. Also see
+# https://lists.ubuntu.com/archives/ubuntu-devel/2018-June/040369.html
+ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
+  export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic-functions
+endif

 %:
dh $@ --with systemd

b) Adopting the patch from (b)

Thanks!

Bug#901313: ignoring: Numerical argument out of domain

[Michael Biebl]

Am 11.06.2018 um 11:41 schrieb 積丹尼 Dan Jacobson:
> Package: systemd
> Version: 238-5
> 
> Now lots of these messages:
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> umount() / -10070, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> profil() / -10040, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> lock() / -10027, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> gtty() / -10022, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> prof() / -10039, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> rtas() / -10187, ignoring: Numerical argument out of domain

That just seems to be a debug message.
Do you have debug logging enabled?
Can you provide your kernel command line as well (cat /proc/cmdline)


-- 
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#901041: libviennacl-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/libviennacl-dev/README.gz

[Anton Gladky]

Thanks, Andreas. My fault.

I hope the next upload will fix the issue. At least I can upgrade
the both packages without problem now.

Regards

Anton


2018-06-11 5:35 GMT+02:00 Andreas Beckmann :
> Followup-For: Bug #901041
> Control: found -1 1.7.1+dfsg1-4
>
> You fixed the wrong problem. The Breaks+Replaces may still be needed,
> but the underlying problem is not fixed - both libviennacl-dev and
> libviennacl-doc ship these files:
>
>   usr/share/doc/libviennacl-dev/README.gz
>   usr/share/doc/libviennacl-dev/changelog.gz
>
> This is most likely caused by a behavioral change in dh_installdocs
> in debhelper compat level 11.
>
> (Due to upload+testing timing I saw the buster->sid failure before the
> sid+sid failure).
>
>
> Andreas
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#901343: mysql++ FTCBFS: uses AC_TRY_RUN for discovering localtime_r

[Helmut Grohne]

Source: mysql++
Version: 3.2.2+pristine-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

mysql++ fails to cross build from source, because it cannot be built
without localtime_r and it fails finding localtime_r with AC_TRY_RUN.
For checking that function, AC_TRY_COMPILE is sufficient. The attached
patch should fix that, but I couldn't test it, because mysql++ fails to
autoreconf. Hope it works. Please consider applying it. Also consider
building from source.

Helmut
--- mysql++-3.2.2+pristine.orig/config/localtime_r.m4
+++ mysql++-3.2.2+pristine/config/localtime_r.m4
@@ -9,16 +9,11 @@
 [
 	AC_MSG_CHECKING([for localtime_r()])
 
-	AC_TRY_RUN([
-		#include 
-		int main(void)
-		{
+	AC_TRY_COMPILE([#include ],[
 			time_t tt;
 			struct tm stm;
 			localtime_r(, );
-			return 0;
-		}
-	], [localtime_r_found=yes], [localtime_r_found=no], [localtime_r_found=no])
+	], [localtime_r_found=yes], [localtime_r_found=no])
 
 	AC_MSG_RESULT([$localtime_r_found])
 	if test x"$localtime_r_found" = xyes

Bug#900987: libncurses-dev: feature test macros in compiler flags

[Sven Joachim]

Control: tags -1 upstream

On 2018-06-07 19:11 +0200, Jakub Wilk wrote:

> Package: libncurses-dev
> Version: 6.1+20180210-4
>
> The compiler flags that are supposedly needed to compile with ncurses
> include feature test macros:
>
>   $ ncurses6-config --cflags
>   -D_GNU_SOURCE -D_DEFAULT_SOURCE
>
>   $ pkg-config --cflags ncurses
>   -D_GNU_SOURCE -D_DEFAULT_SOURCE

This has been done upstream in the 20150221 patchlevel:

,
| + capture define's related to -D_XOPEN_SOURCE from the configure check
|   and add those to the *-config and *.pc files, to simplify use for
|   the wide-character libraries.
`

Which raises a few questions, e.g.

- Why is this done even if ncurses is configured without --enable-widec ?

- Why does it end up in tinfo.pc and tic.pc which (presumably) would
  never need it?

> Please don't include them.
> _GNU_SOURCE is particularly nasty, because it can change semantics of
> some libc functions (at least sscanf and strerror_r).

I tend to agree, but would rather not deviate from upstream, especially
since this behavior has been in place for over three years already.

Cheers,
   Sven

Bug#586135: New MisterHouse release

[Robert J. Clay]

On Thu, Nov 2, 2017 at 10:06 AM Robert J. Clay  wrote:
>
> On Thu, Oct 19, 2017 at 6:30 PM, Robert J. Clay  wrote:
> > Note also that upstream is working on a new release and it may be for
> > version 5.0 rather than just version 4.3.
>
>A new version of MisterHouse was released on 31 October 2017 and it
> did indeed turn out to be version 5.0.  I will be continuing with the
> packaging effort, using the new version as the basis of it.

  The version 5.0 release is still the most recent and I will still be
basing the debian packaging on that.


--
 Robert J. Clay
 rjc...@gmail.com
 j...@rocasa.us



-- 
Robert J. Clay
rjc...@gmail.com

Bug#901342: Release 18.1.1

[積丹尼 Dan Jacobson]

Package: libgl1-mesa-glx
Version: 18.1.0-1
Severity: wishlist

In https://lists.freedesktop.org/archives/nouveau/2018-June/030500.html
we see I am asked to install 18.1.1 . So do please put it on Debian
experimental soon.

Bug#901341: trayer FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: trayer
Version: 1.1.8-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

trayer fails to cross build from source, because debian/rules does not
pass cross tools to make. Using dh_auto_build is the easiest way to fix
that. Beyond that, the upstream Makefile hard codes the build
architecture strip. Stripping during build is bad, because it breaks
DEB_BUILD_OPTIONS=nostrip and the creation of -dbgsym packages. Thus I
propose exporting the DEVEL variable that disables stripping. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru trayer-1.1.8/debian/changelog trayer-1.1.8/debian/changelog
--- trayer-1.1.8/debian/changelog   2018-03-19 03:10:13.0 +0100
+++ trayer-1.1.8/debian/changelog   2018-06-11 19:24:22.0 +0200
@@ -1,3 +1,12 @@
+trayer (1.1.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Use the makefile build system so dh_auto_build passes cross tools.
++ Disable stripping during build.
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 19:24:22 +0200
+
 trayer (1.1.8-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru trayer-1.1.8/debian/rules trayer-1.1.8/debian/rules
--- trayer-1.1.8/debian/rules   2017-07-08 06:35:35.0 +0200
+++ trayer-1.1.8/debian/rules   2018-06-11 19:24:22.0 +0200
@@ -5,8 +5,10 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
+export DEVEL=do not strip
+
 %:
-   dh $@
+   dh $@ --buildsystem=makefile
 
 override_dh_auto_configure:
./configure --prefix=/usr

Bug#749275: Updated debian source code repository

[Robert J. Clay]

 The Debian source code repository for the
libpgobject-util-pseudocsv-perl package is now at the new
salsa.debian.org service, at:

https://salsa.debian.org/perl-team/modules/packages/libpgobject-util-pseudocsv-perl



-- 
Robert J. Clay
rjc...@gmail.com
j...@rocasa.us

Bug#901340: rev-plugins FTCBFS: upstream Makefile hard codes build architecture compiler g++

[Helmut Grohne]

Source: rev-plugins
Version: 0.7.1-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

rev-plugins fails to cross build from source, because the upstream
Makefile hard codes the build architecture compiler g++. After making it
substitutable, rev-plugins cross builds successfully. Please consider
applying the attached patch.

Helmut
--- rev-plugins-0.7.1.orig/Makefile
+++ rev-plugins-0.7.1/Makefile
@@ -28,7 +28,7 @@
 
 REVERBS_O = reverbs.o reverbs_if.o zreverb.o pareq.o
 zita-reverbs.so:	$(REVERBS_O)	
-	g++ -shared  -o $@  $(REVERBS_O) $(LDFLAGS)
+	$(CXX) -shared  -o $@  $(REVERBS_O) $(LDFLAGS)
 
 reverbs.o:	ladspaplugin.h reverbs.h zreverb.h pareq.h
 reverbs_if.o:	ladspaplugin.h reverbs.h zreverb.h pareq.h

Bug#749275: PGObject::Util::PseudoCSV PREREQ_PM ?

[Robert J. Clay]

Chris,

On Fri, Jul 7, 2017 at 5:57 PM Robert J. Clay  wrote:
> On Fri, Jul 7, 2017 at 4:09 PM, Chris Travers  wrote:
>>
>> will fix that in the Makefile.  Basically at present, trying to have 
>> everything in PGObject::Util be usable by the ecosystem but not
>> depend on PGObject base classes or mappers.  The makefile.pl is in error and 
>> I will fix.
>>>
>>>
>
> OK, I'll make a note of that and keep an eye out for a new updated 
> version.   (Let me know if I should open an ticket for it.)

   I've added an issue regarding that [1] as well as one for the minor
spelling error [2].   I'll keep an eye out for when you have have a
chance to release an updated module..


-- 
Robert J. Clay
rjc...@gmail.com
j...@rocasa.us
[1] https://github.com/ledgersmb/PGObject-Util-PseudoCSV/issues/5
[2] https://github.com/ledgersmb/PGObject-Util-PseudoCSV/issues/4

Bug#897060: Some observations

[Sébastien Litaize]

Hello,

I have similar symptoms on a much older 32 bit laptop running sid.

My notes:

No problems with kernel 4.14 (I currently use 4.14.0-3-686-pae, aka 4.14.17-1).

All (Debian compiled) 4.15 and 4.16 I've tried are randomly affected (the very 
same kernel will sometimes boot OK, sometimes not).

When the graphical screen fails to come up, no key combination will restore the 
screen, but in fact the machine is running: SSHd works, and I can (blindly) 
login on tty2. "poweroff" kills SSHd, but the machine does not power down.

I suppose bisecting between 4.14 and 4.15 would be useful, but I'm not sure 
it's practical with a random kernel problem and a slow machine.

If there is anything else I can test, please ask.

Best regards,

Sebastien

Dmesg output (truncated):
[7.618511] pci :00:00.0: Intel 945GM Chipset
[7.618535] pci :00:00.0: detected gtt size: 262144K total, 262144K 
mappable
[7.619103] pci :00:00.0: detected 8192K stolen memory
[7.621865] [drm] Replacing VGA console driver
[7.622607] Console: switching to colour dummy device 80x25
[7.624237] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.624240] [drm] Driver supports precise vblank timestamp query.
[7.625131] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[7.625498] iwl3945 :02:00.0: Tunable channels: 13 802.11bg, 23 802.11a 
channels
[7.625501] iwl3945 :02:00.0: Detected Intel Wireless WiFi Link 3945ABG
[7.698373] ieee80211 phy0: Selected rate control algorithm 'iwl-3945-rs'
[7.743689] iTCO_vendor_support: vendor-support=0
[7.750950] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[7.751014] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, 
TCOBASE=0x1060)
[7.752398] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[7.835042] BUG: unable to handle kernel NULL pointer dereference at 
[7.835059] IP:   (null)
[7.835063] *pdpt = 360b4001 *pde =  
[7.835072] Oops: 0010 [#1] SMP
[7.835077] Modules linked in: iTCO_wdt iTCO_vendor_support arc4 i915(+) 
joydev evdev snd_hda_codec_conexant serio_raw snd_hda_codec_generic iwl3945 
pcspkr iwlegacy snd_hda_intel mac80211 drm_kms_helper r852 snd_hda_codec 
sm_common snd_hda_core sg snd_hwdep nand snd_pcm lpc_ich r592 nand_ecc cfg80211 
nand_bch memstick bch snd_timer mtd rfkill drm snd i2c_algo_bit shpchp rng_core 
soundcore battery ac video button cuse fuse coretemp cpufreq_userspace 
acpi_cpufreq firewire_sbp2 sunrpc loop ip_tables x_tables autofs4 ext4 crc16 
mbcache jbd2 fscrypto ecb crypto_simd cryptd aes_i586 raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod sr_mod 
cdrom ata_generic firewire_ohci ahci libahci sdhci_pci cqhci
[7.835195]  sdhci mmc_core ata_piix firewire_core crc_itu_t psmouse 
i2c_i801 libata scsi_mod ehci_pci e100 mii uhci_hcd ehci_hcd usbcore usb_common 
thermal
[7.835222] CPU: 1 PID: 321 Comm: systemd-udevd Not tainted 4.16.0-2-686-pae 
#1 Debian 4.16.12-1
[7.835228] Hardware name: FUJITSU SIEMENS Amilo Si 1520/10AD, BIOS  1.01
 03/08/2006
[7.835234] EIP:   (null)
[7.835238] EFLAGS: 00010202 CPU: 1
[7.835244] EAX: f2fea000 EBX: f2fea000 ECX:  EDX: f60d1c78
[7.835251] ESI: f8b1d495 EDI: f8b1d48d EBP: f60d1c94 ESP: f60d1c54
[7.835258]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[7.835264] CR0: 80050033 CR2:  CR3: 36a8bcc0 CR4: 06f0
[7.835271] Call Trace:
[7.835378]  ? intel_modeset_setup_hw_state+0x2fc/0xee0 [i915]
[7.835390]  ? _cond_resched+0x17/0x40
[7.835464]  __intel_display_resume+0x1c/0xc0 [i915]
[7.835537]  intel_display_resume+0xcc/0xf0 [i915]
[7.835610]  intel_lid_notify+0xc7/0xd0 [i915]
[7.835682]  ? intel_lvds_mode_valid+0x50/0x50 [i915]
[7.835691]  notifier_call_chain+0x51/0x80
[7.835699]  blocking_notifier_call_chain+0x3b/0x50
[7.835707]  acpi_lid_notify_state+0x9a/0x260 [button]
[7.835714]  acpi_lid_update_state+0x20/0x30 [button]
[7.835722]  acpi_lid_initialize_state+0x1e/0x30 [button]
[7.835729]  acpi_lid_input_open+0x3b/0x50 [button]
[7.835737]  input_open_device+0x78/0xa0
[7.835745]  evdev_open+0x16b/0x1b0 [evdev]
[7.835752]  ? evdev_event+0x50/0x50 [evdev]
[7.835760]  chrdev_open+0xa3/0x1a0
[7.835769]  do_dentry_open+0x1ac/0x2d0
[7.835775]  ? cdev_put.part.1+0x20/0x20
[7.835781]  vfs_open+0x41/0x70
[7.835789]  path_openat+0x560/0x1290
[7.835797]  ? snprintf+0x15/0x20
[7.835803]  ? input_print_bitmap+0xdb/0xf0
[7.835811]  do_filp_open+0x6a/0xd0
[7.835820]  ? __alloc_fd+0x36/0x160
[7.835827]  do_sys_open+0x1b5/0x250
[7.835834]  SyS_openat+0x1b/0x20
[7.835841]  do_fast_syscall_32+0x7f/0x1b0
[7.835849]  entry_SYSENTER_32+0x4e/0x7c
[7.835855] EIP: 0xb7facd09
[7.835859] 

Bug#901339: pd-iemlib: pvu~ is missing (maybe other objects too?)

[Jogi]

Package: pd-iemlib
Version: 1.20.1-2
Severity: normal

Dear Maintainer,

I just noticed that "pvu~" is missing from pd-iemlib.  Please fix :)

Cheers,
J.Hofmueller



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

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

Versions of packages pd-iemlib depends on:
ii  libc6   2.24-11+deb9u3
ii  puredata0.48.1-4
ii  puredata-core [pd]  0.48.1-4

pd-iemlib recommends no packages.

pd-iemlib suggests no packages.

-- no debconf information

Bug#863247: Merge request for ARM support on java-package

[Richard Ruigrok]

Hi,

Please advise if anything further is required to get this merge request 
completed and merged:

https://salsa.debian.org/java-team/java-package/merge_requests/1

Thanks,
Richard

-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Bug#901338: gitlab: dependency on postgresql-contrib pulls in postgresql server

[Frederik Himpe]

Package: gitlab
Version: 10.7.5+dfsg-2~bpo9+1
Severity: normal

Dear Maintainer,

gitlab depends on postgresql-client and postgresql-contrib. The latter
pulls in the postgresql server package, and because postgresql itself
already depends on postgresql-client, the explicit dependency on
postgresql-client in gitlab is actually useless.

Personally I already have a postgresql server running on another host,
which I want to use for gitlab, so I would prefer a suggest or recommend
dependency instead of a hard dependency.

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (600, 'stable'), (550, 'proposed-updates'), (500, 'oldstable'), 
(450, 'oldstable-proposed-updates'), (420, 'testing'), (200, 'unstable'), (160, 
'experimental'), (150, 'oldoldstable'), (140, 'oldoldstable-proposed-updates')
Architecture: amd64 (x86_64)

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

Versions of packages gitlab depends on:
ii  adduser3.115
ii  apache2 [httpd]2.4.25-3+deb9u4
ii  asciidoctor1.5.6.2-2~bpo9+1
ii  bc 1.06.95-9+b3
ii  bundler1.13.6-2
ii  dbconfig-pgsql 2.0.9~bpo9+1
ii  debconf [debconf-2.0]  1.5.61
ii  git1:2.17.1-1~bpo9+1
ii  gitlab-shell   7.1.2+dfsg-2~bpo9+1
ii  gitlab-workhorse   4.2.1+debian-2~bpo9+1
ii  init-system-helpers1.48
ii  lsb-base   9.20161125
ii  nodejs 8.11.1~dfsg-2~bpo9+1
ii  npm1.4.21+ds-2~bpo9+1
ii  openssh-client 1:7.4p1-10+deb9u3
ii  postfix [mail-transport-agent] 3.1.8-0+deb9u1
ii  postgresql-client  9.6+181+deb9u1
ii  postgresql-client-9.6 [postgresql-client]  9.6.7-0+deb9u1
ii  postgresql-contrib 9.6+181+deb9u1
ii  rake   12.3.1-1~bpo9+1
ii  redis-server   5:4.0.9-2~bpo9+1
ii  ruby   1:2.3.3
ii  ruby-ace-rails-ap  4.1.1-1
ii  ruby-acts-as-taggable-on   5.0.0-2~bpo9+1
ii  ruby-addressable   2.5.2-1~bpo9+1
ii  ruby-akismet   2.0.0-1
ii  ruby-allocations   1.0.3-1+b2
ii  ruby-arel  6.0.4-1~bpo9+1
ii  ruby-asana 0.6.0-1~bpo9+1
ii  ruby-asciidoctor-plantuml  0.0.8-1~bpo9+1
ii  ruby-asset-sync2.2.0-2~bpo9+1
ii  ruby-attr-encrypted3.1.0-1~bpo9+1
ii  ruby-babosa1.0.2-2
ii  ruby-base320.3.2-3
ii  ruby-batch-loader  1.2.1-1~bpo9+1
ii  ruby-bcrypt-pbkdf  1.0.0-1~bpo9+1
ii  ruby-bootstrap-form2.7.0-1~bpo9+1
ii  ruby-bootstrap-sass3.3.5.1-5
ii  ruby-browser   2.2.0-2
ii  ruby-carrierwave   1.2.2-1~bpo9+1
ii  ruby-charlock-holmes   0.7.5-1~bpo9+1
ii  ruby-chronic   0.10.2-3
ii  ruby-chronic-duration  0.10.6-1
ii  ruby-commonmarker  0.17.9-1~bpo9+1
ii  ruby-connection-pool   2.2.0-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise4.4.3-1~bpo9+1
ii  ruby-devise-two-factor 3.0.0-2
ii  ruby-diffy 3.1.0-1~bpo9+1
ii  ruby-doorkeeper4.3.1-1~bpo9+1
ii  ruby-doorkeeper-openid-connect 1.3.0-1~bpo9+1
ii  ruby-dropzonejs-rails  0.7.1-1
ii  ruby-email-reply-trimmer   0.1.6-1~bpo9+1
ii  ruby-escape-utils  1.2.1-1~bpo9+1
ii  ruby-excon 0.60.0-1~bpo9+1
ii  ruby-faraday   0.13.1-2~bpo9+1
ii  ruby-fast-blank1.0.0-1~bpo9+1
ii  ruby-flipper   0.13.0-3~bpo9+1
pn  ruby-flipper-active-record 
pn  ruby-flipper-active-support-cache-store
ii  ruby-fog-aliyun0.2.0-1~bpo9+1
ii  ruby-fog-aws   2.0.1-1~bpo9+1
ii  ruby-fog-core 

Bug#900803: Debian in Fongbé

[Magloire Edah]

I've been waiting for this, I can not wait to see the end of this project.
I like it so much..!

Bug#901313: ignoring: Numerical argument out of domain

[積丹尼 Dan Jacobson]

> "MB" == Michael Biebl  writes:

MB> I assume pid 230 is your "systemd --user" instance?

I don't know.

MB> It apparently fails to apply a set of seccomp filters.
MB> Please include the output of
MB> reportbug --template systemd

Hmmm, 2 lines. Might contain personal info.
I'll send it to your private address.

Bug#901313: ignoring: Numerical argument out of domain

[Michael Biebl]

Control: tags -1 + moreinfo

Am 11.06.2018 um 11:41 schrieb 積丹尼 Dan Jacobson:
> Package: systemd
> Version: 238-5
> 
> Now lots of these messages:
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> umount() / -10070, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> profil() / -10040, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> lock() / -10027, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> gtty() / -10022, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> prof() / -10039, ignoring: Numerical argument out of domain
> Jun 11 17:24:42 jidanni6 systemd[230]: Failed to add rule for system call 
> rtas() / -10187, ignoring: Numerical argument out of domain

I assume pid 230 is your "systemd --user" instance?
It apparently fails to apply a set of seccomp filters.
Please include the output of
reportbug --template systemd

to this bug report, so we have a bit more information about your system.


-- 
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#901337: darkplaces FTCBFS: uses the build architecture toolchain

[Helmut Grohne]

Source: darkplaces
Version: 0~20140513+svn12208-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

darkplaces fails to cross build from source, because it uses the build
architecture toolchain. The first step towards cross building is passing
cross tools to make and the easiest way of doing so is dh_auto_build.
That mostly works except for the makefile hard coding the build
architecture pkg-config. Then it mostly builds, except for building some
file with -msse2. The armhf compiler didn't particularly like that flag.
Turns out the upstream makefile uses uname to vary what is being built,
so we need to pass DP_MAKE_TARGET and DP_MACHINE. Pretending that
DP_MAKE_TARGET is linux works at least for linux-any, kfreebsd-any and
hurd-any. Using DEB_HOST_GNU_CPU for DP_MACHINE also works sufficiently
well, because the makefile only checks for x86_64 and x*86. Then
darkplaces cross builds successfully. Please consider applying the
attached patch.

Helmut
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+darkplaces (0~20140513+svn12208-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Also pass DP_MAKE_TARGET and DP_MACHINE to avoid uname calls.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 17:51:09 +0200
+
 darkplaces (0~20140513+svn12208-7) unstable; urgency=medium
 
   * darkplaces: Explicitly depend on libgl1. In this game engine it's
--- a/debian/patches/cross.patch
+++ b/debian/patches/cross.patch
@@ -0,0 +1,67 @@
+--- a/makefile
 b/makefile
+@@ -386,8 +386,8 @@
+ 
+ # vorbis
+ ifeq ($(DP_LINK_VORBIS), shared)
+-  CFLAGS_LIBVORBIS=-DLINK_TO_LIBVORBIS `pkg-config --cflags vorbisfile`
+-  LIB_VORBIS=`pkg-config --libs vorbisfile`
++  CFLAGS_LIBVORBIS=-DLINK_TO_LIBVORBIS `$(PKG_CONFIG) --cflags vorbisfile`
++  LIB_VORBIS=`$(PKG_CONFIG) --libs vorbisfile`
+ endif
+ ifeq ($(DP_LINK_VORBIS), dlopen)
+   CFLAGS_LIBVORBIS=
+@@ -396,8 +396,8 @@
+ 
+ # theora
+ ifeq ($(DP_LINK_THEORA), shared)
+-  CFLAGS_LIBTHEORA=-DLINK_TO_THEORA `pkg-config --cflags theora vorbis 
vorbisenc ogg`
+-  LIB_THEORA=`pkg-config --libs theora vorbis vorbisenc ogg`
++  CFLAGS_LIBTHEORA=-DLINK_TO_THEORA `$(PKG_CONFIG) --cflags theora vorbis 
vorbisenc ogg`
++  LIB_THEORA=`$(PKG_CONFIG) --libs theora vorbis vorbisenc ogg`
+ endif
+ ifeq ($(DP_LINK_THEORA), dlopen)
+   CFLAGS_LIBTHEORA=
+@@ -406,8 +406,8 @@
+ 
+ # png
+ ifeq ($(DP_LINK_PNG), shared)
+-  CFLAGS_LIBPNG=-DLINK_TO_PNG `pkg-config --cflags libpng`
+-  LIB_PNG=`pkg-config --libs libpng`
++  CFLAGS_LIBPNG=-DLINK_TO_PNG `$(PKG_CONFIG) --cflags libpng`
++  LIB_PNG=`$(PKG_CONFIG) --libs libpng`
+ endif
+ ifeq ($(DP_LINK_PNG), dlopen)
+   CFLAGS_LIBPNG=
+@@ -416,8 +416,8 @@
+ 
+ # curl
+ ifeq ($(DP_LINK_CURL), shared)
+-  CFLAGS_LIBCURL=-DLINK_TO_CURL `pkg-config --cflags libcurl`
+-  LIB_CURL=`pkg-config --libs libcurl`
++  CFLAGS_LIBCURL=-DLINK_TO_CURL `$(PKG_CONFIG) --cflags libcurl`
++  LIB_CURL=`$(PKG_CONFIG) --libs libcurl`
+ endif
+ ifeq ($(DP_LINK_CURL), dlopen)
+   CFLAGS_LIBCURL=
+@@ -425,8 +425,8 @@
+ endif
+ 
+ ifeq ($(DP_LINK_FREETYPE2), shared)
+-  CFLAGS_LIBFREETYPE2=-DLINK_TO_FREETYPE2 `pkg-config --cflags freetype2`
+-  LIB_FREETYPE2=`pkg-config --libs freetype2`
++  CFLAGS_LIBFREETYPE2=-DLINK_TO_FREETYPE2 `$(PKG_CONFIG) --cflags 
freetype2`
++  LIB_FREETYPE2=`$(PKG_CONFIG) --libs freetype2`
+ endif
+ ifeq ($(DP_LINK_FREETYPE2), dlopen)
+   CFLAGS_LIBFREETYPE2=
+--- a/makefile.inc
 b/makefile.inc
+@@ -25,6 +25,7 @@
+ CPUOPTIMIZATIONS?=-fno-math-errno -ffinite-math-only -fno-rounding-math 
-fno-signaling-nans -fno-trapping-math
+ # NOTE: *never* *ever* use the -ffast-math or -funsafe-math-optimizations flag
+ 
++PKG_CONFIG?=pkg-config
+ SDL_CONFIG?=sdl-config
+ SDL2_CONFIG?=sdl2-config
+ SDLCONFIG_UNIXCFLAGS?=`$(SDL_CONFIG) --cflags`
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -12,3 +12,4 @@
 Fix-various-typos.patch
 Don-t-build-SSE-only-software-rasterizer-on-non-x86-.patch
 Disable-gpu-skinning-for-skeletal-models.patch
+cross.patch
--- a/debian/rules
+++ b/debian/rules
@@ -38,11 +38,13 @@
 # LDFLAGS_* are used to compile builddate.c, so yes, they do need to include
 # the CPPFLAGS.
 override_dh_auto_build:
-   $(MAKE) \
+   dh_auto_build -- \
CFLAGS_RELEASE="$(CPPFLAGS) $(CFLAGS)" \
CFLAGS_DEBUG="$(CPPFLAGS) $(CFLAGS)" \
LDFLAGS_RELEASE="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)" \
LDFLAGS_DEBUG="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)" \
+   DP_MAKE_TARGET=linux \
+   DP_MACHINE=$(DEB_HOST_GNU_CPU) \
DP_LINK_CURL=shared \
DP_LINK_FREETYPE2=shared \
DP_LINK_JPEG=shared \

Bug#900203: bug#31777: guile-2.2 FTCBFS for mipsel: In procedure load-thunk-from-memory: No such file or directory

[Mark H Weaver]

Hi Rob,

Rob Browning  writes:

> [If possible, please preserve the 900203-forwarded address in replies]
>
> We're currently unable to cross-build guile 2.2 on all of the debian
> release architectures, which is important given that through make, etc.,
> guile's now part of the core bootstrap set for new architectures.
>
> You can see additional information here
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900203

Thanks.  I was able to reproduce the problem by running:

  ./meta/build-env guild compile --target=arm-unknown-linux-gnueabihf \
-Wunbound-variable -Wmacro-use-before-definition -Warity-mismatch \
-Wformat -L module --from=elisp \
-o module/language/elisp/ARM-boot.go \
module/language/elisp/boot.el

from my built git checkout of the stable-2.2 branch.

>   ERROR: In procedure load-thunk-from-memory:
>   In procedure load-thunk-from-memory: No such file or directory
>   Makefile:2267: recipe for target 'language/elisp/boot.go' failed

The "No such file or directory" was bogus, caused by bad error handling
in 'load-thunk-from-memory', and fixed in the following commits:

  
https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2=deef64a739d868ed5fda4e55e387528c1b6c196b
  
https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2=9fbb36725634d05c3e46de7619e2f6019fbeb6fe

With those fixes, the error message becomes:

  In procedure load-thunk-from-memory: ELF file does not have native word size

While cross-compiling our elisp compiler, there were attempts to load
object code built for the target machine into the Guile process running
on the build machine.

I just pushed commit bff75635e5ed08de63b02c661cf65f2e1b28c995 to the
stable-2.2 branch, which together with the earlier commit
988aa29238fca862c7e2cb55f15762a69b4c16ce allows me to successfully
cross-compile language/elisp/boot.el using the above command.

Would you like to try cherry-picking these commits and see if they fix
the problem for you?

  
https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2=988aa29238fca862c7e2cb55f15762a69b4c16ce
  
https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2=bff75635e5ed08de63b02c661cf65f2e1b28c995

 Thanks,
   Mark

Bug#901303: git-buildpackage: gbp import-orig --uscan skips unrelated files importing repacked tarball

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2018-06-11 17:52:55)
> Quoting Guido Günther (2018-06-11 16:05:46)
> > On Mon, Jun 11, 2018 at 03:52:55PM +0200, Jonas Smedegaard wrote:
> > > Quoting Guido Günther (2018-06-11 15:02:06)
> > > > Hi,
> > > > On Mon, Jun 11, 2018 at 02:10:52PM +0200, Jonas Smedegaard wrote:
> > > > > Quoting Guido Günther (2018-06-11 13:32:34)
> > > > > > Hi,
> > > > > > On Mon, Jun 11, 2018 at 11:59:58AM +0200, Jonas Smedegaard wrote:
> > > > > > > Quoting Guido Günther (2018-06-11 11:07:33)
> > > > > > > > On Mon, Jun 11, 2018 at 11:04:51AM +0200, Guido Günther wrote:
> > > > > > > > > On Mon, Jun 11, 2018 at 10:01:44AM +0200, Jonas Smedegaard 
> > > > > > > > > wrote:
> > > > > > > > > > "gbp import-orig --uscan" seems to choke on tarballs 
> > > > > > > > > > repacked by uscan.
> > > > > > > > > > 
> > > > > > > > > > With the attached debian files - changelog, copyright, and 
> > > > > > > > > > watch, in an freshly created git project (i.e. just "git 
> > > > > > > > > > init"), doing "gbp import-orig --uscan" will succeed but 
> > > > > > > > > > the resulting project wil be missing the subdirectories 
> > > > > > > > > > translations and utils.
> > > > > > > > > > 
> > > > > > > > > > Doing same without the copyright file will have all files 
> > > > > > > > > > imported.
> > > > > > > > > > 
> > > > > > > > > > The repacked tarball do contain the subdirectories, so it 
> > > > > > > > > > seems gbp chokes on it for some reason.
> > > [...]
> > > > > > The tarball generated by uscan "monero_0.12.2.0~dfsg.orig.tar.gz" 
> > > > > > does
> > > > > > not contain the directories you mention. When I run this:
> > > > > > 
> > > > > > $ git branch upstream
> > > > > > $ gbp import-orig -v --merge-mode=replace 
> > > > > > --postimport=/bin/true --no-pristine-tar --no-sign --uscan
> > > > > > … 
> > > > > > $ DIRS='translations|utils' ; tar -list -af 
> > > > > > monero_0.12.2.0~dfsg.orig.tar.gz | grep -qs -E "(${DIRS})/" || echo 
> > > > > > "${DIRS} not found"
> > > > > > translations|utils not found
> > > > > > 
> > > > > > Can you show me what I'm missing to reproduce this?
> > > > > 
> > > > > Oh - I use Midnight Commander (package mc) to inspect tarballs, and 
> > > > > apparently that can parse tarballs that tar cannot.
> > > > > 
> > > > > Seems this is an issue of corrupted tarball, then.
> > > > > 
> > > > > I now found a commandline tool that confirms that the dirs exist:  
> > > > > Can 
> > > > > you try confirm by installing package pax and running this command:
> > > > > 
> > > > >   paxtar tvzf monero_0.12.2.0~dfsg.orig.tar.gz '*.ts'
> > > > > 
> > > > > At my end, that outputs the following:
> > > > > 
> > > > > -rw-rw-r--  1 root root195575 Jun  3 18:41 
> > > > > monero-0.12.2.0/translations/monero.ts
> > > > > -rw-rw-r--  1 root root230673 Jun  3 18:41 
> > > > > monero-0.12.2.0/translations/monero_fr.ts
> > > > > -rw-rw-r--  1 root root204343 Jun  3 18:41 
> > > > > monero-0.12.2.0/translations/monero_it.ts
> > > > > -rw-rw-r--  1 root root224691 Jun  3 18:41 
> > > > > monero-0.12.2.0/translations/monero_sv.ts
> > > >
> > > > Yeah, I see these with paxtar
> > > 
> > > Good, so I am not dreaming here.  That's progress!
> > > 
> > > 
> > > > but given that dpkg (AFAIK) uses plain tar I wonder if there's a bug 
> > > > here?
> > > 
> > > I see potentially two bugs:
> > > 
> > >  a) Creating a tarball that is unparsable by Debian /bin/tar
> > > 
> > >  b) Wrongly parsing tarball with /bin/tar which other tools can parse.
> > > 
> > > Since git-buildpackage does not create any tarball here (uscan did it), 
> > > I suggest that we reuse this bugreport for b) and create a new bugreport 
> > > for a).
> > > 
> > > 
> > > > Can you dig out what makes these files different and if these are 
> > > > allowed by policy? I tried several of tar's -H options but this did 
> > > > not change anything and did not find anything related in Debian policy 
> > > > either.
> > > 
> > > Sorry, I don't understand your question.  Also, if it relates to a) then 
> > > please wait and I will file a separate bugreport for that.
> > > 
> > > 
> > > > What is monero using to create the tarball? I quick grep in the 
> > > > sources didn't bring anything up.
> > > 
> > > How upstream tarball was created might or might not matter - in any case 
> > > it is related to a), so please let me create another bugreport for that.
> > > 
> > > 
> > > First, do you agree it makes sense to separate a) into another separate 
> > > bugreport?  And discuss only b) here (and possibly reassign to tar)?
> > 
> > Yes. As I read it a) would need to be assigned to uscan (with affects:
> > git-buildpackage) and b) stays with gbp.
> >  -- Guido
> 
> Seems the bug was reported already: 831870
> 
> A workaround is mentioned - I will try if that works here too...

No, workaround seemingly only "worked" by shrinking the tarball to the 
part that didn't get mangled by 

Bug#900819: gimp: Dependency on liblcms2-2 needs tightening

[Michael Biebl]

Am 11.06.2018 um 16:22 schrieb Thomas Weber:
> Hi guys,
> 
> thanks for informing me of this problem and for the patch. I uploaded
> lcms2 2.9-2 with the fix,

Thanks!

 but I did not close the current bug report - I
> assume that gimp will need at least another rebuild to pick up the
> stricter dependency.

Correct, the gimp package will need a rebuild to pick up the tighter
dependency.

-- 
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#901303: git-buildpackage: gbp import-orig --uscan skips unrelated files importing repacked tarball

[Jonas Smedegaard]

Quoting Guido Günther (2018-06-11 16:05:46)
> On Mon, Jun 11, 2018 at 03:52:55PM +0200, Jonas Smedegaard wrote:
> > Quoting Guido Günther (2018-06-11 15:02:06)
> > > Hi,
> > > On Mon, Jun 11, 2018 at 02:10:52PM +0200, Jonas Smedegaard wrote:
> > > > Quoting Guido Günther (2018-06-11 13:32:34)
> > > > > Hi,
> > > > > On Mon, Jun 11, 2018 at 11:59:58AM +0200, Jonas Smedegaard wrote:
> > > > > > Quoting Guido Günther (2018-06-11 11:07:33)
> > > > > > > On Mon, Jun 11, 2018 at 11:04:51AM +0200, Guido Günther wrote:
> > > > > > > > On Mon, Jun 11, 2018 at 10:01:44AM +0200, Jonas Smedegaard 
> > > > > > > > wrote:
> > > > > > > > > "gbp import-orig --uscan" seems to choke on tarballs 
> > > > > > > > > repacked by uscan.
> > > > > > > > > 
> > > > > > > > > With the attached debian files - changelog, copyright, and 
> > > > > > > > > watch, in an freshly created git project (i.e. just "git 
> > > > > > > > > init"), doing "gbp import-orig --uscan" will succeed but 
> > > > > > > > > the resulting project wil be missing the subdirectories 
> > > > > > > > > translations and utils.
> > > > > > > > > 
> > > > > > > > > Doing same without the copyright file will have all files 
> > > > > > > > > imported.
> > > > > > > > > 
> > > > > > > > > The repacked tarball do contain the subdirectories, so it 
> > > > > > > > > seems gbp chokes on it for some reason.
> > [...]
> > > > > The tarball generated by uscan "monero_0.12.2.0~dfsg.orig.tar.gz" does
> > > > > not contain the directories you mention. When I run this:
> > > > > 
> > > > > $ git branch upstream
> > > > > $ gbp import-orig -v --merge-mode=replace --postimport=/bin/true 
> > > > > --no-pristine-tar --no-sign --uscan
> > > > > … 
> > > > > $ DIRS='translations|utils' ; tar -list -af 
> > > > > monero_0.12.2.0~dfsg.orig.tar.gz | grep -qs -E "(${DIRS})/" || echo 
> > > > > "${DIRS} not found"
> > > > > translations|utils not found
> > > > > 
> > > > > Can you show me what I'm missing to reproduce this?
> > > > 
> > > > Oh - I use Midnight Commander (package mc) to inspect tarballs, and 
> > > > apparently that can parse tarballs that tar cannot.
> > > > 
> > > > Seems this is an issue of corrupted tarball, then.
> > > > 
> > > > I now found a commandline tool that confirms that the dirs exist:  Can 
> > > > you try confirm by installing package pax and running this command:
> > > > 
> > > >   paxtar tvzf monero_0.12.2.0~dfsg.orig.tar.gz '*.ts'
> > > > 
> > > > At my end, that outputs the following:
> > > > 
> > > > -rw-rw-r--  1 root root195575 Jun  3 18:41 
> > > > monero-0.12.2.0/translations/monero.ts
> > > > -rw-rw-r--  1 root root230673 Jun  3 18:41 
> > > > monero-0.12.2.0/translations/monero_fr.ts
> > > > -rw-rw-r--  1 root root204343 Jun  3 18:41 
> > > > monero-0.12.2.0/translations/monero_it.ts
> > > > -rw-rw-r--  1 root root224691 Jun  3 18:41 
> > > > monero-0.12.2.0/translations/monero_sv.ts
> > >
> > > Yeah, I see these with paxtar
> > 
> > Good, so I am not dreaming here.  That's progress!
> > 
> > 
> > > but given that dpkg (AFAIK) uses plain tar I wonder if there's a bug 
> > > here?
> > 
> > I see potentially two bugs:
> > 
> >  a) Creating a tarball that is unparsable by Debian /bin/tar
> > 
> >  b) Wrongly parsing tarball with /bin/tar which other tools can parse.
> > 
> > Since git-buildpackage does not create any tarball here (uscan did it), 
> > I suggest that we reuse this bugreport for b) and create a new bugreport 
> > for a).
> > 
> > 
> > > Can you dig out what makes these files different and if these are 
> > > allowed by policy? I tried several of tar's -H options but this did 
> > > not change anything and did not find anything related in Debian policy 
> > > either.
> > 
> > Sorry, I don't understand your question.  Also, if it relates to a) then 
> > please wait and I will file a separate bugreport for that.
> > 
> > 
> > > What is monero using to create the tarball? I quick grep in the 
> > > sources didn't bring anything up.
> > 
> > How upstream tarball was created might or might not matter - in any case 
> > it is related to a), so please let me create another bugreport for that.
> > 
> > 
> > First, do you agree it makes sense to separate a) into another separate 
> > bugreport?  And discuss only b) here (and possibly reassign to tar)?
> 
> Yes. As I read it a) would need to be assigned to uscan (with affects:
> git-buildpackage) and b) stays with gbp.
>  -- Guido

Seems the bug was reported already: 831870

A workaround is mentioned - I will try if that works here too...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#901274: [lintian] warn about *.md,.eslintrc, .npmignore, LICENSE, CHANGES, PATENTS, *.woff, *.ttf, *.woff.? under /usr/lib/node (may be /usr/lib ?)

[Chris Lamb]

Bastien,

> >> >> Did you prefer a reset or reset of master ?
> >> >
> >> > A reset or a reset?
> >>
> >> A reset or a revert...
>
> pushed Bug#901274

May I suggest making a merge requests so it's easier to comment on?


Regards,

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

Bug#901336: xcftools FTCBFS: does not propagate CC from ./configure to make

[Helmut Grohne]

Source: xcftools
Version: 1.0.7-6
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

xcftools fail to cross build from source, because the correctly detected
cross compiler is not propagated from ./configure to make. The attached
patch fixes that nad makes xcftools cross build successfully. Please
consider applying it.

Helmut
--- xcftools-1.0.7.orig/Makefile.in
+++ xcftools-1.0.7/Makefile.in
@@ -30,6 +30,7 @@
 APPNAME			= @PACKAGE_TARNAME@
 program_transform_name	= @program_transform_name@
 
+CC			= @CC@
 CFLAGS			= @CFLAGS@
 LDFLAGS			= @LDFLAGS@ @LIBICONV@
 LIBS			= @LIBS@

Bug#901335: id3ren is stripped during make install

[Helmut Grohne]

Source: id3ren
Version: 1.1b0-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

make install strips id3ren. This breaks:
 * Handling of DEB_BUILD_OPTIONS=nostrip -> #437191
 * Generation of a -dbgsym package
 * Cross building (as the build architecture strip is used)

Please consider applying the attached patch or bumping the debhelper
compatibility level to at least 11. Doing so also fixes #437191.

Helmut
diff --minimal -Nru id3ren-1.1b0/debian/changelog id3ren-1.1b0/debian/changelog
--- id3ren-1.1b0/debian/changelog   2016-06-05 07:38:41.0 +0200
+++ id3ren-1.1b0/debian/changelog   2018-06-11 17:37:17.0 +0200
@@ -1,3 +1,10 @@
+id3ren (1.1b0-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't strip during make install. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 17:37:17 +0200
+
 id3ren (1.1b0-7) unstable; urgency=low
 
   * QA upload.
diff --minimal -Nru id3ren-1.1b0/debian/rules id3ren-1.1b0/debian/rules
--- id3ren-1.1b0/debian/rules   2016-06-05 01:45:20.0 +0200
+++ id3ren-1.1b0/debian/rules   2018-06-11 17:37:15.0 +0200
@@ -5,3 +5,6 @@
 
 %:
dh  $@
+
+override_dh_auto_install:
+   dh_auto_install -- INSTALL='install --strip-program=true'

Bug#895469: openjfx FTBFS on armel: invalid instructions

[Emmanuel Bourg]

Le 11/06/2018 à 15:10, peter green a écrit :

> Debdiff for what I uploaded to raspbian is available at
> http://debdiffs.raspbian.org/main/o/openjfx/openjfx_8u141-b14-3%2brpi1.debdiff

Thanks a lot for the help Peter!

It looks like JSStringRef.cpp was eventually fixed upstream (at least in
OpenJFX 9.0.1+11 [1], but not on the 8u-dev branch yet).

I'll try to upload OpenJFX 8u171 with this patch before upgrading to
OpenJFX 11.

[1]
https://salsa.debian.org/java-team/openjfx9/blob/master/modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSStringRef.cpp#L65

Bug#901334: restore window title upon exit

[積丹尼 Dan Jacobson]

Package: xterm
Version: 333-1
Severity: wishlist

# su - dyy #causes the icewm window title to change.
$ exit #leaves the window title as dyy@jidanni6 BAD

Bug#901333: mp3rename FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: mp3rename
Version: 0.6-10
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

mp3rename fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that is using
dh_auto_build. Unfortunately, it's not that easy as mp3rename uses
help2man. I really recommend using a proper manpage. In the presence of
help2man, we can build mp3rename twice: Once for help2man and then for
real. The attached patch implements that and makes mp3rename cross
buildable. Please consider applying the attached patch.

Helmut
diff -u mp3rename-0.6/debian/changelog mp3rename-0.6/debian/changelog
--- mp3rename-0.6/debian/changelog
+++ mp3rename-0.6/debian/changelog
@@ -1,3 +1,12 @@
+mp3rename (0.6-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Build twice: once for help2man and once for real.
++ Let dh_auto_build pass cross tools to make.
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 16:52:27 +0200
+
 mp3rename (0.6-10) unstable; urgency=medium
 
   * QA upload.
diff -u mp3rename-0.6/debian/rules mp3rename-0.6/debian/rules
--- mp3rename-0.6/debian/rules
+++ mp3rename-0.6/debian/rules
@@ -8,6 +8,9 @@
 # This is the debhelper compatability version to use.
 #export DH_COMPAT=3
 
+include /usr/share/dpkg/architecture.mk
+export DEB_BUILD_MAINT_OPTIONS=hardening=-format
+
 configure: configure-stamp
 configure-stamp:
dh_testdir
@@ -20,12 +23,15 @@
 build-stamp:
dh_testdir
 
-   # Add here commands to compile the package.
-   $(MAKE)
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build
#/usr/bin/docbook-to-man debian/mp3rename.sgml > mp3rename.1
/usr/bin/help2man -h -h -v '-s help' -S 'Debian GNU/Linux' \
-N -o mp3rename.1 -n 'Rename mp3 files based on id3tags' \
./mp3rename
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   dh_auto_clean
+   dh_auto_build
+endif
 
touch build-stamp
 

Bug#901306: pandoc: FTBFS on armhf: ghc: panic

[John MacFarlane]

It would be worth reporting this as a bug to the ghc
tracker, as requested in the message.

Emilio Pozuelo Monfort  writes:

> Source: pandoc
> Version: 2.2.1-1
> Severity: serious
>
> pandoc now FTBFS on armhf with a ghc panic:
>
> [112 of 131] Compiling Text.Pandoc.Readers.HTML ( 
> src/Text/Pandoc/Readers/HTML.hs, dist-ghc/build/Text/Pandoc/Readers/HTML.p_o )
> ghc: panic! (the 'impossible' happened)
>   (GHC version 8.2.2 for arm-unknown-linux):
>   piResultTy
>   Addr#
>   String
>   Call stack:
>   CallStack (from HasCallStack):
> prettyCurrentCallStack, called at 
> compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
> callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in 
> ghc:Outputable
> pprPanic, called at compiler/types/Type.hs:949:35 in ghc:Type
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> Full logs at https://buildd.debian.org/status/logs.php?pkg=pandoc=armhf
>
> Emilio

Bug#901274: [lintian] warn about *.md,.eslintrc, .npmignore, LICENSE, CHANGES, PATENTS, *.woff, *.ttf, *.woff.? under /usr/lib/node (may be /usr/lib ?)

[Bastien ROUCARIES]

pushed Bug#901274

On Mon, Jun 11, 2018 at 9:59 AM, Chris Lamb  wrote:
> Bastien,
>
>> >> > Could you move the other changes to this branch too (or a "901274"
>> >> > branch/MR or something?)
>> >>
>> >> Did you prefer a reset or reset of master ?
>> >
>> > A reset or a reset?
>>
>> A reset or a revert...
>
> I have subsequently pushed other fixes so a [--hard] reset is not
> possible and would also require an ugly force push. At this point
> pleas please back out all of the commits in a single commit.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#891636: latexmk: NMU for new upstream

[Paride Legovini]

On Wed, 28 Feb 2018 Norbert Preining  wrote:
> I have packaged the latest version 4.55a and I am planning to upload an
> NMU for it within a few days.

Dear Norbert,

Just a friendly ping: do you have any news on this? Will you proceed
with the NMU?

Cheers,

Paride

Bug#901332: d-i: Offer to shut down / power off instead of reboot at the end

[Thorsten Glaser]

Package: debian-installer
Severity: normal

d-i always insists on rebooting at the end. This is made worse
by it telling the user to change boot media, which, for virtual
machines, means reconfiguring the VM.

I *generally* wish to reconfigure the VM after first install
*anyway*.

So, please, at the end, where it tells the reboot message, add
a third button that shuts down / powers off the system instead
of rebooting.

Thanks in advance!

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

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

Bug#901331: stretch-pu: package ganeti/2.15.2-7+deb9u2

[Apollon Oikonomopoulos]

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

Dear SRMs,

I would like to update ganeti in Stretch to resolve #895599, whereby 
ganeti fails to "export" (aka dump) VMs because of an SSL verification 
error. The bug is fixed by cherry-picking an upstream commit, already 
included in 2.16 which is in unstable.

Full source debdiff attached.

Regards,
Apollon
diff -Nru ganeti-2.15.2/debian/changelog ganeti-2.15.2/debian/changelog
--- ganeti-2.15.2/debian/changelog	2017-10-03 17:31:05.0 +0300
+++ ganeti-2.15.2/debian/changelog	2018-06-11 17:42:10.0 +0300
@@ -1,3 +1,9 @@
+ganeti (2.15.2-7+deb9u2) stretch; urgency=medium
+
+  * Properly verify SSL certificates during VM export (Closes: #895599)
+
+ -- Apollon Oikonomopoulos   Mon, 11 Jun 2018 17:42:10 +0300
+
 ganeti (2.15.2-7+deb9u1) stretch; urgency=medium
 
   * Depend on lsb-base (>= 3.0.6) for init-functions.
diff -Nru ganeti-2.15.2/debian/patches/impexpd-fix-certificate-verification-with-new-socat.patch ganeti-2.15.2/debian/patches/impexpd-fix-certificate-verification-with-new-socat.patch
--- ganeti-2.15.2/debian/patches/impexpd-fix-certificate-verification-with-new-socat.patch	1970-01-01 02:00:00.0 +0200
+++ ganeti-2.15.2/debian/patches/impexpd-fix-certificate-verification-with-new-socat.patch	2018-06-11 17:42:10.0 +0300
@@ -0,0 +1,55 @@
+From 7bb03511f6b13f83cc7cbc5fe6a30bd46105b0bd Mon Sep 17 00:00:00 2001
+From: Apollon Oikonomopoulos 
+Date: Wed, 20 Dec 2017 12:57:12 +0200
+Subject: [PATCH] impexpd: fix certificate verification with new socat versions
+
+Socat versions after 1.7.3 verify the server certificate's subject
+against either the hostname, or the openssl-commonname option. Since
+ganeti uses 'ganeti.example.com' for all self-signed certs, certificate
+verification will fail, as socat will be told to connect to the node
+using its proper name.
+
+Fix this by passing the openssl-commonname option. Since this option is
+only available on newer socat versions and older socat versions will
+break when passed the unknown option, we need to parse `socat -V` output
+to check if we need to specify the option or not.
+
+This fixes #1226.
+
+Signed-off-by: Apollon Oikonomopoulos 
+---
+ lib/impexpd/__init__.py | 18 ++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/lib/impexpd/__init__.py b/lib/impexpd/__init__.py
+index 97a9716cc..850bdb987 100644
+--- a/lib/impexpd/__init__.py
 b/lib/impexpd/__init__.py
+@@ -197,6 +197,24 @@ class CommandBuilder(object):
+ "intervall=1",
+ ] + common_addr_opts
+ 
++  # For socat versions >= 1.7.3, we need to also specify
++  # openssl-commonname, otherwise server certificate verification will
++  # fail.
++  socat = utils.RunCmd([SOCAT_PATH, "-V"])
++  # No need to check for errors here. If -V is not there, socat is really
++  # old. Any other failure will be handled when running the actual socat
++  # command.
++  for line in socat.output.splitlines():
++match = re.match(r"socat version ((\d+\.)*(\d+))", line)
++if match:
++  try:
++version = tuple(int(x) for x in m.group(1).split('.'))
++if version >= (1, 7, 3):
++  addr2 += ["openssl-commonname=%s" % constants.X509_CERT_CN]
++  except TypeError:
++pass
++  break
++
+ else:
+   raise errors.GenericError("Invalid mode '%s'" % self._mode)
+ 
+-- 
+2.17.1
+
diff -Nru ganeti-2.15.2/debian/patches/series ganeti-2.15.2/debian/patches/series
--- ganeti-2.15.2/debian/patches/series	2017-10-03 14:09:55.0 +0300
+++ ganeti-2.15.2/debian/patches/series	2018-06-11 17:42:10.0 +0300
@@ -16,3 +16,4 @@
 use-hv-class-to-check-for-migration.patch
 do-not-specify-socat-ssl-method.patch
 fix-failover-from-dead-node.patch
+impexpd-fix-certificate-verification-with-new-socat.patch

Bug#901330: xserver-xorg-core: Consider autobind-GPUs patch

[Sam Morris]

Package: xserver-xorg-core
Version: 1.19.6-1
Severity: wishlist
Tags: upstream patch

Red Hat, Fedora and Ubuntu have been carrying (an older iteration of)
the attached patch for a while. It makes external displays on laptops
such as the Lenono P50, which wires them to the discrete GPU only,
usable without explicit configuration by the end user (e.g., arranging
to run xrandr --setprovideroutputsource during login).

I've been testing this on my laptop for a few days and haven't seen any
particular problems with it (I have filed separate bugs for the other
issues that I've seen while testing).

NB, after applying the patch, you still have to enable the AutoBindGPU
option in a ServerFlags section of xorg.conf. It would be nice if the
functionality could be enabled by default, as it is in the other
distributions that ship earlier versions of the patch.

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:191b] (rev 06)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107GLM [Quadro 
M2000M] [10de:13b0] (rev a2)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 62 Jun  4 13:47 10-auto-bind-gpu.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.16.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27)

Xorg X server log files on system:
--
-rw-r--r-- 1 sam sam 76928 May 24 13:40 /home/sam/.local/share/xorg/Xorg.2.log
-rw-r--r-- 1 sam sam 64495 Jun 11 14:14 /home/sam/.local/share/xorg/Xorg.1.log

Contents of most recent Xorg X server log file 
(/home/sam/.local/share/xorg/Xorg.1.log):

[49.331] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() 
failed
[49.331] _XSERVTransMakeAllCOTSServerListeners: server already running
[49.331] (--) Log file renamed from 
"/home/sam/.local/share/xorg/Xorg.pid-1598.log" to 
"/home/sam/.local/share/xorg/Xorg.1.log"
[49.331] 
X.Org X Server 1.20.0
X Protocol Version 11, Revision 0
[49.331] Build Operating System: Linux 4.16.0-2-amd64 x86_64 Debian
[49.331] Current Operating System: Linux joyeux 4.16.0-2-amd64 #1 SMP 
Debian 4.16.12-1 (2018-05-27) x86_64
[49.331] Kernel command line: BOOT_IMAGE=/vmlinuz-4.16.0-2-amd64 
root=/dev/mapper/joyeux-root ro quiet cgroup_enable=memory swapaccount=1 
zswap.enabled=1 splash
[49.331] Build Date: 04 June 2018  09:39:00AM
[49.331] xorg-server 2:1.20.0-2sam1 (https://www.debian.org/support) 
[49.331] Current version of pixman: 0.34.0
[49.331]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[49.331] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[49.331] (==) Log file: "/home/sam/.local/share/xorg/Xorg.1.log", Time: Thu 
Jun  7 17:36:38 2018
[49.331] (==) Using config directory: "/etc/X11/xorg.conf.d"
[49.331] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[49.331] (==) No Layout section.  Using the first Screen section.
[49.331] (==) No screen section available. Using defaults.
[49.331] (**) |-->Screen "Default Screen Section" (0)
[49.331] (**) |   |-->Monitor ""
[49.332] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[49.332] (**) Option "AutoBindGPU" "true"
[49.332] (==) Automatically adding devices
[49.332] (==) Automatically enabling devices
[49.332] (==) Automatically adding GPU devices
[49.332] (**) Automatically binding GPU devices
[49.332] (==) Max clients allowed: 256, resource mask: 0x1f
[49.332] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[49.332]Entry deleted from font path.
[49.332] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[49.332] (==) ModulePath set to "/usr/lib/xorg/modules"
[49.332] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[49.332] (II) Loader magic: 0x560ce08ddde0
[49.332] (II) Module ABI versions:
[49.332]X.Org ANSI C Emulation: 0.4
[  

Bug#900912: openjdk-10: Accessibility does not get loaded

[Samuel Thibault]

Control: tags -1 + patch

Samuel Thibault, le lun. 11 juin 2018 15:17:05 +0200, a ecrit:
> be it a hardcoded classpath to java-atk-wrapper.jar.

For instance the attached patch works fine (and doesn't disturb the
headless case).

Samuel
Index: openjdk-10-10.0.1+10/src/hotspot/os/linux/os_linux.cpp
===
--- openjdk-10-10.0.1+10.orig/src/hotspot/os/linux/os_linux.cpp
+++ openjdk-10-10.0.1+10/src/hotspot/os/linux/os_linux.cpp
@@ -369,6 +369,7 @@ void os::init_system_properties_values()
 }
 Arguments::set_java_home(buf);
 set_boot_path('/', ':');
+Arguments::append_sysclasspath("/usr/share/java/java-atk-wrapper.jar");
   }
 
   // Where to look for native libraries.

Bug#884484: python-cryptography-vectors/2.2.2-1 appears to break python-cryptography in testing

[Tristan Seligmann]

On Mon, 11 Jun 2018 at 09:15 Paul Gevers  wrote:

> Hi Tristan,
>
> On 11-06-18 02:49, Tristan Seligmann wrote:
> > On Sun, 10 Jun 2018 at 21:57 Paul Gevers  > did you ever
> > considered to add these vectors (as a second tar ball in the source 3
> > format) to the source package of python-cryptography?
> >
> >
> > I think this might actually be the ideal solution, all else being equal,
> > but a lot of the tooling in use (dh_python, pybuild, git-dpm, etc.)
> > unfortunately does not handle this scenario well, so I haven't attempted
> it.
>
> I don't assume you filed bug reports against those tools?
>

git-dpm is unmaintained now, I think; DPMT is switching to gbp-pq which I
think does support multiple tarballs. Thinking about the other tools, I
guess the problem is that there are two entirely separate (but duplicate;
ie. both Python packages) build processes that need to be run, and usually
we would use two separate source packages to do this. But maybe there's
something I missed?

Anyhow, to answer the question, I didn't file any bug reports myself.

Bug#901329: libglc-dev: move quesoglc.pc to a multiarch location

[Helmut Grohne]

Package: libglc-dev
Version: 0.7.2-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:warzone2100

warzone2100 fails to cross build from source, because it cannot find
quesoglc.pc. During cross compilation, pkg-config does not search
/usr/lib/pkgconfig. Thus quesoglc.pc should be moved to a multiarch
libdir. The attached patch implements that. Please consider applying it.

Helmut
diff --minimal -Nru quesoglc-0.7.2/debian/changelog 
quesoglc-0.7.2/debian/changelog
--- quesoglc-0.7.2/debian/changelog 2011-08-15 19:44:42.0 +0200
+++ quesoglc-0.7.2/debian/changelog 2018-06-11 16:35:25.0 +0200
@@ -1,3 +1,10 @@
+quesoglc (0.7.2-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Configure with a multiarch --libdir. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 16:35:25 +0200
+
 quesoglc (0.7.2-5) unstable; urgency=low
 
   [ Paul Wise ]
diff --minimal -Nru quesoglc-0.7.2/debian/libglc-dev.install 
quesoglc-0.7.2/debian/libglc-dev.install
--- quesoglc-0.7.2/debian/libglc-dev.install2011-08-15 10:42:16.0 
+0200
+++ quesoglc-0.7.2/debian/libglc-dev.install2018-06-11 16:35:25.0 
+0200
@@ -1,4 +1,4 @@
 usr/include/*
-usr/lib/libGLC.a
-usr/lib/libGLC.so
-usr/lib/pkgconfig/quesoglc.pc
+usr/lib/*/libGLC.a
+usr/lib/*/libGLC.so
+usr/lib/*/pkgconfig/quesoglc.pc
diff --minimal -Nru quesoglc-0.7.2/debian/libglc0.install 
quesoglc-0.7.2/debian/libglc0.install
--- quesoglc-0.7.2/debian/libglc0.install   2011-03-11 07:19:31.0 
+0100
+++ quesoglc-0.7.2/debian/libglc0.install   2018-06-11 16:35:25.0 
+0200
@@ -1 +1 @@
-usr/lib/libGLC.so.*
+usr/lib/*/libGLC.so.*
diff --minimal -Nru quesoglc-0.7.2/debian/rules quesoglc-0.7.2/debian/rules
--- quesoglc-0.7.2/debian/rules 2011-08-15 19:20:56.0 +0200
+++ quesoglc-0.7.2/debian/rules 2018-06-11 16:35:25.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 %:
dh $@ --parallel --with autoreconf
 
@@ -9,11 +11,11 @@
 
 override_dh_auto_configure:
rm -rf src/glew.c src/fribidi
-   dh_auto_configure
+   dh_auto_configure -- --libdir='$${prefix}/lib/$(DEB_HOST_MULTIARCH)'
 
 override_dh_auto_install:
dh_auto_install
-   rm $(CURDIR)/debian/tmp/usr/lib/libGLC.la
+   rm $(CURDIR)/debian/tmp/usr/lib/*/libGLC.la
 
 override_dh_install:
dh_install --fail-missing

Bug#901238: Acknowledgement (wnorwegian: Both word list files should be in UTF-8, not in ISO-8859 anymore)

[Pander]

Also have a look at the follwing. These files are OK:

/usr/share/dict/bokmaal
/usr/share/dict/bokmål -> bokmaal
/usr/share/dict/nynorsk


But these symbolic links are dubious:

/usr/share/dict/norsk -> /etc/dictionaries-common/norsk
/etc/dictionaries-common/norsk -> /usr/share/dict/bokmaal


I think this symbolic link should be removed:

/etc/dictionaries-common/norsk ->

And the following symbolic link should be used instead:

/usr/share/dict/norsk -> /usr/share/dict/nynorsk


Please double check this proposal.


On 06/10/2018 02:27 PM, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 901238: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901238.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   pan...@users.sourceforge.net
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Tollef Fog Heen 
>
> If you wish to submit further information on this problem, please
> send it to 901...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>

Bug#901328: snack FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: snack
Version: 2.2.10.20090623-dfsg-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

snack fails to cross build from source, because it does not pass --host
to ./configure. We cannot use dh_auto_configure here, because snack's
./configure does not understand --runstatedir. The attached patch passes
--host explicitly and makes snack cross build successfully. Please
consider applying it.

Helmut
diff --minimal -Nru snack-2.2.10.20090623-dfsg/debian/changelog 
snack-2.2.10.20090623-dfsg/debian/changelog
--- snack-2.2.10.20090623-dfsg/debian/changelog 2018-04-24 11:12:20.0 
+0200
+++ snack-2.2.10.20090623-dfsg/debian/changelog 2018-06-11 16:29:45.0 
+0200
@@ -1,3 +1,10 @@
+snack (2.2.10.20090623-dfsg-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass --build and --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 16:29:45 +0200
+
 snack (2.2.10.20090623-dfsg-7) unstable; urgency=medium
 
   * Add osspd as an explicit dependency of libsnack-oss since for linux it
diff --minimal -Nru snack-2.2.10.20090623-dfsg/debian/rules 
snack-2.2.10.20090623-dfsg/debian/rules
--- snack-2.2.10.20090623-dfsg/debian/rules 2018-04-24 11:12:20.0 
+0200
+++ snack-2.2.10.20090623-dfsg/debian/rules 2018-06-11 16:29:43.0 
+0200
@@ -11,6 +11,8 @@
 
 CONFIGOPTS = --enable-gcc \
 --enable-shared \
+--build=$(DEB_BUILD_GNU_TYPE) \
+--host=$(DEB_HOST_GNU_TYPE) \
 --with-tcl=/usr/lib \
 --with-tk=/usr/lib \
 --prefix=/usr \

Bug#900819: gimp: Dependency on liblcms2-2 needs tightening

[Thomas Weber]

Hi guys,

thanks for informing me of this problem and for the patch. I uploaded
lcms2 2.9-2 with the fix, but I did not close the current bug report - I
assume that gimp will need at least another rebuild to pick up the
stricter dependency.

Thomas

Bug#901160: Updating the description of the Standards-Version field

[Ian Jackson]

Sean Whitton writes ("Re: Bug#901160: Updating the description of the 
Standards-Version field"):
> A sentence that we can't readily understand should probably be removed
> from Policy.  So I propose doing that (small modification to the patch I
> posted for seconds, and already seconded by Holger).

SGTM.  (Count this as a second if you like...)

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#901327: tigervnc: FTBFS: Hunk #1 FAILED

[Niko Tyni]

Source: tigervnc
Version: 1.7.0+dfsg-8
Severity: serious

This package fails to build from source on current sid/amd64.

>From the build log:

  touch debian/stamp-patched
  /usr/bin/make -f debian/rules update-config
  make[1]: Entering directory '/<>/tigervnc-1.7.0+dfsg'
  make[1]: 'update-config' is up to date.
  make[1]: Leaving directory '/<>/tigervnc-1.7.0+dfsg'
  cd ./unix/xserver && \
{ tar --strip-components 1 -xvJf /usr/src/xorg-server.tar.xz | \
sed -e 's@^[^/]*/@@' > .apply-patches-unify-xorg-and-vnc-tree.files; } 
&& \
touch .apply-patches-unify-xorg-and-vnc-tree.stamp
  cd ./unix/xserver && { \
patch --no-backup-if-mismatch -p1 < 
/<>/tigervnc-1.7.0+dfsg/debian/xserver119.patch && \
touch .apply-patches-vnc-patch-xorg.stamp; \
  }
  patching file configure.ac
  Hunk #2 succeeded at 1778 (offset -86 lines).
  Hunk #3 succeeded at 1817 (offset -86 lines).
  Hunk #4 succeeded at 2036 (offset -87 lines).
  Hunk #5 succeeded at 2571 (offset -126 lines).
  patching file hw/Makefile.am
  patching file mi/miinitext.c
  Hunk #1 FAILED at 114.
  Hunk #2 succeeded at 109 (offset -129 lines).
  1 out of 2 hunks FAILED -- saving rejects to file mi/miinitext.c.rej
  patching file include/os.h
  Hunk #1 succeeded at 633 (offset 12 lines).
  make: *** [debian/rules:129: 
unix/xserver/.apply-patches-vnc-patch-xorg.stamp] Error 1
 
-- 
Niko Tyni   nt...@debian.org

Bug#901326: wesperanto: Convert README.Debian from ISO-8859 to UTF-8

[Pander]

Package: wesperanto
Version: 2.1.2000.02.25-55
Severity: normal
Tags: l10n

Please, convert file /usr/share/doc/wesperanto/README.Debian from
ISO-8859 test to UTF-8 Unicode text.


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

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

-- no debconf information

Bug#892175: pycryptodome FTBFS on 32bit big endian: src/montgomery.c:245: mont_mult: Assertion `t[2*abn_words] <= 1' failed

[Petter Reinholdtsen]

The assert failure is in mont_mult(), which according to its own comment 
implements
https://en.wikipedia.org/wiki/Montgomery_modular_multiplication >.  If the
patch mentioned by James, which seem to add testing of the suspected functions 
and
modify their implementation quite a bit, do solve the problem, I notice a new
upstream version has been released since the commit was applied in March.

Perhaps upgrading to the latest upstream version will solve the problem?  Anyone
working on updating the package?

-- 
Happy hacking
Petter Reinholdtsen

Bug#901325: tinycdb FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: tinycdb
Version: 0.78
Tags: patch

tinycdb fails to cross build from source, because it does not pass cross
tools to make. Using dh_auto_build fixes that and makes tinycdb cross
build successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru tinycdb-0.78/debian/changelog 
tinycdb-0.78+nmu1/debian/changelog
--- tinycdb-0.78/debian/changelog   2012-05-11 16:41:27.0 +0200
+++ tinycdb-0.78+nmu1/debian/changelog  2018-06-11 16:03:15.0 +0200
@@ -1,3 +1,10 @@
+tinycdb (0.78+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Jun 2018 16:03:15 +0200
+
 tinycdb (0.78) unstable; urgency=low
 
   * new release (0.78), a few minor fixes:
diff --minimal -Nru tinycdb-0.78/debian/rules tinycdb-0.78+nmu1/debian/rules
--- tinycdb-0.78/debian/rules   2012-05-11 16:51:50.0 +0200
+++ tinycdb-0.78+nmu1/debian/rules  2018-06-11 16:02:48.0 +0200
@@ -16,7 +16,7 @@
 build-arch: libcdb.pc
 libcdb.pc:
dh_testdir
-   $(MAKE) CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" \
+   dh_auto_build -- CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" \
staticlib sharedlib cdb-shared nss
cp -pf nss_cdb-Makefile cdb-Makefile
cp -pf cdb-shared cdb

Bug#901324: wcatalan: Convert dictionaries-common file to UTF-8 and switch symbolic link

[Pander]

Package: wcatalan
Version: 0.20111230b-10
Severity: normal
Tags: l10n

Please, convert the file /var/lib/dictionaries-common/wordlist/wcatalan
from ISO-8859 text to UTF-8 Unicode text.

Also, please switch the link
  /usr/share/dict/catalan -> catala
with the file
  /usr/share/dict/catala
because it is the convention to have the word list in a file with an
English name for the language and any local names for the language used
in a symbolic link to that file. See for example packages wdutch, wswedish and 
wdanish. Using this convention eases automatic usage of this word list from an 
English list of word list names.

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

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

Versions of packages wcatalan depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  dictionaries-common1.27.2

wcatalan recommends no packages.

wcatalan suggests no packages.

-- debconf information excluded