Bug#885829: lios: Lios crashing on start

[mahashakti89]

Package: lios
Version: 2.6-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Lios package is crashing on start, giving following error message :

lios
/usr/lib/python3/dist-packages/lios/ui/gtk/text_view.py:21: PyGIWarning: Gtk 
was imported without specifying a version first. Use gi.require_version('Gtk', 
'3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk
/usr/lib/python3/dist-packages/lios/ui/gtk/print_dialog.py:23: PyGIWarning: 
PangoCairo was imported without specifying a version first. Use 
gi.require_version('PangoCairo', '1.0') before import to ensure that the right 
version gets loaded.
  from gi.repository import PangoCairo
/usr/lib/python3/dist-packages/lios/cam.py:19: PyGIWarning: GstVideo was 
imported without specifying a version first. Use gi.require_version('GstVideo', 
'1.0') before import to ensure that the right version gets loaded.
  from gi.repository import GdkX11, GstVideo
/usr/lib/python3/dist-packages/lios/ui/gtk/terminal.py:21: PyGIWarning: Vte was 
imported without specifying a version first. Use gi.require_version('Vte', 
'2.91') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, GObject, Vte

(lios:21533): Gtk-WARNING **: Cannot connect attribute 'text' for cell renderer 
class 'lios+ui+gtk+tree_view+CellRendererToggle' since attribute does not exist
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/lios/main.py", line 1297, in 
make_preferences_effective
self.dict = 
dictionary.Dict(dictionary.dictionary_language_dict[languages[self.preferences.language]])
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/lios", line 8, in 
linux_intelligent_ocr_solution()
  File "/usr/lib/python3/dist-packages/lios/main.py", line 331, in __init__
self.make_preferences_effective()
  File "/usr/lib/python3/dist-packages/lios/main.py", line 1318, in 
make_preferences_effective
pacman -S aspell-fr""").format(languages[self.preferences.language]))
IndexError: list index out of range
zsh: exit 1 lios


 Regards




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

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

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


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lios depends on:
ii  aspell-en2017.08.24-0-0.1
ii  espeak   1.48.04+dfsg-5+b1
ii  gir1.2-gst-plugins-base-1.0  1.12.4-1
ii  gir1.2-gtk-3.0   3.22.26-2
ii  gir1.2-vte-2.91  0.50.2-3
ii  imagemagick  8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-16
ii  poppler-utils0.61.1-2
ii  python3  3.6.4-1
ii  python3-enchant  2.0.0-1
ii  python3-gi   3.26.1-2
ii  python3-sane 2.8.3-1+b1
ii  python3-speechd  0.8.8-1
ii  tesseract-ocr4.00~git2188-cdc35338-2

lios recommends no packages.

Versions of packages lios suggests:
ii  cuneiform  1.1.0+dfsg-6

-- no debconf information

Bug#884060: iproute2: Upgrade from 4.9.0-2 to 4.9.0-2.1 breaks wireless.

[Van]

I'll have to defer to the maintainers judgement about closing the issue.  It's 
a moot point for me as at least 2 newer versions of iproute2 have hit the 
unstable repo since I reported what I thought was a bug and the issue seems to 
have been resolved with the upgrades.  Thank you for updating me.

On Fri, Dec 29, 2017, at 18:03, Andreas Henriksson wrote:
> Hello Van,
> 
> On Wed, Dec 20, 2017 at 04:20:31PM -0500, Van wrote:
> > I downgraded today from 4.13.0-1 to 4.9.0-2.1.  Initially, I wasn't able to 
> > connect via wireless.  Network manager made several attempts then just 
> > stopped trying.  I then restarted network manager service (systemctl 
> > restart network-manager.service), but network manager made several 
> > unsuccessful attempts to connect and then just stopped trying.  After a few 
> > more minutes, network manager successfully connected.  So, perhaps 
> > 4.9.0-2.1 just caused an issue(s) where it takes network manager longer to 
> > establish a wifi connection.
> > 
> > I'm including additional info below.  Again though, my belief is that 
> > whatever the issue is with 4.9.0-2.1, if there is an issue, appears to have 
> > been resolved with 4.13.0-1.  My wifi connection is established without 
> > issue upon bootup with 4.13.0-1.
> > 
> > I don't know if it's relevent, but when looking through the output of 
> > journalctl, a different MAC is set for my wireless card and then gets set 
> > to the real MAC.
> [...]
> 
> I'm quite sure NetworkManager and iproute2 are completely unrelated.
> They have nothing in common other than both talking directly to the
> kernel via the netlink protocol. (In other words, NetworkManager
> does not utilize ip(route2).)
> 
> The information in this bug report is quite vague and it seems to me
> like the problem you might have seen could have been just by chance
> matching to your up/downgrades of the iproute2 package version.
> 
> I think there's enough information here to close this bug report but
> will leave that decition up to the new maintainer(s).
> 
> Regards,
> Andreas Henriksson

Bug#883273: automatically handle Gruntfile.js/.coffee

[Pirate Praveen]

Control: affects -1 nodejs-dev

[copying nodejs/npm2deb maintainers]
bcc: pkg-javascript-devel, follow #845043

On Thu, 28 Dec 2017 09:11:00 + Niels Thykier 
wrote:> Sure; the idea more about you developing the prototype in a separate
> package and less about the concrete name of the package.  We can also do
> it inside debhelper, but then you get changes at the pace of debhelper
> releases plus the stability woes/guarantees of debhelper (e.g. at some
> point it will take compat bumps to fix things).

I just found out nodejs-dev has some basic debhelper plugin
https://anonscm.debian.org/cgit/collab-maint/nodejs.git/tree/debian/nodejs.pm
may be we can extend that.

> If those are "good enough" for you, then I am fine with going that
> direction.
> 
> >> FTR, I know next to nothing about grunt/nodejs builds, so I am a poor
> >> choice for driving such a prototype.  However, I am happy to assist with
> >> the debhelper integration bit.
> > 
> > I think it does not need any nodejs knowledge. If you find a
> > Gruntfile.js or Gruntfile.coffee, just call "grunt build".
> > 
> > Same for gulp, if you find a Gulpfile.js, just call "gulp build".
> > 
> > Also for cake, if you find Cakefile, just call "cake.coffeescript build".
> > 
> 
> I assume that the above instructions cover "dh_auto_build" and
> "auto-detection".  What do I do for:
> 
>  * dh_auto_configure?  (Nothing?)

I did not have to use this yet, so we can skip it for now I guess.

>  * dh_auto_test? ( test |  check?)

yes, for the most cases, but since many test dependencies are not yet
packaged, we may skip it too for now.

>  * dh_auto_install?  ( install DESTDIR=.../debian/tmp/ ?)

npm2deb creates debian/install file and I think dh_auto_install can be
skipped.

>  * dh_auto_clean?  ( clean?)

yes.

> Should I pass any flags for some tools to (e.g.) disable internet usage,
> tweak which tests are being run, choose where stuff is installed,
> whether files are minimized, etc.?

I don't think there is any standard way of doing such things. I think we
can expect them to be handled manually for now.




signature.asc
Description: OpenPGP digital signature

Bug#885775: apparmor: Apparmor triggers NULL pointer dereference in kernel 4.14.7-1 when updating with aptitude

[intrigeri]

Control: forwarded -1 appar...@lists.ubuntu.com

Hi AppArmor kernel developers,

we got this bug reported in Debian:

Kertesz Laszlo:
>* What led up to the situation?
>   Installed kernel 4.14 in Debian Testing and ever since at every upgrade 
> where systemd or other important 
>   packages were upgraded the system froze with the last 2 lines in the 
> system log:

>   Dec 29 21:25:26 laca-desktop kernel: BUG: unable to handle kernel NULL 
> pointer dereference at 0005
>   Dec 29 21:25:26 laca-desktop kernel: IP: __task_pid_nr_ns+0xc7/0xf0

>   The system became unresponsive, not even the sysrq combinations were 
> working
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>   Restarted ran dpkg --configure -a and every time the system froze
>   Booting with the 4.13 kernel was fine, dpkg finished its run

>   At the next upgrade i still got the freeze, after reboot i disabled the 
> kernel security features with the kernel command line security=false

>* What was the outcome of this action?
>   dpkg was working fine with the kernel 4.14 too

Do you need more info from me or from the bug reporter (Kertesz
Laszlo, Cc'ed)?

Cheers,
-- 
intrigeri

Bug#797036: iproute2: ss not reporting any listening udp sockets

[Tim Connors]

On Fri, 29 Dec 2017, Luca Boccassi wrote:

> Control: close -1 3.7.0-1
>
> On Thu, 27 Aug 2015 17:32:02 +1000 report...@rather.puzzling.org wrote:
> > Package: iproute2
> > Version: 3.16.0-2
> > Severity: normal
> > 
> > 0-0-17:20:59, Thu Aug 27 tconnors@pi:~ (bash)
> > 7185,30> sudo ss -anu
> > State   Recv-Q Send-Q  Local
> Address:PortPeer Address:Port 
> > 0-0-17:21:54, Thu Aug 27 tconnors@pi:~ (bash)
> > 
> > Not sure whether it's a kernel 3.18 thing or not, because rkhunter
> > didn't use to false-detect that it thought a whole bunch of UDP ports
> > were being used.  An another box running kernel 3.17, I do get
> > expected output:
> > 
> > 445024,1> sudo ss -anu
> > State   Recv-Q Send-Q  Local
> Address:PortPeer Address:Port 
> >
> UNCONN  0  0   *:36557 
>  *:* 
> > ...
> > 
> > Issue not fixed with iproute2 from testing.
> > 
> > 
> > Eg, from rkhunter:
> >  Port number: UDP:123 is being used by /usr/sbin/ntpd
> > 
> > 
> > 6853,29> ps 714
> >   PID TTY  STAT   TIME COMMAND
> >   714 ?Ss 2:32 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u
> 102:104
> > 
> > 6854,30> cat /proc/714/net/udp
> >   sl  local_address rem_address   st tx_queue rx_queue tr tm->when
> retrnsmt   uid  timeout inode ref pointer drops 
> >31: :82C3 : 07 : 00:
>  00 9385 2 db301400 0  
> >57: :03DD : 07 : 00:
>  00 7244 2 db301180 0  
> >69: :14E9 : 07 : 00:
>    1100 8592 2 db300c80 0  
> >93: :0801 : 07 : 00:
>  00 9363 2 db300280 0  
> >   108: :A510 : 07 : 00:
>  00 9660 2 d87fe280 0  
> >   128: :8324 : 07 : 00:
>  00 9693 2 d87fe500 0  
> >   179: :0357 : 07 : 00:
>  00 3555 2 db30 0  
> >   192: :B664 : 07 : 00:
>  00 8067 2 db300a00 0  
> >   203: :006F : 07 : 00:
>  00 7241 2 db300f00 0  
> >   210: :9F76 : 07 : 00:
>    1100 8594 2 db300780 0  
> >   215: 1C01A8C0:007B : 07 : 00:
>  00 9450 2 d87fe000 0  
> >   215: 017F:007B : 07 : 00:
>  00 9449 2 db301b80 0  
> >   215: :007B : 07 : 00:
>  00 9438 2 db301680 0  
> >   245: :E899 : 07 : 00:
>  00 9729 2 d87fe780 0  
> > 
> > 6855,31> sudo lsof -p 714
> > COMMAND PID USER   FD  TYPE DEVICE SIZE/OFF   NODE NAME
> > ntpd714  ntp  cwd   DIR   0,13 4096  2 /
> (192.168.1.17:/piroot)
> > ntpd714  ntp  rtd   DIR   0,13 4096  2 /
> (192.168.1.17:/piroot)
> > ntpd714  ntp  txt   REG   0,13   453328   2054
> /usr/sbin/ntpd (192.168.1.17:/piroot)
> > ntpd714  ntp  mem   REG   0,1338612 171210 /lib/arm-
> linux-gnueabihf/libnss_nis-2.19.so (192.168.1.17:/piroot)
> > ntpd714  ntp  mem   REG   0,1371628 149467 /lib/arm-
> linux-gnueabihf/libnsl-2.19.so (192.168.1.17:/piroot)
> > ntpd714  ntp  mem   REG   0,1330592 166482 /lib/arm-
> linux-gnueabihf/libnss_compat-2.19.so (192.168.1.17:/piroot)
> > ntpd714  ntp  mem   REG   0,1375644 171217 /lib/arm-
> linux-gnueabihf/libresolv-2.19.so (192.168.1.17:/piroot)
> > ntpd714  ntp  mem   REG   0,1318048 171207 /lib/arm-
> linux-gnueabihf/libnss_dns-2.19.so (192.168.1.17:/piroot)
> > ntpd714  ntp  mem   REG   0,13 9600 14 /lib/arm-
> linux-gnueabihf/libnss_mdns4_minimal.so.2 (192.168.1.17:/piroot)
> > ntpd714  ntp  mem   REG   0,1342724 171208 /lib/arm-
> linux-gnueabihf/libnss_files-2.19.so (192.168.1.17:/piroot)
> > ntpd714  ntp  mem   REG   0,1317868 147644 /lib/arm-
> linux-gnueabihf/libattr.so.1.1.0 (192.168.1.17:/piroot)
>
> Hi,
>
> This was fixed upstream in 3.1.0, so closing this bug now.

Hmmm, something specific about the raspberry pi armv6l architecture?

Rerunning those same tests, still no ss output:

9229,1> uname -a
Linux pi 4.9.59+ #1047 Sun Oct 29 

Bug#884648: mate-panel occasionally crashes with segfault

[agafnd]

> A backtrace for this crash is needed to find out the cause of the crash.
> It can be obtained, for example, if systemd-coredump is installed.

Hi,

If I understand correctly, you want me to run `systemd-coredump --backtrace`
(or some similar command) the next time mate-panel crashes?
Apologies if I am quite wrong.

Bug#884798: lintian could complain about pkg-config uses that fail to use $ac_tool_prefix

[Helmut Grohne]

On Fri, Dec 29, 2017 at 06:02:07PM -0500, James McCoy wrote:
> http://tirania.org/blog/archive/2012/Oct-20.html had some strong words
> to say about using pkg.m4.  Are those concerns still valid?  Should
> pkg.m4's macros be recommended or simply AC_PATH_TOOL?

That blog post looks like a misinformed user to me. The shell way he
recommends breaks cross compilation. I've never encountered the issue of
aclocal not substituting PKG_CHECK_MODULES as pkg.m4 is on the search
path once you install pkg-config. On Debian system you practically
cannot encounter the issue (as you will have pkg-config installed anyway
to use it). For other distributions, many source packages embed
(outdated) copies of pkg.m4. This is not great, but works.

In any case, using AC_PATH_TOOL fixes cross compilation. Just refrain
from using bare pkg-config.

Helmut

Bug#874029: /usr/bin/uscan: Re: [uscan] Please support verification against a signed file of hashsums

[Mike Hommey]

Package: devscripts
Version: 2.17.11
Followup-For: Bug #874029

> How many packages are like this type.

I can't tell you how many, but I can tell you that's how Mozilla does it
too, so this applies to firefox, thunderbird, nspr and nss:

https://download-installer.cdn.mozilla.net/pub/firefox/releases/52.5.3esr/SHA256SUMS.asc
https://download-installer.cdn.mozilla.net/pub/thunderbird/releases/52.5.2/SHA512SUMS.asc
https://download-installer.cdn.mozilla.net/pub/nspr/releases/v4.17/src/SHA256SUMS
https://download-installer.cdn.mozilla.net/pub/security/nss/releases/NSS_3_34_1_RTM/src/SHA256SUMS

Note there's actually no signature for nspr and nss (ironically). Which
makes me think checking hashes without signatures could be useful too.
I think I've seen other upstreams with hashes without signatures. Well,
as a matter of fact, there are at least on the gnome ftp:
http://ftp.gnome.org/pub/gnome/sources/glib/2.55/glib-2.55.0.sha256sum

Sure, this is not secure, but security is not the only reason one might
want to check hashes. You can just want to double check you got the
right archive, and not something with some bit flips (although arguably,
that would probably fail to uncompress).

Mike

Bug#757909: pulseaudio-module-gconf: migration to a dconf PA backend

[Martin-Éric Racine]

At least, paprefs uses gconf as its backend,

Martin-Éric

2017-12-30 3:22 GMT+02:00 Jeremy Bicha :
> Control: severity -1 important
> Control: user pkg-gnome-maintain...@lists.alioth.debian.org
> Control: usertags -1 oldlibs gconf
>
> As far as I am aware, there is no desktop using gconf any more.
>
> Debian GNOME Stretch and Ubuntu 17.04+ (at least default Ubuntu
> flavor) did not include gconf by default.
>
> I don't know if we'll be able to completely remove gconf before
> Buster's release, but we are trying to get the number of packages
> using gconf as low as possible.
>
> Thanks,
> Jeremy Bicha

Bug#878674: nodejs segfaults when building d3-* with webpack

[Pirate Praveen]

Control: severity -1 grave

On Mon, 13 Nov 2017 23:21:03 +0100 =?UTF-8?B?SsOpcsOpbXkgTGFs?=
 wrote:
> I'd like to lower the severity of this bug because it concerns code
that is
> not (yet) in debian. We'll raise it again if/when node-d3-zoom crashes
when
> building on build server.

segfault has reached the build server and raising the severity.

https://buildd.debian.org/status/fetch.php?pkg=node-es6-promise=all=4.1.1%2Bds-1=1514582110=0

I guess it makes sense to reupload nodejs 8.9 to unstable sooner.



signature.asc
Description: OpenPGP digital signature

Bug#885127: GnuTLS update breaks self-signed certificates

[Andreas Metzler]

On 2017-12-29 Daniel Kahn Gillmor  wrote:
> On Fri 2017-12-29 14:38:14 +0200, Rémi Denis-Courmont wrote:
>> The version of GnuTLS in Debian incorrectly flags self-signed
>> certificates as insecure certificate chain algorithm. This makes no
>> sense; the flag is for certificate chains using insecure algorithms
>> such as MD2, MD5 and SHA-1.

> sorry, i'm having a hard time seeing this.  In the example you give below:

>> This is reproducible also with gnutls-bin (both with Debian and upstream 
>> GnuTLS):
[...]
>> - Status: The certificate is NOT trusted. The certificate issuer is unknown. 
>> The certificate chain uses insecure algorithm. 
>> *** PKI verification of server certificate failed...
>> *** Fatal error: Error in the certificate.
>> *** handshake has failed: Error in the certificate.


> the error says "The certificate issuer is unknown", which is surely the
> *correct* response for a self-signed certificate when you haven't added
> that certificate to your list of X.509 root authorities.
[...]

Daniel, I agree that ""The certificate issuer is unknown" would be the
correct error message. However gnutls *additionally* throws an "The
certificate chain uses insecure algorithm." And the latter is afaict
wrong. There is no insecure algorim involved, the self-signature uses
"RSA-SHA256". (I had tried to make this clear with Actual
results/Expected results in the upstream report.)

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

Bug#885828: dolibarr: CVE-2017-17971

[Salvatore Bonaccorso]

Source: dolibarr
Version: 5.0.4+dfsg3-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/Dolibarr/dolibarr/issues/8000

Hi,

the following vulnerability was published for dolibarr.

CVE-2017-17971[0]:
| The test_sql_and_script_inject function in htdocs/main.inc.php in
| Dolibarr ERP/CRM 6.0.4 blocks some event attributes but neither onclick
| nor onscroll, which allows XSS.

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-2017-17971
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17971
[1] https://github.com/Dolibarr/dolibarr/issues/8000

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#885827: scan-view still points to the old clang directory

[Russ Allbery]

Package: clang
Version: 1:4.0-40
Severity: normal

When run, scan-view reports:

Traceback (most recent call last):
  File "/usr/bin/scan-view", line 144, in 
main()
  File "/usr/bin/scan-view", line 141, in main
run(port, args, args.root)
  File "/usr/bin/scan-view", line 71, in run
import ScanView
ImportError: No module named ScanView
Unhandled exception in thread started by 
sys.excepthook is missing
lost sys.stderr

Changing this line:

BASE_DIR = '/usr/share/clang/scan-view-3.9'

to point to 4.0 fixes the problem.

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

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

Versions of packages clang depends on:
ii  clang-4.0  1:4.0.1-8

clang recommends no packages.

clang suggests no packages.

-- no debconf information

Bug#885826: linux-igd: /etc/init.d/linux-igd requires $network

[Nye Liu]

Package: linux-igd
Version: 1.0+cvs20070630-5
Severity: serious
Tags: patch
Justification: Policy 9.3.2

/etc/init.d/linux-igd requires $network or it will fail to start.

--- linux-igd.dist  2017-12-28 22:07:28.512055702 -0800
+++ linux-igd   2016-09-22 09:01:57.0 -0700
@@ -1,8 +1,8 @@
 #! /bin/sh
 ### BEGIN INIT INFO
 # Provides:  linux-igd
-# Required-Start:$remote_fs $syslog
-# Required-Stop: $remote_fs $syslog
+# Required-Start:$remote_fs $syslog $network
+# Required-Stop: $remote_fs $syslog $network
 # Default-Start: 2 3 4 5
 # Default-Stop:  0 1 6
 # Short-Description: UPnP Internet Gateway Device

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

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

Versions of packages linux-igd depends on:
ii  iptables  1.6.1-2+b1
ii  libc6 2.25-5
ii  libupnp6  1:1.6.24-4
ii  lsb-base  9.20170808

linux-igd recommends no packages.

linux-igd suggests no packages.

-- Configuration Files:
/etc/default/linux-igd changed [not included]
/etc/init.d/linux-igd changed [not included]

-- no debconf information

Bug#885825: miniupnpd: listen needs to be set to an interface, not an ip addres

[Nye Liu]

Package: miniupnpd
Version: 1.8.20140523-4.2
Severity: serious
Justification: Policy 9.3.2

In /etc/default/miniupnpd, i have:

MiniUPnPd_LISTENING_IP=192.168.19.1

But this results in:

Error: please specify LAN network interface by name instead of IPv4 address : 
192.168.19.1
can't parse "192.168.19.1" as a valid interface name

To make it work, I must put:
MiniUPnPd_LISTENING_IP=eth1

dpkg configure should state it wants an interface, not an ip address.

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

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

Versions of packages miniupnpd depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  iproute2   4.14.1-1
ii  iptables   1.6.1-2+b1
ii  libc6  2.25-5
ii  libip4tc0  1.6.1-2+b1
ii  libip6tc0  1.6.1-2+b1
ii  libnfnetlink0  1.0.1-3+b1
ii  net-tools  1.60+git20161116.90da8a0-1
ii  uuid-runtime   2.30.2-0.1

miniupnpd recommends no packages.

miniupnpd suggests no packages.

-- debconf information:
* miniupnpd/listen: 192.168.19.1
* miniupnpd/ip6script: true
* miniupnpd/start_daemon: true
* miniupnpd/iface: eth0

Bug#885824: libgoffice-0.10-dev: Please drop Depends on libglade

[Jeremy Bicha]

Package: libgoffice-0.10-dev
Version: 0.10.35-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libglade
Tags: sid buster

Please drop the dependency of libgoffice-0.10-dev on libglade2.0-dev
(libglade is a library for gtk2).

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#829324: iproute2: malformed git repository (missingSpaceBeforeDate: invalid author/committer line - missing space before date)

[Stephen Hemminger]

On Fri, 29 Dec 2017 21:41:52 +0100
Luca Boccassi  wrote:

> Control: tags -1 wontfix
> 
> On Mon, 04 Jul 2016 00:04:41 +0200 intrigeri 
> wrote:
> > Control: tag -1 + upstream
> > 
> > Hi,
> > 
> > Daniel Kahn Gillmor wrote (02 Jul 2016 14:51:26 GMT) :  
> > > It looks like there is an error in the git repository for debian
> > > packaging for iproute2:  
> > 
> > FWIW, I've just stumbled upon the same problem (trying to help with
> > #783276) when cloning the upstream repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.g  
> it
> > 
> > Cheers,
> > --
> > intrigeri  
> 
> Hi,
> 
> Thanks for the report, but running git fsck these all look like errors
> in the upstream repository tags, so they should be fixed there. It
> smells like it was the result of a migration from whatever was used
> before git.
> 
> Incidentally, any idea if these problems can actually be fixed without
> breaking the history of the repository? Any suggestion on what do to?
> Perhaps these tags should be deleted and recreated? A bit of a hassle
> to sync, but doable.
> 
> Looks like they had a similar problem in collectd:
> 
> https://github.com/collectd/collectd/issues/2115
> 
> Stephen, FYI: this is easily reproducible by running "git fsck" in the
> upstream repository.
> 

Mostly this is because older versions of git did things in messy way
and were less picky. kernel repo has same issue.



pgpQdJIvEEKp6.pgp
Description: OpenPGP digital signature

Bug#885823: evolution-rss: Depends on gconf

[Jeremy Bicha]

Source: evolution-rss
Version: 0.3.95-8
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#883950: Next steps on "[GPL-3+]" proposal

[Russ Allbery]

Stuart Prescott  writes:

> TL;DR: I'd prefer we didn't use the brackets or bump version numbers,
> hence challenging this now before it becomes too entrenched.

> * In copyright-format/1.0, the tokens specifying the licences are
> entirely opaque with the exception of the + at the end (and then these
> tokens are concatenated with and/or/,/with(.*)exception etc). Opaqueness
> is a handy property to maintain but is violated by the use of the
> brackets as [GPL-3+].

> * A file with "License: [GPL-3+]" and a file with "License: GPL-3+" are
> under the same licence and making it look different is no benefit. For
> the common licences we are discussing, the important information is
> 'which licence', most readers will already know what the tokens mean and
> there is no need to do more; this seem pretty uncontroversial as it is,
> after all, pretty foundational to the proposal to remove the "On Debian
> systems, …" text.

Thank you.  I was struggling with this but couldn't put my finger on what
was bothering me.  Why not just say that we can omit the "can be found in
/usr/share/common-licenses" text completely and otherwise leave the format
unmodified?

I agree that we should probably add /usr/share/common-licenses to the
default motd.  Currently, we say:

The programs included with the Debian GNU/Linux system are free
software; the exact distribution terms for each program are described
in the individual files in /usr/share/doc/*/copyright.

and could just add something like:

The full texts of common licenses used by multiple packages can be
found in /usr/share/common-licenses.

Then, in a README in /usr/share/common-licenses, we could say something
very short like:

References to one of these licenses with a + appended, such as
"GPL-2+", indicate the choice of the named license file or any later
version of the same license.

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

Bug#869655: approx frequently FTBFS with test failures

[Axel Beckert]

Control: clone -1 -2
Control: retitle -2 approx: FTBFS with ocaml 4.05.0: Some fatal warnings were 
triggered
Control: found -2 5.8-1
Control: fixed -2 5.9-1
Control: close -2

Hi Ole and Eric,

Ole Streicher wrote:
> @Adrian: Are you sure this is a regression introduced with 5.9-1?

I fear so:

~ → links2 -dump 
https://tests.reproducible-builds.org/debian/history/approx.html | fgrep FTBFS 
| fgrep -v 5.9-1
2016-10-26 5.5-2   unstable amd64FTBFS FTBFS4m 9s
profitbricks-build5-amd64  profitbricks-build1-amd64  amd64_4/54728  
2015-12-01 5.5-2   unstable armhfFTBFS FTBFS5m 55s  
   armhf_14/164   

So all approx FTBFS reported by the reproducible builds project were
from either 5.9-1 or 5.2-2 (more than a year ago) while 5.8-1 and
5.7-1 never FTBFS, at least not in testing.

There's a small chance that 5.8-1 would FTBFS with Ocaml from
Unstable. Since I couldn't reproduce the FTBFS with approx and ocaml
from unstable on amd64, I didn't try to build approx from testing with
ocaml from unstable on amd64.

But I was able to reproduce the FTBFS of approx 5.9-1 on unstable
armhf six times in a row (with several variants: with and w/o
eatmydata, with different nice and concurrency levels).

So I tried to build approx 5.8-1 with ocaml from unstable on armhf,
too. And it indeed FTBFS with ocaml from unstable. But not due to a
failing test suite but due to fatal compiler warnings:

ocamlfind ocamlc -c -warn-error A -package nethttpd -package pcre -o approx.cmo 
approx.ml
+ ocamlfind ocamlc -c -warn-error A -package nethttpd -package pcre -o 
approx.cmo approx.ml
File "approx.ml", line 283, characters 10-26:
Warning 3: deprecated: String.lowercase
Use String.lowercase_ascii instead.
File "approx.ml", line 1:
Error: Some fatal warnings were triggered (1 occurrences)
Command exited with code 2.
Makefile:15: recipe for target 'approx' failed
make[1]: *** [approx] Error 10

> 1. lower the severity to let it migrate, or

Sounds like the wrong option to me.

> 2. set the version-found to 5.8-1

Sounds wrong to me, too, given my findings.

> to enable autoremoval of the package
> in testing (and then let the transition go).

This nevertheless sounds like the correct approach.

So IMHO the clean solution is a separate bug report covering the FTBFS
of 5.8-1 with ocaml from unstable, which is fixed with 5.9-1. I've
tried to implement that with the control statements above by cloning
this bug report. Feel free to fix that if it doesn't result in the
expected outcome.

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#885797: [Pkg-matrix-maintainers] Bug#885797: revolt: please build-depend on libglib2.0-dev-bin

[Hubert Chathi]

On Fri, 29 Dec 2017 23:50:08 +, Simon McVittie  said:

[...]

> This is easily fixed by changing the Build-Depends to pull in either
> libglib2.0-dev-bin, or libglib2.0-dev. I'll do a delayed NMU with the
> obvious change when I get a bug number; or if a maintainer would
> prefer to take care of this, a suitable patch is attached.

Hi Simon,

Thank you for the report and for the NMU.  I don't think we have any
uploads for Revolt planned in the near future, so we can just let the
NMU go through.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#885819: almanah: Depends on gconf

[Jeremy Bicha]

Source: almanah
Version: 0.11.1-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

Someone should look into packaging a git snapshot since it looks like
this app has been ported from gconf to gsettings in git master.

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885821: cdrdao: Depends on gconf

[Jeremy Bicha]

Source: cdrdao
Version: 1:1.2.3-3
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885820: apcupsd: Depends on gconf

[Jeremy Bicha]

Source: apcupsd
Version: 3.14.14-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885817: gnomint: Depends on gconf

[Jeremy Bicha]

Source: gnomint
Version: 1.2.1-7
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885818: alltray: Depends on gconf

[Jeremy Bicha]

Source: alltray
Version: 0.71b-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#883950: Next steps on "[GPL-3+]" proposal

[Stuart Prescott]

Hi Sean,

On Friday, 29 December 2017 09:18:51 AEDT Sean Whitton wrote:
[...]
> We now know that we can go ahead with the main proposal to introduce the
> "[GPL-3+]" notation into our machine-readable copyright format.

My personal preference is for debian/copyright to record the facts Debian is 
required to know rather than an increasingly verbose dosier of evidence that 
supports those facts; that has a nice benefit of people spending less time 
copying and reformatting text. I think there is merit in persuing this.

That said, I find the proposal that we should use "[GPL-3+]" (#883950) and the 
proposal that a "License-Grant" field be added (#786470) to be largely 
contradictory. I think accepting (or even pursuing) one should mean killing 
the other:

* The "License-Grant" proposal is seeking to find a place in the copyright 
file for yet more boilerplate so that we can record what is claimed to be very 
important information that we should not be omitting ("This program is free 
software; …"). 

* The "[GPL-3+] proposal" is seeking to remove what is claimed to be 
completely unimportant boilerplate, including the licence grant text and more 
("On Debian systems, …").

Recent discussions on other mailng lists have demonstrated that we don't 
really know what we want from d/copyright and I guess these two contradictory 
proposals illustrate that further.

 
> However, we still need to decide how we are going to hint to the local
> admin that "GPL-3+" means "GPL version 3 or any later version at your
> option".  (The purpose is to keep the machine-readable copyright format
> basically readable without reference to the copy of the spec on the
> Debian web mirrors.  So it's not the square brackets that we need to
> hint about.  It's the '+'.)

Apart from /u/s/common-licenses/README, perhaps documenting the meaning of "+" 
is as simple as adding /usr/share/common-licenses to /etc/motd since that is 
what we already use that to point users to the existence of /usr/share/*/
copyright at present.


While recognising that you're asking about the "+" not the brackets at this 
stage, a couple of comments on the format from the perspective of a maintainer 
of code that looks at d/copyright. 

TL;DR: I'd prefer we didn't use the brackets or bump version numbers, hence 
challenging this now before it becomes too entrenched.

* In copyright-format/1.0, the tokens specifying the licences are entirely 
opaque with the exception of the + at the end (and then these tokens are 
concatenated with and/or/,/with(.*)exception etc). Opaqueness is a handy 
property to maintain but is violated by the use of the brackets as [GPL-3+].

* A file with "License: [GPL-3+]" and a file with "License: GPL-3+" are under 
the same licence and making it look different is no benefit. For the common 
licences we are discussing, the important information is 'which licence', most 
readers will already know what the tokens mean and there is no need to do 
more; this seem pretty uncontroversial as it is, after all, pretty 
foundational to the proposal to remove the "On Debian systems, …" text.

* For the casual reader, the brackets are apparently to signal that one should 
look in /usr/share/common-licenses, but how would one know "[…]" meant to do 
that in any case if one didn't already know to do that? There is no value in 
them for communication to the user. Having accepted people should know to look 
in /u/s/d/*/copyright and /u/s/common-licenses, then the brackets are 
unneeded.

* For the completeness of the specification, the brackets only relax the 
'must' in the last paragraph of §6.7 that says there will be either (a) more 
lines of clarification for that licence in the current field or (b) a stand-
alone stanza to go with that licence key. This proposal is just changing that 
'must' for a handful of common licences and this proposal could simply turn 
into an exception being written into that paragraph. (Noting that the spec 
doesn't use must/should as we would often do and that 'otherwise … should' is 
really 'otherwise … must').

* If, as I believe, this proposal can be delivered with only a relaxation of 
the copyright-format/1.0 requirement on expanding the License field, then it 
could be done without incrementing the version number. A version bump gains 
nothing for the reader but costs a lot for all the people writing parsers. 
Worse, we'll end up with Lintian pestering every single maintainer to do a 
useless s/1.0/1.1/.


A final more general comment -- please include the people who write code based 
on the copyright-format specification in the discussion of specification 
changes and include them early on. (cme, lintian, sources.d.o, python-debian 
are the ones that come to mind; there are probably others) People who write 
parsers are probably policy wonks who read the list anyway, but it's worth 
checking.

cheers
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   

Bug#885816: racket: Recommends libunique

[Jeremy Bicha]

Source: racket
Version: 6.11+dfsg1-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
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.

Your package recommends libunique.

Please drop the recommends. Otherwise, consider porting your package to
GTK3 and related maintained libraries.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885618: kde-l10n-de lacks German translation for kmail2

[Pino Toscano]

On venerdì 29 dicembre 2017 23:05:09 CET Hans wrote:
> please note, that this bug is in version 17.08.3, too. I installed it and got 
> the same problem as described. Maybe you might want to recheck this, before 
> it 
> goes into testing. Maybe this bugreport should be reopened? 

The version 17.08.3 of what?  If you are talking about kde-l10n-de, then
what I said still applies, since kde-l10n will not contain anymore
translations of KDE applications based on Frameworks 5 (like kmail and
the while PIM stack).

-- 
Pino Toscano

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

Bug#885815: fcitx-configtool-gtk2: Depends on libunique

[Jeremy Bicha]

Package: fcitx-configtool-gtk2
Version: 0.4.9-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
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.

Your package depends and or build-depends on libunique.

Please consider dropping fcitx-configtool-gtk2 to help us achieve this
goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885814: lxsession: Depends on libunique

[Jeremy Bicha]

Source: lxsession
Version: 0.5.3-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
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.

Your package depends and or build-depends on libunique.

Please port your package to GTK3 and related maintained libraries.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885813: xfce4-notes-plugin: Depends on libunique

[Jeremy Bicha]

Source: xfce4-notes-plugin
Version: 1.8.1-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
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.

Your package depends and or build-depends on libunique.

The 1.8.0 NEWS entry says that there is a gtk3 build option, but it is
"missing features" compared to the gtk2 version.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#884780: RFS: piu-piu/1.0-1 [ITP]

[Adam Borowski]

In general, the package is in a releasable state already.  Network play
doesn't work, but the game itself is playable.

Please tell me if you'd want to upload to NEW now (and improve in a
subsequent version) or get it fully working from the in-archive start.

On Sat, Dec 30, 2017 at 12:46:40AM +0300, Ivan wrote:
> 29.12.2017 01:51, Adam Borowski пишет:
> > debian/changelog:
> > * you need to file an ITP bug ("reportbug wnpp") and put its number here.
> >ITPs are there so people are notified about what you're going to package.
> >In this case, it's pretty unlikely anyone will object, and we already did
> >the review, but it's a formality that costs us little.

Bug #884780 is this RFS.

> > * as the package is meant for upload, please s/UNRELEASED/unstable/

> Change UNRELEASED to unstable but:
> Now running lintian...
> E: piu-piu changes: bad-distribution-in-changes-file unstable
> Finished running lintian.

>From the version of your nc I see you're running an old version of Ubuntu,
it has lintian that's 1. outdated, 2. configured for Ubuntu.  Thus, it's
output will be obviously wrong.

> > I also couldn't get network play to work: it just hangs on both client and
> > server.  But single player mode appears to be fine.

> Network, hm... Maybe nc version is different?

I had netcat-traditional installed, but netcat-openbsd doesn't work either.

> I checked with this wersion:
> ii  netcat-openbsd 1.105-7ubuntu1 amd64 TCP/IP swiss army knife
> Works fine.

And here we go.  1.105-7ubuntu1 means either trusty or xenial.  I installed
xenial, indeed it works -- but only xenial<->xenial.  When either the server
or the client uses a newer release, it doesn't connect.

However, not only xenial is an old release (there were yakkety, zesty and
artful in meantime), but also the first version of Ubuntu that can possibly
ship your game is bionic.  It has netcat-openbsd 1.187-1, same as Debian
unstable, thus I assume it won't work.

Obviously, what I care about is Debian not Ubuntu, but they're on the same
boat.

Also, if the game needs netcat for some functionality, it should declare
at least Suggests: or Recommends: netcat.  Or perhaps even Depends:, as
while network play will probably be used only by a minority of users, both
netcat implementations are tiny packages that do no harm by being installed.


Also, compared to the previous submission, I see in the diff:
-Build-Depends: debhelper (>= 10)
-Standards-Version: 4.1.1
+Build-Depends: debhelper (>= 9)
+Standards-Version: 3.9.7

While using an old compat version is ok (useful for backports to old
releases), it's better to declare up to date standards.

It's not a show-stopper issue, though.  If you wish to ignore it, I can
upload as-is.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#885812: pk-update-icon: Depends on libunique

[Jeremy Bicha]

Source: pk-update-icon
Version: 2.0.0-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
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.

Your package depends and or build-depends on libunique.

Please port your package to GTK3 and related maintained libraries.
Otherwise, please consider requesting that your package be removed from
Debian to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885811: libgtk2-unique-perl: Remove libgtk2-unique-perl during the Buster cycle

[Jeremy Bicha]

Source: libgtk2-unique-perl
Version: 0.05-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
User: pkg-perl-maintain...@lists.alioth.debian.org
Usertags: gnome2-removal
Tags: sid buster
Control: blocked -1 by 870418

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.

Your package depends and or build-depends on libunique.

Please port your package to GTK3 and related maintained libraries.
Otherwise, please consider requesting that your package be removed from
Debian to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885810: gmpc: Depends on libunique

[Jeremy Bicha]

Source: gmpc
Version: 11.8.16-12
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
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.

Your package depends and or build-depends on libunique.

Please port your package to GTK3 and related maintained libraries.
Otherwise, please consider requesting that your package be removed from
Debian to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885809: caja-actions-dev: update dependencies

[Jeremy Bicha]

Package: caja-actions-dev
Version: 1.8.3-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
Tags: sid buster

caja-extensions-dev depends on libgtk2.0-dev and libunique-dev but the
source package build-depends on gtk3 (only). Please update the
dependencies.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885808: ario: Depends on libunique

[Jeremy Bicha]

Source: ario
Version: 1.5.1-1.3
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
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.

Your package depends and or build-depends on libunique.

Please port your package to GTK3 and related maintained libraries.
Otherwise, please consider requesting that your package be removed from
Debian to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885807: alarm-clock-applet: Depends on libunique

[Jeremy Bicha]

Source: alarm-clock-applet
Version: 0.3.4-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique
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.

Your package depends and or build-depends on libunique.

Please port your package to GTK3 and related maintained libraries.
Otherwise, please consider requesting that your package be removed from
Debian to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885806: chromium-browser: Don't Build-Depend on gconf

[Jeremy Bicha]

Source: chromium-browser
Version: 63.0.3239.84-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

chromium-browser has an unused Build-Dependency on libgconf2-dev.
Please remove it.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885805: RFS: ITP for luakit2/1.0

[Grégory DAVID]

Package: sponsorship-requests
Severity: wishlist
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

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

 * Package name: luakit2
   Version : 1.0
   Upstream Author : Aidan Holm
 * URL : https://github.com/luakit/luakit
 * License : GPLv3
   Section : web

  It builds those binary packages:

luakit2- fast and small web browser extensible by Lua, WebKit2 based

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/l/luakit2/luakit2_1.0.dsc

  More information about luakit2 can be obtained from
https://luakit.github.io/.

  Regards,
   Grégory David



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

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

-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEE8qxxv3aBr1TLJioP3p2n4r21O4cFAlpG03gUHGdyb29sb3RA
Z3Jvb2xvdC5uZXQACgkQ3p2n4r21O4d5sAf/VuIFtrN9zWrfm3te3j4+aTOZiXBW
8OaFBoA0dVCNSLpsu2JrNyV6CVoJGS8EheRi9EnoVHn2++XkmebXbMd2066jD57A
r+uWuN4yw6SyRnHxpKzyi3dSp7o13SzNDE/XBfAuAIuPCB0N/PK9iM4QOxrJ7Ms/
ptoEdGHI24IQ+ieF93olcBiz8JXe5J8QUaaiTHH+BLtHFPrddCKYwKp5jhaWaAsu
EuLlWB7U7U6YcAUvlgxjlwWYVFQWHFyjPSc4yOkImCC6bRxbbDcfVTa+T609o3x9
Bmbf0QLjMgZfPUNX0xpHid+5LKR0OLsDW48JdxkETDT3BUM1I4ycG7Sjlw==
=ORP1
-END PGP SIGNATURE-

Bug#885786: gnustep-back: Please drop art backend package

[Yavor Doganov]

Jeremy Bicha wrote:
> On Fri, Dec 29, 2017 at 7:59 PM, Yavor Doganov  wrote:
> >   3) Take libart under our umbrella.  (Provided it's a viable option
> >  in the first place.)
> 
> As you can see, libart has had zero maintenance since 2010:

It doesn't bother me much.  Almost half of the GNUstep stack (non-core
packages and libraries) is unmaintained, some of them since 2001.
We're used to it.  As long as we can cope with security and other
important bugs, it is manageable.  But it's a last resort.

> But if we can remove libgnome, then it probably makes sense to
> remove libgnomecanvas too and if we can remove that, then this is
> one of the only packages left using libart.

Right, that's ironclad logic and I don't dispute your effort to get
rid of libraries that you have to maintain but have no future and/or
are abandoned upstream.  I'm just sharing our concerns.

> https://bugs.debian.org/885800 (and dia is unmaintained).

Dia was a flagman package once upon a time, I'm surprised to see it
unmaintained.  I'll take a look to see if I can help with this bug or
at least get some QA job done.  It's a real pity.

Ivan Vučica wrote:
> > On 30 Dec 2017, at 00:59, Yavor Doganov  wrote:
> > 
> >  1) Wait for the opal or wayland backends to be labelled "ready for
> > release".  We can drop art immediately then.
> 
> It would be nice if Opal (Core Graphics) would be packaged anyway (a
> requirement for the -back opal). I’m not aware of apps that require
> it, but it would not be terrible to have a dev package either.

Some time ago I filed an ITP bug for CoreBase but discovered some
ABI-related issues and couldn't upload the package back then.
Afterwards I went MIA and probably haven't even reported it upstream.
It has always been my intention to package Opal.

 > Wayland backend has not been merged at this time, and it’d be a
 > “windowing” backend, not a “drawing” backend anyway. That is: I
 > think it still uses Cairo.

Right.  It's still useful to have it as a separate backend.  There's a
truckload of windowing and rendering issues, different behavior,
different code paths and different font choices between the backends.

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

[Paul Wise]

On Fri, Dec 29, 2017 at 7:54 PM, Alexis Murzeau wrote:

> Yes I will do that and consider check-all-the-things to be run at each
> version.

Ok, great. I'm also interested in any feedback you have on the tool.

> Indeed my bad. Also, the package got rejected because of a higher
> version in stable for the package livestreamer.
>
> Does the way to handle that is to add an epoch version, so it become
> 1:0.9.0~dfsg.2-2 ?

No, I would suggest to set the binary package version for livestreamer
only, that way you can drop the transitional package after buster
without having to keep the epoch around forever. You can set the
binary package version by passing the -v option to dpkg-gencontrol via
dh_gencontrol:

include /usr/share/dpkg/pkg-info.mk

override_dh_gencontrol:
dh_gencontrol -plivestreamer -- -v1.12.2+streamlink+$(DEB_VERSION)
dh_gencontrol --remaining-packages

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#757909: pulseaudio-module-gconf: migration to a dconf PA backend

[Jeremy Bicha]

Control: severity -1 important
Control: user pkg-gnome-maintain...@lists.alioth.debian.org
Control: usertags -1 oldlibs gconf

As far as I am aware, there is no desktop using gconf any more.

Debian GNOME Stretch and Ubuntu 17.04+ (at least default Ubuntu
flavor) did not include gconf by default.

I don't know if we'll be able to completely remove gconf before
Buster's release, but we are trying to get the number of packages
using gconf as low as possible.

Thanks,
Jeremy Bicha

Bug#515856: debhelper: please implement dh get-orig-source

[Russ Allbery]

Simon McVittie  writes:

> If this is reinstated, please can we discard the requirement that
> get-orig-source be invokable with an arbitrary working directory?  Many
> packages don't do that (because it's much more difficult to achieve than
> it looks), so clearly nobody is actually able to rely on it.

I think a compelling reason to get rid of the Policy specification of
get-orig-source is that the specification has proven to be incomplete and
inconsistently implemented, so you don't really know what you're going to
get when you invoke it.  (Usually just an error that the target wasn't
found.)  The people who can therefore effectively use it are either the
maintainers of that package who know what it does, or people who have read
some package documentation like README.source that explains how to use it.
And neither of those audiences need Policy to mention it.

Think of it this way: what behavior do we enable by including the current
paragraph about get-orig-source in Policy that would not be available if
Policy were just silent about it?

I think the original hope was that you could download a random Debian
source package and then run debian/rules get-orig-source to get the
tarball on which to base an upgrade to the latest Debian version.  But I
don't think this has panned out in practice, and uscan is now far more
sophisticated and a better way to achieve this (plus has much larger
archive coverage).  For instance, get-orig-source would require one to
implement their own checking of upstream source signatures, whereas this
can be easily automated with uscan.

> In my own packages that have a get-orig-source (mostly those where I
> have to use git snapshots or delete large non-free subtrees or both), I
> usually end up implementing a maintainer-get-orig-source target that
> wraps get-orig-source to make it work the way I want it to.

To me, this is a clear sign that get-orig-source is not useful as Policy
currently documents it.

The common case where get-orig-source might work out of the box is already
handled with uscan, which is better-documented and more widely
standardized.  For the remaining weird cases, Policy's description was not
all that helpful, and maintainer-focused custom targets or tools plus
documentation in README.source seems like the best approach.  For example,
if you have to repack upstream source in complicated ways, it's quite
possible you'll need to adjust that repacking with new upstream versions,
which means you need some documentation somewhere anyway and
get-orig-source in isolation isn't enough.

That said, the current description of README.source focuses on how to
modify the package.  Maybe it would be worth explicitly saying that how to
repack new upstream source should be documented in README.source if it's
not obvious how to do so?

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

Bug#885786: gnustep-back: Please drop art backend package

[Jeremy Bicha]

On Fri, Dec 29, 2017 at 7:59 PM, Yavor Doganov  wrote:
>   3) Take libart under our umbrella.  (Provided it's a viable option
>  in the first place.)

As you can see, libart has had zero maintenance since 2010:

https://git.gnome.org/browse/archive/libart_lgpl/

You are correct that libart was not mentioned in that email. But if we
can remove libgnome, then it probably makes sense to remove
libgnomecanvas too and if we can remove that, then this is one of the
only packages left using libart. If you're really curious, the only
other issues I am aware of for libart's removal are
https://bugs.debian.org/885787 and https://bugs.debian.org/885800 (and
dia is unmaintained).

Anyway, we'll check in again later once more of the libgnome stack is
removed. Consider this to be early warning. :)

Thanks,
Jeremy Bicha

Bug#885786: [Debian GNUstep maintainers] Bug#885786: gnustep-back: Please drop art backend package

[Ivan Vučica]

> On 30 Dec 2017, at 00:59, Yavor Doganov  wrote:
> 
>  1) Wait for the opal or wayland backends to be labelled "ready for
> release".  We can drop art immediately then.

It would be nice if Opal (Core Graphics) would be packaged anyway (a 
requirement for the -back opal). I’m not aware of apps that require it, but it 
would not be terrible to have a dev package either.

Wayland backend has not been merged at this time, and it’d be a “windowing” 
backend, not a “drawing” backend anyway. That is: I think it still uses Cairo.

>  2) Package the old xlib backend.  This is even more deprecated; the
> only good news is that Xlib is not going away soon.

It sounds like a decent alternative for people that want ‘as simple backend as 
possible’, too.

>  3) Take libart under our umbrella.  (Provided it's a viable option
> in the first place.)

To reiterate what you mentioned earlier in your email, on upstream mailing 
lists there were recently some voices saying they prefer font rendering of 
libart. For reader’s reference, emails were from 2017-11-27 on gnustep-dev@.

>  4) Just leave the cairo backend.



signature.asc
Description: Message signed with OpenPGP

Bug#885786: gnustep-back: Please drop art backend package

[Yavor Doganov]

Control: tags -1 - patch

Jeremy Bicha wrote:
> Source: gnustep-back

> Could you please help by removing the art backend package? It doesn't
> have any reverse-depends in Debian.

I'm afraid we'll have to postpone this request.  Thanks for the patch,
but I'm formally removing the patch tag because it is incomplete: it
doesn't take into account the alternatives system and the maintainer
scripts.  However, this is not an issue at all; dropping the art
backend is straightforward and would be an easy thing to do -- we
certainly don't need patches to carry out this trivial job.

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

I don't see gnustep-back in the list of packages here; it's probably
because libart is (was) way down the (old) GNOME stack and isn't
really a GNOME library, although it has always been under the GNOME
umbrella.

It is very important for us to have at least two GNUstep backends
available in Debian.  That way, we can distinguish GUI vs. Back bugs
and also backend-specific bugs that only apply to a particular
backend.  We always invite bug reporters to try to reproduce with the
other backend, it sometimes helps to narrow down the problem.

The art backend has been deprecated upstream (GNUstep) for a long
time, but it's still useful and in some situations provides better
rendering of fonts in particular.  It has its issues (mostly #749233)
but cairo has other problems as well.

There are several options:

  1) Wait for the opal or wayland backends to be labelled "ready for
 release".  We can drop art immediately then.

  2) Package the old xlib backend.  This is even more deprecated; the
 only good news is that Xlib is not going away soon.

  3) Take libart under our umbrella.  (Provided it's a viable option
 in the first place.)

  4) Just leave the cairo backend.

Bug#885797: revolt: diff for NMU version 0.0+git20170627.3f5112b-2.1

[Simon McVittie]

Control: tags 885797 + pending

I've prepared an NMU for revolt (versioned as 0.0+git20170627.3f5112b-2.1)
and uploaded it to DELAYED/7. Please let me know if I should delay
it longer or cancel it.

Regards,
smcv
diffstat for revolt-0.0+git20170627.3f5112b revolt-0.0+git20170627.3f5112b

 changelog |9 +
 control   |2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff -Nru revolt-0.0+git20170627.3f5112b/debian/changelog revolt-0.0+git20170627.3f5112b/debian/changelog
--- revolt-0.0+git20170627.3f5112b/debian/changelog	2017-11-25 17:05:24.0 +
+++ revolt-0.0+git20170627.3f5112b/debian/changelog	2017-12-30 00:49:08.0 +
@@ -1,3 +1,12 @@
+revolt (0.0+git20170627.3f5112b-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on libglib2.0-dev-bin as well as libglib2.0-bin.
+glib-compile-resources moved from -bin to -dev-bin in version
+2.54.2-5 to fix #885019 (Closes: #885797)
+
+ -- Simon McVittie   Sat, 30 Dec 2017 00:49:08 +
+
 revolt (0.0+git20170627.3f5112b-2) unstable; urgency=medium
 
   * Depend on gir1.2-webkit2-4.0 instead of directly on libwebkit2gtk-4.0.
diff -Nru revolt-0.0+git20170627.3f5112b/debian/control revolt-0.0+git20170627.3f5112b/debian/control
--- revolt-0.0+git20170627.3f5112b/debian/control	2017-11-16 22:11:58.0 +
+++ revolt-0.0+git20170627.3f5112b/debian/control	2017-12-30 00:49:08.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Matrix Packaging Team 
 Uploaders: Hubert Chathi 
-Build-Depends: debhelper (>=9), libglib2.0-bin, python3:any | python3-all:any | python3-dev:any | python3-all-dev:any, python3-gi
+Build-Depends: debhelper (>=9), libglib2.0-bin, libglib2.0-dev-bin, python3:any | python3-all:any | python3-dev:any | python3-all-dev:any, python3-gi
 Standards-Version: 3.9.8
 Homepage: https://github.com/aperezdc/revolt
 Vcs-Git: git://anonscm.debian.org/collab-maint/revolt.git

Bug#885804: tomboy: Depends on gconf

[Jeremy Bicha]

Source: tomboy
Version: 1.14.1-4
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
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.

Your package depends and or build-depends on gconf. It is recommended
to use dconf / gsettings instead of gconf which is no longer
maintained.

Please port your package to GTK3 and related maintained libraries.
Otherwise, please consider requesting that your package be removed from
Debian to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#515856: debhelper: please implement dh get-orig-source

[Simon McVittie]

On Fri, 29 Dec 2017 at 21:06:05 +0100, Bill Allombert wrote:
> It would be more useful to kept it but to add a note toward migrating to
> uscan if possible.

If this is reinstated, please can we discard the requirement that
get-orig-source be invokable with an arbitrary working directory?
Many packages don't do that (because it's much more difficult to achieve
than it looks), so clearly nobody is actually able to rely on it.

We seem to have three categories of get-orig-source, that I've seen:

- ignore that requirement, rely on dpkg's default.mk, get-orig-source
  will just fail when invoked from some other directory (very common),
  technically a Policy violation (example: gnome-shell-extension-caffeine)

- obey that requirement by duplicating information that exists elsewhere
  in the source package, meaning maintainers can't copy the same
  get-orig-source implementation into multiple packages with similar
  upstream patterns (example: iortcw)

- obey that requirement by doing "clever" (non-obvious, fragile) things
  with $(MAKEFILE_LIST), usually triggering Lintian warnings for having
  used dpkg-parsechangelog instead of default.mk because default.mk
  can't work with that pattern (example: mpdris2)

The first seems the least bad to me, although I've tried all three.

In my own packages that have a get-orig-source (mostly those where I
have to use git snapshots or delete large non-free subtrees or both),
I usually end up implementing a maintainer-get-orig-source target that
wraps get-orig-source to make it work the way I want it to.

smcv

Bug#885803: libgnomecanvasmm2.6: Don't release with Buster

[Jeremy Bicha]

Source: libgnomecanvasmm2.6
Version: 2.26.0-2
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgnomecanvas
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.

We should be able to remove libgnomecanvasmm2.6 from Debian Testing
soon.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885802: gcc-6: Please don't Build-Depend on libart

[Jeremy Bicha]

Source: gcc-6
Version: 6.4.0-11
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
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.

gcc-6 (and gcc-5 and gcc-4.8) Build-Depends on libart-2.0-dev. gcc-7
does not, maybe it's related to the removed gij/gcj packages. Please
investigate whether that Build-Depends can be dropped for Buster.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Simon McVittie]

On Fri, 29 Dec 2017 at 22:24:23 +0100, Markus Koschany wrote:
> Am 29.12.2017 um 00:06 schrieb Jonathan Nieder:
> > Using 'Files: *' when different files are under different licenses
> > sacrifices precision, but it doesn't sacrifice accuracy.  You can say
> > 
> >  Files: *
> >  License: GPL-2 and Permissive-License-1 and Permissive-License-2 and ...
> > 
> > Or you can even write
> > 
> >  Files: *
> >  License: Freeorion
> 
> Ok I can see the misunderstanding now. The above statement would be
> incorrect for freeorion because it translates to:
> 
> You are allowed to use the files under GPL-2 and Permissive-License-1
> and Permissive-License-2 and ...
> 
> But this is not true. Not all files are dual/triple/-licensed. Actually
> no file is even dual-licensed.

I think you're confusing this with a disjunction (dual/multi-license),
which is "GPL-2 or Permissive-License-1 or ..." in copyright-format.

"License: GPL-2 and Permissive-License-1 and Permissive-License-2 ..."
means you can only redistribute the file(s) in question if
you simultaneously do everything GPL-2 requires, everything
Permissive-License-1 requires, everything Permissive-License-2 requires,
and so on. In the case of the GPL, in practice that collapses into
"everything GPL-2 requires", unless the file is a GPL violation due to
the other licenses being non-GPL-compatible - but my understanding is
that the ftp team still require us to quote all the licenses, even if
they have no practical effect.

There are a couple of real-world examples of the "and" syntax in
src:darkplaces, where permissively-licensed code was copied into a
GPL-2+ project, resulting in files that are partly GPL-2+ and partly
some permissive license.

> I had to split the game into four digestible pieces (which are in total
> 1.2 GB large). My original idea was to duplicate the copyright file for
> all three data packages but back then this proposal has been harshly
> rejected on debian-mentors (when I wasn't a DD yet) because the
> copyright file would have mentioned files which are not part of a
> specific source package.

For what it's worth, when I discussed splitting openarena-data with the
ftp team (and then uploaded the split parts through NEW), they didn't
object to the copyright files being identical, with each source package
listing some copyright holders and licenses that actually only exist
in the other source packages from the same group.

However, I can see that d-mentors wouldn't like that: people sponsoring
random packages (that they themselves aren't necessarily involved or
interested in) will tend to assume that this particular package doesn't
deserve to be a special case, because 95% of the time it doesn't. Making
pragmatic decisions like "this is not what I'd usually do, but in this
case it makes more sense" requires enough context to understand the
costs and benefits that apply.

smcv

Bug#726589: lintian: version-substvar-for-external-package false positive if the package name contains substvars, too

[Andreas Beckmann]

Control: reopen -1

On 2017-12-26 19:23, Chris Lamb wrote:
> tags 726589 + wontfix
> thanks
> 
> Hi,
> 
>> lintian: version-substvar-for-external-package false positive if
>> the package name contains substvars, too
> 
> As such variables are (no longer?) valid in the Package, Source and
> Architecture fields, I am closing this bug. :)

This is a bug about Depends/Recommends/Suggests triggering the false
positive.


Andreas

Bug#885801: gnumeric: Please don't Build-Depend on libart

[Jeremy Bicha]

Source: gnumeric
Version: 1.12.35-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
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.

Your package appears to have an unnecessary Build-Depends on libart-
2.0-dev. Please drop it to help us achieve this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885800: dia: Don't Build-Depend on libart

[Jeremy Bicha]

Source: dia
Version: 0.97.3+git20160930-6
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgnomecanvas
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.

Your package build-depends on libart2.0-dev. The package builds fine
without that build-dependency, but the configure step has this output:

  Libart support (PNG export):   no


Please investigate whether the build-dependency can be dropped or
whether another maintained library can replace libart (like gdk-pixbuf, 
cairo, or imagemagick)

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885127: vlc: Cast Chromecast unusable due to gnutls error

[Floris]

Op Fri, 29 Dec 2017 22:48:30 +0100 schreef Daniel Kahn Gillmor  
:



On Tue 2017-12-26 22:24:59 +0100, Floris wrote:
I'm not sure this is a VLC bug, although I think it is odd that VLC 3  
has

a Chromecast feature, but it isn't working. Maybe build vlc without
Chromecast support in Debian until Google and/ or GnuTLS has a decent  
fix

for this issue. Or make a workaround.


Dropping chromecast support in debian doesn't seem like great option to
me if it's available upstream.  And GnuTLS has at least two different
fixes available.

One approach (as noted in my earlier post on this bug report) is to
explicitly grant that self-signed cert root CA status.  But that's
generally unpleasant, because it means that cert can MITM any of your
other connections.

A better approach to connecting to a persistently-named, self-signed
chromecast stream would be for VLC to take advantage of GnuTLS's "TOFU"
(trust on first use) functionality:

https://gnutls.org/manual/gnutls.html#Certificate-verification

or, if we already know that chromecast is never a strongly-secured
connection, we could just disable authentication on chromecast
connections (i do not have a chromecast, and i do not know what security
posture chromecast users expect from their connections).

hth,

--dkg



I think a lot of end users expect the "it just works" method. When you  
cast something from Chrome/ Chromium to the Chromecast there isn't a  
warning about a certificate. In addition, the certificate issued by the  
chromecast is only valid for 2 days. Does it mean that you get a new  
warning every two days? So I tend more to the last option.


gnutls-cli 192.168.1.14:8009
Processed 149 CA certificate(s).
Resolving '192.168.1.14:8009'...
Connecting to '192.168.1.14:8009'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=c036e8e6-dce8-c593-4624-e743f8eb7f04', issuer  
`CN=c036e8e6-dce8-c593-4624-e743f8eb7f04', serial 0x07b58554, RSA key 2048  
bits, signed using RSA-SHA256, activated `2017-12-29 09:57:32 UTC',  
expires `2017-12-31 09:57:32 UTC',  
pin-sha256="lqW7HJ396wf5w02vBO0Oyu3Os05S7OKUunht17mBwQE="

Public Key ID:
sha1:6b30af9317dcec5b8f16671aff24ccfa8af38bd4

sha256:96a5bb1c9dfdeb07f9c34daf04ed0ecaedceb34e52ece294ba786dd7b981c101
Public Key PIN:
pin-sha256:lqW7HJ396wf5w02vBO0Oyu3Os05S7OKUunht17mBwQE=
Public key's random art:
+--[ RSA 2048]+
| |
| |
| |
| |
|  o.So   |
|   +o.o.ooo  |
|   .+o. EB+ .|
|  oo..o+o+.o |
|  .o  +=*+o..|
+-+

- Status: The certificate is NOT trusted. The certificate issuer is  
unknown. The certificate chain uses insecure algorithm. The name in the  
certificate does not match the expected.

*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** handshake has failed: Error in the certificate.

Bug#885799: multimedia-devel: Drop obsolete Recommends

[Jeremy Bicha]

Source: multimedia-devel
Version: 0.6
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Tags: sid buster

libart-2.0-dev is a deprecated and unmtaintained library that the
Debian GNOME team aims to remove from Debian before the Buster release.

libjuce-dev was removed from Debian last month.

Please remove both of these recommends from multimedia-devel.

It is my understanding that it is RC for a package to recommend removed
libraries because it will keep unmaintained libraries from being
autoremoved.

Thanks,
Jeremy Bicha

Bug#661886: ip: man page should mention "label" length limit

[Andreas Henriksson]

Hello Kiss Gabor (Bitman),

Following up on old bug report available at
https://bugs.debian.org/661886

On Fri, Mar 02, 2012 at 01:05:47PM +0100, Kiss Gabor (Bitman) wrote:
> Hi Andreas,
> 
> > Would be awesome if you where willing to write a patch for this and
> > send it upstream. As you might be aware there are several other areas
> 
> No problem. I'll do it. :)

Was there every any progress on this?

If not, I have to voice my skeptisism here about documenting what seems
to be a *linux* limitation in iproute2.

The relevant code in iproute2 suggests that the netlink protocol does
not have a particular limitation on label length:

} else if (strcmp(*argv, "label") == 0) {
NEXT_ARG();
l = *argv;
addattr_l(, sizeof(req), IFA_LABEL, l, 
strlen(l)+1);


FWIW, This is similar to the situation in util-linux, where as one
example people usually request fsck and mount document filesystem
specific options. This quickly gets outdated and inconsistent as it
depends on which version of linux you're using and so on. It's much
better if Linux documents its own restrictions and you check the
documentation in the particular version you're using. (The conclusion in
the util-linux camp has been to stop documenting these things, although
the existing documentation has not (yet) been fully removed.)

I'd thus leave the suggestion to the new maintainers to consider
this bug report a wontfix and closing it.

Regards,
Andreas Henriksson

Bug#793057: ITP: godot -- open source MIT licensed game engine

[Kienan Stewart]

I've uploaded an updated package to mentors.debian.net. I think it's ready for 
more review/testing. I'm also looking for a sponsor if anyone is willing.

Thanks,
Kienan


signature.asc
Description: PGP signature

Bug#885798: gimp: Please drop Build-Depends on libart

[Jeremy Bicha]

Source: gimp
Version: 2.8.20-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
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.

Your package appears to have an unnecessary Build-Depends on
libart-2.0-dev. Please remove it to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885797: revolt: please build-depend on libglib2.0-dev-bin

[Simon McVittie]

Package: revolt
Version: 0.0+git20170627.3f5112b-2
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)

In bug #885019, the GNOME maintainers were asked to move the
glib-compile-resources tool to a more appropriate package to fix
cross-compiling. glib-compile-resources is a development tool and is not
needed by typical non-developer users, so moving it to libglib2.0-dev-bin
seemed most appropriate.

For the majority of packages that use glib-compile-resources, this had no
practical effect, because libglib2.0-dev depends on both. However,
revolt is unusual in that it uses glib-compile-resources without
depending on libglib2.0-dev (because it isn't native code). Depending
on libglib2.0-bin was previously enough to get glib-compile-resources,
but now isn't enough, making revolt FTBFS.

This is easily fixed by changing the Build-Depends to pull in either
libglib2.0-dev-bin, or libglib2.0-dev. I'll do a delayed NMU with the
obvious change when I get a bug number; or if a maintainer would prefer
to take care of this, a suitable patch is attached.

Thanks,
smcv
>From 3e10087807b360cc3d6d2ae208f92c3b9f28e9e6 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 29 Dec 2017 23:32:27 +
Subject: [PATCH] Build-depend on libglib2.0-dev-bin as well as libglib2.0-bin

glib-compile-resources moved from -bin to -dev-bin in version
2.54.2-5 to fix #885019 (Closes: #nn)
---
 debian/changelog | 9 +
 debian/control   | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index c277bb9..5673bc0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+revolt (0.0+git20170627.3f5112b-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on libglib2.0-dev-bin as well as libglib2.0-bin.
+glib-compile-resources moved from -bin to -dev-bin in version
+2.54.2-5 to fix #885019 (Closes: #nn)
+
+ -- Simon McVittie   Fri, 29 Dec 2017 23:30:30 +
+
 revolt (0.0+git20170627.3f5112b-2) unstable; urgency=medium
 
   * Depend on gir1.2-webkit2-4.0 instead of directly on libwebkit2gtk-4.0.
diff --git a/debian/control b/debian/control
index 9834670..8c5b0c8 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: net
 Priority: optional
 Maintainer: Matrix Packaging Team 
 Uploaders: Hubert Chathi 
-Build-Depends: debhelper (>=9), libglib2.0-bin, python3:any | python3-all:any | python3-dev:any | python3-all-dev:any, python3-gi
+Build-Depends: debhelper (>=9), libglib2.0-bin, libglib2.0-dev-bin, python3:any | python3-all:any | python3-dev:any | python3-all-dev:any, python3-gi
 Standards-Version: 3.9.8
 Homepage: https://github.com/aperezdc/revolt
 Vcs-Git: git://anonscm.debian.org/collab-maint/revolt.git
-- 
2.15.1

Bug#494372: Need more information about potential tc-prio(8) bug

[Andreas Henriksson]

Control: tags -1 + moreinfo upstream

Hello Harald Geyer,

Following up on this very old bug report. I'm tagging it moreinfo
based on my previous reply and that it's unclear what and/or if there is
a bug here at all.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494372#10

Please also note that the table in question has since been changed, so
any potential bug might have been resolved. It would thus be
interesting to get feedback on the current state of this issue.

If there's no further information provided I'd suggest this bug report
should simply be closed.

Regards,
Andreas Henriksson

Bug#885796: etherape: Depends on libgnomecanvas

[Jeremy Bicha]

Source: etherape
Version: 0.9.15+hg20171110-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgnomecanvas
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.

Your package depends and or build-depends on libgnomecanvas.

Please port your package to GTK3 and related maintained libraries.
Otherwise, please consider requesting that your package be removed from
Debian to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#561424: don't mention bin files on man page

[Andreas Henriksson]

Control: tags -1 + wontfix upstream

Hello jidanni,

Sorry for the very late followup...

First some historic information is available in:
- https://bugs.debian.org/325290
- See upstream commit 7dfb0366655a136f82c23fb3a6e6f30b482e3f86
  adds manpage.
- See also commit a07b2a77925f320d85c5256933b90a4ef39b4fd4

Further comments inlined below...

On Thu, Dec 17, 2009 at 09:29:39AM +0800, jida...@jidanni.org wrote:
> Package: iproute
> Version: 20090324-1
> Severity: wishlist
> File: /usr/share/man/man8/routel.8.gz
> 
> Regarding:
> FILES
>/usr/bin/routef
>/usr/bin/routel
> 
> * Shouldn't section (8) commands be in sbin, not bin?

If my opinion counts I'd be willing to follow in Arch Linux
footsteps and (after doing usrmerge) symlink sbin/ to bin/
so we can avoid ever again having a discussion about bin vs sbin.

On a more serious note, these scripts where first installed in
their current path in ancient times. I don't think it's worthwhile
trying to move them now.

> * Man pages usually list sbin or bin files.
> * The commands are so different, they deserve their own man pages.

They are tiny shell scripts whos documentation is magnitudes larger
then the actual scripts. I don't think they're worth more. I'm thus
tagging this bug report (based on the subject line being what's
requested) as wontfix. They where only documented at all in the
first place because of a request to do so. (See previously mentioned
bug report.)

If anything, I'd suggest stop installing the routef/routel scripts (and
their manpage). I simply don't see the value in shipping them and I
think very few people even knows or cares about their existance.
This is really up to the new maintainer(s) to decide though, and I'm
thus leaving the bug report open until they make the final call.

> * Of course I tried routef before reading the documentation. Luckily it
> didn't do what it said, and my networking was fine (bug?) even though I was
> root. And even if not root, routef doesn't return an error.

(Lucky for you I guess...)

Regards,
Andreas Henriksso

Bug#885795: RFS: zapping/0.10~cvs6-12 [QA] [RC]

[Yavor Doganov]

Package: sponsorship-requests
Severity: important

Dear mentors,

I'm looking for a sponsor for the orphaned package "zapping".  I would
appreciate if someone with a TV card (potential sponsor or not) builds
the package and eventually confirms that I haven't introduced any
regressions.  It's obvious that it has some subtle bugs but I wouldn't
want this release to hit the archive if it introduces new ones,
regardless of their severity.  I feel very uneasy to work on something I
can't really test, especially when I'm not familiar at all with the code
and the APIs.  Thanks in advance.

 * Package name: zapping
   Version : 0.10~cvs6-12
   Upstream Author : Iñaki García Etxebarria 
 Michael H. Schimek 
 and other
 * URL : http://zapping.sourceforge.net/
 * License : GPL-2
   Section : gnome

It builds this binary package:

  zapping- television viewer for the GNOME environment

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zapping/zapping_0.10~cvs6-12.dsc

Changes since the last upload:

  * QA upload.
  * debian/compat: Bump to 11.
  * debian/control (Priority): Set to optional.
(Build-Depends): Remove libesd0-dev (Closes: #856096).  Require
debhelper >= 11.  Remove dh-autoreconf and automake.  Add
autoconf-archive for the AX_COMPILER_FLAGS macro.  Remove ancient
version requirements for libgnomeui-dev, libgtk2.0-dev, libzvbi-dev.
Add freebsd-glue [hurd-any] in an attempt to fix FTBFS on GNU/Hurd.
(Vcs-Git, Vcs-Browser): Use secure/canonical URIs.
(zapping-dbg): Remove in favor of automatic -dbgsym.
(Standards-Version): Claim compliance with 4.1.3 as of this release.
  * debian/rules: Simplify -- remove unused variables, use standard
targets, order overrides sequentially.  Remove trailing whitespace.
Enable all hardening flags.  Don't invoke dh_autoreconf.  Don't
install the .xpm icon.
(override_dh_strip): Pass --dbgsym-migration.
  * debian/gnome-television.xpm:
  * debian/menu: Delete as per Policy requirement.
  * debian/zapping.install:
  * debian/preinst: Delete, no longer necessary.
  * debian/README.Debian: Fix two typos.
  * debian/patches/03-Desktop.patch: Add Keywords field.
  * debian/patches/08-Spelling-typos.patch: Fix yet another typo.
  * debian/patches/15-Misc-warnings.patch: Fix more warnings.
  * debian/patches/19-zapping_setup_fb_crash.patch: New; fix a segfault
when zapping_setup_fb is invoked with an invalid display name.  Thanks
Alexandre Rebert / Mayhem Team for the report (Closes: #716640).
  * debian/patches/20-Check-return-value.patch: New; fix compiler warnings
[-Wunused-result] which popped up due to the hardened CPPFLAGS.
  * debian/patches/21-GnomeVFS-to-GIO.patch: New; port to GIO, hopefully
done right (Closes: #868412).
  * debian/patches/22-gnome-common-deprecate.patch: New; don't use
deprecated gnome-common macro (Closes: #829824).
  * debian/patches/series: Update.
  * debian/changelog: Whitespace cleanup.
  * debian/copyright: Rewrite to adhere to copryight-format 1.0.

Bug#877983: ip: not easily findable on apropos

[Luca Boccassi]

Control: forwarded -1 https://patchwork.ozlabs.org/patch/854015/

On Sun, 08 Oct 2017 11:46:29 +0200 Lynoure Braakman 
wrote:
> Package: iproute2
> Version: 4.9.0-1
> Severity: wishlist
> 
> 
> Dear Maintainer,
> 
> I am very grateful for your work on Debian.
> 
> As someone used to ifconfig, I sometimes struggle with remembering it
was the command
> ip I should use now. I never could with it with apropos, and I
finally figured out why.
> 
> "ip - show / manipulate routing, devices, policy routing and tunnels"
> 
> The description for ip doesn't mention 'network', 'address',
'interface', 'ethernet', 
> 'internet' or 'mac', so it's rather hard to find for someone
wondering what ifconfig was
> replaced with. 
>  
> Could finding ip with one of those, by including it into the name or
description, be made 
> possible, making the change easier for people used to ifconfig?
> 
> -- 
> Lynoure Braakman

Hi,

It's a good suggestion - I forwarded the following patch upstream:

--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -1,6 +1,6 @@ 
 .TH IP 8 "20 Dec 2011" "iproute2" "Linux"
 .SH NAME
-ip \- show / manipulate routing, devices, policy routing and tunnels
+ip \- show / manipulate routing, network devices, policy routing, interfaces 
(ethernet and more) and tunnels
 .SH SYNOPSIS
 
 .ad l

-- 
Kind regards,
Luca Boccassi

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

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Russ Allbery]

Markus Koschany  writes:
> Am 29.12.2017 um 23:35 schrieb Russ Allbery:

>> Policy does not require that.  ftpmaster might, which is not quite the
>> same thing.

> That's a bold claim.

> "Every package must be accompanied by a verbatim copy of its copyright
> information and distribution license in the file
> /usr/share/doc/package/copyright"

I think there's an active project debate of the meaning of just about
every word in that sentence, and most of those debates have gone on for
years.  For example, does "verbatim" mean that collapsing multiple
copyright statements into one as allowed by copyright-format 1.0 is a
Policy violation, since that makes the copy not "vertabim"?

Anyway, the point that I was trying to make is that Policy says you have
to copy the copyright information and distribution license.  There's
nothing in there that says this means every license in the source package;
even ftpmaster doesn't require the licenses in, say, configure and
Makefile.in be copied.  An equally valid interpretation is that this is
the license under which the package is distributed, which is probably the
most restrictive of the set of licenses that cover the material that went
into the derivative work, or the union of them, depending on the exact
wording of the licenses.

In other words, if you have a few public domain files, a few GPL-2+ files,
and a few GPL-3+ files, there's nothing in Policy right now that says you
can't just put the GPL-3 into /usr/share/doc/package/copyright of the
resulting binary package and be done with it, since that's the effective
distribution license for the binary package.  However, that's not the
current ftpmaster policy, and ftpmaster both predates Policy and is the
decision-making body in Debian responsible for this.

That means Policy is at best horribly ambiguous and at worst wrong and
should be fixed to state the actual requirements, which I think everyone
agrees on.  Fixed to say *what* is the problem.

> Experience tells me that packages are rejected if they don't mention
> _each and every_ copyright information.

> I'm absolutely certain this warrants rejects by the FTP team. In my
> opinion Policy should always be in sync with ftpmasters decisions. I
> understand that this is not always easy to achieve but if your statement
> is true, it is kind of shocking because it means the ftpmasters are
> above Policy.

We would love to bring Policy in sync with ftpmaster decisions as soon as
we can figure out how to describe them.  That sounds flippant, but it's
the essence of the current situation: Policy says the bare minimum (and
the same thing it's said for years) because we don't have a more accurate
description of the actual requirements that everyone has signed off on.

This isn't ftpmaster's fault, in that I don't think they have a concrete
guide either.  It's more an apprenticeship and tradition thing, which
doesn't seem to be standardized sufficiently to turn into Policy language.
I feel like that would be a good goal for the project, but this has also
been something we've all wanted for years and years now.  It's clearly
quite hard to achieve, and I'm not sure the right path that would get us
there.

That's why I've been arguing in debian-devel in favor of a working group
to try to analyze this and produce a written policy we can get consensus
on.  Then we can put that into Policy and hopefully everyone will finally
be on the same page.

>> The Expat license grants *anyone* the right to do that, so the Debian
>> package maintainer can do this just as easily as upstream can.

> This is correct and sounds completely sensible to me. From my personal
> experience I can say this is not the reality though. We are required to
> mention public-domain licensed files and very permissive licensed files
> in d/copyright too. I can't just write the package is licensed under the
> GPL-2. I have to mention _all_ the different licenses in one package,
> otherwise my package gets rejected.

Yes, I know, but this is not coming from Policy.  Policy is basically
silent on this.

Please note: I'm not saying Policy *contradicts* ftpmaster either.  I'm
saying that Policy basically doesn't document the requirements for
debian/copyright.

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

Bug#846152: iproute2: Missing .sp in manpage ip-link.8

[Luca Boccassi]

On Sat, 2017-12-30 at 00:14 +0100, Andreas Henriksson wrote:
> Version: 4.14.1-1
> 
> Hi Luca,
> 
> On Fri, Dec 29, 2017 at 09:49:49PM +0100, Luca Boccassi wrote:
> > Control: tags -1 moreinfo
> > 
> > On Mon, 28 Nov 2016 19:41:36 +0100 David Rabel  > >
> > wrote:
> > > Package: iproute2
> > > Version: 4.8.0-1
> 
> [...]
> > > in man 8 ip-link there is a missing newline where the link types
> > > are
> > 
> > specified,
> > > right between bond and can.
> 
> [...]
> > that's a list, why should there be a newline there? Any particular
> > reason?
> 
> I assume you're looking at the current 4.14.1 sources? This was
> originally reported against an older version and seems to have been
> fixed since. See:

Duh - it's actually sillier than that, I did go back to the 4.8 tag,
but I was looking at the wrong bit of manpage. Thanks for checking it
out :-)

> $ git describe 103bc5f11da9b9f7bb4ca0fb187aa13d1135ad76
> v4.13.0-128-g103bc5f1
> 
> 
> $ git show 103bc5f11da9b9f7bb4ca0fb187aa13d1135ad76
> commit 103bc5f11da9b9f7bb4ca0fb187aa13d1135ad76
> Author: Roman Mashak 
> Date:   Fri Oct 27 15:05:34 2017 -0400
> 
> ip: added missing newline in man page
> 
> Signed-off-by: Roman Mashak 
> 
> diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> index 851b308c..d96ee288 100644
> --- a/man/man8/ip-link.8.in
> +++ b/man/man8/ip-link.8.in
> @@ -250,6 +250,7 @@ Link types:
>  .sp
>  .B bond
>  - Bonding device
> +.sp
>  .B can
>  - Controller Area Network interface
>  .sp
> 
> I'm thus closing this bug report. (The moreinfo tag was removed in
> a separate mail as that can not be done when sending to
> *-d...@bugs.debian.org.)
> 
> Regards,
> Andreas Henriksson

-- 
Kind regards,
Luca Boccassi

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

Bug#885794: inkscape: Please don't Build-Depend on libart

[Jeremy Bicha]

Source: inkscape
Version: 0.92.2-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
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.

inkscape appears to have an unnecessary build-dependency on libart-2.0-
dev. Please remove it to help us complete this goal.

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

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885686: k3d: Depends on unmaintained gtksourceview2

[Manuel A. Fernandez Montecelo]

Control: forwarded -1 https://github.com/K-3D/k3d/issues/30


Hi Jeremy,

2017-12-29 5:25 GMT+01:00 Jeremy Bicha :
> Source: k3d
> Version: 0.8.0.6-5
> Severity: important
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs gtksourceview2
> 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.
>
> Your package depends on gtksourceview2 which has not had a new release
> since 2010.
>
> Please port your package to GTK3 and gtksourceview3 and related
> maintained libraries. Otherwise, please consider requesting that your
> package be removed from Debian to help us complete this goal.
>
> [1] https://lists.debian.org/debian-devel/2017/10/msg00299.html
>
> On behalf of the Debian GNOME team,
> Jeremy Bicha

Thanks for the report.  I forwarded the report upstream.

The software seems to be only in maintenance mode, with few changes in
the last few years, so porting is unlikely unless it's pretty
straightforward.

I didn't look into it in detail, but if not porter, hopefully it's an
optional feature that can be disabled.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#884124: iproute2: Add iproute2-dev package

[Luca Boccassi]

On Fri, 2017-12-29 at 23:52 +0100, Andreas Henriksson wrote:
> Control: tags -1 = wontfix
> 
> Hello Evgenii Smirnov,
> 
> On Mon, Dec 11, 2017 at 07:19:27PM +0100, Evgenii Smirnov wrote:
> > Package: iproute2
> > Version: 4.3.0-1ubuntu3.16.04.2
> > Severity: wishlist
> > Tags: patch
> > 
> > ip link tool has an ability to use external shared libraries for 
> > defining custom device kinds which will be managed by the tool.
> > To build such libraries three header files are needed. It would 
> > be great to provide this headers in a dev package.
> 
> There used to be an iproute-dev package, which was removed by me.
> There where no legitimate users, only abusers of this internal code
> which is not a proper library to export as is for external
> consumption.
> Also the internal libnetlink is as far as I know being phased out
> even for internal iproute2 usage in favour of libmnl.
> The existing users where ported over to libmnl where needed when
> the iproute-dev package was removed.
> I would suggest you base your own code around libmnl where possible
> and if you're really modifying the iproute2 internals, then do that
> by patching the iproute2 source (via debian/patches/) and rebuild
> the package from source. If libnetlink is not yet fully phased out
> in upstream iproute2 I'm convinced your help in porting it over to
> libmnl is welcome as well! :)
> 
> I'm thus tagging this bug report as wontfix based on the historical
> information and suggesting that it should be closed (but both of
> these are really up to the new maintainers to decide on).
> 
> Regards,
> Andreas Henriksson

Hi,

Personally I agree with your point of view - I wouldn't really be too
keen to maintain downstream some internal headers for public usage -
having to counter API breakages and so on.

If upstream committed to publish a public header, with all the
guarantees this would entail, that would change things - but I don't
see that happening.

If Alex also agrees then we'll close this.

-- 
Kind regards,
Luca Boccassi

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

Bug#885793: tldr-py,tldr: File collision when installing together: /usr/bin/tldr (and maybe further files)

[Axel Beckert]

Package: tldr-py,tldr
Severity: serious
Control: found -1 tldr-py/0.7.0-1
Control: found -1 haskell-tldr/0.2.3-1

Hi,

installing tldr when tldr-py is already installed fails as follows since
both packages ship /usr/bin/tldr (and maybe further files like e.g. man
pages. etc.):

Preparing to unpack .../tldr_0.2.3-1_amd64.deb ...
Unpacking tldr (0.2.3-1) ...
dpkg: error processing archive /var/cache/apt/archives/tldr_0.2.3-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/bin/tldr', which is also in package tldr-py 0.7.0-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/tldr_0.2.3-1_amd64.deb

Please either conflict with each other or both start using
update-alternatives (if suitable wrt. commandline options, etc.) to
choose between the different implementations.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Bug#885341: [tex-live] Bug#885341: texlive-latex-extra: wordcount.tex is distributed without its script compagnion

[Karl Berry]

Added wordcount.sh to TeX Live for tonight's build. Thanks. -k

Bug#885127: GnuTLS update breaks self-signed certificates

[Daniel Kahn Gillmor]

Control: tags 885127 + moreinfo unreproducible

On Fri 2017-12-29 14:38:14 +0200, Rémi Denis-Courmont wrote:
> The version of GnuTLS in Debian incorrectly flags self-signed certificates as 
> insecure certificate chain algorithm. This makes no sense; the flag is for 
> certificate chains using insecure algorithms such as MD2, MD5 and SHA-1.

sorry, i'm having a hard time seeing this.  In the example you give below:

> This is reproducible also with gnutls-bin (both with Debian and upstream 
> GnuTLS):
>
> # gnutls-cli self-signed.badssl.com
> Processed 148 CA certificate(s).
> Resolving 'self-signed.badssl.com:443'...
> Connecting to '104.154.89.105:443'...
> - Certificate type: X.509
> - Got a certificate list of 1 certificates.
> - Certificate[0] info:
>  - subject `CN=*.badssl.com,O=BadSSL,L=San Francisco,ST=California,C=US', 
> issuer `CN=*.badssl.com,O=BadSSL,L=San Francisco,ST=California,C=US', serial 
> 0x0086fb4dc8e5dd0f18, RSA key 2048 bits, signed using RSA-SHA256, activated 
> `2016-08-08 21:17:05 UTC', expires `2018-08-08 21:17:05 UTC', pin-
> sha256="9SLklscvzMYj8f+52lp5ze/hY0CFHyLSPQzSpYYIBm8="
> Public Key ID:
> sha1:7965dfc93c6ae6fe8381ec482216ec44ef47282a
> 
> sha256:f522e496c72fccc623f1ffb9da5a79cdefe16340851f22d23d0cd2a58608066f
> Public Key PIN:
> pin-sha256:9SLklscvzMYj8f+52lp5ze/hY0CFHyLSPQzSpYYIBm8=
> Public key's random art:
> +--[ RSA 2048]+
> | |
> | .   |
> |o . .   o|
> | = o o o .o..|
> |+ + S o . .=.|
> | E . + o + o .. .|
> |  . . . + o  +o  |
> | . .+. . |
> |.o...|
> +-+
>
> - Status: The certificate is NOT trusted. The certificate issuer is unknown. 
> The certificate chain uses insecure algorithm. 
> *** PKI verification of server certificate failed...
> *** Fatal error: Error in the certificate.
> *** handshake has failed: Error in the certificate.


the error says "The certificate issuer is unknown", which is surely the
*correct* response for a self-signed certificate when you haven't added
that certificate to your list of X.509 root authorities.

In the forwarded bug report
(https://gitlab.com/gnutls/gnutls/issues/347), Andreas says:

>>> a) gnutls-cli self-signed.badssl.com
>>> b) Generate a test-cert with "certtool --generate-self-signed " with
>>> default algoritms and use gnutls-serv/gnutls-cli

(though presumably not in that order)

well, i tried that, and things still worked for me.

in particular, to generate the self-signed certificate, i did:

   certtool --generate-privkey --outfile key.pem
   certtool --generate-self-signed --load-privkey key.pem --outfile cert.pem

when answering the questions in the second invocation, i just hit enter
on everything except:


Common name: bad.example
The certificate will expire in (days): 30
Is this a TLS web server certificate? (y/N): y
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): n

Once that was done, i pointed bad.example to 127.0.0.1 in /etc/hosts,
launched the server with:

   gnutls-serv --x509keyfile key.pem --x509certfile cert.pem

and then connected with the client like so:

   gnutls-cli --x509cafile cert.pem bad.example:5556


everything worked successfully.

Can you give a clearer example of the problem you're seeing?  I don't
see anything broken in my tests.

--dkg


signature.asc
Description: PGP signature

Bug#885127: vlc: Cast Chromecast unusable due to gnutls error

[Daniel Kahn Gillmor]

On Tue 2017-12-26 22:24:59 +0100, Floris wrote:
> I'm not sure this is a VLC bug, although I think it is odd that VLC 3 has  
> a Chromecast feature, but it isn't working. Maybe build vlc without  
> Chromecast support in Debian until Google and/ or GnuTLS has a decent fix  
> for this issue. Or make a workaround.

Dropping chromecast support in debian doesn't seem like great option to
me if it's available upstream.  And GnuTLS has at least two different
fixes available.

One approach (as noted in my earlier post on this bug report) is to
explicitly grant that self-signed cert root CA status.  But that's
generally unpleasant, because it means that cert can MITM any of your
other connections.

A better approach to connecting to a persistently-named, self-signed
chromecast stream would be for VLC to take advantage of GnuTLS's "TOFU"
(trust on first use) functionality:

https://gnutls.org/manual/gnutls.html#Certificate-verification

or, if we already know that chromecast is never a strongly-secured
connection, we could just disable authentication on chromecast
connections (i do not have a chromecast, and i do not know what security
posture chromecast users expect from their connections).

hth,

--dkg


signature.asc
Description: PGP signature

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Markus Koschany]

Am 29.12.2017 um 23:35 schrieb Russ Allbery:
> Markus Koschany  writes:
> 
>> Ok I can see the misunderstanding now. The above statement would be
>> incorrect for freeorion because it translates to:
> 
>> You are allowed to use the files under GPL-2 and Permissive-License-1
>> and Permissive-License-2 and ...
> 
>> But this is not true. Not all files are dual/triple/-licensed. Actually
>> no file is even dual-licensed.
> 
> That's not what "and" means.  That would be "or".  "and" means you have to
> follow all of those licenses when using a work composed of those files,
> which sounds correct to me.

Of course. My bad! Still in the case of freeorion Jonathan's suggestion
would be incorrect. Nobody is obliged to adhere to _all_ license
conditions for _all_ files. If there are images licensed under CC-BY,
then I certainly don't have to follow all license conditions of the GPL
when I create a derivative work based on those images.

> It's not correct if you take one of the files from the group in isolation;
> in that case, you probably only have to follow one of the licenses.  But
> that gets back to the question of just what we're supposed to be
> documenting in debian/copyright.
> 
>> But if there is even one file which is differently licensed like
> 
>> Files: src/parser.c
>> Copyright: 2009, John Jay
>> License: Expat
> 
>> you have to mention that in d/copyright. Otherwise your copyright file
>> would be incomplete/incorrect under the current Policy requirements.
>> This is reject-worthy.
> 
> Policy does not require that.  ftpmaster might, which is not quite the
> same thing.

That's a bold claim.

"Every package must be accompanied by a verbatim copy of its copyright
information and distribution license in the file
/usr/share/doc/package/copyright"

Experience tells me that packages are rejected if they don't mention
_each and every_ copyright information.

I'm absolutely certain this warrants rejects by the FTP team. In my
opinion Policy should always be in sync with ftpmasters decisions. I
understand that this is not always easy to achieve but if your statement
is true, it is kind of shocking because it means the ftpmasters are
above Policy.

>> However upstream could simply state that all software is GPL-2+ licensed
>> because the Expat license grants them the right to sublicense parser.c.
> 
> The Expat license grants *anyone* the right to do that, so the Debian
> package maintainer can do this just as easily as upstream can.

This is correct and sounds completely sensible to me. From my personal
experience I can say this is not the reality though. We are required to
mention public-domain licensed files and very permissive licensed files
in d/copyright too. I can't just write the package is licensed under the
GPL-2. I have to mention _all_ the different licenses in one package,
otherwise my package gets rejected.

Perhaps this should be clarified. I would really like to see this happen.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#884060: iproute2: Upgrade from 4.9.0-2 to 4.9.0-2.1 breaks wireless.

[Andreas Henriksson]

Hello Van,

On Wed, Dec 20, 2017 at 04:20:31PM -0500, Van wrote:
> I downgraded today from 4.13.0-1 to 4.9.0-2.1.  Initially, I wasn't able to 
> connect via wireless.  Network manager made several attempts then just 
> stopped trying.  I then restarted network manager service (systemctl restart 
> network-manager.service), but network manager made several unsuccessful 
> attempts to connect and then just stopped trying.  After a few more minutes, 
> network manager successfully connected.  So, perhaps 4.9.0-2.1 just caused an 
> issue(s) where it takes network manager longer to establish a wifi connection.
> 
> I'm including additional info below.  Again though, my belief is that 
> whatever the issue is with 4.9.0-2.1, if there is an issue, appears to have 
> been resolved with 4.13.0-1.  My wifi connection is established without issue 
> upon bootup with 4.13.0-1.
> 
> I don't know if it's relevent, but when looking through the output of 
> journalctl, a different MAC is set for my wireless card and then gets set to 
> the real MAC.
[...]

I'm quite sure NetworkManager and iproute2 are completely unrelated.
They have nothing in common other than both talking directly to the
kernel via the netlink protocol. (In other words, NetworkManager
does not utilize ip(route2).)

The information in this bug report is quite vague and it seems to me
like the problem you might have seen could have been just by chance
matching to your up/downgrades of the iproute2 package version.

I think there's enough information here to close this bug report but
will leave that decition up to the new maintainer(s).

Regards,
Andreas Henriksson

Bug#884798: lintian could complain about pkg-config uses that fail to use $ac_tool_prefix

[James McCoy]

On Tue, Dec 19, 2017 at 08:56:20PM +0100, Helmut Grohne wrote:
> A slightly better way would be using AC_PATH_TOOL (with the same
> arguments) and the only difference here is considering $ac_tool_prefix.
> The recommended way is using the PKG_PROG_PKG_CONFIG macro from
> pkg-config tough. This macro will result in an empty PKG_CONFIG variable
> if pkg-config happens to not be found rather than the "no" value
> depicted above.

http://tirania.org/blog/archive/2012/Oct-20.html had some strong words
to say about using pkg.m4.  Are those concerns still valid?  Should
pkg.m4's macros be recommended or simply AC_PATH_TOOL?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#885792: stlcmd: stl_boolean not properly installed

[John Allwine]

Package: stlcmd
Version: 1.0-1
Severity: normal

The command stl_boolean is not properly installed using the Makefile
from v1.0.

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

Kernel: Linux 4.9.36-moby (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages stlcmd depends on:
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libstdc++6  6.3.0-18

stlcmd recommends no packages.

stlcmd suggests no packages.

-- no debconf information

Bug#701231: lintian: NDEBUG in compilation logs

[Chris Lamb]

tags 701231 + moreinfo
thanks

Hi,

> It would really be terrific to grep throught the compilation logs
> and check for the presence of -DNDEBUG.

(Alas, Lintian does not have access to this.)

> Another approach could be to grep through d/rules files for expression like:
>
> -DCMAKE_BUILD_TYPE:STRING=Release

Is this still valid? Would you still find it useful...? I'm not
terribly convinced at the moment :)


Regards,

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

Bug#884124: iproute2: Add iproute2-dev package

[Andreas Henriksson]

Control: tags -1 = wontfix

Hello Evgenii Smirnov,

On Mon, Dec 11, 2017 at 07:19:27PM +0100, Evgenii Smirnov wrote:
> Package: iproute2
> Version: 4.3.0-1ubuntu3.16.04.2
> Severity: wishlist
> Tags: patch
> 
> ip link tool has an ability to use external shared libraries for 
> defining custom device kinds which will be managed by the tool.
> To build such libraries three header files are needed. It would 
> be great to provide this headers in a dev package.

There used to be an iproute-dev package, which was removed by me.
There where no legitimate users, only abusers of this internal code
which is not a proper library to export as is for external consumption.
Also the internal libnetlink is as far as I know being phased out
even for internal iproute2 usage in favour of libmnl.
The existing users where ported over to libmnl where needed when
the iproute-dev package was removed.
I would suggest you base your own code around libmnl where possible
and if you're really modifying the iproute2 internals, then do that
by patching the iproute2 source (via debian/patches/) and rebuild
the package from source. If libnetlink is not yet fully phased out
in upstream iproute2 I'm convinced your help in porting it over to
libmnl is welcome as well! :)

I'm thus tagging this bug report as wontfix based on the historical
information and suggesting that it should be closed (but both of
these are really up to the new maintainers to decide on).

Regards,
Andreas Henriksson

Bug#702349: lintian should not complain about hardening for package written in pure Ocaml

[Chris Lamb]

tags 702349 + moreinfo
thanks

Hi,

> lintian should not complain about hardening for package written
> in pure Ocaml

Any update on this? Does Lintian need to do anything anymore? :)


Regards,

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

Bug#885618: kde-l10n-de lacks German translation for kmail2

[Hans]

Hi Pino,

please note, that this bug is in version 17.08.3, too. I installed it and got 
the same problem as described. Maybe you might want to recheck this, before it 
goes into testing. Maybe this bugreport should be reopened? 

Best regards

Hans

> This was done on purpose, because (hopefully soon) the KDEPIM 17.08.3
> stack, where each package carries its own translations, will migrate to
> testing.

> This is just a temporary issue, and not something we need to fix.

-- 
Pino Toscano

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Russ Allbery]

Markus Koschany  writes:

> Ok I can see the misunderstanding now. The above statement would be
> incorrect for freeorion because it translates to:

> You are allowed to use the files under GPL-2 and Permissive-License-1
> and Permissive-License-2 and ...

> But this is not true. Not all files are dual/triple/-licensed. Actually
> no file is even dual-licensed.

That's not what "and" means.  That would be "or".  "and" means you have to
follow all of those licenses when using a work composed of those files,
which sounds correct to me.

It's not correct if you take one of the files from the group in isolation;
in that case, you probably only have to follow one of the licenses.  But
that gets back to the question of just what we're supposed to be
documenting in debian/copyright.

> But if there is even one file which is differently licensed like

> Files: src/parser.c
> Copyright: 2009, John Jay
> License: Expat

> you have to mention that in d/copyright. Otherwise your copyright file
> would be incomplete/incorrect under the current Policy requirements.
> This is reject-worthy.

Policy does not require that.  ftpmaster might, which is not quite the
same thing.

> However upstream could simply state that all software is GPL-2+ licensed
> because the Expat license grants them the right to sublicense parser.c.

The Expat license grants *anyone* the right to do that, so the Debian
package maintainer can do this just as easily as upstream can.

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

Bug#750537: naive debian/rules parsing for python interpreter name

[Chris Lamb]

tags 750537 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=2c7f8a7d1b4565980556ae2a237658389edd3c5d


Regards,

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

Bug#885778: swami: Depends on libgnomecanvas

[Jaromír Mikeš]

2017-12-29 21:12 GMT+01:00 Jeremy Bicha :

> Source: swami
> Version: 2.0.0+svn389-5
> Severity: important
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs libgnomecanvas
> 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.
>
> Your package depends and or build-depends on libgnomecanvas.
>
> Please port your package to GTK3 and related maintained libraries.
> Otherwise, please consider requesting that your package be removed from
> Debian to help us complete this goal.
>
> [1] https://lists.debian.org/debian-devel/2017/10/msg00299.html


​Hi ​Joshua,

as you see swami needs to be ported to GTK3 otherwise will be removed from
debian
with next debian release.
Please let me know if there is a plan such update.

best regards

mira

Bug#885781: petri-foo: Depends on libgnomecanvas

[Jaromír Mikeš]

2017-12-29 21:16 GMT+01:00 Jeremy Bicha :

> Source: petri-foo
> Version: 0.1.87-4
> Severity: important
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs libgnomecanvas
> 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.
>
> Your package depends and or build-depends on libgnomecanvas.
>
> Please port your package to GTK3 and related maintained libraries.
> Otherwise, please consider requesting that your package be removed from
> Debian to help us complete this goal.
>
> [1] https://lists.debian.org/debian-devel/2017/10/msg00299.html


​Hi James,

as you see petri-foo needs to be ported to GTK3 otherwise will be removed
from debian
with next debian release.
Please let me know if there is any plan for fixing this issue.

best regards

mira ​

Bug#885325: Similar issue: Mount points not found by apache2 and another services

[Michael Biebl]

Am 29.12.2017 um 13:03 schrieb Sumit Madan:
> I'll try that tomorrow evening and inform you; I'm not at home
> currently. But what I can tell is that the behavior over SSH has been
> changed. In the past I often created mounts over SSH.

My guess is that this is related to this upstream change

https://github.com/systemd/systemd/commit/652bb2637aee54e3503a22d2928a929ecd7a84b3

and ssh.service using

RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

See https://github.com/systemd/systemd/issues/7761#issuecomment-354507016

-- 
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#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Vincent Blut]

On Fri, Dec 29, 2017 at 08:09:07PM -0200, Gabriel F. T. Gomes wrote:

On 29 Dec 2017, Vincent Blut wrote:


With this release, you can close #847971 too. ;-)


Oh, great! :)

I added this information to the changelog so that the bug gets closed
automatically  (I also resubmitted to mentors).


Awesome, thanks Gabriel!


Thanks.


You’re welcome,
Vincent


signature.asc
Description: PGP signature

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Markus Koschany]

Am 28.12.2017 um 23:10 schrieb Russ Allbery:
> Markus Koschany  writes:
> 
>> Why do we add the BSD license to common-licenses but not MIT and zlib?
> 
> I'm not sure why the BSD license was included in common-licenses
> originally.  My theory was that it was to include all the licenses
> mentioned by name in the DFSG.  However, the version in common-licenses is
> specific to code whose copyright is held by the University of California,
> so it's not very useful.  Including it there in that form was probably a
> mistake.
> 
> We found multiple packages in Debian that referred to the common-licenses
> version of the BSD license but weren't actually released under that
> license.  That's why Policy now says to not reference the version of the
> BSD license in common-licenses.
> 
> We haven't removed it because it's very hard to do that.  There are still
> quite a few packages in the archive that reference it (many possibly
> incorrectly).
> 
> See https://bugs.debian.org/284340.

I see. Thanks for your explanation.

Apparently including more DFSG-licenses is a recurring theme. It is
telling that this even goes back to 2004. One faction would like to see
BSD/MIT/zlib aka permissive short-licenses included, the other side
believes this could be ambiguous and mistakes are inevitable.

*sigh*

This is like prohibiting cars for transportation because they could be
used as weapons or football matches because someone could get hurt. I
believe we make life for us more difficult than necessary. Well, I guess
it can't be helped...






signature.asc
Description: OpenPGP digital signature

Bug#829046: recap

[Sergio Durigan Junior]

On Friday, December 29 2017, Pirate Praveen wrote:

> On 12/29/2017 11:45 PM, Sergio Durigan Junior wrote:
>
>> I would also like to notice that I'm still working on my personal copy
>> of the repository, located at:
>> 
>>   https://git.sergiodj.net/debian/pagure.git/
>> 
>> Although I appreciate the help from Boyuan Yang, I think the pagure.git
>> repository on collab-maint is very disorganized and hard to work on.
>> Since we're going to move from Alioth to salsa.debian.org anyway, I
>> think this is a good opportunity to readjust the current repository
>> (without losing Boyuan Yang's changes, of course).
>> 
>> Pirate, I am not yet a DD, so could you please create a "pagure" project
>> under the Debian group on salsa.debian.org and put me as the
>> responsible?  My username there is "sergiodj-guest".
>
> Created the repo and made you a master.
> https://salsa.debian.org/debian/pagure

Thanks, Pirate!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Sergio Durigan Junior]

On Friday, December 29 2017, Gabriel F. T. Gomes wrote:

> On 29 Dec 2017, Sergio Durigan Junior wrote:
>>On Friday, December 29 2017, Gabriel F. T. Gomes wrote:
>>> On 22 Dec 2017, Sergio Durigan Junior wrote:
>>>
>>Yeah, that's right.  I'm still using git.debian.org for my packages,
>>but I should change that as well.
>
> I changed to the new server and fixed the Vcs-* fields accordingly:
>
> https://salsa.debian.org/gabrielftg-guest/bash-completion-debian/commit/f2140c2633a8849d423d475a91db9ba40ff840c9
>
>>Cool.  As I said, I consider this to be a matter of preference; I
>>personally wouldn't bother to see /etc/bash_completion.d/ still there
>>in the next release.  But thanks for doing that.
>
> Also fixed:
>
> https://salsa.debian.org/gabrielftg-guest/bash-completion-debian/commit/e4185da001ceafbc713806faa4315cb8443471be
>
It's also a good idea to bump the Standards-Version to 4.1.2 now.  
>>>
>>> OK.  
>>
>>4.1.3 now :-).
>
> Also fixed:
>
> https://salsa.debian.org/gabrielftg-guest/bash-completion-debian/commits/unstable

Thanks for doing that.

So, unfortunately salsa doesn't provide a good way for non-DDs to create
projects under the Debian group, which is the equivalent of the
"collab-maint" namespace on Alioth.  For that reason, the best approach
in this case would be to ask a DD to create the "bash-completion"
project under the Debian group, and put you as the responsible for it.
This is the best way because it guarantees that other developers will
have access to the repository if you go AWOL.

I am not yet a DD (waiting on my process to advance), so I can't do it
for you :-(.

> Thanks for the reviews, so far. :) <3
>
> If and when you can, could you review these last changes?
> If so, would you also be willing to sponsor the package?
> (it's on mentors: https://mentors.debian.net/package/bash-completion)

After the project is created under the Debian group and you update the
Vcs-* fields accordingly, I consider this package as ready for upload.
As I'm not yet a DD, I can't really sponsor your changes, but I can
certainly put you in touch with someone who can if you need.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

On 29 Dec 2017, Vincent Blut wrote:

>With this release, you can close #847971 too. ;-)

Oh, great! :)

I added this information to the changelog so that the bug gets closed
automatically  (I also resubmitted to mentors).  

Thanks.


pgpLrqiNCueS5.pgp
Description: OpenPGP digital signature

Bug#839880: proftpd-basic: proftpd server instance crashed with signal 11

[Hilmar Preuße]

On 28.12.2017 14:53, Hilmar Preuße wrote:

Добры бечер Олег,

On my system the addr2line command gives only useful results if I use
the numbers in (), like this. At least output below makes sense to me.
What does your addr2line returns?

hille@amd64-sid:~$ addr2line -e /usr/sbin/proftpd 0x55e39fd633b0
??:0
hille@amd64-sid:~$ addr2line -e /usr/sbin/proftpd 0x1f3b0
./src/pool.c:546

Hilmar

> Hi Олег,
> 
> did to try to run addr2line as described on [1]? Does is print something
> useful. The command is provided by package binutils.
> 
> Hilmar
> 
> [1] http://www.proftpd.org/docs/howto/Compiling.html
> 
>> Got some positive results
>>
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): -BEGIN STACK TRACE-
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [0] /usr/sbin/proftpd(+0x1f3b0)
>> [0x55e39fd633b0]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [1] /usr/sbin/proftpd(+0x1f3b0)
>> [0x55e39fd633b0]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [2] /usr/sbin/proftpd(palloc+0x37)
>> [0x55e39fd634b2]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [3] /usr/sbin/proftpd(pcalloc+0x32)
>> [0x55e39fd63547]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [4]
>> /usr/sbin/proftpd(pr_response_add+0xee) [0x55e39fd8de25]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [5] /usr/lib/proftpd/mod_sftp.so(+0x3c7ef)
>> [0x7f04249dd7ef]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [6]
>> /usr/lib/proftpd/mod_sftp.so(sftp_auth_handle+0x62) [0x7f04249ddc31]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [7]
>> /usr/lib/proftpd/mod_sftp.so(sftp_ssh2_packet_handle+0x363)
>> [0x7f04249bc9ad]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [8] /usr/lib/proftpd/mod_sftp.so(+0xfa07)
>> [0x7f04249b0a07]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [9] /usr/sbin/proftpd(+0x19ee3)
>> [0x55e39fd5dee3]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [10] /usr/sbin/proftpd(+0x1a706)
>> [0x55e39fd5e706]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [11] /usr/sbin/proftpd(+0x1bf2f)
>> [0x55e39fd5ff2f]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [12] /usr/sbin/proftpd(main+0x94b)
>> [0x55e39fd60ce3]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [13]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f04282e1561]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): [14] /usr/sbin/proftpd(_start+0x2a)
>> [0x55e39fd5adaa]
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): -END STACK TRACE-
>> 2017-12-28 07:32:21,761 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): ProFTPD terminating (signal 11)
>> 2017-12-28 07:32:21,762 sim-ng-data proftpd[26614] sim-ng-data
>> (PG10.local[192.168.3.17]): SSH2 session closed.
>>
>>
>> 28.12.2017 0:09, Hilmar Preuße пишет:
>>> On 26.12.2017 09:41, Мороз Олег wrote:
>>>
>>> Hi Олег,
>>>
 Have made changes in

 /etc/security/limits.d/core_dump.conf

 then set path to save code dumps into /tmp

 vniiem@sim-ng-data /tmp % /sbin/sysctl -a -r kernel.core
 kernel.core_pattern = /tmp/core.%e.%p.%t
 kernel.core_pipe_limit = 0
 kernel.core_uses_pid = 0

 Then relogin and reinstall proftpd, tried to login to ftp , but no
 core.dump was generated

>>> So, proftpd seems to trap the SIGSEGV (sig11) and performs a grace
>>> shutdown upon SIG11. I've found [1] giving some hints to debug crash
>>> problems. I've put debug binaries using --enable-devel=stacktrace on
>>> [2]. I've crashed the binaries using a SIGSEGV and found a stack trace
>>> in /var/log/proftpd/proftpd.log:
>>>
>>> 2017-12-27 21:51:07,528 amd64-sid proftpd[23112] amd64-sid: -BEGIN
>>> STACK TRACE-
>>> 2017-12-27 21:51:07,528 amd64-sid proftpd[23112] amd64-sid: [0]
>>> /lib/x86_64-linux-gnu/libc.so.6(__select+0x13) [0x7fd99e1c3cc3]
>>> 2017-12-27 21:51:07,529 amd64-sid proftpd[23112] amd64-sid: [1]
>>> /lib/x86_64-linux-gnu/libc.so.6(__select+0x13) [0x7fd99e1c3cc3]
>>> 2017-12-27 21:51:07,529 amd64-sid proftpd[23112] amd64-sid: [2]
>>> /usr/sbin/proftpd(+0x1a2d0) [0x5559bc50c2d0]
>>> 2017-12-27 21:51:07,529 amd64-sid proftpd[23112] amd64-sid: [3]
>>> /usr/sbin/proftpd(+0x1bf2f) [0x5559bc50df2f]
>>> 2017-12-27 21:51:07,529 

Bug#885791: O: lbcd -- return system load via UDP for remote load balancers

[Russ Allbery]

Package: wnpp
Severity: normal

I am orphaning the lbcd package.

The package description is:
 lbcd is a daemon that answers UDP queries for system load information and
 returns such information as uptime, load, number of logged-in users,
 percentage free of /tmp and /var/tmp, and whether there is a user on the
 console.  It is intended for use with a load balancing system, and is
 particularly useful for such things as UNIX clusters for remote login
 where a traditional hardware load balancing solution doesn't work as well.
 .
 No load balancing system is included in this package, only the client
 daemon and a simple Perl script to query it.  No security or access
 control is done by the daemon, so access control must be done via
 iptables, a firewall, or an equivalent system.

Note that this package is also orphaned upstream.  It's useful for a quick,
unauthenticated view of system health, but modern load balancing techniques
have made it mostly irrelevant today.

I no longer use the package (or maintain it -- I used to be upstream), and
doubt I will want it again in the forseeable future.

Bug#885790: Add DH_EXTRA_ADDON check

[Paul R. Tagliamonte]

Thank you!

Paul

On Dec 29, 2017 4:50 PM, "Chris Lamb"  wrote:

> tags 885790 + pending
> thanks
>
> Applied in Git, many thanks! I expect it will be in unstable in about
> 4 or 5 days.
>
>   https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=
> 4d4cb5c492067e04ee6957c476c112f988b51760
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#885790: Add DH_EXTRA_ADDON check

[Chris Lamb]

tags 885790 + pending
thanks

Applied in Git, many thanks! I expect it will be in unstable in about
4 or 5 days.

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=4d4cb5c492067e04ee6957c476c112f988b51760


Regards,

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

Bug#883087: consolation: very slow restart

[Yuri D'Elia]

On Fri, Dec 29 2017, Bill Allombert wrote:
>> It would be nice to have a non-forking mode though.
>
> So you would like a command line option that prevent forking ?
> What should be the name ? --no-daemon ?

I've seen and like "-f" for "foreground" personally, but --no-daemon is
just as good: your call. This would avoid the need for a pid file in
both cases:

With start-stop-daemon you can combine -m -b to make a pid file for you.
With systemd just change Type=simple (or remove it as it's default).