Bug#898135: bibutils: CVE-2018-10773 CVE-2018-10774 CVE-2018-10775

[Salvatore Bonaccorso]

Hi David,

On Mon, May 07, 2018 at 04:19:22PM -0300, David Bremner wrote:
> Salvatore Bonaccorso  writes:
> 
> > Source: bibutils
> > Version: 6.2-1
> > Severity: normal
> > Tags: security upstream
> >
> > Hi,
> >
> > The following vulnerabilities were published for bibutils. This report
> > is to mainly make aware of the issues, I'm not sure if upstream were
> > made aware of those, as the CVE references by now just consist of
> > pointing to reproducers.
> >
> > CVE-2018-10773[0]:
> > | NULL pointer deference in the addsn function in serialno.c in
> > | libbibcore.a in bibutils through 6.2 allows remote attackers to cause a
> > | denial of service (application crash), as demonstrated by copac2xml.
> >
> > CVE-2018-10774[1]:
> > | Read access violation in the isiin_keyword function in isiin.c in
> > | libbibutils.a in bibutils through 6.2 allows remote attackers to cause
> > | a denial of service (application crash), as demonstrated by isi2xml.
> >
> > CVE-2018-10775[2]:
> > | NULL pointer dereference in the _fields_add function in fields.c in
> > | libbibcore.a in bibutils through 6.2 allows remote attackers to cause a
> > | denial of service (application crash), as demonstrated by end2xml.
> >
> 
> Thanks for the report. The use of "remote attacker" seems odd to me,
> since bibutils does not provide any network functionality.

Note those are just the CVE descriptions from the MITRE database, it's
actually maybe even a bit of a stretch to call all those
vulnerabilities (rather than just bugs). I guess the reporter had in
mind a webexposed service which uses bibutils when requesting the CVE
and mentioning remote attacker and denial of service. My intention
was, given the reporter of those probably did not notify upstream,
upstream could be notified of those bugs at least via Debian. We have
marked all those arleady as "unimportant" in the security tracker.

Regards,
Salvatore

Bug#898152: ITP: berrynet -- deep learning gateway

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
Owner: "Ying-Chun Liu (PaulLiu)" 
Severity: wishlist

* Package name: berrynet
  Version : 2.2.0
  Upstream Author : DT42 http://www.dt42.io/
* URL : https://github.com/DT42/BerryNet
* License : GPLv3+
  Programming Lang: python, javascript
  Description : deep learning gateway
 BerryNet turns devices into an intelligent gateway with deep learning
 running on it. No internet connection is required, everything is done
 locally on the local LAN and the IoT devices.



If we have this package inside Debian, we can use deep learning models
easier with GUI. Also when this package is in Debian, BerryNet will no
longer specific to Raspberry Pi 3. All arches/devices can be an
intelligent gateway and can provide more resources than RPi3.

-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature

Bug#885957: Not fixed.

[Nye Liu]

Not fixed

random: Trying to read entropy from /dev/random
Configuration file: /etc/hostapd/hostapd.conf
ctrl_interface_group=4 (from group name 'adm')
nl80211: TDLS supported
nl80211: TDLS external setup
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Using driver-based off-channel TX
nl80211: TDLS channel switch
nl80211: Driver-advertised extended capabilities (default) - 
hexdump(len=8): 04 00 00 00 00 00 00 40
nl80211: Driver-advertised extended capabilities mask (default) - 
hexdump(len=8): 04 00 00 00 00 00 00 40

nl80211: Use separate P2P group interface (driver advertised support)
nl80211: Enable multi-channel concurrent (driver advertised support)
nl80211: use P2P_DEVICE support
nl80211: interface wlan0 in phy phy0
nl80211: Set mode ifindex 4 iftype 3 (AP)
nl80211: Failed to set interface 4 to mode 3: -16 (Device or resource busy)
nl80211: Try mode change after setting interface down
nl80211: Set mode ifindex 4 iftype 3 (AP)
nl80211: Mode change succeeded while interface is down
nl80211: Setup AP(wlan0) - device_ap_sme=0 use_monitor=0
nl80211: Subscribe to mgmt frames with AP handle 0x555d9de51e20
nl80211: Register frame type=0xb0 (WLAN_FC_STYPE_AUTH) 
nl_handle=0x555d9de51e20 match=
nl80211: Register frame type=0x0 (WLAN_FC_STYPE_ASSOC_REQ) 
nl_handle=0x555d9de51e20 match=
nl80211: Register frame type=0x20 (WLAN_FC_STYPE_REASSOC_REQ) 
nl_handle=0x555d9de51e20 match=
nl80211: Register frame type=0xa0 (WLAN_FC_STYPE_DISASSOC) 
nl_handle=0x555d9de51e20 match=
nl80211: Register frame type=0xc0 (WLAN_FC_STYPE_DEAUTH) 
nl_handle=0x555d9de51e20 match=
nl80211: Register frame type=0x40 (WLAN_FC_STYPE_PROBE_REQ) 
nl_handle=0x555d9de51e20 match=
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=04
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=0501
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=0503
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=0504
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=06
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=08
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=09
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=0a
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=11
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x555d9de51e20 match=7f

rfkill: initial event: idx=0 type=1 op=0 soft=0 hard=0
nl80211: Add own interface ifindex 7 (ifidx_reason 4)
nl80211: if_indices[16]: 7(4)
nl80211: Add own interface ifindex 4 (ifidx_reason -1)
nl80211: if_indices[16]: 7(4) 4(-1)
nl80211: Adding interface wlan0 into bridge eth1
phy: phy0
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Previous country code 00, new country code US
Continue interface setup after channel list update
ctrl_iface not configured!
random: Got 20/20 bytes from /dev/random
RTM_NEWLINK: ifi_index=4 ifname=wlan0 operstate=2 linkmode=0 
ifi_family=0 ifi_flags=0x1002 ()

nl80211: Ignore interface down event since interface wlan0 is up
RTM_NEWLINK: ifi_index=4 ifname=wlan0 operstate=2 linkmode=0 
ifi_family=0 ifi_flags=0x1003 ([UP])
RTM_NEWLINK: ifi_index=4 ifname=wlan0 operstate=2 linkmode=0 master=7 
ifi_family=0 ifi_flags=0x1003 ([UP])
RTM_NEWLINK: ifi_index=4 ifname=wlan0 operstate=2 linkmode=0 master=7 
ifi_family=0 ifi_flags=0x1003 ([UP])
RTM_NEWLINK: ifi_index=4 ifname=wlan0 master=7 operstate=2 ifi_family=7 
ifi_flags=0x1003 ([UP])

nl80211: Add ifindex 7 for bridge eth1
nl80211: Add own interface ifindex 7 (ifidx_reason 4)
nl80211: ifindex 7 already in the list
RTM_NEWLINK: ifi_index=7 ifname=eth1 operstate=6 linkmode=0 ifi_family=0 
ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])

wlan0: Event INTERFACE_STATUS (5) received
Unknown event 5
Channel list update timeout - try to continue anyway
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz 20 mBm
nl80211: 2457-2482 @ 20 MHz 20 mBm (no IR)
nl80211: 2474-2494 @ 20 MHz 20 mBm (no OFDM) (no IR)
nl80211: 5170-5250 @ 80 MHz 20 mBm (no IR)
nl80211: 5250-5330 @ 80 MHz 20 mBm (DFS) (no IR)
nl80211: 5490-5730 @ 160 MHz 20 mBm (DFS) (no IR)
nl80211: 5735-5835 @ 80 MHz 20 mBm (no IR)
nl80211: 57240-63720 @ 2160 MHz 0 mBm
nl80211: Added 802.11b mode based on 802.11g information
ACS: Automatic channel selection started, this may take a bit
ACS: Scanning 1 / 5
wlan0: nl80211: scan request
nl80211: Passive scan requested
Scan requested (ret=0) - scan timeout 10 seconds
wlan0: interface state COUNTRY_UPDATE->ACS
wlan0: ACS-STARTED
Interface initialization will be completed in a callback (ACS)
nl80211: Drv Event 

Bug#897572: urandom hang in early boot

[Ben Caradoc-Davies]

On 08/05/18 15:55, Ben Caradoc-Davies wrote:
If something calls getrandom without GRND_NONBLOCK while crng_init==1 
(during early boot)
I now have conclusive evidence that this is the cause of the hang. If I 
add a printk:


diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..b7358cc32f42 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2021,6 +2021,9 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, 
size_t, count,

if (!crng_ready()) {
if (flags & GRND_NONBLOCK)
return -EAGAIN;
+   printk(KERN_NOTICE "random: %s: getrandom without "
+   "GRND_NONBLOCK while crng not ready\n",
+   current->comm);
ret = wait_for_random_bytes();
if (unlikely(ret))
return ret;

I get these at the console just before the hang:

random: plymouthd: uninitialized urandom read (8 bytes read)
random: plymouthd: uninitialized urandom read (8 bytes read)
random: plymouthd: getrandom without GRND_NONBLOCK while crng not ready

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#898151: bpfcc: Not migrate to testing

[Shengjing Zhu]

Source: bpfcc
Severity: normal

Dear Maintainer,

bpfcc didn't migrate to testing. I see you have tried to request RoM
but still not migrated. After consulting on #debian-dev

12:18 I think it is because arch-all packages are depending on 
packages that only exist on some arches 
https://qa.debian.org/excuses.php?package=bpfcc
12:19 IIRC the release team requires those deps to be satisfiable on 
i386, so I think bpfcc will need hinting into testing
12:19 I got this in an i386 chroot: python3-bpfcc : Depends: libbpfcc 
(>= 0.5.0-5) but it is not installable
12:19  oddly, https://qa.debian.org/excuses.php?package=bpfcc says 
"Migration status: OK: Will attempt migration (Any information below is purely 
informational)" -- "Valid candidate"
12:20  so not everything is playing by the same rules if it still 
isn't :)
12:20 yeah, testing migration is sometimes confusing. the log link 
usually explains things
12:21 Maybe that's it
12:21 
https://release.debian.org/doc/britney/short-intro-to-migrations.html#migration-phase-2-installability-regression-testing
12:22 I'd suggest reportbug release.debian.org, chose other, request 
hinting


pabs suggests to request britney hints to get the bpfcc migrated.


signature.asc
Description: PGP signature

Bug#898150: desktop-base: misspelled identifier "gloabl" should be "global" in softwaves.script

[Ben Caradoc-Davies]

Package: desktop-base
Version: 9.0.5
Severity: normal

Dear Maintainer,

"gloabl" should be "global" at line 992 in
/usr/share/plymouth/themes/softwaves/softwaves.script.

Kind regards,
Ben.



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

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

Versions of packages desktop-base depends on:
ii  dpkg 1.19.0.5+b1
ii  librsvg2-common  2.40.20-2

desktop-base recommends no packages.

Versions of packages desktop-base suggests:
ii  xfce4  4.12.4

-- no debconf information

Bug#897572: urandom hang in early boot

[Ben Caradoc-Davies]

On 08/05/18 14:00, Ben Hutchings wrote:

You keep saying this, but based on my reading of the code I don't see
how reads from /dev/urandom can end up blocking.


Ben, I think you are right. I have picked through the code in detail and 
none of the changes affect any substantive logic (except logging). I do 
not think urandom_read can ever block. The urandom warning may be from a 
previous read before the hang: related, but a red herring.


The *one* substantive change that is affected is getrandom:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n2007

If something calls getrandom without GRND_NONBLOCK while crng_init==1 
(during early boot):


- Before 43838a23a05f ("random: fix crng_ready() test"), this just falls 
thorough to urandom_read and everything seems to work (but is not 
cryptographically secure).


- After 43838a23a05f ("random: fix crng_ready() test"), this will call 
wait_for_random_bytes and hang waiting on mouse wiggles 
(cryptographically secure).


But what is calling getrandom without GRND_NONBLOCK? I could find 
nothing in the plymouth or systemd/udev codebase. Or is it something 
they spawn? I even read the plymouth softwaves.script.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#897631: [Fwd: Re: Kernel update breaks GDM]

[Ben Hutchings]

 Forwarded Message 
From: silvio.s...@gmail.com
To: Ben Hutchings 
Subject: Re: Kernel update breaks GDM
Date: Tue, 08 May 2018 01:07:55 +0200
Message-Id: <1525734475.1800.1.camel@localhost>

> Control: tag -1 moreinfo
> 
> On Thu, 03 May 2018 18:59:36 +0200 silvio.s...@gmail.com wrote:
> [...]
> > However soon after logging in (usually by the time I had written a
> > couple of commands) GDM would start and I could then log in from
> > the
> > GUI and from then on everything would work just fine. GDM would
> > however
> > not start if I didn't log in from the command line, instead the
> > system
> > would just hang indefinetly (I actually left it on for about 30 min
> > while going on lunch).
> 
> [...]
> 
> This may sound like a silly request, but does GDM start up if you
> wiggle the mouse for a few seconds?
> 
> Ben.
> 


No it doesn't. It starts only if I log in and only if I start typing
some command in the terminal after I've logged in.

If I wiggle the mouse for a while it just continues to hang. If I just
log in and don't type any command it doesn't start either. It's really
weird!

Here's what I've tried so far:

- I've added the "Debian-gdm" user to "video" group as well, thought it
might help, but it didn't.

- I updated the NVIDIA driver to both 384.130 and the newest 396-
version but neither of those helped.

- If I edit the "/etc/gdm3/daemon.conf"-file and comment out the
"#WaylandEnable=false"-line the NVIDIA driver does load (I can hear the
fans of my graphics card go silent) but then I get a completely blank
screen.


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

Bug#898149: Recommends: freerdp-x11 won't be in buster

[Shengjing Zhu]

Package: krdc
Version: 4:17.08.3-1
Severity: serious
Justification: Policy 2.2.1

Dear Maintainer,

Due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890928
freerdp-x11 won't be in buster, was superseded by freerdp2-x11.

Policy 2.2.1:

the packages in main must not require or recommend a package outside of main
for compilation or execution.

Versions of packages krdc depends on:
ii  libc6 2.27-3
ii  libkf5bookmarks5  5.44.0-1
ii  libkf5completion5 5.44.0-1
ii  libkf5configcore5 5.44.0-1
ii  libkf5configgui5  5.44.0-1
ii  libkf5configwidgets5  5.44.0-1
ii  libkf5coreaddons5 5.44.0-1
ii  libkf5dnssd5  5.44.0-1
ii  libkf5i18n5   5.44.0-1
ii  libkf5kcmutils5   5.44.0-1
ii  libkf5notifications5  5.44.0-1
ii  libkf5notifyconfig5   5.44.0-1
ii  libkf5service-bin 5.44.0-1
ii  libkf5service55.44.0-1
ii  libkf5wallet-bin  5.44.0-1
ii  libkf5wallet5 5.44.0-1
ii  libkf5widgetsaddons5  5.44.0-1
ii  libkf5xmlgui5 5.44.0-2+b1
ii  libqt5core5a  5.10.1+dfsg-5
ii  libqt5gui55.10.1+dfsg-5
ii  libqt5widgets55.10.1+dfsg-5
ii  libqt5xml55.10.1+dfsg-5
ii  libstdc++68.1.0-1
ii  libvncclient1 0.9.11+dfsg-1

Versions of packages krdc recommends:
ii  freerdp-x11  1.1.0~git20140921.1.440916e+dfsg1-15

Versions of packages krdc suggests:
ii  khelpcenter  4:17.08.3-1
pn  krfb 

-- no debconf information


signature.asc
Description: PGP signature

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Chris Lamb]

tags 898136 + moreinfo
thanks

Hi Russ,

> I just now checked, and the packages currently diagnosed with this tag [1]
> are 100% false positives, which makes me wonder if this tag should just be
> deleted.

Always possible. Let's let pabs chime in; tagging as moreinfo for now... :)


Regards,

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

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Chris Lamb]

tags 889816 + pending
thanks

Hi Raphael,

> >  "W: latest-debian-changelog-entry-without-new-version"
> > 
> > Do you think it's still worth adding (essentially) an "E:" version
> > of this? I would tend to be in favour, given that at least I did not
> > see this warning when uploading "that" Django version.
> 
> I think this warning was not in place yet when you made that mistake.

This warning was added in 2007 so it's likely I just missed it. Anyway,
I have implemented this in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/bb13a144e8b2b4326dc5a1d65bf7a1b8f1881247

> Still I think that [latest-debian-changelog-entry-without-new-version]
> was not correctly implemented. It should really ensure that […]

(If so, could you clone and/or re-file etc. with concrete examples?)


Best wishes,

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

Bug#883218: RFS: elpy/1.20.0-1 [ITP]

[Chris Lamb]

Hi Nicholas,

> > Anyway, thank you for your kind comments. Do let me know if/when
> > you have any updates to the package, particularly one that fixes the
> > FTBFS twice-in-a-row.
> 
> This was solved in #896998 "python-pip: missing required _vendor
> module. Broken ${python:Depends}?". 

Hm? I think you misparsed - your package FTBFS when built twice in a
row right now AFACIT. Nothing to do with tests or pip or anything..


Regards,

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

Bug#880612: RFS: imenu-list/0.8-1 [ITP]

[Chris Lamb]

Hi Nicholas,

> > I am looking for a sponsor for my package "imenu-list".  It is a
> > dependency for the spacemacs packaging effort and should also be a
> > recommended dependency for fountain-mode (see blocking bugs for more
> > info).

Uploaded.


Regards,

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

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Russ Allbery]

Chris Lamb  writes:

> Just to confirm; it currently it reports for all packages that provide
> mail-transport-agent, ie:

>   citadel-server
>   courier-mta
>   dma
>   esmtp-run
>   exim4
>   exim4-daemon-heavy
>   exim4-daemon-light
>   masqmail
>   msmtp-mta
>   nullmailer
>   opensmtpd
>   postfix
>   qmail-run
>   sendmail-bin
>   ssmtp

> .. and the suggestion is that this list is (essentially) reduced to
> just exim4?

> If so, I don't believe this would warrant the change in severity.

Some more research:

I looked at the original bug report from Paul Wise (cc'd) (#892144), and
the motivation was unclear to me.  Were there packages in the archive that
depended on only one MTA and weren't MTA add-ons or otherwise
intentionally locked to just one MTA?

I just now checked, and the packages currently diagnosed with this tag [1]
are 100% false positives, which makes me wonder if this tag should just be
deleted.

At first glance, the bug this tag is trying to diagnose seems unlikely to
me.  I'm not sure how many maintainers intended to depend on a generic
mail-transport-agent and just picked one out of a hat (although I admit
the lack of documentation in Policy for how to declare this dependency
doesn't help).  In contrast, add-ons for one specific MTA, or management
interfaces that only know how to configure one specific MTA, are fairly
common.

[1] 
https://lintian.debian.org/tags/depends-on-mail-transport-agent-without-alternatives.html

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

Bug#897582: closed by Adam Borowski <kilob...@angband.pl> (Re: Bug#897582: RFS: xalan/1.11-7)

[Bill Blough]

On Tue, May 08, 2018 at 12:51:05AM +, Debian Bug Tracking System wrote:
> Date: Tue, 8 May 2018 02:49:25 +0200
> From: Adam Borowski 
> 
> One quite visible change is that the location of documentation has changed. 
> This might be interesting to the user.
> 
> Uploaded.
> 

To be honest, I missed that.  I need to make sure I don't forget to use
debdiff in the future.

Though it looks like it wasn't the documentation, but rather the
examples, that moved from the -doc to the -dev package.  It wasn't a
change that I made, but rather, looks like fallout from going to dh
compat 11.

I'll do another upload to fix it.  Thanks for pointing it out.  And
thanks for your upload, and for giving me permissions.

Best regards,
Bill

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Chris Lamb]

Hi Scott.


> Limiting it to packages that depend on exim4 would address all the false 
> positives I saw (since I mostly know about postfix stuff).

Just to confirm; it currently it reports for all packages that
provide mail-transport-agent, ie:

  citadel-server
  courier-mta
  dma
  esmtp-run
  exim4
  exim4-daemon-heavy
  exim4-daemon-light
  masqmail
  msmtp-mta
  nullmailer
  opensmtpd
  postfix
  qmail-run
  sendmail-bin
  ssmtp

.. and the suggestion is that this list is (essentially) reduced to
just exim4?

If so, I don't believe this would warrant the change in severity.


Best wishes,

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

Bug#897572: urandom hang in early boot

[Ben Hutchings]

On Tue, 2018-05-08 at 11:12 +1200, Ben Caradoc-Davies wrote:
> On 08/05/18 05:34, Laurent Bigonville wrote:
> > Apparently it's also happening for other applications that are starting 
> > later during the boot like GDM.
> > Somebody has reported an issue on IRC where GDM was taking upto 8 
> > minutes to start (dmesg was showing several "random: systemd: 
> > uninitialized urandom read (16 bytes read)" during boot)
> > That problem might impact lot of people I'm afraid.
> 
> systemd is the underlying cause: plymouthd uses libudev1, which expects 
> getrandom/urandom(?) to never block:
> https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L34
> 
> See discussion here about systemd usage of random numbers:
> systemd reads from urandom before initialization
> https://github.com/systemd/systemd/issues/4167
> 
> The new problem is that 43838a23a05f ("random: fix crng_ready() test") 
> turns an ugly warning and cryptographic weakness into an indefinite 
> hang. Security achieved!

You keep saying this, but based on my reading of the code I don't see
how reads from /dev/urandom can end up blocking.

(For the time being I've concentrated on fixing stretch, so I haven't
done substantial testing in unstable.)

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.



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

Bug#898038: caused by host

[Trent Lloyd]

The script regex should be improved not to check in the case you specify 
(and thus this patch should applied).


However host should *always* timeout after 5 seconds regardless. The bug 
in host that causes it to never timeout appears to be a relatively 
recently introduced behavior and on the Ubuntu side we did not see this 
in 9.10.3 but we do see this in 9.11.3. This bug can also trigger with 
actual nameservers that do exist - so your patch won't fix all instances 
of the issue but obviously will help for some.


It's possible however that this entire script can be removed with the 
latest nss-mdns updates that have migrated to testing, as I believe that 
should ignore multi-label .local queries from memory (would have to be 
verified), e.g. queries for a.b.local will pass through mdns into the 
normal resolver stack.


- Trent

Bug#898148: mysql-server: it does not allow me to change the database

[Fabián Bonetti]

Package: mysql-server
Version: 5.5.+default
Severity: important


it does not allow me to change the database.

/var/lib/mysql 

but I want to put the database on another disk.

"datadir" does not work ?. in the configuration.



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

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

Versions of packages mysql-server depends on:
ii  default-mysql-server  1.0.2

mysql-server recommends no packages.

mysql-server suggests no packages.

-- no debconf information

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Benjamin Kaduk]

On Mon, May 07, 2018 at 05:10:27PM +0100, Ben Hutchings wrote:
> On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote:
> 
> There are basically three "strengths" of random numbers available now:
> 
> Weak:   /dev/urandom
> Medium: getrandom(flags=0)
> Strong: /dev/random, getrandom(flags=GRND_RANDOM)
> 
> k5_get_os_entropy() has switched from weak/strong depending on the
> "strong" flag to always medium.  I think what you actually want is
> medium/strong.

At high risk of opening up the RNG debate that I did not want to
revisit, the current stance of upstream krb5 seems to fall into what
I'll call the "Schneier worldview", that a fully-seeded
well-designed CSPRNG can produce arbitrary amounts of random output
with no need to track "entropy depletion" or similar (emphasis on
fully-seeded).  So the question (for them) is not "strong" or
"weak", but rather "fully seeded" or "not seeded yet".  In this
worldview, if you have to choose between /dev/random and
/dev/urandom, (1) /dev/random is the only thing that actually
provides the guarantee you want, but (2) /dev/random is incredibly
painful for using "all the time", so you're tempted to use
/dev/urandom for cases where it's "less important", like session
keys, but reserve /dev/random for times when you really care about
the "fully seeded" property, like long-term keys.  When those were
the only choices, the 'strong' flag made sense.

Now, we have getrandom(), which is a great API and is pretty much
exactly what you want (again, at least in this worldview).  IIUC Ted
says that you should "just use getrandom" for your entropy needs and
not worry about /dev/*random.  I don't know whether he takes a
stance on the GRND_RANDOM flag, though.

Anyway, I mention this all in the hope that we can just drop this
line or discussion and let upstream krb5 decide what properties they
want from a CSPRNG, and not try to revisit that design.


To answer Sam's questions, in the above worldview, the right answer
for the KDC and the right answer for kadmind are the same -- just
use getrandom().  It provides the output of a high-quality CSPRNG,
and is guaranteed to block until fully seeded.  In this worldview,
the cryptographic quality of the (fully seeded) urandom pool is more
than adequate, so there's no need to ever pass GRND_RANDOM.

I'm certainly open to having krb5 ship a proof-of-concept
wait-for-entropy.service in unstable for a while, though it seems
like something better suited for libc or systemd core for the long
term.

If we need to for stretch, it would presumably be easy enough to
just add a stanza to the KDC's unit file to increase the timeout
(though how do we know what sort of timeout is "long enough"?).

> I'm going to start a discussion on debian-release, as we need to
> coordinate a solution across multiple packages.

Thanks, I'm glad someone with more time than me has already started
getting the right thing done.

> Jann Horn suggested improving systemd-random-seed.service so that it
> actually credits entropy after feeding saved random bits into the RNG. 
> But this will require some care to ensure we never use the same random
> bits twice (including on multiple systems built from the same system
> image).

Indeed, that's in the general case a rather hard problem.

-Ben


signature.asc
Description: PGP signature

Bug#895572: mupdf-tools: mutool fails with "Cannot convert between incompatible pixmaps"

[Kan-Ru Chen]

Hi,

Thanks for the report!

This is likely a upstream bug so I have forwarded the report to here: 
https://bugs.ghostscript.com/show_bug.cgi?id=699318

Kanru

On Tue, May 8, 2018, at 3:47 AM, Stefan Monnier wrote:
> Ping?
> 
> 
> Stefan
> 
> 
> Stefan Monnier  writes:
> 
> > Package: mupdf-tools
> > Version: 1.12.0+ds1-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Recently, Emacs's doc-view-mode started failing for me in some cases.
> > After tracking down the origin of the problem, it seems to be due to
> > a problem in `mutool`.
> > I can reproduce it with:
> >
> > mutool draw -o foo.png foo.pdf 1
> >
> > with the attached PDF file, which gives me:
> >
> > page foo.pdf 1error: Cannot convert between incompatible pixmaps
> > error: Cannot convert between incompatible pixmaps
> > warning: Ignoring error during interpretation
> > error: Cannot convert between incompatible pixmaps
> > warning: Ignoring error during interpretation
> > error: Cannot convert between incompatible pixmaps
> > warning: Ignoring error during interpretation
> > error: Cannot convert between incompatible pixmaps
> > warning: Ignoring error during interpretation
> >
> > even though both `evince` and `mupdf` display it just fine.
> >
> >
> > Stefan
> >
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers testing
> >   APT policy: (990, 'testing'), (500, 'stable')
> > Architecture: i386 (i686)
> >
> > Kernel: Linux 4.14.0-3-686-pae (SMP w/2 CPU cores)
> > Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=fr_CH.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages mupdf-tools depends on:
> > ii  libc62.27-3
> > ii  libfreetype6 2.8.1-2
> > ii  libharfbuzz0b1.7.2-1
> > ii  libjbig2dec0 0.13-6
> > ii  libjpeg62-turbo  1:1.5.2-2+b1
> > ii  libopenjp2-7 2.3.0-1
> > ii  zlib1g   1:1.2.8.dfsg-5
> >
> > mupdf-tools recommends no packages.
> >
> > mupdf-tools suggests no packages.
> >
> > -- no debconf information

Bug#897572: urandom hang in early boot

[Ben Caradoc-Davies]

On 08/05/18 05:34, Laurent Bigonville wrote:
Apparently it's also happening for other applications that are starting 
later during the boot like GDM.
Somebody has reported an issue on IRC where GDM was taking upto 8 
minutes to start (dmesg was showing several "random: systemd: 
uninitialized urandom read (16 bytes read)" during boot)

That problem might impact lot of people I'm afraid.


systemd is the underlying cause: plymouthd uses libudev1, which expects 
getrandom/urandom(?) to never block:

https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L34

See discussion here about systemd usage of random numbers:
systemd reads from urandom before initialization
https://github.com/systemd/systemd/issues/4167

The new problem is that 43838a23a05f ("random: fix crng_ready() test") 
turns an ugly warning and cryptographic weakness into an indefinite 
hang. Security achieved!


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#898147: Acknowledgement (gdm3: fails to start: ("Oops! A problem has occured!" screen))

[Leandro Doctors]

severity 898147 grave
found 898147 gdm3/3.28.1-1
thanks

Bug#898147: Acknowledgement (gdm3: fails to start: ("Oops! A problem has occured!" screen))

[Leandro Doctors]

found 898147 gdm3/3.28.1-1

Bug#898147: Acknowledgement (gdm3: fails to start: ("Oops! A problem has occured!" screen))

[Leandro Doctors]

severity 898147 grave

Bug#884141: gdm3: fails to start, no log info

[Leandro Doctors]

Hi, Jan,

I have just realized you did not provide any information regarding what
happens...
If you don't, it will be very difficult for anyone to help you.

I recommend you try filling the corresponding templates inside reportbug,
or reportbug-ng...

Best,
Leandro

Bug#884141: gdm3: fails to start, no log info

[Leandro Doctors]

Please disregard my previous message. It was meant for a new bug (which I
have just created).

Bug#898147: gdm3: fails to start: ("Oops! A problem has occured!" screen)

[Leandro Doctors]

Package: gdm3

Version: 3.28.1-1


--- Please enter the report below this line. ---

Dear Maintainer,

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

* What led up to the situation?

Installed GDM3.


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

For now, just started to do some debugging... (I copy the output of
relevant systemd-related commands below.)

  From what I could see in the log (journalctl), it seems to have something
to do with GLibC...
However, I don't know to which glibc/gdm3 version to downgrade to, as I
have all packages from testing...

* What was the outcome of this action?

When booting, GDM3 fails to start. It gives me the "Oops! A problem has
occured!" screen.
The system boots OK with both SDDM and LightDM.

* What outcome did you expect instead?

GDM to start correctly.


* Additional logs:

Here is the output of relevant systemd-related commands ("systemctl" and
"journalctl").


#systemctl status gdm3

● gdm.service - GNOME Display Manager
   Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor
preset:
enabled)
   Active: active (running) since Mon 2018-05-07 13:12:30 -03; 22min ago
 Main PID: 704 (gdm3)
Tasks: 3 (limit: 4915)
   Memory: 8.0M
   CGroup: /system.slice/gdm.service
   └─704 /usr/sbin/gdm3

May 07 13:33:21 berlin gdm3[704]: Child process -1061 was already dead.
May 07 13:33:21 berlin gdm3[704]: Child process 1046 was already dead.
May 07 13:33:21 berlin gdm3[704]: Unable to kill session worker process
May 07 13:33:21 berlin gdm-launch-environment][1670]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)
May 07 13:33:21 berlin gdm-launch-environment][1670]:
pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm
May 07 13:33:21 berlin gdm3[704]: GdmDisplay: display lasted 0.294573
seconds
May 07 13:33:21 berlin gdm3[704]: Child process -1691 was already dead.
May 07 13:33:21 berlin gdm3[704]: Child process 1670 was already dead.
May 07 13:33:21 berlin gdm3[704]: Unable to kill session worker process
May 07 13:33:21 berlin gdm-launch-environment][1708]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)





#journalctl -rx --unit=gdm

-- Logs begin at Mon 2018-05-07 13:12:28 -03, end at Mon 2018-05-07
13:39:32 -03. --
May 07 13:39:23 berlin gdm-launch-environment][1818]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)
May 07 13:39:23 berlin gdm3[1792]: Unable to kill session worker process
May 07 13:39:23 berlin gdm3[1792]: Child process 1796 was already dead.
May 07 13:39:23 berlin gdm3[1792]: Child process -1800 was already dead.
May 07 13:39:23 berlin gdm3[1792]: GLib: g_variant_new_string: assertion
'string != NULL' failed
May 07 13:39:23 berlin gdm3[1792]: GdmDisplay: display lasted 0.477945
seconds
May 07 13:39:23 berlin gdm-launch-environment][1796]:
pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm
May 07 13:39:23 berlin gdm-launch-environment][1796]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)
May 07 13:39:23 berlin systemd[1]: Started GNOME Display Manager.
-- Subject: Unit gdm.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit gdm.service has finished starting up.
--
-- The start-up result is RESULT.
May 07 13:39:23 berlin systemd[1]: Starting GNOME Display Manager...
-- Subject: Unit gdm.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit gdm.service has begun starting up.
May 07 13:39:23 berlin systemd[1]: Stopped GNOME Display Manager.
-- Subject: Unit gdm.service has finished shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit gdm.service has finished shutting down.
May 07 13:39:22 berlin gdm3[704]: GLib: g_hash_table_find: assertion
'version == hash_table->version' failed
May 07 13:39:22 berlin gdm3[704]: GLib: g_variant_new_string: assertion
'string != NULL' failed
May 07 13:39:22 berlin gdm3[704]: GLib: g_variant_new_string: assertion
'string != NULL' failed
May 07 13:39:22 berlin systemd[1]: Stopping GNOME Display Manager...
-- Subject: Unit gdm.service has begun shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit gdm.service has begun shutting down.
May 07 13:33:21 berlin gdm-launch-environment][1708]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)
May 07 13:33:21 berlin gdm3[704]: Unable to kill session worker process
May 07 13:33:21 berlin gdm3[704]: Child process 1670 was already dead.
May 07 13:33:21 berlin gdm3[704]: Child process -1691 was already dead.
May 07 13:33:21 berlin gdm3[704]: GdmDisplay: display lasted 0.294573
seconds
May 07 

Bug#880612: RFS: imenu-list/0.8-1 [ITP]

[Nicholas D Steeves]

Dear Chris,

This RFS is a simple one.  Fountain-mode (already in the archive) is
for screenplay writing, and imenu-list should be a recommended
dependency because it is part of the standard upstream-recommended
configuration (#880623).  Imenu-list provides fountain-mode with a
hyperlinked TOC as a sidebar.

On Sat, Jan 27, 2018 at 05:54:30PM -0500, Nicholas D Steeves wrote:
> Dear mentors and emacsen team,
> 
> I am looking for a sponsor for my package "imenu-list".  It is a
> dependency for the spacemacs packaging effort and should also be a
> recommended dependency for fountain-mode (see blocking bugs for more
> info).
> 
> Package name: imenu-list
> Version : 0.8-1
> Upstream Author : Bar Magal 
> URL : https://github.com/bmag/imenu-list
> License : GPL-3+
> Section : lisp
> 
> It builds this binary package:
> 
> elpa-imenu-list - show the current Emacs buffer's imenu entries in a 
> separate window
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/imenu-list
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/i/imenu-list/imenu-list_0.8-1.dsc
> 
> Alternatively, the repository can be cloned with this command:
> 
> git clone https://salsa.debian.org/emacsen-team/imenu-list
> 
> More information about hello can be obtained from 
> https://github.com/bmag/imenu-list
> 
> Regards,
> Nicholas




signature.asc
Description: PGP signature

Bug#898146: junit4: FTBFS with Java 10 due to removed SecurityManager methods

[Emmanuel Bourg]

Package: junit4
Version: 4.12-6
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10

junit4 fails to build with Java 10 due to the removal of several methods
from the java.lang.SecurityManager class:

 [INFO] -
 [ERROR] COMPILATION ERROR :
 [INFO] -
 [ERROR] 
/build/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[42,8]
 error: method does not override or implement a method from a supertype
 [ERROR] 
/build/junit4-4.12/src/test/java/org/junit/tests/running/core/MainRunner.java:[44,79]
 error: cannot find symbol
   symbol:   method getInCheck()
   location: variable originalSecurityManager of type SecurityManager
 [INFO] 2 errors
 [INFO] 

Bug#880612: RFS: imenu-list/0.8-1 [ITP]

[Nicholas D Steeves]

Dear Chris,

This RFS is a simple one.  Fountain-mode (already in the archive) is
for screenplay writing, and imenu-list should be a recommended
dependency because it is part of the standard upstream-recommended
configuration (#880623).  Imenu-list provides fountain-mode with a
hyperlinked TOC as a sidebar.

On Sat, Jan 27, 2018 at 05:54:30PM -0500, Nicholas D Steeves wrote:
> Dear mentors and emacsen team,
> 
> I am looking for a sponsor for my package "imenu-list".  It is a
> dependency for the spacemacs packaging effort and should also be a
> recommended dependency for fountain-mode (see blocking bugs for more
> info).
> 
> Package name: imenu-list
> Version : 0.8-1
> Upstream Author : Bar Magal 
> URL : https://github.com/bmag/imenu-list
> License : GPL-3+
> Section : lisp
> 
> It builds this binary package:
> 
> elpa-imenu-list - show the current Emacs buffer's imenu entries in a 
> separate window
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/imenu-list
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/i/imenu-list/imenu-list_0.8-1.dsc
> 
> Alternatively, the repository can be cloned with this command:
> 
> git clone https://salsa.debian.org/emacsen-team/imenu-list
> 
> More information about hello can be obtained from 
> https://github.com/bmag/imenu-list
> 
> Regards,
> Nicholas




signature.asc
Description: PGP signature

Bug#898145: Updating the mason Uploaders list

[Tobias Frost]

Source: mason
Version: 1.0.0-12.3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Thomas Scheffczyk  has not been working on
the mason package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#883218: RFS: elpy/1.20.0-1 [ITP]

[Nicholas D Steeves]

On Fri, May 04, 2018 at 12:24:05AM +0100, Chris Lamb wrote:
> Dear Nicholas,
> 
> > the experience I gained while investigating them will make diagnosing
> > potential future autopkgtest failures faster
> 
> I trust I'm not hearing any kind of apologetic subtext in your
> reply.. If I look think about anything that I might be vain enough
> to claim I "know", I usually learnt it when something broke. Or I
> broke it. :)

David Bremner tells me "the fancy word for that is experiential
learning" :p As far as subtext...mm, it wasn't intentional, and my
paragraph is kind of unclear, but it's possible there's some
unconscious self-promotion or a ":. autopkgtest is good"
subtext.  I'm optimistic about autopkgtest and DebCI.  Here is why:

> Anyway, thank you for your kind comments. Do let me know if/when
> you have any updates to the package, particularly one that fixes the
> FTBFS twice-in-a-row.

This was solved in #896998 "python-pip: missing required _vendor
module. Broken ${python:Depends}?".  Something in the sid's Python
ecosystem changed, broke python-pip, which broke Elpy's lisp parsing
of "python -m pip --help", which broke various self-tests.  I expect
Elpy's many self-tests are going to be a simultaneous PITA and
indirect QA tool, because the package will function as a kind of
canary for Python regressions in sid.  I'm sure there are other
packages that do this and Elpy's not unique in this way, of course.

> This interaction has made me think that a Debian Maintainer
> application should be on your TODO as well.

Thank you! :-D  That means a lot to me.

Debian Maintainer since 2016-12-21 ;-)
https://nm.debian.org/person/sten


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#898100: linux-image-3.16.0-6-amd64: SCTP IPv4/v6 mixed mode socket doesn't return peer adresses anymore (with sctp_getpaddrs())

[Ben Hutchings]

Control: found -1 3.2.101-1
Control: tag -1 upstream fixed-upstream patch

On Mon, 2018-05-07 at 09:49 +0200, Fred Boiteux wrote:
> Package: src:linux
> Version: 3.16.56-1
> Severity: normal
> 
> Dear Maintainer,
> 
> With latest Debian Jessie Linux kernel (3.16.56-1) version,
> my SCTP application, which uses an IPv6 socket to get IPv4 or IPv6 messages,
> can retrieve anymore IPv4 addresses from peers, using sctp_getpaddrs() 
> function.
> 
> I've identified the impacting patch :r
> sctp: Fixup v4mapped behaviour to comply with Sock API
> 
> I've rebuilt a kernel with this patch reverted, and my application works
> well with
> 
> I retrieve IPv4 peer addresses in a IPv6-mapped format, like :
> 0x00: 0A 00 A5 B8 C0 A8 FE B2 00 00 00 00  
> 0x0C: 00 00 00 00 00 00 FF FF C0 A8 FE B2  
> 0x18: 30 3B C0 1F  0;..
> which means : :::192.168.254.178%532691760 -> 192.168.254.178

Note that the flowinfo and scope_id were garbage here.

> But with the latest Jessie kernel, i get :
> 0x00: 0A 00 A5 B8 00 00 00 00 00 00 00 00  
> 0x0C: 00 00 00 00 00 00 FF FF 00 00 00 00  
> 0x18: 00 00 00 00  
> which translates to : :::0.0.0.0
> 
> 
> I've stated the same bug with latest Debian Wheezy kernel
> (linux-image-3.2.0-6-amd64 package, 3.2.101-1 version) :
> I don't know if i should add a separate bug report ?
[...]

No need; the bug tracking system can handle multiple versions.

It looks like this was fixed upstream by:

commit 9302d7bb0c5cd46be5706859301f18c137b2439f
Author: Jason Gunthorpe 
Date:   Tue May 26 17:30:17 2015 -0600

sctp: Fix mangled IPv4 addresses on a IPv6 listening socket

and I should apply that fix as well.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

Bug#898144: ITP: gnome-shell-extension-appindicator -- AppIndicator/KStatusNotifierItem support for GNOME Shell

[Matteo F. Vescovi]

Package: wnpp
Severity: wishlist
Owner: "Matteo F. Vescovi" 

* Package name: gnome-shell-extension-appindicator
  Version : 22
  Upstream Author : Jonas Kümmerlin 
* URL : https://github.com/ubuntu/gnome-shell-extension-appindicator
* License : GPL-2+
  Programming Lang: JavaScript
  Description : AppIndicator/KStatusNotifierItem support for GNOME Shell

This extension integrates Ubuntu AppIndicators and KStatusNotifierItems
(KDE's blessed successor of the systray) into GNOME Shell.

Features:
 - show indicator icons in the panel
 - reveal indicator menus upon click
 - double clicking an icon will activate the application window
   (if implemented by the indicator)
 - middle mouse click an icon to send a 'SecondaryActivate' event
   to the application. Support needs to be implemented in the application

I intend to maintain this package under the GNOME Team umbrella.

-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Raphael Hertzog]

Hi Chris,

On Mon, 07 May 2018, Chris Lamb wrote:
> I've just implemented this, but I notice that it overlaps with
> 
>  "W: latest-debian-changelog-entry-without-new-version"
> 
> Do you think it's still worth adding (essentially) an "E:" version
> of this? I would tend to be in favour, given that at least I did not
> see this warning when uploading "that" Django version.

I think this warning was not in place yet when you made that mistake.

Still I think that this warning was not correctly implemented. It should
really ensure that the epoch-less version does not match any former
epoch-less version (of entries matching the same source package name).

Ensuring that the version is greater is not sufficient as we can have had
multiple epoch jumps in the past and we can potentially have again the
same version even though the last two changelog entries have increasing
version numbers.

So yes I think that this "error-level" tag is still deserved and that we
should better implement latest-debian-changelog-entry-without-new-version. 

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#898143: Updating the jackson-dataformat-smile Uploaders list

[Tobias Frost]

Source: jackson-dataformat-smile
Version: 2.7.8-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Wolodja Wentland  has not been working on
the jackson-dataformat-smile package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#898140: Updating the jackson-databind Uploaders list

[Tobias Frost]

Source: jackson-databind
Version: 2.9.5-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Wolodja Wentland  has not been working on
the jackson-databind package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#898142: Updating the salt Uploaders list

[Tobias Frost]

Source: salt
Version: 2017.7.4+dfsg1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Wolodja Wentland  has not been working on
the salt package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#898141: Updating the jackson-dataformat-yaml Uploaders list

[Tobias Frost]

Source: jackson-dataformat-yaml
Version: 2.8.10-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Wolodja Wentland  has not been working on
the jackson-dataformat-yaml package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#895572: mupdf-tools: mutool fails with "Cannot convert between incompatible pixmaps"

[Stefan Monnier]

Ping?


Stefan


Stefan Monnier  writes:

> Package: mupdf-tools
> Version: 1.12.0+ds1-1
> Severity: normal
>
> Dear Maintainer,
>
> Recently, Emacs's doc-view-mode started failing for me in some cases.
> After tracking down the origin of the problem, it seems to be due to
> a problem in `mutool`.
> I can reproduce it with:
>
> mutool draw -o foo.png foo.pdf 1
>
> with the attached PDF file, which gives me:
>
> page foo.pdf 1error: Cannot convert between incompatible pixmaps
> error: Cannot convert between incompatible pixmaps
> warning: Ignoring error during interpretation
> error: Cannot convert between incompatible pixmaps
> warning: Ignoring error during interpretation
> error: Cannot convert between incompatible pixmaps
> warning: Ignoring error during interpretation
> error: Cannot convert between incompatible pixmaps
> warning: Ignoring error during interpretation
>
> even though both `evince` and `mupdf` display it just fine.
>
>
> Stefan
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable')
> Architecture: i386 (i686)
>
> Kernel: Linux 4.14.0-3-686-pae (SMP w/2 CPU cores)
> Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CH.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages mupdf-tools depends on:
> ii  libc62.27-3
> ii  libfreetype6 2.8.1-2
> ii  libharfbuzz0b1.7.2-1
> ii  libjbig2dec0 0.13-6
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libopenjp2-7 2.3.0-1
> ii  zlib1g   1:1.2.8.dfsg-5
>
> mupdf-tools recommends no packages.
>
> mupdf-tools suggests no packages.
>
> -- no debconf information

Bug#898139: ITP: octave-bsltl -- biospeckle laser tool library for Octave

[Rafael Laboissière]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissière 

* Package name: octave-bsltl
  Version : 1.1.1
  Upstream Author : Fernando Pujaico Rivera 
* URL : http://www.nongnu.org/bsltl/
* License : GPL-3+
  Programming Lang: Octave
  Description : biospeckle laser tool library for Octave

The BSLTL package is a free collection of routines for working with 
the digital processing of biospeckle laser pattern images in Octave, 
a scientific computation software.


This Octave add-on package is part of the Octave-Forge project.  It 
will be maintained in the realm of the Debian Octave Group.


A preliminary version of the package can be built using 
git-buildpackage from the repository 
https://salsa.debian.org/pkg-octave-team/octave-bsltl.git

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Scott Kitterman]

On Monday, May 07, 2018 01:35:30 PM Russ Allbery wrote:
> Scott Kitterman  writes:
> > Package: lintian
> > Version: 2.5.85
> > Severity: normal
> > 
> > Also, please reduce the certainty from certain.  It's not.
> > 
> > I'd just noticed depends-on-mail-transport-agent-without-alternatives.
> > I mainain approximately 10% of the packages affected by the check (3 of
> > 33) and in all those cases the check is wrong.  A cursory review of some
> > of the others clearly show it's incorrect for them as well (at least
> > 10).  I don't think a check with a false positive rate of a minimum of
> > nearly 50% is that useful.
> > 
> > In the case of my three, they depend on postfix without alternative
> > becuase they are only for postfix.
> 
> It sounds like there's both a bug and a certainty error here, but I don't
> think this check is a good example of something that should be pedantic.
> The dependency structure for depending on a generic MTA should be
> documented in Policy and only isn't because no one has found the time to
> write the patch.
> 
> A simple check for whether the depended-on MTA is also present in the name
> of the package would make a lot of these false positives go away.  If the
> package name contains "postfix" or "exim4" and depends on those MTAs, it's
> probably not a mistake.  :)
> 
> More generally, I suspect this tag should only affect packages that depend
> on the default (exim4).  If the package is already depending on a
> non-default MTA, I think it's highly likely that was intentional and
> Lintian is being more annoying than helpful here.
> 
> Pedantic isn't a dumping ground for buggy or uncertain checks.  If a check
> is known to be buggy or produce a lot of false positives but we don't want
> to delete it entirely because we think we can make it better in the
> future, that's what experimental is for.  Pedantic is for best-practice
> advice that's controversial, that is correct but may not be fixable (no
> upstream changelog, for instance), or that is minor
> quality-of-implementation details that a lot of maintainers aren't
> interested in messing with (upstream/metadata, for instance).

Thanks.  Experimental seems better.  Mostly I was thinking "not on the list of 
stuff most people see".  

I don't think that package name is a great trigger since, while many MTA 
specfic packages have the MTA name in the package name, not all do and there's 
no requirement for it.

Limiting it to packages that depend on exim4 would address all the false 
positives I saw (since I mostly know about postfix stuff).

Scott K

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Russ Allbery]

Scott Kitterman  writes:

> Package: lintian
> Version: 2.5.85
> Severity: normal

> Also, please reduce the certainty from certain.  It's not.

> I'd just noticed depends-on-mail-transport-agent-without-alternatives.
> I mainain approximately 10% of the packages affected by the check (3 of
> 33) and in all those cases the check is wrong.  A cursory review of some
> of the others clearly show it's incorrect for them as well (at least
> 10).  I don't think a check with a false positive rate of a minimum of
> nearly 50% is that useful.

> In the case of my three, they depend on postfix without alternative
> becuase they are only for postfix.

It sounds like there's both a bug and a certainty error here, but I don't
think this check is a good example of something that should be pedantic.
The dependency structure for depending on a generic MTA should be
documented in Policy and only isn't because no one has found the time to
write the patch.

A simple check for whether the depended-on MTA is also present in the name
of the package would make a lot of these false positives go away.  If the
package name contains "postfix" or "exim4" and depends on those MTAs, it's
probably not a mistake.  :)

More generally, I suspect this tag should only affect packages that depend
on the default (exim4).  If the package is already depending on a
non-default MTA, I think it's highly likely that was intentional and
Lintian is being more annoying than helpful here.

Pedantic isn't a dumping ground for buggy or uncertain checks.  If a check
is known to be buggy or produce a lot of false positives but we don't want
to delete it entirely because we think we can make it better in the
future, that's what experimental is for.  Pedantic is for best-practice
advice that's controversial, that is correct but may not be fixable (no
upstream changelog, for instance), or that is minor
quality-of-implementation details that a lot of maintainers aren't
interested in messing with (upstream/metadata, for instance).

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

Bug#897542: raincat: FTBFS: Could not find module `Item.Items'

[Markus Koschany]

I have pushed an update of raincat to

https://salsa.debian.org/games-team/raincat

I believe the new upstream release will address this issue but even if
not it should be doable to fix this.

I'm currently waiting for haskell-sdl2 which is in the NEW queue.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#422878: Dobrý deň, drahý, potrebujem vašu naliehavú odpoveď, máme dôležitú otázku na diskusiu o tom, že hovoríš anglicky?

[Sergeant Schieble Anderson]

Bug#898138: 389-ds-base: CVE-2018-1089

[Salvatore Bonaccorso]

Source: 389-ds-base
Version: 1.3.7.10-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerability was published for 389-ds-base.

CVE-2018-1089[0]:
unauthenticated ns-slapd crash via largefilter value in ldapsearch

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1089
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1089
[1] http://www.openwall.com/lists/oss-security/2018/05/07/2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888677: pdf-presenter-console: [regression] raster image rendering is really poor

[Francesco Poli]

On Mon, 7 May 2018 20:13:32 +0200 Andreas Bilke wrote:

> Evgeny Stambulchik found a nicer solution for this problem. The annotations
> from the PDF are removed from the document (at least in the in-memory
> version).
> 
> Therefore we can use render() again and have nice pixel graphics.
> 
> We released v4.1.2 to reflect this change.

Sounds nice: I am looking forward to giving it a try.

If I manage to find the time, I will rebuild and test it.
Otherwise, I will install the new version, as soon as it is packaged
for Debian unstable.

Thanks to you and to Evgeny for working on a solution!
Bye.

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


pgpT33gzkRyMA.pgp
Description: PGP signature

Bug#898137: nfsd: increase DRC cache limit

[Sergio Gelato]

Source: linux
Version: 4.9.88-1
Severity: wishlist
Tags: patch

I've run into this capacity limitation in stretch, which is addressed
upstream in Linux 4.15 by the following commit:

commit 44d8660d3bb0a1c8363ebcb906af2343ea8e15f6
Author: J. Bruce Fields 
Date:   Tue Sep 19 20:51:31 2017 -0400

nfsd: increase DRC cache limit

which trivially applies to Linux 4.9 (I haven't checked 3.16) and provides
significant relief in my use case. It would save me (and perhaps others)
work if this change could be included in Debian's 4.9 kernel packages;
otherwise I'll have to keep maintaining my own fork. (4.15 has other
issues so I don't want to use it in production yet.)

For the benefit of others who may be running into the same problem, here
is a more detailed description.

Symptom: an NFS server accepts only a limited number of concurrent v4.1+
mounts. Once that limit is reached, new clients get NFS4ERR_DELAY (10008)
replies to CREATE_SESSION. (This can be seen in the server's dmesg after
rpcdebug -m nfsd -s proc.) Increasing the number of nfsd threads has no
impact on the number of mounts allowed. A server with 512MB of RAM
only accepts 7 or 8 concurrent NFSv4.1+ mounts. From the perspective of
an affected client, mount.nfs appears to hang (triggering a kernel backtrace
after 120 seconds); in reality, though, it just keeps reissuing CREATE_SESSION
calls until one of them succeeds.

Pre-v4.1 clients are unaffected by this since sessions are new to NFS v4.1.

The proposed patch just increases the limit by an order of magnitude, at
the cost of using more kernel memory. As noted in comments in the source
code, it would be nice to make this tuneable by the server administrator.

Bug#898131: fbb: xfbbC lost ncurses support after rebuild

[Sven Joachim]

On 2018-05-07 20:27 +0200, Sven Joachim wrote:

> Package: fbb
> Version: 7.07-3+b1
> Severity: important
>
> In ncurses 6.1+20180210-1, the libncurses5-dev and libncursesw5-dev
> packages had been merged into a single libncurses-dev package.  In fbb,
> this has the rather strange and undesirable effect that the configure
> script fails to properly detect support for either ncurses _or_
> ncursesw:
>
> ,
> | checking for NcursesW wide-character library... yes
> | checking for working ncursesw/curses.h... yes
> | checking for working ncursesw.h... no
> | checking for working ncurses.h... yes
> `
>
> Clearly "checking for working ncursesw.h... no" is broken,

There is actually no ncursesw.h in Debian, but we do have cursesw.h in
libncurses-dev (previously in libncursesw5-dev).

> and later xfbbC is not linked with -lncursesw or -lncurses.

I tried to replace the rather outdated m4/ax_with_curses.m4 file with
the version from the autoconf-archive package, but that did not fix the
problem. :-/

Cheers,
   Sven

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Scott Kitterman]

Package: lintian
Version: 2.5.85
Severity: normal

Also, please reduce the certainty from certain.  It's not.

I'd just noticed depends-on-mail-transport-agent-without-alternatives.  I
mainain approximately 10% of the packages affected by the check (3 of 33) and
in all those cases the check is wrong.  A cursory review of some of the others
clearly show it's incorrect for them as well (at least 10).  I don't think a
check with a false positive rate of a minimum of nearly 50% is that useful.

In the case of my three, they depend on postfix without alternative becuase
they are only for postfix.

Scott K

Bug#898135: bibutils: CVE-2018-10773 CVE-2018-10774 CVE-2018-10775

[David Bremner]

Salvatore Bonaccorso  writes:

> Source: bibutils
> Version: 6.2-1
> Severity: normal
> Tags: security upstream
>
> Hi,
>
> The following vulnerabilities were published for bibutils. This report
> is to mainly make aware of the issues, I'm not sure if upstream were
> made aware of those, as the CVE references by now just consist of
> pointing to reproducers.
>
> CVE-2018-10773[0]:
> | NULL pointer deference in the addsn function in serialno.c in
> | libbibcore.a in bibutils through 6.2 allows remote attackers to cause a
> | denial of service (application crash), as demonstrated by copac2xml.
>
> CVE-2018-10774[1]:
> | Read access violation in the isiin_keyword function in isiin.c in
> | libbibutils.a in bibutils through 6.2 allows remote attackers to cause
> | a denial of service (application crash), as demonstrated by isi2xml.
>
> CVE-2018-10775[2]:
> | NULL pointer dereference in the _fields_add function in fields.c in
> | libbibcore.a in bibutils through 6.2 allows remote attackers to cause a
> | denial of service (application crash), as demonstrated by end2xml.
>

Thanks for the report. The use of "remote attacker" seems odd to me,
since bibutils does not provide any network functionality.

d

Bug#659069: Info received (Bug#659069: Info received (Bug#659069: why hasn't this been packaged yet? figured Debian folks would be all over it))

[Cyril Soler]

The retroshare software already ships debian packages for Debian 8+9, as can be 
seen here:
https://build.opensuse.org/project/show/network:retroshare
 
What we're asking for, is to Debian to include retroshare into their package 
repository so that:
- users can "sudo apt-get install retroshare"
- Tails can add retroshare to their distribution (being distributed by Debian 
is a requirement)

The process of creating binary installable  .debs with from Retroshare sources 
has been done for a
long time already.

What's missing is the distribution part. So according to the document you're 
citing page 45, what we
need is:

- "prepare a source package". We have this already. Packages build perfectly 
well with pbuilder. the
-pedantic flag may raise a few bits that I can fix easily.

- "find a Debian developer that will sponsor your package". This what I thought 
I was asking for.
Maybe the tag "RFP" is not appropriate then?

Thx for the help. We're definitely making some progress!

Cyril


On 07/05/2018 20:15, Niels Thykier wrote:
> Cyril Soler:
>> Could anyone from Debian consider this request please? It's been 6 years 
>> now, and I believe that a decent number of users are
>> actually expecting Debian to package Retroshare. Thx!
>>
> Hi Cyril,
>
> Unfortunately, packaging in Debian relies on a volunteer who is willing
> to donate their spare time working on packaging this application.  Given
> the bug is still an RFP (Request For Package), no one has committed to
> spend their spare time on it.
>
> I noticed that several people have expressed interest.  Please note that:
>
>   Anyone who is willing to put in the effort and accept that commitment
>   can package retroshare for Debian.
>
> If you are up for the challenge, Debian provides several resources
> including the debian-ment...@lists.debian.org mailing list for general
> Debian related packaging questions.
>   For a packaging tutorial, I can recommend
> https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial
> (which can also be used for "internal-only" packaging at work or at home
> if that has any interest).
>
> Thanks,
> ~Niels
>

-- 
To secure your emails, use PGP (e.g. enigmail on thunderbird)
My key: 0xD1F93BE3 

Bug#898135: bibutils: CVE-2018-10773 CVE-2018-10774 CVE-2018-10775

[Salvatore Bonaccorso]

Source: bibutils
Version: 6.2-1
Severity: normal
Tags: security upstream

Hi,

The following vulnerabilities were published for bibutils. This report
is to mainly make aware of the issues, I'm not sure if upstream were
made aware of those, as the CVE references by now just consist of
pointing to reproducers.

CVE-2018-10773[0]:
| NULL pointer deference in the addsn function in serialno.c in
| libbibcore.a in bibutils through 6.2 allows remote attackers to cause a
| denial of service (application crash), as demonstrated by copac2xml.

CVE-2018-10774[1]:
| Read access violation in the isiin_keyword function in isiin.c in
| libbibutils.a in bibutils through 6.2 allows remote attackers to cause
| a denial of service (application crash), as demonstrated by isi2xml.

CVE-2018-10775[2]:
| NULL pointer dereference in the _fields_add function in fields.c in
| libbibcore.a in bibutils through 6.2 allows remote attackers to cause a
| denial of service (application crash), as demonstrated by end2xml.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10773
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10773
[1] https://security-tracker.debian.org/tracker/CVE-2018-10774
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10774
[2] https://security-tracker.debian.org/tracker/CVE-2018-10775
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10775

Please adjust the affected versions in the BTS as needed.

Salvatore

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Chris Lamb]

Hi Raphael Hertzog,

I've just implemented this, but I notice that it overlaps with

 "W: latest-debian-changelog-entry-without-new-version"

Do you think it's still worth adding (essentially) an "E:" version
of this? I would tend to be in favour, given that at least I did not
see this warning when uploading "that" Django version.


Regards,

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

Bug#842464: use.t fixed with a whitelist

[Niko Tyni]

I've whitelisted the known warnings discussed in these bugs in alice_0.19-2,
for the benefit of getting autopkgtest checks to pass.

  % cat debian/tests/pkg-perl/use-whitelist 
  # see #898125 and #842464
  (Any::Moose|JSON::PP::Boolean)

-- 
Niko Tyni   nt...@debian.org

Bug#898134: debconf: [INTL:ru] Russian program translation update

[Yuri Kozlov]

Package: debconf
Version: 1.5.66
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

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

Russian program translation update is attached.

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

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


debconf.patch.gz
Description: application/gzip

Bug#898133: libgxps: CVE-2018-10767: Stack Buffer Overflow in calling glib in gxps_images_guess_content_type of gcontenttype.c

[Salvatore Bonaccorso]

Source: libgxps
Version: 0.2.2-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libgxps.

CVE-2018-10767[0]:
| There is a stack-based buffer over-read in calling GLib in the function
| gxps_images_guess_content_type of gxps-images.c in libgxps through
| 0.3.0 because it does not reject negative return values from a
| g_input_stream_read call. A crafted input will lead to a remote denial
| of service attack.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10767
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10767
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1575188

Regards,
Salvatore

Bug#898132: wget2: package lack manpage

[Jonas Smedegaard]

Package: wget2
Version: 1.99.1-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

wget2 lack manpage.

Being a successor of the quite well-documented wget I suspect (and
hope) this might be simply missed in the packaging.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlrwmuoACgkQLHwxRsGg
ASHnERAAoD78998acHpqVr2G5Kwh0D/XbUS8EuDAXcYZYSQLoTQiVKBjvRTjVqsZ
UjYDg/JOHKsjcgUF1n4oFg36knFz7wKe/EvM8Ps5XVeioWvtkOFqQEDRQ+4kB4i2
mjgDZbAFSAGZgZG+G3btoeKNK67br6f6dl4WqthVVOtFjUzo6lEbrep7keoh3BfC
zgWgPPi1L8d4Hd5kjqAglQdiqGK13Gf8b4GIPcxz0ynNKMbuSTc/RGUQwH1qzKxg
rWSrEcCYbpv6vE1yxEsIHTgvU21c5yNOsyWweQuS/xEkg9E9a9ZIUNxFQuCJWZNk
ZpmHxSuIpENvZ7OWMXCh5S7eJLjnZ4PXzbjRTYrbxPZ3jRpdO+MqnK2KQjx//070
6LciPg/Y2BYXMZ3lTrgjK/foDwyjykd9bvPZDEdrzMm96Akcnm//P43t8hvQxeT8
RfSLbkEbFVZyxux4lBBEn83zEO715RAIOopfShzb5P9E11vNlJ8XAOsE8/TD4kBw
lhUbsScVWAdTw2mX5qbOx+OVHI7TG0DfwvvvLG538euuFg9QeIMTEgyxAWXamrgm
55L+3J/QrvUQb+J1xI985rH/rloaxtoUBiueIK8ZrTRgJnHs0VvbPA5ygzzB36PY
oCIisDtTslFkSNX4RUxzhcvnNSO62ml7DJOeYj7ZX4OOxRSTV6w=
=agwn
-END PGP SIGNATURE-

Bug#898131: fbb: xfbbC lost ncurses support after rebuild

[Sven Joachim]

Package: fbb
Version: 7.07-3+b1
Severity: important

In ncurses 6.1+20180210-1, the libncurses5-dev and libncursesw5-dev
packages had been merged into a single libncurses-dev package.  In fbb,
this has the rather strange and undesirable effect that the configure
script fails to properly detect support for either ncurses _or_
ncursesw:

,
| checking for NcursesW wide-character library... yes
| checking for working ncursesw/curses.h... yes
| checking for working ncursesw.h... no
| checking for working ncurses.h... yes
`

Clearly "checking for working ncursesw.h... no" is broken, and later
xfbbC is not linked with -lncursesw or -lncurses.

Bug#898130: abcm2ps: CVE-2018-10771

[Salvatore Bonaccorso]

Source: abcm2ps
Version: 7.8.9-1
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/leesavide/abcm2ps/issues/17

Hi,

The following vulnerability was published for abcm2ps.

CVE-2018-10771[0]:
| Stack-based buffer overflow in the get_key function in parse.c in
| abcm2ps through 8.13.20 allows remote attackers to cause a denial of
| service (application crash) or possibly have unspecified other impact.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10771
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10771
[1] https://github.com/leesavide/abcm2ps/issues/17
[2] 
https://github.com/leesavide/abcm2ps/commit/dc0372993674d0b50fedfbf7b9fad1239b8efc5f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#659069: Info received (Bug#659069: Info received (Bug#659069: why hasn't this been packaged yet? figured Debian folks would be all over it))

[Niels Thykier]

Cyril Soler:
> Could anyone from Debian consider this request please? It's been 6 years now, 
> and I believe that a decent number of users are
> actually expecting Debian to package Retroshare. Thx!
> 

Hi Cyril,

Unfortunately, packaging in Debian relies on a volunteer who is willing
to donate their spare time working on packaging this application.  Given
the bug is still an RFP (Request For Package), no one has committed to
spend their spare time on it.

I noticed that several people have expressed interest.  Please note that:

  Anyone who is willing to put in the effort and accept that commitment
  can package retroshare for Debian.

If you are up for the challenge, Debian provides several resources
including the debian-ment...@lists.debian.org mailing list for general
Debian related packaging questions.
  For a packaging tutorial, I can recommend
https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial
(which can also be used for "internal-only" packaging at work or at home
if that has any interest).

Thanks,
~Niels

Bug#888677: pdf-presenter-console: [regression] raster image rendering is really poor

[Andreas Bilke]

Evgeny Stambulchik found a nicer solution for this problem. The annotations
from the PDF are removed from the document (at least in the in-memory
version).

Therefore we can use render() again and have nice pixel graphics.

We released v4.1.2 to reflect this change.



signature.asc
Description: PGP signature

Bug#898129: libfbclient2: depends on -doc package

[Matthias Urlichs]

Package: libfbclient2
Version: 3.0.3.32900.ds4-3
Severity: minor

aptitude sez:

--\ firebird3.0-common-doc (= 3.0.3.32900.ds4-3)
piA   3.0.3.32900.ds4-3   +132 kB

Please don't depend on the -doc package.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (550, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.15.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 libfbclient2 depends on:
pn  firebird3.0-common  
pn  firebird3.0-common-doc  
ii  libc6   2.27-3
ii  libgcc1 1:8-20180402-1
ii  libncurses5 6.1-1
ii  libstdc++6  8-20180402-1
ii  libtinfo5   6.1-1
pn  libtommath1 

libfbclient2 recommends no packages.

libfbclient2 suggests no packages.

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Chris Lamb]

Dear Raphael,

> Bad:
> 
> python-django (2:2.0-1) experimental; urgency=medium
> 
>   * New upstream stable release.
> https://docs.djangoproject.com/en/2.0/releases/2.0/
> 
>  -- Chris Lamb   Sat, 02 Dec 2017 18:36:33 +
> 
> python-django (1:2.0~rc1-1) experimental; urgency=medium
> 
>   * New upstream release candidate.

Well played sir, well played… :)


Best wishes,

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

Bug#897664: ruby-rjb: FTBFS: make[2]: javah: Command not found

[Chris Lamb]

forwarded 897664 https://github.com/arton/rjb/pull/63
thanks

I've forwarded this upstream here:

  https://github.com/arton/rjb/pull/63


Regards,

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

Bug#898128: linux-image-4.16.0-1-amd64: rma ryzen 5 1600x, swap with 2200g, only useable firmware for Taichi X370 is p4.40, then one of 4 gpus not listed in lspci

[Brahim Sbaiti]

Package: src:linux
Version: 4.16.5-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Can't use the 4th GPU, probably getting the replacement ryzen 5 1600x will 
solve the problem, the integrated gpu might be the culprit
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Version:
Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)

** Command line:
BOOT_IMAGE=/vmlinuz-4.16.0-1-amd64 root=/dev/mapper/re--vg-root ro 
cryptopts=target=sda5_crypt,source=/dev/disk/by-uuid/cacf3162-302c-4ef1-913c-bba1626e5d85,lvm=re--vg-root,keyscript=/lib/cryptsetup/scripts/unlock.sh

** Tainted: PWO (4609)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
[   30.140350] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.2/:15:00.2/:1d:04.0/:2c:00.1/sound/card2/input17
[   30.140591] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.1/:10:00.1/sound/card0/input12
[   30.140855] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.1/:10:00.1/sound/card0/input13
[   30.141102] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.2/:15:00.2/:1d:03.0/:21:00.0/:26:03.0/:28:00.1/sound/card1/input20
[   30.141366] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.2/:15:00.2/:1d:03.0/:21:00.0/:26:03.0/:28:00.1/sound/card1/input21
[   30.141623] input: HD-Audio Generic HDMI/DP,pcm=7 as 
/devices/pci:00/:00:08.1/:38:00.1/sound/card3/input6
[   30.141856] input: HD-Audio Generic HDMI/DP,pcm=8 as 
/devices/pci:00/:00:08.1/:38:00.1/sound/card3/input7
[   30.142094] input: HD-Audio Generic HDMI/DP,pcm=9 as 
/devices/pci:00/:00:08.1/:38:00.1/sound/card3/input8
[   30.142335] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.2/:15:00.2/:1d:04.0/:2c:00.1/sound/card2/input18
[   30.142621] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.1/:10:00.1/sound/card0/input14
[   30.142891] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.2/:15:00.2/:1d:03.0/:21:00.0/:26:03.0/:28:00.1/sound/card1/input22
[   30.143225] input: HD-Audio Generic HDMI/DP,pcm=10 as 
/devices/pci:00/:00:08.1/:38:00.1/sound/card3/input9
[   30.143477] input: HD-Audio Generic HDMI/DP,pcm=11 as 
/devices/pci:00/:00:08.1/:38:00.1/sound/card3/input10
[   30.340726] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: 
(null)
[   30.700069] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[   30.982897] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: 
(null)
[   30.997976] systemd-journald[384]: Received request to flush runtime journal 
from PID 1
[   31.016769] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[   32.707343] audit: type=1400 audit(1525714817.405:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=633 comm="apparmor_parser"
[   32.751452] audit: type=1400 audit(1525714817.449:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=631 
comm="apparmor_parser"
[   32.751655] audit: type=1400 audit(1525714817.449:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=631 
comm="apparmor_parser"
[   32.751857] audit: type=1400 audit(1525714817.449:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=631 
comm="apparmor_parser"
[   32.761520] audit: type=1400 audit(1525714817.461:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=636 comm="apparmor_parser"
[   32.834978] audit: type=1400 audit(1525714817.533:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=632 comm="apparmor_parser"
[   32.873432] audit: type=1400 audit(1525714817.573:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice" 
pid=634 comm="apparmor_parser"
[   32.873641] audit: type=1400 audit(1525714817.573:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice//gpg" 
pid=634 comm="apparmor_parser"
[   32.891222] audit: type=1400 audit(1525714817.589:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=638 
comm="apparmor_parser"
[   34.227011] resource sanity check: requesting [mem 0x000c-0x000f], 
which spans more 

Bug#884141: gdm3: fails to start: ("Oops! A problem has occured!" screen)

[Leandro Doctors]

Package: gdm3

Version: 3.28.1-1


--- Please enter the report below this line. ---

Dear Maintainer,

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

   * What led up to the situation?

Installed GDM3.


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

For now, just started to do some debugging... (I copy the output of
relevant systemd-related commands below.)

 From what I could see in the log (journalctl), it seems to have something
to do with GLibC...
However, I don't know to which glibc/gdm3 version to downgrade to, as I
have all packages from testing...

   * What was the outcome of this action?

When booting, GDM3 fails to start. It gives me the "Oops! A problem has
occured!" screen.
The system boots OK with both SDDM and LightDM.

   * What outcome did you expect instead?

GDM to start correctly.


   * Additional logs:

Here is the output of relevant systemd-related commands ("systemctl" and
"journalctl").


#systemctl status gdm3

● gdm.service - GNOME Display Manager
  Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor preset:
enabled)
  Active: active (running) since Mon 2018-05-07 13:12:30 -03; 22min ago
Main PID: 704 (gdm3)
   Tasks: 3 (limit: 4915)
  Memory: 8.0M
  CGroup: /system.slice/gdm.service
  └─704 /usr/sbin/gdm3

May 07 13:33:21 berlin gdm3[704]: Child process -1061 was already dead.
May 07 13:33:21 berlin gdm3[704]: Child process 1046 was already dead.
May 07 13:33:21 berlin gdm3[704]: Unable to kill session worker process
May 07 13:33:21 berlin gdm-launch-environment][1670]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)
May 07 13:33:21 berlin gdm-launch-environment][1670]:
pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm
May 07 13:33:21 berlin gdm3[704]: GdmDisplay: display lasted 0.294573
seconds
May 07 13:33:21 berlin gdm3[704]: Child process -1691 was already dead.
May 07 13:33:21 berlin gdm3[704]: Child process 1670 was already dead.
May 07 13:33:21 berlin gdm3[704]: Unable to kill session worker process
May 07 13:33:21 berlin gdm-launch-environment][1708]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)





#journalctl -rx --unit=gdm

-- Logs begin at Mon 2018-05-07 13:12:28 -03, end at Mon 2018-05-07
13:39:32 -03. --
May 07 13:39:23 berlin gdm-launch-environment][1818]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)
May 07 13:39:23 berlin gdm3[1792]: Unable to kill session worker process
May 07 13:39:23 berlin gdm3[1792]: Child process 1796 was already dead.
May 07 13:39:23 berlin gdm3[1792]: Child process -1800 was already dead.
May 07 13:39:23 berlin gdm3[1792]: GLib: g_variant_new_string: assertion
'string != NULL' failed
May 07 13:39:23 berlin gdm3[1792]: GdmDisplay: display lasted 0.477945
seconds
May 07 13:39:23 berlin gdm-launch-environment][1796]:
pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm
May 07 13:39:23 berlin gdm-launch-environment][1796]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)
May 07 13:39:23 berlin systemd[1]: Started GNOME Display Manager.
-- Subject: Unit gdm.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit gdm.service has finished starting up.
--
-- The start-up result is RESULT.
May 07 13:39:23 berlin systemd[1]: Starting GNOME Display Manager...
-- Subject: Unit gdm.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit gdm.service has begun starting up.
May 07 13:39:23 berlin systemd[1]: Stopped GNOME Display Manager.
-- Subject: Unit gdm.service has finished shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit gdm.service has finished shutting down.
May 07 13:39:22 berlin gdm3[704]: GLib: g_hash_table_find: assertion
'version == hash_table->version' failed
May 07 13:39:22 berlin gdm3[704]: GLib: g_variant_new_string: assertion
'string != NULL' failed
May 07 13:39:22 berlin gdm3[704]: GLib: g_variant_new_string: assertion
'string != NULL' failed
May 07 13:39:22 berlin systemd[1]: Stopping GNOME Display Manager...
-- Subject: Unit gdm.service has begun shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit gdm.service has begun shutting down.
May 07 13:33:21 berlin gdm-launch-environment][1708]:
pam_unix(gdm-launch-environment:session): session opened for user
Debian-gdm by (uid=0)
May 07 13:33:21 berlin gdm3[704]: Unable to kill session worker process
May 07 13:33:21 berlin gdm3[704]: Child process 1670 was already dead.
May 07 13:33:21 berlin gdm3[704]: Child process -1691 was already dead.
May 07 13:33:21 berlin gdm3[704]: GdmDisplay: display lasted 0.294573
seconds
May 07 13:33:21 berlin 

Bug#461486: RFP: luxcorerender -- physically based and unbiased rendering engine

[Francesco Poli]

Control: retitle -1 RFP: luxcorerender -- physically based and unbiased 
rendering engine


* Package name: luxcorerender
  Version : 2.0
  Upstream Author : David "Dade" Bucciarelli 
Jean-Philippe Grimaldi  
Jens Verwiebe 
Tom "Tomb" Bech 
* URL : https://luxcorerender.org/
* License : Apache-2.0
  Programming Lang: C++
  Description : physically based and unbiased rendering engine

LuxCoreRender is a physically based and unbiased rendering engine.
Based on state of the art algorithms, LuxCoreRender simulates the flow
of light according to physical equations, thus producing realistic
images of photographic quality.



I noticed that the upstream project has slightly changed name and URL,
so I thought I could re-title the RFP bug report and update the info...

This rendering engine looks very promising.
I hope someone will package it for inclusion in Debian!



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


pgp3cqEl1HI0K.pgp
Description: PGP signature

Bug#898074: Confirming gdm bug with kernel 4.9.0-6

[Magnus Wallin]

Confirming this bug on two different laptops (Dell and Lenovo) ; both running 
Debian 9 with kernel 4.9.0-6.

Booting from the previous kernel (4.9.0-6) works as expected (i.e. gdm starts 
in under five minutes!).

--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com 

Bug#896714: Bug#894865: RFS: cavestory-nx/1.0.0-1 [ITP] -- NXEngine is a Cave Story game engine clone

[Tobias Frost]

On Mon, May 07, 2018 at 07:35:04AM -0700, Carlos Donizete Froes wrote:
> Hi Tobias,
> 
> > Thanks. However, I after checking the post [1],
> >  - this seems to be a fan-forum, not the "official" one.
> >  - there is nothing noted in the post that the game assets are under a free
> >license, nor that it is in Public Domain.
> >  - Contraire, the thread explains well that the copyright is "all
> > rights reserved"
> >by default, and the original author "Pixel himself is historically very
> >closed-source/distribution-without-modification biased so it'd be an 
> > uphill
> >battle either way."
> > 
> > IANAL, but IMHO _this_ is a high legal risk for the Debian project.  Please
> > remove cavestory-nx from all Debian servers immediatly, at least until this 
> > is
> > solved. (Also Set the salsa repository to private)
> 
> I understand, it's a shame that the game data is very obscure in the
> part of the license.

Unfortunatly copyright law is "all rights reserved unless otherwise
noted" so rights must be explicitly granted.
Addtitionally, especially in this case, and paired with the ambiguity of
the word free (as in libre vs. as in beer) makes it not easier to judge.

> I am removing this package from mentors.d.n and also from salsa.d.o

Thanks for your prompt reaction!

> > Frankly, you should only fork for important reasons. Minor changes are not.
> > Instead, work together with cavestory-nx and get your fixes merged.
> 
> I understood in this case, as this my project there are no important
> traces to the license on the game data, there is no reason to continue.
> 
> I'm getting ready for another game project for Debian. :)

Looking forward for it. Please do not hesitate to ping me if you have
something to review!

Cheers,
-- 
tobi

> Thanks!
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀  Carlos Donizete Froes (a.k.a coringao) 
> ⣾⠁⢠⠒⠀⣿⡁  Fingerprint: 2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780
> ⢿⡄⠘⠷⠚⠋⠀  Debian Wiki: https://wiki.debian.org/coringao
> ⠈⠳⣄

Bug#898127: remmina: ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED error:14094438:SSL routines:ssl3_read_bytes:tlsv1

[Matt Weatherford]

Package: remmina
Version: 1.2.0-rcgit.29+dfsg-1~bpo9+1
Severity: normal

Dear Maintainer,

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

Remmina on Debian 9 does not want to connect to my Remote Desktop Windows 
2012R2 server.
Heres the error I see:

[10:33:32:169] [6526:6637] [ERROR][com.freerdp.core] - freerdp_set_last_error 
ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
[10:33:32:169] [6526:6637] [ERROR][com.freerdp.core.transport] - BIO_read 
returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert 
internal error
0002000F 0003


If I directly connect with xfreerdp it works fine


mbw@jaxi:~$ xfreerdp /log-level:debug  /u:NETID\\mbw  /v:senkaku
connected to senkaku:3389
Password: 
(remote desktop window pops up as expected)

mbw@jaxi:~$ xfreerdp --version
This is FreeRDP version 1.1.0-beta1 (git n/a)
mbw@jaxi:~$ which xfreerdp
/usr/bin/xfreerdp
mbw@jaxi:~$ 
mbw@jaxi:~$ 
mbw@jaxi:~$ remmina --version
StatusNotifier/Appindicator support: your desktop does support it and 
libappindicator is compiled in remmina. Good!
Remmina - 1.2.0-rcgit-29 (git rcgit-29)
mbw@jaxi:~$ 


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


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

Kernel: Linux 4.15.0-0.bpo.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 remmina depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.26-0+deb9u1
ii  dbus-x11 [dbus-session-bus]   1.10.26-0+deb9u1
ii  libatk1.0-0   2.22.0-1
ii  libavahi-client3  0.6.32-2
ii  libavahi-common3  0.6.32-2
ii  libavahi-ui-gtk3-00.6.32-2
ii  libayatana-appindicator3-10.5.2-1~bpo9+1
ii  libc6 2.24-11+deb9u3
ii  libcairo2 1.14.8-1
ii  libgcrypt20   1.7.6-2+deb9u2
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libice6   2:1.0.9-2
ii  libjson-glib-1.0-01.2.6-1
ii  libpango-1.0-01.40.5-1
ii  libsm62:1.2.2-1+b3
ii  libsoup2.4-1  2.56.0-2+deb9u1
ii  libssh-4  0.7.3-2
ii  libssl1.1 1.1.0f-3+deb9u2
ii  libvte-2.91-0 0.46.1-1
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  remmina-common1.2.0-rcgit.29+dfsg-1~bpo9+1

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.2.0-rcgit.29+dfsg-1~bpo9+1
ii  remmina-plugin-secret  1.2.0-rcgit.29+dfsg-1~bpo9+1
ii  remmina-plugin-vnc 1.2.0-rcgit.29+dfsg-1~bpo9+1

Versions of packages remmina suggests:
pn  remmina-plugin-exec   
pn  remmina-plugin-nx 
pn  remmina-plugin-spice  
pn  remmina-plugin-telepathy  
pn  remmina-plugin-xdmcp  

-- no debconf information

Bug#898126: theano: memory leak

[Rebecca N. Palmer]

Package: python-theano
Version: 1.0.1+dfsg-2
Severity: serious

(Filing this as RC to give myself time to investigate: I may downgrade 
it later.)


Memory usage increases over theano's tests, to ~6GB by the end of the 
python2 set (6981 tests) in Debian sid amd64, and enough to fail the 
Ubuntu arm64 and ppc64el builds (LP#1769672).

Bug#897572: urandom hang in early boot

[Laurent Bigonville]

Hello,

Apparently it's also happening for other applications that are starting 
later during the boot like GDM.


Somebody has reported an issue on IRC where GDM was taking upto 8 
minutes to start (dmesg was showing several "random: systemd: 
uninitialized urandom read (16 bytes read)" during boot)


That problem might impact lot of people I'm afraid.

Installing rng-tools5 seems to help in that case.

Bug#898125: alice: uses deprecated Any::Moose

[Niko Tyni]

Package: alice
Version: 0.19-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

  # perl -MApp::Alice -e1
  Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/App/Alice/MessageBuffer.pm line 3.

This (along with #842464) makes the package fail its autopkgtest checks, see

 http://ci.debian.net/packages/a/alice/unstable/amd64/

There's a related thread around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and I don't think we ever decided if the deprecation warning should be
disabled one way or another...

The primary bug of using Any::Moose still remains of course.
-- 
Niko Tyni   nt...@debian.org

Bug#897346: Re: Stalls on MacOS

[Gilles Fernandez]

Hi Chris,

I didn’t try any other file format, but will definitely do and get back to you!

Best,

Gilles

> On 7 May 2018, at 19:12, Chris Lamb  wrote:
> 
> [changing subject to match bug]
> 
> Hi Gilles,
> 
>> Very sorry for being that slow… I’ll be on vacation starting next week, 
>> I’ll get back to you at that point and do it properly with 
>> a reproducible pdf example and everything…
>  ^^
> 
> Hm, May I infer from that that this doesn't occur with other file types?
> I wonder if this to do with the fifo mechanism on MacOS.
> 
> Thanks for the debug output although unfortunately it does not reveal the
> underlying problem :)
> 
> 
> Regards,
> 
> -- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-

Bug#877093: libdata-dpath-perl: autopkgtest failure: use.t: Name "main::INC" used only once: possible typo at /usr/share/perl/5.26/Safe.pm line 372.

[Niko Tyni]

On Thu, Sep 28, 2017 at 05:35:48PM +0200, gregor herrmann wrote:
> Package: libdata-dpath-perl
> Version: 0.57-1
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: autopkgtest

> autopkgtest-pkg-perl's use.t fails with:
> 
> #   Failed test ' /usr/bin/perl -w -M"Data::DPath" -e 1 2>&1 produced no 
> (non-whitelisted) output'
> #   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108.

> # Name "main::INC" used only once: possible typo at 
> /usr/share/perl/5.26/Safe.pm line 372.

I've disabled use.t for now in 0.57-2 (though possibly just whitelisting
this specific warning would have been more appropriate.)
-- 
Niko

Bug#897346: Re: Stalls on MacOS

[Chris Lamb]

[changing subject to match bug]

Hi Gilles,

> Very sorry for being that slow… I’ll be on vacation starting next week, 
> I’ll get back to you at that point and do it properly with 
> a reproducible pdf example and everything…
  ^^

Hm, May I infer from that that this doesn't occur with other file types?
I wonder if this to do with the fifo mechanism on MacOS.

Thanks for the debug output although unfortunately it does not reveal the
underlying problem :)


Regards,

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

Bug#898124: ITP: hackersh -- a shell with built in security commands

[Manas Kashyap]

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

* Package name: Hackersh
  Version : 0.2.0
 Upstream Author : Itzik Kotler
* URL : https://github.com/ikotler/hackersh
* License : GPL-2.0
  Programming Lang: Python
  Description : It is a free and open source (license) shell (command
interpreter) written in Python with Pythonect-like syntax, built-in
security commands, and out of the box wrappers for various security tools.
  It is like Unix pipeline, but for processing security information and
metadata rather than bytes.

Bug#898092: sddm: takes extremely long time to start

[Leandro Doctors]

merges 898021.

Bug#898046: Acknowledgement (abcde: Options -T (because of octal) and -n broken)

[Steve McIntyre]

On Sun, May 06, 2018 at 09:57:57PM +0200, Samuel Hym wrote:
>retitle 898046 Options -T and -W broken because of octal
>thanks
>
>I ran into the same issue with -W than with -T, namely that handling
>of track numbers is broken for numbers >= 8, because of "0" prefix.

ACK. I'm just about to release a new upstream version (2.9.2) which
should *hopefully* fix a lot of this mess with octal... :-(

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Bug#898103: [Pkg-libvirt-maintainers] Bug#898103: missing dmidecode runtime depends

[Thomas Goirand]

On 05/07/2018 05:28 PM, Guido Günther wrote:
> control: -1 severity wishlist
> retitle: -1 Please depend on dmidecode
> 
> On Mon, May 07, 2018 at 02:19:09PM +0200, Thomas Goirand wrote:
>> On 05/07/2018 01:44 PM, Guido Günther wrote:
>>> On Mon, May 07, 2018 at 10:19:06AM +0200, Thomas Goirand wrote:
 Package: libvirt-daemon-system
 Version: 3.0.0-4+deb9u3+infomaniak+1
 Severity: important

 Hi,

 Running puppet-openstack, I get the below output:

 2018-05-04 14:31:34 + 
 /Stage[main]/Nova::Compute::Libvirt::Services/Service[libvirt] (err): 
 Failed to call refresh: Systemd restart for libvirtd failed!
 debian-stretch-rax-ord-0003871383 libvirtd[1071]: internal error: Failed 
 to find path for dmidecode binary

 Please add dmidecode as runtime depends, as this is needed in some cases.
>>>
>>> It is in Recommends: since you can do without it.
>>>  -- Guido
>>
>> In what way would a Depends: hurt?
> 
> Pulling in more stuff that often isn't needed.
>  -- Guido

The issue is that, when it's needed, it simply refuses to restart.

Never mind, I'll add it to nova-compute.

Cheers,

Thomas Goirand (zigo)

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Ben Hutchings]

On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote:
> I'm returning from vacation and jumping into the middle of this.
> 
> Back in the day when I wrote the code that became k5_get_os_entropy we
> viewed two cases:
> 
> * kadmind.  There we're likely to sometimes be generating long-term
>   shared secrets, and it seemed like strong random numbers were
>   important.
> 
> * krb5kdc, where we were generating session keys used for a few hours.
> 
> It seems like the change to use the getrandom syscall or other code
> changes have moved all the code  to prefer strong random numbers.
> That seems problematic at startup for the KDC.

There are basically three "strengths" of random numbers available now:

Weak:   /dev/urandom
Medium: getrandom(flags=0)
Strong: /dev/random, getrandom(flags=GRND_RANDOM)

k5_get_os_entropy() has switched from weak/strong depending on the
"strong" flag to always medium.  I think what you actually want is
medium/strong.

> Even if we do develop  a target indicating that the RNG is seeded, do we
> really want to block the KDC starup on waiting for this target?
> 
> I see a few issues here:
> 
> 1)  What's the right behavior for the KDC?
> 
> 2) What's the right behavior for kadmind?
> 
> 3) Do we want to provide such a service in krb5-kdc or elsewhere?
> 
> 4) What do we want to do about stretch?  It sounds like we need a fix
> that's small enough that we can backport it to stretch and not make the
> SRMs grumpy.

I'm going to start a discussion on debian-release, as we need to
coordinate a solution across multiple packages.

Jann Horn suggested improving systemd-random-seed.service so that it
actually credits entropy after feeding saved random bits into the RNG. 
But this will require some care to ensure we never use the same random
bits twice (including on multiple systems built from the same system
image).

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

Bug#893804: jessie-pu: package adminer/3.3.3-1+deb8u1

[Chris Lamb]

Hi Adam,

> Please go ahead; sorry for the delay.

adminer_3.3.3-1+deb8u1_amd64.changes uploaded.

> (With the same "coul" typo as the stretch upload.)

Thanks ;)


Regards,

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

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Sam Hartman]

I'm returning from vacation and jumping into the middle of this.

Back in the day when I wrote the code that became k5_get_os_entropy we
viewed two cases:

* kadmind.  There we're likely to sometimes be generating long-term
  shared secrets, and it seemed like strong random numbers were
  important.

* krb5kdc, where we were generating session keys used for a few hours.

It seems like the change to use the getrandom syscall or other code
changes have moved all the code  to prefer strong random numbers.
That seems problematic at startup for the KDC.

Even if we do develop  a target indicating that the RNG is seeded, do we
really want to block the KDC starup on waiting for this target?

I see a few issues here:

1)  What's the right behavior for the KDC?

2) What's the right behavior for kadmind?

3) Do we want to provide such a service in krb5-kdc or elsewhere?

4) What do we want to do about stretch?  It sounds like we need a fix
that's small enough that we can backport it to stretch and not make the
SRMs grumpy.

--Sam

Bug#898092: sddm: takes extremely long time to start

[Leandro Doctors]

On Mon, 7 May 2018, 04:43 Maximiliano Curia,  wrote:

> > Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
>
> It seems that there is a reported bug on 4.16.0 about this:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898021
>
> You might want to downgrade to 4.15.0 just to be sure that you a are
> affected
> by the same issue.
>
> Happy hacking,
>

Thanks a lot, Maximiliano! That was it!

Leandro

Duplicates #898021.

>

Bug#898087: Debian kernel packaging no longer accepts typical downstream version numbering.

[Ian Campbell]

On Mon, 2018-05-07 at 13:36 +0100, peter green wrote:
> Common practice for downstreams (whether complete derivatives or end
> users) is to version modified packages with a version number like
> 
> 4.16.5-1+something1
> 
> Where "something" is the name of a project, the name of the person
> performing the modification etc.
> 
> Unfortunately with 4.16.5-1 of the kernel package such a version
> number is no longer accepted with the error message "Invalid debian
> linux version". It seems the cause of this was the following change.
> 
>   (?P
> -[^-]+
> +[^-+]+
>   )
> 
> Reverting this change allowed me to get a succesful control files
> generation.

This was also reported in #898087

Bug#898103: [Pkg-libvirt-maintainers] Bug#898103: missing dmidecode runtime depends

[Guido Günther]

control: -1 severity wishlist
retitle: -1 Please depend on dmidecode

On Mon, May 07, 2018 at 02:19:09PM +0200, Thomas Goirand wrote:
> On 05/07/2018 01:44 PM, Guido Günther wrote:
> > On Mon, May 07, 2018 at 10:19:06AM +0200, Thomas Goirand wrote:
> >> Package: libvirt-daemon-system
> >> Version: 3.0.0-4+deb9u3+infomaniak+1
> >> Severity: important
> >>
> >> Hi,
> >>
> >> Running puppet-openstack, I get the below output:
> >>
> >> 2018-05-04 14:31:34 + 
> >> /Stage[main]/Nova::Compute::Libvirt::Services/Service[libvirt] (err): 
> >> Failed to call refresh: Systemd restart for libvirtd failed!
> >> debian-stretch-rax-ord-0003871383 libvirtd[1071]: internal error: Failed 
> >> to find path for dmidecode binary
> >>
> >> Please add dmidecode as runtime depends, as this is needed in some cases.
> > 
> > It is in Recommends: since you can do without it.
> >  -- Guido
> 
> In what way would a Depends: hurt?

Pulling in more stuff that often isn't needed.
 -- Guido

Bug#898104: [Pkg-libvirt-maintainers] Bug#898104: missing .service parameters

[Guido Günther]

control: -1 tags +moreinfo

On Mon, May 07, 2018 at 02:18:34PM +0200, Thomas Goirand wrote:
> On 05/07/2018 02:06 PM, Guido Günther wrote:
> > On Mon, May 07, 2018 at 10:24:20AM +0200, Thomas Goirand wrote:
> >> Package: libvirt-daemon-system
> >> Version: 3.0.0-4+deb9u3+infomaniak+1
> >> Severity: important
> >>
> >> Hi,
> >>
> >> After editing the libvirt parameters, it is necessary to restart it. At
> >> least, that's what does puppet-openstack. Unfortunately, it is currently
> >> impossible to do so, as libvirt doesn't stop. Adding these parameters
> >> fixes the issue:
> >>
> >> PIDFile=/var/run/libvirtd.pid
> >> KillSignal=SIGKILL
> >>
> >> As the .service file is generated by the upstream code, here's a small
> >> shell script that I hacked to insert the above at build time:
> > 
> > Can you provide more details?
> > 
> > systemctl restart libvirtd
> > 
> > works here.
> >  -- Guido
> 
> Can you try to do:
> 
> systemctl stop libvirtd
> 
> and see if the process is killed?

$ sudo systemctl stop libvirtd ; ps awux | grep '[l]ibvirtd' || echo "No 
process found"
No process found

Can you please tell me how you're restarting libvirtd?
 -- Guido

Bug#896787: ufw: missing build dependency on python3-distutils

[Jamie Strandboge]

On Tue, 2018-04-24 at 12:57 +0300, Adrian Bunk wrote:
> Source: ufw
> Version: 0.35-5
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/uf
> w.html
> 
> ...
> Performing tests 'installation/check_help'
> - installing
> Traceback (most recent call last):
>   File "./setup.py", line 29, in 
> from distutils.command.install import install as _install
> ModuleNotFoundError: No module named 'distutils.command'
> make: *** [debian/rules:39: install] Error 1
> 
> 
> Due to
> 
> python3.6 (3.6.5~rc1-2) unstable; urgency=medium
> 
>   * python3.6: Drop dependency on python3-distutils.
> ...
>  -- Matthias Klose   Tue, 20 Mar 2018 14:29:58 +0800

Thanks for reporting this issue. I've prepared 0.35-6 to address this
issue and it should be available in unstable soon.

-- 
Jamie Strandboge | http://www.canonical.com

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

Bug#897976: arptables bash script installed in /

[Alberto Molina Coballes]

Hi Cesare,

Thanks for report this bug! I've recently adopted this package and
some important modifications have been made and it seems some mistakes
also :)

The bug reported is related to the init script, indeed it has been
recently deleted in upstream [1], so that commit will be cherry picked
and applied to debian package, closing this bug.

Regards,

Alberto

[1] 
https://git.netfilter.org/arptables/commit/?id=988d6a4cd1b12718177bf3065f07faeabb208713

Bug#898123: ITP: ruby-websocket -- Universal Ruby library to handle WebSocket protocol

[Manas Kashyap]

Package: wnpp
Severity: wishlist
Owner: Manas kashyap 
X-Debbugs-CC: debian-de...@lists.debian.org, debian-r...@lists.debian.org

* Package name: ruby-websocket
  Version : 1.2.5
 Upstream Author : Bernard Potocki
* URL : https://github.com/imanel/websocket-ruby
* License : Expat
  Programming Lang: Ruby
  Description : It is a Universal Ruby library to handle WebSocket
protocol
  .
  It focuses on providing abstraction layer over WebSocket API instead
  of providing server or client functionality.

Bug#897975: gdm3: System fails to boot due to GDM restarting constantly.

[Detlev Zundel]

Package: gdm3
Version: 3.22.3-3+deb9u1
Followup-For: Bug #897975

Dear Maintainer,

after recent upgrade, gdm3 also fails to start as for the other reportes.  It
doesn't even switch to graphical mode and so the few text boot messages stay
visible.

In contrast to previous reporters, I do not see the "ICELockAuthFile fail"
error in my logs.  To narrow down problems I enabled debug mode in
/etc/gdm3/daemon.conf (as attached) and then gdm3 simply starts.  Disabling
debug mode makes gdm3 fail again.

Funnily enough, the last packages upgraded before the failing boot were pretty
innocent:

Start-Date: 2018-05-07  14:29:16
Commandline: apt dist-upgrade
Requested-By: dzu (1000)
Upgrade: linux-libc-dev:amd64 (4.9.82-1+deb9u3, 4.9.88-1), openjdk-8-jre:amd64
(8u162-b12-1~deb9u1, 8u171-b11-1~deb9u1), linux-image-4.9.0-6-amd64:amd64
(4.9.82-1+deb9u3, 4.9.88-1), libmad0:amd64 (0.15.1b-8, 0.15.1b-8+deb9u1),
openjdk-8-jre-headless:amd64 (8u162-b12-1~deb9u1, 8u171-b11-1~deb9u1), libsdl-
image1.2:amd64 (1.2.12-5+b8, 1.2.12-5+deb9u1), tzdata:amd64 (2018d-0+deb9u1,
2018e-0+deb9u1)
End-Date: 2018-05-07  14:30:23

Cheers
  Detlev

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 gdm3 depends on:
ii  accountsservice  0.6.43-1
ii  adduser  3.115
ii  dconf-cli0.26.0-2+b1
ii  dconf-gsettings-backend  0.26.0-2+b1
ii  debconf [debconf-2.0]1.5.61
ii  gir1.2-gdm-1.0   3.22.3-3+deb9u1
ii  gnome-session [x-session-manager]3.22.3-1
ii  gnome-session-bin3.22.3-1
ii  gnome-session-flashback [x-session-manager]  3.22.0-3
ii  gnome-settings-daemon3.22.2-2+deb9u2
ii  gnome-shell  3.22.3-3
ii  gnome-terminal [x-terminal-emulator] 3.22.2-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libaccountsservice0  0.6.43-1
ii  libaudit11:2.6.7-2
ii  libc62.24-11+deb9u3
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libgdm1  3.22.3-3+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libglib2.0-bin   2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libkeyutils1 1.5.9-9
ii  libpam-modules   1.1.8-3.6
ii  libpam-runtime   1.1.8-3.6
ii  libpam-systemd   232-25+deb9u3
ii  libpam0g 1.1.8-3.6
ii  librsvg2-common  2.40.16-1+b1
ii  libselinux1  2.6-3+b3
ii  libsystemd0  232-25+deb9u3
ii  libwrap0 7.6.q-26
ii  libx11-6 2:1.6.4-3
ii  libxau6  1:1.0.8-1
ii  libxcb1  1.12-1
ii  libxdmcp61:1.1.2-3
ii  lsb-base 9.20161125
ii  metacity [x-window-manager]  1:3.22.1-1
ii  mutter [x-window-manager]3.22.3-2
ii  policykit-1  0.105-18
ii  ucf  3.0036
ii  x11-common   1:7.7+19
ii  x11-xserver-utils7.7+7+b1
ii  xterm [x-terminal-emulator]  327-2

Versions of packages gdm3 recommends:
ii  at-spi2-core2.22.0-6+deb9u1
ii  desktop-base9.0.2+deb9u1
ii  x11-xkb-utils   7.7+3+b1
ii  xserver-xephyr  2:1.19.2-1+deb9u2
ii  xserver-xorg1:7.7+19
ii  zenity  3.22.0-1+b1

Versions of packages gdm3 suggests:
ii  gnome-orca3.22.2-3
ii  libpam-gnome-keyring  3.20.0-3

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
[security]
[xdmcp]
[chooser]
[debug]
Enable=true



-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#887107: My improvements to dl10n-check

[Laura Arjona Reina]

Hi Pino

El 05/05/18 a las 09:14, Pino Toscano escribió:
> Hi l10n people,
> 
> (please CC me, I'm not subscribed to debian-i18n@, or #887107)

> noticing the problems when extracting files (mostly translations) from
> sources, few months ago I reworked dl10n-check a little bit, and it
> ought to work better now.
> 
Thanks for caring! And thank you very much for your work.

> I sent all these improvements to a single merge request on salsa:
> https://salsa.debian.org/l10n-team/dl10n/merge_requests/1
> I think I described my commits, and my MR description, well-enough --
> but of course feel free to ask, comment, and try it in case.
> 

For now, I have "reviewed" (read the text of the commit message, and had
a look at the changes in the code) these commits:

dl10n-check: cache the Text::Iconv objects
a0106c8b

dl10n-check: move simple ASCII fallback to subroutine
13c97654

dl10n-check: make Text::Iconv mandatory
41adc507

dl10n-check: save DB at end only if needed
0ecf23fd

dl10n-check: add optional value for --careful
d1fb3695

dl10n-check: simplify org type collection
fe4563de

And all of them look good for me, but my Perl skills are very very few,
and I had not time to actually test... so more reviews welcome.

About the new dependency (libtext-iconv-perl) I have checked that it is
already installed in tye.debian.org. If looking at the remaining commits
I find that we need some other dependency and it is not installed, I
will send an RT ticket to DSA asking for it.

I will go on reviewing the commits and will test the "new" dl10n-check
launching manually the process in tye (when there are no other processes
running) and comparing the current and new databases (and running the
other jobs over the new database, to see if everything works ok).

> (I have other improvements for dl10n.git, but let's get this biggest
> chunk first.)
> 

Yes! I hope to put time on this during the week for tests, and I will
report to the bug the results.

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

Bug#898122: cups-daemon: Harden systemd service by default

[Chiraag Nataraj]

Package: cups-daemon
Version: 2.3~b4-2
Severity: wishlist

Dear Maintainer,

Given that cupsd must run as root, we should restrict its capabilities as much 
as possible. Given that the cups-daemon package provides the systemd service, 
would it be possible to harden it by default? The following options worked for 
me in the [Service] section (but we may need more extensive testing):

CapabilityBoundingSet=CAP_AUDIT_WRITE CAP_CHOWN CAP_DAC_OVERRIDE 
CAP_DAC_READ_SEARCH CAP_FOWNER CAP_FSETID CAP_NET_BIND_SERVICE CAP_NET_RAW 
CAP_SETGID CAP_SETUID
ProtectSystem=strict
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
PrivateTmp=true
PrivateDevices=true
MemoryDenyWriteExecute=true
LockPersonality=true
ReadWritePaths=/etc/cups /var/log/cups /var/run/cups /var/cache/cups 
/var/spool/cups

Sincerely,

Chiraag

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

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

Versions of packages cups-daemon depends on:
ii  adduser   3.117
ii  bc1.07.1-2
ii  libavahi-client3  0.7-4
ii  libavahi-common3  0.7-4
ii  libc6 2.27-3
ii  libcups2  2.3~b4-2
ii  libcupsmime1  2.3~b4-2
ii  libdbus-1-3   1.13.4-1
ii  libgssapi-krb5-2  1.16-2
ii  libpam0g  1.1.8-3.7
ii  libpaper1 1.1.24+nmu5
ii  libsystemd0   238-4
ii  lsb-base  9.20170808
ii  procps2:3.3.14-1+b1
ii  ssl-cert  1.0.39

Versions of packages cups-daemon recommends:
ii  avahi-daemon  0.7-4
pn  colord
ii  cups-browsed  1.20.3-1+b1

Versions of packages cups-daemon suggests:
ii  cups   2.3~b4-2
ii  cups-bsd   2.3~b4-2
ii  cups-client2.3~b4-2
ii  cups-common2.3~b4-2
ii  cups-filters [foomatic-filters]1.20.3-1+b1
ii  cups-ppdc  2.3~b4-2
ii  cups-server-common 2.3~b4-2
ii  foomatic-db-compressed-ppds [foomatic-db]  20180306-1
ii  ghostscript9.22~dfsg-2.1
pn  hplip  
ii  poppler-utils  0.64.0-1
ii  printer-driver-cups-pdf [cups-pdf] 3.0.1-5
ii  printer-driver-gutenprint  5.3.0~pre1-3
ii  printer-driver-hpcups  3.18.4+repack0-2
pn  smbclient  
ii  udev   238-4

-- Configuration Files:
/etc/apparmor.d/usr.sbin.cupsd changed:
/usr/sbin/cupsd flags=(attach_disconnected) {
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  capability chown,
  capability fowner,
  capability fsetid,
  capability kill,
  capability net_bind_service,
  capability setgid,
  capability setuid,
  capability audit_write,
  capability wake_alarm,
  deny capability block_suspend,
  # noisy
  deny signal (send) set=("term") peer=unconfined,
  # nasty, but we limit file access pretty tightly, and cups chowns a
  # lot of files to 'lp' which it cannot read/write afterwards any
  # more
  capability dac_override,
  capability dac_read_search,
  # the bluetooth backend needs this
  network bluetooth,
  # the dnssd backend uses those
  network x25 seqpacket,
  network ax25 dgram,
  network netrom seqpacket,
  network rose dgram,
  network ipx dgram,
  network appletalk dgram,
  network econet dgram,
  network ash dgram,
  /{usr/,}bin/bash ixr,
  /{usr/,}bin/dash ixr,
  /{usr/,}bin/hostname ixr,
  /dev/lp* rw,
  deny /dev/tty rw,  # silence noise
  /dev/ttyS* rw,
  /dev/ttyUSB* rw,
  /dev/usb/lp* rw,
  /dev/bus/usb/ r,
  /dev/bus/usb/** rw,
  /dev/parport* rw,
  /etc/cups/ rw,
  /etc/cups/** rw,
  /etc/cups/interfaces/* ixrw,
  /etc/foomatic/* r,
  /etc/gai.conf r,
  /etc/papersize r,
  /etc/pnm2ppa.conf r,
  /etc/printcap rwl,
  /etc/ssl/** r,
  @{PROC}/net/ r,
  @{PROC}/net/* r,
  @{PROC}/sys/dev/parport/** r,
  @{PROC}/*/net/ r,
  @{PROC}/*/net/** r,
  @{PROC}/*/auxv r,
  @{PROC}/sys/crypto/** r,
  /sys/** r,
  /usr/bin/* ixr,
  /usr/sbin/* ixr,
  /{usr/,}bin/* ixr,
  /{usr/,}sbin/* ixr,
  /usr/lib/** rm,
  # backends which come with CUPS can be confined
  /usr/lib/cups/backend/bluetooth ixr,
  /usr/lib/cups/backend/dnssd ixr,
  /usr/lib/cups/backend/http ixr,
  /usr/lib/cups/backend/ipp ixr,
  /usr/lib/cups/backend/lpd ixr,
  /usr/lib/cups/backend/parallel ixr,
  /usr/lib/cups/backend/serial ixr,
  /usr/lib/cups/backend/snmp ixr,
  /usr/lib/cups/backend/socket ixr,
  /usr/lib/cups/backend/usb ixr,
  # we treat cups-pdf specially, since it needs to write into 

Bug#894865: Bug#896714: Bug#894865: RFS: cavestory-nx/1.0.0-1 [ITP] -- NXEngine is a Cave Story game engine clone

[Carlos Donizete Froes]

Hi Tobias,

> Thanks. However, I after checking the post [1],
>  - this seems to be a fan-forum, not the "official" one.
>  - there is nothing noted in the post that the game assets are under a free
>license, nor that it is in Public Domain.
>  - Contraire, the thread explains well that the copyright is "all
> rights reserved"
>by default, and the original author "Pixel himself is historically very
>closed-source/distribution-without-modification biased so it'd be an uphill
>battle either way."
> 
> IANAL, but IMHO _this_ is a high legal risk for the Debian project.  Please
> remove cavestory-nx from all Debian servers immediatly, at least until this is
> solved. (Also Set the salsa repository to private)

I understand, it's a shame that the game data is very obscure in the
part of the license.

I am removing this package from mentors.d.n and also from salsa.d.o

> Frankly, you should only fork for important reasons. Minor changes are not.
> Instead, work together with cavestory-nx and get your fixes merged.

I understood in this case, as this my project there are no important
traces to the license on the game data, there is no reason to continue.

I'm getting ready for another game project for Debian. :)

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀  Carlos Donizete Froes (a.k.a coringao) 
⣾⠁⢠⠒⠀⣿⡁  Fingerprint: 2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780
⢿⡄⠘⠷⠚⠋⠀  Debian Wiki: https://wiki.debian.org/coringao
⠈⠳⣄

Bug#898121: smartmontools: move MTA to suggested dependencies

[Михаил]

Subject: smartmontools: move MTA to suggested dependencies
Package: smartmontools
Version: 6.5+svn4324-1
Severity: important

Dear Maintainer,
Please move 'mailx | mailutils' from 'Recommends' to 'Suggests'.
I am trying to package hw-probe 
(https://github.com/linuxhw/hw-probe/blob/master/debian/control), it 
depends from smartmontools, but smartmontools pools postfix in some 
cases via a chain of dependencies. The postfix package automatically 
enables the installed posrtfix se$

Postfix must not be pulled as a dependency of hw-probe.

Bug#834543: Won't fix

[Lisandro Damián Nicanor Pérez Meyer]

tag 834543 wontfix
thanks

Hi! Upstream just replied with two very detailed explanations on why this 
can't be fully fixed:



  Eike Ziller added a comment - 7 hours ago
  If this is with QMake projects: This is difficult, so we don't try. The
  compiler setting is foremost a setting for the code model, and the project
  support implementations try their best to get the build system to use that
  compiler.

  QMake defines the compiler through mkspecs. Qt Creator tries to use a mkspec
  that is appropriate for the compiler, and afaik also adds the PATH to the
  location of the C++ compiler in the kit. That works as long as the compiler
  name is the same as one of the supported mkspecs in Qt/QMake.

  For CMake and Qbs projects, Qt Creator can point the build system directly
  to the respective compilers, so there it should work.

And: 

  Tobias Hunger:
  CMake and qbs projects take the compiler settings into account.

  The other build systems do not: There the information set in the kit is used
  only to inform the build system about the compiler specific settings and the
  user is responsible to make sure the actual build system and Qt Creator
  agree on the compiler being used:-/

  Qmake is in a strange in-between place: Creator will switch mkspecs passed
  to qmake based on the toolchain used. So switching between g++ and clang++
  works – provided that the binaries are called "g+" and "clang+" and found in
  PATH. Unfortunately there is no reliable way to do more than that as qmake
  may or may not (based on the mkspec being used) ignore whatever is passed as
  compiler path from the outside.

  Recent creator versions at least warn when qmake and Qt Creator disagree on
  the toolchain being used.

So I'm afraid I am forced to mark this bug as wontfix.

Kinds regards, Lisandro.

-- 
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the world.
  -- seen on the net

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#898120: gpgme1.0: FTBFS with libgpg-error < 1.28, bump b-d

[Julian Andres Klode]

Package: gpgme1.0
Version: 1.11.1-1
Severity: serious

gpgme1.0 uses new API introduced in 1.28, gpgrt_alloc and friends
in cJSON.c, hence FTBFS with older versions.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#898119: cron: Removal of sharp character at the end of line in the header

[Stéphane Blondon]

Package: cron
Version: 3.0pl1-130
Severity: minor
Tags: patch


The header shown by crontab -l has a '#' character at the end of line 9:
# and day of week (dow) or use '*' in these fields (for 'any').#

It's due to a '\n' forgotten at the end of previous line in source code
(patch in attachment based on cron_3.0pl1-130.diff)

-- 
Stéphane
--- cron_3.0pl1-130.diff.orig	2018-05-07 15:50:16.539054242 +0200
+++ cron_3.0pl1-130.diff	2018-05-07 15:53:13.851529214 +0200
@@ -2326,7 +2326,7 @@
 +"# \n"
 +"# To define the time you can provide concrete values for\n"
 +"# minute (m), hour (h), day of month (dom), month (mon),\n"
-+"# and day of week (dow) or use '*' in these fields (for 'any')."
++"# and day of week (dow) or use '*' in these fields (for 'any').\n"
 +"# \n"
 +"# Notice that tasks will be started based on the cron's system\n"
 +"# daemon's notion of time and timezones.\n"