Bug#910698: dogtag-pki needs jdk8

[Emmanuel Bourg]

Le 17/10/2018 à 07:11, Timo Aaltonen a écrit :

> ldapjdk is built against jdk8 because jss/dogtag-pki still need it that
> way or things will break. Though now I realized maybe it might still
> work with -Dant.build.javac.target=1.8 (or whatever jdk8 uses).

What errors do you get if you use the Java 11 compiled ldapjdk with
jss/dogtag-pki?

Bug#904248: Beginnings of a patch to add netbase to build-essential

[Ansgar Burchardt]

Josh Triplett writes:
> Which effectively means the admin should never delete any existing entry
> in the file, only add their own.

It's a configuration file that is not supposed to ever be changed.  If
there are local changes, an admin will likely not include updates
provided by newer packages.

Sadly there are quite a bunch of files in /etc that aren't really
configuration files :(

> Much like /usr/share/misc/pci.ids and other such databases that record
> the state of the real world and standards committees, editing these
> files at all seems questionable.

It is.

> Suppose, hypothetically, that these
> files all moved to /usr/share/misc/ , and then libnss_files.so learned
> to read both /etc/$file and /usr/share/misc/$file , with the former not
> existing by default?

That assumes the files are only accessed via libnss_files.so.  There are
however programs that just access the files directly.  You also require
a particular configuration of nsswitch.conf: what if I look up services
via ldap? :)

One can create /etc/services.local and have a service that merges
services.local with the distribution-provided services to
/var/lib/netbase/services.  /etc/services could then be a symlink to
that file.  (If services.local is empty, /var/lib/netbase/services could
just be a symlink as well to save disk space.)

Or one can just hope a reasonable admin doesn't touch these files (the
current state).

Ansgar

Bug#909000: GUI applications need solutions for GUI

[Narcis Garcia]

Most of M.Thunderbird users aren't CLI users at all.
Most of people who loss Enigmail because of this repository issue,
really loss GnuPG capability unless they use a non-FOSS extension.

Because most of Debian users are only users; neither developers nor
system administrators.

Bug#911212: ITP: minetest-mod-mobs-redo -- Minetest module to add mobs programming interface

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: minetest-mod-mobs-redo
  Version : 20181016
  Upstream Author : TenPlus1
* URL : https://notabug.org/TenPlus1/mobs_redo
* License : Expat
  Programming Lang: lua
  Description : Minetest module to add mobs programming interface

 This minetest module provides an advanced programming interface to add
 mobs into the world.
 .
 It was built from PilzAdam's original Simple Mobs with additional mobs
 by KrupnoPavel, Zeg9, ExeterDad and AspireMint.


Cheers,

jpuydt on irc.debian.org

Bug#911210: RFS: ukui-control-center/1.1.6-2 [RC]

[handsome_feng]

Package: sponsorship-requests
Severity: important

 Dear mentors,

  I am looking for a sponsor for my package "ukui-control-center"

 * Package name: ukui-control-center
   Version : 1.1.6-2
   Upstream Author : heb...@kylinos.cn
 * URL : https://github.com/ukui/ukui-control-center
 * License : GPL-2+, LGPL-2+
   Section : x11

  It builds those binary packages:

ukui-control-center - utilities to configure the UKUI desktop

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

  https://mentors.debian.net/package/ukui-control-center

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

dget -x https://mentors.debian.net/debian/pool/main/u/ukui-control-
center/ukui-control-center_1.1.6-2.dsc

  Changes since the last upload:

  * Debian/control:
+ Drop gnome-control-center-face which is not in Debian Archive (Closes:
#911061)

 Regards,
  handsome_feng



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

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

Bug#911211: Increase default CMA size for armhf kernels

[Priit Laes]

Package: linux-image-armmp-lpae
Version: 4.18+98~bpo9+1

Debian Stretch

Currently, the default CMA size for armhf kernels is set to 16M.
CMA allocator is used by display engine for storing framebuffer data.

At least on sunxi platform (specifically OLinuxino-Lime2-eMMC device)
it causes issues with larger displays (namely 1920x1080), because Xorg
fails to start with following cryptic message:

[snip]
[   855.117] (II) UnloadModule: "fbdev"
[   855.117] (II) Unloading fbdev
[   855.117] (II) UnloadSubModule: "fbdevhw"
[   855.117] (II) Unloading fbdevhw
[   855.118] (==) Depth 24 pixmap format is 32 bpp
[   855.118] (EE) 
Fatal server error:
[   855.118] (EE) AddScreen/ScreenInit failed for driver 0
[   855.118] (EE) 
[   855.119] (EE) 
[/snip]

Increasing CMA size to 24MB (it seems that it can be increased only
by 8MB steps) would be fine, because CMA memory utilization with
1920x1080 display is following:

$ cat /proc/meminfo  |grep Cma
CmaTotal:  24576 kB
CmaFree:7932 kB

Bug#911209: FTBFS (some tests fail)

[Alberto Gonzalez Iniesta]

Package: modsecurity
Version: 3.0.2-1
Severity: serious

Yep, some tests are failing on all buildd. Looking into it.
Thanks Santiago Vila for the heads up.

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

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

Bug#910665: FTBFS on Debian sid

[Chris Knadle]

I'm looking at the build logs of the build failure, and I see that zeroc-ice
3.7.1-2 from June built correctly, but the 3.7.1-2+b1 binNMU fails to build.

   https://buildd.debian.org/status/logs.php?pkg=zeroc-ice&arch=amd64

I'm trying to figure out: which source dependency was uploaded such that a
binNMU was triggered?

The build error happens when building within a python-3 directory, so I'm
guessing this issue is python3 related.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



signature.asc
Description: OpenPGP digital signature

Bug#911208: dolphin: kded5 crashes on right click outside ~/ directory

[Jajo]

Package: dolphin
Version: 4:18.08.0-1
Severity: normal

Dear Maintainer,

When I right click on directories owned by root precisely, it crashes and
restarts kded5. Here is error from the logs

Oct 17 06:54:17 jajo org.kde.kded5[1544]: svn: E235000: In file
'/build/subversion-ZVK4Mj/subversion-1.10.2/subversion/libsvn_wc/wc_db.c' line
9211: assertion failed (svn_dirent_is_absolute(local_abspath))
Oct 17 06:54:18 jajo org.kde.kded5[1544]: KCrash: Attempting to start
/usr/bin/kded5 from kdeinit
Oct 17 06:54:18 jajo org.kde.kded5[1544]: Warning: connect() failed: :
Connection refused
Oct 17 06:54:18 jajo org.kde.kded5[1544]: KCrash: Attempting to start
/usr/bin/kded5 directly
Oct 17 06:54:18 jajo org.kde.kded5[1544]: sock_file=/run/user/1000/kdeinit5__0
Oct 17 06:54:18 jajo org.kde.kded5[1544]: KCrash: crashing...
crashRecursionCounter = 2
Oct 17 06:54:18 jajo org.kde.kded5[1544]: KCrash: Application Name = kded5 path
= /usr/bin pid = 4517
Oct 17 06:54:18 jajo org.kde.kded5[1544]: KCrash: Arguments: /usr/bin/kded5
Oct 17 06:54:18 jajo org.kde.kded5[1544]: KCrash: Attempting to start
/usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit
Oct 17 06:54:18 jajo org.kde.kded5[1544]: Warning: connect() failed: :
Connection refused
Oct 17 06:54:18 jajo org.kde.kded5[1544]: KCrash: Attempting to start
/usr/lib/x86_64-linux-gnu/libexec/drkonqi directly
Oct 17 06:54:18 jajo org.kde.kded5[1544]: sock_file=/run/user/1000/kdeinit5__0
Oct 17 06:54:18 jajo org.kde.kded5[1544]: QSocketNotifier: Invalid socket 7 and
type 'Read', disabling...
Oct 17 06:54:18 jajo org.kde.kded5[1544]: QSocketNotifier: Invalid socket 31
and type 'Read', disabling...
Oct 17 06:54:18 jajo org.kde.kded5[1544]: QSocketNotifier: Invalid socket 14
and type 'Read', disabling...



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

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

Versions of packages dolphin depends on:
ii  baloo-kf5  5.49.0-1+b1
ii  kinit  5.49.0-1
ii  kio5.49.0-1
ii  libc6  2.27-6
ii  libdolphinvcs5 4:18.08.0-1
ii  libkf5baloo5   5.49.0-1+b1
ii  libkf5baloowidgets54:18.08.1-1
ii  libkf5bookmarks5   5.49.0-1
ii  libkf5codecs5  5.49.0-1
ii  libkf5completion5  5.49.0-1
ii  libkf5configcore5  5.49.0-1
ii  libkf5configgui5   5.49.0-1
ii  libkf5configwidgets5   5.49.0-1
ii  libkf5coreaddons5  5.49.0-1
ii  libkf5crash5   5.49.0-1
ii  libkf5dbusaddons5  5.49.0-1
ii  libkf5filemetadata35.49.0-1
ii  libkf5i18n55.49.0-1
ii  libkf5iconthemes5  5.49.0-1
ii  libkf5itemviews5   5.49.0-1
ii  libkf5jobwidgets5  5.49.0-1
ii  libkf5kcmutils55.49.0-1
ii  libkf5kiocore5 5.49.0-1
ii  libkf5kiofilewidgets5  5.49.0-1
ii  libkf5kiowidgets5  5.49.0-1
ii  libkf5newstuff55.49.0-1
ii  libkf5notifications5   5.49.0-1
ii  libkf5parts5   5.49.0-1
ii  libkf5service-bin  5.49.0-1
ii  libkf5service5 5.49.0-1
ii  libkf5solid5   5.49.0-1
ii  libkf5textwidgets5 5.49.0-1
ii  libkf5widgetsaddons5   5.49.0-1
ii  libkf5xmlgui5  5.49.0-1
ii  libphonon4qt5-44:4.10.1-1
ii  libqt5core5a   5.11.1+dfsg-9
ii  libqt5dbus55.11.1+dfsg-9
ii  libqt5gui5 5.11.1+dfsg-9
ii  libqt5widgets5 5.11.1+dfsg-9
ii  libqt5xml5 5.11.1+dfsg-9
ii  libstdc++6 8.2.0-7
ii  phonon4qt5 4:4.10.1-1

Versions of packages dolphin recommends:
ii  kimageformat-plugins  5.49.0-1
ii  kio-extras4:18.08.1-1
ii  ruby  1:2.5.1

Versions of packages dolphin suggests:
pn  dolphin-plugins  

-- no debconf information

Bug#911176: [Pkg-sysvinit-devel] Bug#911176: Bug#911176: upgrade loops indefinitely

[Petter Reinholdtsen]

[Richard Kettlewell]
> addscript racoon <<'EOF'
> ### BEGIN INIT INFO
> # Provides:  racoon
> # Required-Start:$remote_fs setkey
> # Required-Stop: $remote_fs
> # Should-Start:$portmap
> # Should-Stop: $portmap
> # Default-Start: S
> # Default-Stop:  0 1 6
> # X-Stop-After:sendsigs
> # Short-Description: start the ipsec key exchange server 
> ### END INIT INFO
> EOF

Just skimming this list tell me this is wrong.  There is no way the
racon script can both stop before $remote_fs and $portmap, and after
sendsigs which is after $remote_fs and $portmap.  Try removing the
X-Stop-After to see if the dependency loop go away.

I suggest you reassign this to whatever package provide
/etc/init.d/racoon.

-- 
Happy hacking
Petter Reinholdtsen

Bug#648499: gnome sets screen luminosity to the maximum

[Marc Glisse]

Hello,

this seems to have been fixed somehow, at least I haven't had this issue 
in a while. I am not using the same computer as back then, so it is not a 
proof.


(going through old bug reports of mine)

--
Marc Glisse

Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[NIIBE Yutaka]

Hello, again,

Simon McVittie  wrote:
> For Debian, I wonder whether we might be able to patch the script to
> remove this part, which looks like the only architecture variation:
>
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> libdir=${PKG_CONFIG_LIBDIR:-@libdir@}
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"

How about a change like this?

https://dev.gnupg.org/D467

At configure time, if it detects libdir for multiarch, it lets
gpg-error-config script architecture independent to dynamically define
PKG_CONFIG_LIBDIR (by CC or gcc -dumpmachine).

With this, we don't need to have -gpg-error-config.
-- 

Bug#910698: dogtag-pki needs jdk8

[Timo Aaltonen]

(the bug didn't get to pkg-freeipa-devel..)

Hi

ldapjdk is built against jdk8 because jss/dogtag-pki still need it that
way or things will break. Though now I realized maybe it might still
work with -Dant.build.javac.target=1.8 (or whatever jdk8 uses).

-- 
t

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Missing init-script(s)?

[Aron Xu]

Control: severity -1 wishlist

Please don't ping-pong here by changing the severity again, wishlist
is the final priority set for this bug.

I'm not against LSB support, please make it upstream. I think this
statement is clear enough.

Regards,
Aron

Bug#911207: stardict: copyright review needed

[Jeremy Bicha]

Source: stardict
Version: 3.0.1-9.4
Severity: serious

stardict needs a full copyright review. I converted the package to
copyright fomat 1.0. We'll probably want to add stuff to
Files-Excluded and create a new tarball.

Just one example is Po2Tab.zip which makes no sense and appears to be unused.

I apologize I didn't have the time to work on this right now. I
already did a bunch of other repair to the package.

Thanks,
Jeremy

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Russ Allbery]

Ansgar Burchardt  writes:

> a. tor@.service has no init script with the same name. This should be
>fine. (Note: there is also both a "tor.service" and "tor" init
>script.)

Presumably this is fine for the same reason as b.

> b. ssh.socket for systemd has no equivalent in sysvinit at all.
>This should be fine.

This is not a good example, since openssh-server provides an init script
that provides "equivalent functionality" in the form of running sshd as a
daemon, and socket units are not equivalent to an init script and
therefore aren't what this part of Policy is talking about.

> c. It is better to ship integration with some init systems than
>no integration at all. (Including sysvinit scripts at all is not
>required, only when any other integrations are provided.)

I don't agree with this.  Until such time as we make a project-wide
decision to drop support for sysvinit, providing an init script for
straightforward daemons is part of packaging a daemon.  If people are
unwilling to do this work, I don't believe we should accept the package in
Debian.  In other words, I personally believe not providing an init script
should be an RC bug (as Policy currently indicates) given the current
project stance on init systems, except for the standard exception case of
packages that are specifically designed to only be meaningful with systemd
for which making them work with any other init system would require
significant porting (not just writing a simple equivalent init script).

This is not the sort of thing that we should be dropping on an ad hoc
basis given the project decision to support multiple init systems, since
if we give up this principle it will be *extremely* hard to re-establish
it.

That doesn't mean that we can't decide to drop formal sysvinit support.
It does mean that we should do this properly, as a project-wide decision,
which is way, WAY beyond the scope of Policy and is *absolutely not*
something that we're going to be able to decide here on this mailing list
or in this bug report.

> d. Some sysvinit scripts might start multiple services at once,
>but this might be split into multiple units in other systems.
>This should be allowed.

I think tweaking the wording to account for this is reasonable.

> e. It is unclear what "equivalent functionality" implies.  Does this
>include sandboxing features?  Socket activation (which might be
>important for startup order)?  Using the same file for configuration
>(some services can be configured in /etc/default/* for sysvinit,
>but use overrides for systemd)?

This is a fair point, and I think we could certainly change the wording
here to reflect that it's unreasonable to expect 100% equivalent
functionality; there are features that sysvinit simply doesn't support,
for instance.

-- 
Russ Allbery (r...@debian.org)   

Bug#911206: RFP: multiblend -- multi-level image blender for the seamless blending of panoramic images

[Fernando Toledo]

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

--- Please fill out the fields below. ---

Package name: multiblend
Version: 0.6.2
Upstream Author: Davia Horman  
URL: http://horman.net/multiblend/
License: GPL-2+
Description: *multiblend* is a multi-level image blender for the 
seamless blending of panoramic images, such as those created with 
PTAssembler  (my personal 
favourite), Hugin , or PTGui 
. It is a significantly faster drop-in 
alternative to /Enblend/ , although it 
lacks /Enblend's/ advanced features.

Bug#911169: console-setup: can vidcontrol and kbdcontrol depends be removed for non-kfreebsd archs?

[Ben Hutchings]

On Tue, 2018-10-16 at 19:43 +0200, Holger Wansing wrote:
> Package: console-setup
> Severity: wishlist
> 
> 
> Holger Wansing  wrote:
> > Holger Wansing  wrote:
> > > I noticed that the latest upload of console-setup fails to
> > > migrate to testing.
> > > It claims being "uninstallable on amd64", while
> > > https://buildd.debian.org/status/fetch.php?pkg=console-setup&arch=all&ver=1.185&stamp=1534275854&raw=0
> > > says that the build was successful.
> > > 
> > > How can I find out what is wrong here?
> > 
> > Hmm, at the 15. day it migrated to testing now, while I cannot see that 
> > something has changed.
> 
> console-setup needs several attempts everytime, 'til it migrates.
> 
> The point is, that autopkgtest claims about unmet dependencies for all
> archs (packages vidcontrol and kbdcontrol being unavailable).
> However, these packages are only existing for kfreebsd.
> 
> Why does console-setup depend on it on all archs?
> Can the control file be changed for console-setup-freebsd as below?

No.  dpkg-gencontrol handles architecture qualification in Depends
(etc.) at build time, for architecture-dependent binary packages.  You
must not use them in architecture-independent binary packages.

Ben.

>   Package: console-setup-freebsd
>   Section: utils
>   Priority: optional
>   Architecture: all
>   Multi-Arch: foreign
> - Depends: vidcontrol, kbdcontrol, keyboard-configuration (= 
> ${source:Version}), ${misc:Depends}, init-system-helpers (>= 1.29~) | 
> initscripts
> + Depends: vidcontrol [kfreebsd-any], kbdcontrol [kfreebsd-any], 
> keyboard-configuration (= ${source:Version}), ${misc:Depends}, 
> init-system-helpers (>= 1.29~) | initscripts
>   Suggests: console-setup
>   Conflicts: console-setup-linux
>   Breaks: console-setup (<< 1.71)
>   Replaces: console-setup (<< 1.71)
>   Description: FreeBSD specific part of console-setup
>This package includes raw, uuencoded fonts and various screen maps.
> 
> 
> console-setup-freebsd is not needed on archs other than kfreebsd, I suspect?
> Or am I missing something?
> 
> 
> Holger
> 
> 
> 
-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain.
  - Lily Tomlin




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

Bug#755434: pmount: please support exfat filesystem (via fuse)

[Bernd Zeimetz]

Hi,

any news on this bug? Would be pretty awesome to have exfat support
in pmount for buster.

Thanks,

Bernd


--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#911205: Move shared library binaries from libhidapi-dev to libhidapi0 ?

[Witold Baryluk]

Package: libhidapi-dev
Severity: normal

I just found that libhidapi-dev is per arch, and delivers shared libraries.

Isn't this normally done with a package without -dev suffix? With -dev one
only having header files, pkgconfig stuff, some documentation maybe,
and sometimes static library binaries?


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

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

Bug#911157: lintian: complain about grepping the passwd/group file instead of using getent

[Chris Lamb]

Hi Rhonda,

> ~\b(grep\b.*/etc/(?:passwd|group))\b
> 
>  I'm not completely sure about the syntax here, but the \b before the
> bracket looks like it wouldn't catch egrep

Oh, good catch. Fixed in:

  
https://salsa.debian.org/lintian/lintian/commit/38b74fe0a101aa10d4ea87084fa05bc420986321

I decided against using just the filename itself as there were a few
too many false-positives and I think we would catch most peccant
maintainers of new packages it this way.

See, for example:

  https://codesearch.debian.net/search?q=%2Fetc%2Fpasswd+path%3Adebian%2F*post*

and

  https://codesearch.debian.net/search?q=%2Fetc%2Fpasswd+path%3Adebian%2F*pre*


Regards,

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

Bug#863455: firefoxdriver: switch to geckodriver?

[Paul Wise]

On Tue, 2018-10-16 at 11:07 +0200, Sascha Girrulat wrote:

> To build everything from the source it has to build from the main
> repository. But that's really a muddled bunch of binary stuff and
> it's not clear if it's possible to build it from source without
> breaking the DFSG.

It would be nice to clarify or fix this with Mozilla. IIRC the Firefox
maintainers within Debian are Mozilla employees, maybe they can help?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#911204: p4vasp: depend on unmaintained libgnomeui

[Jeremy Bicha]

Source: p4vasp
Version: 0.3.30+dfsg-3
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgnomeui
Tags: sid buster

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. These libraries have been
deprecated and unmaintained for several years.

Please port your package to GTK3 and related maintained libraries.

p4vasp was removed from Testing 9 months ago because of this issue. If
the package can't be ported away from libgnome, it will eventually
need to removed from Debian.

[1] https://lists.debian.org/debian-devel/2017/10/msg00299.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#911203: gnome-do-plugins: Intent to remove from Debian

[Jeremy Bicha]

Source: gnome-do-plugins
Version: 0.8.5-4
Severity: serious
Tags: buster sid
X-Debbugs-Cc: hyper...@debian.org, r...@ubuntu.com
Control: block 911202 by -1

gnome-do was removed from Debian Testing 9 months ago because it
depends on gnome-sharp2. gnome-sharp2 is one of several packages
preventing the removal of libgnome from Debian.

Therefore, I intend to file a removal bug for gnome-do-plugins. Please
let me know promptly if you agree or object.

See https://bugs.debian.org/885046 and https://bugs.debian.org/885047

Thanks,
Jeremy Bicha

Bug#911202: gnome-do: Intent to remove from Debian

[Jeremy Bicha]

Source: gnome-do
Version: 0.95.3-5
Severity: serious
Tags: buster sid
X-Debbugs-Cc: hyper...@debian.org, r...@ubuntu.com

gnome-do was removed from Debian Testing 9 months ago because it
depends on gnome-sharp2. gnome-sharp2 is one of several packages
preventing the removal of libgnome from Debian.

Therefore, I intend to file a removal bug for gnome-do. Please let me
know promptly if you agree or object.

See https://bugs.debian.org/885046

Thanks,
Jeremy Bicha

Bug#911201: banshee-community-extensions: Intent to remove from Debian

[Jeremy Bicha]

Source: banshee-community-extensions
Version: 2.4.0-4
Severity: serious
Tags: buster sid
X-Debbugs-Cc: joshi...@microsoft.com hyper...@debian.org
Control: block 911200 by -1

banshee was removed from Debian Testing 6 months ago because it
depends on gnome-sharp2. gnome-sharp2 is one of several packages
preventing the removal of libgnome from Debian.

Therefore, I intend to file a removal bug for
banshee-community-extensions. Please let me know promptly if you agree
or object.

See https://bugs.debian.org/885049

Thanks,
Jeremy Bicha

Bug#911200: banshee: Intent to remove from Debian

[Jeremy Bicha]

Source: banshee
Version: 2.6.2-6.2
Severity: serious
Tags: buster sid
X-Debbugs-Cc: joshi...@microsoft.com

banshee was removed from Debian Testing 6 months ago because it
depends on gnome-sharp2. gnome-sharp2 is one of several packages
preventing the removal of libgnome from Debian.

Therefore, I intend to file a removal bug for banshee. Please let me
know promptly if you agree or object.

See https://bugs.debian.org/885049

Thanks,
Jeremy Bicha

Bug#911199: docky: Intent to remove from Debian

[Jeremy Bicha]

Source: docky
Version: 2.2.1.1-1
Severity: serious
Tags: buster sid
X-Debbugs-Cc: joshi...@microsoft.com, ric...@ubuntu.com

docky was removed from Debian Testing 9 months ago because it depends
on gnome-sharp2. gnome-sharp2 is one of several packages preventing
the removal of libgnome from Debian.

Therefore, I intend to file a removal bug for docky. Please let me
know promptly if you agree or object.

See https://bugs.debian.org/885048

Thanks,
Jeremy Bicha

Bug#911197: bareftp: Intent to remove from Debian

[Jeremy Bicha]

Source: bareftp
Version: 0.3.9-3
Severity: serious
Tags: buster sid
X-Debbugs-Cc: joshi...@microsoft.com

bareftp was removed from Debian Testing 9 months ago because it
depends on gnome-sharp2. gnome-sharp2 is one of several packages
preventing the removal of libgnome from Debian.

Therefore, I intend to file a removal bug for bareftp. Please let me
know promptly if you agree or object.

See https://bugs.debian.org/885054

Thanks,
Jeremy Bicha

Bug#911198: Browser console empty, all settings deactivated

[martin f krafft]

Package: thunderbird
Version: 1:60.2.1-1
Severity: normal

The "Browser Console" is empty, and all the checkboxes next to e.g.
Logging (but also all the other menus) are unchecked. Clicking them
has no effect. As a result, no messages appear whatsoever, and there
seems to be nothing I can do about it.

I've completely removed ~/.thunderbird and was able to reproduce
this with a fresh profile, and I also confirmed that the problem
exists in safe-mode.

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.1-1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.1-1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-7
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.1-2
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libicu60  60.2-6
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.39-1
ii  libpango-1.0-01.42.4-3
ii  libpangocairo-1.0-0   1.42.4-3
ii  libpangoft2-1.0-0 1.42.4-3
ii  libsqlite3-0  3.25.2-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-7
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  lightning 1:60.2.1-1
pn  myspell-en-us | hunspell-dictionary | myspell-dictionary  

Versions of packages thunderbird suggests:
pn  apparmor  
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.16.1-1

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#857979: approx: does not start on sysvinit system

[Michael Biebl]

On Tue, 21 Mar 2017 10:26:22 +0100 Carsten Leonhardt  wrote:
> Hi,
> 
> you could add a depends on "systemd-sysv | update-inetd" and configure
> inetd only if it's installed:
> 
> [ -x /usr/sbin/update-inetd ]
> 

That doesn't seem to be a good idea.
The existence of update-inetd is not necessarily an indication that
inetd should be configured.

It would be sufficient to document what should be done for the
non-systemd case.



-- 
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#911196: RM: gnome-color-chooser -- RoQA; depends on unmaintained libgnome

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: gnome-color-choo...@packages.debian.org
Affects: src:gnome-color-chooser

gnome-color-chooser's last upstream release was in 2009 when it also
got its last maintainer upload. It got an NMU 2 years ago. Now it is
one of the packages blocking the removal of the unmaintained libgnome
libraries from Debian.

I have gotten no response on the RC bug filed in December. I contacted
the maintainer Werner Pantke in February and again in August to warn
him about the possible removal of the package but I received no
response.

Please remove gnome-color-chooser from Debian.

Thanks,
Jeremy Bicha

Bug#911195: ITP: dxvk -- Vulkan-based translation layer for Direct3D 10/11

[Alexandre Viau]

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

* Package name: dxvk
  Version : 0.90-1
  Upstream Author : Philip Rebohle
* URL : https://github.com/doitsujin/dxvk
* License : Expat
  Programming Lang: C++
  Description : Vulkan-based translation layer for Direct3D 10/11
which allows running 3D applications on Linux using
Wine.

This allows Debian gamers to enjoy much better performances in Direct3D
games using Wine.

I am still unsure which team this would fit in the best, let me know.

Cheers,

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



signature.asc
Description: OpenPGP digital signature

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Ansgar Burchardt]

Ansgar Burchardt writes:
> c. It is better to ship integration with some init systems than
>no integration at all. (Including sysvinit scripts at all is not
>required, only when any other integrations are provided.)

As a special example:

DBus can start services on-demand.  On systems using systemd dbus can do
so by asking systemd to start the service, on other systems dbus will
just start the service on its own.

So for example colord ships colord.service, but no init script as the
service will be started via
/usr/share/dbus-1/system-services/org.freedesktop.ColorManager.service
on other systems.

Policy currently forbids colord.service or requires an init script that
would have to start colord for no reason.

Ansgar

Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[NIIBE Yutaka]

Hello,

Thanks for your explanation.  I learn.

Let me explain from GnuPG development side.  We care traditional UNIXen
and unusual OSes.  (minimum version of) GnuPG should be able to be built
and installed in early stage of development.

Simon McVittie  wrote:
> Control: tags -1 - wontfix

OK.

> That will fix cross-compilation if dependent packages are changed to
> use (for example) PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= 1.33])
> instead of AM_PATH_GPG_ERROR([1.33]).

Yup.  That is my intention.

But... please note that, we don't have an idea doing like that for GnuPG
and its friends.  For building GnuPG, pkg-config (or its alternatives)
should not be one of requirements.

> Is 
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/gpg-error-config-new.in
> the new script?

Yes.

> It's very unusual to parse .pc files "by hand" like this.

I know.  Someone has to do unusual thing to break a tie.  I don't think
it's a good solution, but it makes sense in this situation.  Ugly
compromise, but I did my best to provide gpg-error.pc from upstream.

> The usual way to consume .pc files is to run pkg-config (the reference
> implementation in C) or pkgconf (a reimplementation in Perl).

Perhaps, you mean PkgConfig.  It seems it lacks PKG_CONFIG_SYSROOT_DIR
support.

There is another alternative, pkgconf in FreeBSD.  This looks easier
to build.

> For Debian, I wonder whether we might be able to patch the script to
> remove this part, which looks like the only architecture variation:
>
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> libdir=${PKG_CONFIG_LIBDIR:-@libdir@}
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"

For Debian, where we can assume good environment, package maintainer(s)
can do many things.  I'd suggest something like:

   (1) Having architecture independent -dev package _and_
   architecture dependent -dev package,

   (2) by installing original gpg-error-config as
   -gpg-error-config,

   (3) ... and installing Debian specific gpg-error-config
   which detects architecture dependent path dynamically.

Just an idea.  I don't know this feasibility.

> This is not usually possible. If I run gpg-error-config, for example like
> this:
>
> https://sources.debian.org/src/deja-dup/38.0-1/meson.build/?hl=60#L60
>
> how do you know which architecture I wanted?

Should libdir have the triplet in multiarch environment?
Or simply invoking 'dpkg-architecture -qDEB_HOST_GNU_TYPE'?


*   *   *

These posts from me are basically to inform forthcoming upstream
changes.  I don't insist changes for Debian packaging.  It's up to
Debian.

On the other hand, we are welcom to improve libgpg-error to be Debian
friendly (but not Debian specific).
-- 

Bug#911184: wicd-daemon: Please make log file location configurable

[Axel Beckert]

Control: tag -1 + moreinfo

Hi Dmitry,

Dmitry Bogatov wrote:
> I am working on integrating wicd-daemon with Runit supervision
> system, which assumes logging on stdout.

Cool!

> please make log file location configurable at run time.
> 
> In most cases, daemons have option to specify log file location, and
> providing /dev/stdout fulfils my needs. Wicd, on other hand have path
> to log file hardcoded in setup.py.

There is indeed a directory path (not file path!) in setup.py, but the
hardcoded file name is actually in wicd/wicd-daemon.py.

Then again, wicd/logfile.py seems to have already support for logging
to stdout or stderr.

And as I read the code from wicd/wicd-daemon.py lines 1803 to 1827 and
lines 1882 to 1905, starting the daemon with the option --no-stdout
(sic!) should do what you want. Alternatively try --no-stderr

Can you check if these options already help for your needs?

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

Bug#911194: libbtm-java: FTBFS with Java 11 due to javax.rmi removal

[Emmanuel Bourg]

Package: src:libbtm-java
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

libbtm-java fails to build with Java 11, it's affected by the removal
of the CORBA related classes which include the javax.rmi package:


[javac] /build/libbtm-java-2.1.4/build.xml:45: warning: 'includeantruntime' 
was not set, defaulting to build.sysclasspath=last; set to false for repeatable 
builds
[javac] Using javac -source 1.5 is no longer supported, switching to 6
[javac] Using javac -target 1.5 is no longer supported, switching to 6
[javac] Compiling 136 source files to /build/libbtm-java-2.1.4/dist/classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 6
[javac] warning: [options] source value 6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/libbtm-java-2.1.4/src/bitronix/tm/resource/jms/JndiXAConnectionFactory.java:29:
 error: package javax.rmi does not exist
[javac] import javax.rmi.PortableRemoteObject;
[javac] ^
[javac] 
/build/libbtm-java-2.1.4/src/bitronix/tm/resource/jms/JndiXAConnectionFactory.java:216:
 error: cannot find symbol
[javac] wrappedFactory = (XAConnectionFactory) 
PortableRemoteObject.narrow(lookedUpObject, XAConnectionFactory.class);
[javac]^
[javac]   symbol:   variable PortableRemoteObject
[javac]   location: class JndiXAConnectionFactory
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
[javac] 4 warnings

Bug#911193: eclipselink: FTBFS with Java 11 due to Java EE APIs removal

[Emmanuel Bourg]

Source: eclipselink
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

eclipselink fails to build with Java 11 due to the removal of several
Java EE APIs (javax.xml.soap, javax.xml.ws, javax.rmi and CORBA)

[javac] Compiling 3151 source files to 
/build/eclipselink-2.6.5/target/classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 7
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/ProviderHelper.java:16:
 error: package javax.xml.soap does not exist
[javac] import static javax.xml.soap.SOAPConstants.SOAP_1_2_PROTOCOL;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/ProviderHelper.java:16:
 error: static import only from classes and interfaces
[javac] import static javax.xml.soap.SOAPConstants.SOAP_1_2_PROTOCOL;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/ProviderHelper.java:17:
 error: package javax.xml.soap does not exist
[javac] import static javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/ProviderHelper.java:17:
 error: static import only from classes and interfaces
[javac] import static javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/ProviderHelper.java:18:
 error: package javax.xml.soap does not exist
[javac] import static javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/ProviderHelper.java:18:
 error: static import only from classes and interfaces
[javac] import static javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/ProviderHelper.java:19:
 error: package javax.xml.ws.handler does not exist
[javac] import static 
javax.xml.ws.handler.MessageContext.INBOUND_MESSAGE_ATTACHMENTS;
[javac]   ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/ProviderHelper.java:19:
 error: static import only from classes and interfaces
[javac] import static 
javax.xml.ws.handler.MessageContext.INBOUND_MESSAGE_ATTACHMENTS;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:19:
 error: package javax.xml.soap does not exist
[javac] import static javax.xml.soap.SOAPConstants.SOAP_1_2_PROTOCOL;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:19:
 error: static import only from classes and interfaces
[javac] import static javax.xml.soap.SOAPConstants.SOAP_1_2_PROTOCOL;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:20:
 error: package javax.xml.soap does not exist
[javac] import static javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:20:
 error: static import only from classes and interfaces
[javac] import static javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:21:
 error: package javax.xml.soap does not exist
[javac] import static javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:21:
 error: static import only from classes and interfaces
[javac] import static javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE;
[javac] ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:34:
 error: package javax.xml.soap does not exist
[javac] import javax.xml.soap.AttachmentPart;
[javac]  ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:35:
 error: package javax.xml.soap does not exist
[javac] import javax.xml.soap.MessageFactory;
[javac]  ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:36:
 error: package javax.xml.soap does not exist
[javac] import javax.xml.soap.SOAPBody;
[javac]  ^
[javac] 
/build/eclipselink-2.6.5/org/eclipse/persistence/internal/dbws/SOAPResponseWriter.java:37:
 error: package javax.xml.soap does not exist
[javac] import javax.xml.soap.SOAPException;
[java

Bug#889852: [Piuparts-devel] can't reproduce but I noticed this...

[Holger Levsen]

- Forwarded message from Andreas Beckmann  -

Date: Wed, 17 Oct 2018 00:09:05 +0200
From: Andreas Beckmann 
To: "piuparts-de...@lists.alioth.debian.org" 

Subject: Re: [Piuparts-devel] can't reproduce but I noticed this...
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 
Thunderbird/52.9.1
List-Id: Piuparts development list 

On 2018-10-16 22:18, Holger Levsen wrote:
> So I'm starting to believe this is a bug on piuparts.debian.org and in
> ca-certificates.
/etc/ca-certificates.conf seems to differ depending on being created by
a new installation or being created and updated via a series of
distupgrades.
Not sure if we really want to just ignore it or rather analyze it to
find the underlying cause.

Andreas

___
Piuparts-devel mailing list
piuparts-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/piuparts-devel

- End forwarded message -


signature.asc
Description: PGP signature

Bug#911192: RFP: node-cross-env -- Cross platform setting of environment scripts

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-cross-env
  Version : 553705c302
  Upstream Author : Kent C. Dodds
* URL : https://notabug.org/themusicgod1/cross-env
* License : MIT 
  Programming Lang: javascript
  Description : Cross platform setting of environment scripts

Run scripts that set and use environment variables across platforms 
There's a difference in how windows and POSIX commands utilize environment 
variables. With POSIX, you use: $ENV_VAR and on windows you use %ENV_VAR%.

cross-env makes it so you can have a single command without worrying about 
setting or using the environment variable properly for the platform. Just 
set it like you would if it's running on a POSIX system, and cross-env 
will take care of setting it properly.

node-cross-env is a dev-dependency of node-prettier ( #879665 ).

Bug#911191: wide-dhcpv6-client: patch adding support for a random interface id

[Christopher Martin]

Package: wide-dhcpv6-client
Version: 20080615-21
Severity: wishlist
Tags: patch, ipv6

Please find attached a patch that adds a new feature to
wide-dhcpv6-client, namely an option ("ifid-random") in the
prefix-interface section of dhcp6c.conf to generate a random interface
id on startup. This is useful if you wish to have the final 64 bits of
your IPv6 address change from time to time - a sort of very rough
equivalent of IPv6 Privacy Extensions. If you do not add "ifid-random"
to the config file, then nothing about the client's current behaviour
changes.

Note that if your prefix-interface section has both the current "ifid
X" option (where X is whatever number you want to manually assign as
your interface id) and the new "ifid-random" option, then the
interface id is randomized and "ifid X" is ignored.

Thanks,
Christopher Martin
--- a/cfparse.y
+++ b/cfparse.y
@@ -104,7 +104,7 @@
 
 %token INTERFACE IFNAME
 %token PROFILE PROFILENAME
-%token PREFIX_INTERFACE SLA_ID SLA_LEN IFID DUID_ID
+%token PREFIX_INTERFACE SLA_ID SLA_LEN IFID IFID_RAND DUID_ID
 %token ID_ASSOC IA_PD IAID IA_NA
 %token ADDRESS
 %token REQUEST SEND ALLOW PREFERENCE
@@ -1064,6 +1064,13 @@
 			l->num = (u_int64_t)$2;
 			$$ = l;
 		}
+	|	IFID_RAND EOS
+		{
+			struct cf_list *l;
+
+			MAKE_CFLIST(l, IFPARAM_IFID_RAND, NULL, NULL);
+			$$ = l;
+		}
 	;
 
 ianaconf_list:
--- a/cftoken.l
+++ b/cftoken.l
@@ -244,6 +244,7 @@
 sla-id { DECHO; return (SLA_ID); }
 sla-len { DECHO; return (SLA_LEN); }
 ifid { DECHO; return (IFID); }
+ifid-random { DECHO; return (IFID_RAND); }
 
 	/* duration */
 infinity { DECHO; return (INFINITY); }
--- a/config.c
+++ b/config.c
@@ -521,6 +521,15 @@
 			}
 			break;
 		case IFPARAM_IFID:
+			if (use_default_ifid) {
+for (i = sizeof(pif->ifid) - 1; i >= 0; i--)
+	pif->ifid[i] = (cfl->num >> 8*(sizeof(pif->ifid) - 1 - i)) & 0xff;
+use_default_ifid = 0;
+			}
+			break;
+		case IFPARAM_IFID_RAND:
+			for (i = 0; i < pif->ifid_len ; i++)
+cfl->num = cfl->num*2 + rand()%2;
 			for (i = sizeof(pif->ifid) -1; i >= 0; i--)
 pif->ifid[i] = (cfl->num >> 8*(sizeof(pif->ifid) - 1 - i)) & 0xff;
 			use_default_ifid = 0;
--- a/config.h
+++ b/config.h
@@ -266,7 +266,7 @@
DECL_PREFIX, DECL_PREFERENCE, DECL_SCRIPT, DECL_DELAYEDKEY,
DECL_ADDRESS,
DECL_RANGE, DECL_ADDRESSPOOL,
-   IFPARAM_SLA_ID, IFPARAM_SLA_LEN, IFPARAM_IFID,
+   IFPARAM_SLA_ID, IFPARAM_SLA_LEN, IFPARAM_IFID, IFPARAM_IFID_RAND,
DHCPOPT_RAPID_COMMIT, DHCPOPT_AUTHINFO,
DHCPOPT_DNS, DHCPOPT_DNSNAME,
DHCPOPT_IA_PD, DHCPOPT_IA_NA, DHCPOPT_NTP,
--- a/dhcp6c.conf.5
+++ b/dhcp6c.conf.5
@@ -453,6 +453,15 @@
 prefix and the sla-id to form a complete interface address.  The
 default is to use the EUI-64 address of the
 .Ar interface .
+.It Xo
+.Ic ifid-random ;
+.Xc
+This statement instructs the client to generate a completely random
+interface id. This will override the
+.Ic ifid
+statement, if present. The resulting random interface id will be combined
+with the delegated prefix and the sla-id to form a complete interface
+address.
 .El
 .El
 .\"

Bug#911190: openjpa: FTBFS with Java 11 due to JAXB removal

[Emmanuel Bourg]

Source: openjpa
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

openjpa fails to build with Java 11 due to the removal of JAXB:

  [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) 
on project openjpa-jdbc: Compilation failure: Compilation failure:
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[25,22]
 package javax.xml.bind does not exist
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[26,22]
 package javax.xml.bind does not exist
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[27,22]
 package javax.xml.bind does not exist
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[28,22]
 package javax.xml.bind does not exist
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[78,13]
 cannot find symbol
  [ERROR]   symbol:   class JAXBContext
  [ERROR]   location: class org.apache.openjpa.jdbc.meta.strats.XMLValueHandler
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[78,30]
 cannot find symbol
  [ERROR]   symbol:   variable JAXBContext
  [ERROR]   location: class org.apache.openjpa.jdbc.meta.strats.XMLValueHandler
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[84,13]
 cannot find symbol
  [ERROR]   symbol:   class Marshaller
  [ERROR]   location: class org.apache.openjpa.jdbc.meta.strats.XMLValueHandler
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[91,16]
 cannot find symbol
  [ERROR]   symbol:   class JAXBException
  [ERROR]   location: class org.apache.openjpa.jdbc.meta.strats.XMLValueHandler
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[107,13]
 cannot find symbol
  [ERROR]   symbol:   class JAXBContext
  [ERROR]   location: class org.apache.openjpa.jdbc.meta.strats.XMLValueHandler
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[107,30]
 cannot find symbol
  [ERROR]   symbol:   variable JAXBContext
  [ERROR]   location: class org.apache.openjpa.jdbc.meta.strats.XMLValueHandler
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[108,13]
 cannot find symbol
  [ERROR]   symbol:   class Unmarshaller
  [ERROR]   location: class org.apache.openjpa.jdbc.meta.strats.XMLValueHandler
  [ERROR] 
/build/openjpa-2.4.2/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/XMLValueHandler.java:[112,16]
 cannot find symbol
  [ERROR]   symbol:   class JAXBException
  [ERROR]   location: class org.apache.openjpa.jdbc.meta.strats.XMLValueHandler

Bug#911189: src:gpgme1.0: please ship gpgme-json with native messaging hooks for chromium and firefox

[Daniel Kahn Gillmor]

Package: src:gpgme1.0
Version: 1.12.0-1
Severity: wishlist

as of gpgme 1.12.0-1, GPGME ships a javascript binding that works with
so-called "Native Messaging" in both chrome and firefox.

we should ship this as a separate binary package, along with the
appropriate extension manifests.

for more details, see lang/js/README in the GPGME sources, and the
following web references:

  Firefox:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_manifests

  Chrome:
https://developer.chrome.com/extensions/nativeMessaging

I plan to work on this, but if anyone wants to send patches before i
get to it, i'd be happy to get them too :)

at the moment, i assume that we just would disallow access to any
extensions, until some extension shows up that wants to use it.

We probably also need to build gpgme.js, which will require working
with node.

i don't know how we'll get the test suites to run cleanly yet either.

--dkg

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

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

Bug#911188: libjdo-api-java: FTBFS with Java 11 due to javax.rmi removal

[Emmanuel Bourg]

Package: src:libjdo-api-java
Version: 3.1-2
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

libjdo-api-java fails to build with Java 11, it's affected by the removal
of the CORBA related classes which include the javax.rmi package:

  [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) 
on project jdo-api: Compilation failure: Compilation failure:
  [ERROR] 
/build/libjdo-api-java-3.1/api/src/java/javax/jdo/JDOHelper.java:[58,16] error: 
package javax.rmi does not exist
  [ERROR] 
/build/libjdo-api-java-3.1/api/src/java/javax/jdo/JDOHelper.java:[1785,47] 
error: cannot find symbol
  [ERROR]   symbol:   variable PortableRemoteObject
  [ERROR]   location: class JDOHelper

Bug#911167: GTK2 support will reach EOL in Debian in the near future (Was: Bug#911167: gwyddion: Depend on gtksourceview2)

[Yeti]

On Tue, Oct 16, 2018 at 10:18:59PM +0200, Andreas Tille wrote:
> Hi David and Petr,
> 
> as you can see below, we can not ship gwyddion - at least not in its
> current form with GUI if it will stick to GTK-2+ toolkit.  Do you
> see any chance to port it to GTK-3+?

There is no way to port to GTK+3 without breaking backward
compatibility.  We value backward compatibility.

Some time not that long ago Debian was *the* distribution which supported
the widest range of software.  Now you are removing GTK+2 when Fedora
still offers GTK+1?

This is bat shit crazy.  There will be probably GTK+5 released before we
would be able to port to GTK+3.  GTK+2 is *the* *stable* *version*.  No
one who does actual software development can afford to spend 3/4 of time
and effort constantly porting to some new GTK+ nonsense and deal with
neverending deprecations.

If Debian does not support GTK+2 we will have to tell users to avoid it.

Regards,

Yeti

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Jonathan Nieder]

Andreas Henriksson wrote:

> It seems obvious to me that the above policy snippet was written in a
> time when the universe revolved around sysvinit. In current day and age
> sysvinit itself would be an "Alternate init system". We could update the
> snippet to say that any package providing support for an alternate init
> system must also provide systemd units if we wanted to modernize this
> part of policy.

I don't follow: why would we need such a requirement, given that
systemd knows how to execute init scripts?

Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[Werner Koch]

On Tue, 16 Oct 2018 09:51, s...@debian.org said:

> However, none of this solves co-installability in Debian:
> libgpg-error-dev:amd64 and libgpg-error-dev:armhf can't be
> installed at the same time, because they have different content in
> /usr/bin/gpg-error-config, and that will be a problem for as long as

/usr/bin/gpg-error-config should only be used for native building.  For
cross-building it is expected that a dedicated gpg-error-config script
is installed in the root directory of the host platform (e.g. as
/usr/i686-w64-mingw32/bin/gpg-error-config) and only that
gpg-error-config should ever be considered.  In past this required
manual configuration but meanwhile SYSROOT seems to be an accepted
standard and we can make use of it.  This means to only look there for
the config script to get the right version and not take whatever we find
and only print a warning if the platform is wrong.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp3e0bdhz6hy.pgp
Description: PGP signature

Bug#911187: axis: FTBFS with Java 11 due to javax.rmi and CORBA removal

[Emmanuel Bourg]

Source: axis
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

axis fails to build with Java 11 due to the removal of the javax.rmi
and org.omg.CORBA packages:


  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:25: 
error: package org.omg.CORBA does not exist
  [javac] import org.omg.CORBA.ORB;
  [javac] ^
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:26: 
error: package org.omg.CosNaming does not exist
  [javac] import org.omg.CosNaming.NameComponent;
  [javac] ^
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:27: 
error: package org.omg.CosNaming does not exist
  [javac] import org.omg.CosNaming.NamingContext;
  [javac] ^
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:28: 
error: package org.omg.CosNaming does not exist
  [javac] import org.omg.CosNaming.NamingContextHelper;
  [javac] ^
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:85: 
error: cannot find symbol
  [javac] ORB orb = ORB.init(new String[0], orbProps);
  [javac] ^
  [javac]   symbol:   class ORB
  [javac]   location: class CORBAProvider
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:85: 
error: cannot find symbol
  [javac] ORB orb = ORB.init(new String[0], orbProps);
  [javac]   ^
  [javac]   symbol:   variable ORB
  [javac]   location: class CORBAProvider
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:88: 
error: cannot find symbol
  [javac] NamingContext root = 
NamingContextHelper.narrow(orb.resolve_initial_references("NameService"));
  [javac] ^
  [javac]   symbol:   class NamingContext
  [javac]   location: class CORBAProvider
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:88: 
error: cannot find symbol
  [javac] NamingContext root = 
NamingContextHelper.narrow(orb.resolve_initial_references("NameService"));
  [javac]  ^
  [javac]   symbol:   variable NamingContextHelper
  [javac]   location: class CORBAProvider
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:89: 
error: cannot find symbol
  [javac] NameComponent nc = new NameComponent(nameId, nameKind);
  [javac] ^
  [javac]   symbol:   class NameComponent
  [javac]   location: class CORBAProvider
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:89: 
error: cannot find symbol
  [javac] NameComponent nc = new NameComponent(nameId, nameKind);
  [javac]^
  [javac]   symbol:   class NameComponent
  [javac]   location: class CORBAProvider
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:90: 
error: cannot find symbol
  [javac] NameComponent[] ncs = {nc};
  [javac] ^
  [javac]   symbol:   class NameComponent
  [javac]   location: class CORBAProvider
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:91: 
error: package org.omg.CORBA does not exist
  [javac] org.omg.CORBA.Object corbaObject = root.resolve(ncs);
  [javac]  ^
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/CORBAProvider.java:101: 
error: package org.omg.CORBA does not exist
  [javac] private static final Class[] CORBA_OBJECT_CLASS = new Class[] 
{org.omg.CORBA.Object.class};
  [javac]   
  ^
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/EJBProvider.java:129: error: 
package javax.rmi does not exist
  [javac] Object ehome = javax.rmi.PortableRemoteObject.narrow(ejbHome, 
homeClass);
  [javac] ^
  [javac] 
/build/axis-1.4/src/org/apache/axis/providers/java/EJBProvider.java:254: error: 
package javax.rmi does not exist
  [javac] Object ehome = javax.rmi.PortableRemoteObject.narrow(ejbHome, 
homeClass);
  [javac] ^

Bug#834298: nis: problem appears to be in invocation in /etc/init.d/nis

[Joe Pfeiffer]

Package: nis
Version: 3.17.1-3+b1
Followup-For: Bug #834298

The problem appears to be in line 172 of /etc/init.d/nis:
--exec ${NET}/ypbind -- $broadcast ${YPBINDARGS}

If I execute this by hand (for my environment, which does not use
-broadcast and has empty YPBINDARGS), ie

/usr/sbin/ypbind --

I get the response

babs:~# ypbind --
Usage:
ypbind [-broadcast | -ypset | -ypsetme] [-f configfile]
  [-no-ping] [-broken-server] [-local-only] [-i ping-interval]
  [-r rebind-interval] [-debug] [-verbose] [-n | -foreground]
ypbind -c [-f configfile]
ypbind --version

If I delete the -- from the invocation it works.

Bug#911186: stretch-pu: package clamav/0.100.1+dfsg-0+deb9u1

[Sebastian Andrzej Siewior]

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

clamav upstream published a new version which contains security relevant
bug fixes, one of them has CVE-2018-15378 assigned.

We have 0.100.2 in unstable since last week and this Stretch version
runs on one of my servers.

Attaching a debdiff with the docs/ folder filtered out.

Sebastian
diff -Nru clamav-0.100.1+dfsg/clamd/clamd.c clamav-0.100.2+dfsg/clamd/clamd.c
--- clamav-0.100.1+dfsg/clamd/clamd.c   2018-06-27 21:12:10.0 +0200
+++ clamav-0.100.2+dfsg/clamd/clamd.c   2018-09-19 21:29:07.0 +0200
@@ -370,6 +370,15 @@
 break;
 }
 
+/* TODO: Re-enable OnAccessExtraScanning once the thread resource 
consumption issue is resolved. */
+if(optget(opts, "OnAccessExtraScanning")->enabled) {
+logg("*ScanOnAccess: OnAccessExtraScanning was requested, but has "
+ "been disabled due to a known issue with thread resource "
+ "cleanup. The OnAccessExtraScanning feature will be "
+ "re-enabled in a future release when the issue is resolved. "
+ "For details, see: 
https://bugzilla.clamav.net/show_bug.cgi?id=12048\n";);
+}
+
 if(!(engine = cl_engine_new())) {
 logg("!Can't initialize antivirus engine\n");
 ret = 1;
diff -Nru clamav-0.100.1+dfsg/clamd/onaccess_ddd.c 
clamav-0.100.2+dfsg/clamd/onaccess_ddd.c
--- clamav-0.100.1+dfsg/clamd/onaccess_ddd.c2018-06-27 21:12:10.0 
+0200
+++ clamav-0.100.2+dfsg/clamd/onaccess_ddd.c2018-09-19 21:29:07.0 
+0200
@@ -385,9 +385,12 @@
}
}
 
+   /* TODO: Re-enable OnAccessExtraScanning once the thread resource 
consumption issue is resolved. */
+#if 0
if(optget(tharg->opts, "OnAccessExtraScanning")->enabled) {
logg("ScanOnAccess: Extra scanning and notifications 
enabled.\n");
-   }
+}
+   #endif
 
 
FD_ZERO(&rfds);
@@ -476,6 +479,9 @@
const char *path, const char *child_path, const struct 
inotify_event *event, int wd, uint64_t in_mask) {
 
struct stat s;
+
+   /* TODO: Re-enable OnAccessExtraScanning once the thread resource 
consumption issue is resolved. */
+#if 0
if (optget(tharg->opts, "OnAccessExtraScanning")->enabled) {
if(stat(child_path, &s) == 0 && S_ISREG(s.st_mode)) {
onas_ddd_handle_extra_scanning(tharg, child_path, 
ONAS_SCTH_ISFILE);
@@ -487,8 +493,10 @@
 
onas_ddd_handle_extra_scanning(tharg, child_path, 
ONAS_SCTH_ISDIR);
}
-   } else {
-
+   }
+   else
+#endif
+   {
if(stat(child_path, &s) == 0 && S_ISREG(s.st_mode)) return;
if(!(event->mask & IN_ISDIR)) return;
 
@@ -504,6 +512,8 @@
const char *path, const char *child_path, const struct 
inotify_event *event, int wd, uint64_t in_mask) {
 
struct stat s;
+   /* TODO: Re-enable OnAccessExtraScanning once the thread resource 
consumption issue is resolved. */
+#if 0
if (optget(tharg->opts, "OnAccessExtraScanning")->enabled) {
if(stat(child_path, &s) == 0 && S_ISREG(s.st_mode)) {
onas_ddd_handle_extra_scanning(tharg, child_path, 
ONAS_SCTH_ISFILE);
@@ -515,7 +525,10 @@
 
onas_ddd_handle_extra_scanning(tharg, child_path, 
ONAS_SCTH_ISDIR);
}
-   } else {
+   }
+   else
+#endif
+   {
if(stat(child_path, &s) == 0 && S_ISREG(s.st_mode)) return;
if(!(event->mask & IN_ISDIR)) return;
 
diff -Nru clamav-0.100.1+dfsg/clamd/onaccess_fan.c 
clamav-0.100.2+dfsg/clamd/onaccess_fan.c
--- clamav-0.100.1+dfsg/clamd/onaccess_fan.c2018-06-27 21:12:10.0 
+0200
+++ clamav-0.100.2+dfsg/clamd/onaccess_fan.c2018-09-19 21:29:07.0 
+0200
@@ -252,9 +252,14 @@
 
if((check = onas_fan_checkowner(fmd->pid, tharg->opts))) {
scan = 0;
-   if (check != CHK_SELF || !(optget(tharg->opts, 
"OnAccessExtraScanning")->enabled)) {
-   logg("*ScanOnAccess: %s skipped (excluded UID)\n", 
fname);
-}
+   /* TODO: Re-enable OnAccessExtraScanning once the thread resource 
consumption issue is resolved. */
+   #if 0
+   if ((check != CHK_SELF) || !(optget(tharg->opts, 
"OnAccessExtraScanning")->enabled)) {
+   #else
+   if (check != CHK_SELF) {
+   #endif
+   logg("*ScanOnAccess: %s skipped (excluded 
UID)\n", fname);
+   }
}
 
if(sizelimit) {
diff -Nru clamav-0.100.1+dfsg/configure clamav-0.100.2+dfsg/configure
--- clamav-0.100.1+dfsg/configure   2018-06-27 21:12:10.0 +0200
+++ clamav-0.100.2+dfsg/configure  

Bug#911185: commit hash not found in translation-check header breaks the wml build

[Laura Arjona Reina]

Package: www.debian.org
Severity: wishlist

Dear all
When there is a mistake in the hash of the translation-check header in a
wml file, the build fails. Here's an example when doing "make" with a
wml file with a translation-check header containing "test" instead of
the git hash:

wml -q -D CUR_YEAR=2018 -o UNDEFuES:index.es.html@g+w   index.wml
ePerl:Error: Perl runtime error (interpreter rc=0)

 Contents of STDERR channel: -
count_changes() ERROR: commit rev1 test not found in revisions of
../..//english/reports/index.wml
--
** WML:Break: Error in Pass 3 (rc=1).
../../Makefile.common:119: recipe for target 'index.es.html' failed

I wonder if we'd like that instead of failing, the script would handle
this issue and build the page using the tag "originalolder" (then, the
translated file would be available, with a warning "Wrong translation
version!").

I'm attaching a patch that generates this behavior, but I have some
concerns:

* I'm not sure if we should change all the occurrences in the code where
a commit is not found from failure to this behaviour (see the diff, 4
occurrences)
* I'm not sure if we want that, or we prefer that the build fails and
make the CI not ignore these errors (then I guess the person committing
the file with wrong translation hash would get a mail, and hopefully fix
the file. If the page is built, maybe these kind of issues pass by
unnoticed).

Comments?

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
diff --git a/Perl/Local/VCS_git.pm b/Perl/Local/VCS_git.pm
index 9c76c0ba969..6f065f290a3 100644
--- a/Perl/Local/VCS_git.pm
+++ b/Perl/Local/VCS_git.pm
@@ -467,12 +467,12 @@ sub cmp_rev
 	}
 	if ($pos1 == -1) {
 	# Not found
-	print STDERR "ERROR: commit rev1 $rev1 not found in revisions of $file\n";
-	$ret = undef;
+	$self->_debug("WARNING: commit rev1 $rev1 not found in revisions of $file\n");
+	$ret = -1;
 	} elsif ($pos2 == -1) {
 	# Not found
-	print STDERR "ERROR: commit rev2 $rev2 not found in revisions of $file\n";
-	$ret = undef;
+	$self->_debug("WARNING: commit rev2 $rev2 not found in revisions of $file\n");
+	$ret = -1;
 	} elsif ($pos1 == $pos2) {
 	$ret = 0;
 	} elsif ($pos1 < $pos2) {
@@ -562,12 +562,12 @@ sub count_changes
 	}
 	if ($pos1 == -1) {
 	# Not found
-	print STDERR "count_changes() ERROR: commit rev1 $rev1 not found in revisions of $file\n";
-	$ret = undef;
+	$self->_debug("count_changes() WARNING: commit rev1 $rev1 not found in revisions of $file\n");
+	$ret = -1;
 	} elsif ($pos2 == -1) {
 	# Not found
-	print STDERR "count_changes() ERROR: commit rev2 $rev2 not found in revisions of $file\n";
-	$ret = undef;
+	$self->_debug("count_changes() WARNING: commit rev2 $rev2 not found in revisions of $file\n");
+	$ret = -1;
 	} else {
 	$ret = $pos1 - $pos2;
 	}

Bug#909788: rng-tools5: Missing init script

[Carsten Leonhardt]

Control: severity -1 serious
Control: tags -1 + patch

Not shipping init scripts equivalent to the service files violates
policy 9.11, therefore the bug severity is serious.

I've now attached a patch.

diff -Nur rng-tools5-5/debian/changelog rng-tools5-5-patched/debian/changelog
--- rng-tools5-5/debian/changelog	2018-10-16 23:41:15.0 +0200
+++ rng-tools5-5-patched/debian/changelog	2018-10-16 23:47:35.85600 +0200
@@ -1,3 +1,10 @@
+rng-tools5 (5-4) unstable; urgency=low
+
+  [Carsten Leonhardt]
+  * Add init script. (Closes: #909788)
+
+ -- Carsten Leonhardt   Tue, 16 Oct 2018 23:45:50 +0200
+
 rng-tools5 (5-3) unstable; urgency=low
 
   * adds check so the daemon exits properly after receiving a
diff -Nur rng-tools5-5/debian/rngd.init rng-tools5-5-patched/debian/rngd.init
--- rng-tools5-5/debian/rngd.init	1970-01-01 01:00:00.0 +0100
+++ rng-tools5-5-patched/debian/rngd.init	2018-10-16 23:41:52.27200 +0200
@@ -0,0 +1,21 @@
+#!/bin/sh
+# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
+if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
+set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
+fi
+### BEGIN INIT INFO
+# Provides:  rngd
+# Required-Start:$remote_fs $syslog
+# Required-Stop: $remote_fs $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop:  0 1 6
+# Short-Description: entropy gathering daemon (rngd)
+# Description:   Check and feed random data from hardware device
+#to kernel random device
+
+### END INIT INFO
+
+# Author: Carsten Leonhardt 
+
+DESC="entropy gathering daemon"
+DAEMON=/usr/sbin/rngd

Bug#911184: wicd-daemon: Please make log file location configurable

[Dmitry Bogatov]

Package: wicd-daemon
Version: 1.7.4+tb2-6
Severity: wishlist

Dear Maintainer,

please make log file location configurable at run time. I am working on
integrating wicd-daemon with Runit supervision system, which assumes
logging on stdout.

In most cases, daemons have option to specify log file location, and
providing /dev/stdout fulfils my needs. Wicd, on other hand have path
to log file hardcoded in setup.py. Please, add a bit of flexibility.

Bug#911183: logback: FTBFS with Java 11 due to sun.reflect.Reflection removal

[Emmanuel Bourg]

Source: logback
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

logback fails to build with Java due to the removal of the sun.reflect package:

  [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) 
on project logback-classic: Compilation failure: Compilation failure:
  [ERROR] 
/build/logback-1.2.3/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java:[20,19]
 cannot find symbol
  [ERROR]   symbol:   class Reflection
  [ERROR]   location: package sun.reflect
  [ERROR] 
/build/logback-1.2.3/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java:[45,13]
 cannot find symbol
  [ERROR]   symbol:   variable Reflection
  [ERROR]   location: class ch.qos.logback.classic.spi.PackagingDataCalculator
  [ERROR] 
/build/logback-1.2.3/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java:[85,31]
 cannot find symbol
  [ERROR]   symbol:   variable Reflection
  [ERROR]   location: class ch.qos.logback.classic.spi.PackagingDataCalculator

Bug#911182: libquartz-java: FTBFS with Java 11 due to javax.rmi removal

[Emmanuel Bourg]

Package: src:libquartz-java
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

libquartz-java fails to build with Java 11, it's affected by the removal
of the CORBA related classes which include the javax.rmi package:

  [INFO] -
  [ERROR] COMPILATION ERROR :
  [INFO] -
  [ERROR] 
/build/libquartz-java-1.8.6/quartz/src/main/java/org/quartz/jobs/ee/ejb/EJBInvokerJob.java:[31,17]
 package javax.rmi does not exist
  [ERROR] 
/build/libquartz-java-1.8.6/quartz/src/main/java/org/quartz/jobs/ee/ejb/EJBInvokerJob.java:[163,41]
 cannot find symbol
symbol:   variable PortableRemoteObject
location: class org.quartz.jobs.ee.ejb.EJBInvokerJob
  [ERROR] 
/build/libquartz-java-1.8.6/quartz/src/main/java/org/quartz/jobs/ee/ejb/EJBInvokerJob.java:[182,33]
 cannot find symbol
symbol:   variable PortableRemoteObject
location: class org.quartz.jobs.ee.ejb.EJBInvokerJob

Bug#826994: Missing init-script(s)?

[Carsten Leonhardt]

Control: severity -1 serious

Not shipping init scripts equivalent to the service files violates
policy 9.11, therefore the bug severity is serious.

Bug#911157: lintian: complain about grepping the passwd/group file instead of using getent

[Rhonda D'Vine]

* Chris Lamb  [2018-10-16 17:05:17 CEST]:
> Dear Rhonda,
> 
> Thank you for filing this.

 Sure, no worries. :)

> > https://sources.debian.org/src/proftpd-dfsg/1.3.5d-1/debian/proftpd-basic.postinst/?hl=28#L28
> > is an example from our pool, but there are more.
> 
> This example:
> 
>   https://github.com/FRRouting/frr/blob/master/debianpkg/frr.postinst#L4-L9
> 
> … is also relevant but may not be as-reliably detectable.

 It's nice that you come to the same conclusion about the same code
snippet that I mentioned in my original mail, let me quote myself. :)

,> original bugreport <
|  The package where I stumbled upon this had the code a bit more complex,
| I'm unsure how this might be detectable:
| 
| #v+
| PASSWDFILE=/etc/passwd
| GROUPFILE=/etc/group
| 
| frruid=`egrep "^frr:" $PASSWDFILE | awk -F ":" '{ print $3 }'`
| frrgid=`egrep "^frr:" $GROUPFILE | awk -F ":" '{ print $3 }'`
| frrvtygid=`egrep "^frrvty:" $GROUPFILE | awk -F ":" '{ print $3 }'`
| #v-
`> original bugreport <

 So, yes, we seem to agree on that. :)

> However, to
> quote IRC:
> 
>   * h01ger agrees that any reference to /etc/passwd or /etc/group is
> very probably a bug

 Right, though some packages (shadow comes to mind?) might refer to it
with good reasons.  But I'm sure you can check that in lintian labs for
false positives.

 When I look into
https://salsa.debian.org/lintian/lintian/commit/8cbfd096b0 though:

~\b(grep\b.*/etc/(?:passwd|group))\b

 I'm not completely sure about the syntax here, but the \b before the
bracket looks like it wouldn't catch egrep - which is used in the above
example (although it's using a variable instead of the filename so it
wouldn't catch it anyway - but if it would use the filename ... would
that match?

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#910465: makedumpfile: [INTL:pt] Updated Portuguese translation - debconf messages

[Thadeu Lima de Souza Cascardo]

On Sat, Oct 06, 2018 at 06:16:49PM +0100, Américo Monteiro wrote:
> Package: makedumpfile
> Version: 1_1.6.4-2
> Tags: l10n, patch
> Severity: wishlist
> 
> Updated Portuguese translation for makedumpfile's debconf messages
> Translator: Américo Monteiro 
> Feel free to use it.
> 
> For translation updates please contact 'Last Translator' 
> 
> -- 
> Melhores cumprimentos/Best regards,
> 
> Américo Monteiro
> 
> -

Hi, Américo.

There is already an updated translation from Rui Branco. I don't see
anything wrong with it. Though I am a native Portuguese speaker as well,
I defer to you both to decide whether any update is needed.

Thanks.
Cascardo.


signature.asc
Description: PGP signature

Bug#910542: better support for OCaml object files via ocamlobjinfo

[Chris Lamb]

tags 910542 + pending
thanks

Thanks for the report. I've implemented this in Git, now pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/bc92ac311960b43abd1067df83ddee1729dc38bd

  debian/control |   1 +
  diffoscope/comparators/__init__.py |   1 +
  diffoscope/comparators/ocaml.py|  51 +++
  diffoscope/external_tools.py   |   3 +++
  tests/comparators/test_ocaml.py|  54 +
  tests/data/ocaml_expected_diff |  15 +++
  tests/data/test1.cmi   | Bin 0 -> 1126 bytes
  tests/data/test2.cmi   | Bin 0 -> 11486 bytes
  8 files changed, 125 insertions(+)


Regards,

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

Bug#911181: sitemesh: FTBFS with Java 11 due to javax.rmi removal

[Emmanuel Bourg]

Source: sitemesh
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

sitemesh fails to build with Java 11, it's affected by the removal of the CORBA
related classes which include the javax.rmi package:

[javac] 
/build/sitemesh-2.4.1+dfsg/src/java/com/opensymphony/module/sitemesh/Factory.java:17:
 error: package javax.rmi does not exist
[javac] import javax.rmi.PortableRemoteObject;
[javac] ^
[javac] 
/build/sitemesh-2.4.1+dfsg/src/java/com/opensymphony/module/sitemesh/Factory.java:94:
 error: cannot find symbol
[javac] result = (String)PortableRemoteObject.narrow(o, 
String.class); // rmi-iiop friendly.
[javac]  ^
[javac]   symbol:   variable PortableRemoteObject
[javac]   location: class Factory

Bug#911020: installation-guide: Comments on section D.3

[Holger Wansing]

Hi,

Brian Potkin  wrote:
> Please have a look at
> 
>   https://lists.debian.org/debian-user/2018/10/msg00438.html
> 
> and its followup
> 
>   https://lists.debian.org/debian-user/2018/10/msg00448.html
> 
> Could changes to advice for /e/n/i and /etc/hosts be considered?

Getting some sort of a patch for this would speed up the process ...


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#911179: Qt5 packages uninstallable in Sid

[scozatigheratten]

Can confirm the issue.

This is a serious problem and renders virtually ANY package that depends on Qt 
uninstallable,
including KDE, VLC, LXQt and other major ones...

Please fix as soon as possible.

Bug#911176: [Pkg-sysvinit-devel] Bug#911176: upgrade loops indefinitely

[Petter Reinholdtsen]

[Ian Jackson]
> Even so, surely insserv shouldn't just spin.  It should break the
> cycle (perhaps badly) and be able to carry on.

It isn't spinning.  It is called via update-rc.d from several postinst
scripts, and report the problem every time.  There is no way to know
where to sensible break the cycle, so it was decided early to reject
installation of packages introducing a cycle, to force people to address
the issue right away while the machine is still running instead of
risking a non-booting system to surprise the user on the next boot.

The initial report just show a lot of packages being installed, not a
loop.

Sure, one could try to break the cycle, but the end result might be to
brick the machine.

Could this be caused by a removed but non-purged package with an broken
init.d script?  I've seen quite a few of those.

-- 
Happy hacking
Petter Reinholdtsen

Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: freeradius: freeradius refuses to start - missing libs

[Michael Stapelberg]

control: reassign -1 freeradius-dhcp
control: severity -1 important

(Downgrading severity because this only affects installations which have
the optional freeradius-dhcp package installed and enabled.)

Dimitri, this is a result of your change
https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919.
Could you revert it for the time being, and, if you chose to go forward
with a fix, outline the rationale? The commit only describes the what, not
the why. Specifically, in which way was the rpath “bogus”?

Also, while at it, could you please ensure that
https://salsa.debian.org/freeradius-team/freeradius is in sync with what’s
in the archive? Your NMU is not reflected in the changelog, for example :-/

Thanks!

On Tue, Oct 16, 2018 at 10:09 PM Kamil Jonca  wrote:

> Package: freeradius
> Version: 3.0.16+dfsg-4.1+b1
> Severity: grave
> Justification: renders package unusable
>
> After upgrade, freeradius refuses to start.
> In its log we can see:
>
> Tue Oct 16 21:59:52 2018 : Error:
> /etc/freeradius/3.0/mods-enabled/dhcp[18]: Failed to link to module
> 'rlm_dhcp': libfreeradius-dhcp.so: cannot open shared object file: No such
> file or directory
>
> bug is mysterious because:
> [from /etc/freeradius/3.0/radiusd.conf]
> libdir = /usr/lib/freeradius/
>
> #ls -la /usr/lib/freeradius/rlm_dhcp*
> -rw-r--r-- 1 root root 14344 Oct 13 06:49 /usr/lib/freeradius/rlm_dhcp.so
>
>
> moreover (I do not know if it is important)
> #ldd /usr/lib/freeradius/rlm_dhcp.so
> linux-vdso.so.1 (0x7fff15dcc000)
> libfreeradius-dhcp.so => not found
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4c96b7a000)
> /lib64/ld-linux-x86-64.so.2 (0x7f4c96d78000)
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8),
> LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages freeradius depends on:
> ii  freeradius-common  3.0.16+dfsg-4.1
> ii  freeradius-config  3.0.16+dfsg-4.1+b1
> ii  libc6  2.27-6
> ii  libcap21:2.25-1.2
> ii  libct4 1.00.82-2+b1
> ii  libfreeradius3 3.0.16+dfsg-4.1+b1
> ii  libgdbm6   1.18-2
> ii  libpam0g   1.1.8-3.8
> ii  libpcre3   2:8.39-11
> ii  libperl5.265.26.2-7+b1
> ii  libreadline7   7.0-5
> ii  libsqlite3-0   3.25.2-1
> ii  libssl1.1  1.1.1-1
> ii  libtalloc2 2.1.14-1
> ii  libwbclient0   2:4.8.5+dfsg-1
> ii  lsb-base   9.20170808
>
> Versions of packages freeradius recommends:
> ii  freeradius-utils  3.0.16+dfsg-4.1+b1
>
> Versions of packages freeradius suggests:
> pn  freeradius-krb5
> ih  freeradius-ldap3.0.16+dfsg-4.1+b1
> pn  freeradius-mysql   
> ih  freeradius-postgresql  3.0.16+dfsg-4.1+b1
> pn  freeradius-python2 
> ii  snmp   5.7.3+dfsg-3
>
> -- Configuration Files:
> /etc/default/freeradius changed:
> FREERADIUS_OPTIONS="-xxx -l /var/log/freeradius/radius.log"
>
> /etc/logrotate.d/freeradius changed:
> /var/log/freeradius/*.log {
> weekly
> compress
> delaycompress
> notifempty
> missingok
> postrotate
> /etc/init.d/freeradius reload > /dev/null
> endscript
> }
>
>
> -- no debconf information
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael

Bug#911176: [Pkg-sysvinit-devel] Bug#911176: upgrade loops indefinitely

[Richard Kettlewell]

On 16/10/2018 21:10, Petter Reinholdtsen wrote:
> 
> Note, it is unlikely the problem is in initscripts.  It is more likely
> to be an incorrect dependency in one of the other init.d scripts
> involved.  When it is known which, I recommend to reassign this bug to
> the correct package.
> 
> I further recommend to have a look at the output from
> /usr/share/insserv/check-initd-order, and to wrap up the output from
> /usr/share/insserv/make-testsuite as an attachment to this bug to allow
> anyone to try to reproduce the problem.
richard@deodand:~$ /usr/share/insserv/check-initd-order
richard@deodand:~$ /usr/share/insserv/make-testsuite > mt.txt

mt.txt is attached.

ttfn/rjk
set +C
cat <<'EOF' > $insconf
$local_fs   +mountall +mountall-bootclean +mountoverflowtmp +umountfs
$network+networking +ifupdown
$named  +named +dnsmasq +lwresd +bind9 +unbound $network
$remote_fs  $local_fs +mountnfs +mountnfs-bootclean +umountnfs +sendsigs
$syslog +rsyslog +sysklogd +syslog-ng +dsyslog +inetutils-syslogd
$time   +hwclock
   glibc udev console-screen keymap keyboard-setup console-setup 
cryptdisks cryptdisks-early checkfs-loop
EOF
set -C

addscript anacron <<'EOF'
### BEGIN INIT INFO
# Provides:  anacron
# Required-Start:$remote_fs $syslog $time
# Required-Stop: $remote_fs $syslog $time
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Run anacron jobs
# Description: The first purpose of this script is to run anacron at
#  boot so that it can catch up with missed jobs.  Note
#  that anacron is not a daemon.  It is run here just once
#  and is later started by the real cron.  The second
#  purpose of this script is that said cron job invokes
#  this script to start anacron at those subsequent times,
#  to keep the logic in one place.
### END INIT INFO
EOF

addscript apache2 <<'EOF'
### BEGIN INIT INFO
# Provides:  apache2
# Required-Start:$local_fs $remote_fs $network $syslog $named
# Required-Stop: $local_fs $remote_fs $network $syslog $named
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# X-Interactive: true
# Short-Description: Apache2 web server
# Description:   Start the web server
#  This script will start the apache2 web server.
### END INIT INFO
EOF

addscript apache-htcacheclean <<'EOF'
### BEGIN INIT INFO
# Provides:  apache-htcacheclean
# Required-Start:$remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: Cache cleaner process for Apache2 web server
# Description:   Start the htcacheclean helper
#  This script will start htcacheclean which will periodically scan the
#  cache directory of Apache2's mod_cache_disk and remove outdated files.
### END INIT INFO
EOF

addscript atd <<'EOF'
### BEGIN INIT INFO
# Provides:  atd
# Required-Start:$syslog $time $remote_fs
# Required-Stop: $syslog $time $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: Deferred execution scheduler
# Description:   Debian init script for the atd deferred executions
#scheduler
### END INIT INFO
EOF

addscript binfmt-support <<'EOF'
### BEGIN INIT INFO
# Provides:  binfmt-support
# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Support for extra binary formats
# Description:   Enable support for extra binary formats using the Linux
#kernel's binfmt_misc facility.
### END INIT INFO
EOF

addscript bootlogs <<'EOF'
### BEGIN INIT INFO
# Provides:  bootlogs
# Required-Start:hostname $local_fs
# Required-Stop:
# Should-Start:  $x-display-manager gdm kdm xdm ldm sdm wdm nodm
# Default-Start: 1 2 3 4 5
# Default-Stop:
# Short-Description: Log file handling to be done during bootup.
# Description:   Various things that don't need to be done particularly
#early in the boot, just before getty is run.
### END INIT INFO
EOF

addscript bootmisc.sh <<'EOF'
### BEGIN INIT INFO
# Provides:  bootmisc
# Required-Start:$remote_fs
# Required-Stop:
# Should-Start:  udev
# Default-Start: S
# Default-Stop:
# Short-Description: Miscellaneous things to be done during bootup.
# Description:   Some cleanup.  Note, it need to run after 
mountnfs-bootclean.sh.
### END INIT INFO
EOF

addscript checkfs.sh <<'EOF'
### BEGIN INIT INFO
# Provides:  checkfs
# Required-Start:checkroot
# Required-Stop:
# Should-Start:
# Default-Start: S
# Default-Stop:
# X-Interactive: true
# Short-Description: Check all filesystems.
### END INIT INFO
EOF

addscript checkroot-bootclean.sh <<'EOF'
### BEGIN INIT INFO
# Provides:  checkroot-bootclean
# Required-Start:checkroot
# Required-Stop:
# Default-Start: S
# D

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Trek]

On Tue, 16 Oct 2018 22:26:40 +0200
Michael Biebl  wrote:

> > to Guilhem Moulin: I made a little patch because the socket
> > permissions seems to be wrong when --chuid is specified
> I think you meant Guillem (our dear dpkg maintainer) here?

yes, I'm sorry, please Guillem Jover can you check this patch?

ciao!>From 67d080cc7c195f1a34cb6a0dc7ac7a5d9dbad28d Mon Sep 17 00:00:00 2001
From: Trek 
Date: Tue, 16 Oct 2018 21:45:42 +0200
Subject: [PATCH] Set the proper permissions to s-s-d notify socket and
 directory

If the --chuid parameter is specified, the notify socket is not
accessible by the client, because mkdtemp() creates a directory owned
by root with 0700 permission. Moreover fchown() on a socket does not
have effects, because a socket doesn't have an associated inode.

Change the directory owner to runas_uid and use chown() instead of
fchown() to change the socket owner. Drop unneeded fchmod().
---
 utils/start-stop-daemon.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/utils/start-stop-daemon.c b/utils/start-stop-daemon.c
index 476b31b..5f14931 100644
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -548,6 +548,9 @@ setup_socket_name(const char *suffix)
 
 	atexit(cleanup_socket_dir);
 
+	if (chown(notify_sockdir, runas_uid, runas_gid))
+		fatal("cannot change socket directory ownership");
+
 	if (asprintf(¬ify_socket, "%s/notify", notify_sockdir) < 0)
 		fatal("cannot allocate socket name");
 
@@ -578,7 +581,7 @@ create_notify_socket(void)
 	if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) < 0)
 		fatal("cannot set close-on-exec flag for notification socket");
 
-	sockname = setup_socket_name(".s-s-d-notify");
+	sockname = setup_socket_name("start-stop-daemon");
 
 	/* Bind to a socket in a temporary directory, selected based on
 	 * the platform. */
@@ -590,12 +593,7 @@ create_notify_socket(void)
 	if (rc < 0)
 		fatal("cannot bind to notification socket");
 
-	rc = fchmod(fd, 0660);
-	if (rc < 0)
-		fatal("cannot change notification socket permissions");
-
-	rc = fchown(fd, runas_uid, runas_gid);
-	if (rc < 0)
+	if (chown(su.sun_path, runas_uid, runas_gid))
 		fatal("cannot change notification socket ownership");
 
 	// XXX: verify we are talking to an expected child?? not sure whether
@@ -1446,7 +1444,7 @@ parse_options(int argc, char * const *argv)
 		badusage("--remove-pidfile requires --pidfile");
 
 	if (pid_str && pidfile)
-		badusage("need either --pid of --pidfile, not both");
+		badusage("need either --pid or --pidfile, not both");
 
 	if (background && action != ACTION_START)
 		badusage("--background is only relevant with --start");
-- 
2.1.4

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 16.10.18 um 22:24 schrieb Trek:
> good job!
> 
> with cryptsetup the new patches are running fine
> 
> thank you to every one!
> 
> to Guilhem Moulin: I made a little patch because the socket permissions
> seems to be wrong when --chuid is specified
I think you meant Guillem (our dear dpkg maintainer) here?


-- 
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#908796: udev (with sysvinit) fails to find devices at boot

[Trek]

good job!

with cryptsetup the new patches are running fine

thank you to every one!

to Guilhem Moulin: I made a little patch because the socket permissions
seems to be wrong when --chuid is specified

ciao :)>From 67d080cc7c195f1a34cb6a0dc7ac7a5d9dbad28d Mon Sep 17 00:00:00 2001
From: Trek 
Date: Tue, 16 Oct 2018 21:45:42 +0200
Subject: [PATCH] Set the proper permissions to s-s-d notify socket and
 directory

If the --chuid parameter is specified, the notify socket is not
accessible by the client, because mkdtemp() creates a directory owned
by root with 0700 permission. Moreover fchown() on a socket does not
have effects, because a socket doesn't have an associated inode.

Change the directory owner to runas_uid and use chown() instead of
fchown() to change the socket owner. Drop unneeded fchmod().
---
 utils/start-stop-daemon.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/utils/start-stop-daemon.c b/utils/start-stop-daemon.c
index 476b31b..5f14931 100644
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -548,6 +548,9 @@ setup_socket_name(const char *suffix)
 
 	atexit(cleanup_socket_dir);
 
+	if (chown(notify_sockdir, runas_uid, runas_gid))
+		fatal("cannot change socket directory ownership");
+
 	if (asprintf(¬ify_socket, "%s/notify", notify_sockdir) < 0)
 		fatal("cannot allocate socket name");
 
@@ -578,7 +581,7 @@ create_notify_socket(void)
 	if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) < 0)
 		fatal("cannot set close-on-exec flag for notification socket");
 
-	sockname = setup_socket_name(".s-s-d-notify");
+	sockname = setup_socket_name("start-stop-daemon");
 
 	/* Bind to a socket in a temporary directory, selected based on
 	 * the platform. */
@@ -590,12 +593,7 @@ create_notify_socket(void)
 	if (rc < 0)
 		fatal("cannot bind to notification socket");
 
-	rc = fchmod(fd, 0660);
-	if (rc < 0)
-		fatal("cannot change notification socket permissions");
-
-	rc = fchown(fd, runas_uid, runas_gid);
-	if (rc < 0)
+	if (chown(su.sun_path, runas_uid, runas_gid))
 		fatal("cannot change notification socket ownership");
 
 	// XXX: verify we are talking to an expected child?? not sure whether
@@ -1446,7 +1444,7 @@ parse_options(int argc, char * const *argv)
 		badusage("--remove-pidfile requires --pidfile");
 
 	if (pid_str && pidfile)
-		badusage("need either --pid of --pidfile, not both");
+		badusage("need either --pid or --pidfile, not both");
 
 	if (background && action != ACTION_START)
 		badusage("--background is only relevant with --start");
-- 
2.1.4

Bug#909000: [Pkg-mozext-maintainers] Bug#909000: Thunderbird 60 cannot STILL be at stretch normal repository

[Daniel Kahn Gillmor]

On Tue 2018-10-16 12:05:33 +0200, Carsten Schoenert wrote:
> yes, the problem here is Enigmail, not Thunderbird! But I don't see that
> this as a vulnerability per se from a security perspective.
> And you still can install the Mozilla AddOns manually into FF and TB.
> It's a loosing of comfort and easy usage of the system provided
> packages, but not more for the typical single user cases on a machine or
> laptop.

fwiw, the version of enigmail that you get from the Mozilla addons store
has what i consider to be pretty serious problems:

 * it downloads and executes binaries from the web on behalf of the user
   (its "pEp" mode) without any form of verification beyond https
   certificate validation.

 * it contains a bundle of OpenPGP.js, which doesn't appear to be easily
   buildable (or modifiable) from source, so it's not free software in
   the sense that debian cares about.

I don't think we want to encourage people to do that.

> And happily dkg is taking this challenge really seriously!

Thanks for the vote of confidence, Carsten! :)

> And being not able to send automated encrypted email is not a
> vulnerability as you still can use gpg on the command line and encrypt
> your content obviously with less comfort, and it's your decision. And
> again, you can still install Enigmail from upstream. So hey, that's life.

fwiw, i don't consider encryption from the command line to be a
substitute for proper integration with your mail user agent.  If you do
that, you're also likely forcing your peers to do the same thing, and
it's really easy to screw it up on one side or the other.

So this situation really is a security issue for some people, who are
losing the capacity to send and receive encrypted e-mail.  There are
people who, if their mail is forced back into cleartext, run risks with
potential consequences ranging from loss of employment to loss of
liberty or even loss of life.

I really hope debian can get this sorted out for the next stable point
release at the latest.

thanks to everyone for their constructive help getting it done!

   --dkg


signature.asc
Description: PGP signature

Bug#911157: lintian: complain about grepping the passwd/group file instead of using getent

[Chris Lamb]

tags 911157 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/8cbfd096b018e384f905b198543aa90c107e22c6

  checks/scripts.desc   | 11 +++
  data/scripts/maintainer-script-bad-command|  1 +
  debian/changelog  |  2 ++
  t/tests/scripts-maintainer-general/debian/debian/postinst |  9 +
  t/tests/scripts-maintainer-general/desc   |  1 +
  t/tests/scripts-maintainer-general/tags   |  2 ++
  6 files changed, 26 insertions(+)


Regards,

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

Bug#911023: memory leak in the backlight control of the dell-laptop module

[Gabriele Mazzotta]

Hi,

there are a couple of commits queued for 4.19 that fix some memory
leaks: https://patchwork.kernel.org/patch/10594683/ and
https://patchwork.kernel.org/patch/10594681/. Looking at the call
trace I'd say the first patch is going to fix your issue.

They should both be included in the stable trees given the tag in
the commit.

Regards,
Gabriele

Bug#911167: GTK2 support will reach EOL in Debian in the near future (Was: Bug#911167: gwyddion: Depend on gtksourceview2)

[Andreas Tille]

Control: forwarded -1 David Necas , Petr Klapetek 

Control: tags -1 upstream

Hi David and Petr,

as you can see below, we can not ship gwyddion - at least not in its
current form with GUI if it will stick to GTK-2+ toolkit.  Do you
see any chance to port it to GTK-3+?

Kind regards

   Andreas.


On Tue, Oct 16, 2018 at 12:55:34PM -0400, Jeremy Bicha wrote:
> Source: gwyddion
> Version: 2.50-2
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs gtksourceview2
> Tags: sid buster
> Control: block 911166 by -1
> 
> gwyddion depends on gtksourceview2. The Debian GNOME team is
> trying to remove gtksourceview2 from Debian. Please port to gtk3 and
> gtksourceview4.
> 
> Because of the late timing of this RC bug in the Buster cycle and
> because there might be a few other packages that won't be ported in
> time, please let me know if you object to gtksourceview2's removal
> from Buster.
> 
> Thanks,
> Jeremy Bicha
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#911176: [Pkg-sysvinit-devel] Bug#911176: upgrade loops indefinitely

[Ian Jackson]

Petter Reinholdtsen writes ("Bug#911176: [Pkg-sysvinit-devel] Bug#911176: 
upgrade loops indefinitely"):
> 
> Note, it is unlikely the problem is in initscripts.  It is more likely
> to be an incorrect dependency in one of the other init.d scripts
> involved.  When it is known which, I recommend to reassign this bug to
> the correct package.

Even so, surely insserv shouldn't just spin.  It should break the
cycle (perhaps badly) and be able to carry on.

I've asked rjk on irc for a copy of the /etc/init.d, but:

> I further recommend to have a look at the output from
> /usr/share/insserv/check-initd-order, and to wrap up the output from
> /usr/share/insserv/make-testsuite as an attachment to this bug to allow
> anyone to try to reproduce the problem.

Cool, I didn't know about that.  Much better.

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#903698: sphinxbase: build appears broken for multiple python3 versions

[Samuel Thibault]

Samuel Thibault, le mar. 16 oct. 2018 03:04:16 +0200, a ecrit:
> Samuel Thibault, le ven. 12 oct. 2018 04:12:08 +0200, a ecrit:
> > I'm thinking... My chroots have a lib -> usr/lib symlink. Could it be
> > that python somehow gets lost between /lib/python* and /usr/lib/python*,
> > and dependending on e.g. inode number or directory order, we could have
> > one way or the other?
> > 
> > Right now I have two VMs with almost the same chroot (differences
> > notably lie in .pyc files), one works, the other doesn't. When I mount
> > the chroot of one on the other, the chroot behavior holds (i.e. the
> > failing chroot keeps failing on the VM which produced a working chroot).
> 
> This is driving me crazy :)
> 
> I have uploaded the VM images on
> https://people.debian.org/~sthibault/tmp/fails.img.gz
> https://people.debian.org/~sthibault/tmp/works.img.gz
> 
> Booting one or the other does not matter. What does matter is the
> disk image used to store the chroot. Each VM image has its own
> /var/cache/pbuilder/sphinxbase-build directory (almost exactly the
> same), and it does not matter which of the two I copy, if I copy it
> inside the fails.img disk I'm getting the lintian issue, and if it's
> inside the works.img disk I'm not getting it (there's a fresh checkout
> of sphinbase in /tmp/sphinxbase inside the chroots). And of course my
> own main system is in the fails case, thus preventing me from building
> the package :) tune2fsk does not show any difference between the two
> filesystem options, just creation time, mount count & such.
> 
> Any other idea of what could be different between the two filesystems?

It could very well be e.g. the resulting inode numbers and such, thus my
hypothesis at the top of the quotes above. Python people can have a look
at the fails.img.gz image, where the issue is notably reproducible from
the chroot in /var/cache/pbuilder/sphinxbase-build , building for
instance in /tmp/sphinxbase.

Samuel

Bug#911176: [Pkg-sysvinit-devel] Bug#911176: upgrade loops indefinitely

[Petter Reinholdtsen]

Note, it is unlikely the problem is in initscripts.  It is more likely
to be an incorrect dependency in one of the other init.d scripts
involved.  When it is known which, I recommend to reassign this bug to
the correct package.

I further recommend to have a look at the output from
/usr/share/insserv/check-initd-order, and to wrap up the output from
/usr/share/insserv/make-testsuite as an attachment to this bug to allow
anyone to try to reproduce the problem.

-- 
Happy hacking
Petter Reinholdtsen

Bug#911180: freeradius: freeradius refuses to start - missing libs

[Kamil Jonca]

Package: freeradius
Version: 3.0.16+dfsg-4.1+b1
Severity: grave
Justification: renders package unusable

After upgrade, freeradius refuses to start.
In its log we can see:

Tue Oct 16 21:59:52 2018 : Error: /etc/freeradius/3.0/mods-enabled/dhcp[18]: 
Failed to link to module 'rlm_dhcp': libfreeradius-dhcp.so: cannot open shared 
object file: No such file or directory 

bug is mysterious because:
[from /etc/freeradius/3.0/radiusd.conf]
libdir = /usr/lib/freeradius/

#ls -la /usr/lib/freeradius/rlm_dhcp* 
-rw-r--r-- 1 root root 14344 Oct 13 06:49 /usr/lib/freeradius/rlm_dhcp.so


moreover (I do not know if it is important)
#ldd /usr/lib/freeradius/rlm_dhcp.so
linux-vdso.so.1 (0x7fff15dcc000)
libfreeradius-dhcp.so => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4c96b7a000)
/lib64/ld-linux-x86-64.so.2 (0x7f4c96d78000)


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

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

Versions of packages freeradius depends on:
ii  freeradius-common  3.0.16+dfsg-4.1
ii  freeradius-config  3.0.16+dfsg-4.1+b1
ii  libc6  2.27-6
ii  libcap21:2.25-1.2
ii  libct4 1.00.82-2+b1
ii  libfreeradius3 3.0.16+dfsg-4.1+b1
ii  libgdbm6   1.18-2
ii  libpam0g   1.1.8-3.8
ii  libpcre3   2:8.39-11
ii  libperl5.265.26.2-7+b1
ii  libreadline7   7.0-5
ii  libsqlite3-0   3.25.2-1
ii  libssl1.1  1.1.1-1
ii  libtalloc2 2.1.14-1
ii  libwbclient0   2:4.8.5+dfsg-1
ii  lsb-base   9.20170808

Versions of packages freeradius recommends:
ii  freeradius-utils  3.0.16+dfsg-4.1+b1

Versions of packages freeradius suggests:
pn  freeradius-krb5
ih  freeradius-ldap3.0.16+dfsg-4.1+b1
pn  freeradius-mysql   
ih  freeradius-postgresql  3.0.16+dfsg-4.1+b1
pn  freeradius-python2 
ii  snmp   5.7.3+dfsg-3

-- Configuration Files:
/etc/default/freeradius changed:
FREERADIUS_OPTIONS="-xxx -l /var/log/freeradius/radius.log"

/etc/logrotate.d/freeradius changed:
/var/log/freeradius/*.log {
weekly
compress
delaycompress
notifempty
missingok
postrotate
/etc/init.d/freeradius reload > /dev/null
endscript
}


-- no debconf information

Bug#910707: s-s-d: please implement service readiness protocol

[Michael Biebl]

Hi Guillem

On Sat, 13 Oct 2018 12:14:57 +0200 Guillem Jover  wrote:
> Thanks, I've now improved this to the point I think it should always (!)
> work.

The bug reporter from #908796, also confirms that this works for him now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908796#134

Cheers,
Michael

-- 
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#911179: Qt5 packages uninstallable in Sid

[Jussi Pakkanen]

Package: libqt5core5a
Version: 5.11.2+dfsg-3

Qt packages are currently uninstallable in Sid. Trying to do a
pbuilder package build from scratch gives the following error:

The following packages have unmet dependencies:
libqt5sensors5 : Depends: qtbase-abi-5-11-0 which is a virtual package
and is not provided by any available package

libqt5webchannel5 : Depends: qtbase-abi-5-11-0 which is a virtual
package and is not provided by any available package

libqt5webkit5 : Depends: qtbase-abi-5-11-0 which is a virtual package
and is not provided by any available package

Depends: qtdeclarative-abi-5-11-0 which is a virtual
package and is not provided by any available package

qttools5-dev-tools : Depends: qtbase-abi-5-11-0 which is a virtual
package and is not provided by any available package

libqt5designer5 : Depends: qtbase-abi-5-11-0 which is a virtual
package and is not provided by any available package

libqt5positioning5 : Depends: qtbase-abi-5-11-0 which is a virtual
package and is not provided by any available package

This happens both on x86 and x86_64 and affects many packages.

Thanks,

Bug#911177: [PATCH] dlm: Toplevel Makefile always returns success

[Valentin Vidic]

Check exit codes from each of the subdirectories.
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index dd29bcea..ab069a1c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,2 +1,2 @@
 all install clean: %:
-   for d in libdlm dlm_controld dlm_tool fence; do $(MAKE) -C $$d $@; done
+   set -e; for d in libdlm dlm_controld dlm_tool fence; do $(MAKE) -C $$d 
$@; done
-- 
2.19.0

Bug#910790: [Pkg-raspi-maintainers] Bug#910790: Bug#910790: Testing the proposal

[Matthias Luescher]

Hi

I have updated the proposal according to your findings:
https://salsa.debian.org/lueschem-guest/raspi3-firmware/tree/bugfix/hook_ordering

Best regards
Matthias

Bug#911177: [Debian-ha-maintainers] Bug#911177: dlm: does not trap errors from make

[Valentin Vidic]

On Tue, Oct 16, 2018 at 09:22:22PM +0200, Helmut Grohne wrote:
> The upstream Makefile runs submakes in a for loop without any error
> trapping. Thus it continues building even in the presence of failures.
> Doing so violates the Debian policy section 4.6. The recommended
> solution is adding "set -e".

Confirmed, I will send a patch to the upstream...

-- 
Valentin

Bug#907219: m2crypto: testsuite problems with OpenSSL 1.1.1

[Kurt Roeckx]

All the errors in the test suite are problems in the test suite
itself. Some of those have been fixed upstream.

Some of the problems are:
- The test suite used 1024 bit keys, they have been replaced by
  2048 bit keys
- The test suite didn't send the Finished message to the server,
  the client just closed the connection, resulting in the server
  just hanging.
- Because of the split in TLS 1.2 and TLS 1.3 cipher strings, it's
  getting things like an unexpected cipher when using TLS 1.3

Bug#911174: thunar: drag menu doesn't work

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-10-16 at 21:03 +0200, Pavel Kreuzt wrote:
> when dragging some files to a thunar window it should show a submenu to
> choose wether to copy or move the files there. that menu is not showing and
> the files are being moved without asking.

What do you mean by “it should”? Simple drag and drop was never with a menu:
it moves when on the same filesystem, and copy when accross. The emblem on the
cursor indicates the action that will be taken.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlvGPGoACgkQ3rYcyPpX
RFta2Qf+Oqxv4YPWRMoboCYd8JyhQwY4KIWLomGr8xG0xSKUAmotwB4OxD6dpYbp
v41DB239IM4vqRbMUxe+VlDdjV5QUDzNYHGLKbpDPeKRLVzdWNEzIlfBr2wHsjIG
/2/3fUJWTJxtWJJG6IfQKLGIDYDZA6lF5g6bhRIkWO7cP6A98zCEtZFehffLQhoZ
Avf0UnAumY5CvjVJgi5ovzZNa6OQDXdOLoB+mnGTdEUq+2zG9RAvoQ+niFrNdxdt
e1Fp0t1RZ9I/nU5IIEKv2i2vEqwuGStYayirhJvjBb/TmbdQKhdKPqQG2B4ZBYM2
y2CThE0Qy8yM3Glbrm85Xx5ueo5pWA==
=820d
-END PGP SIGNATURE-

Bug#911110: gradio: automatic codec installation isn't supported by your distribution

[Cédric BRINER]

The gradio application says:
automatic codec installation isn't supported by your distribution.
Please install "gstreamer|1.0|gradio|MPEG-2 AAC decoder-audio/mpeg,
mpegversion=(int)2, level=(string)1, profile=(string)lc" manually.


 From the point of view of a Flatpak app, "your distribution" is the Flatpak
runtime (container) that it's running in, not Debian. gradio uses GStreamer
plugins from the Flatpak runtime, not from Debian.

That is really misleading.


The Flatpak runtime that gradio uses is chosen by the maintainers of the
gradio Flatpak app, so only they can solve this. I'd suggest reporting this
at https://github.com/flathub/de.haeckerfelix.gradio/issues

For the record, I've open a issue on github:
https://github.com/haecker-felix/Gradio/issues/355


So it seems that somehow, flatpak could be able to automatically install the
right package


Flatpak automatically installs the runtime that the gradio app asks for
(currently org.gnome.Platform version 3.28, although until a few days
ago it was version 3.30). If that runtime isn't suitable, then that's
a bug in the gradio app or a bug in the runtime.

That makes things clearer in my mind.

Thanks for your prompt answer.

Let's then close this bug.

 smcv

cED

Bug#911178: jconvolver FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: jconvolver
Version: 0.9.3-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

jconvolver fails to cross build from source, because it builds for the
wrong architecture. For one thing, the upstream Makefile hard codes the
build architecture compiler "g++". Making it substitutable is part of
the solution. Then jconvolver does not build anything during
dh_auto_build. The actual build is performed during make install and no
cross tools are passed at that point. Replacing all those overrides with
a --sourcedirectory flag fixes that part as well and makes jconvolver
cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru jconvolver-0.9.3/debian/changelog 
jconvolver-0.9.3/debian/changelog
--- jconvolver-0.9.3/debian/changelog   2016-12-20 16:03:48.0 +0100
+++ jconvolver-0.9.3/debian/changelog   2018-10-16 21:26:18.0 +0200
@@ -1,3 +1,12 @@
+jconvolver (0.9.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Avoid overrides using dh --sourcedirectory.
++ cross.patch: Make g++ substitutable.
+
+ -- Helmut Grohne   Tue, 16 Oct 2018 21:26:18 +0200
+
 jconvolver (0.9.3-2) unstable; urgency=medium
 
   [ James Cowgill ]
diff --minimal -Nru jconvolver-0.9.3/debian/patches/cross.patch 
jconvolver-0.9.3/debian/patches/cross.patch
--- jconvolver-0.9.3/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ jconvolver-0.9.3/debian/patches/cross.patch 2018-10-16 21:26:18.0 
+0200
@@ -0,0 +1,29 @@
+--- jconvolver-0.9.3.orig/source/Makefile
 jconvolver-0.9.3/source/Makefile
+@@ -37,7 +37,7 @@
+ JCONVOLVER_O =jconvolver.o config.o jconfig.o audiofile.o sstring.o 
jclient.o
+ jconvolver:   LDLIBS += -lzita-convolver -lfftw3f -lsndfile -lclthreads 
-ljack -lpthread -lrt
+ jconvolver:   $(JCONVOLVER_O)
+-  g++ $(LDFLAGS) -o $@ $(JCONVOLVER_O) $(LDLIBS)
++  $(CXX) $(LDFLAGS) -o $@ $(JCONVOLVER_O) $(LDLIBS)
+ $(JCONVOLVER_O):
+ -include $(JCONVOLVER_O:%.o=%.d)
+ 
+@@ -46,7 +46,7 @@
+ FCONVOLVER_O =fconvolver.o config.o fconfig.o audiofile.o sstring.o
+ fconvolver:   LDLIBS += -lzita-convolver -lfftw3f -lsndfile -lpthread -lrt
+ fconvolver:   $(FCONVOLVER_O)
+-  g++ $(LDFLAGS) -o $@ $(FCONVOLVER_O) $(LDLIBS)
++  $(CXX) $(LDFLAGS) -o $@ $(FCONVOLVER_O) $(LDLIBS)
+ $(FCONVOLVER_O):
+ -include $(FCONVOLVER_O:%.o=%.d)
+ 
+@@ -55,7 +55,7 @@
+ MAKEMULTI_O = makemulti.o audiofile.o
+ makemulti : LDLIBS += -lsndfile -lrt
+ makemulti:$(MAKEMULTI_O)
+-  g++ $(LDFLAGS) -o $@ $(MAKEMULTI_O) $(LDLIBS)
++  $(CXX) $(LDFLAGS) -o $@ $(MAKEMULTI_O) $(LDLIBS)
+ 
+ 
+ install:  all
diff --minimal -Nru jconvolver-0.9.3/debian/patches/series 
jconvolver-0.9.3/debian/patches/series
--- jconvolver-0.9.3/debian/patches/series  2014-02-26 13:05:14.0 
+0100
+++ jconvolver-0.9.3/debian/patches/series  2018-10-16 21:25:04.0 
+0200
@@ -1,3 +1,4 @@
 makefile.patch
 makefile2.patch
 03-spelling.patch
+cross.patch
diff --minimal -Nru jconvolver-0.9.3/debian/rules jconvolver-0.9.3/debian/rules
--- jconvolver-0.9.3/debian/rules   2016-12-20 16:03:48.0 +0100
+++ jconvolver-0.9.3/debian/rules   2018-10-16 21:26:15.0 +0200
@@ -5,11 +5,4 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
-   dh $@
-
-override_dh_auto_clean:
-   $(MAKE) -C source/ clean
-   dh_auto_clean
-
-override_dh_auto_install:
-   $(MAKE) -C source/ DESTDIR=$(CURDIR)/debian/jconvolver install
+   dh $@ --sourcedirectory=source

Bug#911177: dlm: does not trap errors from make

[Helmut Grohne]

Source: dlm
Version: 4.0.7-2
Severity: serious
Justification: policy 4.6
Tags: upstream

The upstream Makefile runs submakes in a for loop without any error
trapping. Thus it continues building even in the presence of failures.
Doing so violates the Debian policy section 4.6. The recommended
solution is adding "set -e".

Helmut

Bug#911176: upgrade loops indefinitely

[Richard Kettlewell]

Package: initscripts
Version: 2.88dsf-59.11

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
  libgdbm5 libmbedcrypto1 libobjc-7-dev libprotobuf-lite10 libprotoc10
  libstd-rust-1.28 libtinfo5 libx264-152 linux-doc-4.17
  linux-image-4.17.0-3-amd64
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  libgdbm6 libprotobuf-lite17 libprotobuf17 libprotoc17
The following packages will be upgraded:
  apache2 apache2-bin apache2-data apache2-utils apt apt-utils autopoint
  chromium chromium-common clang-7 desktop-file-utils
dh-strip-nondeterminism
  dirmngr dmidecode dpkg dpkg-dev gettext gettext-base gnupg gnupg-l10n
  gnupg-utils gnupg2 gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
gpgsm
  gpgv initscripts inkscape libaprutil1 libaprutil1-dbd-sqlite3
  libaprutil1-ldap libapt-inst2.0 libapt-pkg-dev libapt-pkg5.0
libasprintf-dev
  libasprintf0v5 libavahi-client3 libavahi-common-data libavahi-common3
  libavahi-glib1 libclang-common-7-dev libclang1-7 libdistro-info-perl
  libdpkg-perl libdrm-amdgpu1 libdrm-common libdrm-dev libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl-mesa0 libegl1-mesa
  libegl1-mesa-dev libfile-stripnondeterminism-perl libgbm1 libgd3
  libgdbm-compat4 libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-glx
  libglapi-mesa libglx-mesa0 libgpg-error-dev libgpg-error0 libgpgme11
  libimobiledevice6 libjson-glib-1.0-0 libjson-glib-1.0-common libllvm7
  libltdl7 libnghttp2-14 libparted-fs-resize0 libparted2 libpcsclite1
  libperl5.26 libpq-dev libpq5 libprotobuf-c1 libprotobuf-dev libprotoc-dev
  libproxy1v5 librest-0.7-0 libsoup-gnome2.4-1 libsoup2.4-1 libtool
  libtool-doc libusbmuxd4 libvolume-key1 libx11-6 libx11-data libx11-dev
  libx11-doc libx11-xcb-dev libx11-xcb1 libxapian-dev libxapian30
  libxcb-dri2-0 libxcb-dri2-0-dev libxcb-dri3-0 libxcb-dri3-dev libxcb-glx0
  libxcb-glx0-dev libxcb-present-dev libxcb-present0 libxcb-randr0
  libxcb-randr0-dev libxcb-render0 libxcb-render0-dev libxcb-shape0
  libxcb-shape0-dev libxcb-shm0 libxcb-shm0-dev libxcb-sync-dev libxcb-sync1
  libxcb-xfixes0 libxcb-xfixes0-dev libxcb-xinerama0 libxcb-xkb1 libxcb1
  libxcb1-dev linux-doc-4.18 linux-image-4.18.0-2-amd64 linux-libc-dev
man-db
  mesa-common-dev parted perl perl-base protobuf-compiler python-apt
  python-apt-common python3-apt rsyslog sysv-rc sysvinit-utils texlive
  texlive-base texlive-fonts-recommended texlive-latex-base
  texlive-latex-recommended usbmuxd xserver-common xserver-xorg-core zenity
  zenity-common
149 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/262 MB of archives.
After this operation, 12.9 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: news for deodand
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 219443 files and directories currently installed.)
Preparing to unpack .../archives/dpkg_1.19.2_amd64.deb ...
Unpacking dpkg (1.19.2) over (1.19.1) ...
Setting up dpkg (1.19.2) ...
Selecting previously unselected package libgdbm6:amd64.
(Reading database ... 219441 files and directories currently installed.)
Preparing to unpack .../libgdbm6_1.18-2_amd64.deb ...
Unpacking libgdbm6:amd64 (1.18-2) ...
Preparing to unpack .../libgdbm-compat4_1.18-2_amd64.deb ...
Unpacking libgdbm-compat4:amd64 (1.18-2) over (1.14.1-6+b1) ...
Preparing to unpack .../perl-base_5.26.2-7+b1_amd64.deb ...
Unpacking perl-base (5.26.2-7+b1) over (5.26.2-7) ...
Setting up perl-base (5.26.2-7+b1) ...
(Reading database ... 219447 files and directories currently installed.)
Preparing to unpack .../perl_5.26.2-7+b1_amd64.deb ...
Unpacking perl (5.26.2-7+b1) over (5.26.2-7) ...
Preparing to unpack .../libperl5.26_5.26.2-7+b1_amd64.deb ...
Unpacking libperl5.26:amd64 (5.26.2-7+b1) over (5.26.2-7) ...
Preparing to unpack .../libapt-pkg-dev_1.7.0_amd64.deb ...
Unpacking libapt-pkg-dev:amd64 (1.7.0) over (1.7.0~rc2) ...
Preparing to unpack .../libapt-inst2.0_1.7.0_amd64.deb ...
Unpacking libapt-inst2.0:amd64 (1.7.0) over (1.7.0~rc2) ...
Preparing to unpack .../libapt-pkg5.0_1.7.0_amd64.deb ...
Unpacking libapt-pkg5.0:amd64 (1.7.0) over (1.7.0~rc2) ...
Setting up libapt-pkg5.0:amd64 (1.7.0) ...
(Reading database ... 219448 files and directories currently installed.)
Preparing to unpack .../archives/apt_1.7.0_amd64.deb ...
Unpacking apt (1.7.0) over (1.7.0~rc2) ...
Setting up apt (1.7.0) ...
(Reading database ... 219448 files and directories currently installed.)
Preparing to unpack .../apt-utils_1.7.0_amd64.deb ...
Unpacking apt-utils (1.7.0) over (1.7.0~rc2) ...
Preparing to unpack .../libgpg-error-dev_1.32-2_amd64.deb ...
Unpacking libgpg-error-dev (1.32-2) over (1.32-1) ...
Preparing to unpack .../libgpg-error0_1.32-2_amd64.deb ...
Unpacking libgpg-erro

Bug#911175: ghostscript: CVE-2018-18284: 1Policy operator gives access to .forceput

[Salvatore Bonaccorso]

Source: ghostscript
Version: 9.20~dfsg-1
Severity: grave
Tags: patch security upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=699963

Hi,

The following vulnerability was published for ghostscript.

CVE-2018-18284[0]:
1Policy operator gives access to .forceput

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-18284
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18284
[1] https://bugs.ghostscript.com/show_bug.cgi?id=699963
[2] https://bugs.chromium.org/p/project-zero/issues/detail?id=1696
[3] 
http://git.ghostscript.com/?p=ghostpdl.git;h=8d19fdf63f91f50466b08f23e2d93d37a4c5ea0b

Regards,
Salvatore

Bug#911174: thunar: drag menu doesn't work

[Pavel Kreuzt]

Package: thunar
Version: 1.8.2-1
Severity: normal

Dear Maintainer,

when dragging some files to a thunar window it should show a submenu to choose 
wether to copy or move the files there. that menu is not showing and the files 
are being moved without asking.

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.2-2
ii  libatk1.0-0 2.30.0-1
ii  libc6   2.27-6
ii  libcairo2   1.15.12-1
ii  libexo-2-0  0.12.2-2
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgtk-3-0  3.24.1-2
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-3
ii  libpango-1.0-0  1.42.4-3
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-3-0  1.8.2-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.2-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  gnome-flashback [polkit-1-auth-agent] 3.30.0-1
ii  gnome-shell [polkit-1-auth-agent] 3.30.1-2
ii  gvfs  1.38.0-2
ii  libcairo-gobject2 1.15.12-1
ii  libpangocairo-1.0-0   1.42.4-3
ii  libxfce4panel-2.0-4   4.12.2-1
ii  lxpolkit [polkit-1-auth-agent]0.5.3-2
ii  lxqt-policykit [polkit-1-auth-agent]  0.13.0-1
ii  mate-polkit [polkit-1-auth-agent] 1.20.1-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  polkit-kde-agent-1 [polkit-1-auth-agent]  4:5.13.4-1
ii  thunar-volman 0.9.0-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-1
ii  xdg-user-dirs 0.17-1

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-1
ii  thunar-media-tags-plugin  0.3.0-1

-- no debconf information

Bug#911172: RFP: wklingon -- Klingon dictionary words for /usr/share/dict

[Pander]

Package: wnpp
Severity: wishlist

* Package name: wklingon
  Version : 1.0.0
  Upstream Author : Pander 
* URL : https://github.com/PanderMusubi/klingon
* License : Apache License
  Programming Lang: Python
  Description : Klingon dictionary words for /usr/share/dict

This package provides the file /usr/share/dict/klingon-latin
containing a list of Klingon words.

Klingon is a language constructed language from the Star Trek
universe. The source for this dictionary is boQwI'.

The project already offers a Debian package. See also request for
packaging related spell checker under package name hunspell-tlh.

Bug#910943: libhtml-tidy-perl: Please upload pending 1.60-2 and coordinate with libtidy transition

[gregor herrmann]

On Sat, 13 Oct 2018 12:46:33 -0400, Boyuan Yang wrote:

> Could you please investigate into those issues and upload a new
> version to solve the incompatibility problem?

So, I pushed a patch to the git repo which adjusts the testsuite to
html-tidy 5.7. I'm not uploading this right now because
- it's ugly
- there are issues which look like htm-tidy problems [0]
- and there's html-tidy 2:5.6.0-1 in NEW ...

Reviews from other perl-team members welcome.


Cheers,
gregor

[0]

-- (4:9) Warning: too many title elements in 
+- (2:5) Warning: too many title elements in 


for test data like



Test stuff
As if one title isn't enough
 
What?

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#911173: RFP: hunspell-tlh -- Klingon dictionary for Hunspell and Nuspell

[Pander]

Package: wnpp
Severity: wishlist

* Package name: hunspell-tlh
  Version : 1.0.0 
  Upstream Author : Pander 
* URL : https://github.com/PanderMusubi/klingon
* License : Apache License
  Programming Lang: Python
  Description : Klingon dictionary for Hunspell and Nuspell

This is the Klingon dictionary for use with the Hunspell and
Nuspell spell checkers, which are in its turn are used within the
LibreOffice and the Mozilla spell checkers.

Klingon is a language constructed language from the Star Trek
universe. The source for this dictionary is boQwI'.

The project already offers a Debian package. See also request for
packaging related word list under package name wklingon.

Bug#864827: Please go ahead adding explanations to the wiki

[Antoine Beaupre]

On Fri, Sep 21, 2018 at 08:48:20AM -0400, Stefan Monnier wrote:
> >> This bug basically makes the package unusable.  
> > Unfortunately that's true.
> >> I understand that adapting the packaging to the new structure of
> >> Zotero-5 will take some time, but in the mean time, could someone add
> >> a page to the Debian wiki outlining how to install Zotero-5 by hand on
> >> a Debian system
> > You are more than welcomed to do so.  Everyone can contribute to the
> > Debian wiki.
> 
> I know that, but I need to read this wiki page ;-)

Hello!

I don't know which wiki page you people are all refering to; I couldn't
find any myself, so I made one:

https://wiki.debian.org/Zotero

I hope that helps! :)

A.

-- 
The individual has always had to struggle to keep from being overwhelmed
by the tribe. If you try it, you will be lonely often, and sometimes
frightened. But no price is too high to pay for the privilege of owning
yourself.- Friedrich Nietzsche


signature.asc
Description: PGP signature

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Andreas Henriksson]

Hi,

On Tue, Oct 16, 2018 at 06:49:56PM +0200, Ansgar Burchardt wrote:
[...]
> +---
> | However, any package integrating with other init systems must also
> | be backwards-compatible with sysvinit by providing a SysV-style init
> | script with the same name as and equivalent functionality to any
> | init-specific job
> +---[ Debian Policy, 9.11 "Alternate init systems" ]
> 
> I propose to drop the requirement for the following reasons:
[...]

I don't really disagree with anything Ansgar has already said, but would
like to present a different view mostly for potential "food for thought".

It seems obvious to me that the above policy snippet was written in a
time when the universe revolved around sysvinit. In current day and age
sysvinit itself would be an "Alternate init system". We could update the
snippet to say that any package providing support for an alternate init
system must also provide systemd units if we wanted to modernize this
part of policy. On the other hand, that should probably be "should"
rather than "must" since we don't want to make numerable
un(der)maintained packages still not providing native systemd units
insta-RC-buggy.

(I'm not sure if targeting very specific issues and documenting things
related to systemd or init systems are worth it when we still miss the
"large picture" related to systemd in policy. On the other hand maybe
we'll never get there unless we start small and document things piece by
piece. I'm still leaning towards thinking just dropping this section is
better than doing a direct translation of it to the current systemd
reality which might just end up being confusing and help noone.)

Regards,
Andreas Henriksson

Bug#911171: epigrass: Please don't depend on python-visual

[Jeremy Bicha]

Source: epigrass
Version: 2.4.7-2
Severity: serious

python-visual is in poor shape in Debian. See the RC bug where
apparently it isn't even usable. It is one of the last 2 packages
depending on the unmaintained libglademm2.4. It was removed from
Ubuntu because it fails to build with the latest boost.

After visiting the website, I found what appears to be the latest
version on pip but it is now named vpython. It looks like the latest
version has dependencies that aren't in Debian.

Anyway, the only package depending on python-visual is epigrass but
when I look at Epigrass/dgraph.py it appears to be an optional
backend. You can use Qt instead.

Please consider removing the python-visual dependency so we can try to
remove python-visual from Debian.

Thanks,
Jeremy Bicha

Bug#894519: xpra 2.4 depends on python-gtkglext1

[Jeremy Bicha]

xpra only recommends python-gtkgl in Debian.

Your xpra package isn't from Debian.

Thanks,
Jeremy Bicha

Bug#911022: flann breaks hugin autopkgtest: undefined symbol: LZ4_resetStreamHC

[Andreas Metzler]

On 2018-10-16 Andreas Metzler  wrote:
[...]
> Okay, confirmed. So the failing autpkgtest is fixed by flann -6 and I
> only need to fix hugin's FTBFS.

... which is fixed with the latest hugin upload.

Bug#907979: Bug #907979: thunderbird: version 60.0-2 can't connect to gmail (or anything when xul-ext-gnome-keyring is installed)

[Jiri Masik]

On Mon, 24 Sep 2018 02:07:19 -0400 Joshua Judson Rosen 
 wrote:

I suspect that Benjamin has xul-ext-gnome-keyring installed, with which
Thunderbird 60 broke compatibility; see:

"xul-ext-gnome-keyring doesn't work with firefox >=57"


The assertion there, "In the meantime this still works for firefox-esr" from 
December 2017,
is of course no longer true that 60 has become esr; and while there's not yet 
any mention
of *Thunderbird* in that bug, it does appear to be the same sort of problem due 
to
Thunderbird 60 having made similar motions to phase out the XUL extension 
mechanisms--
which I guess is already known, seeing the notes in the Debian changelog like 
this:

   * [4a993c5] adding additional packages to Breaks with thunderbird
  The packages calendar-exchange-provider and enigmail
  xul-ext-sogo-connector aren't compatible to the webextension interface
  and we need to add a versioned Breaks.


I had the same problems as Benjamin described with a GMail account,
but *also* had a similar "Thunderbird just never completes login" problem
with an Dpvecot IMAP server that I administer (also on Debian).

After removing the xul-ext-gnome-keyring package, Thunderbird 60 works with 
both accounts :)

I guess the thunderbird package should add xul-ext-gnome-keyring to its 
"Breaks" list?




Hi Joshua,
thanks for your post, I had the same problem (i.e. unable to connect to 
any imap server with an updated thunderbird (versions ~>60.0) and 
removing xul-ext-gnome-keyring solved this issue

cheers
Jiri

Bug#894519: xpra 2.4 depends on python-gtkglext1

[Jeremy Bicha]

Control: tags -1 -buster +buster-ignore +bullseye
Control: block -1 by 885497

Ok, let's keep python-gtkglext1 around for Buster but I do intend to
remove this and anything else still using pygtk for Bullseye.

Thanks,
Jeremy Bicha

Bug#911170: swish++ FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: swish++
Version: 6.1.5-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

swish++ fails to cross build from source, because it builds for the
build architecture. The easiest way of passing cross tools to make is
using dh_auto_build. Unfortunately, swish++ has a little uncommon way to
name the tools. For instance the C++ compiler is called CC and the C
compiler is called LD. The variables need to be renamed. Further down
the road, it uses the wrong strip via install -s. It is best to avoid
stripping at install time as that breaks generation of -dbgsym packages.
The attached patch fixes all of that and makes swish++ cross buildable.
Please consider applying it.

Helmut
diff --minimal -Nru swish++-6.1.5/debian/changelog 
swish++-6.1.5/debian/changelog
--- swish++-6.1.5/debian/changelog  2017-08-12 06:47:44.0 +0200
+++ swish++-6.1.5/debian/changelog  2018-10-16 18:16:46.0 +0200
@@ -1,3 +1,13 @@
+swish++ (6.1.5-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_tools pass cross tools to make.
++ Supply unsual variables such as C++ compiler as CC.
++ Defer all stripping to dh_strip.
+
+ -- Helmut Grohne   Tue, 16 Oct 2018 18:16:46 +0200
+
 swish++ (6.1.5-5) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru swish++-6.1.5/debian/rules swish++-6.1.5/debian/rules
--- swish++-6.1.5/debian/rules  2017-08-12 06:07:33.0 +0200
+++ swish++-6.1.5/debian/rules  2018-10-16 18:16:46.0 +0200
@@ -20,9 +20,6 @@
 else
 CFLAGS += -O2
 endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-install_program += -s
-endif
 
 include /usr/share/quilt/quilt.make
 
@@ -42,8 +39,7 @@
 
 build-stamp: configure-stamp
dh_testdir
-   # Add here commands to compile the package.
-   $(MAKE)
+   dh_auto_build -- 'LD:=$$(CC)' 'CC:=$$(CXX)'
touch build-stamp
 
 clean: unpatch